7 ms·

Embedded in Rust: Brave new I/O

365 points by kartD 9y ago

vvanders 9y ago
This is amazing. Register and peripheral config is so easy to fuck up and waste a whole day chasing down because of limited debugging capabilities on these platforms. I've hit just about every one of those scenarios these compile-time guards now catch on one project or another. Kudos, can't wait to see where to goes from here.
- jfaucett 9y ago
  I know this has me really exited too. I think there is so much potential for rust in the embedded space. Personally, I'd be content if the core team just concentrated on making rust the best platform for doing embedded programming. IMHO that's where rust can really blow the competition away.
  - petra 9y ago
    The hard challenge in embedded is porting to every mcu. Can this be done without convincing mcu companies to do it themselves ?
    - Eridrus 9y ago
      They could use Julia's "resurrected LLVM "C Backend"" and compile down to C, and then let developers use existing tools to get running on their MCU. Would probably mess with the debugging experience though.
      - steveklabnik 9y ago
        mrustc would be another path here.
      - nitrogen 9y ago
        Would probably mess with the debugging experience though. If the compiler in question supports the #line directive, it might not be too bad.
    - henrikeh 9y ago
      Honestly it depends upon what people expect from "the port". A lot of people seem to be content with Arduino-like software compatibility: high-level constructs that offer basic functionality expected across a larger number of mcu's. Even something as "simple" as a timer peripheral will vary greatly across manufacturers and families of mcu's -- something you'd care about for real-time control, but not care about in other cases. 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.
      - vvanders 9y ago
        > 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. 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.
      - 9y ago
    - xfer 9y ago
      I have an xmos board(xcore architecture), although llvm has a backend for it, it is missing debugging support for timing analysis(XTA) and also outdated so potentially missing on various size optimizations. 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) 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.
    - jfaucett 9y ago
      > The hard challenge in embedded is porting to every mcu. Can this be done without convincing mcu companies to do it themselves ? 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.
  - steveklabnik 9y ago
    FWIW, I share your feelings regarding prioritizing this. In general, it's something we want, but we're still discussing what the overall goals for this year will be. We'll see!
  - jvns 9y ago
    if you have ideas about what Rust should focus on in 2018, consider writing a blog post about your ideas! they have an open call for posts right now. https://blog.rust-lang.org/2018/01/03/new-years-rust-a-call-for-community-blogposts.html https://blog.rust-lang.org/2018/01/03/new-years-rust-a-call-...
- robotjosh 9y ago
  What is limiting about being able to step thru each instruction?
  - vvanders 9y ago
    That's assuming that you have a functional ICE[1] and aren't dealing with a timing issue in another subsystem :). 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. [1] https://en.wikipedia.org/wiki/In-circuit_emulation https://en.wikipedia.org/wiki/In-circuit_emulation
    - alxlaz 9y ago
      Why are you doing any kind of professional work, at such a low level, without an ICE?
      - __david__ 9y ago
        Because ICEs are overrated. Many systems can't be debugged by single stepping (think servos or anything with physical hardware being controlled). ICEs rarely work well—every single one I've ever used was completely unreliable and required lots of fiddling to make it work. And then the next day you had to start the whole fiddling process over again. In the end they aren't very productive except for very specific types of bugs (they are invaluable in the very beginning of a project when you are bringing up a board). Once everything is generally up and running I find them to be pretty useless.
  - IshKebab 9y ago
    Yeah if you can get that to work. It's usually a serious hassle. 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.
Animats 9y ago
Nice. So how many manufacturers create those XML files which describe all the registers? Is that common in the Arduino community, for example?
- dbcurtis 9y ago
  AFAIK SVD files are an ARM thing.
  - timerol 9y ago
    Yeah, they are ARM specific, at least according to https://siliconlabs.github.io/Gecko_SDK_Doc/CMSIS/SVD/html/index.html https://siliconlabs.github.io/Gecko_SDK_Doc/CMSIS/SVD/html/i.... "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."
  - twic 9y ago
    Is it that it would be impossible to write an SVD file for another architecture, or just that vendors don't do it? 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.
    - jdub 9y ago
      DeviceTree is the standard / tooling you'll see outside ARM micro-controllers. Started on Power, then found a place in Linux's ARM tree, and is now spreading further.
    - kbumsik 9y ago
      Probably, but companies wouldn’t do it since they have their own tooling. And I don’t think the community would like to write it neither. Look at a SVD file for a single MCU. https://github.com/posborne/cmsis-svd/blob/master/data/STMicro/STM32F100xx.svd 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.
