All problems disappear with enough speed. Eventually the main loop is fast enough that you can poll.
If you're doing something truly cutting edge your competitors aren't better than you are so you can afford that second uC and more parts.
Most of engineering judgment is finding the point where the goal is ambitious enough to keep up with or pass the competition while conservative enough that it'll likely work, or at least you won't get sued.
Re:Fearless concurrency in your microcontroller
by pdelbarba on Tuesday May 09, 2017 @04:39PM
(#14303615)
In abstract this is true, but in real life, you get presented with a microcontroller and are told to make X happen in Y time. The current trend is where microcontrollers are becoming fast enough to essentially be bare-bones computers. Maybe they're so fast that you can poll a dozen sensors fast enough to respond to an event, but now clients want you need to drive a graphic display with all the system performance stats in real time and stream cat videos via UDP to it whenever the user gets bored.
Being able to squeeze the full potential out of these devices is getting harder and harder with current methods. Safe concurrency and memory management can allow developers to fully utilize their hardware without needing a grey beard to write some unreadable assembly that you later find out was just a plagiarized version of the Windows ME memory manager.
Re:Fearless concurrency in your microcontroller
by kevin_thibedeau on Tuesday May 09, 2017 @07:58PM
(#14304890)
You can't just thrown in more, beefier hardware with hard power and volume constraints.
Edit: and the real reason you don't want to do this is because the EEs and manufacturing engineers on your project will try to kill you. Two uCs means two codebases and two devices to program during production, plus extra testing, more complicated design, and more parts to place (uC, crystal, caps, etc)