Building up your PASM test / debug environment.

potatohead · 2010-09-03 21:35

So, what do you do?

I'm curious about the different approaches.

Mine is to knock up some code that outputs things I want to see. My preference on the Prop is to use a cog for video, then dump things to the screen.

Some handy goodies are, print hex, print decimal, print binary.

Also a memory scan is good, like writing a section of the HUB memory to the screen quickly. Can see stuff change.

A routine to pause until button pressed on pin.

Blink the light.

With video, it's all about the base signal, which requires a lot of thought, or time and a scope. Once that's done, then writing things inside the signal loop can be done with the other methods, or can be done in a way that leaves output to be seen.

So, how do you boot-strap your PASM working environment?

Phil Pilgrim (PhiPi) · 2010-09-03 21:43

Oscillosope mostly. Sometimes tv_text or tv_wtext. The best strategy is to get things working small bits at a time before moving to each new stage of the development. That way, each new problem is easier to isolate and debug. People who enter and test entire programs at once are either natural-born geniuses or just asking for weeks of head-scratching. And, BTW, debuggers and emulators are for weenies!

-Phil

RinksCustoms · 2010-09-03 21:57

Phil Pilgrim (PhiPi) wrote: »

Oscillosope mostly... ..BTW, debuggers and emulators are for weenies!

-Phil

LOL

.. ROFL:rofl:

bill190 · 2010-09-03 22:20

I use one cog to test the output of another cog! (And a Basic Stamp running on another PC and a regular old frequency counter.)

I'm working on some IR stuff. Initially I created a 38 kHz carrier on one cog and can test that with the Basic Stamp or frequency counter.

Then I send data with PASM switching on/off the 38 kHz on another cog and output via an IR transmitter LED.

Then use yet another cog to read the data with an IR receiver, then that sends the test data to serial terminal.

So on my breadboard I have an IR transmitter pointing at an IR receiver and both connected to the same Propeller.

Other times I use a regular LED or multiple LED's to test a certain part of a program. I can then see what is happening.

Or if I want to know the value of a variable (troubleshooting), I'll output that to serial terminal.

And I have a multimeter handy for testing this and that. And a scope.

HollyMinkowski · 2010-09-03 22:55

I print data to the screen mostly.
Also leds make good indicators.
And of course an oscilloscope is always
a useful tool.
I suppose ViewPort would be useful
but I have not worked with it much.
I do wish I had a copy though, it
would be nice to detail its usage
on my PASM blog. Maybe I will get
a copy of it in its most basic Lite form.

jazzed · 2010-09-03 23:22

I use a PASM debugger to validate my assumptions and it is best used while building things from the beginning rather than trying to fix something near the end. My old analog o-scope also provides value for timing analysis and in that role it is priceless. When I have lots of signals to look at, I use a logic analyzer like Propalyzer. I rarely use mailboxes to look at values on TV/VGA because the instrumentation code usually gets in the way. I almost always use print statements in Spin and that usually leaves a mess ... so sad. LEDs are my absolute last resort.

I once found a thread where Phil complained about not having a debugger

Phil Pilgrim (PhiPi) · 2010-09-03 23:57

jazzed wrote: »

I once found a thread where Phil complained about not having a debugger

Mah good suh [removes glove; slap, slap], ah take great umbrage at such a scurrilous inculpation! You have impugned mah honah as a gentleman programmah! [rifles through credenza] Now weah did ah store those dueling pistols?

-Col. Philip C. Pilgrim, Esq., D.D., 3rd Propellah Regiment

Ale · 2010-09-04 06:03

I eat my own dog food and use my own emulator. Then I use either a serial terminal with a simple "poke" debugger or the screen (sometimes both). The scope or LA are a constant companion

wjsteele · 2010-09-04 06:21

So let me get this straight? What you guys are saying is that the code you wright sometimes doesn't work right away?

Interesting! I've not run into that situation yet.

Bill

Phil Pilgrim (PhiPi) · 2010-09-04 08:55

wjsteele wrote: »

What you guys are saying is that the code you right sometimes doesn't work right away?

On occasion I do have to right the code I write. But once I right it, it works right away, else I really couldn't call it righted. Right?

-Phil

Ravenkallen · 2010-09-04 09:17

I use LEDs for testing everything first. Just a simple on and off indication could be enough info to know your program is working, plus they are cheap and plentiful...

pjv · 2010-09-04 10:00

Hi All;

I'm fortunate to have a Tektronix MSO scope, and have to 16 logic channels connected to output port bits 15..0. The 4 analog channels mostly get used for other signals. So far all my work is in assembler (don't understand SPIN yet), so when testing my code, I usually want to know the value of variables at various points, and so I simply insert the following snippet at those places:

mov Hold,outa 'keep the present port value
mov outa,VarableName 'show the lower 16 bits of the variable
mov outa,Hold 'restore the original port state

and carry on. It does require of course that those port bits be in the output direction at the time of the peek, and if they are not, then the DIRA also needs to be saved, altered and restored.

Works great, because it is all in real time.

Cheers,

Peter (pjv)

Brian Riley · 2010-09-04 10:36

Ravenkallen wrote: »

I use LEDs for testing everything first. Just a simple on and off indication could be enough info to know your program is working, plus they are cheap and plentiful...

I pretty much do the same, but I use a 'special' LED that has the series resistor (330 ohm) built in so they can be quickly deployed without having also handle a resistor.

FWIW, Here are the Mouser p/n's

for the Green LED

SSL-LX5093GD-12V

and for the Red LED

SSL-LX5093ID-5V

