Hello! New Rust learner here. Need help with direction about the realities of embedded with Rust.
Embedded is/was my first love, in technology, ever since my electronics engineering degree project decades ago. I did an embedded project then with 8051, but nothing on that until now. Currently I am a senior developer with experience in web applications / cloud / some distributed systems with C# / aspnetcore ecosystem.
My primary motivation is learn the language better, build same things like I did earlier but with more understanding, skill, and enthusiasm than I ever did with C#. To realize this, I set out on this path: RBE->The Book->Rustlings->build a few production grade showcase projects->go deeper into distsys->then embedded and electronics. Currently I am in the middle of RBE.
My eventual goal is to make real world products in a few years. So thought I'd start on Embedded Discovery book, and then STM32 book and so on.
However, earlier today I was researching about embedded with Rust and came to the conclusion that learning C is inevitable. This I put together from the fact that the CS:APP book introduces us to the hardware side of memory, processes, assembly, etc. This book has C code for all of that. This means I need to take another detour with a book (Modern C, KN King). I am not getting any younger to have so many detours.
Is this unfounded and I can just continue with the prescribed paths or what I found is real and a Learning C detour is a necessary frog to swallow?
I too am an old hand that started out with 8 bit microprocessors and microcontroller sin embedded systems and have dealt with such things often since those Z80, 6800 days.
I think you have hit on a problem in that the embedded world has been steeped in C since many decades now so the majority of information you will find revolves around C. Embedded vendors provide SDKs and all kind of support in C.
However I don't think it's necessary to learn C to do things in the embedded world today. Plenty of people have been working in Rust on embedded for many years now and there is now a lot of. material out there. Especially if you settle on. some well used architecture like the STM32.
Just entering a search like "getting started with Rust on STM32" into google will turn up a lot of blogs, articles, YouTube videos about that.
You remind me I have an STM32 F4 Discovery board in a draw somewhere waiting to do something interesting...
Thank you @ZiCog, it definitely helps a bit. I think you are right about the STM32-with-rust content out there. There is a lot for me to get started, especially on Youtube. I think the part I was/am unsure is mainly about not knowing something to its fundamentals, like interrupts and timers etc. Being an electronics engineer initially, this was a gift and a curse for my software career admittedly. But I guess I should be able to find my way. I thought about using LLMs to fill the gap, but decided to not to take that route.
Well that is thing. setting up interrupts timers and all manner of other peripherals is of course independent of what language you do it in. But vendors would typically provide ready made code to do that written in C.
I'm hoping by now there is enough of that low level code in Rust available. I have not looked into this much but the first thing you might want its a hardware abstraction layer (HAL) to do that peripheral access. From what I have heard such HAL's do exist in Rust.
The LLM idea is interesting. I just typed "flash a LED on stm32 using Rust" into Google search and then clicked on it's AI Mode. It's kind of amazing what happens with such queries, it will explain all about how to do it and even show you the code that does it. I have had chats with that about all kind of little software things, it's amazing how much code you can get generated for free!
If nothing else it will come up with a lot of info and links for you and suggest approaches you may not have heard of to search for in the first place.
To focus on this bit, I would say it's pretty much true, but maybe not in the way you expect.
Inevitably, you're eventually going to run into documentation or headers or a blog post talking about some functionality written in C and you'll realize that C is largely just a different (often crazy) syntax for most of what you're doing in Rust minus the type system; and you've accidentally ended up learning it anyway.
There's definitely some weirdness around the way macros work, the bizarre function pointer syntax, and the user data pointer convention that will trip you up initially, but for the purpose of just reading and understanding C there's really not much to learn after you're comfortable with Rust.
The question has previously been asked here if that means you should learn C first as a stepping stone, and while I don't think there was any full consensus, the jist seemed to be that it's mostly a question of motivation for new programmers; if you already have plenty of experience in C# (especially the more recent versions!) Rust is likely to be more comfortable.
Just don't get caught off guard by the borrow checker continuously kicking you in a soft place: the pain is bad habits leaving your body
Depends on what you mean by “learning C”. C Isn't A Programming Language Anymore, it's more of the way to describe how anything cross-platform works, these days.
Learning to write prorgams in C is not needed. Learning how to read C headers… that's different story.
Yes, actually, this is the only type of usage I try to limit myself to. That and a few follow ups, and then try to get a hand-off prompt to continue the conversation in another chat. Any more than this, it seems to lead into a uncomfortable thought-erasing spiral.
In fact this is how I arrived at the original question and wanted validation from people.
This is very helpful. The earlier reply gave me some things to think about, but your explanation directly addresses the concern I was trying to confront.
