Embedded Rust on microcontrollers (Cortex M, Cortex A, Softcores etc.)

[tggzzz]

We should use all tools at our disposal to reduce defects in deployed systems.

That's true too. You need to evaluate different solutions and make decisions based on your evaluation. Which, BTW,  you cannot do until you know what is that you're supposed to build.

Believing that using a certain language would solve problems is like believing that choosing a certain hammer would let you build a better house. There are other things to consider first - blueprints, materials, construction methods ...

You are committing an elementary error: conflating verification (do the right thing) and verification (do the thing right) in order to make an argument. That is a strawman argument since other people are not conflating the two.

[profdc9]

I would really sincerely like to see a better solution for programming, and if Rust is that, I would be more in favor of it.  Nothing on this thread is going to result in a better solution, or convince anyone to try or adopt anything.  There is no one trying to reach out to someone halfway, and if I have one complaint about Rust, it's that those who advocate it are especially unwilling to reach out to others.  They almost wear the difficulty of their language as a badge of honor, so that only the best and most qualified will use it.  No one has to use anything, and this thread is doing very little to convince anyone that Rust is an approachable, useful solution for anything.

It would be great if even one person on this thread said, "well golly, I didn't realize Rust is a good tool, I'll try it," but the rhetoric here is polarizing and offers no solutions.  This is one of my greatest beefs with Rust in general, in that it seems to be more about how not to program than it is how to program, which isn't very helpful.  I can't see a language with this philosophy being widely adopted.

There are good ideas in Rust, but I am going to guess that someone other group of people that are more accommodating will likely use them in a more approachable language, and that will be adopted instead of Rust.

[NorthGuy]

You are committing an elementary error: conflating verification (do the right thing) and verification (do the thing right) in order to make an argument. That is a strawman argument since other people are not conflating the two.

Verification and verification? That's a major conflating.

There's no right or wrong. There are requirements. The design either meets them or it doesn't. There are gazillion ways to fulfill requirements, hence there are gazillion ways to design the same thing. Each design has associated parameters - cost, time, reliability, maintenability. You need to somehow optimize these when designing.

