Opinions on lack of debugging tools?

Martin Hebel

I'm curious about something. There's some pretty strong coverage here by embedded developers with strong backgrounds on this board. How much of a hinderance has a lack of simulation/emulation tools been in your development with the propeller? Does the simplicity of the Propeller reduce the need for high level debugging tools? Or is it more a case of simply getting by since none exist? I tend to feel the lack of internal hardware greatly simplifies the programming task. It was easier for me to write a serial routine than pouring through pages of reference material in how to configure a typical controller and scratch my head when things didn't work right. And the ability to generate signals in one Cog to test another is really great!

Thanks in advance for your feedback,
Martin

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Martin Hebel
Personal Links with plenty of BASIC Stamp info
StampPlot - Graphical Data Acquisition and Control
AppBee - XBee ZigBee / IEEE 802.15.4 Adapters & Devices

Mike Green

I've had a lot of luck using both the VGA display and TV display at the same time with one containing normal program output and the other with just debugging information. I've also used just a VGA hires text driver with some simple assembly routines to format debug data and write directly into the VGA screen buffer. The simplicity of the COGs also helps.

I have used one cog as an minimal emulator for a Stamp coprocessor (that was not available) with its own separate display.

Most of the debugging problems that I have had (and continue to have) that are not amenable to debugging with the Propeller itself have involved subtle timing problems that probably need a combination of external logic analyzer and oscilloscope to isolate and examine properly.

Phil Pilgrim (PhiPi)

I agree with Mike. I haven't felt the need for much more than a TV display or terminal program for data-centric debugging or a spare pin and a 'scope for timing stuff. But I started out in this business on a shoestring, so never grew accustomed to emulators and other fancy debugging tools. (The SX-Key, when it came along, nearly spoiled me!)

-Phil

Bill Henning

I remember reading a thread that someone is working on an emulator, for testing code, with cycle accurate waveform generation for all the pins. I'd love to get that.

I expect to use the TV output for initial debugging; later maybe a two wire (I2C) LCD - however the limited size of the code that can run in a cog helps keep bugs to a minimum.

Other than that, I am eager to start experimenting with my propellers.. they should arrive tomorrow [noparse]:)[/noparse]

Dennis Ferron

After the madness that I had to endure to program an Atmel in C, there hardly seems to be any difficulty at all to programming the Propeller - it "just works". This never ceases to amaze me.

simonl

When playing with PICs I've used an emulator, but only for checking simple stuff (I only have a freebie emulator with fixed 'hardware'). It would be nice to see the likes of ISIS VSM for the PChip -- my electronics and soldering skills leave a lot to be desired -- so I could simulate my project before commiting it to hardware though

That said, I also used to use an LCD, but now that I can send my debug data to a TV... oh biy, I ain't ever goin' back Now, if only the TV would do more than 40char's wide (or I could get hold of a decent FP VGA monitor...)

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,

Simon

Ym2413a

I just use some extra pins and o-scope those for debuging reasons.
Code too fast? Add some wait statements and watch some LED's toggle on and off.
Wondering how fast your loop runs in ASM? Toggle a PIN from Hi to Low every time your code cylces.

I never used emulators for coding anything before so I can't really miss them.
When I emulate my code, I run it through my head with the datasheet infront of me.

Guess I'm just low-tech or very retro.

David B

I have the sort of philosophical approach that if my code is so confusing that I can't understand why a certain variable has some value at some time, then either my code needs simplifying, or I need to study it harder, or both. So I generally tend to not bother with external debuggers.

I use an on-board seven-segment LED for low-level IO debugging, and a serial LCD for higher level, and haven't felt the need for any more than those.

But on the other hand, even though I'd never used the sx debugger, when SxSim came along I found uses for it that I'd never imagined. If somebody makes a Propeller simulator, it could well have the same effect.

David