Rust for embedded - Page 1
Forum section: electronics / general

author: SreejitS
author_rank: Contributor
timestamp: September 26, 2016, 05:26:01 am
content: Hello everyone!I recently came across a programming language called rust which is fast but safe language. My immediate response was to use it for embedded dev. It seems people already have started that and a github repo named zinc can be used to for a handful of uCs (NXP lpc11xx, NXP lpc17xx, Freescale k20, ST STM32f4, ST STM32l1).Only few peripherals are supported and as a beginner I would love people contributing to the project as I really feel it would help the community to write awesome embedded firmware.I am so excited about the project!!What is your view on this??Github link :https://github.com/hackndev/zinc

author: nano
author_rank: Contributor
timestamp: September 26, 2016, 05:54:39 am
content: I think rust is really interesting for embedded and I plan on using it in future.There are more embedded rust projects besides zinc that may be interesting:http://www.tockos.org/- A secure operating system for MCUs with a nice blog.https://japaric.github.io/copper/- WIP Book on embedded development in Rust.

author: ataradov
author_rank: Super Contributor
timestamp: September 26, 2016, 05:56:53 am
content: Rust is a decent language, but its safety comes at a really big price. Once you narrate the program with all those borrowing directives, it starts to look like total unreadable garbage.Some features of the language would be too heavy for the embedded systems.I don't think it is going to be really usable in embedded world.Also, being more oriented towards desktop programming, it really lacks granularity of memory control and heavily relies on dynamic memory allocation.

author: SreejitS
author_rank: Contributor
timestamp: September 26, 2016, 06:03:05 am
content: Cool!!I never knew there are rust+embedded libraries!!Thanks for pointing it out

author: SreejitS
author_rank: Contributor
timestamp: September 26, 2016, 06:32:17 am
content: @ ataradovI was under the impression that compile time optimizations and lack of garbage collector would make it apt for embedded stuff.May I know why do you think its still heavy for embedded use?

author: ataradov
author_rank: Super Contributor
timestamp: September 26, 2016, 06:39:30 am
content: Quote from: SreejitS on September 26, 2016, 06:29:56 amUnicode strings, heavy reliance on dynamic memory. Advanced language tools (like iterators) can hide some slow code behind really nice syntax.In embedded systems, direct memory access is an important thing, so half of your code will end up looking like this:Code:ptr::write_volatile(&mut (*self.registers).scr, 0x0000001);Also, if you look at that OS code, there are a lot of "unsafe" places.And with following good programming practices, it is not that hard to write good programs in C. Rust still will not save you from making logical mistakes, which become prevalent once you can write safe code.

author: SreejitS
author_rank: Contributor
timestamp: September 26, 2016, 06:50:18 am
content: QuoteTrue that. No tool can defeat human dumbness.What is the opinion on using rust as a quick prototyping language and then port it to C for production. I feel that way the developers will feel less frustrated.

author: alexanderbrevig
author_rank: Frequent Contributor
timestamp: September 26, 2016, 06:53:18 am
content: I really like rust for systems programming and I've had fun making some simple web server stuff. If you need concurrency and like to think functional, I'd recommend Rust.However, I must say I would not consider it for embedded because theintentof the language does not match our needs. The intent of C is much much closer.

author: ataradov
author_rank: Super Contributor
timestamp: September 26, 2016, 06:55:27 am
content: Quote from: SreejitS on September 26, 2016, 06:50:18 amRust is nowhere ready for production on embedded. Why do you think it makes it easy to prototype? I see all the limitations really annoying, to the point where it will just make sense to wrap the whole thing into one big "unsafe { }" block.Plus, if you write something in a truly Rust style, there is no way to port it to C, it is basically a full rewrite.Also, there are no header files for MCUs, so all low level code right now is a bunch of magic numbers. Some of this is solvable, but I just don't see why anyone would bother. It is a pointless exercise, like MicroPython and embedded Java.

