4 ms·
My 2 cents, from the perspective of someone who built a career on writing software in C for small devices. C has longevity b/c its compact and provides a strai
by jdblair 9y ago
My 2 cents, from the perspective of someone who built a career on writing software in C for small devices.
C has longevity b/c its compact and provides a straightforward model of memory on the machine. I understand the desire to use safe, garbage collected, memory safe language when you're serving HTTP requests, but sometimes you need to access the hardware: twiddle a GPIO or read from a DMA device. This is where I've yet to see a good replacement for C, and by extension, C++ (b/c its fundamentally still just C). Maybe rust is there, but I don't have experience there to judge.
[edited for clarity]
- steveklabnik 9y agoTo be clear, since I have seen this pop up lately, Rust doesn't have a GC and absolutely gives you access to hardware. The challenges for it on embedded are mostly toolchain issues.
- scruple 9y agoSo, are vendors working on rust toolchains for their hardware? I'm asking from a place of genuine curiosity, I left embedded a number of years ago. I've always viewed the 'rust breaking into embedded' problem as a toolchain issue, as well. But, my intuition is that vendors will be slow to release rust support in toolchains because the industry is still firmly in the "we write in C" camp.
- steveklabnik 9y agoThat's what I meant by challenges; it's pretty much "can LLVM support the chip and then did someone put in the compiler work in rustc", rather than "vendors are directly providing Rust support." Your intuition is mine as well.
- analog31 9y agoThis is an interesting thread... https://news.ycombinator.com/item?id=14071282 https://news.ycombinator.com/item?id=14071282 In my view the industry inertia is a chicken and egg thing. You want a chip that runs your existing code. Then you want to write new code on your existing chip. And you have ongoing projects at different stages, sharing chips and code.
- jdblair 9y agoThis is good to hear. I may give rust a shot. I have a lot of inertia, though, because I already know how to set up and maintain my cross-compile toolchain. I've also heard that Go may a viable option, at least on ARM, and I'm considering giving it a try for my next embedded side project.
- steveklabnik 9y agoSo, some quick things: every Rust compiler is a cross-compiler, so that's not the tough part. You need to compile 'libcore' for the target, but https://github.com/japaric/xargo https://github.com/japaric/xargo makes that pretty straightforward if your chip isn't one of the ones provided by the Rust project, if it is, then you just need to run a command to download it and you're good to go. https://forge.rust-lang.org/platform-support.html https://forge.rust-lang.org/platform-support.html is said target list today. AVR is coming soon, it works but has bugs and is hacky. Japaric is quite prolific, he writes over at http://blog.japaric.io/ http://blog.japaric.io/ and his latest posts are about his RTOS-like framework. Finally if you're into ARM, https://www.tockos.org/ https://www.tockos.org/ might be up your alley.
- jdblair 9y agoNoting all this for future research. Thanks!
- steveklabnik 9y agoAny time! :) I really need to write better docs on all of this...
- ksrm 9y agoIs there anything anywhere comparing ROM and RAM usage of Rust vs. C for embedded devices? Can you write anything meaningful in Rust with say 8KB of RAM?
- steveklabnik 9y agoI don't have great numbers, https://news.ycombinator.com/item?id=15367507 https://news.ycombinator.com/item?id=15367507 talks about 256k flash and 32k RAM. That said, the new AVR support includes 8 and 16 bit chips, I don't know the lowest amount of RAM that has had actual code running on it yet.
- jjrh 9y agoI think the other point is we have decades and decades of code at this point written in C, or built on top of C. In some regards 'if it ain't broke don't fix it' holds quite a bit of truth. The embedded world may start to move to doing more things in a higher level language to speed up development in areas that may not need the same level of high performance or real time certainty. Stuff like TI RTOS while still C made getting to a proof of concept much faster.
- Sir_Cmpwn 9y ago>C++ (b/c its fundamentally still just C) I agree with your comment but hate this comparison. C and C++ are completely different languages. Idiomatic C++ looks nothing like C and vice versa.
- jdblair 9y agoYes, I agree with you, but I make this point because C++ gives me the same direct access to the hardware. I can always just write C (or inline assembly, if I really have to go there). That's why my last embedded project was written in C++. There was a core that implemented SPI by bit-banging GPIO registers, but wrapped around that was idiomatic C++.
- Sir_Cmpwn 9y agoThe line is pretty grey, but I don't consider that much different than a project in any language writing and linking to a few modules in C where necessary.