6 ms·

I know this has me really exited too. I think there is so much potential for rust in the embedded space. Personally, I'd be content if the core team just concen

I know this has me really exited too. I think there is so much potential for rust in the embedded space. Personally, I'd be content if the core team just concentrated on making rust the best platform for doing embedded programming. IMHO that's where rust can really blow the competition away.

petra 9y ago
The hard challenge in embedded is porting to every mcu. Can this be done without convincing mcu companies to do it themselves ?
- Eridrus 9y ago
  They could use Julia's "resurrected LLVM "C Backend"" and compile down to C, and then let developers use existing tools to get running on their MCU. Would probably mess with the debugging experience though.
  - steveklabnik 9y ago
    mrustc would be another path here.
  - nitrogen 9y ago
    Would probably mess with the debugging experience though. If the compiler in question supports the #line directive, it might not be too bad.
- henrikeh 9y ago
  Honestly it depends upon what people expect from "the port". A lot of people seem to be content with Arduino-like software compatibility: high-level constructs that offer basic functionality expected across a larger number of mcu's. Even something as "simple" as a timer peripheral will vary greatly across manufacturers and families of mcu's -- something you'd care about for real-time control, but not care about in other cases. ARM controllers are (relatively) uniform and the svd files do a lot of the work by providing the mapping for the memory mapped peripherals. Across other devices it becomes even more complicated. AVR devices, AFAIK, are not providing memory mapped flash. There are also differences in byte v page erasable flash and eeprom. How would something like this map to Rust? I don't know and I'm honestly skeptical of the practical use but there is a quite serious effort put into making the AVR backend for LLVM ready for use. --- It really makes me wonder a lot about "embedded" programming and where it is heading. If I were to bet I'd say that there is a significant movement to employ more and more powerful "microcontrollers" in order to allow remove all the resource constraints typically associated with "embedded" programming. Stuff like Esprino, MicroPython, huge layers of abstraction etc. are today kind of nice tools for learning and starting out -- but give it a few years and somebody will ship a successful product build around this. It doesn't matter that the BOM cost is higher, the current draw is larger and the complexity and security understanding decreased -- it enables a faster time to market and in the end that is what makes the business. The same is happening in FPGA development. The old-fashioned hardware folks say that "not how it's done" -- myself included. But you know what they say: > When the wind of change blows, some build walls, while others build windmills.
  - vvanders 9y ago
    > It doesn't matter that the BOM cost is higher, the current draw is larger and the complexity and security understanding decreased -- it enables a faster time to market and in the end that is what makes the business. I think consumers are still going to be cost-sensitive in quite a few markets so BOM will still be critical. I'd argue you're already seeing this with more than a few companies using Android + mid-tier ARMs when market time matters more than final cost. There's probably just going to be less people that know how to do it, much in the same way native programming is today.
  - fake-name 9y ago
    > ARM controllers are (relatively) uniform and the svd files do a lot of the work by providing the mapping for the memory mapped peripherals. What? Sure, the core is relatively uniform, but the peripherals are radically different between manufacturers.
    - henrikeh 9y ago
      Absolutely, device drivers must still be written. My observation is just that these device drivers are hidden deeper and deeper levels of abstraction, just like on a regular PC.
    - FigBug 9y ago
      CMSIS provides an abstraction layer for peripherals, so at least the basics are the same between manufacturers. At least it's something, usually when switch MCUs you have to rewrite everything related to peripherals. https://developer.arm.com/embedded/cmsis https://developer.arm.com/embedded/cmsis
      - dbcurtis 9y ago
        True, but the main way an ARM licensee has to differentiate their product is adding unique peripherals. So the generic functionality is in CMSIS, but the reason you chose the processor may not be. If you look at a die photo and see what area goes to what, pretty quickly you conclude all microcontroller makers are just selling value-added flash memory.
- xfer 9y ago
  I have an xmos board(xcore architecture), although llvm has a backend for it, it is missing debugging support for timing analysis(XTA) and also outdated so potentially missing on various size optimizations. Even ignoring that, because llvm instruction set mismatch between versions, i can't feed the rust generated IR to their firmware generating tool. If you see their language xC(https://en.wikipedia.org/wiki/XC_(programming_language) https://en.wikipedia.org/wiki/XC_(programming_language), it extends C with various pointer types(restricted, movable, alias) for memory safety. Rust definitely is a good fit for this kind of development with borrow checker, traits etc.
- jfaucett 9y ago
  > The hard challenge in embedded is porting to every mcu. Can this be done without convincing mcu companies to do it themselves ? Agreed, but I think long-term its certainly going to be easier doing that on the rust platform with a tool like cargo than the current state of affairs. Maybe if rust just concentrated on the hobbyist/prototypers at first i.e. arduino / rasberry pi, to make that experience as great and pain free as possible and really showcase what can be done with rust and cargo. That would at least make it a viable tool for professors teaching the next gen of engineers and all the startups/prototypers/hobbiests.
steveklabnik 9y ago
FWIW, I share your feelings regarding prioritizing this. In general, it's something we want, but we're still discussing what the overall goals for this year will be. We'll see!
jvns 9y ago
if you have ideas about what Rust should focus on in 2018, consider writing a blog post about your ideas! they have an open call for posts right now. https://blog.rust-lang.org/2018/01/03/new-years-rust-a-call-for-community-blogposts.html https://blog.rust-lang.org/2018/01/03/new-years-rust-a-call-...