aidos 9y ago
OT but I’ve just got into microcontrollers for the first time in the last week via an Arduino Uno. I’m absolutely in love with it and I now need to go a bit deeper (I’m working on a synth). I get a lot of the concepts like the registers to control the timers / interrupts but I’ve found a good guide to be lacking. I haven’t seen a list anywhere of all the available registers and what the bits do. I get that it’s different for different chips but I thought the info for more common ones (like the ATMega328) would be easier to come by. Any hints on where to look?
- flapjackdan 9y ago
  The manufacturer website is where you usually want to go to find the documentation. The product datasheet will specify the peripherals and register set for the chip you're looking at, including a description of each register and the fields within them. Some companies have a different name for this document. E.g. ST usually define their registers in a Reference Manual. Here's the datasheet for the ATMega328: http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-42735-8-bit-AVR-Microcontroller-ATmega328-328P_Datasheet.pdf http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-42735-...
  - aidos 9y ago
    Got it. Thanks. Not sure I’m any the wiser flicking through there to be honest!
  - baobrien 9y ago
    To add, ST has a 'datasheet' and a 'reference manual' for each chip and chip family. The datasheet is usually under 200 pages and is focused more on electrical information and is focused on a few chips. The ST reference manuals are generally over 1000 pages and cover all of the software/register information for a family of parts.
- deleted 9y ago
  [deleted]
- shakna 9y ago
  Arduino is AVR, who are currently owned by MicroChip. 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 https://www.microchip.com/webdoc/avrassembler/index.html [1] https://www.microchip.com/wwwproducts/en/ATmega328#documents https://www.microchip.com/wwwproducts/en/ATmega328#documents
robotjosh 9y ago
These problems that embedded rust is trying to solve are not a big deal. In C you try to minimize what happens in any interrupt, usually just set a flag, save a result, and return. You generally use atomic instructions on gpio. To set or clear a bit mask is atomic so there is not much reason to read-modify-write gpio in an interrupt or anywhere. I think these solutions would create more work than they save.
- robert_foss 9y ago
  I can't say that I agree. I would rather thread through some boilplate, rather than have a hard to debug issue on a platform that I have low visibility into.
  - robotjosh 9y ago
    It sounds like this would work for beginners or certain people who know rust and not C. A new firmware language could never be widely adopted if it is not made for the career firmware engineer to use.
    - weberc2 9y ago
      I think you give firmware engineers too little credit.
- vvanders 9y ago
  Keep reading, they also cover dealing with exclusive access to subsystems. I could totally see this being applied to DMA and other long-running peripherals to great success. 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.
  - __david__ 9y ago
Animats 9y ago
This is, amusingly, a lot like Modula I, circa 1979. That had language support for device registers, cooperative multiprogramming, and interrupts. A very nice way to program a PDP-11 at the bare metal level.
mikepurvis 9y ago
This is super exciting, and it smacks a little bit of the C++11 variadic template based HW init scheme explored in the stm32plus library, eg: https://github.com/andysworkshop/stm32plus/blob/master/examples/timer_dual_pwm_gpio_out/timer_dual_pwm_gpio_out.cpp#L48-L57 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?
- detuur 9y ago
  Looks to me like this is something that can be added to the take() function. After all, you're generating the crate yourself with svd2rust. I wonder if these "auto-crates" would be viable for submission to crates.io. This way you could solve that HW bug once and for all for everyone.
kurtisc 9y ago
This doesn't seem particularly courageous, plucky, fearless, valiant, valorous, intrepid, heroic, lionhearted, manful, macho, bold, daring, daredevil, adventurous, or audacious.
deleted 9y ago
[deleted]
bfrog 9y ago
I ordered up a stm32f3 discovery to tinker with this

