Those are some really good hints on how to instrument code.
A good reason to find a processor with a few more pins than the Nano.
Doesn't really need to be timer based,? can just set pins high when doing?
the various jobs, perhaps include a pin for when it's idle. This is far better than trying
to print stuff to a serial monitor or a display, as writing to a pin is pretty much instantaneous.
One of those $20 DSO138's would be adequate as a scope for this sort of thing.
Driving LED's from those pins would sort of work, but not nearly as informative as a scope.
Checking the stack like that is a very good idea, it can be really hard to debug when the
stack fills up to where it starts stepping on your global variables.? All it takes is one array
invoked as a dynamic variable, or a poorly written library function.? Could set hundreds of bytes
to the magic 0x55 value and count them each loop if you wish, so long as you have time to .
do the counting.
Jerry, KE7ER
toggle quoted message
Show quoted text
On Sun, May 16, 2021 at 06:15 PM, jerry@... wrote:
On 2021-05-16 16:15, Evan Hand wrote:
All,
While I agree that there is enough sample time for the ADC, I have not
seen any analysis on the polling time of the main loop of the program.
I once worked on an embedded project with the following architecture, which is more or less what I use when starting a project from scratch:
1. A main loop. Each run through the loop takes a defined time ( we used 50ms, or 20 times a second ).
2. A timer interrupt. On that project, it happened every 2 ms. It bumped a counter on every invocation.
3. The main loop would time out its 50ms by counting the counter done by the 2ms interrupt.
4. When the main loop finished whatever useful things it was doing, it would set a pin high and wait till the timer count was 50ms. Then it would set the pin low, and go back to the beginning of the loop.
5. We would stick an oscilloscope on that pin, and it would tell us if the CPU was too busy. As the CPU loaded up, the pulse would get
shorter and shorter, because the CPU was spending less time just waiting at the end of the 50ms loop.
This was done by an Intel 8031 running at 9MHz, with VERY limited resources.
At the top of the main loop, the stack pointer was always at the same number. If it wasn't, we knew something was badly wrong, and the processor would log the occurrence and reset.
We also set the top 3 bytes of the stack to 0x55. If it wasn't 0x55 anymore, we knew we were close to blowing the stack.
- Jerry KF6VB
