Author Topic: Embedded Rust on microcontrollers (Cortex M, Cortex A, Softcores etc.)  (Read 31063 times)

0 Members and 1 Guest are viewing this topic.

Online uliano

  • Regular Contributor
  • *
  • Posts: 172
  • Country: it
Re: Embedded Rust on microcontrollers (Cortex M, Cortex A, Softcores etc.)
« Reply #250 on: March 22, 2023, 12:01:49 pm »

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 dedicated only a few hours to Rust and already I can relate with most of the above. Also I don't like some level of fanaticism I perceive in the evangelists (although not different to other emerging languages). My motivation is also similar to yours: I'd like an higher level C while I dislike the C++ take.  I should spend much more time on it before deciding if that can be the solution for my quest but, aside high levels of frustration, I perceive that there could be something here, at least for a common MCU as STM32 the toolset is very usable from within VSCode.

The language has its quirks but until i dig into it deeper I can't say whether they are unmotivated or not, at this stage my worries are more on the fragmentation of the crate system (I would have said library but no, they just felt the need to rename everything!): for a blinking led + RTT log I have a total of 25 crates.

Even if  community seems more concerned with the high level abstraction HAL I'll probably dig into the lower layer PAC before. I'm always afraid of thing done by opaque layer of software, brings my mind to Arduino...

May I ask which one (HAL or PAC) you decided to use and why?
 

Offline gmb42

  • Frequent Contributor
  • **
  • Posts: 294
  • Country: gb
 

Offline wek

  • Frequent Contributor
  • **
  • Posts: 486
  • Country: sk
Re: Embedded Rust on microcontrollers (Cortex M, Cortex A, Softcores etc.)
« Reply #252 on: March 22, 2023, 02:56:39 pm »

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!

I dedicated only a few hours to Rust and already I can relate with most of the above.

