[eschneider]

Lots of (most?) real-time and embedded code run in a state where suspending/resuming really doesn't work in any useful fashion, so it's logging, and minimal logging at that to figure out what's going wrong in-situ.

That said, much benefit is gained by writing the complicated bits in such a way that they can be tested/debugged/examined independently on a host system.

[nuancebydefault]

Hmmm I have 20+ years of embedded sw programming experience and can tell you the reason that embedded software is oftentimes not easily debugged using a debugger, is the crappyness of the debugger solution (debug probe, its firmware and its eco system). Also, high end embedded ICs often contain a serious amount if silicon bugs. The fact that it needs to run real-time, is mostly not in the way of the debugging process. In other words, embedded processors and their eco systems tend to be sub-par in terms of developer friendlyness. Addendum SHARC ADSP anomaly list https://www.analog.com/media/en/dsp-documentation/integrated...

[realo]

I'm with you there!

Be happy if you can flash a led... happier if you have two speeds... and Nirvana if it is a multi-color led.

Intense jealousy of your colleagues who have TWO leds on their boards!