author: SreejitS
author_rank: Contributor
timestamp: September 26, 2016, 07:08:21 am
content: I would agree that the current state of rust is pretty unusable but i am excited about the possibilities.QuoteTo get a peripheral up and running using C code may take more time than using a functional language. So you can check whether or not the hardware is sending/receiving correct data or something like that fairly easily, just like it is done in arduino(Don't Hate)

author: ataradov
author_rank: Super Contributor
timestamp: September 26, 2016, 07:11:58 am
content: I chose to master the tools I use daily and it does not take me a long time to implement things.Also, writing low level code in Rust is a nightmare.Or you were going to depend on drivers written by others? In that case you are going to wait for a long time until your part is supported.

author: SreejitS
author_rank: Contributor
timestamp: September 26, 2016, 07:16:10 am
content: Cool...I see your point.I just wish to lower the entry barrier for embedded systems....

author: ataradov
author_rank: Super Contributor
timestamp: September 26, 2016, 07:18:49 am
content: Entry barrier must be high, otherwise you end up with an industry full of unqualified people. Arduino is already doing this to a certain extent.

author: SreejitS
author_rank: Contributor
timestamp: September 26, 2016, 07:34:04 am
content: Well, even with industry full of this "qualified" people, embedded developers have to work with primitive tools and debuggers that are not taking full advantage of developments in programming languages. That is something I find very annoying as a beginner. And that is why I took immediate interest when I found about rust.Anyway, I can conclude that languages like rust is currently unusable but who knows what the future holds for us !!

author: SreejitS
author_rank: Contributor
timestamp: September 26, 2016, 08:10:57 am
content: Can anyone share there experience in embedded coding in language other than C/C++ ?PS: I dont have any personal grudge against C/C++ , just want to know stuff, that's all!

author: farsi
author_rank: Regular Contributor
timestamp: September 26, 2016, 10:57:59 am
content: maybe you could look at:embeddednodejs.comwhile javascript is for sure not the same in code size and efficiency than C or C++, its syntax is popular and there is larger community of programmers around.

author: legacy
author_rank: Super Contributor
timestamp: September 26, 2016, 11:15:45 am
content: I don't think Rust is good for the low-level

author: alexanderbrevig
author_rank: Frequent Contributor
timestamp: September 26, 2016, 01:38:51 pm
content: I've tried JavaScript (based on Espruino), MicroPython and a homebrew LISP.They're all fun and different, and feel good while initially prototyping. But sooner or later you hit a wall because you're not as low level as you need to be.If you had asked me a year ago I would be a huge proponent for scripted languages for the embedded, but since then I've had to rewrite all my previous work to low level. I feel more confident in the result, and looking back I would never sell a product that's running a script.Programming in C will mean the initial learning curve is larger, but you get an intimate knowledge of the chip which enables you to be quick down the line. Seemingly weird bugs may become obvious when you're not simply doing some version ofdigitalWrite(pin, state)but instead know which registers to check etc.C (and C++ if the tool chain is good) are my hands down favorites. I've looked at ADA too, but I'll rather stay with my good old friend.

author: SreejitS
author_rank: Contributor
timestamp: September 26, 2016, 02:02:40 pm
content: @ alexanderbrevigI think i am at the stage where you have been an year agoI feel all the scripting is fun to implement and i am guessing that's where the fun ends....Can you share on how your experience was with Ada?Thank You!

author: legacy
author_rank: Super Contributor
timestamp: September 26, 2016, 02:45:33 pm
content: Quote from: alexanderbrevig on September 26, 2016, 01:38:51 pmGNAT? Green Hills? for PowerPC? AVR8? AVR32?with/without exceptions enabled?

author: alexanderbrevig
author_rank: Frequent Contributor
timestamp: September 26, 2016, 03:03:36 pm
content: Quote from: SreejitS on September 26, 2016, 02:02:40 pmI still use an Espruino (javascript) from time to time if I want to just try something out very quickly.They also make for good live demos, as you can program them with the REPL and have things happen instantly.Quote from: SreejitS on September 26, 2016, 02:02:40 pmI triedhttp://libre.adacore.com/andhttps://github.com/AdaCore/Ada_Drivers_Libraryusing a tutorial I couldn't find just now...There was some difficulties setting it all up, and I don't really like the language so I did not bother to spend much time on it. I got the LEDs blinking and stopped at that.It seems to me there are some people on this forum who likes it, maybe try to googleada site:eevblog.comor start a thread on the topic?I forgot to mention I also triedhttp://www.eluaproject.net/which is also kind of cool, but I stopped after some simple tests with that as well.

author: legacy
author_rank: Super Contributor
timestamp: September 26, 2016, 03:35:14 pm
content: Quote from: alexanderbrevig on September 26, 2016, 03:03:36 pmif you want to try ADA, you'd better use GNAT with host=PC, target=PCit's more comfortable, this wayonce you have mastered the language you can move tohost=PC, target=PowerPC (we also have emulators, e.g. Qemu)I wouldn't suggest ADA (especially with exceptions enabled)for small machines with restricted amount of resources and ramI happen to use ADA in avionics, our targets are PowerPC fly-control boxesusually developed around PowerPC460, e500, with 128Mbyte of ram at leastthe low level (kernel, driver, etc) is still written in C (rarely in C++)and ADA takes its seat on a BSP/iBSP for the high-level (Application)

author: legacy
author_rank: Super Contributor
timestamp: September 26, 2016, 03:47:59 pm
content: Quote from: alexanderbrevig on September 26, 2016, 03:03:36 pmeLua is also supported in the new line of pocket calculatorsmade by Texas Instruments under the name of "Ti-nSpire"if you are interested,hereit is a good forum(it points directly to the eLua section)I have already bought mine, lucky second hand from ebaypaid 60 USD, and freely updated to the last OS versionin order to have the fulleLuasupport availablealong with the CAS (computer algerbra system) supportto make the story short:eLuarocks for those thingsand it's also used inside a lot of game-engines

author: ataradov
author_rank: Super Contributor
timestamp: September 26, 2016, 03:51:39 pm
content: Quote from: legacy on September 26, 2016, 03:47:59 pmExcept if your MCU does not support double precision flaoting point. In that case eLua sucks very much. And again, it is not a low-level language, it is good for scripting, but no for system programming.

author: legacy
author_rank: Super Contributor
timestamp: September 26, 2016, 03:56:27 pm
content: Quote from: ataradov on September 26, 2016, 03:51:39 pmof course, I meant for those things like pocket calculators (arm based) developed with double precision engines or with CAS engines, in those cases eLua interfaces the engine with its scripting capability, and it's damn usefulthe alternative consists in downloading the C SDK, and develop your own calculator app in Cyou can choose, therefore it makes sense

author: legacy
author_rank: Super Contributor
timestamp: September 26, 2016, 04:02:01 pm
content: Quote from: legacy on September 26, 2016, 03:56:27 pmthey are usually written in C/C++sometimes directly in assemblyeLuacan pass arguments, do foreign-calls, and get resultsit works like awrapper, but it adds a ton of scripting capabilities

author: Marco
author_rank: Super Contributor
timestamp: September 26, 2016, 04:42:25 pm
content: Quote from: ataradov on September 26, 2016, 06:39:30 amSo, how many exploitable overflow bugs do you think are hidden in your internet facing code after using those good programming practices?

author: ataradov
author_rank: Super Contributor
timestamp: September 26, 2016, 04:45:08 pm
content: Quote from: Marco on September 26, 2016, 04:42:25 pmI don't know, obviously. But there is no proof that Rust actually helps anything here. Rust only helps if you never-ever use unsafe keyword, which never happens in a real program.If anything, unsafe sections simply point out sections where you should look for exploits first. Convenient language for both sides, I guess

author: Marco
author_rank: Super Contributor
timestamp: September 26, 2016, 04:58:33 pm
content: It will inevitably happen in hardware interfacing code, it need never happen in anything else as long as you can swallow the performance overhead for runtime bounds checking.

author: legacy
author_rank: Super Contributor
timestamp: September 26, 2016, 06:15:43 pm
content: Quote from: Marco on September 26, 2016, 04:58:33 pmthat's the same problem with ADA, and the reason why I was suggesting big-iron processors like PowerPC rather then small machines

author: tggzzz
author_rank: Super Contributor
timestamp: September 26, 2016, 06:57:41 pm
content: Quote from: Marco on September 26, 2016, 04:58:33 pmBut who cares about correctness so long as it is fast? No, that's not a joke, unfortunately. or at least lack of easily and mechanically detectable errors

author: Feynman
author_rank: Regular Contributor
timestamp: September 26, 2016, 07:20:44 pm
content: We were and still are definitely lacking a decent programming language for embedded systems.But since the C-beast is pretty much tamed (MISRA, Lint and stuff), I think there is no need anymore for another "high level" language for deeply embedded systems.

author: SreejitS
author_rank: Contributor
timestamp: October 03, 2016, 05:03:03 pm
content: QuoteAgreed

author: legacy
author_rank: Super Contributor
timestamp: October 03, 2016, 05:25:07 pm
content: Quote from: SreejitS on October 03, 2016, 05:03:03 pmI agree, too

author: autobot
author_rank: Regular Contributor
timestamp: October 08, 2016, 12:54:41 pm
content: Quote from: SreejitS on September 26, 2016, 07:16:10 amThe arduino was very sucsessful in that but had big limitations. The mbed(and mbed OS) could be the answer - combining global collaboration and code sharing, under a well designed structure(with a lot of attention to tools/security/power/cost etc) and somewhat higher barrier than the arduino in order to create higher quality in contributed code.