9 ms·

Show HN: Rust, ARM Cortex M, and a Generated HAL

137 points by jamesmunns 10y ago

anujdeshpande 10y ago
Dope !
wyager 10y ago
Sweet! The Teensy might be the most accessible ARM dev board right now, so this is great news for embedded rust. Ever since Rust was announced, I've been eagerly awaiting it's practicability as a replacement for C/C++. The only place you really have to use either of those these days is embedded systems, so this is kind of the final step towards getting modern languages in every subfield of software development.
- pjmlp 10y ago
  > The only place you really have to use either of those these days is embedded systems, so this is kind of the final step towards getting modern languages in every subfield of software development. Unless you are doing it for work, there are alternatives although not as safe as Rust. http://www.mikroe.com/compilers/ http://www.mikroe.com/compilers/
- duskwuff 10y ago
  > The Teensy might be the most accessible ARM dev board right now Disagree. It's nice enough as an Arduino-alike, but it doesn't have any debugging capabilities -- the only commands exposed by the loader[1] are "write block" and "reboot". As an ARM development board, I'm much more a fan of ST's Discovery series[2]. Most of their boards are in the $10-$20 range, and they all include a USB-based programmer/debugger compatible with open-source tools. [1]: https://www.pjrc.com/teensy/halfkay_protocol.html https://www.pjrc.com/teensy/halfkay_protocol.html [2]: http://www.st.com/stm32discovery http://www.st.com/stm32discovery
  - tbirdz 10y ago
    I second this. The STM32 discovery series boards are really great for messing around with!
JoshTriplett 10y ago
I ran into some of the folks behind this at RustConf; they're doing some really interesting work. They're running Rust on bare-metal with a minimalist embedded OS, and providing easy ways to get access to twiddle hardware, without having a dozen intermediate layers between your code and that hardware.
- yitchelle 10y ago
  With the way rust is developing, it could nudge C as the main programming language for embedded. Kudos this the team.
  - hak8or 10y ago
    Good luck with that. There ain't no way rust is getting a misra complaint setup anytime soon. Not to mention, the current vendors are entrenched in their ways to ridiculous levels. Companies like keil for example don't bother to have a Linux complaint tool chain.
    - posterboy 10y ago
      *compliant so sorry
    - S_I 10y ago
      I do embedded development (for 8051 8 Bit micro controllers), so IMO it has nothing to do with entrenched, and everything to do with with the following (at least from my point of view). But before i explain my reasoning, i will the define the term 'embedded development' for this comment as follows: - No gigahertz (not even close). - No multi core. - No giga- and no megabytes of RAM. - No OS. - Micro second respond time, but truck loads of computation. - No ARM processors. So here goes. 1.In my world memory safety is simply not an issue, because we don't allocate dynamically. So neither the borrow checker nor lifetimes are an advantage. 2.The micro controllers are piloting a complex machine with all kinds of actuators and sensors. So the code is actually (and that is really a rough generalization) a big state machine. So the functional elements of Rust don't help that much because, although functional programming and state machines are doable, the code is IMO far from ..... let's say elegant. 3.If you do real time systems with micro second respond times (like i do), you really want to know what kind of code will be generated from a specific line of code just by looking at it. Maybe experienced Rust developers are able to do that, input would be appreciated here (looking at you Steve ;-). 4.I'v read about the guaranties the Rust developers give regarding stability of features, breaking changes etc. This combined with the (at least in this domain) neck breaking speed of development (i see the Rust community already talking about optional GC) is pretty much a show stopper in this domain. Why? Because (warning generalization coming) most embedded developers are already dealing with really hard problems, they simply don't have the time to keep up. Furthermore, if you have code that needs to be not only compilable, but also functionally working after twenty years (yes you read that right), you do not want things developing that fast. Remember, this kind of code is keeping all the infrastructure we all rely on working. 5.Rust is a complex language to build a compiler for. You will have to persuade Keil and friends to invest the time and money to do that. And no, LLVM is no option, because it does not target enough architectures. 6.Rust is perceived as too complex by my peers. Don't say it is easy. It is may be easy for you or me, but not for everyone. And you know, those people are valuable too and need a job too. So there you have it. Rust just does not buy you enough in that kind of environment.
splitrocket 10y ago
Woo-Hoo! This is super exciting! Thanks!
bronz 10y ago
im trying to learn rust right now. its really hard
- wyldfire 10y ago
  Stick with it! If you don't already have experience with C/C++ I would imagine it being extremely challenging. I've only scratched the surface of the language and I can agree that it's not simple. I've gotten lots of help from #rust on IRC and places like /r/rust. https://users.rust-lang.org https://users.rust-lang.org might be good too, but I've only lurked there.
