Debug Command Protocol

[ncoplin]

Hi,

This was asked in #3178, but seems not to have been answered at the time.

I've been able to "see" the data using 4800,N,8,1 @ 4MHz and a terminal, but I cannot find the format that the data is streamed in.

Is this format available to assist in the development of an alternate debug tool (yep, I know the method is sloe, but I find it really helpful!)

Many thanks,
Nick

 

[SAborn]

Not sure on your actual question, but have you actually tried using "DEBUG' as it works a treat for me, look it up in manual 2.

 

[ncoplin]

Hi,

Yes I use DEBUG from the P.E quite successfully, but I'm looking to understand the actual protocol for the stream of data coming on the link.

The reason is that am writing an app which will include a debugger and I would like the DEBUG command to send information to it when connected. Hence I need to know the format of the data stream to interpret the information. I would like to use DEBUG and get the full dump, rather than requiring a specialised serial out routine for every variable in memory. The command line compilers send the program, I need to write something that receives the DEBUG response. Does that clarify the detail I am seeking?

Cheers,
Nick

 

[inglewoodpete]

I wrote a logger of debug data that wrote the data to a csv file for import into Excel a few years ago. You will need to specify which PICAXE you are using. The speed differs between models.

I queried this about 3 1/2 years ago here

 

[Technical]

The debug protocols vary between PICAXE chips, so it would be a question of writing a debug processor for each chip type.

Which is why we generally recommend using sertxd in this type of situation instead, as you can specify what data is output and in which format, and so it is then much easier for your software to interpret it e.g.

sertxd (b0,b1,b2,b3)

 

[ncoplin]

Hi,

My focus is the 20pin chips, the 20M, 20M2 and 20X2. I anticipated that there may be a difference between chips for the reason of what functionality is supported (eg number of named variables, system variables, etc). Supporting different protocols for different chips is not a problem, and the app already supports selection of the compiler specific to the chip type. The use of DEBUG is neat in that the output is chip dependent, not user dependent (ie with SERTXD a user can change what is sent and thereby screwup the "diagnostic tool").

If the data is in logical and consistent stream, I guess I'll just have to snoop and reverse engineer if the info is not available.

Nick

PS: InglewoodPete, data logging of the DEBUG output is one of the uses I had in mind, but looks like your work is on different chips.