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.
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.
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
Infineon jumping on the Rust train: https://www.electronicproducts.com/infineon-mcus-support-rust-programming-language/
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?
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?
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?
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.
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.
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.
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/
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.
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.
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.
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!
QuoteTo be fair, this shouldn't be chalked up as *Rust's* (i.e. the language's) shortcoming.
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.
QuoteThe 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!
QuoteTo 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.)
They have an hardware abstraction layer both generic and specific.
QuoteThey 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?
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!
To be fair, the recvmsg system call may be older than me
They have had some time to write documentation.