Embedded in Rust: Brave new I/O
blog.japaric.io
blog.japaric.io
Kudos, can't wait to see where to goes from here.
ARM controllers are (relatively) uniform and the svd files do a lot of the work by providing the mapping for the memory mapped peripherals.
Across other devices it becomes even more complicated. AVR devices, AFAIK, are not providing memory mapped flash. There are also differences in byte v page erasable flash and eeprom. How would something like this map to Rust? I don't know and I'm honestly skeptical of the practical use but there is a quite serious effort put into making the AVR backend for LLVM ready for use.
---
It really makes me wonder a lot about "embedded" programming and where it is heading. If I were to bet I'd say that there is a significant movement to employ more and more powerful "microcontrollers" in order to allow remove all the resource constraints typically associated with "embedded" programming.
Stuff like Esprino, MicroPython, huge layers of abstraction etc. are today kind of nice tools for learning and starting out -- but give it a few years and somebody will ship a successful product build around this. It doesn't matter that the BOM cost is higher, the current draw is larger and the complexity and security understanding decreased -- it enables a faster time to market and in the end that is what makes the business.
The same is happening in FPGA development.
The old-fashioned hardware folks say that "not how it's done" -- myself included. But you know what they say:
> When the wind of change blows, some build walls, while others build windmills.
https://semiengineering.com/mcu-sales-up-in-2017-and-2018/
As vvanders says, the hard data shows plenty of the market is still maximizing profit by using 8-bitters (33%) and 16-bitters (26%). That's a combined 59% of microcontrollers a 32-/64-bit-only language would be leaving on the table in terms of deployment. Even ATS language, much more difficult than Rust, has already been deployed on 8-bitters.
http://metasepi.org/doc/metasepi-icfp2015-arduino-ats.pdf
Hopefully, Rust stays adding whatever features are necessary to support this stuff. If not, the Haskell crowd can always grab it up with DSL's like Ivory:
https://ivorylang.org/ivory-introduction.html
EDIT to add: A link about 4-bit MCU market that still exists for anyone wondering what that part of the pie chart was about.
Sure, a 32-bit chip is bound to be bigger than an equivalent 8 or 16-bit one, but e.g. the pulpino project has designed a 32-bit one using only 11.6 kGE. Not very much nowadays. For comparison, according to someone from Atmel, the AVR core is 12k gates, and megaAVR is 20k gates (https://www.embeddedrelated.com/showthread/comp.arch.embedde... ).
Well, let me show you how low they get it so you know what your reusable-for-better-products micro would compete with:
http://www.microchip.com/ParamChartSearch/chart.aspx?branchI...
The smallest one is designed, masked, printed on silicon, packaged and sold in 5k quantities at 24 cents a chip at a profit! That's nuts! I can only imagine what the 4-bitters cost. The cheapest 32-bitter I found were 32-bit NXP's at 10,000 units for about 50 cents. So, they're getting there. It's an understatement, though, to say the manufacturing costs are highly competitive in this sector. :)
I think consumers are still going to be cost-sensitive in quite a few markets so BOM will still be critical. I'd argue you're already seeing this with more than a few companies using Android + mid-tier ARMs when market time matters more than final cost.
There's probably just going to be less people that know how to do it, much in the same way native programming is today.
What?
Sure, the core is relatively uniform, but the peripherals are radically different between manufacturers.
If you look at a die photo and see what area goes to what, pretty quickly you conclude all microcontroller makers are just selling value-added flash memory.
Even ignoring that, because llvm instruction set mismatch between versions, i can't feed the rust generated IR to their firmware generating tool.
If you see their language xC(https://en.wikipedia.org/wiki/XC_(programming_language), it extends C with various pointer types(restricted, movable, alias) for memory safety. Rust definitely is a good fit for this kind of development with borrow checker, traits etc.
If the compiler in question supports the #line directive, it might not be too bad.
Agreed, but I think long-term its certainly going to be easier doing that on the rust platform with a tool like cargo than the current state of affairs.
Maybe if rust just concentrated on the hobbyist/prototypers at first i.e. arduino / rasberry pi, to make that experience as great and pain free as possible and really showcase what can be done with rust and cargo. That would at least make it a viable tool for professors teaching the next gen of engineers and all the startups/prototypers/hobbiests.
ICE pins are usually configured with the exact registers this article talks about. It's common for UART/SPI serial port configuration to be a part of enabling ICE. Some chips also let you disable the ICE pins so that you can use them to pick the cheapest chip possible.
Another issue is that with microcontrollers you are usually debugging really low level stuff like interrupts where you can't even do printf debugging. Or you are setting registers on some black box subsystem and it just won't work and the only way to fix it is just keep randomly changing registers until you find the one you got wrong, or if you're lucky find working example code and bisect from that.
Or you've got some timing sensitive code that you can't stop and the only debugging channel that is fast enough is toggling group connected to an oscilloscope.
https://github.com/andysworkshop/stm32plus/blob/master/examp...
Though obviously the Rust approach provides a lot more guarantees, especially at runtime.
The one thing that interests me is how flexible this approach would be at dealing with cases where you have to hack around a hardware bug. For example, I had a board on it with an I2C expander whose default I2C address was not one the STM32 was able to address, but could be changed at runtime with an I2C command. So this was dealt with in firmware by initializing those pins initially as GPIO and bit-banging in the message to change the address, then changing them over to the regular I2C peripheral and taking it from there.
How possible would something like that be with this much more tightly constrained Rust IO model?
I'll also disagree that this is a small problem. We had one of these that was so hard to track down that it involved 100+ devices running in a stress loop over 24 hours with cameras looking for the regression. Ended up being a timing sequence that could have been caught by a system like this.
The repro was incredibly infrequent but when you've got millions of units even 0.01% chance of something happening is too often.
That it's auto-generated is the neat part, but then again, you could auto-generate C code that was just as robust (though admittedly, a lot of that robustness would be pushed to run-time checks with C code).
First, you can always use unsafe and access low level registers ignoring all the synchronization. You are still getting typed access to the bits (well, contingent on SVD file quality), which is an improvement over hand-writing bit manipulation code (or using wrong constant for shift/mask in STM32 HAL, for example).
Second, look at the port splitting example. If you split port into pins, when you can independently move these pins into different execution contexts and you won't need any synchronization as well. Write to a pin would be a single write to BSRR register -- no read-modify-write. So you are getting safety and about the same generated code as for hand-written code (well, except that if you want to do multiple pins at once).
What if you want to reconfigure port? This is, actually, what was particularly annoying for me with the old version of svd2rust I/O. Even though I know that my two subsystems operate on completely different pins, I still had to pass CRL/CRH around, to avoid potential race when reconfiguring pins.
This new version has the same property, though, -- according to the article.
However, the solution is pretty straightforward. By using ARM bit-banging feature, you can have the same "split" atomic-share-nothing-style API for the port reconfiguration, too. Similarly, you would split, for example, GPIOA into 8 pins and each pin would allow you to both input/output data and change port direction.
So, bottom line, I think you can get best of both worlds most of the time: safety and performance of the hand-written code. And in corner cases, you can still ignore all the safety and access registers without any overhead.
I don't really understand what is this approach lacking for career firmware engineer.
(disclaimer: I haven't ported my firmware yet, so I could be wrong in my assumptions how this new I/O works).
The fact is, no one's development process is that parallel, so critical-path-style arguments don't work. Turning even just a few easy parts free does reduce dev costs, and in these case we're clean-sweeping like all the low hanging fruit.
Checkout the latest version (now called modm). A description of our device file format can be found here: https://github.com/modm-io/modm/blob/develop/devices/Readme.... If you are interested in the data for STMs, checkout: https://github.com/modm-io/modm-devices/tree/develop/devices...
"The CMSIS System View Description format(CMSIS-SVD) formalizes the description of the system contained in ARM Cortex-M processor-based microcontrollers, in particular, the memory mapped registers of peripherals."
If it's possible, and this tooling makes SVDs a really powerful tool for porting, then perhaps it would be easier for the community to write SVDs for non-ARM chips than code.
https://github.com/posborne/cmsis-svd/blob/master/data/STMic...
It’s a more than 10k loc XML file. It is too much effort for the community to do that and verify it. And as an embedded system engineer, I wouldn’t trust the community-driven register definition because even vendors have some bug on it and it is almost impossible for the community to write a better register definitions than the vendors themselves. This is a vendors’ job, not the community's.
Any hints on where to look?
I have implemented several soft synths on the Teensy, both with and without the audio library. It works.
Here's the datasheet for the ATMega328: http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-42735-...
From what I gather, the technique is to change the PWM in an interrupt continuously to match the amplitude of your output wave. During that 1ms, what happens? Does the PWM still output a regular wave but I can’t adjust it? Or does the PWM wave itself stop?
So you can find the asm guide here: [0]
The Atmega328's datasheets are here: [1], which includes things like a register breakdown.
[0] https://www.microchip.com/webdoc/avrassembler/index.html
[1] https://www.microchip.com/wwwproducts/en/ATmega328#documents