the green has a bit larger series resistor and they are each nominally rated at 5V and 12V ... BUT they work fine at 3.3v Propeller voltages.

CAVEAT ... I find myself unable to visually distinguish one of these LEDs from its non-resistored brethren, I often suggest to people that if they will be mixed to dab a little Wite-Out on the base

One more comment, I have adopted a convention in both my personal work and all the kits I sell, that Green LEDs are for power (yellow for raw Vin) and Red LEDs for digital indicators.

cheers ... BBR

RinksCustoms · 2010-09-04 10:57

i recently picked up a relatively inexpensive 2ch USB scope +16 ch LSA (or 8ch LSA/8ch Logic generator). Its been very helpful in determining that iv'e ben wasting my time with this stupid TMP100 SOT23-6 I2C temp sensor, the prop -even when i wrote an I2C driver from scratch- spit out signalling with great accuracy & granularity.
Other than that, i use a 4" or 7" widescreen lcd's for automotive headrests i got on the cheap and spit out variable data with TV Terminal object , or use PST.

potatohead · 2010-09-04 11:13

What's a "poke" debugger Ale?

Beau Schwabe · 2010-09-04 19:21

Does self shock therapy count as a debug method? :smilewinkgrin: ... even if it's unplanned or involuntary? -- joking

For the most part I start out debugging with what seems to be the most practical for the task, starting out low level and working my way up the chain as the project matures.

LED - visual debugging

Speaker - audio debugging

scope - debugging for what we can't see or hear

Serial - debugging for when the bits have something to say

TV - when you just want to bring it all together

Edit: hey I'm HEX inverted (this was my 4049th) post

Leon · 2010-09-05 01:56

Any chance of JTAG or something like that with the Propeller II, Beau?

Cluso99 · 2010-09-05 04:13

Depends on the code. I use Leds if it is simple for a pass/fail type approach. I like to use superbright leds and use 10K with them - stick them in the mouse holes!

Anything more complex where I need to see the results I send characters or strings out the serial port to the pc.

I rarely use a scope - it mostly sits in its original carton. Unless of course I am doing something analog, which I suspect is where Phil is coming from.

I did have to write a debugger for the Interpreter to see that everything was OK and I did write a datalogger to check the pins and send to the pc.

As Phil said, you should test your code in pieces.

Quote from somewhere old... "The person who never had a bug in their code has never written anything."

Beau: 4049 hex inverter - isn't that a backwards step - you already achieved a 4004 microprocessor (well, it was just a smart programmable calculator). You can of course look forward to the 6502 or 6800. LOL

Ron Czapala · 2010-09-05 09:20

Holly,
When you say "I print data to the screen mostly" are you referring to the PC monitor using the Parallax Serial Terminal?

Do you have any sample code you could share?

I am wondering how to display variables from within PASM code (other than writing values back to main memory where another cog could display it)

Thanks,
Ron

Heater. · 2010-09-05 10:51

Ron,

I am wondering how to display variables from within PASM code

In desperation when I started out I had 8 LEDS on my Prop and would dump variables byte at a time to those with a little delay between each byte so you have time to read it. Not recommended.

Also I have used just one LED to light up if a PASM variable achieves a value I think it should have. Also not recommended.

By far the simplest is dumping values to some high location in HUB, far away from your code, and have another Spin object dump it to TV/VGA or serial. Perhaps that is added to some existing process that is looping continually.

Leon · 2010-09-05 10:54

There is some code for doing that, which I've used, with various ways of displaying the data - hex, ASCII, etc.

Ron Czapala · 2010-09-05 11:10

Leon,
Where is this code of which you speak?

Leon · 2010-09-05 12:01

I think I found it in the Obex.

potatohead · 2010-09-05 18:30

Well, the AiGeneric text driver, and PotatoText both operate with a standard one byte per character screen memory.

You can write stuff right to the screen.

Eric Ball has a hex font in his one pin TV driver. This can be used to directly read the memory. Recommended.

Just either write to where the screen is, or point the screen memory to a region of the HUB you want to view.

ratronic · 2010-09-05 21:56

For me it depends what i am trying to track down. I use a led or DSO or write a variable to the screen. This is the way I write to the screen. But I also do this using rs232 or tv. This routine simply increments a # on the display

Con                                                                                                 
  _clkmode = xtal1 + pll16x                                                                         
  _xinfreq = 5_000_000                                                                              
                                                                                                    
Var                                                                                                 
  long a                                                                                            
Obj                                                                                                 
  vga : "vga_text"                                                                                  
                                                                                                    
Pub main                                                                                            
  vga.start(16)                                                                                     
  cognew(@entry,@a)                                                                                 
  waitcnt(10000000+cnt)                                                                             
  repeat                                                                                            
    vga.out(1)                                                                                      
    vga.dec(a)                                                                                      
    vga.str(string("   "))                                                                          
                                                                                                    
Dat                                                                                                 
              org                                                                                   
entry         or        dira,led  'set up debug led                                                 
              mov       t1,par    'save par to t1                                                   
                                                                                                    
loop          'your pasm code                                                                       
              mov       variable,tst  'then mov the cog variable you want to see into 'variable'    
              wrlong    variable,t1   'display the variable in spin routine above                   
              or        outa,led      'insert this to trigger led in your code                      
              add       tst,#1        'increment variable                                           
              jmp       #loop                                                                       
                                                                                                    
tst      long  0        'variable                                                                   
variable long  0        'variable                                                                   
led      long  1 << 5   'replace '5' with i/o pin led is hooked to                                  
t1       res   1        'temp var to store par

Building up your PASM test / debug environment.

Comments