Hacker News Reader

> 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/) 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.

True, I was a bit hyperbolic.

From what I've seen, using registers is often simpler and easier than using the vendor GPIO libraries.

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.

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 ?

freertos or projects like that could help. They need different drivers anyway so good rtos support would mean you can ignore the official sdk.

I don't think they need software lock-in. They already have hardware lock-in, which is easily 10 times stronger.

Rewiring and redesigning all electronics around a new MCU is just an insane undertaking. Irrelevant of API change in the software.

In the EBM embedded survey 2013, regarding microcontorllers[1], they asked the question "why did you use the same processor", pg 56:

https://www.slideshare.net/MTKDMI/2013-embedded-market-study...

Many of the reasons we're regarding software, indicating that software lock-in is a significant factor.

[1]they called it microprocessors , but pages 54, 60 hint we're talking about mcu's.

Assuming there was a bit of standardisation around the basic API. There is still significant lock-in by other factors.

It could be that the software is the thing they think first, if you ask the people writing it.

Maybe. But you have to consider that such surveys(and similar tools) could make semi company managers believe that software lock-in is important, and that's all it takes.

Agree. Hardware SDK and tools are utterly terrible.

That's the major reason I stay away from embedded development.

> 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/

http://www.astrobe.com/default.htm

http://www.microej.com/

http://www.adacore.com/press/8-bit-avr-microcontroller/

https://www.parallax.com/microcontrollers/propeller

https://www.parallax.com/microcontrollers/basic-stamp

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-r...

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.

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.

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.

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.

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

1. https://gist.github.com/uxp/35c9d5d51b2229f5c4c2e5b11c3341e5

The MBed suite is rather nice to use.

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.

Check avr-vala (https://github.com/apmasell/avr-vala)

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

Did you look at Céu? A really cute language, I think.

http://ceu-lang.org/

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

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 - hard to follow without moderation, but pros and cons are at the end.

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

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"