- steveklabnik 10y ago
  I am in the process of re-writing the book, and the quality is much higher this time around. http://rust-lang.github.io/book/ http://rust-lang.github.io/book/ getting there! Chapters 8 and 9 should be merged soon. But yeah, beyond that, we love helping new people: my sibling commenter already gave you all the good links :)
  - leeoniya 10y ago
    hey Steve, would it be possible to retain scroll position of the nav menu after navigation. I'm finding the auto-scroll of the clicked section to top a bit disorienting.
    - steveklabnik 10y ago
      File a bug against mdbook, we'll see what the maintainer says :) https://github.com/azerupi/mdBook https://github.com/azerupi/mdBook
- bsder 10y ago
  Just so you know and hopefully are encouraged--learning C is really hard, too. Most people just never actually learn it. Rust makes you come to grips immediately with the things that will bite you in C later. Keep at it. It's a continuing process regardless of language.
goatlover 10y ago
D seems like an easier language than Rust. It's too bad D didn't catch on.
- toomanybeersies 10y ago
  D is garbage collected, which rules it out for embedded systems.
  - lultimouomo 10y ago
    They're working hard to reduce the dependency on the GC as much as possibile. I think if they had done that and the C++ interop a few years ago D would have had more success, but with limited resources I understand that it may have been to much of a burden on the language development proper.
  - pjmlp 10y ago
    Really?! Java doesn't have any problems with that. http://www.ptc.com/developer-tools/perc http://www.ptc.com/developer-tools/perc https://www.aicas.com/cms/en/JamaicaVM https://www.aicas.com/cms/en/JamaicaVM http://www-03.ibm.com/software/products/en/real-time http://www-03.ibm.com/software/products/en/real-time The problem with D's garbage collector is that it just a very old implementation, with performance problems and they lack contributions to improve it.
    - toomanybeersies 10y ago
      Those are all running on RTOSes such as RT Linux on an X86/PPC or full ARM platform. Those won't run on an ARM Cortex M chip, where your current options are effectively ASM, Ada, or C if you want high performance and low price and power consumption.
      - pjmlp 10y ago
        They also run bare metal. Do you want commercial products specifically targeted for ARM Cortex M chip with GC enabled languages? Bare metal Oberon compilers for ARM Cortex-M4 and Cortex-M3: http://www.astrobe.com/default.htm http://www.astrobe.com/default.htm MicroEJ developed in a mix of Java and C. http://www.microej.com/products/device-software-development/microej-os/ http://www.microej.com/products/device-software-development/...

137 points by jamesmunns 10y ago

Dope !

Sweet! The Teensy might be the most accessible ARM dev board right now, so this is great news for embedded rust. Ever since Rust was announced, I've been eagerly awaiting it's practicability as a replacement for C/C++. The only place you really have to use either of those these days is embedded systems, so this is kind of the final step towards getting modern languages in every subfield of software development.

pjmlp 10y ago
> The only place you really have to use either of those these days is embedded systems, so this is kind of the final step towards getting modern languages in every subfield of software development. Unless you are doing it for work, there are alternatives although not as safe as Rust. http://www.mikroe.com/compilers/ http://www.mikroe.com/compilers/
duskwuff 10y ago
> The Teensy might be the most accessible ARM dev board right now Disagree. It's nice enough as an Arduino-alike, but it doesn't have any debugging capabilities -- the only commands exposed by the loader[1] are "write block" and "reboot". As an ARM development board, I'm much more a fan of ST's Discovery series[2]. Most of their boards are in the $10-$20 range, and they all include a USB-based programmer/debugger compatible with open-source tools. [1]: https://www.pjrc.com/teensy/halfkay_protocol.html https://www.pjrc.com/teensy/halfkay_protocol.html [2]: http://www.st.com/stm32discovery http://www.st.com/stm32discovery
- tbirdz 10y ago
  I second this. The STM32 discovery series boards are really great for messing around with!

JoshTriplett 10y ago

I ran into some of the folks behind this at RustConf; they're doing some really interesting work. They're running Rust on bare-metal with a minimalist embedded OS, and providing easy ways to get access to twiddle hardware, without having a dozen intermediate layers between your code and that hardware.

