Debug mode questions

[chino]

It appears that DEBUG_ENABLE still runs in many places even when DEBUG is not set?

It would be cool if the debug serial commands supported running a capture and what not for testing (especially because of the reset-on-serial-connection behavior).

[gillham]

I intentionally left the DEBUG_ENABLE / DEBUG_ON / DEBUG_OFF statements inline so as not to affect the timing of the loops. I had intended to redefine them as the equivalent number of NOPs when DEBUG is not set, but haven't gotten around to it. It is relatively simple, just a matter of double-checking the number of cycles for each of those and adding the #ifdef logic. Expanding the debug commands to simulate a capture is a good suggestion. I initially added those for my internal use and didn't want to add do much "UI" to it, but based on the occasional issues people have, I think adding a simple capture command at a predefined rate is probably useful.

Do you think adding a few commands with different rates would useful? I really don't want to build a UI to select the rate. I think just some predefined samples would be good.

[chino]

I actually ended up doing echo -e "\x01" and then pasting that into the box to generate a capture so I could print the values out with 2.

I mean if you supported text names for all the binary commands that are sent in then that's a great way to test..

Probably makes sense too to support picking different rates as you suggested.

Might be cool to even support a continuous streaming mode where it just echo's ascii art bar on each line or even allowing me to point an xterm at it for an ncurses interface :]

[gillham]

Most of the output is 8bit binary so not particularly useful from the serial console, but initiating a capture so it can be printed via the debug options is useful and I will look into adding something like that.

[gillham]

I did some checking and the DEBUG_ENABLE / DEBUG_ON / DEBUG_OFF statements use 82 bytes of flash, so I don't it is that critical to remove them.

I did add a few more commands you can do via the Serial Monitor. Send a '?' to see the list, but effectively you can capture at 4MHz/1MHz/500KHz and dumb the buffer. I also added an experimental feature to print the first part of the buffer in a textual representation of the signals. It runs vertically but if you use the sample signal generator at the bottom of the setup() function you can clearly see the signal in the output. Let me know if there is anything else on this particular issue, but I believe it is resolved for now.

[chino]

Cool!