What methods do you use to debug PASM-code ?
StefanL38
Posts: 2,292
Hello,
most of the time I'm programming in SPIN.
But for one thing that needed raw speed I coded in PASM.
It was a lot of try and error.
Now I have a new thing where PASM is required
What methods do you use to debug PASM ?
best regards
Stefan
most of the time I'm programming in SPIN.
But for one thing that needed raw speed I coded in PASM.
It was a lot of try and error.
Now I have a new thing where PASM is required
What methods do you use to debug PASM ?
best regards
Stefan
Comments
-Phil
I use Ariba's PASD in a pinch. It can usually do surprising things in addition to what it's supposed to do.
There are limits though and I often forget how to set it up because I don't use it much.
I do vividly remember PASD limits most of the time:
- No breakpoints on self-modifying code instructions
- you must add a dozen or so longs to your PASM so the debugger will work
- the ORG label must have a space before it. i.e. " entry org 0"
- you can not use single brace block comments { ... } that confuses PASD
- the debug memory and cog windows are always on top with no option (very annoying)
- you must respecify the com port every time you restart the application
- in some circumstances given compile errors, the window positions will require terminating programs via taskbar
- finally convenient toolbar buttons are not available
- Added: also one file can not contain multiple sections of dat ... org ... and "res" variables in the middle.
Aside from that list of details, PASD is really a great tool. Just memorize the list [noparse]:)[/noparse]Cluso99's PASM/SPIN debugger can be useful, but it requires manually tracking source lines.
I've never bothered with POD beyond some simple tests.
The GEAR emulator makes absolutely no sense to me.
Also, avoid at all cost paying for a PASM debugger [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230
Post Edited (jazzed) : 6/18/2009 8:13:07 PM GMT
There is PASD. It allows me to initially single-step debug asm code to verify that SPIN variables are passed to the cog, and that the code is actually doing what's intended.
Then I use ViewPort to 'scope' in logic analyzer mode to view the I/Os running at full speed. And using a spare or several spare I/Os to output a pulse at appropriate locations of the code, one can view the timing of a cog.
These are the 'crutches' I've found useful. Of course, one needs spare cogs to use these; PASD uses 1 cog, ViewPort uses 2 cogs at 20 MHz sampling to 4 cogs at 80 MHz sampling. For my application, the 20 MHz speed is adequate, as I have few spare cogs with two Props.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
Better (or worse) than debugging Win programs using·only printf() statements.
@Stefan: I've been using Viewport very recently for this, but if you are doing asm to do *really* fast stuff, it might not work for that... grab a 'real' scope or logic analyzer. (See contradiction above [noparse]:)[/noparse]
cheers,
- Howard
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"This device contains recyclable materials, which can be re-decomposed
and re-integrated into brand new marvels... We strongly encourage you
to contact the provided information and recycle yourself always. "
You can then use TV, VGA, or serial to monitor this HUB RAM variable...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
I appreciate anyone taking time to produce a solution also ... especially if it's easy to understand/use.
Forum search is just one of those other things you have to play with to learn how to make it useful.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230
-Phil
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle
Post Edited (Leon) : 6/18/2009 9:54:04 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
the XMOS architecture is precisely what gives them the room for debugging tools·- after all, their primary core the XS1 is 32-bit, has registers, is threaded, has thread state identifiers ---·even the littlest one in·their pack·( XS1-G2 144BGA·)· has two xcores, 128k of SRAM·and runs 800 MIPs.·Althougth its perhaps not really a fair comp. to the Propeller I, I do agree that Parallax should have planned in some debugging hooks at the very least. As amazing as the Prop is, that's a surprising oversight, IMO.
Even though JTAG is standard, I know many people who·dislike·using·it.· Perhaps Parallax will jump two leaps with the PropII by having a process-transparent debugger that is so good it sets a *new* industry standard for debugging. (Then, again, maybe we are putting too many hopes into the new Prop.!)
just my 2 pence [noparse]:)[/noparse]
- Howard
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Post Edited (CounterRotatingProps) : 6/19/2009 12:46:08 AM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,
I used to use POD, but I can't use in when working on XMM code. Most of my really tricky PASM debuggging is done using the debug LED on the Hydra. I wrote some simple code that takes a long value and flashes it out on the debug LED in Hex.
Surprisingly effective.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
I can see the benefit but as an example I see everyone talk about doing just what you said adding an outa to an led or using the led on the hydra as a debugging aid but???????
OK so I write a program but how does that help me in anyway? so if I can turn on an led doesn't that only mean that part of the programming is working? another example I see some of the code in the obex downloads
a few of them have the fullduplexserial and keyboard in the code but commented out ?? I know they put them there for debugging but I just cant get my hands around the concept I would love a simple example or explanation
@mikediv,
For me using a debugger is good for 2 things: 1) finding and fixing mistakes, and 2) verifying assumptions. With print statements and a serial port, you can accomplish a great deal, but there are limits. Using LED/pin states you can track the progress of your program or inspect variables. Rayman's approach to displaying PASM states with wrlong, etc... allows infinitely more flexibility than LEDs. You need a hook for that though.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230
Slow or not, it was actually ok for that.
It's better now for having breakpoints. Good for understanding what little bits of code do.
On the top of my to get list is a decent scope. I know I would lean toward the Phil method of just outputting to spare pins.
Right now, I normally use a video display and write things to HUB memory. A simple 40x24 text screen with an ASCII font works great. Some people are either working on single pin NTSC monochrome drivers, or have them done. I'll jump on one of those when I get the chance. One single pin, with memory mapped video text can do a lot.
I don't use the LED blinker idea much. When I'm working on the Prop, I've got a video capture device, which makes it easy to just write to the display. Making little movies isn't a bad idea either. Write a whole bunch of stuff, then trace back through, delete the large MPEG when done.
Normally incorporating something like video is a problem, but not on the Prop. That is what is cool about the chip. Just include the video driver and point it at some area of HUB memory, then forget about it. Nice...
One other thing I've done is just throw all of HUB memory onto a higher resolution display to see a sort of dynamic memory map. Helped to find a bad pointer writing to the wrong area of RAM once.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
I've been nebulously expanding since 1999 [noparse]:)[/noparse]
Good guess on the Nebula name, but it's actually the Carina Nebula's Keyhole Nebula between "God's middle finger" and the Dog-fish globule. See en.wikipedia.org/wiki/File:Keyhole_Nebula_-_Hubble_1999.jpg ... it's my windows wall-paper.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230
So, you're a hardware guy ... what do you do when your hardware does not work correctly? You measure at some points of interest to understand what might be wrong and for example in a signal path you try to spot the point where the signal starts getting wrong. You check the ins and outs whether they meet your expectation.
That's exactly what debugging software is about. You want to see the ins and outs of the software. Simple blinking LED's can be used to track the path of the software for example if you have jumps which might be conditional. If you found out that the software ends in a branch of code where you did not expect it then you start watching the variables which are used to make the decision.
Using 8 LEDs gives the possibility to show bytes of in or out variables.
Using TV or Serial interface gives you more possibilities in showing what's going on, but needs more efford/changes of the original program.