DEBUG commands defined in DAT strings

Francis Bauer

A question came up in the March 16th P2 discussion as to whether or not you could store DEBUG statements in DAT strings rather than hard-coded statements. Turns out the answer is Yes, but I've found some limitations with this method using both PNut_v35j and PropTool 2.5.3

I've attached an example Spin2 program using DEBUG SCOPE commands that I used for these experiments. I've documented in the Spin2 file the exceptions I've found when using DAT strings to hold the DEBUG statements/definitions. The following screenshot shows that there are a few DEBUG commands that don't expand correctly. See the softScope debug text output example in the image below, it shows the un-expanded commands:

jonnymac also recently submitted another example of using DAT strings to hold DEBUG PLOT statements/definitions.

cgracey

Yeah, it only works for literal strings. You'd have to do your own variable-to-number-string conversions.

MagIO2

As the question came from me, I feel free to use this thread. Just let me know if you have other plans for the thread. (Especialy because I also would like to see some trouble to get shooted in the stuff I attached).

So, the idea was to have a general purpose object, which can easily be reused in different projects. The code I attached only shows a draft, which kind of works and gives a rough picture of what I am thinking of.
In my first try I simply used debug( @buffer ) because I had a demo running which enclosed the debug-string in some double quotes and the double quote thing ran, the @buffer thing of course did not.
So, the missing link I've learned about yesterday was the ZSTR_ with the underscore. Sometimes things are burried so deep inside of the documents ;o) and those heads-ups are needed.

Of course the inline PASM which reads the samples needs to become much more clever to be worth a generalization.

What does not work at the end of this day is, that the sample() produces more than one sample. The main program actually loops over 52 different values and waits a while between each byte. The sample throws a lot of debug output, but it always seems to be the same no matter what I try. And I would even expect it to wait until next trigger occurs.

The demo code currently uses Pins 8 to 11 as output, so change it if that conflicts with some hardware you attached there.

Open questions:
Why? does it only work once
Is the way of reading INA valid in case that Smart-Pins are used by the main program? Is INA a register that is available in each COG and can it be used for nomal pin state reading in one COG, whereas it is the Smart-Pin-Flag with a different meaning in another COG?