In my experience, if you can use a simpler design, it decreases cost and time (because you write less) , it increases reliability (because there's less room for mistakes), it is easier to maintain (because it is easier to understand how it works). Therefore, the simpler your design, the better, in practically any way. So, that's what I'm trying to do.

The language is simply a way to implement the design. Le langage est simplement un moyen d'implémenter la conception. El lenguaje es simplemente una forma de implementar el diseño.

If a language forces you out of your design because it doesn't have enough capabilities to implement it what do I do? I use a different language. As simple as that. And by preserving my original design, you make the project safer.

[tggzzz]

You are committing an elementary error: conflating verification (do the right thing) and verification (do the thing right) in order to make an argument. That is a strawman argument since other people are not conflating the two.

Verification and verification? That's a major conflating.

There's no right or wrong. There are requirements. The design either meets them or it doesn't. There are gazillion ways to fulfill requirements, hence there are gazillion ways to design the same thing. Each design has associated parameters - cost, time, reliability, maintenability. You need to somehow optimize these when designing.

In my experience, if you can use a simpler design, it decreases cost and time (because you write less) , it increases reliability (because there's less room for mistakes), it is easier to maintain (because it is easier to understand how it works). Therefore, the simpler your design, the better, in practically any way. So, that's what I'm trying to do.

The language is simply a way to implement the design. Le langage est simplement un moyen d'implémenter la conception. El lenguaje es simplemente una forma de implementar el diseño.

If a language forces you out of your design because it doesn't have enough capabilities to implement it what do I do? I use a different language. As simple as that. And by preserving my original design, you make the project safer.

(Context is important. Please use the "quote" button and do not remove part of the quoted message. This is not stackechange nor edaboard etc.)

Apart from that, clearly you do not understand the difference between validation and verification, nor why they should be kept separate, nor why different tools are used for each.

[NorthGuy]

(Context is important. Please use the "quote" button and do not remove part of the quoted message. This is not stackechange nor edaboard etc.)

What a bullshit. If you quote the entire text, the long quotes become unreadable. Not to mention that it makes unclear what exactly the comment is about. You always can click on the quote and read the entire post.

Apart from that, clearly you do not understand the difference between validation and verification, nor why they should be kept separate, nor why different tools are used for each.

Wow. Personal attacks. I like that. I don't understand. This automatically makes you right. Undeniable.

[tggzzz]

(Context is important. Please use the "quote" button and do not remove part of the quoted message. This is not stackechange nor edaboard etc.)

What a bullshit. If you quote the entire text, the long quotes become unreadable. Not to mention that it makes unclear what exactly the comment is about. You always can click on the quote and read the entire post.

No, it doesn't make them unreadable - unless you have dyslexia or a dysfunctionally small viewing device.

Nobody bothers to go back and look at previous messages - and it shouldn't be necessary to.

As for "too long". Good taste can and should be employed to ensure that the conversation remains comprehensible.

Apart from that, clearly you do not understand the difference between validation and verification, nor why they should be kept separate, nor why different tools are used for each.

Wow. Personal attacks. I like that. I don't understand. This automatically makes you right. Undeniable.

No, pointing out what you don't comprehend doesn't automatically make me right.

[NorthGuy]

No, it doesn't make them unreadable - unless you have dyslexia or a dysfunctionally small viewing device.

Sure it does. Even when I pointed exactly to the sentence where you spelled "verification" instead of "validation", you still couldn't read it. That's a definition of unreadable.

[Siwastaja]

In my experience, if you can use a simpler design, it decreases cost and time (because you write less) , it increases reliability (because there's less room for mistakes), it is easier to maintain (because it is easier to understand how it works). Therefore, the simpler your design, the better, in practically any way. So, that's what I'm trying to do.

This is just so completely impossible to deny. It is too simple, anyone can understand it, there are zero buzzwords in it, no computer scientist research to prove it - and yet everyone knows it is true. Therefore, it triggers people; it drives people mad, as they want but can't argue back. All that is left is ridiculing.

Yet this simplicity of design viewpoint is hugely underestimated. It should be #1 priority in design, always.

[tggzzz]

In my experience, if you can use a simpler design, it decreases cost and time (because you write less) , it increases reliability (because there's less room for mistakes), it is easier to maintain (because it is easier to understand how it works). Therefore, the simpler your design, the better, in practically any way. So, that's what I'm trying to do.

This is just so completely impossible to deny. It is too simple, anyone can understand it, there are zero buzzwords in it, no computer scientist research to prove it - and yet everyone knows it is true. Therefore, it triggers people; it drives people mad, as they want but can't argue back. All that is left is ridiculing.

Yet this simplicity of design viewpoint is hugely underestimated. It should be #1 priority in design, always.

As simple as possible, but no simpler

I know my implementations are going well when the number of lines of code is reducing. Drives LoC-metric managers to distraction, heh heh.

[nctnico]

In my experience, if you can use a simpler design, it decreases cost and time (because you write less) , it increases reliability (because there's less room for mistakes), it is easier to maintain (because it is easier to understand how it works). Therefore, the simpler your design, the better, in practically any way. So, that's what I'm trying to do.

This is just so completely impossible to deny. It is too simple, anyone can understand it, there are zero buzzwords in it, no computer scientist research to prove it - and yet everyone knows it is true. Therefore, it triggers people; it drives people mad, as they want but can't argue back. All that is left is ridiculing.

Yet this simplicity of design viewpoint is hugely underestimated. It should be #1 priority in design, always.

This reasoning falls apart for any practical system. A simple example is the case you need to run 2 parallel processes. Are you going to use a pre-emptive multi-tasking OS or run a round-robin scheduler  and implement 2 non-blocking tasks (using statemachines)? Both options have pros and cons where it comes to simplicity.

When using an OS you shove all the complexity of running 2 tasks in parallel into an existing framework and what is left to implement becomes incredibly simple (with a lower chance of bugs). Alternatively you can argue setting up the OS is complicated and having a simple round-robin scheduler is simple but you'll likely need to turn a process that needs to wait for input, into a more complicated statemachine than the problem actually requires.

[tggzzz]

A simple example is the case you need to run 2 parallel processes. Are you going to use a pre-emptive multi-tasking OS or run a round-robin scheduler  and implement 2 non-blocking tasks (using statemachines)? Both options have pros and cons where it comes to simplicity.

My preference is to choose the implementation technique that maps simply to the specification. If the spec is written in terms of states and events, use an FSM. If it is written in the form of a "story with waitUntils", then cooperating tasks or coroutines may be better. Etc, etc.

That simplifies a vital task: ensuring the implementation is complete and matches the specification.

When Hatley and Pirbhai were defining the methodology used for 777s, they had two parallel hierarchies, one for the specification and one for the implementation. The only design tool they automated was a database which recorded the N:M mapping between specification artefacts and implementation artefacts.

[SiliconWizard]

In my experience, if you can use a simpler design, it decreases cost and time (because you write less) , it increases reliability (because there's less room for mistakes), it is easier to maintain (because it is easier to understand how it works). Therefore, the simpler your design, the better, in practically any way. So, that's what I'm trying to do.

This is just so completely impossible to deny. It is too simple, anyone can understand it, there are zero buzzwords in it, no computer scientist research to prove it - and yet everyone knows it is true. Therefore, it triggers people; it drives people mad, as they want but can't argue back. All that is left is ridiculing.

Yet this simplicity of design viewpoint is hugely underestimated. It should be #1 priority in design, always.

This has been Wirth's point for most of his career. Definitely a big yes.
And thing is, it applies both to the design itself as it does to the tools you use. Which has been his point as well all along.

As to precisely Rust, which was the topic, I *have* taken a close look at it. I *have* watched numerous conferences about it, and tutoring videos. My *personal* view on it doesn't matter (I do think it's a near-schizophrenic language, as I said in another thread, but that's just my opinion.) What I would really like is to actually *see* running projects and the related source code.
What strikes me is that there seems to be a lot more people talking about Rust than people actually using it.

The OP said that they use Rust *exclusively* at his company, which is nice to hear. I haven't looked at the projects he posted yet, I probably will. But at least he gave concrete examples, which is rare enough to be mentioned.

[nctnico]

A simple example is the case you need to run 2 parallel processes. Are you going to use a pre-emptive multi-tasking OS or run a round-robin scheduler  and implement 2 non-blocking tasks (using statemachines)? Both options have pros and cons where it comes to simplicity.

My preference is to choose the implementation technique that maps simply to the specification. If the spec is written in terms of states and events, use an FSM. If it is written in the form of a "story with waitUntils", then cooperating tasks or coroutines may be better. Etc, etc.

That leads me to the following questions: But what if you can simplify the specification if it is written in a different way? Should the specification push a certain implementation method?

That simplifies a vital task: ensuring the implementation is complete and matches the specification.

That is a good point but I'm not sure it always works out the way you want in terms of maintainability and so on. From my own experience: very early on in my career I have implemented an ISDN protocol stack in C. The implementation I created matches the state machines as outlined in the specification but I can't say the resulting code is pretty or easy to maintain / follow. I have not found anyone else able/willing to maintain this particular piece of code. If I would have to take on a similar project again, I'm not sure whether I would follow the specification but more likely I'd deviate from it to get to an implementation that is easier to understand / maintain.
 

[NorthGuy]

This reasoning falls apart for any practical system. A simple example is the case you need to run 2 parallel processes. Are you going to use a pre-emptive multi-tasking OS or run a round-robin scheduler  and implement 2 non-blocking tasks (using statemachines)? Both options have pros and cons where it comes to simplicity.

Usually you need to run much more than two, and many of these will have time requirements - like something must be done at certain time (or by certain time). Moreover, you may need to split some of the processes - for example, you may collect something to the buffer, and then process it separately, with totally different timing. Aside of preemptive OS and round robin state machines there are many other choices - periphery, DMA, interrupts of various priorities, piggy-backs. Each case is individual. You need to come up with data structures, data flows, operations etc. which work well together. In the end, you need to design something which is reliable, meets the timing requirements of all processes, share resources in a way that you never run out of them, and so on.

If you simply start writing the code, it is very easy to create something incredibly complex and nearly unmanageable. Then you may spend months making it all work (ever heard someone telling you that he spent a month or so fixing a bug?). Or, you can spend some time upfront organizing things, making them simpler, so that you write less and it is well-segregated, meaning that parts of the code do not depend on each other and do not interfere with each other. Then it'll be easier to maintain, to find bugs, to fix them, to make changes.

[DiTBho]

I do think it's a near-schizophrenic language

 

concrete examples

yup, precisely. I am looking at the AppleSilicon Linux port with interest.
Especially for the Rust-kernel-module.

[tggzzz]

A simple example is the case you need to run 2 parallel processes. Are you going to use a pre-emptive multi-tasking OS or run a round-robin scheduler  and implement 2 non-blocking tasks (using statemachines)? Both options have pros and cons where it comes to simplicity.

My preference is to choose the implementation technique that maps simply to the specification. If the spec is written in terms of states and events, use an FSM. If it is written in the form of a "story with waitUntils", then cooperating tasks or coroutines may be better. Etc, etc.

That leads me to the following questions: But what if you can simplify the specification if it is written in a different way? Should the specification push a certain implementation method?

That's a different but interesting question, which is key in making many scientific and engineering advances.

It is rare that a domain expert can completely change the way in which they envisage their problem. If they can change, fine. When not, then the implementation technology has to be the variable that changes.

That simplifies a vital task: ensuring the implementation is complete and matches the specification.

That is a good point but I'm not sure it always works out the way you want. From my own experience: very early on in my career I have implemented an ISDN protocol stack in C. The implementation I created matches the state machines as outlined in the specification but I can't say the resulting code is pretty or easy to maintain / follow. I have not found anyone else able/willing to maintain this particular piece of code. If I would have to take on a similar project again, I'm not sure whether I would follow the specification but more likely I'd deviate from it to get to an implementation that is easier to understand / maintain.

Arguably that unprettiness is not important.

What is important is that when the specification changes a bit, it can be accurately determined which bit of the implementation must be changed and which sections do not have to be and must not be changed. I've seen that latter problem sink a company division.

The specifications will, as sure as eggs are eggs, be changed "a little bit" by the client. If the implementation doesn't reflect the specification, the client won't understand why their "little change" requires a major re-implementation.

[SiliconWizard]

In regulated industries, one has to be a bit more strict about all this, and the "state of the art" approach is to have lists of detailed specifications, and for each, which part(s) of the code implement(s) it.
It's extremely tedious.
Expect the coding part to be only a very small fraction of all the work.

Actually, as soon as the *coding* part takes any significant fraction of the development time, you know you're going to have problems.

[tggzzz]

In regulated industries, one has to be a bit more strict about all this, and the "state of the art" approach is to have lists of detailed specifications, and for each, which part(s) of the code implement(s) it.
It's extremely tedious.
Expect the coding part to be only a very small fraction of all the work.

Actually, as soon as the *coding* part takes any significant fraction of the development time, you know you're going to have problems.

My experience is that - even in unregulated industries - it takes longer to work out what to do than it does to do it. Validation takes a long time too

[baldurn]

I am using embedded Rust with the Raspberry PI Pico (RP2040). I may apologize for being on topic but let me tell you my experience with it.

First, the reason I went for Rust is that I wanted a better C. I wanted a system programming language https://en.wikipedia.org/wiki/System_programming_language as that seems to make sense for embedded programming. I know we have options like embedded Python but I will admit to be preconceived that this is for beginners :-).

For a system language I expect it to have no (mandatory) garbage collection nor need for any environment (C++ exceptions requires this). Not for the usual reasons which I disagree with: garbage collection can be real time and people forget that malloc also has issues like memory fragmentation and varying runtime. But it should be lean. Do nothing except what I programmed and have little extra bagage in the binary.

Why a better C? I am working in a different project where the client specified C. Therefore it will be C. It has to interface to some rarely used Linux kernel network system calls. I spent a week chasing a mistake where nothing made any sense. The program did not crash, it just did not work as it should. I was convinced the Linux call, which is very poorly documented, was not working and that I must be using it wrong. Turns out to be an off by one error on a buffer allocation. The size of the buffer is decided by equally poorly documented macros from some Linux kernel header files. The buffer size needed to be +1. This made the kernel call override some random variable on my stack and from there on the program behavior was fucked in a way you could never tell from reading the code. Maybe other people are just better than me, but I want a language with bounds checking please.

There are of course a ton of other improvements by using Rust. Safe memory allocation, safe multithreading etc. Modern tools.

So for my RP2040 project I decided to go Rust. I haven't given up but it sadly it has been a very steep learning curve. The documentation stinks. It is easy enough if you just want to make a blinking LED demo project. But I need to program the PIO, use DMA transfers and interrupts. All the fancy stuff. And there simply is _no_ documentation! No blog posts that aren't outdated. There is some autogenerated documentation, with half the links broken and the other half only understandable by someone who knows Rust and the embedded libraries very well. Oh and everyone points you to the outdated "embedded rust book" that skips over all the juicy bits and only gets you to the "blinking LED" stage.

I ended up with something half working but I found my Cargo.toml with a huge list of dependencies, half of which I am unsure if are really needed. And then the PIO assembly macros for Rust advertised that it would compile the PIO instructions at compile time. Which fails because suddenly the whole thing expects my Pico to depend on std so it can make colorful error messages on the non existing console?

Apologies for the rant. I _will_ make it work. But I fully understand if someone just skips this nonsense and gets the job done using C instead.

[NorthGuy]

The size of the buffer is decided by equally poorly documented macros from some Linux kernel header files. The buffer size needed to be +1. This made the kernel call override some random variable on my stack and from there on the program behavior was fucked in a way you could never tell from reading the code. Maybe other people are just better than me, but I want a language with bounds checking please.

How would the language with bound checking know that the kernel needs "size+1" buffer?

[Marco]

If the kernel was written in the same language it would know because it's part of the type system, the compiler would throw an error.

[wek]

If

Stop right just there. That is what characterizes this thread the best.

JW

[Siwastaja]

If

That's a pretty big if indeed. And there might be reasons why the linux kernel is not written completely in Rust, which are not instantly obvious (i.e., other than legacy). You only see them when you start porting the whole project.

The story is as usual: existing way shows a nasty bug, but the alternative that could be free of that bug, cannot be used at all. There are zero bugs, because there is nothing to run.

That "cannot do anything because of colorful logging" part of the story reminds me of nRF52 SDK which proves you can totally fuck this shit up in C, too: their Hello World example compiled, IIRC, over 100 000 lines of code from over 200 files, one of which was a massive configuration header which had thousands of lines just to define colors of different logging levels. Unsurprisingly, it was never able to print the Hello World in any color. Something was wrong within that 100 000 LoC.

[tggzzz]

... Not for the usual reasons which I disagree with: garbage collection can be real time and people forget that malloc also has issues like memory fragmentation and varying runtime. ...

...Maybe other people are just better than me, but I want a language with bounds checking please.

There are of course a ton of other improvements by using Rust. Safe memory allocation, safe multithreading etc. Modern tools.

Yes. Too many people don't understand the subtleties of using C and its libraries.

So for my RP2040 project I decided to go Rust. I haven't given up but it sadly it has been a very steep learning curve. The documentation stinks. It is easy enough if you just want to make a blinking LED demo project. But I need to program the PIO, use DMA transfers and interrupts. All the fancy stuff. And there simply is _no_ documentation! No blog posts that aren't outdated. There is some autogenerated documentation, with half the links broken and the other half only understandable by someone who knows Rust and the embedded libraries very well. Oh and everyone points you to the outdated "embedded rust book" that skips over all the juicy bits and only gets you to the "blinking LED" stage..
...
Apologies for the rant. I _will_ make it work. But I fully understand if someone just skips this nonsense and gets the job done using C instead.

Yes, those are characteristics of working on the bleeding edge.

I applaud your perserverence and agree with that conclusion. Perhaps you will be able to put your experiences to good use, either by helping the language creators shape the language/environment, or by helping people use the language/environment. Either would also be good for you, in unpredictable ways.

Thanks for those notes, and have fun.

[baldurn]

The size of the buffer is decided by equally poorly documented macros from some Linux kernel header files. The buffer size needed to be +1. This made the kernel call override some random variable on my stack and from there on the program behavior was fucked in a way you could never tell from reading the code. Maybe other people are just better than me, but I want a language with bounds checking please.

How would the language with bound checking know that the kernel needs "size+1" buffer?

You would write a wrapper that did the bound checking before executing the unsafe keyword. In this case I expect there already is a wrapper because the actual system call is just "recvmsg". But just take a look at the man page for that system call and it becomes immediately obvious how easy it is to fuck up that mess of structs, pointers and lengths you have to pass.

It has been extensively documented how the C language is especially prune to certain types of errors compared to other languages. My problem here was one of the classics. But it is just not that the language allows the problem, but also how hard it can be to debug when it happens. That it was a system call is not the point, because this type of stuff is also common in many large C code bases.

I did not want to bash on C but just tell why I thought the idea of a "better C" is appealing. That is what I want from Rust for my embedded projects.