365 points by kartD 9y ago

This is amazing. Register and peripheral config is so easy to fuck up and waste a whole day chasing down because of limited debugging capabilities on these platforms. I've hit just about every one of those scenarios these compile-time guards now catch on one project or another. Kudos, can't wait to see where to goes from here.

jfaucett 9y ago
I know this has me really exited too. I think there is so much potential for rust in the embedded space. Personally, I'd be content if the core team just concentrated on making rust the best platform for doing embedded programming. IMHO that's where rust can really blow the competition away.
- petra 9y ago
  The hard challenge in embedded is porting to every mcu. Can this be done without convincing mcu companies to do it themselves ?
  - Eridrus 9y ago
    They could use Julia's "resurrected LLVM "C Backend"" and compile down to C, and then let developers use existing tools to get running on their MCU. Would probably mess with the debugging experience though.
    - steveklabnik 9y ago
      mrustc would be another path here.
    - nitrogen 9y ago
      Would probably mess with the debugging experience though. If the compiler in question supports the #line directive, it might not be too bad.
  - henrikeh 9y ago
    Honestly it depends upon what people expect from "the port". A lot of people seem to be content with Arduino-like software compatibility: high-level constructs that offer basic functionality expected across a larger number of mcu's. Even something as "simple" as a timer peripheral will vary greatly across manufacturers and families of mcu's -- something you'd care about for real-time control, but not care about in other cases. 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.
    - vvanders 9y ago
      > 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. 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.
    - 9y ago
  - xfer 9y ago
    I have an xmos board(xcore architecture), although llvm has a backend for it, it is missing debugging support for timing analysis(XTA) and also outdated so potentially missing on various size optimizations. 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) 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.
  - jfaucett 9y ago
    > The hard challenge in embedded is porting to every mcu. Can this be done without convincing mcu companies to do it themselves ? 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.
- steveklabnik 9y ago
  FWIW, I share your feelings regarding prioritizing this. In general, it's something we want, but we're still discussing what the overall goals for this year will be. We'll see!
- jvns 9y ago
  if you have ideas about what Rust should focus on in 2018, consider writing a blog post about your ideas! they have an open call for posts right now. https://blog.rust-lang.org/2018/01/03/new-years-rust-a-call-for-community-blogposts.html https://blog.rust-lang.org/2018/01/03/new-years-rust-a-call-...
robotjosh 9y ago
What is limiting about being able to step thru each instruction?
- vvanders 9y ago
  That's assuming that you have a functional ICE[1] and aren't dealing with a timing issue in another subsystem :). 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. [1] https://en.wikipedia.org/wiki/In-circuit_emulation https://en.wikipedia.org/wiki/In-circuit_emulation
  - alxlaz 9y ago
    Why are you doing any kind of professional work, at such a low level, without an ICE?
    - __david__ 9y ago
      Because ICEs are overrated. Many systems can't be debugged by single stepping (think servos or anything with physical hardware being controlled). ICEs rarely work well—every single one I've ever used was completely unreliable and required lots of fiddling to make it work. And then the next day you had to start the whole fiddling process over again. In the end they aren't very productive except for very specific types of bugs (they are invaluable in the very beginning of a project when you are bringing up a board). Once everything is generally up and running I find them to be pretty useless.
- IshKebab 9y ago
  Yeah if you can get that to work. It's usually a serious hassle. 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.

Animats 9y ago

Nice. So how many manufacturers create those XML files which describe all the registers? Is that common in the Arduino community, for example?

dbcurtis 9y ago
AFAIK SVD files are an ARM thing.
- timerol 9y ago
  Yeah, they are ARM specific, at least according to https://siliconlabs.github.io/Gecko_SDK_Doc/CMSIS/SVD/html/index.html https://siliconlabs.github.io/Gecko_SDK_Doc/CMSIS/SVD/html/i.... "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."
