Hacker News new | comments | ask | show | jobs | submit login
Show HN: Rust, ARM Cortex M, and a Generated HAL (jamesmunns.com)
137 points by jamesmunns on Sept 26, 2016 | hide | past | web | favorite | 43 comments



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.


With the way rust is developing, it could nudge C as the main programming language for embedded. Kudos this the team.


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.


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.


  > input would be appreciated here 
Ha! :D <3

I mirror what dpc_pw says, but in a slightly different way: while I'm kinda comfy with assembly, I'm not fantastic with it yet. But that's more about the details than the big picture, and I can usually feel pretty confident I have an understanding of the shape of what's going on. I have no idea how to turn this intuition into something teachable yet though :(

Oh, and on the "breakneck pace" bit: the whole idea is that things are backwards compatible, so you don't _have_ to "keep up" if you don't want to. But the idea is that keeping up should be trivial. Most people don't do anything at all to move to the new compiler.

One issue that there is with this, though, is support: right now, we don't super-officially support older versions of Rust, though we will make a best-effort if there's a security issue. But at some point, we'll probably have "LTS" releases with actual support on a longer timeframe. This is part of the whole maturity thing, which sadly, just needs time :)


He he, i knew you are lurking somewhere :-). Yeah, i will just have to give it time.

Good to hear about the possibility of a LTS release! Any rough estimation about the timeframe?

Oh and by the way, the documentation is fantastic.Big thank you!


Thanks :)

  > Any rough estimation about the timeframe?
Not particularly. It's still in early stages. We proposed a "Rust platform" idea, but it was poorly received by a large chunk of the community. We are starting towards moving towards a kind of "yearly planning" strategy, which would be one option for the timing of such a thing. But we'll see; it really needs someone to champion it, and like any other feature, as we start to feel pressure, we'll start to prioritize it relative to other things.


Regarding 1., do you completely disregard MISRA-C and the other safety certifications?

What about bounds checking and making sure the pointers are always valid?


"Regarding 1., do you completely disregard MISRA-C and the other safety certifications?"

Hmm, i don't think i understand that. Of course we do not disregard MISRA-C. I don't know where this impression came from. As i said, no dynamic allocation, no pointer arithmetic etc. Could you elaborate?

"What about bounds checking and making sure the pointers are always valid?"

Well, if your code is controlling big, possibly dangerous machines, you will/should be doing formal verification anyway (i use FRAMA-C). This will go a long way regarding said issues.

Furthermore you will not/should not create your complex state machines by hand. There are tools for that (and yes, formally verified as well).

P.S.: CompCert is a necessity as well.


Because of this "In my world memory safety is simply not an issue, because we don't allocate dynamically".

In C, memory safety is always an issue, due to how array and strings are handled via pointers without any sort of validation.

Thanks for clarifying your tooling, nice to see you care.

It would be good if more developers would care to use Frama-C.


Ah, i see. Of course it is an issue, but it is not an issue ;-).


Embedded dev here too. I worked mostly on bigger (processing power-wise) systems. Actually as big embedded as you can find (PC-level performance), I toy with smaller ones as a hobby. :)

1. That is kind of true but only in tiny systems. Having some lists (with proven bounded size etc.) is still often necessary, where pointer invalidation is a problem. But even tiny embedded systems will grow in processing power, get SMP etc. - it's just a matter of time. And there is way more that Rust has to offer.

2. Rust is not functional programming language. Rust allows to write parts of the code in functional fashion and the resulting code is very efficient (because it's functional and can be optimized well), so you can employ it when needed. The thing is: C does not support functional programming well, so you write code imperative way. But imperative ways are neither inherently faster, nor easier. In many cases functional style code is both easier to understand and generates better code. Sometimes because it's easier to understand the code, you can spent more time optimizing the performance, instead of fixing bugs.

3. Actually after couple of years writing Rust code, I can predict the asm generated by `rustc` almost as well as C compilers. Abstractions provided by rust map very directly to CPU instructions. Also, there have been numerous times when working on C code, I had to give up on optimal runtime performance because lack of C expressiveness, safety and sanity concerns. Rust static dispatch through generic traits, combined with optimizer and LTO does wonders, really. People just need to overcome the bias that abstractions are costly.

4. GC in Rust is going to be optional and "manual". Just like `Vec` does dynamic allocations, and you can just not use it. The "functionality working after twenty years" is IMO a wishful thinking. Real C code is ridden with bugs, especially undefined behaviors dependencies, that after 20 years compilers tend to expose rather easily as they got better at (ab)using them. UB is actually my biggest problem with C and C++. I have been working with very smart people, following all the standards, using static analysis, carefully testing and reviewing and we still were hit quite often with C-quirkiness and UB. It's common in embedded to pin the version of the toolchain for the precisely that reason: changing a toolchain version can expose new bugs in your code (not to mention bugs in the compiler, but that's another story). Also, the building system: good luck running `make` (or something like it) on a project from 20-years ago.

