Re: QMX+ V2 - I've killed it
|
One failure mode that I have not seen discussed is if the MPU freezes.? How do you ensure the loop is executed every 1 ms, and can you detect if it does not?? This is a tradeoff in using only one MPU for the radio—cost savings with a tradeoff of possible failure modes.? Maybe a failsafe heartbeat can shut down the input.? You can still have the controller stuck in a state where the interrupt will not trigger the failsafe.
Practically speaking the MPU doesn't normally "freeze". If the programmer made some mistake and didn't cover some unforeseen situation, the code goes off into its own infinite loop someplace waiting for something to happen which never does, for example. The thing *looks* like it froze because it's unresponsive to controls etc. and looks frozen. But really it's still doing it's interrupts and related stuff.?
It happens to me all the time because when I'm programming I make a lot of mistakes and "freeze" the MPU. But it doesn't kill the SMPS because the interrupts are still running fine. Or, sometimes the "freeze" causes the MPU to do some illegal activity and reboot. Which then starts off the SMPS from scratch anyway.?
I've never encountered a situation where a MPU really freezes: neither reboots nor continues with it's interrupt operations. It's a matter of firmware design to make sure that the SMPS loop runs in a high priority interrupt and no other interrupts at that or higher priority do anything significant that could get stuck waiting for anything or suffering memory overruns etc.?
Which reminds me of another point: I intentionally don't use C malloc/free in any QRP Labs projects. I have (so far) always found ways to avoid it. This removes a major unpredictability of the firmware system. Apparently unlike for example my ISP's internet modem which I have to reboot every couple of days otherwise it gets painfully slow. One of few benefits of frequent power outages: takes care of slow internet modems by rebooting them!
73 Hans G0UPL
|
