11–20 of 52 posts
Earlier quoted context omitted.
Many of those features are already available in Ada, and to a lesser extent Pascal and Basic. But yeah, more options is even better.
On an ARM Cortex M4?
- Oberon, http://www.astrobe.com/default.htm
- Java, http://www.microej.com/resources/supported-platforms/
- Pascal and Basic, https://www.mikroe.com/stm32/
Nice article. Some good insights, as well as beginner how-to steps. The embedded industry has proven to be very resistant to innovations and modern code-writing practices. Some platforms I coded for didn't even support/allow C99 standard. C++ is gaining some foothold (mbed, for example). Developers don't feel the urge to catch on with times, like in other industries. And yet, now they are expected to write secure IoT…
Is this changing now?
Earlier quoted context omitted.
On an ARM Cortex M4?
Yes, some examples, this list is not exhaustive. - Oberon, http://www.astrobe.com/default.htm - Java, http://www.microej.com/resources/supported-platforms/ - Pascal and Basic, https://www.mikroe.com/stm32/ - Ada, http://blog.adacore.com/tag/STM32
For instance, what will your hypersonic rocket do while garbage collection is running instead of it's real-time control loops?
Nice article. Some good insights, as well as beginner how-to steps. The embedded industry has proven to be very resistant to innovations and modern code-writing practices. Some platforms I coded for didn't even support/allow C99 standard. C++ is gaining some foothold (mbed, for example). Developers don't feel the urge to catch on with times, like in other industries. And yet, now they are expected to write secure IoT…
It was my understanding that C++ was being abandoned in the embedded world in favor of C due to the failure of UML. See for example, the intro of this (possibly outdated) article: http://embeddedgurus.com/state-space/2008/01/object-based-pr... Is this changing now?
But at no time has UML tooling been the driving factor behind the industry's adoption or lack of adoption of a language.
The problem with C++ and other high-level languages has always been that it's hard to see how much a line of code costs. Incrementing a pointer to an array in C has a transparent, short runtime, compared to moving to the next element in a C++ collection which may accidentally invoke a dizzying indecipherable mess of template objects, overloaded operators, and STL dependencies. Or in other languages, you may need a large operating system and runtime to be loaded.
High level languages do handy magic things for you under the hood. If your engine bay is measured in terabytes of storage, gigabytes of RAM, gigaflops of computational power, hundreds of watts of electrical power, and seconds of acceptable interaction time, those magic things that let programmers build useful features faster are nice.
But when you're trying to get guaranteed responses in microseconds from milliwatts of electrical power in a few kilobytes of RAM, you're likely going to be hand-picking everything under the hood. No magic allowed.
Earlier quoted context omitted.
Otoh controllers cost almost nothing, so you can get safe concurrency just by duplicating the CPU.
You're not wrong, but this is sort of like saying that CPU's cost nothing, so just replace your i5 with 4 celerons. Distributed programming is even harder than multi-threaded programming if you need tightly coupled communication. Imagine you need to read an ADC (think oscilloscope output if you're not familiar) at 1MB/s and also need to be analyzing the data while talking to other devices on various peripherals about…
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.
Earlier quoted context omitted.
Otoh controllers cost almost nothing, so you can get safe concurrency just by duplicating the CPU.
Never trust a sentence with the word "just" in it. Duplicating the microcontroller on a project where people spend all afternoon arguing about 10 cents on the BOM is not a welcome idea. Also, the most eye-opening required course I took as an undergrad was reliability engineering. After you learn to do the reliability math, adding several solder joints to the product purely out of laziness looks profoundly stupid. Nei…
Or the word 'never'. There are no absolutes! :)
Nice article. Some good insights, as well as beginner how-to steps. The embedded industry has proven to be very resistant to innovations and modern code-writing practices. Some platforms I coded for didn't even support/allow C99 standard. C++ is gaining some foothold (mbed, for example). Developers don't feel the urge to catch on with times, like in other industries. And yet, now they are expected to write secure IoT…
Those are opposing goals.
Earlier quoted context omitted.
Yes, some examples, this list is not exhaustive. - Oberon, http://www.astrobe.com/default.htm - Java, http://www.microej.com/resources/supported-platforms/ - Pascal and Basic, https://www.mikroe.com/stm32/ - Ada, http://blog.adacore.com/tag/STM32
No offense, but nobody in their right mind is going to use any of this in a production environment. For instance, what will your hypersonic rocket do while garbage collection is running instead of it's real-time control loops?
Earlier quoted context omitted.
You're not wrong, but this is sort of like saying that CPU's cost nothing, so just replace your i5 with 4 celerons. Distributed programming is even harder than multi-threaded programming if you need tightly coupled communication. Imagine you need to read an ADC (think oscilloscope output if you're not familiar) at 1MB/s and also need to be analyzing the data while talking to other devices on various peripherals about…
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…
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.