- twic 9y ago
  Is it that it would be impossible to write an SVD file for another architecture, or just that vendors don't do it? 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.
  - jdub 9y ago
    DeviceTree is the standard / tooling you'll see outside ARM micro-controllers. Started on Power, then found a place in Linux's ARM tree, and is now spreading further.
  - kbumsik 9y ago
    Probably, but companies wouldn’t do it since they have their own tooling. And I don’t think the community would like to write it neither. Look at a SVD file for a single MCU. https://github.com/posborne/cmsis-svd/blob/master/data/STMicro/STM32F100xx.svd 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.

aidos 9y ago

OT but I’ve just got into microcontrollers for the first time in the last week via an Arduino Uno. I’m absolutely in love with it and I now need to go a bit deeper (I’m working on a synth). I get a lot of the concepts like the registers to control the timers / interrupts but I’ve found a good guide to be lacking. I haven’t seen a list anywhere of all the available registers and what the bits do. I get that it’s different for different chips but I thought the info for more common ones (like the ATMega328) would be easier to come by. Any hints on where to look?

flapjackdan 9y ago
The manufacturer website is where you usually want to go to find the documentation. The product datasheet will specify the peripherals and register set for the chip you're looking at, including a description of each register and the fields within them. Some companies have a different name for this document. E.g. ST usually define their registers in a Reference Manual. Here's the datasheet for the ATMega328: http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-42735-8-bit-AVR-Microcontroller-ATmega328-328P_Datasheet.pdf http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-42735-...
- aidos 9y ago
  Got it. Thanks. Not sure I’m any the wiser flicking through there to be honest!
- baobrien 9y ago
  To add, ST has a 'datasheet' and a 'reference manual' for each chip and chip family. The datasheet is usually under 200 pages and is focused more on electrical information and is focused on a few chips. The ST reference manuals are generally over 1000 pages and cover all of the software/register information for a family of parts.
deleted 9y ago
[deleted]
shakna 9y ago
Arduino is AVR, who are currently owned by MicroChip. 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 https://www.microchip.com/webdoc/avrassembler/index.html [1] https://www.microchip.com/wwwproducts/en/ATmega328#documents https://www.microchip.com/wwwproducts/en/ATmega328#documents

robotjosh 9y ago

These problems that embedded rust is trying to solve are not a big deal. In C you try to minimize what happens in any interrupt, usually just set a flag, save a result, and return. You generally use atomic instructions on gpio. To set or clear a bit mask is atomic so there is not much reason to read-modify-write gpio in an interrupt or anywhere. I think these solutions would create more work than they save.

robert_foss 9y ago
I can't say that I agree. I would rather thread through some boilplate, rather than have a hard to debug issue on a platform that I have low visibility into.
- robotjosh 9y ago
  It sounds like this would work for beginners or certain people who know rust and not C. A new firmware language could never be widely adopted if it is not made for the career firmware engineer to use.
  - weberc2 9y ago
    I think you give firmware engineers too little credit.
vvanders 9y ago
Keep reading, they also cover dealing with exclusive access to subsystems. I could totally see this being applied to DMA and other long-running peripherals to great success. 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.
- __david__ 9y ago

Animats 9y ago

This is, amusingly, a lot like Modula I, circa 1979. That had language support for device registers, cooperative multiprogramming, and interrupts. A very nice way to program a PDP-11 at the bare metal level.

mikepurvis 9y ago

This is super exciting, and it smacks a little bit of the C++11 variadic template based HW init scheme explored in the stm32plus library, eg: https://github.com/andysworkshop/stm32plus/blob/master/examples/timer_dual_pwm_gpio_out/timer_dual_pwm_gpio_out.cpp#L48-L57 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?

detuur 9y ago
Looks to me like this is something that can be added to the take() function. After all, you're generating the crate yourself with svd2rust. I wonder if these "auto-crates" would be viable for submission to crates.io. This way you could solve that HW bug once and for all for everyone.

kurtisc 9y ago

This doesn't seem particularly courageous, plucky, fearless, valiant, valorous, intrepid, heroic, lionhearted, manful, macho, bold, daring, daredevil, adventurous, or audacious.

deleted 9y ago

[deleted]

bfrog 9y ago

I ordered up a stm32f3 discovery to tinker with this