6 ms·

I recently finished my Master's Thesis on using anything other than C/C++ on microcontrollers. It's a mess. A couple of languages like Rust, D, etc. can be hac

I recently finished my Master's Thesis on using anything other than C/C++ on microcontrollers. It's a mess. A couple of languages like Rust, D, etc. can be hacked on micros due to their compiler suite, but it is always messy. Above guide uses inline assembly to blink a GPIO. Hardware access is on register level. None of this makes your live easier. In order to be viable for microcontrollers you need two things: * a compiler or interpreter for your target * a Hardware API There are some projects, like MicroPython and Espruino who realized the importance of the Hardware API. They basically transcend micro-interpreters and RTOS (especially given the languages asyncio features). Microcontroller vendors ship C/C++ libraries for their hardware. You either have to wrap that, like the micro-interpreters do, or your language has to be able to use them natively. What Rust on microcontrollers need is a Kickstarter campaign with a nice dev-board as perk to finance a project that implements a nice API for that specific micro.

valarauca1 10y ago
C/C++ library?!? In my experience most bundle their own compiler suite. Nothing like learning what parts of C++03 are/aren't implemented. Especially in the RTOS space where most the time your program is just an object file being injected into the OS.
- turbinerneiter 10y ago
  True, the libraries are C. Compilers are often gcc. Like AVR has a gcc compiler and as you said some parts of C++ are implemented. For ARM there is also a gcc. I only have experience with AVR and ARM (STM) to be honest.
  - uxp 10y ago
    I came across this [0] yesterday while looking for STM32 stuff for those cheap ass $2 STM32F103 boards. To your point, however, it's still just writing values directly out to register pointers. That entire repo can be boiled down to one little C program like this [1]. 0. https://github.com/jamesmunns/bluepill https://github.com/jamesmunns/bluepill 1. https://gist.github.com/uxp/35c9d5d51b2229f5c4c2e5b11c3341e5 https://gist.github.com/uxp/35c9d5d51b2229f5c4c2e5b11c3341e5
- AlphaSite 10y ago
  The MBed suite is rather nice to use.
mafribe 10y ago
Is your Masters dissertation online? I'd be interested in reading it.
- turbinerneiter 10y ago
  I do plan to make it a website, like a gitbook or something, but right now, I'm hammocking. Also don't expect much. I'm a Mechanical Engineer and it was a bit out of my league, so it didn't go very deep. The paper will hopefully soon be published: ISBN 978-3-8007-4395-7 "Evaluation of MicroPython as Application Layer Programming Language on CubeSats" in the "ARCS 2017 Conference Proceedings"
