5 ms·

I really hope rust gains a foothold in the embedded market. We need these features badly. As uCs get more powerful (you can get 200mhz chips for a few dollars

I really hope rust gains a foothold in the embedded market. We need these features badly. As uCs get more powerful (you can get 200mhz chips for a few dollars) with more RAM and complicated networked peripherals, it's a no-brainer to have these features available in a safe way. Currently if you have an application relying on dynamic memory usage, for instance, most developers will write their own simple memory management, usually in which you have an array that various things hold pointers to and get's freed all at once. All that just to spread some memory around, and concurrency is an even dirtier word than the heap...

amelius 9y ago
Otoh controllers cost almost nothing, so you can get safe concurrency just by duplicating the CPU.
- pdelbarba 9y ago
  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 what you've found. You'll have to use Direct Memory Access most likely so communicating that data stream over SPI to another microcontroller might not be the best idea unless you have a lot of extra RAM to buffer everything in. 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)
  - VLM 9y ago
    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.
    - pdelbarba 9y ago
      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.
    - kevin_thibedeau 9y ago
      You can't just thrown in more, beefier hardware with hard power and volume constraints.
- dbcurtis 9y ago
  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. Neither idea makes you look good to the old grey-beards on the other side of the table at the design review.
  - LeifCarrotson 9y ago
    > Never trust a sentence with the word "just" in it. Or the word 'never'. There are no absolutes! :)
- jandrese 9y ago
  On the other hand building a system out of a lot of small processors tends to lead to very complex systems in the end, since the different parts almost always need to communicate at some point. In the end it doesn't buy you much since you end up having to write message passing systems and their associated handlers everywhere.
pjmlp 9y ago
Many of those features are already available in Ada, and to a lesser extent Pascal and Basic. But yeah, more options is even better.
- dbcurtis 9y ago
  On an ARM Cortex M4?
  - pjmlp 9y ago
    Yes, some examples, this list is not exhaustive. - Oberon, http://www.astrobe.com/default.htm http://www.astrobe.com/default.htm - Java, http://www.microej.com/resources/supported-platforms/ http://www.microej.com/resources/supported-platforms/ - Pascal and Basic, https://www.mikroe.com/stm32/ https://www.mikroe.com/stm32/ - Ada, http://blog.adacore.com/tag/STM32 http://blog.adacore.com/tag/STM32
    - pdelbarba 9y ago
      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?
      - analognoise 9y ago
        Hypersonic rockets are probably already running Ada.
        pdelbarba 9y ago
        Good point :) I probably should have stuck to picking on Java. Ada is a pretty good example of a language that handles real time use cases with concurrency and memory pools well. That said, it's fallen out of favor in "recent" years.
        9y ago

amelius 9y ago

Otoh controllers cost almost nothing, so you can get safe concurrency just by duplicating the CPU.

pdelbarba 9y ago
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 what you've found. You'll have to use Direct Memory Access most likely so communicating that data stream over SPI to another microcontroller might not be the best idea unless you have a lot of extra RAM to buffer everything in. 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)
- VLM 9y ago
  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.
  - pdelbarba 9y ago
    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.
  - kevin_thibedeau 9y ago
    You can't just thrown in more, beefier hardware with hard power and volume constraints.
dbcurtis 9y ago
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. Neither idea makes you look good to the old grey-beards on the other side of the table at the design review.
- LeifCarrotson 9y ago
  > Never trust a sentence with the word "just" in it. Or the word 'never'. There are no absolutes! :)
jandrese 9y ago
On the other hand building a system out of a lot of small processors tends to lead to very complex systems in the end, since the different parts almost always need to communicate at some point. In the end it doesn't buy you much since you end up having to write message passing systems and their associated handlers everywhere.

pjmlp 9y ago

Many of those features are already available in Ada, and to a lesser extent Pascal and Basic. But yeah, more options is even better.

dbcurtis 9y ago
On an ARM Cortex M4?
- pjmlp 9y ago
  Yes, some examples, this list is not exhaustive. - Oberon, http://www.astrobe.com/default.htm http://www.astrobe.com/default.htm - Java, http://www.microej.com/resources/supported-platforms/ http://www.microej.com/resources/supported-platforms/ - Pascal and Basic, https://www.mikroe.com/stm32/ https://www.mikroe.com/stm32/ - Ada, http://blog.adacore.com/tag/STM32 http://blog.adacore.com/tag/STM32
  - pdelbarba 9y ago
    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?
    - analognoise 9y ago
      Hypersonic rockets are probably already running Ada.
      - pdelbarba 9y ago
        Good point :) I probably should have stuck to picking on Java. Ada is a pretty good example of a language that handles real time use cases with concurrency and memory pools well. That said, it's fallen out of favor in "recent" years.
        9y ago