Matt Gleich -> 2/19/2022
The past two weeks have been full of some exciting developments. From learning how to make PCBs with KiCad to flashing my first binary (written in rust) to a microcontroller there have been updates on all fronts of the project. Below is a summary of some of the major developments that have been made over the last 2 weeks.
Using a course I found on Udemy I was able to develop my first PCB. This PCB (pictured below) is just a test board so I can get myself familiar with the general process of developing PCBs and ordering them. All that this PCB does is turn on an LED when the user presses a button, all while drawing power from an onboard coin cell battery.
In order to make this PCB, I needed to learn about the PCB development process. The process first starts with the schematic which is just the basic electrical functions of the circuit. This is all done inside of an application inside of KiCad called Eeschema. Using the ERC (electrical rules check) we can make sure that the circuit meets some basic qualifications. It isn’t supposed to ensure functionality (we use breadboards for that), just basic connections and electrical rules.
Once we have the circuit schematic done in Eeschema we can move on to designing what the PCB will look like. Before we do that we need to pair the symbols found in Eeschema with footprints. Footprints, like their name suggests, outline what the actual device looks like on the board. The image above is from PCBnew and shows the actual size for certain devices like the resistor (R1). Once we are done with this we can generate gerber files which can then be sent off to the manufacturer. I ended up going with PCBWay to manufacture the boards because of their price, board control (e.g. materials, color, etc.), and reputation among hobbyists. I ordered the boards at the start of last week and they should be coming next Thursday.
The Rust programming language is the language I have selected to use for programming the RP2040. Between the memory management benefits and the modern ecosystem/language design, it was an easy choice to make. I might end up having to switch to C++ if I can’t end up writing my own PAC for all of the devices I need to use. In the last two weeks, I’ve been reading the Rust Discovery book. Below I’ll discuss some of what I’ve learned so far.
Rust’s Embedded Ecosystem
Rust’s embedded ecosystem is a very important part of writing embedded Rust applications. It’s essentially a number of Rust libraries working together. Libraries in Rust are called crates. The core parts are:
- HALs: Stands for Hardware Abstraction Layer. This provides an abstraction library for common chip features like I2C, SPI, and timers.
- PACs: Stands for Peripheral Access Crate. This provides an abstraction over specific devices such as an LCD display.
- embedded-hal: A generic crate that provides traits that HALs and PACs can implement or derive from.
All of these parts are fairly generic and platform-agnostic. This means that I could, in theory, change the microcontroller used in this project without having to find new crates.
Flashing and Debugging
Flashing the code is essentially like “uploading the code” to the microcontroller. To do this I use a cargo subcommand crate called cargo-embed. For debugging I am using lldb as gdb doesn’t seem to be supported for arm64 darwin at the moment. A debugger allows me to stop the code at certain points (called breakpoints) and inspect the memory to see what values variables hold and what functions have been called at that point.
Over the next week I am planning on getting the following things done:
- Finish the discovery book.
- Solder and inspect ordered PCBs from PCBWay. They should be arriving Thursday from DHL.
- Finish basic PAC for the IS31FL3731.