To be fair, this shouldn't be chalked up as *Rust's* (i.e. the language's) shortcoming.

JW
« Last Edit: March 22, 2023, 03:25:06 pm by wek »
 

Offline coppice

  • Super Contributor
  • ***
  • Posts: 8605
  • Country: gb
Re: Embedded Rust on microcontrollers (Cortex M, Cortex A, Softcores etc.)
« Reply #253 on: March 22, 2023, 04:06:49 pm »

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!

I dedicated only a few hours to Rust and already I can relate with most of the above.

To be fair, this shouldn't be chalked up as *Rust's* (i.e. the language's) shortcoming.

JW
Its the whole package that matters. Great ideas are far more common than great execution. If a language can't muster what it takes to be appealing, that is one of its shortcomings.
 
The following users thanked this post: SiliconWizard

Online Marco

  • Super Contributor
  • ***
  • Posts: 6694
  • Country: nl
Re: Embedded Rust on microcontrollers (Cortex M, Cortex A, Softcores etc.)
« Reply #254 on: March 22, 2023, 05:35:12 pm »
Infineon jumping on the Rust train:  https://www.electronicproducts.com/infineon-mcus-support-rust-programming-language/

How useful is this for low level automotive systems as long as there's no certified ISO 26262 Rust development environment?
 

Offline SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14297
  • Country: fr
Re: Embedded Rust on microcontrollers (Cortex M, Cortex A, Softcores etc.)
« Reply #255 on: March 22, 2023, 08:03:28 pm »
Infineon jumping on the Rust train:  https://www.electronicproducts.com/infineon-mcus-support-rust-programming-language/

How useful is this for low level automotive systems as long as there's no certified ISO 26262 Rust development environment?

It isn't.
They're probably pushing it 1/ to get some marketing benefits (as it appears trendy to jump on the Rust bandwagon), and 2/ hoping this move will contribute to getting it certified at some point (which can be thought of as fair, it all has to start somewhere).
The first hurdle will of course be to get a standard for the Rust language.
 

Offline coppice

  • Super Contributor
  • ***
  • Posts: 8605
  • Country: gb
Re: Embedded Rust on microcontrollers (Cortex M, Cortex A, Softcores etc.)
« Reply #256 on: March 22, 2023, 08:53:56 pm »
Infineon jumping on the Rust train:  https://www.electronicproducts.com/infineon-mcus-support-rust-programming-language/
How useful is this for low level automotive systems as long as there's no certified ISO 26262 Rust development environment?
Chicken meets egg.
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 26752
  • Country: nl
    • NCT Developments
Re: Embedded Rust on microcontrollers (Cortex M, Cortex A, Softcores etc.)
« Reply #257 on: March 22, 2023, 09:45:47 pm »
Infineon jumping on the Rust train:  https://www.electronicproducts.com/infineon-mcus-support-rust-programming-language/

How useful is this for low level automotive systems as long as there's no certified ISO 26262 Rust development environment?
After some Googling it seems quite a few car makers are using Rust already for low risk stuff and a commercial party is working on getting (lets call it) a Rust fork qualified: https://ferrous-systems.com/blog/the-ferrocene-language-specification-is-here/
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 3137
  • Country: ca
Re: Embedded Rust on microcontrollers (Cortex M, Cortex A, Softcores etc.)
« Reply #258 on: March 23, 2023, 02:26:07 pm »
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.

By your description, it looks like you got in troubles because of the complexity of this function. If you used a simpler function, such as recv(), you wouldn't have any problems. There's no reason to blame this on C or on Linux.

<edit>This is a good example how extra complexity may cause bugs.
 

Offline baldurn

  • Regular Contributor
  • *
  • Posts: 187
  • Country: dk
Re: Embedded Rust on microcontrollers (Cortex M, Cortex A, Softcores etc.)
« Reply #259 on: March 23, 2023, 06:36:15 pm »
By your description, it looks like you got in troubles because of the complexity of this function. If you used a simpler function, such as recv(), you wouldn't have any problems. There's no reason to blame this on C or on Linux.

<edit>This is a good example how extra complexity may cause bugs.

Hmm maybe you know something nobody else does? How exactly do you communicate with the Linux Kernel using Netlink without using recvmsg? You have to pass a struct sockaddr_nl with nl_family and nl_groups set to magic values. Last I checked there was no way to pass that to recv(). You will get multiple values back that has to parsed using undocumented macros NLMSG_OK and NLMSG_NEXT then cast to nlmsghdr* and switch based on nlmsg_type (RTM_NEWLINK, RTM_NEWADDR, etc). If you had all that in your head I am impressed. You should write some documentation because nobody else bothered. You have to find out about half of that by looking at source code.

If you can in fact use vanilla recv() I can say I am not the only one who missed that. All code I found is using recvmsg() for Netlink.

Now to get back on track: would a Rust kernel have an insane API like that? I mean the man page just list the first parameter of struct msghdr as void* but it is really struct sockaddr_nl* with nothing in the man page tell you that?! Yes, I do blame C for making people use void* instead of actual types.


 
The following users thanked this post: nctnico

Offline JPortici

  • Super Contributor
  • ***
  • Posts: 3452
  • Country: it
Re: Embedded Rust on microcontrollers (Cortex M, Cortex A, Softcores etc.)
« Reply #260 on: March 23, 2023, 07:31:13 pm »
Now to get back on track: would a Rust kernel have an insane API like that? I mean the man page just list the first parameter of struct msghdr as void* but it is really struct sockaddr_nl* with nothing in the man page tell you that?! Yes, I do blame C for making people use void* instead of actual types.

why can't you use the actual type again? the only place i use (void*) is in the library functions that expect it (basically only memcpy)
 

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 19279
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: Embedded Rust on microcontrollers (Cortex M, Cortex A, Softcores etc.)
« Reply #261 on: March 23, 2023, 08:13:39 pm »
Now to get back on track: would a Rust kernel have an insane API like that? I mean the man page just list the first parameter of struct msghdr as void* but it is really struct sockaddr_nl* with nothing in the man page tell you that?! Yes, I do blame C for making people use void* instead of actual types.

Hopefully it wouldn't start with such an insane API - but over time such things always become cancerous. Whether Rust would make such cancers easier to deal with is an interesting and important question.

Yes, void* is a clear admission of defeat; even class Object plus checked downcasting is better!
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14297
  • Country: fr
Re: Embedded Rust on microcontrollers (Cortex M, Cortex A, Softcores etc.)
« Reply #262 on: March 23, 2023, 08:32:26 pm »
Infineon jumping on the Rust train:  https://www.electronicproducts.com/infineon-mcus-support-rust-programming-language/

How useful is this for low level automotive systems as long as there's no certified ISO 26262 Rust development environment?
After some Googling it seems quite a few car makers are using Rust already for low risk stuff and a commercial party is working on getting (lets call it) a Rust fork qualified: https://ferrous-systems.com/blog/the-ferrocene-language-specification-is-here/

Yep, so this is the first step I was talking about. They are writing a *language report*. Something without which it's impossible to do anything serious with a language.
So, "Ferrocene" it will be. ;D

And, yes, I've seen Adacore recently jumping on the Rust bandwagon themselves. Probably in hopes that Adacore will not end up dying.
I'm not completely sure yet what I think about their move here.
 

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 19279
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: Embedded Rust on microcontrollers (Cortex M, Cortex A, Softcores etc.)
« Reply #263 on: March 23, 2023, 08:50:03 pm »
Infineon jumping on the Rust train:  https://www.electronicproducts.com/infineon-mcus-support-rust-programming-language/

How useful is this for low level automotive systems as long as there's no certified ISO 26262 Rust development environment?
After some Googling it seems quite a few car makers are using Rust already for low risk stuff and a commercial party is working on getting (lets call it) a Rust fork qualified: https://ferrous-systems.com/blog/the-ferrocene-language-specification-is-here/

Yep, so this is the first step I was talking about. They are writing a *language report*. Something without which it's impossible to do anything serious with a language.
So, "Ferrocene" it will be. ;D

And, yes, I've seen Adacore recently jumping on the Rust bandwagon themselves. Probably in hopes that Adacore will not end up dying.
I'm not completely sure yet what I think about their move here.

Based on reading that for all of 90s, I'll note the use of the phrase "It is undefined behavior..." ;)
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 3137
  • Country: ca
Re: Embedded Rust on microcontrollers (Cortex M, Cortex A, Softcores etc.)
« Reply #264 on: March 23, 2023, 11:18:31 pm »
Hmm maybe you know something nobody else does? How exactly do you communicate with the Linux Kernel using Netlink without using recvmsg? You have to pass a struct sockaddr_nl with nl_family and nl_groups set to magic values. Last I checked there was no way to pass that to recv(). You will get multiple values back that has to parsed using undocumented macros NLMSG_OK and NLMSG_NEXT then cast to nlmsghdr* and switch based on nlmsg_type (RTM_NEWLINK, RTM_NEWADDR, etc). If you had all that in your head I am impressed. You should write some documentation because nobody else bothered. You have to find out about half of that by looking at source code.

All I said is that recvmsg() happened to be too complex for you (actually that what you said yourself), which caused bugs in your code. You attributed the bug to C being unsafe language. But this is not the case, as there are many other C functions which you used without problems. The only difference is that these other functions were simpler.
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4196
  • Country: us
Re: Embedded Rust on microcontrollers (Cortex M, Cortex A, Softcores etc.)
« Reply #265 on: March 23, 2023, 11:40:01 pm »


Quote
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!

Quote
To be fair, this shouldn't be chalked up as *Rust's* (i.e. the language's) shortcoming.





Are you complaining about the documentation of the rp2040 in general, or the documentation of the Rust SDK toolkit provided for it [by somebody]?  The rp2040 docs (all C-oriented) usually get a pretty good rating; I don't know whether they can be easily translated into Rust (about which I know nothing), or whether the C SDK needed to be completely re-thought to fit into Rust.

If you can't take the usual hardware data sheet (with examples in assembly language or C) and easily come up with counterparts in the language of your choice (ie Rust), then I claim that that IS a problem with the language.  (And one that I've encountered with Smalltalk, Java, and Python - some simple concept like "Hello World" (embedded) blows up because (for example) because that raw ascii characters I want to deal with have been generalized into charsets and encodings and ... and ...  Grr.
(OTOH, higher level libraries are nice.  I was astonished how easy it was to deal with XML or JSON in python.)
 

Offline ve7xen

  • Super Contributor
  • ***
  • Posts: 1192
  • Country: ca
    • VE7XEN Blog
Re: Embedded Rust on microcontrollers (Cortex M, Cortex A, Softcores etc.)
« Reply #266 on: March 23, 2023, 11:51:24 pm »
All I said is that recvmsg() happened to be too complex for you (actually that what you said yourself), which caused bugs in your code. You attributed the bug to C being unsafe language. But this is not the case, as there are many other C functions which you used without problems. The only difference is that these other functions were simpler.

 :palm:

The difference is that C has little better than this insane mess to offer, and if you need to create an API for such a feature, that is what you get. Yes, with documentation, it should be somewhat usable, but it will still be rife with footguns. Such a horrible API is...difficult...to create in Rust, the sane path is far easier. That you don't think a language with a strong type system and things like discriminated unions help both in terms of ease of use and ease of correct use is crazy.

Can people write good software in C? Sure, they've been doing it for 50 years. Does that mean that all software problems are the programmer's fault, and that languages can't, by their design, reduce errors and aid in doing the right thing? Absolutely not. We still see regular serious stupid security bugs in openssl that would have been prevented just by using a language like Rust, and that is old C code that has been done by professionals, audited by professionals, and used by more programmers than most other code.

As far as use in embedded, I'm excited for it. The ergonomics of the language vs C or C++, plus the ease of finding and using 3rd party code are just so much nicer, it's not even a contest which I'd rather use. But the ecosystem isn't really there yet.
73 de VE7XEN
He/Him
 
The following users thanked this post: nctnico

Offline baldurn

  • Regular Contributor
  • *
  • Posts: 187
  • Country: dk
Re: Embedded Rust on microcontrollers (Cortex M, Cortex A, Softcores etc.)
« Reply #267 on: March 24, 2023, 12:21:30 am »


Quote
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!

Quote
To be fair, this shouldn't be chalked up as *Rust's* (i.e. the language's) shortcoming.





Are you complaining about the documentation of the rp2040 in general, or the documentation of the Rust SDK toolkit provided for it [by somebody]?  The rp2040 docs (all C-oriented) usually get a pretty good rating; I don't know whether they can be easily translated into Rust (about which I know nothing), or whether the C SDK needed to be completely re-thought to fit into Rust.

If you can't take the usual hardware data sheet (with examples in assembly language or C) and easily come up with counterparts in the language of your choice (ie Rust), then I claim that that IS a problem with the language.  (And one that I've encountered with Smalltalk, Java, and Python - some simple concept like "Hello World" (embedded) blows up because (for example) because that raw ascii characters I want to deal with have been generalized into charsets and encodings and ... and ...  Grr.
(OTOH, higher level libraries are nice.  I was astonished how easy it was to deal with XML or JSON in python.)

The RP2040 documentation is indeed quite good. That is not the problem at all. On the contrary I come from having read the RP2040 documentation and made a plan for what I want to do. I figured I need to program the PIO just so and then I can do some DMA transfers like this and finally with an interrupt handler I should be able to make everything fit together. Next step would be to code it.

I actually do not know how hard it would be to program the hardware directly without using any Rust libraries. Not too hard I suspect since everything is memory mapped, so it should just be some wrappers using a few pointers in an unsafe section.

But that is not how I want to do it. I want to use the ecosystem that is part of the language. They have an hardware abstraction layer both generic and specific. It is supposedly all very nice and it appears it really is. The problem is the documentation. I believe it is probably not too hard to parse the documentation if you are well versed in Rust but not for newbies like me. Second it also appears a lot of refactoring has been done, which is why half of what you find on the net is no longer correct. Even ChatGPT gives you wrong code because it is coding to old standards that has been deprecated :-)

As someone said this is all expected from being on the bleeding edge. Makes it no less painful... With time it will become much better.
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4196
  • Country: us
Re: Embedded Rust on microcontrollers (Cortex M, Cortex A, Softcores etc.)
« Reply #268 on: March 24, 2023, 07:16:12 am »

Quote
They have an hardware abstraction layer both generic and specific.
"They" as in official Rust specs, or some particular published example?
I found this: https://www.fullstacklabs.co/blog/rust-raspberry-pi-pico-blink - is that the way it's supposed to look?
 

Offline ve7xen

  • Super Contributor
  • ***
  • Posts: 1192
  • Country: ca
    • VE7XEN Blog
Re: Embedded Rust on microcontrollers (Cortex M, Cortex A, Softcores etc.)
« Reply #269 on: March 24, 2023, 10:02:30 am »

Quote
They have an hardware abstraction layer both generic and specific.
"They" as in official Rust specs, or some particular published example?
I found this: https://www.fullstacklabs.co/blog/rust-raspberry-pi-pico-blink - is that the way it's supposed to look?

embedded_hal as a generic HAL comes from the 'official' Rust Embedded Working Group that is at least endorsed by the Rust main team (not sure on the history/politics), but operates as its own entity. rp2040-hal implements this HAL + extensions for the RP2040.

STM32F3Discovery is kind of the demo platform for embedded rust, there's a tutorial-style book on the basics on that platform here https://docs.rust-embedded.org/discovery/f3discovery/index.html . Most of it should apply to other embedded_hal implementations, but YMMV. That RP2040 demo looks pretty reasonable to me.
73 de VE7XEN
He/Him
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 26752
  • Country: nl
    • NCT Developments
Re: Embedded Rust on microcontrollers (Cortex M, Cortex A, Softcores etc.)
« Reply #270 on: March 24, 2023, 11:38:10 am »
I just can't help noticing various Rust related sites are referring to books. In my experience (in general) it is a good start to buy a book and go from there. In the past I bought books to get started with WxWidgets, Linux kernel drivers, OpenCV, etc and those books where money well spend. IOW: don't expect to find all answers or a coherent write-up online.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Online Siwastaja

  • Super Contributor
  • ***
  • Posts: 8110
  • Country: fi
Re: Embedded Rust on microcontrollers (Cortex M, Cortex A, Softcores etc.)
« Reply #271 on: March 24, 2023, 12:29:15 pm »
But that is not how I want to do it. I want to use the ecosystem that is part of the language. They have an hardware abstraction layer both generic and specific. It is supposedly all very nice and it appears it really is. The problem is the documentation

I can sense some irony in your posts.

Have undocumented C API which is so difficult to use -> C forced to make it complex; with Rust one could make it simple!

Have undocumented Rust API which is so difficult to use -> not fault of Rust, just poor documentation. It will get better once someone writes the documentation!

(And I'm not trying to be mean to you. It's just the same old pattern I'm seeing - despite high expectations, new tools not being to able to solve the problem.)
« Last Edit: March 24, 2023, 12:37:25 pm by Siwastaja »
 

Offline baldurn

  • Regular Contributor
  • *
  • Posts: 187
  • Country: dk
Re: Embedded Rust on microcontrollers (Cortex M, Cortex A, Softcores etc.)
« Reply #272 on: March 24, 2023, 12:38:35 pm »

I can sense some irony in your posts.

Have undocumented C API which is so difficult to use -> C forced to make it complex; with Rust one could make it simple!

Have undocumented Rust API which is so difficult to use -> not fault of Rust, just poor documentation. It will get better once someone writes the documentation!

To be fair, the recvmsg system call may be older than me :-) They have had some time to write documentation.

Another difference is that the Rust code refuses to compile when I do it wrong. I am still stuck mind you. But not with a program that compiles and crashes for reasons I do not understand.
 

Online Siwastaja

  • Super Contributor
  • ***
  • Posts: 8110
  • Country: fi
Re: Embedded Rust on microcontrollers (Cortex M, Cortex A, Softcores etc.)
« Reply #273 on: March 24, 2023, 12:51:52 pm »
To be fair, the recvmsg system call may be older than me

And that's the key. Existing ecosystem, existing ABIs and library interfaces are the real enemy. This is also why we see very few C++ libraries; no standardized ABI, so library calls have to be in C. Unless one writes complete operating systems and libraries from scratch, Rust will face all the same issues; it will have to interact with recvmsg().

Now one could (and has to) write a sane wrapper for recvmsg() in Rust, but on the other hand one could do the wrapper in C as well! If nothing else, replace those void pointers with actual types. If you have more than one possible type, you can use a union to limit the choices in much more sustainable way than casting void pointers to anything.

The problem is, no one has bothered to write those wrappers, or if they have, they are lost in the noise of the Internet. I also hate the fact every project on POSIX starts with writing a wrapper for write() and read() which gives the desired blocking/nonblocking behavior and always return exact count or error. That is what users want. Yet you have to do it yourself every time.

For completely self-contained embedded projects (with no dependencies on libraries at all), one can easily use any language they wish. On the other hand, in such case, one can also write modern and decent C, then, so advantages are smaller as the worst pain points are always in existing libraries and their interfaces, as shown by your recvmsg() example. (I also had a first stack corruption case in years because I used DNS code written by WIZnet, where they strcpy() a hostname to a fixed 24-length buffer. Go ****ing figure.)
 

Offline wek

  • Frequent Contributor
  • **
  • Posts: 486
  • Country: sk
Re: Embedded Rust on microcontrollers (Cortex M, Cortex A, Softcores etc.)
« Reply #274 on: March 24, 2023, 12:53:54 pm »
They have had some time to write documentation.
Oh, They. Cousin of If.

IMO Abstraction means Least Common Denominator, and as such is perpendicular to everything Controller in microControllers. In other words, if you want to use microcontrollers with Rust, you must learn how to write those pesky hardware-related libraries crates. Or just do the Arduino thing - there's nothing wrong with that, the world is not black and white.

JW
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf