How to debug microcontrollers in the "real world"?

[0db]

I believe some CPUs have had a "trap after instruction" bit in their status flags, in which case you can just set that in wherever interrupts save the status register and then do a return from interrupt to execute one instruction. Sadly, neither the Z80 nor the 6502 have that.

That rings a bell, but I never (knowingly)  came across it.

That's the typical Motorola 68k approach.

[0db]

If I needed to output lots of debug data in (semi) realtime, I wouldn't bother with a serial UART. I'd use something like Segger's RTT.

https://www.segger.com/products/debug-probes/j-link/technology/about-real-time-transfer/

Like when you develop a sensors-fusion algorithm (IMU, for example) and you have fours sensors streaming data and you need to catch what's going wrong realtime.

Sometimes you are just lucky and there is some trick.

Like when I had to develop a seismic sensor, and since it was not practically possible, neither it made sense, to be install sensor on a rock face just to collect data streams, I chose to produce a kind of "synthetic" stream by sampling data on breaking some blocks of cement mortar.

Then I used the "synthetic" stream to test my algorithm. And it also opened doors to the so called "equivalent time" testing.

I was a student, no money for a DSO, LA ... and printfs and puts were just too slow. But not so slow in the "equivalent time" environment.

[tggzzz]

...
Sometimes you are just lucky and there is some trick.

Like when I had to develop a seismic sensor, and since it was not practically possible, neither it made sense, to be install sensor on a rock face just to collect data streams, I chose to produce a kind of "synthetic" stream by sampling data on breaking some blocks of cement mortar.

Then I used the "synthetic" stream to test my algorithm. And it also opened doors to the so called "equivalent time" testing.

I was a student, no money for a DSO, LA ... and printfs and puts were just too slow. But not so slow in the "equivalent time" environment.

Sounds like a good example of the aphorism in my .sig

In a pure electronics environment, that attitude is essential when, for example, developing the world's fastest scope or highest precision DMM.

[brucehoult]

...
Sometimes you are just lucky and there is some trick.

Like when I had to develop a seismic sensor, and since it was not practically possible, neither it made sense, to be install sensor on a rock face just to collect data streams, I chose to produce a kind of "synthetic" stream by sampling data on breaking some blocks of cement mortar.

Then I used the "synthetic" stream to test my algorithm. And it also opened doors to the so called "equivalent time" testing.

I was a student, no money for a DSO, LA ... and printfs and puts were just too slow. But not so slow in the "equivalent time" environment.

Sounds like a good example of the aphorism in my .sig

In a pure electronics environment, that attitude is essential when, for example, developing the world's fastest scope or highest precision DMM.

For those unfamiliar, here is what is meant by "span"



See also



Look ma! No engine!

[tggzzz]

You don't need to understand what "span" is in order to get the gist of the aphorism; "span" could have been replaced with "wirlbleator"

I've been in an ASH25 twice. The first winch launch flight lasted 5 mins; the sky was less than cooperative. The second, 15 mins later, lasted a couple of hours and could have been longer.

My favourite and short video showing span is of an ETA. Watch the wing bend!


Or, more simply,


But this is too far off topic for me to want to continue.