4 ms·
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 log
by eschneider 4y ago
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.
- realo 4y agoI'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!
- nuancebydefault 4y agoHmmm 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-circuit-anomalies/adsp-21467_21469-sharc-anomaly.pdf https://www.analog.com/media/en/dsp-documentation/integrated...