ASM development & Debugging - tips, tricks & approaches

mike101video

Hi all,
I've had my Propeller chips for a while, and have some simple boards operating, but now I have time to really get into building the application I want. This will entail modifying the Full Duplex Serial object to hand Sony LANC protocal. ( I can get an outboard chip to do this, but it will ideal to run in a COG.)

I've worked in assembler from ranging from Intel 8086, IBM/360 ( Yes, I go back that far - and further) to PIC. Of-course, my first listing of an asm prog is perfect but it never runs right.......

I've asking if there if any one has developed a set of asm debug tools (Traps, variable montoring, trace points, etc), or has an approach to debugging on the propeller that they would like to share. It would seem that the Propeller is ideal for this sort of work, as one COG may be dedicated as a debug engine, monitoring/controlling the asm application in another COG. It could be a mix of SPIN and ASM code.

Linked to this: is any one using a MACRO or text preprocessor with ASM code. I could see writing code with a "TRAP id#" statement, that is preprocessed into either code, or nothing, depending on whether debug options are turned on.

Or, am I defining a project I need to do before I get started on my real project.

These are great forums, and I have dropped in whenever I can - and a great product!!!!

thanks in advance for any help/comments....

Mike

Mike Green

I've thought about using a macro preprocessor with assembly and SPIN (it's all the same to the compiler). With assembly, the routines are generally so small (in terms of lines of code) that I don't think it matters. It might be different for building data tables with packed information, but that hasn't arisen yet.

I've done quite a bit of debugging in assembly. The best way I've found is to have a VGA or TV text driver running in one cog and pass the address of its screen buffer to the assembly routine, usually by having the SPIN startup routine store the address in a constant in the DAT section. That way it's there in cog memory when the assembly routine is started. I then have some short routines in assembly that convert values to binary text (%0000) or hexadecimal ($0000) directly into sequential locations in the screen buffer or copy individual characters into successive locations. You can even put text inline, but I haven't bothered. These display routines are written to save or not use the carry and zero flags so they can be called from anywhere in your code.

It wouldn't be hard to generalize this into a single routine with a call followed by a long word packet with an address, screen coordinates, and a formatting code, but I haven't really needed that. Attached is one version that I've used. It is intended for use with the hires VGA text driver which stores successive characters in ascending byte locations. If you want to use this with the lores VGA text driver or the TV text driver, you'll have to modify the DebugOut routine to store the characters as words (and increment the address by 2) since these drivers include the character and its color information in a 16 bit word.

The other stuff you mentioned like traps, trace points, etc. hasn't been necessary. Routines in Propeller assembly usually are fairly short or, if long, are broken up into small segments that can be debugged individually. The assemble/debug cycle is so short that you can usually find a bug, correct it, try again, then strip out the old debug code, insert new code, and try again, all in one or two minutes.

Similarly, you can write a special purpose SPIN interface to an assembly routine that produces/displays test information very easily and change it very quickly.

Phil Pilgrim (PhiPi)

Mike,

Mike Green said...
The other stuff you mentioned like traps, trace points, etc. hasn't been necessary. Routines in Propeller assembly usually are fairly short or, if long, are broken up into small segments that can be debugged individually.

This is a very interesting point and bears additional emphasis. What make these kinds of debugging tools necessary with other processors are the all the interrupts and multitasking required by most real-time applications. These all go away when the job can be partitioned among multiple processors.

I, too, have toyed with writing a preprocessor — a Propeller Helper, if you will. It would be a convenient way to try out features we might desire for the compiler. It's one thing to suggest new features to the developers; another, to demontrate concretely how they might work. To be successful, such a preprocessor would have to integrate as seamlessly as possible into the operation of the IDE. That could be tricky, since there aren't really any convenient hooks for compiling a preprocessed program from the command line. For now, it would have to be a two-step process.

-Phil

Mike Green

One other thought ... Because any cog can observe the state of all the I/O pins and can set the state of I/O pins that are used as inputs by another cog, it is possible, even easy, to write a high level display/logging program in SPIN and have it monitor the I/O going on in another cog. The logic analyzer written by Paul Baker is one example. It can run in one set of cogs with its own keyboard and display while something else is running in a different set of cogs. I've written a co-processor simulator that accepted serial I/O commands from one cog and pretended to be a Stamp-based coprocessor by supplying some "canned" replies directly to the I/O register bits all the time while displaying the transaction on a TV monitor while the "real" program was using a VGA display and PS/2 keyboard.

Once the "real" program was debugged, it was a simple matter to remove the references to the simulator (written as a separate object) and plug in a Stamp to the I/O pins. The only statement removed from the "real" program was the call to the initialization routine in the simulator that provided the pin numbers to use.