Embedded in Rust

Embedded in Rust https://blog.japaric.io/ Recent content on Embedded in Rust Hugo -- gohugo.io en-us <a rel="license" href="http://creativecommons.org/licenses/by/4.0/"><img alt="Creative Commons License" src="https://i.creativecommons.org/l/by/4.0/80x15.png" /></a><br/>Jorge Aparicio Sun, 23 Jun 2019 18:00:00 +0200 Real Time For the Masses goes multi-core https://blog.japaric.io/multicore-rtfm/ Sun, 23 Jun 2019 18:00:00 +0200 https://blog.japaric.io/multicore-rtfm/ v0.5.0 of Real Time For the Masses (RTFM), the embedded concurrency framework, is coming out soon-ish – some time after Rust 1.36 is released – and will include experimental support for homogeneous and heterogeneous multi-core Cortex-M devices. This blog post covers the upcoming multi-core API and includes a refresher on the single-core API. Heterogeneous support in μAMP But first, one update relevant to multi-core RTFM from the μAMP (microamp) front since the last post: cargo-microamp has gained support for heterogeneous multi-core devices. μAMP: Asymmetric Multi-Processing on microcontrollers https://blog.japaric.io/microamp/ Fri, 10 May 2019 15:33:00 +0200 https://blog.japaric.io/microamp/ An asymmetric multiprocessing (AMP) system is a multiprocessor computer system where not all of the multiple interconnected central processing units (CPUs) are treated equally. – Wikipedia What is μAMP? microamp (styled as μAMP) is a framework (library plus cargo subcommand) for building bare-metal applications that target AMP systems. This blog post is a deep dive into this framework which serves as the core foundation of the multi-core version of Real Time For the Masses (RTFM), which I’ll cover in the next blog post. cargo-call-stack, part 2: getting call graph information from rustc https://blog.japaric.io/stack-analysis-2/ Sat, 13 Apr 2019 16:39:52 +0200 https://blog.japaric.io/stack-analysis-2/ In a previous post I described the current implementation of cargo-call-stack, a static stack usage analysis tool. In the second part of that post I described the problems the tool runs into when dealing with indirect function calls (both function pointer calls and dynamic dispatch) and proposed improving the output of the tool by having rustc inject type information in the LLVM IR it produces. While discussing that idea with rustc developers they noted that the compiler could emit information that’s more relevant to call graph analysis than just the signatures of functions and trait methods. Implementing a static stack usage analysis tool https://blog.japaric.io/stack-analysis/ Wed, 13 Mar 2019 20:09:57 +0100 https://blog.japaric.io/stack-analysis/ (This blog covers the implementation details of cargo-call-stack v0.1.2. If you are only interested in using the tool these tweets and the README will give you an idea of what it can do.) Motivation So, why would you ever want to analyze the stack usage of your program at compile time? The obvious answer is when you want to know if your application can stack overflow at runtime without actually running your program. RTFM v0.4: +stable, software tasks, message passing and a timer queue https://blog.japaric.io/rtfm-v4/ Wed, 19 Dec 2018 18:40:45 +0100 https://blog.japaric.io/rtfm-v4/ Hey there! It’s been a long time since my last post. Today I’m pleased to announce v0.4.0 of the Real Time for The Masses framework (AKA RTFM), a concurrency framework for building real time applications. The greatest new feature, IMO, is that RTFM now works on stable Rust (1.31+)! 🎉 🎉 🎉 This release also packs quite a few new features which I’ll briefly cover in this post. For a more throughout explanation of RTFM’s task model and its capabilities check out the RTFM book, which includes examples you can run on your laptop (yay for emulation), and the API documentation. Weekly driver 4: ENC28J60, Ethernet for your microcontroller https://blog.japaric.io/wd-4-enc28j60/ Tue, 13 Mar 2018 04:32:18 +0100 https://blog.japaric.io/wd-4-enc28j60/ It’s week number 11 and the weekly driver #4 is out! Last time, I did drivers 1 and 2 so you may be wondering where’s driver 3? Driver #3, the MCP3008 (8 channel 10-bit ADC with SPI interface), was covered by @pcein in their blog. Also, as of now there are at least 14 (!) drivers being worked on by the community. This week I’m releasing a driver for the ENC28J60, an Ethernet controller with SPI interface. Weekly driver 1 & 2: L3GD20, LSM303DLHC and Madgwick https://blog.japaric.io/wd-1-2-l3gd20-lsm303dlhc-madgwick/ Mon, 19 Feb 2018 15:57:59 +0100 https://blog.japaric.io/wd-1-2-l3gd20-lsm303dlhc-madgwick/ Oh, time flies. It’s already week 8 and we have zero weekly driver posts out there – don’t worry though because there’s plenty of drivers and embedded-hal implementations in the works. To play catch up in this post I’ll cover two embedded-hal drivers: the l3gd20 and the lsm303dlhc. The L3GD20 is an IC that contains a gyroscope and exposes I2C and SPI interfaces; the LSM303DLHC is an IC that contains an accelerometer and a magnetometer, and exposes an I2C interface. Zero cost stack overflow protection for ARM Cortex-M devices https://blog.japaric.io/stack-overflow-protection/ Sat, 17 Feb 2018 18:16:39 +0100 https://blog.japaric.io/stack-overflow-protection/ One of the core features of Rust is memory safety. Whenever possible the compiler enforces memory safety at compile. One example of this is the borrow checker which prevents data races, iterator invalidation, pointer invalidation and other issues at compile time. Other memory problems like buffer overflows can’t be prevented at compile time. In those cases the compiler inserts runtime checks, bounds checks in this case, to enforce memory safety at runtime. Memory safe DMA transfers https://blog.japaric.io/safe-dma/ Fri, 09 Feb 2018 11:47:30 +0100 https://blog.japaric.io/safe-dma/ UPDATE Given the comments I’ve received so far I think I should more explicitly mention that the context here are systems that lack a MMU and where a memory allocator may or may not be available or desirable, e.g. Cortex-M microcontrollers. In this post I’ll describe an approach to building memory safe DMA based APIs. DMA? DMA stands for Direct Memory Access and it’s a peripheral used for transferring data between two memory locations in parallel to the operation of the core processor. RTFM v0.3.0: safe `&'static mut T` and less locks https://blog.japaric.io/rtfm-v3/ Mon, 22 Jan 2018 19:58:35 +0100 https://blog.japaric.io/rtfm-v3/ RTFM (Real Time For the Masses) v0.3.0 is out! This blog post will cover the goodies of this new release. The minor (breaking) release was mainly to become compatible with the new IO model presented in my previous blog post, but a new feature also shipped with this release: safe creation of &'static mut references. First, let’s look at one feature that landed in v0.2.1 but that didn’t get documented in this blog, yet it was essential to adapt RTFM to the new IO model: Embedded Rust in 2018 https://blog.japaric.io/embedded-rust-in-2018/ Sun, 21 Jan 2018 22:10:38 +0100 https://blog.japaric.io/embedded-rust-in-2018/ This is my #Rust2018 blog post. These are some things I think the Rust team needs to address this year to make Rust a (more) viable alternative to C/C++ in the area of bare metal (i.e. no_std) embedded applications. Stability Here’s a list of breakage / regressions I encountered (i.e. that I had to work around / fix) during 2017: Changes in target specification files broke compilation of no_std projects that use custom targets. Brave new I/O https://blog.japaric.io/brave-new-io/ Thu, 18 Jan 2018 00:44:18 +0100 https://blog.japaric.io/brave-new-io/ Hey there! It’s been a while. I’ve been working on some cool stuff for you. Now that’s in more or less good shape I can blog about it! This blog post introduces our new approach to I/O in embedded contexts. Overview: The register model First some background information In microcontrollers all external I/O requires interacting with peripherals. Peripherals are additional pieces of electronics that sit in the same chip / package as the core processor. RTFM v2: simpler, less overhead and more device support https://blog.japaric.io/rtfm-v2/ Sat, 29 Jul 2017 02:39:45 -0500 https://blog.japaric.io/rtfm-v2/ Hiya folks! It’s been a while. Today I’m pleased to present the next version of the Real Time For the Masses framework: cortex-m-rtfm v0.2.0 or just v2, which is how I like to call it. Here’s the executive summary of the changes: v2 is simpler. v1 used a bunch of tokens – ceiling tokens, priority tokens, preemption threshold tokens and task tokens – for memory safety; this made the API rather boilerplatery. A CPU usage monitor for the RTFM framework https://blog.japaric.io/cpu-monitor/ Sun, 04 Jun 2017 14:08:14 -0500 https://blog.japaric.io/cpu-monitor/ We have used the RTFM framework in the previous posts but put most of the application logic in tasks, and always sent the processor to sleep in the idle function. In this post we’ll put the idle function to better use and build a CPU usage monitor there. Idle The main logic of the CPU usage monitor will be in the idle function. Let’s see how it works: // RESOURCES peripherals! The ITM and the quest for faster logging https://blog.japaric.io/itm/ Wed, 31 May 2017 21:14:06 -0500 https://blog.japaric.io/itm/ In this post we’ll explore the different alternatives one has to log data from a microcontroller to some host machine. Be it for printf style debugging or for logging sensor data. The Blue Pill This time I’ll use a different development board: the Blue Pill. On the center the Blue Pill development board. On the left side a UART to USB adapter based on the CH340G. On the right side an SWD programmer: a Chinese clone of the ST-LINK. Overhead analysis of the RTFM framework https://blog.japaric.io/rtfm-overhead/ Tue, 23 May 2017 09:33:23 -0500 https://blog.japaric.io/rtfm-overhead/ In the last post I introduced the RTFM framework, and made several claims about it being highly efficient both in memory usage and runtime overhead. In this post I’ll analyze all the RTFM concurrency primitives to back up those claims. To do that I’ll first introduce a non-invasive timing method that’s accurate to a single clock cycle, which is the time the processor spends to execute one of the simplest instructions. Fearless concurrency in your microcontroller https://blog.japaric.io/fearless-concurrency/ Tue, 09 May 2017 09:07:39 -0500 https://blog.japaric.io/fearless-concurrency/ I want to start by thanking all the people that has sent improvements and comments to all the crates and tools I presented in the last blog post. The Rust community rocks! Last time I showed you how to easily develop Rust programs for pretty much any ARM Cortex-M microcontroller. In this post I’ll show you one way of doing memory safe concurrency. It’s important to note that the Rust language doesn’t impose a single concurrency model. Rust your ARM microcontroller! https://blog.japaric.io/quickstart/ Fri, 28 Apr 2017 22:05:45 -0500 https://blog.japaric.io/quickstart/ IMPORTANT! READ THIS! Hello there! This article is outdated and following it will only confuse you. Check out the embedded Rust book and the rest of the embedded WG bookshelf for up to date and maintained documentation on embedded Rust development. If you still want to read this post, for historical reasons and what now, scroll down. Want to program your microcontroller in Rust but your microcontroller vendor doesn’t provide a Rust HAL / SDK? Hello, world! https://blog.japaric.io/hello-world/ Mon, 24 Apr 2017 08:00:08 -0500 https://blog.japaric.io/hello-world/ Hey there! Welcome to my blog, where I’ll be writing about Rust and embedded systems-y stuff – that’s it, mainly about programming ARM Cortex-M microcontrollers as that’s what Rust best supports today 1. But, I’m interested in anything that has a #![no_std] attribute in it 2 so I may cover some other stuff as well. That being said, this first post is neither about Rust or embedded stuff as it’s mainly for testing my blogging setup; so, why not write about that instead?