6 ms·

This is amazing. Register and peripheral config is so easy to fuck up and waste a whole day chasing down because of limited debugging capabilities on these plat

This is amazing. Register and peripheral config is so easy to fuck up and waste a whole day chasing down because of limited debugging capabilities on these platforms. I've hit just about every one of those scenarios these compile-time guards now catch on one project or another. Kudos, can't wait to see where to goes from here.

jfaucett 9y ago
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.
    - 9y ago
  - 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-...
robotjosh 9y ago
What is limiting about being able to step thru each instruction?
- vvanders 9y ago
  That's assuming that you have a functional ICE[1] and aren't dealing with a timing issue in another subsystem :). ICE pins are usually configured with the exact registers this article talks about. It's common for UART/SPI serial port configuration to be a part of enabling ICE. Some chips also let you disable the ICE pins so that you can use them to pick the cheapest chip possible. [1] https://en.wikipedia.org/wiki/In-circuit_emulation https://en.wikipedia.org/wiki/In-circuit_emulation
  - alxlaz 9y ago
    Why are you doing any kind of professional work, at such a low level, without an ICE?
    - __david__ 9y ago
      Because ICEs are overrated. Many systems can't be debugged by single stepping (think servos or anything with physical hardware being controlled). ICEs rarely work well—every single one I've ever used was completely unreliable and required lots of fiddling to make it work. And then the next day you had to start the whole fiddling process over again. In the end they aren't very productive except for very specific types of bugs (they are invaluable in the very beginning of a project when you are bringing up a board). Once everything is generally up and running I find them to be pretty useless.
- IshKebab 9y ago
  Yeah if you can get that to work. It's usually a serious hassle. Another issue is that with microcontrollers you are usually debugging really low level stuff like interrupts where you can't even do printf debugging. Or you are setting registers on some black box subsystem and it just won't work and the only way to fix it is just keep randomly changing registers until you find the one you got wrong, or if you're lucky find working example code and bisect from that. Or you've got some timing sensitive code that you can't stop and the only debugging channel that is fast enough is toggling group connected to an oscilloscope.

jfaucett 9y ago

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.
  - 9y ago
- 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-...

robotjosh 9y ago

What is limiting about being able to step thru each instruction?

vvanders 9y ago
That's assuming that you have a functional ICE[1] and aren't dealing with a timing issue in another subsystem :). ICE pins are usually configured with the exact registers this article talks about. It's common for UART/SPI serial port configuration to be a part of enabling ICE. Some chips also let you disable the ICE pins so that you can use them to pick the cheapest chip possible. [1] https://en.wikipedia.org/wiki/In-circuit_emulation https://en.wikipedia.org/wiki/In-circuit_emulation
- alxlaz 9y ago
  Why are you doing any kind of professional work, at such a low level, without an ICE?
  - __david__ 9y ago
    Because ICEs are overrated. Many systems can't be debugged by single stepping (think servos or anything with physical hardware being controlled). ICEs rarely work well—every single one I've ever used was completely unreliable and required lots of fiddling to make it work. And then the next day you had to start the whole fiddling process over again. In the end they aren't very productive except for very specific types of bugs (they are invaluable in the very beginning of a project when you are bringing up a board). Once everything is generally up and running I find them to be pretty useless.
IshKebab 9y ago
Yeah if you can get that to work. It's usually a serious hassle. Another issue is that with microcontrollers you are usually debugging really low level stuff like interrupts where you can't even do printf debugging. Or you are setting registers on some black box subsystem and it just won't work and the only way to fix it is just keep randomly changing registers until you find the one you got wrong, or if you're lucky find working example code and bisect from that. Or you've got some timing sensitive code that you can't stop and the only debugging channel that is fast enough is toggling group connected to an oscilloscope.