> Remember, this kind of code is keeping all the infrastructure we all rely on working.

A lot of human suffering had to been thrown at the problem to make C code do the job there, and countless list of bugs in critical widely-deployed software tells much about how well it worked. It is sooo relieving, when you don't have to debug weird bugs due to UB, data races, pointer invalidation, memory allocations bugs, and you can actually express your code in a way that is both fast and impossible to mis-use.

However I agree that Rust is, from serious embedded work perspective, completely immature.

5. Agreed. Not to mention that in some application the compiler (and all toolchain elements), as well as the compiled software needs to be certified. Good luck building a certified Rust compiler. :)

6. That is true. Rust is way more complex, and many people does their job well using tools they know, goes home and have better things to do then learn new programming languages.

IMO. Rust won't overtake neither C, nor C++ places any time soon (let's say 20 years), but for some applications and some people is going to be very valuable proposition. There are some things that C just completely sucks at: it's ridden with UB instanity, lack of expressiveness, worse performance (yes, I really believe C performance is going to be worse than Rust one due to aliasing and static dispatch), lack of integrated building system (yay cargo!) which to this day makes it really hard to reuse code. As micro-controllers become more and more powerful (SMP!) and bigger-embedded systems more popular, Rust might be gaining some traction.


I am also an embedded dev, and I agree heartily with your post.

Something that Rust is bringing is sane and safe default. That does not look like a big deal, because you can write C and C++ "the right way". But in the real world, it does not always work like that.

My team has inherited a 1M LoC real time application that is been moved around and developed by different team of subcontractors in the last ten years. It has devolved in a bug ridden mess (hence the need to bring it back in house).

Rust would not have been a silver bullet but there is a whole class of error that would not have happened, and would have been forbidden in the first place.

The subcontractors were supposed to use a static analyzer but we got the code back we had to fix 5000 defects of the worst kind (buffer overflows, dereferencing null pointer, memory leaks and so on)

For me, the value proposition of Rust is that it is roughly equivalent to C + a good static analyzer, but it is for free, and you are sure the checks are in place and have been executed.

In my mind it is pretty clear that in the next 20 years, C is going to be replace by something safer in the embedded world. It might be Rust, it might be something else.


> People just need to overcome the bias that abstractions are costly.

C++ (which has a lot of zero-cost abstractions) tried to shift this bias since several decades with very limited success. Languages like Nim (or even Matlab with Embedded Coder) have the advantage there's intermediate C output that can be manually inspected for unintended runtime abstractions.


The irony is that C was in that spot on the 80's and early 90's, but somehow it became so ingrained in the industry that people forget how it was like when C only mattered to UNIX workstations.


Also a reply to serene (one post below).

Before i reply, i would like to make two point clear.

First, i'm not going to argue about performance, because i've used Rust for personal projects, i can say that it is really (like REALLY) efficient. Performance is great, no discussion.

And two, as said, i've used it and like it. But honestly, the best thing about it (IMO) are the error messages. So...

1.Agreed. I'm just skeptical if i will see the day that those new processors will be as energy efficient as a 8051. Power consumption will always be an issue.

2.Well yes and no, at least that is my (maybe false) impression.As you say, if you want to be really efficient with Rust, you really should program functional as much as you possibly can. So is it functional or not? My impression is that it most of the time does not know what it wants to be.