petra 9y ago

The hard challenge in embedded is porting to every mcu. Can this be done without convincing mcu companies to do it themselves ?

Eridrus 9y ago
They could use Julia's "resurrected LLVM "C Backend"" and compile down to C, and then let developers use existing tools to get running on their MCU. Would probably mess with the debugging experience though.
- steveklabnik 9y ago
  mrustc would be another path here.
- nitrogen 9y ago
  Would probably mess with the debugging experience though. If the compiler in question supports the #line directive, it might not be too bad.
henrikeh 9y ago
Honestly it depends upon what people expect from "the port". A lot of people seem to be content with Arduino-like software compatibility: high-level constructs that offer basic functionality expected across a larger number of mcu's. Even something as "simple" as a timer peripheral will vary greatly across manufacturers and families of mcu's -- something you'd care about for real-time control, but not care about in other cases. ARM controllers are (relatively) uniform and the svd files do a lot of the work by providing the mapping for the memory mapped peripherals. Across other devices it becomes even more complicated. AVR devices, AFAIK, are not providing memory mapped flash. There are also differences in byte v page erasable flash and eeprom. How would something like this map to Rust? I don't know and I'm honestly skeptical of the practical use but there is a quite serious effort put into making the AVR backend for LLVM ready for use. --- It really makes me wonder a lot about "embedded" programming and where it is heading. If I were to bet I'd say that there is a significant movement to employ more and more powerful "microcontrollers" in order to allow remove all the resource constraints typically associated with "embedded" programming. Stuff like Esprino, MicroPython, huge layers of abstraction etc. are today kind of nice tools for learning and starting out -- but give it a few years and somebody will ship a successful product build around this. It doesn't matter that the BOM cost is higher, the current draw is larger and the complexity and security understanding decreased -- it enables a faster time to market and in the end that is what makes the business. The same is happening in FPGA development. The old-fashioned hardware folks say that "not how it's done" -- myself included. But you know what they say: > When the wind of change blows, some build walls, while others build windmills.
- vvanders 9y ago
  > It doesn't matter that the BOM cost is higher, the current draw is larger and the complexity and security understanding decreased -- it enables a faster time to market and in the end that is what makes the business. I think consumers are still going to be cost-sensitive in quite a few markets so BOM will still be critical. I'd argue you're already seeing this with more than a few companies using Android + mid-tier ARMs when market time matters more than final cost. There's probably just going to be less people that know how to do it, much in the same way native programming is today.
- fake-name 9y ago
  > ARM controllers are (relatively) uniform and the svd files do a lot of the work by providing the mapping for the memory mapped peripherals. What? Sure, the core is relatively uniform, but the peripherals are radically different between manufacturers.
  - henrikeh 9y ago
    Absolutely, device drivers must still be written. My observation is just that these device drivers are hidden deeper and deeper levels of abstraction, just like on a regular PC.
  - FigBug 9y ago
    CMSIS provides an abstraction layer for peripherals, so at least the basics are the same between manufacturers. At least it's something, usually when switch MCUs you have to rewrite everything related to peripherals. https://developer.arm.com/embedded/cmsis https://developer.arm.com/embedded/cmsis
    - dbcurtis 9y ago
      True, but the main way an ARM licensee has to differentiate their product is adding unique peripherals. So the generic functionality is in CMSIS, but the reason you chose the processor may not be. If you look at a die photo and see what area goes to what, pretty quickly you conclude all microcontroller makers are just selling value-added flash memory.
xfer 9y ago
I have an xmos board(xcore architecture), although llvm has a backend for it, it is missing debugging support for timing analysis(XTA) and also outdated so potentially missing on various size optimizations. Even ignoring that, because llvm instruction set mismatch between versions, i can't feed the rust generated IR to their firmware generating tool. If you see their language xC(https://en.wikipedia.org/wiki/XC_(programming_language) https://en.wikipedia.org/wiki/XC_(programming_language), it extends C with various pointer types(restricted, movable, alias) for memory safety. Rust definitely is a good fit for this kind of development with borrow checker, traits etc.
jfaucett 9y ago
> The hard challenge in embedded is porting to every mcu. Can this be done without convincing mcu companies to do it themselves ? Agreed, but I think long-term its certainly going to be easier doing that on the rust platform with a tool like cargo than the current state of affairs. Maybe if rust just concentrated on the hobbyist/prototypers at first i.e. arduino / rasberry pi, to make that experience as great and pain free as possible and really showcase what can be done with rust and cargo. That would at least make it a viable tool for professors teaching the next gen of engineers and all the startups/prototypers/hobbiests.

steveklabnik 9y ago

FWIW, I share your feelings regarding prioritizing this. In general, it's something we want, but we're still discussing what the overall goals for this year will be. We'll see!

jvns 9y ago

if you have ideas about what Rust should focus on in 2018, consider writing a blog post about your ideas! they have an open call for posts right now. https://blog.rust-lang.org/2018/01/03/new-years-rust-a-call-for-community-blogposts.html https://blog.rust-lang.org/2018/01/03/new-years-rust-a-call-...