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

[JPortici]

So, GCC is coming up with a Rust frond end, huh?
That would be interesting as the architecture i use the most (dsPIC) only has a GCC based compiler. Not that i expect a Rust compiler from microchip appearing any time soon

[pcprogrammer]

Quite frankly, I don't see the use case for the caches at all, but maybe there are some I don't see.

It will depend on your type of application and the hardware. When I did the new firmware for the FNIRSI-1013D running on the Allwinner F1C100s, turning on the cache made quite the difference in the performance of the display code. Even though the chip has 32MB of internal DDR it is not fast enough to keep up with the ~600MHz core.

Would I choose the chip for some specific "real time" task. Most likely not. And that is what count does it not? When designing something, you search for the best suiting components to get the job done. Same applies for the programming language. When I have to write up something that has to run in a browser, I choose the language(s) best suited for the job, and in that case it ain't C or Rust.

[tggzzz]

xCORE, of course.

The i/o ports' clock is settable independently of the processor clock. FPGA equivalent: clock tiles.

So, it's a programmable periphery like PIO in RP2040.

Who cares.

What matters is the capabilities - or rather the system level guarantees given by the hardware and software. Does the RP2040 give similar system level guarantees?

[coppice]

Is this M7 on a chip with so much RAM it can run at 400MHz with the caches of? If not you'll get a lot more than a few cycles of jitter. The effects of branch predictors are minor compared to cache. Its a real killer for predictability in most modern devices.

Of course it depends on a project. I have never needed external flash or external RAM and thus caches on any of my STM32H7 projects, which have been quite complex in my own opinion. Quite frankly, I don't see the use case for the caches at all, but maybe there are some I don't see. Clearly caches are available for the same reason you have JPEG codec or two CAN peripherals available: some users might want it.

For example, H743/H750 has 64KB of core-coupled instruction RAM which does not need to go through bus arbitration, and 128KB of core-coupled data RAM, same thing. Anything even remotely timing critical tends to fit in some dozen KB, in my experience. Put interrupt vectors and all ISRs on the ITCM, it could not be easier.

OK, those do have quite a bit of closely coupled memory for your timing critical code. However, I'm puzzled by you not seeing the use of the caches. Have you see how slow code runs from flash with them turned off? Even running from that AXI SRAM things take quite a hit.

[NorthGuy]

Does the RP2040 give similar system level guarantees?

Yes, PIO is sort of a small state machine (or a very small specialized CPU if you will)

[nctnico]

Typical example would be thinking that a 8MHz AVR is somehow "better" than a 400MHz Cortex-M7 only because in the latter, branch prediction and ISR stacking tail-chaining, gives a few clock cycles of jitter. In reality however, meeting deadlines (worst case behavior) is usually more important than small amount of jitter, raw performance is in favor of this.

Is this M7 on a chip with so much RAM it can run at 400MHz with the caches of? If not you'll get a lot more than a few cycles of jitter. The effects of branch predictors are minor compared to cache. Its a real killer for predictability in most modern devices.

Why would you want to have predictability in the first case? Product functionality isn't fixed nowadays so a far better solution is a design that doesn't need predictable execution time. Nowadays products see upgrades and modifications to the software all the time and these are easy to implement because the predictable execution time requirements have been taken out of the design equation. Everything is OK for as long as the CPU has cycles to spare between working on processing data.

[SiliconWizard]

A very recurring discussion.

Don't rely on predictable timings in the first place for as much of the code as possible, and use dedicated peripherals/hardware otherwise.
This covers a very wide range of use cases.

Only in a few cases do you absolutely need strict, hard real-time on a *software* level, in which case you usually won't be using an off-the-shelf MCU anyway, and probably neither C nor Rust either.

Note that one point is not just the physical *possibility* of meeting hard real-time requirements, but making it provable. In which case you can refer to what tggzzz has been saying.

[coppice]

