Kudos to PASD

JasonDorie · 2011-03-12 00:22

I decided it was time to spend a little more effort on my quadrotor. One thing I've been wanting to do is convert the i2c gyro reading code from Spin to PASM. I took a bunch of code from the sdspiFemto routines by Mike Green, added some setup code, twiddled some things, and got.... nothing.

I spent a decent amount of time debugging, using my oscilloscope and various "write intermediate to hub ram" methods, but wasn't really getting anywhere. I captured images of the scope readings and compared them between the PASM (slowed down) and the Spin versions. Everything looked fine.

Then I Googled for "PASM debugger" and happened upon PASD. A few short hours later, I have a complete PASM version of my i2c gyro code. The Spin version maxed out at about 250Hz. The PASM version, doing identical work, takes 21200 cycles, meaning it could run at 3773Hz with an 80MHz clock.

So, to the person who wrote this wonderful tool, thank you!! To anyone who hasn't tried it, you should - it just might change your life. PASM no longer scares me.

MagIO2 · 2011-03-12 01:11

Nice feedback!

I also downloaded PASD but somehow I did not try it yet .... same with ViewPort.
At the time when I downloaded PASD I decided to write my own Propeller Simulator in Java for learning about the internals of the propeller. But it's far away from being complete and would need a lot of work to add a nice GUI. The point is ... in that time I forgot about PASD and maybe did not have a real need for it because the PASM code I wrote simply worked.
But I think I'll now spend some time with PASD and ViewPort to see where these can help me.

Thanks for the reminder!

HShanko · 2011-03-12 10:39

I've been using PASDfor several years now to initially debug new PASM code. Just to check that what I want is really what I wrote. Always lots of bugs/errors/typs to creep in. And having several cats around, to verify they didn't also provide some input to the keyboard!!! Worst is if you just selected a block of code and they touch a key and you blinked at that moment. Gone!

Even though one can only debug one PASM cog at a time, it is one tool that relatively easily does the job.

Mike G · 2011-03-12 11:02

I've been using PASD for a few years too. I believe Ariba developed PASD.

jazzed · 2011-03-12 11:35

I used PASD until i realized i needed features it does not offer and then developed my own. PASD is a good tool for understanding what PASM does in many respects, but like anything else it has limits.

HShanko · 2011-03-12 13:54

@jazzed,

Is you PASM debugger released somewhere? Available?

What limits does exceed over PASD?

Ariba · 2011-03-12 16:54

Jason, thank you for the kudos. It's always nice to get a positive feedback.
I've done PASD in the early days of my Propeller carriere, mainly to fully understand PASM.I think today a debugger should be done with the listing output of BST, which will make it better and easier.

Andy

jazzed · 2011-03-12 23:38

HShanko wrote: »

@jazzed,

Is you PASM debugger released somewhere? Available?

What limits does exceed over PASD?

@HShanko, It is posted in the forum. I'm not trying to hijack this thread, so I won't go into details here.
Andy's right about the BST list files. Brad added some nice options for Spin/PASM source level debug.

JasonDorie · 2011-03-13 00:04

Today I got my PASM code to read an adxl345 accelerometer on the same bus as the gyro, run the cordic routines to convert cartesian to polar, and it all fits in a single cog. Without PASD this would've taken a LOT longer, so thanks again Andy.

Do you still actively work on the software? If not, would you be willing to share code? I had been thinking of ways to implement my own when I found yours, so I'm curious as to how it works, particularly the breakpoints and waitcnt handling.

Ariba · 2011-03-13 03:05

I made some changes to the GUI part and the source code parser last year. But I don't want to make changes to the part that interacts with the PASDebug-cog and the intraction of the two cogs - this is very complicated and I don't remember all the details.

The Windows application is made with PureBasic 4, which is not free (costs about 100$), and my source has very few comments. So I don't know if the Basic source code can be of any use for you.

There was some description of how it works in the old PASD thread which was accidentally deleted by a Moderator because of a SPAM post.

Basically the Windows App has access to the debugged cog memory throught the helper cog when the debugged cog stays in the little kernel. This is the case at begin and when a breakpoint is reached.
Breakpoints are made by replacing the instruction at this position with a jumpret to the kernel (to Addr 0). The Window App holds a copy of the cog code and can restore the break locations if you delete a breakpoint.
Single steps are done by reading the instruction to a location in the kernel and execute it there (something like LMM inside the cog). Single stepping of jumps need another technic otherwise the return address would not be correct, so they are made by setting two breakpoints: one after the jump and one at the address to jump to. After the jump is executed the two locations are restored.
Waitcnt is replaced by a NOP in single step mode, because the timing relation to CNT is anyway lost at every break. If you want debug waitcnts you need to set a breakpoint after it and let run the code until there.

There are other debugger solutions by Cluso99 and jazzed which need fewer or zero longs inside the debugged Cog for the kernel. I think they also provide the source code. If you want to do your own debugger I think the best approach would be to make a comfortable GUI to jazzed's debugger.

Andy

JasonDorie · 2011-03-14 00:48

Thanks for the description Andy - that sounds a lot like how I was thinking of doing it. Basically a small driver to cache & restore instructions and talk to a comm cog. I may try to do something like it still. If you're not uncomfortable sharing code I could probably port your UI to C# pretty quickly.