fest 10y ago
Another interesting language for embedded targets is Ada: http://blog.adacore.com/tag/STM32 http://blog.adacore.com/tag/STM32
robotjosh 10y ago
The vendor SDKs are the weak link, not the compiler or language. Development could go 4x smoother if the vendor code were solid. Every single project I bump into sdk bugs that make it clear they have shipped code that was not tested. Its like they expect us to debug their code that they had developed on the cheap. Lately my philosophy is to just take the vendor header file and write my own low level drivers because it takes a more predictable amount of time. Our industry could use 3rd party SDKs.
- petra 10y ago
  There's a big conflict in mcu development:On the one hand, you have developers who want reliable and comfortable libraries so they can develop well and fast. Higher-level is a word to describe that(it's only partially accurate). On the other hand, mcu companies make a significant amount of their profit based on lock-in(since mcu's are mostly commodities). And the higher level the API's and the rapid development is, the less lock-in companies get. That together with the fact it costs a lot to develop quality libraries are the main reason to the state we're in today. As for solutions: 1. ARM did face that problem once, with cores, and played it hand well , they came to mcu vendors and told them - the carrot: using our core will save you money on development(core/compilers/etc). The stick: a startup called luminary-micro , who could do cheap mcu's since all that was free. - So can this move be played again, today, with peripherals ? maybe build a nice peripheral set, with libraries, well tested, etc - and offer it cheaply to the risc-v guys , and other mcu vendors, including Chinese mcu vendors ? - Maybe the place to look for quality libraries is at mcu startups ? the last one was the acquired energy-micro , are their libraries better ? 2. The IOT is a big shift. Shifts create different leverage points sometime. Is there something that open-source community can do together to push the vendors towards great libraries in that niche , even if vendors don't like it much? For example, what if the open-source community focused on one of the hardest building block of the IOT - security ? what if we created a highly proven security IP, proven by the community to a great extent, but used it licensing to push mcu vendors ? Are there any other ideas how to solve this conflict ?
  - robotjosh 10y ago
    freertos or projects like that could help. They need different drivers anyway so good rtos support would mean you can ignore the official sdk.
kam 10y ago
> Above guide uses inline assembly to blink a GPIO. No, the only inline ASM in this guide is to cause a debugger breakpoint. You also need inline ASM to enable/disable interrupts, and that's about it. The code in this guide looks ugly because it's written to show how to use the hardware without any abstraction. Higher level APIs like f3 (https://docs.rs/f3/0.3.1/f3/ https://docs.rs/f3/0.3.1/f3/) exist, though not nearly for every chip or peripheral. Even in C, for anything outside the popular Arduino/mbed/etc boards, your choice is usually between buggy vendor bloatware and using the registers directly after carefully reading the datasheet.
- turbinerneiter 10y ago
  True, I was a bit hyperbolic.
- snovv_crash 10y ago
  From what I've seen, using registers is often simpler and easier than using the vendor GPIO libraries.
petra 10y ago
Is creating a Hardware API that complex that it would require a kickstarter ? because this link talk about using rustbindgen to automatically generate embedded bindings to a vendor library: https://spin.atomicobject.com/2015/05/21/generate-embedded-rust-bindings/ https://spin.atomicobject.com/2015/05/21/generate-embedded-r...
- turbinerneiter 10y ago
  Creating a _nice_ and _reliable_ API with _good_ documentation that is _native_ to the language - I do think so, yes. Also keep in mind that there would be a specific devboard to build a community around.
  - dbcurtis 10y ago
    Total agreement. And even before the coding starts, defining good abstractions for complex peripherals is very difficult. Counter/timer modules are the poster child for that. Heck, if you look at the Micropyothon issues on github you will find pages of vigorous debate about GPIO pullup configuration, much less anything complex.
pjmlp 10y ago
> Microcontroller vendors ship C/C++ libraries for their hardware They also ship Basic, Pascal, Ada, Oberon and Java, here's a small selection for those curious about the offerings. https://www.mikroe.com/ https://www.mikroe.com/ http://www.astrobe.com/default.htm http://www.astrobe.com/default.htm http://www.microej.com/ http://www.microej.com/ http://www.adacore.com/press/8-bit-avr-microcontroller/ http://www.adacore.com/press/8-bit-avr-microcontroller/ https://www.parallax.com/microcontrollers/propeller https://www.parallax.com/microcontrollers/propeller https://www.parallax.com/microcontrollers/basic-stamp https://www.parallax.com/microcontrollers/basic-stamp
geon 10y ago
Did you look at Céu? A really cute language, I think. http://ceu-lang.org/ http://ceu-lang.org/
pcarolan 10y ago
Can you go into your experience evaluating MicroPython a little deeper? What were the pros and cons you discovered?
- turbinerneiter 10y ago
  Look out for ISBN 978-3-8007-4395-7 "Evaluation of MicroPython as Application Layer Programming Language on CubeSats" in the "ARCS 2017 Conference Proceedings" - paper should come out soon enough. I have a presentation under http://plamauer.space/presentation.html http://plamauer.space/presentation.html - hard to follow without moderation, but pros and cons are at the end.
ksrm 10y ago
Perhaps a viable way to break the monopoly that C/C++ has in embedded software is to create a language that compiles to C. That way people can use their existing compilers (which may be the only choice for a particular target), drivers, middleware, etc. but benefit from a modern, safe(r) language.
- desiderantes 10y ago
  Check avr-vala (https://github.com/apmasell/avr-vala https://github.com/apmasell/avr-vala)

valarauca1 10y ago

C/C++ library?!? In my experience most bundle their own compiler suite. Nothing like learning what parts of C++03 are/aren't implemented. Especially in the RTOS space where most the time your program is just an object file being injected into the OS.

turbinerneiter 10y ago
True, the libraries are C. Compilers are often gcc. Like AVR has a gcc compiler and as you said some parts of C++ are implemented. For ARM there is also a gcc. I only have experience with AVR and ARM (STM) to be honest.
- uxp 10y ago
  I came across this [0] yesterday while looking for STM32 stuff for those cheap ass $2 STM32F103 boards. To your point, however, it's still just writing values directly out to register pointers. That entire repo can be boiled down to one little C program like this [1]. 0. https://github.com/jamesmunns/bluepill https://github.com/jamesmunns/bluepill 1. https://gist.github.com/uxp/35c9d5d51b2229f5c4c2e5b11c3341e5 https://gist.github.com/uxp/35c9d5d51b2229f5c4c2e5b11c3341e5
AlphaSite 10y ago
The MBed suite is rather nice to use.

mafribe 10y ago

Is your Masters dissertation online? I'd be interested in reading it.

turbinerneiter 10y ago
I do plan to make it a website, like a gitbook or something, but right now, I'm hammocking. Also don't expect much. I'm a Mechanical Engineer and it was a bit out of my league, so it didn't go very deep. The paper will hopefully soon be published: ISBN 978-3-8007-4395-7 "Evaluation of MicroPython as Application Layer Programming Language on CubeSats" in the "ARCS 2017 Conference Proceedings"

fest 10y ago

Another interesting language for embedded targets is Ada: http://blog.adacore.com/tag/STM32 http://blog.adacore.com/tag/STM32

robotjosh 10y ago

The vendor SDKs are the weak link, not the compiler or language. Development could go 4x smoother if the vendor code were solid. Every single project I bump into sdk bugs that make it clear they have shipped code that was not tested. Its like they expect us to debug their code that they had developed on the cheap. Lately my philosophy is to just take the vendor header file and write my own low level drivers because it takes a more predictable amount of time. Our industry could use 3rd party SDKs.

petra 10y ago
There's a big conflict in mcu development:On the one hand, you have developers who want reliable and comfortable libraries so they can develop well and fast. Higher-level is a word to describe that(it's only partially accurate). On the other hand, mcu companies make a significant amount of their profit based on lock-in(since mcu's are mostly commodities). And the higher level the API's and the rapid development is, the less lock-in companies get. That together with the fact it costs a lot to develop quality libraries are the main reason to the state we're in today. As for solutions: 1. ARM did face that problem once, with cores, and played it hand well , they came to mcu vendors and told them - the carrot: using our core will save you money on development(core/compilers/etc). The stick: a startup called luminary-micro , who could do cheap mcu's since all that was free. - So can this move be played again, today, with peripherals ? maybe build a nice peripheral set, with libraries, well tested, etc - and offer it cheaply to the risc-v guys , and other mcu vendors, including Chinese mcu vendors ? - Maybe the place to look for quality libraries is at mcu startups ? the last one was the acquired energy-micro , are their libraries better ? 2. The IOT is a big shift. Shifts create different leverage points sometime. Is there something that open-source community can do together to push the vendors towards great libraries in that niche , even if vendors don't like it much? For example, what if the open-source community focused on one of the hardest building block of the IOT - security ? what if we created a highly proven security IP, proven by the community to a great extent, but used it licensing to push mcu vendors ? Are there any other ideas how to solve this conflict ?
- robotjosh 10y ago
  freertos or projects like that could help. They need different drivers anyway so good rtos support would mean you can ignore the official sdk.

kam 10y ago

> Above guide uses inline assembly to blink a GPIO. No, the only inline ASM in this guide is to cause a debugger breakpoint. You also need inline ASM to enable/disable interrupts, and that's about it. The code in this guide looks ugly because it's written to show how to use the hardware without any abstraction. Higher level APIs like f3 (https://docs.rs/f3/0.3.1/f3/ https://docs.rs/f3/0.3.1/f3/) exist, though not nearly for every chip or peripheral. Even in C, for anything outside the popular Arduino/mbed/etc boards, your choice is usually between buggy vendor bloatware and using the registers directly after carefully reading the datasheet.

turbinerneiter 10y ago
True, I was a bit hyperbolic.
snovv_crash 10y ago
From what I've seen, using registers is often simpler and easier than using the vendor GPIO libraries.

petra 10y ago

Is creating a Hardware API that complex that it would require a kickstarter ? because this link talk about using rustbindgen to automatically generate embedded bindings to a vendor library: https://spin.atomicobject.com/2015/05/21/generate-embedded-rust-bindings/ https://spin.atomicobject.com/2015/05/21/generate-embedded-r...

turbinerneiter 10y ago
Creating a _nice_ and _reliable_ API with _good_ documentation that is _native_ to the language - I do think so, yes. Also keep in mind that there would be a specific devboard to build a community around.
- dbcurtis 10y ago
  Total agreement. And even before the coding starts, defining good abstractions for complex peripherals is very difficult. Counter/timer modules are the poster child for that. Heck, if you look at the Micropyothon issues on github you will find pages of vigorous debate about GPIO pullup configuration, much less anything complex.

pjmlp 10y ago

> Microcontroller vendors ship C/C++ libraries for their hardware They also ship Basic, Pascal, Ada, Oberon and Java, here's a small selection for those curious about the offerings. https://www.mikroe.com/ https://www.mikroe.com/ http://www.astrobe.com/default.htm http://www.astrobe.com/default.htm http://www.microej.com/ http://www.microej.com/ http://www.adacore.com/press/8-bit-avr-microcontroller/ http://www.adacore.com/press/8-bit-avr-microcontroller/ https://www.parallax.com/microcontrollers/propeller https://www.parallax.com/microcontrollers/propeller https://www.parallax.com/microcontrollers/basic-stamp https://www.parallax.com/microcontrollers/basic-stamp

geon 10y ago

Did you look at Céu? A really cute language, I think. http://ceu-lang.org/ http://ceu-lang.org/

pcarolan 10y ago

Can you go into your experience evaluating MicroPython a little deeper? What were the pros and cons you discovered?

turbinerneiter 10y ago
Look out for ISBN 978-3-8007-4395-7 "Evaluation of MicroPython as Application Layer Programming Language on CubeSats" in the "ARCS 2017 Conference Proceedings" - paper should come out soon enough. I have a presentation under http://plamauer.space/presentation.html http://plamauer.space/presentation.html - hard to follow without moderation, but pros and cons are at the end.

ksrm 10y ago

Perhaps a viable way to break the monopoly that C/C++ has in embedded software is to create a language that compiles to C. That way people can use their existing compilers (which may be the only choice for a particular target), drivers, middleware, etc. but benefit from a modern, safe(r) language.

desiderantes 10y ago
Check avr-vala (https://github.com/apmasell/avr-vala https://github.com/apmasell/avr-vala)