sis there a possability for singlestep debugging

StefanL38

hello to every propeller(pilot)

im really really new to the propeller. Knowing not very much

reading about start and stop cogs

is there a possability to create a special debugmode
by using one cog as something like a "debugmaster"
switching on and off other cogs after each commandline?

or would i have to write additional code that makes the handshaking for this

sending bytes to a PC-terminal or creating a TV-Picture helps a lot.
But there are some problems that could be solved much quicker with a singlestep
mode

If you have a fast runnig main-cycle with a cycletime with less than - let's say 10 seconds
you don't have time to react fast enough by watching a TV-Screen switching the state of an IO-PIN
for testing what's happening if the state is alternated


One example:

a program running a main-cycle waiting for commands making the
program do different things

The real switch-state of a digital sensor ist "OFF".
Inside the software the switchstate is represented by a boolean variable
updated by a own routine (process-image)

When the software is running normally the switchstate "OFF" would raise an errormessage

For debugging purposes i would like to change the switch-state of the variable to "ON"
making the program going on the normal way (and not raising an errormessage)

now it would be very helpful to have something like a singlestep mode.


Within one main-cycle the process-image has finished updating and has set the switchstate to "OFF"
i stop execution after process-image-updating changing the switchstae to "ON"
and then go on with execution step by step analysing what the program is doing
in the rest of this main-cycle

Of course i could make the program stop by a hardwareswitch and a little bit of additional code in this case

But a singlestep mode allows to stop EVERYWHERE changing ANY variable to ANY value
and then go on with the next commandline without adding (and remove after debugging) additional code

So one solution about this could be a simulater running on a PC
One mode simulating everything

Another mode using a 40-DIP-connector and hardware to get the voltagelevels of every PIN of the PCB
where normally the propeller is plugged in using the voltagelevel-info to change the state of IO-PINs

Does anybody have different ideas about quickly solving problems like this?

Maybe the complete different architecture of the propeller offers new possabilities

best regards

Stefan


what are the three mortal enemies to a hardcore programmer?
fresh air
daylight
and this deafening noise of the birds

(just kidding)

Mike Green

There is no single step mode or anyway to implement it with the Propeller architecture in hardware. The cogs can only be stopped and, when they're restarted, they are completely reinitialized. With multiple cogs, it's really easy to do debugging using one cog as a video display and another for a PS/2 keyboard. The cog you're debugging can easily write directly to the video display buffer and read the keyboard buffer. I'm sure you could write a small debugging routine that ran with the program being debugged in one cog and a debug command interpreter that ran in another cog. The small debugging routine could handle the breakpoints and single step stuff and pass data through main (HUB) memory to the debugger which would do the display and command interpretation. The instruction set is not complicated from a debugger's standpoint except for the WAITxx instructions and other time-dependent coding. There's very little "state" that would have to be saved (mostly the carry and zero flags) to do software single stepping and that's easy to handle.

Post Edited (Mike Green) : 9/1/2006 2:49:07 PM GMT

BiblioTech

Off the top of my head here with little practical knowledge, could you use a second Prop as a clock source for the one you want to debug. If so how slow can a Prop under test·be clocked·reliably?

Assume the "D-bugProp" uses keyboard and display objects with general or specific debug objects. The Prop being debugged looses·8 I/O pins and 1 cog. The I/O pins each repesent 1 cog and while in one state the cog waits in the other it dosn't. The "debug cog" could be used to·log the I/O pins state(dir and value)·at each full hub cycle for transmission to and display by the D-bugProp when asked.·If all other cogs were waiting·the debug cog would·pass all register states and parts or all of the main(hub) ram as well as the buffered I/O log to the D-bugProp for display and evaluation.

Also can a Prop function reliably if the external clock signal is "erratic".

While I've been typing this many problems have poked at me for attention but I don't know enough to answer my own doubts but i"m willing to learn.

·· Frans...

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Read a book, under a lamp and think what it took to get here.

CJ

I read somewhere on the forums here that that prop is a static memory device and can be clocked at any speed up to its max

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Who says you have to have knowledge to use it?

I've killed a fly with my bare mind.