DADebug for serial output

I have built serial compatible versions of the lovely DADebug module. One outputs to serial, one does so on a ticker, and there’s the regular DADebug too.

http://www.heyrick.co.uk/random/dadebug.zip

My help file says:

DADebug builds to help debugging with RISC OS and a serial connection
=====================================================================

Uses the HAL DebugTX routine. Tested with DEVELOPMENT version of RISC OS
on the RaspberryPi (v5.21). May also work on the Beagle/Panda/etc, but
this has not been tested. *May* also work on the RiscPC, but NEEDS to
have RISC OS 5. Other versions don't provide the HAL facilities.


Three modules are provided. They all provide the same API, so only one
can be loaded at any given time.

The regular version of DADebug begins the debug log with "Debug start".

The serial versions begin it with "[0m[2J[1mDebug start"
which will clear the screen of an VT100/ANSI compatible terminal and then
set bold text. On a PC, use something like HyperTerminal...


DADbgSer
This version of DADebug will output to a serial terminal. You need to type
*DADPrint to get debug output to appear, and *DADReset to clear the log.

DADbgSerTick
This is like DADbgSer, with the exception that it will output the debug
information by itself every 60 seconds. This can be useful for times when
you cannot really get to a command line to instruct the module to output
its log. If you are doing low level stuff and the machine appears to freeze,
if the mouse pointer moves and the Caps Lock indicator works, it is quite
probable that the system ticker is still running. Just wait for the minute
to elapse, then the debug log should be transmitted to you.

DADebug
Basic "everyday" version of the module for use in a TaskWindow. You'll need
to use this if you don't have serial hardware.


With the RaspberryPi, I use a cheap little USB to 3.3V Serial interface that
I got from Amazon. Look for "Arduino USB serial", but check it runs at 3.3V
and not 5V.
Details here: http://www.heyrick.co.uk/blog/index.php?diary=20140620


Information on how to use DADebug is available here:
https://www.riscosopen.org/viewer/view/castle/RiscOS/Sources/Programmer/DADebug/Doc/DADebug?rev=1.4


DADebug was written by Ben Avison and Jeffrey Lee. It is released under the
standard Castle licence, which is available at:
http://www.castle-technology.co.uk/riscosbaselicence.htm
I neither claim, nor wish to imply, any sort of copyright upon this code. My
changes are minor (the ANSI style start mesage). Everything else was just
tweaking the build options and then building the module...


For reference, if anybody cares, the modification is as follows:
--8< --------
DefaultStartString
 [ UseHAL
        =       27,"[0m",27,"[2J",27,"[1mDebug start", 13, 10, 0
 |
        =       "Debug start", 13, 10, 0
 ]
--8< --------


I hope the options provided by these modules help make your debugging less
stressful!


Best wishes,

Rick.

Nice work!

Just a reminder: the correct process to update any Castle-licenced components from the RISC OS source tree is to send your patches to the ROOL code submissions address – code@riscosopen.org – and then we can host both the sources and any binaries built from it. It sounds like the various versions could/should just be build options for the same codebase and could be included in the HardDisc4 build somewhere (all three versions).

The other reason for doing it this way is to allow a review cycle to happen before anyone else starts to use the changes – because that would only cause problems if we decide things need to be done differently. For example, we might want to have the serial version of the module called “DADebugS”, which would break any pre-existing RMEnsures people had. We’d also ensure that any such changes have been correctly put through the allocations process (i.e. module names) to avoid conflicts with other peoples’ software.

Nice work!

Err… Thanks. All I did was basically hit Shift-Ctrl-C in Zap. ;-)

the correct process to update any Castle-licenced components from the RISC OS source tree is to send your patches to the ROOL code submissions address

This isn’t an update as such. The only addition was to switch the serial output to include an ANSI screen clear and to set bold text, because that is suitable for the terminal I am using. It also means the display becomes white on black instead of black on white (less eye strain in those long debugging sessions). I’m actually surprised nobody has (yet?) sent me death threats for sticking ANSI codes into debug output. ;-)
I provided the source mods in my message, as it’s a single line of data wrapped in a conditional, and it’s not even essential…

This was just intended as a release to help people who know of DADebug, and would like to use it with serial hardware without the hassles involved in building parts of RISC OS.
If it proves useful/popular, you might like to consider doing this as a part of the standard tools release. It was not intended to be a submission, just an aid to others.

It sounds like the various versions could/should just be build options for the same codebase

Yes indeed. You’ll need to modify the code to use external symbols, but:
TickerPrint SETL {FALSE} (line 38) sets whether or not it auto-prints every 60 seconds.
UseHAL SETL {FALSE} (line 41) sets whether or not it uses the HAL DebugTX routine.

could be included in the HardDisc4 build somewhere (all three versions).

I believe that would be useful for developers. Might make it nicer to debug Wimp programs if you could see the program running under RISC OS on one screen, and debug output (under whatever) on another screen. Side by side, at the same time.

It does, however, raise an interesting question. Is it better to consider this to be three slightly different incarnations of the same DADebug (as I have), or to consider these to be three different things?

It’s important.

Argument AGAINST three incarnations: You can’t have different versions loaded at one time. It isn’t currently possible to spool to a TaskWindow and output via serial.
Argument FOR three incarnations: The host program will likely be looking for the presence of one of the SWIs to determine if DADebug is actually present. Using the same SWI chunk in each incarnation means the host program can be completely agnostic to what DADebug is actually doing. As long as the interface matches, it could be bouncing IP packets of Langley and spitting the results as Morse on ticker tape for all anybody cares…

Argument AGAINST three different: You do this, the whole thing is dead in the water. What software author is going to want to support multiple debug tools? They’ll pick the one that works for them and ignore the rest.
Argument FOR three different: You could have different messages going to different devices, I guess? I’m pretty much for the idea of this being three incarnations so… ;-)

For example, we might want to have the serial version of the module called “DADebugS”, which would break any pre-existing RMEnsures people had.

I would hope developers around here would be smarter than to assume the presence of any specific debug utility in a release version of their software. :-)
The thing I’m working on doesn’t even RMEnsure it. If DADebug is not loaded, the SWI lookup fails and it tells the debug() function to drop out immediately.

We’d also ensure that any such changes have been correctly put through the allocations process (i.e. module names) to avoid conflicts with other peoples’ software.

Oh, for sure. Anybody that releases stuff without an allocation needs to be slapped upside the back of the head. Or maybe just poked with a cattle prod.

send your patches to the ROOL code submissions address – code@riscosopen.org – and then we can host both the sources and any binaries built from it

Any chance of an auto responder on this, so we know that the submission(s) have made it?

Edit: Hehe, (another) Textile parser fail!