I'm going to have to look into BST and some of the other offerings here. I had no idea there were debuggers. For Spin it's usually not an issue for me because it's easy to insert debug output, but for PASM it's very useful.

Ariba · 2011-03-14 02:50

If you dont expect any support from me, I will send you the sources by PM.
But I fear it is not easy to translate to C#.

And as I said, today I would do it quite different. An LMM loop for the interface to the cog (perhaps without the need of a second cog) and instead of pick the source from the IDE and parse it, I would take the listing of BST or Homespun.

Andy

JasonDorie · 2011-03-14 10:50

The problem I see with the LMM approach is that you can't support full-speed execution any more. I'd say if you're going to go to that much trouble, you'd almost be better off performing full emulation on the PC and just transmitting pin and hub ops back & forth. To the end user it wouldn't appear to be much different. LMM would run faster, but the emulation approach would let you see the carry & zero flags. Random thinking - that was another approach I had in mind. Basically a single cog version of Gear that talks to the prop so you can test with real hardware.

If you're willing to send code that'd be great. I don't expect any support. Send it to mail @ (my username) .com. I've never seen PureBasic so it's completely possible I'm getting in over my head, but I'd like to take a look.

jazzed · 2011-03-14 11:13

JasonDorie wrote: »

The problem I see with the LMM approach is that you can't support full-speed execution any more.

What do you mean exactly? As long as you're running something in the cog (throttling one instruction at a time or otherwise), you have access to everything including setting breakpoints (a temporary jump to some handler routine). Full emulation in the PC (and poke/peek Propeller) would make for a much smaller footprint.

JasonDorie · 2011-03-14 12:51

jazzed wrote: »

What do you mean exactly?

I just meant that the code being LMM'd in would not run "full speed" (as in native), so you might still have issues with waitcnt for timing critical stuff. Andy's version still supports full speed native execution until you hit a breakpoint. I doubt it matters much though - anyone halting their code has to expect that timing is going to be compromised anyway.

The full emulation model is interesting to me because it would be totally non-intrusive to the code being "run" - you'd simply replace the code in the cog with your debug kernel and then run the original code on the host PC. I don't see a typical PC having any trouble emulating a cog in something close to real time. The biggest slowdown would be turnaround time for fetching pin, hub, or special register values because it's synchronous. Straight writes wouldn't be as bad because you could send them async.

jazzed · 2011-03-14 13:37

Run full speed to breakpoint is a minimum debugger requirement. I guess LMM runtime speed is useful as Catalina C's runtime though.

LMM, Spin, or PC commands can be used to setup the breaks though. Cluso99's debugger uses LMM in the shadow registers for the handler stub. All my debugger code (some of which comes from Cluso99) is in spin except the stub.

I like being able to produce a full instruction trace to a console as well as full speed operation, but as you suggest waitcnt is troublesome with anything but full speed.

You should look at Dave Hein's spinsim. It fully emulates PASM in a C program and could be easily adapted to your purpose.

JasonDorie · 2011-03-14 14:06

Regarding SpinSim, I'm going to have to have a look at that. I've been getting back into Prop coding lately, and I really miss having a debugger. I know there are those who'll claim it's a crutch for bad coding practices, but I'm unfamiliar with a lot of stuff on the electronics side, and sometimes just a sanity check is nice (am I actually doing what I think I am?).

I'm going to have to take a second look at the debuggers and other prop tools around. I haven't looked at BST, Homespun, Catalina, or much else besides the PropTool for a very long time. I'm probably really out of touch with what's available. I did try Viewport at one point, but was a little disappointed with how much setup was needed (no insult intended to Hanno, either - it looks like a cool tool, it just wasn't what I was looking for at the time, and it was quite a while ago).

I liked Andy's approach because it required nearly no code changes, I didn't have to register my variables, etc, etc. The idea of a purely PC sim debugger is appealing for similar reasons - no real code changes required.

Ariba · 2011-03-14 20:57

Jason
The idea is to only replace the function of the second cog (the PASDebug) with LMM. The code that you want to debug runs still in full speed.
The LMM code needs to implement a serial receive and transmit routine and must detect and execute some commands. One of theme is:
Run the user code until a breakpoint is reached. The break jumpret then jumps back into the LMM loop and the communication with the PC is done there.

init   'pc = lmmBegin
break  'store c,z to a register
lmm    rdlong instr,pc
       add    pc,#4
instr  nop            'execute lmm code
       jmp    #lmm

' begin of user code to debug in cog
  ...
  ...
  jmpret retaddr,break  'breakpoint
  ...


' LMM break handler code
lmmBegin
  'serial communication to PC App
  'commands for:
  ' - breakpoints set and restore
  ' - continue
  ' - read cog memory
  ' - read Main Memory
  ' - execute single instructions
  ' - ...

Andy

P.S. Will send you the Basic sources to your Email address

JasonDorie · 2011-03-15 14:46

Andy - I've received the code and had a quick look at it. It doesn't look that complicated, and I started programming in Pascal, so it looks oddly familiar too.

Thanks!

Kudos to PASD

Comments