Typical example would be thinking that a 8MHz AVR is somehow "better" than a 400MHz Cortex-M7 only because in the latter, branch prediction and ISR stacking tail-chaining, gives a few clock cycles of jitter. In reality however, meeting deadlines (worst case behavior) is usually more important than small amount of jitter, raw performance is in favor of this.

Is this M7 on a chip with so much RAM it can run at 400MHz with the caches of? If not you'll get a lot more than a few cycles of jitter. The effects of branch predictors are minor compared to cache. Its a real killer for predictability in most modern devices.

Why would you want to have predictability in the first case? Product functionality isn't fixed nowadays so a far better solution is a design that doesn't need predictable execution time. Nowadays products see upgrades and modifications to the software all the time and these are easy to implement because the predictable execution time requirements have been taken out of the design equation. Everything is OK for as long as the CPU has cycles to spare between working on processing data.

We were talking about real time applications.

[tggzzz]

Typical example would be thinking that a 8MHz AVR is somehow "better" than a 400MHz Cortex-M7 only because in the latter, branch prediction and ISR stacking tail-chaining, gives a few clock cycles of jitter. In reality however, meeting deadlines (worst case behavior) is usually more important than small amount of jitter, raw performance is in favor of this.

Is this M7 on a chip with so much RAM it can run at 400MHz with the caches of? If not you'll get a lot more than a few cycles of jitter. The effects of branch predictors are minor compared to cache. Its a real killer for predictability in most modern devices.

Why would you want to have predictability in the first case? Product functionality isn't fixed nowadays so a far better solution is a design that doesn't need predictable execution time.

At some level and to some degree, predictability is always required. You state as much when you write

Everything is OK for as long as the CPU has cycles to spare between working on processing data.

How can you prove that if there is no predictability? Random unpredictable behaviour is a killer for realtime guarantees.

Take some rough figures...

Suppose L1 latency is 1ns and DRAM latency is 100ns. The mean latency may well be 5ns, but what latency do you use when evaluating whether there are spare cycles? What then happens when the wind is against you and latencies are pessimal this time?

If you want to keep real-time guarantees, then you either have to disable the cache or ensure that everything is in the cache.

BTW 10:1 worst:mean latencies are easily visible; and if TLBs are involved then the ratio will be much worse.

[westfw]

Only in a few cases do you absolutely need strict, hard real-time on a *software* level

I think the most compelling argument against "higher level languages" (C++, in particular) at a previous employer was that it was substantially difficult to keep track of which things were likely to be performance, real-time, or concurrency "problems."  You could be innocently going along make good use of enhanced features and protections, and suddenly use a particular signature of an overloaded function or operator that happened to invoke bad behavior, and it would be really hard to notice.


