DADebug for serial output
Rick Murray (539) 13840 posts |
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 " |
Steve Revill (20) 1361 posts |
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. |
Rick Murray (539) 13840 posts |
Err… Thanks. All I did was basically hit Shift-Ctrl-C in Zap. ;-)
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. ;-) 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.
Yes indeed. You’ll need to modify the code to use external symbols, but:
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 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.
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. :-)
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. |
Rick Murray (539) 13840 posts |
Any chance of an auto responder on this, so we know that the submission(s) have made it? Edit: Hehe, (another) Textile parser fail! |