yitchelle 10y ago
With the way rust is developing, it could nudge C as the main programming language for embedded. Kudos this the team.
- hak8or 10y ago
  Good luck with that. There ain't no way rust is getting a misra complaint setup anytime soon. Not to mention, the current vendors are entrenched in their ways to ridiculous levels. Companies like keil for example don't bother to have a Linux complaint tool chain.
  - posterboy 10y ago
    *compliant so sorry
  - S_I 10y ago
    I do embedded development (for 8051 8 Bit micro controllers), so IMO it has nothing to do with entrenched, and everything to do with with the following (at least from my point of view). But before i explain my reasoning, i will the define the term 'embedded development' for this comment as follows: - No gigahertz (not even close). - No multi core. - No giga- and no megabytes of RAM. - No OS. - Micro second respond time, but truck loads of computation. - No ARM processors. So here goes. 1.In my world memory safety is simply not an issue, because we don't allocate dynamically. So neither the borrow checker nor lifetimes are an advantage. 2.The micro controllers are piloting a complex machine with all kinds of actuators and sensors. So the code is actually (and that is really a rough generalization) a big state machine. So the functional elements of Rust don't help that much because, although functional programming and state machines are doable, the code is IMO far from ..... let's say elegant. 3.If you do real time systems with micro second respond times (like i do), you really want to know what kind of code will be generated from a specific line of code just by looking at it. Maybe experienced Rust developers are able to do that, input would be appreciated here (looking at you Steve ;-). 4.I'v read about the guaranties the Rust developers give regarding stability of features, breaking changes etc. This combined with the (at least in this domain) neck breaking speed of development (i see the Rust community already talking about optional GC) is pretty much a show stopper in this domain. Why? Because (warning generalization coming) most embedded developers are already dealing with really hard problems, they simply don't have the time to keep up. Furthermore, if you have code that needs to be not only compilable, but also functionally working after twenty years (yes you read that right), you do not want things developing that fast. Remember, this kind of code is keeping all the infrastructure we all rely on working. 5.Rust is a complex language to build a compiler for. You will have to persuade Keil and friends to invest the time and money to do that. And no, LLVM is no option, because it does not target enough architectures. 6.Rust is perceived as too complex by my peers. Don't say it is easy. It is may be easy for you or me, but not for everyone. And you know, those people are valuable too and need a job too. So there you have it. Rust just does not buy you enough in that kind of environment.

splitrocket 10y ago

Woo-Hoo! This is super exciting! Thanks!

bronz 10y ago

im trying to learn rust right now. its really hard

wyldfire 10y ago
Stick with it! If you don't already have experience with C/C++ I would imagine it being extremely challenging. I've only scratched the surface of the language and I can agree that it's not simple. I've gotten lots of help from #rust on IRC and places like /r/rust. https://users.rust-lang.org https://users.rust-lang.org might be good too, but I've only lurked there.
steveklabnik 10y ago
I am in the process of re-writing the book, and the quality is much higher this time around. http://rust-lang.github.io/book/ http://rust-lang.github.io/book/ getting there! Chapters 8 and 9 should be merged soon. But yeah, beyond that, we love helping new people: my sibling commenter already gave you all the good links :)
- leeoniya 10y ago
  hey Steve, would it be possible to retain scroll position of the nav menu after navigation. I'm finding the auto-scroll of the clicked section to top a bit disorienting.
  - steveklabnik 10y ago
    File a bug against mdbook, we'll see what the maintainer says :) https://github.com/azerupi/mdBook https://github.com/azerupi/mdBook
bsder 10y ago
Just so you know and hopefully are encouraged--learning C is really hard, too. Most people just never actually learn it. Rust makes you come to grips immediately with the things that will bite you in C later. Keep at it. It's a continuing process regardless of language.

goatlover 10y ago

D seems like an easier language than Rust. It's too bad D didn't catch on.

toomanybeersies 10y ago
D is garbage collected, which rules it out for embedded systems.
- lultimouomo 10y ago
  They're working hard to reduce the dependency on the GC as much as possibile. I think if they had done that and the C++ interop a few years ago D would have had more success, but with limited resources I understand that it may have been to much of a burden on the language development proper.
- pjmlp 10y ago
  Really?! Java doesn't have any problems with that. http://www.ptc.com/developer-tools/perc http://www.ptc.com/developer-tools/perc https://www.aicas.com/cms/en/JamaicaVM https://www.aicas.com/cms/en/JamaicaVM http://www-03.ibm.com/software/products/en/real-time http://www-03.ibm.com/software/products/en/real-time The problem with D's garbage collector is that it just a very old implementation, with performance problems and they lack contributions to improve it.
  - toomanybeersies 10y ago
    Those are all running on RTOSes such as RT Linux on an X86/PPC or full ARM platform. Those won't run on an ARM Cortex M chip, where your current options are effectively ASM, Ada, or C if you want high performance and low price and power consumption.
    - pjmlp 10y ago
      They also run bare metal. Do you want commercial products specifically targeted for ARM Cortex M chip with GC enabled languages? Bare metal Oberon compilers for ARM Cortex-M4 and Cortex-M3: http://www.astrobe.com/default.htm http://www.astrobe.com/default.htm MicroEJ developed in a mix of Java and C. http://www.microej.com/products/device-software-development/microej-os/ http://www.microej.com/products/device-software-development/...