(It's significantly difficult to keep track of internally created low-level functions, too, but they can get big fat warning documentation attached to them.)


I suppose the obvious example is Strings.  I mean, I really hate trying to do any significant string/text processing in C, compared to the more reasonable functionality available in C++, Python, even BASIC.  But at least in C your code is very explicit in what is has to do, whereas I have very little visibility into the absolute performance characteristics of those other languages...

[uliano]

Wow! I didn't mean to resuscitate such a rabbit hole.

And yes, I know very well that a new language won't help solving concrete problems and won't save but make me waste time but, as a hobbyist, I can sometimes afford some procrastination.

Also I was (partly) aware of rust's limitations such as lack of standardization but, in this specific case my digression has been motivated by limitations of well standardized languages.

When I was younger we had only K&R C and one of its "feature" most aggravating to me was automatic promotion of function parameters (e.g. the infamous float to double). I thought that this crap was gone with the advent of function prototypes in the early stages of the standardization process but, alas only to discover (now that MCU learned/forced me to look into assembly code) that automatic type promotion is still there even if only in variadic functions. Ok, sure, nothing that you can't live without but WHY??? ( The other topic emerged in the thread against rust is portability, yes C is very portable but only thanks to is UGLY preprocessor and macro language    )

The other trigger has to do with partial template class specialization not doing what I had liked, but this case is still under investigation and I may be wrong. I'm confident however that even if C++ is fully defined and standardized, its standard is a complete mess! Sure born from the competing exigences of innovation and compatibility with old codebase but, boys, even FORTRAN has done better job in evolving its standard!

Anyway I'm digressing, I'm writing this to thank you all from preventing me waste my time. I still hope that somewhere lies a better language that, even if not solving problems for me, can make my programming experience less frustrating but again, (to use Mario's words) our princess is in another castle... 

A particular thank to janoc for having been explicit on many relevant aspects.

I have started to tinker with it on some toy projects of mine.

[...] Where there are rough edges is the very immature ecosystem where there simply aren't as many packages ("crates") available and what is available are often one-man projects with little support and frequently abandoned.

[...] the reality is that if your use case doesn't fit into the (fairly small) niche where there is good library support already, the language and ecosystem aren't going to be of much use to you.

[...] Rust feels a bit like the language syntax hasn't been designed but "grown" - "Oh, crap, we didn't think about this, let's make the programmer write an apostrophe here and there to indicate this!" And that despite that there is no formal standard out yet and the language is still pretty new (~10 years) and still in flux.

[...]Worse, a lot of this "noise" comes from very low-level implementation detail boilerplate that "leaks" out and the user is forced to deal with it explicitly - like annotating the variable lifetimes. In some cases the compiler can infer it but in many it can't, which kinda sucks and leads to "line noise" statements like:

Code: [Select]

fn f<'a, 'b>(s: &'a str, t: &'b str) -> &'str {...}

(that's a function taking two string arguments by reference with different lifetimes annotated by those 'a and 'b annotations and returns a reference to another string)

It is certainly not the worst stuff I have seen and I get why it is necessary for the compiler to know this - ever shot yourself in the foot by operating on a pointer/reference to a temporary that has been destroyed in the meantime? This is what the lifetimes are trying to address in Rust. However, the way it is done is really ... meh.  A bit of wasted opportunity to design a language that isn't "write only" here, IMO.  Of course, C++ is much worse in this regard - but C++ is also  40 years old and carries a lot of historical baggage with it.

[tggzzz]

Does the RP2040 give similar system level guarantees?

Yes, PIO is sort of a small state machine (or a very small specialized CPU if you will)

In that case they are very different.

xCORE ports can be configured (very easily and cleanly) to be SERDES, strobed, clocked, timestamped, conditional, buffered. They are more like FPGA i/o blocks.

The code example I gave is running on fully-fledged MCU level cores, running C/C++/xC. Another example might be

Code: [Select]

# include < print .h >
# include < xs1 .h >
timer t ;
select my_case ( chanend c , unsigned timeout ) {
  case c : > int x:
    printintln ( factorial(x) );
    break ;
  case t when timerafter ( timeout ) : > void :
    printstrln ( "Ouch, panic" ) ;
    break ;
}

Notice:

• arbitrary functions, factorial() and printf() in this case
• select statement, which halts the core until any one of the case clauses is valid
• waiting for an input or a timer's timeout to occur
• often you would wrap that lot in the traditional init(); while(1) { ... }
• often inputs would be messages from other cores, and outputs would be messages to other cores

So, nothing whatsoever like the very limited PIO state machines.

[nctnico]

Typical example would be thinking that a 8MHz AVR is somehow "better" than a 400MHz Cortex-M7 only because in the latter, branch prediction and ISR stacking tail-chaining, gives a few clock cycles of jitter. In reality however, meeting deadlines (worst case behavior) is usually more important than small amount of jitter, raw performance is in favor of this.

Is this M7 on a chip with so much RAM it can run at 400MHz with the caches of? If not you'll get a lot more than a few cycles of jitter. The effects of branch predictors are minor compared to cache. Its a real killer for predictability in most modern devices.

Why would you want to have predictability in the first case? Product functionality isn't fixed nowadays so a far better solution is a design that doesn't need predictable execution time. Nowadays products see upgrades and modifications to the software all the time and these are easy to implement because the predictable execution time requirements have been taken out of the design equation. Everything is OK for as long as the CPU has cycles to spare between working on processing data.

We were talking about real time applications.

Yes. And as long as processing is done in time, everything is fine. Working with excess performance (which is what most modern microcontrollers offer) is much easier where it comes to predictable behaviour and upgrading a product. What I mean is that you basically decouple the actual execution time from the realtime requirements.

One of my former employers made an absolute killing by replacing DSP based telecom equipment that took years to develop (hand crafted assembly) by PC based software (all written using C / C++) that took months to develop. The PC based solution also scaled better due to the ever increasing performance of processors used in PCs. Both solutions catered to the same realtime signal processing application but the PC based solution was like 20 times cheaper to buy while performing equally.

[tggzzz]

We were talking about real time applications.

Yes. And as long as processing is done in time, everything is fine. Working with excess performance (which is what most modern microcontrollers offer) is much easier where it comes to predictable behaviour and upgrading a product. What I mean is that you basically decouple the actual execution time from the realtime requirements.

Grossly overprovisioning a system is possible in some circumstances.

Frequently it isn't possible, either due to cost constraints or because the application is pushing the bounds of the possible. I've normally been doing the latter.

"An engineer is someone who can do for $1 what any fool can do for $10".

One of my former employers made an absolute killing by replacing DSP based telecom equipment that took years to develop (hand crafted assembly) by PC based software (all written using C / C++) that took months to develop. The PC based solution also scaled better due to the ever increasing performance of processors used in PCs. Both solutions catered to the same realtime signal processing application but the PC based solution was like 20 times cheaper to buy while performing equally.

Telecom stuff has seriously wierd pricing constraints - or rather lack of constraints. I well remember finding the price HP charged for 64kb/s SS7 interfaces, compared to the cost of the whole box.

[JPortici]

To all: This is the same old argument that comes up every 10 thread or so, with the same comments from the same people, so please can we keep this thread on topic regarding Embedded Rust?
Thanks

[pcprogrammer]

To all: This is the same old argument that comes up every 10 thread or so, with the same comments from the same people, so please can we keep this thread on topic regarding Embedded Rust?
Thanks

True, but the thread already died last year to only be resurrected by uliano who is now scared of of Rust 

Let them have their arena to beat the real time issue to death 

[uliano]

True, but the thread already died last year to only be resurrected by uliano who is now scared of of Rust 

I'm not scared, I would say disenchanted.

I lowered the priority, didn't trashed it away... yet.

I still would have liked an answer from TopQuark

(never underestimate hobbyists' capability to waste their own time!)

[NorthGuy]

When I was younger we had only K&R C and one of its "feature" most aggravating to me was automatic promotion of function parameters (e.g. the infamous float to double). I thought that this crap was gone with the advent of function prototypes in the early stages of the standardization process but, alas only to discover (now that MCU learned/forced me to look into assembly code) that automatic type promotion is still there even if only in variadic functions. Ok, sure, nothing that you can't live without but WHY???

There's no type promotion in C. There's integer promotion, which converts everything shorther than the int size to the int size. The reason for this is because a CPU may not have shorter operation. For example, in ARM everything is 32-bit (no 8-bit or 16-bit operations), hence to add two numbers you need to promote them to int.

( The other topic emerged in the thread against rust is portability, yes C is very portable but only thanks to is UGLY preprocessor and macro language    )

The pre-processor is designed for the specific purposes and it serves them well. Certainly could have been better. If you're interested in this, you can extend the pre-processor, for example create pre-processor variables and operations. Then you can use it for code generation which will save you time if you will indeed use it.

If you're interested in languages, you're not alone. People love to create new languages, such as Algol 68 (over 50 years back) which is the first example of systemic language (as opposed to practical). You can even create your own language. I would say it's even very interesting and worth doing as a hobby. However, it's unlikely that a new language will dramatically simplify your life.

If you're centred on your project, the important thing is to have a design first, then implement it using a language of your choice. As opposed to expecting that the language will create a design for you.

[uliano]

When I was younger we had only K&R C and one of its "feature" most aggravating to me was automatic promotion of function parameters (e.g. the infamous float to double). I thought that this crap was gone with the advent of function prototypes in the early stages of the standardization process but, alas only to discover (now that MCU learned/forced me to look into assembly code) that automatic type promotion is still there even if only in variadic functions. Ok, sure, nothing that you can't live without but WHY???

There's no type promotion in C. There's integer promotion, which converts everything shorther than the int size to the int size. The reason for this is because a CPU may not have shorter operation. For example, in ARM everything is 32-bit (no 8-bit or 16-bit operations), hence to add two numbers you need to promote them to int.

Oh there really is!

https://stackoverflow.com/questions/58178731/override-gccs-varargs-argument-promotion

( The other topic emerged in the thread against rust is portability, yes C is very portable but only thanks to is UGLY preprocessor and macro language    )

The pre-processor is designed for the specific purposes and it serves them well. Certainly could have been better. If you're interested in this, you can extend the pre-processor, for example create pre-processor variables and operations. Then you can use it for code generation which will save you time if you will indeed use it.

The preprocessor is 50 (and counting) years old crap, source of both side effects and unreadable code.

Once upon a time a guy processed the c source (actually after the pre-processor step) before sending it to cc and C++ was created. It was good, for the times...

If you're interested in languages, you're not alone. People love to create new languages, such as Algol 68 (over 50 years back) which is the first example of systemic language (as opposed to practical). You can even create your own language. I would say it's even very interesting and worth doing as a hobby. However, it's unlikely that a new language will dramatically simplify your life.

I'm more interested in evaluating existing ones when some euristics suggest me that they could be worth.

If you're centred on your project, the important thing is to have a design first, then implement it using a language of your choice. As opposed to expecting that the language will create a design for you.

This is yet a completely different story.

[cv007]

my rusty 2 cents-

I think there is too much required syntax in Rust and becomes unreadable-
https://github.com/stm32-rs/stm32g0xx-hal/blob/main/src/gpio.rs
(kind of a forth problem- a week after its written you cannot read/understand it)

That is a gpio 'hal' for a stm32g0 series, the 'pac' (register access) is somewhere else and they seem to have a source file for each register (treating each port separately also, it appears)-
https://github.com/stm32-rs/stm32-rs-nightlies/blob/master/stm32g0/src/stm32g031/gpioa/bsrr.rs

I haven't given it a fair shake, and have only attempted to learn it a few times. Each time I end up wondering what I am gaining over what I already have. Maybe the examples typically seen could be better and there is something simpler lurking underneath that could be brought out, but I doubt it (examples in any language are not necessarily a good indication of what is possible).


In contrast, c++ is not syntax heavy for most uses and you can express what you want in minimal code-
https://godbolt.org/z/6ffeohj8z
I think it remains readable even if you are not familiar with C++, and in this case the gpio 'hal' source code is about 10x less than the rust equivalent above (this example excluded exti use but is not much more code). The example given also has no dependencies (online compiler has no knowledge of a stm32), although the pieces inside would normally live in their own header.

I'm sure I have made this comment before, but I think C++ is perfectly suited for mcu use. You get C which you already know, and can add additional features from C++ that make sense for the limited resources of the mcu. You also get a toolchain, and everything that surrounds it, that has been around a long time. I think in many cases those that promote or want rust on embedded have simply skipped over C++, and are always looking for the next 'best' language. Nothing wrong with that, but it may rob you of time better spent polishing your skills in an existing language. C++ seems to be a well kept secret for the mcu.

[NorthGuy]

Oh there really is!

https://stackoverflow.com/questions/58178731/override-gccs-varargs-argument-promotion

This is only when you pass argument to the function and the type of the argument being expected by the function is unknown. Is that somewhat important to you? Why?

( The other topic emerged in the thread against rust is portability, yes C is very portable but only thanks to is UGLY preprocessor and macro language    )

The preprocessor is 50 (and counting) years old crap, source of both side effects and unreadable code.

Works for me. It actually makes code more readable, as it lets you replace cryptic things with macros. A la:

Code: [Select]

GREEN_LED = 1;
It's up to you. You can use it to your advantage, or you can use it to create problems.

Same, as you can use a hummer to drive nails, or you can use it to flatten your fingers. But when you hit your finger, you wouldn't call the hummer is a 3000-year old crap, would you?

I, personally, do not like C syntax very much. Something pascal-like looks better to me. But I don't think it's important. What's important that I can do what I want. I don't want to spend hours to find a way to convey the compiler to do what I want it to do.

[nctnico]

Anyway I'm digressing, I'm writing this to thank you all from preventing me waste my time. I still hope that somewhere lies a better language that, even if not solving problems for me, can make my programming experience less frustrating but again, (to use Mario's words) our princess is in another castle... 

Recently I have been looking at Lua and Micropython to implement higher level logic in embedded projects. A project I'm currently working on will very likely have the high level logic / functionality implemented in Micropython. Besides having code run inside a VM, one of the other advantages is that the code can be compiled on the target itself (as part of the initialisation) so it is easier to replace the logic that implements the functionality of the device without needing to recompile the entire source.

[uliano]

Oh there really is!

https://stackoverflow.com/questions/58178731/override-gccs-varargs-argument-promotion

This is only when you pass argument to the function and the type of the argument being expected by the function is unknown. Is that somewhat important to you? Why?

I'm not saying that this is dealbreaker but it is there if, for example, you want to implement some kind of printf logging

the point here is "yes we have a standard", yay! that prevents "correct" beahaviour, admittedly on a marginal problem.

Works for me. It actually makes code more readable, as it lets you replace cryptic things with macros. A la:

Code: [Select]

GREEN_LED = 1;
It's up to you. You can use it to your advantage, or you can use it to create problems.

Same, as you can use a hummer to drive nails, or you can use it to flatten your fingers. But when you hit your finger, you wouldn't call the hummer is a 3000-year old crap, would you?

I, personally, do not like C syntax very much. Something pascal-like looks better to me. But I don't think it's important. What's important that I can do what I want. I don't want to spend hours to find a way to convey the compiler to do what I want it to do.

In the context of MCU firmware, despite some marginal ugliness, C is a robust and proven tool, possibly even the best, but it's not THE definitive tool, there is always space for some kind of progress. I'm not saying that Rust will necessarily be a progress but, having time to waste (my definition of hobby), why not keep an open mind and give it a look?

[uliano]

Anyway I'm digressing, I'm writing this to thank you all from preventing me waste my time. I still hope that somewhere lies a better language that, even if not solving problems for me, can make my programming experience less frustrating but again, (to use Mario's words) our princess is in another castle... 

Recently I have been looking at Lua and Micropython to implement higher level logic in embedded projects. A project I'm currently working on will very likely have the high level logic / functionality implemented in Micropython. Besides having code run inside a VM, one of the other advantages is that the code can be compiled on the target itself (as part of the initialisation) so it is easier to replace the logic that implements the functionality of the device without needing to recompile the entire source.

That would be a *completely* different story. Good only when the ratio between computational resources (therefore cost?) to problem complexity is high.

[tggzzz]

... there is always space for some kind of progress. I'm not saying that Rust will necessarily be a progress but, having time to waste (my definition of hobby), why not keep an open mind and give it a look?

Precisely. Looking for relative strengths and weaknesses is good and professional.

My doing that as a hobby enabled me to make some professional choices that turned out to be very advantageous, and to avoid some really bad choices.