3.Agreed and motivational to hear that it just takes some time (i'm still not that good with predicting the outcome).

4."Just like `Vec` does dynamic allocations, and you can just not use it." This, right there. The "and you can just not use it". This is what the C++ camp is saying, so the Rust community could end like the C++ community, where everyone is using another dialect.But that's just my personal grief.Anyhow, yes UB is maybe THE biggest problem. I've mentioned CompCert above, so if you are interested see http://compcert.inria.fr/man/manual004.html.

Regarding "A lot of human suffering had to been thrown at the problem to make C code do the job there", yes i agree. But now it (mostly) works, and nobody wants to risk anything and touch that code base, let alone rewrite.

5.Agreed.

6.My experience is not even that my peers have better things to do or do not want to try. I think it's matter of taste. People are different and prefer different things.

To seren: "Rust would not have been a silver bullet but there is a whole class of error that would not have happened, and would have been forbidden in the first place. The subcontractors were supposed to use a static analyzer but we got the code back we had to fix 5000 defects of the worst kinds (buffer overflows, dereferencing null pointer, memory leaks and so on) For me, the value proposition of Rust is that it is roughly equivalent to C + a good static analyzer, but it is for free, and you are sure the checks are in place and have been executed."

What makes you think that those people wouldn't have used "unsafe" everywhere, just because it makes their job easier?You would have ended up with the same mess.


> What makes you think that those people wouldn't have used "unsafe" everywhere, just because it makes their job easier?You would have ended up with the same mess.

To be fair, it would probably have happened that way, but I think is harder to hide the use of unsafe everywhere.


while Misra-C does have some good engineering practice in it, I think it is jumping the gun when the rust is still in its infancy. Give Rust another 5 years and support from a few more microcontroller vendors, and maybe there is a chance for a Misra-Rust to be created.


*compliant

so sorry


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.


> 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

[2]: http://www.st.com/stm32discovery


I second this. The STM32 discovery series boards are really great for messing around with!


> 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/


im trying to learn rust right now. its really hard


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.


Knowing C, and liking Rust and struggling to learn it. I think Rust is more like C++ than C in the type of difficulty of learning.

C is more like chess: the rules are not that complicated and you can figure out how to write code. It will be a long time to learn to write good C code.

With Rust it is hard to figure out the rules, even to get start writing code. They are more like complicated board games with lots of rules to learn.

As an aside, after I wrote that it reminded me of this map: http://goldns.ru/cppmap-2012.png C++ devs will get all the inside jokes there, Alexandrescu's castle, curiously recurring template, exceptional swamps and others...


Rust seems very much like modern C++. Borrowing, references and the like have nearly direct analogs to C++ references, unique_ptr and other STL constructs. Except the compiler enforces them with (my opinion) relatively more clear error messages most of the time and in some cases the syntax is actually clearer (others not necessarily).

My biggest struggle so far is overcoming the differences in the implementation of generics. I have yet to "fight the borrow checker," but the generics implementation is something of a hurtle for me.


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 might be good too, but I've only lurked there.


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/ 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 :)


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.


File a bug against mdbook, we'll see what the maintainer says :)

https://github.com/azerupi/mdBook


C is easier to learn, hard to use well. Rust is harder to learn, but easier to use well.

C is an easier language to learn that Rust because it's simpler. That is deceptive though - you may understand the language, but it takes years to understand how to use it properly and safely. Rust has a bit of a learning hurdle at the start, but once you understand the language it's much clearer how to use it effectively and safely.

(C++ is the worst of both worlds)


Certainly not easy. And you could forget the concepts if you don't continue with it. But the documentation is great. They've explained everything clearly. If you follow it one by one, it actually gives you a "masochistic" pleasure of learning it ;)


What languages do you know? There are some tutorials aimed at people coming from different languages.

That said, some concepts hit you in the face right away, making the language have an initially steep learning curve, but after that it becomes much easier.


Woo-Hoo! This is super exciting! Thanks!


Dope !


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


D is garbage collected, which rules it out for embedded systems.


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.


Really?! Java doesn't have any problems with that.

http://www.ptc.com/developer-tools/perc

https://www.aicas.com/cms/en/JamaicaVM

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.


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.


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

MicroEJ developed in a mix of Java and C.

http://www.microej.com/products/device-software-development/...


D does catch on slow and steady. ;)




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: