10 ms·
I'll try to empathize with the original author by providing an example "from real life" or from my life anyway LOL. Blog posts are too small to provide a lot o
by VLM 5y ago
I'll try to empathize with the original author by providing an example "from real life" or from my life anyway LOL.
Blog posts are too small to provide a lot of information. So in 2021 if you're programming a STM32 you're probably doing something complicated so if its license compatible blah blah etc you're probably/possibly pulling in the whole MBED OS along with include rtos.h and doing everything in separate threads etc.
Which is good for real world projects that are complex enough to benefit from a full featured RTOS.
But its cargo culting if you're literally blinking a LED for a kids toy or similar level of complexity.
The world is full of microcontrollers that do little more than act as timers or do protocol conversion. If you implement a car transmission microcontroller that needs to convert a quadrature motion input to a single canbus thing, if you do it as a raspi with full Debian linux including GUI and 5 layers of middlewear you have seemingly infinite security surface and reliability surface and will never be able to prove its unhackable or even reliable. But if you do a quadrature encoder and canbus interface in, I donno, 50 or so lines of commented C that handle various error conditions and sensor failure conditions, its going to be very easy to prove it works reliably and very difficult if not impossible to hack as one of the 375 microprocessors supposedly installed in every new car. On the other hand the GUI and 5 layers of middlewear might unfortunately be the best way to implement the stereotypically hypercomplicated GUI that new car buyers have come to expect/dread.