DEV Community: Filip

Universally Stupid: Battling USB on a microcontroller with Rust

Filip — Tue, 07 Jan 2020 08:38:14 +0000

Of ancient runes,
a cursed mess -
STM32
OTG FS

WTF is USB

It's everywhere. It replaced many different connectors of the past - sometimes by just being able to emulate them, as is the case with serial ports. Some devices use it just for the power. But it's still an obtuse piece of design-by-committee which is difficult to implement right even if you've been doing this sort of thing for a long time indeed. Just ask the Raspberry Pi people!

I'm going to skip over a lot of the USB spec itself, because it's huge. Indeed, even a website calling itself USB Made Simple comes up to seven parts, not including extra material. I would try to skim through the USB 2.0 standard but apparently it's hosted by someone who doesn't understand how to set up TLS in nginx:

No, I'm going to focus only on the bits that I found I needed in order to get my device to work. So starting from the electricals, a compliant-ish cable will have the following wires inside of it:

Red for VBUS (nominal 5V), as expected
Black for GND, also as expected
Green for D+
White for D-

Everything is wrapped in a thin metallised film which acts as a shield against RF interference, which is a good job that I slit everything open and started messing about with the wires. Here's one of my breakout boards I've made. I added a Schottky diode to prevent stupid things from happening, like the computer trying push current to itself.

For a brief mention of the theory - USB is a single-master, packet-switched, tiered star network where the host controls a number of peripherals that each have a hardware address (ish) and a network address (ish). The hardware address is composed of the Vendor ID and Product ID (VID and PID). If you want your device to be fully legit, you'll probably need to buy yourself a VID which is kinda expensive - either $5000 per year if you want to be a member of the USB Implementors Forum or $6000 one off purchase (source), and there's still lots of hoops you have to jump through. Or for fewer hoops, most of them based around your product needing to be open source, you can get yourself a PID from pid.codes for free. And of course just for testing, you can use any VID/PID you'd like but remember this is not compliant with anything.

There's also USB OTG ("On The Go") which allows connections between two embedded devices, but I don't think I ever saw it used.

Now there's two of them!

There are actually two different USB implementations in the STM32 range: a USB Device core available on lower tier MCUs like F0-F3, and USB OTG cores available on higher tier MCUs like F4 and up. To make matters worse, there are two flavours of the USB OTG core. There's the Full Speed version which allows for up to 12Mbit/s data rates with a transceiver (or PHY) built into the MCU silicon, and a High Speed version which allows for up to 480 Mbit/s rates but requires an external transceiver, connected via a parallel interface to the MCU. Or, the High Speed core can also use the built-in Full Speed transceiver to achieve 12Mbit/s. Since both cores support OTG they automatically also support USB 2.0. Slightly confused? Yeah, me too.

It should also be noted that very similar USB OTG cores can be found in RISC-V MCUs made by the company GigaDevice which tries to compete with ST by just straight up cloning their chips. The reason is that they were originally designed by a company called Synopsys.

A rusty old bus

Is there Rust support for these cores? Kinda. There is a project aiming to create a library for writing USB peripherals with the Synopsys USB OTG cores, which would support both the STM32F4 and up, as well as the weird GigaDevice parts. It can be found here:

https://github.com/stm32-rs/synopsys-usb-otg

To use the USB OTG FS peripheral (plenty fast enough for a keyboard and serial port), you need to route D- to PA11 and D+ to PA12. You should also connect the USB 5V to the E5V pin on the Nucleo board, and switch the jumper for where the board will take its 5V from from U5V to E5V (Note that the Nucleo F446ZE board has USB OTG FS broken out already into a connector). There are some requirements as to how fast a particular clock needs to be. Also, you need to run a forked version of the HAL crate because it has some modifications that are required to support the USB functionality. This is an edge so bleeding, all the local vampires are trying to get in on the action.

As luck would have it, there is some example code for the F446 to borrow from. However, the luck ends here.

From here onwards, it's all pain.

It's surprisingly difficult to get any low level information about USB connections from Windows, even if you go through the trouble of installing USBPcap - a useful piece of software for capturing connections between functional devices. Sometimes you won't even get Windows to grace you with an error message - the device you are connecting will just get power and that's about it. Furthermore, it seems like most other example libraries only support the OTG FS peripheral. I tried that with Mbed, a C++ based environment from Arm, and it does actually work on the Nucleo F446RE board, provided that you connect the pins right - I had a dummy USB keyboard enumerating in no time. The Rust library, however, gave me nothing.

The one where you get stuck

I got stuck. The code compiled but nothing actually happened. And at the time of writing this I didn't have any test gear handy so I couldn't stick a logic analyser on the USB lines. I did open a bug on the Synopsys driver crate, and then started properly looking at the code inside, as well as other crates that together create some sort of support for the F446.

I also started looking at C/C++ implementations of the low-level drivers in an attempt to fix the bug, and from there I noticed that there are actually some inconsistencies between the C header files and support libraries that ST provides, and the System View Description XML files that it also has to provide as per ARM licence terms. Namely, the SVD files can be, shall we say, utter garbage, with mislabelled or even missing registers. For instance one of the registers for the "IN endpoint 0" - a control endpoint reserved by the USB spec - that should be called FS_DIEPTXF0 is actually called FS_GNPTXFSIZ in the SVD, and therefore, in all the crates generated from the SVD.

Oh and two other endpoint registers are missing, which means that on this microcontroller that has 6 endpoints (1 control + 5 for application use), only 4 are actually usable from Rust. I have filed a PR with the appropriate base crate to add those endpoints back, however even after applying those changes locally didn't fix my issues. So I need to think about several different strategies to deal with this. First, however, I'd really need to sit down and verify that the generated register maps match what is in the Reference Manual, in case there are more subtle errors within the SVD files.

Try to fix the synopsys-usb-otg crate.
Write my own Rust USB drivers using a model much closer to what the Reference Manual offers, hoping that this would somehow work better than the existing attempt.
Steal the low-level drivers from somewhere else - either the official C/C++ HAL provided by ST or something like the ChibiOS HAL, which do support USB on the F446, and then write a crate that wraps it and exposes it to Rust world.
Abandon the idea of using Rust for everything, use an RTOS, write application code in Rust.

All these options seem kinda daunting. The last one would be perhaps the most productive - after all, I would get a proper HAL, an actual RTOS, and community support from other users of said RTOS. However, it means using a large chunk of code that doesn't have the safety guarantees of Rust. I can minimise that chunk by only using an external USB HAL, which is probably the second most productive, and I may even be able to fit it into the usb-device model allowing me to write my actual keyboard implementation in Rust. I definitely don't want to be writing my own USB drivers given that I don't fully know what I'm doing yet, and I think the preferred option is fixing synopsys-usb-otg, which would also hopefully help other people too. I will however need to buy a logic analyser capable of monitoring and decoding USB Full Speed communications and spend some time learning the usb-device model preferred in the world of embedded Rust.

Learnings

It's a shame that the F446 implementation of USB is getting in the way, because from what I've seen the device side of the protocol is fairly reasonable. And not having proper test gear or much in the way of debugging capabilities doesn't really help either - sure, I can use on-chip debugging to set breakpoints in my code but I still have no visibility into what the USB core itself is doing. I can see that the enable() routine runs but then nothing really happens, and the OS doesn't even see the device.

It also seems that Rust isn't quite as ready for embedded use as I had thought - sure, most of the stuff is there for a few lines of microcontrollers, but it's all third party support, and from what I've seen no manufacturer of MCUs has looked at supporting Rust natively. The lack of support for USB is also very annoying considering that quite a lot of what Rust has to offer would work very well on USB devices. And it seems that nobody has really invested in making a credible USB Host implementation for embedded Rust either.

On the other hand, maybe it would be enough to use Rust for application code and use a C-based library here and there?

What do you think?

What's up, doc? Rust doctests and you

Filip — Mon, 09 Dec 2019 14:16:40 +0000

Rust has an interesting feature in its documentation system: if you're writing a library, it will actually compile and run the examples you give in your rustdoc comments as tests. This took me by surprise because I typically don't expect the documentation examples to immediately work, but I see why this is being done - and it's all to do with the fairly obvious: people will copy and paste examples from docs into their code.

So, doctests try to ensure that the examples you give in your doc comments will actually work. Cool, how do we make use of that?

Denial: Not a river in Egypt

You can ignore doctests. Sometimes you may just want to let an example be an example and not be considered a test.

Acceptance: Let it go

You can also just let doctest run your code examples. What you need to keep in mind is that you will need to use all your types inside the example, like so:

Enlightenment: Writing examples as tests

Tests in Rust are fairly simple - any function that either returns () or panics can be a test, and your doctests can be used as regular tests, with asserts and everything:

Galaxy brain: hiding the tests in your docs

But what if you don't actually want to put all the test code and boilerplate in the documentation example itself? Well, rust has you covered too:

And note how this will look in the generated HTML docs:

(Also see the little warning label on the first example? That's because we marked the first example as an ignored test, and the docs will make a note of that - so that's an incentive to keep your doctests passing.)

Even more

Those are just the basics of doctests in Rust, and if you write libraries in this language, you should definitely check out the documentation tests manual for more - and I bet those examples are also tested 🤯

So you want to write an embedded driver in Rust

Filip — Sat, 07 Dec 2019 21:19:10 +0000

This is the fourth post along my journey to creating a biometric password manager. For an overview of the project, read this post.

For my sins, I decided to pick a project where I try to learn way too many different things at the same time, and choose components with little resources and lots of work that needs to be put into them in order to get them working. And so I ended up in the middle of writing a driver for an obscure part in a language I don't know very well yet, so at least I'm gonna get a blog post out of this whole process.

Poking it with a stick

When you see a new library or piece of tech that you want to use but don't know how, you tend to want to look at the documentation. Except in the case where the documentation's quite limited, partly due to being badly put together, and partly because what little there is, is badly translated. It's like you buy a car but then you realise that the whole dashboard is missing, and what you have is a photo of a dashbord from a similar type of car and a brief guide of what all the wires do, except some of the labels are confusing or wrong. So you decide to make your own dashboard because hey, you bought the car already.

The question is, when you start working on your dashboard, what bit do you hook up first? Ideally you want something that gives you some indication that the car is working, but doesn't actually cause it to do anything. Like the indicator lights. And so the very first request I implemented was for the status of my R502.

When you're dealing with something that you don't fully understand, you tend to go a bit conservative. I wanted to make my test request something that would not alter the state of the device, something analogous to a GET request in a REST API. Many embedded components offer this sort of endpoint one way or another - it's a useful tool for validating that the device has initialised properly and is ready for operation.

Make it work first, make it pretty later, don't skip steps

Prepare to rewrite your code. A lot. You want to create something simple first, but the moment it outlives its usefulness, you have to replace it. Other people will look at your code, do you want them to yell at you on Twitter?

Remember how I said to do the simplest, non-destructive thing first? You should also do it in a fairly simple way. For instance, having a massive match statement that contains a handful of initial commands is okay for the start - but pretty soon you'll start wanting to split up the logic somehow into separate "classes" or modules. The final design of a driver like this should ideally separate the concerns - you'd want to put all the UART interface stuff in one layer, and packet serialisation/deserialisation in another.

One more thing: Write examples. Examples are the most important piece of documentation you can ever produce. They will also help you validate your API design since you'll be forced to use the API you create. In fact, I realised that I needed to change how my API is designed after writing an example that simply authenticates with the R502 - code consuming the library ended up looking clunky and not too much to my liking. Another thing you can do in the example is cheat - while the driver I'm writing is going to target embedded devices through the embedded-hal interface, there's nothing that says you have to do development on an embedded device to begin with - just write some bridge code between your favourite serial port support crate for an x64 architecture and embedded-hal, and you'll be able to compile and run your examples directly on your machine.

Hell is other people's code

Remember the dubiously modified Arduino driver that I mentioned in the last post on the R502? Turns out that actually it can tell you quite a lot about the device if you actually pay attention to it, and also really understand the datasheet. What took me the longest was trying to figure out how to put the individual commands together to actually enroll and verify fingerprints. I remember one day I was trying to figure out what commands to implement after the initial handshake protocol. So I looked more thoroughly at the examples given in the shady Dropbox link that you have to email the manufacturer for. And at some point, it just clicked - but that will only happen if you really take the mental effort to understand the datasheet and the examples, and that's not easy considering that the datasheet is written in bad English and the examples are written in bad C++.

A brief guide to the R502

From what I can understand now, the theory of operation of the R502 fingerprint sensor module is thus:

The front of the device is a type of camera. It uses capacitance to create an image - likely an offshoot from capacitive touch button technology. When you place a finger on the device and tell it to capture an image, it will measure how long it takes to charge each capacitor in (presumably) a matrix of 192x192 pixels, creating an image of your fingerprint. That image is stored in the R502's image buffer. There exist commands to download the image from the R502 to a host, or even upload another from the host - more on that in the speculations below. The R502 can then be instructed to process the image and put the result into one of two character buffers - and I suspect that character here doesn't refer to text but rather the characteristics of your finger.

Two character buffers? Why?

Well, to enroll a fingerprint, you have to capture two images of it. Because the device has little in the way of RAM - although it does rock a full fake STM32 micro - it's easier to have two character buffers rather than two image buffers. It's also easier to run the matching algorithm on already processed fingerprints. And if you want to match a specific fingerprint, you can actually load a character file from R502's internal flash into one of the buffers and capture a new image into another. Then the matching is a question of "do the two character buffers look similar?" There is also a function in the device to match a newly captured fingerprint against the whole library - all enrolled fingerprints on the device. The R502 supports up to 200.

So, what are the common workflows on this device then?

Enrolling a fingerprint

This workflow registers a new fingerprint in the R502.

Capture a fingerprint image
Process it into character buffer 1
Capture another image of the same finger
Process it into character buffer 2
Generate a template from both character buffers
Store the template into the library at the given index

Matching a specific fingerprint

This workflow matches a new fingerprint against a specific,
previously enrolled one.

Capture a fingerprint image
Process it into character buffer 1
Load the requested finger from flash into character buffer 2
Perform a match

Searching for a fingerprint

This workflow matches a new fingerprint against the whole list of
previously enrolled fingers, and tells which one it is if there is
a match.

Capture a fingerprint image
Process it into character buffer 1
Perform a search

The order of doing things

The principal rule of getting things to just work is to do the simplest thing first. However, after implementing a few commands, they are all roughly the same level of simple. Sure, some of them return their data in multiple packets, but we're not doing those yet. The second thing to consider is, which piece of work unblocks the biggest proportion of further development - and in this case, capturing a fingerprint image features in all three core workflows.

I am using github's projects functionaliy here to keep track of what I'm doing in an approximation of a kanban process. Each workflow has a project attached and issues are linked together - at the very least, the final workflow ticket will have a list of dependencies. It should help me keep track of what I need to do next - with the downside of making the project fully project-managed. I mean how am I supposed to just do the things in an order?

What is the R502 for?

So here's the speculation section. The R502 is not an inherently secure device - I would love it to be able to do signed exchanges or even just basic encryption of packets being sent back and forth.

However, that's not quite what the device is designed for - apparently, you can upload fingerprint images to it from a host machine, which in theory means you can network the things and enroll someone on one and have them be enrolled on all of your readers. One of the use cases listed on the manufacturer's website is attendance tracking - for schools or perhaps shift work. Certainly the TSA has been using fingerprint-based shift clocks (which were hilariously vulnerable), and I hear that this method of clocking in and out is popular in various places in Asia.

Some of the other accessories sold by HZ Grow include a control box for a solenoid. You plug your fingerprint reader and lock into it, and it'll lock and unlock stuff for you based on whether the fingerprint is correct. In fact there are gun safes that implement similar mechanisms, again hilariously vulnerable to attacks on anything other than the electronics.

Call the forklift person

Right so I have this driver now. It doesn't do much but you are able to perform one of the main workflows outlined in a previous section, so I decided that it's a good time as any to release the bloody thing to the world and see what comes back. Hopefully nothing nasty. I picked the MIT licence for it because that's the default in Cargo and I don't hold any trademarks I wish to protect or patents I need to grant so there's no point of using the Apache 2.0 licence. Then I made sure I was happy with the documentation and finally did cargo publish.

It's there now. On the internet. Here: https://crates.io/crates/hzgrow-r502 (oh and the docs are here: https://docs.rs/hzgrow-r502/0.1.1/)

I should probably go add it to some list or something, in case someone wants to buy one of those fingerprint modules and start using it for something. There's probably fun to be had. Somehow.

Next time I hope to have more of the functionality done and have a demo running on an actual microcontroller. That should be an amount of fun as well.

Strange parts: fingerprint reader testing

Filip — Tue, 12 Nov 2019 11:08:48 +0000

This is the third post along my journey to creating a biometric password manager. For an overview of the project, read this post.

Questionable findings

Finding the actual fingerprint reader for the job was not easy. Which is crazy considering how popular small fingerprint readers are - chances are, you have one in your pocket right now. The problem is that those parts are made specifically for mobile phone manufacturers, and don't typically trickle down to the average maker. I think at the very beginning of this project, before I even decided to do it, I spent about a day's worth of mashing different keywords together and browsing through parts. Some "highlights":

DigiKey, Mouser, Farnell - the usual suspects - didn't have any modules small enough for my application. Even LCSC, which specialises in Asian brands, doesn't have anything (useful) in stock.
You can find quite a lot of materials about a particular Adafruit part, which unfortunately is flipping huge - the intended use is in fingerprint-enabled safes or locks.
There's quite a lot on Aliexpress and Alibaba, but finding what I want in this particular haystack is never easy, especially with people putting up a clone of a clone, or reselling somebody else's part with $1 markup.
You'll also find tiny little USB dongles that integrate the exact sort of fingerprint reader you might want, as if to taunt you - "you want that sensor, don't you? too bad, you can't have it"
Alibaba is slightly more forthcoming but only if you tweak your keywords just right. fingerprint reader seems to be more suitable for complete devices, fingerprint sensor or module would usually throw up more parts.

For now I settled on a module made by a company called Grow (or Hangzhou Grow), where you can buy the sensors direct on Alibaba. I will probably revisit my part selection before any serious production. However, I now have something semi-reasonable to start prototyping with: the Grow R502 (not an affiliate link). That part itself appears to be a clone of this Miaxis part - however that module is not readily available.

For a more detailed - and by that I mean longer and less coherent - version of this sort of process, I recommend that one EEVBlog video, which is just half an hour of Dave browsing through similarly decreasing in reputation corners of the internet, looking for a perfect display for his project.

"Data" sheets

To get the full datasheet or manual for the sensor, or the example code, SDKs, and other essential equipment, you have to go to the manufacturer's website... and they're not there, because you need to contact them. I think this might be because of some copy protection tactics they're trying to do? In any case, what they will send you eventually is a pair of Dropbox links, one for the manuals for all their products, and one for the code examples and test software.

The datasheet/manual is in delightful Chinglish that you typically only find on cheap tat that Big Clive tears down on YouTube for our collective amusement. You really have to work hard to figure out what they mean. And sometimes they'll have downright incorrect information. For instance, the datasheet would say that the connector on the back of the device is a "MX1.0-6P", presumably meaning Molex. However it's not Molex, but rather a 1mm pitch micro JST type connector. Did I mention the cables are really hard to find? Yes, you could probably make your own, but really, would you like to spend an afternoon crimping wires for a 1 millimetre pitch connectors? Nah.

I would really love it if the manufacturer offered an option of a flat flex cable. That would make integrating this module in a small, USB dongle sized enclosure much easier. Perhaps that's what I'll look for when I revisit my part selections.

Iron work

Because of the small pitch of the original connector, I decided to make a breakout board from some perfboard. It's just connecting some 2.54mm (0.1") headers to the loose ends of the wires coming out of the cable supplied with the sensor. You can see a video of how I did it below:

Next, I just had to hook it up to a serial to USB converter that could also supply 3.3V power to the module. From there, I should be able to run the quasi-supplied software and get the module up and running. I chose to use the ESP-Prog. Normally this device is used to program the ESP8266 and ESP32 microcontrollers, however it can also function as a general purpose USB to serial converter with 3.3V supply and logic. Of the 6 pins on the R502 you only need to connect 4 in order to test the sensor - RXD, TXD, VCC, and GND. The next thing is to run the software.

Software gore

Once I connected everything together, I double checked which serial port I would be using and opened the TestDemo app you get by emailing the company. It lets you interface with the sensor, enrol fingerprints, query them, and notionally also view the image captured by the sensor, but...

This glitch art is lovely, isn't it? It also kinda looks like some fake unicode escaped that one twitter account. Still, the core function of the sensor did work - I was able to enrol a finger, match it again, and have it not find a match if a different finger is used. The Grow rep tells me this sort of image is normal, though, so maybe it's not meant to be like a photograph but some sort of internal representation used by the R502.

Road rage

So now the "only" thing left to do is write some software for the F446RE board that works with this sensor.

For which there are no Rust drivers.

low voice we're gonna have to write a driver aren't we

What is there are some Arduino examples and a library which we can shamelessly pilfer from. It's okay because they were clearly shamelessly pilfered from Adafruit. No, really. As well as source code for what might be the TestDemo application. That folder they send you is really full of stuff - there's apparently a .NET SDK, something for Android, two demo apps, and a copy of the aforementioned Adafruit fingerprint library, no doubt with some customisations of dubious quality.

For a first stab at the driver, I want a really simple API. The fingerprint sensor itself is largely a request-response device, with a separate GPIO line for generating an interrupt when a finger is placed on the reader so it can also act as a button. Something like this would be neat:

let (tx, rx) = serial1.split();
let r502 = R502::new(tx, rx);
let response = r502.send_command(Command::ReadSysPara { address: 0xFFFFFFFF })
                   .unwrap();

The design goal here is to make the driver be consistent with the datasheet, such as it is, which means using the same command and field names, unless they're absolutely ridiculous. I also want to use the embedded-hal crate so that the whole thing can be used on any microcontroller that has Rust support when I'm done with it, and then it can be pilfered back by the manufacturer and stuck in another randomly named RAR file inside that Dropbox link. Your (sic) welcome, HZ Grow!

Up next

Writing drivers is of course going to take a while with the sort of hectic schedule I seem to have found myself in the middle of right now, so I will write another post when I make the first release. Stay tuned for that! And for now - did you ever find yourself having to write drivers for a poorly documented part? Or designed an embedded driver API? I'd like to hear from you in the comments!

Rusted brains: Running Rust firmware on a Cortex-M microcontroller

Filip — Sun, 20 Oct 2019 08:19:15 +0000

This is the second post along my journey to creating a biometric password manager. For an overview of the project, read this post.

Because I want to program my final product in Rust - to get that memory safety and slightly more ergonomic bare-metal programming - I first need to learn how to use Rust on a microcontroller. To help me, I will be writing some relatively simple firmware programs for the Nucleo-F446RE board that I got for the whole project.

Prepare for boarding

Before you embark on some crazy big project with two big unknowns, you should ask one question - will the two big unknowns work together? For Rust and ARM-based microcontrollers, the answer is largely yes. According to the Rust platform support page, the thumbv7em-none-eabi architecture is supported, albeit without the guarantee of Rust tests passing for each build. For now, that's good enough. The next question is, what is the best toolchain? Because ARM is such a broad platform, even if you focus on Cortex-M microcontrollers, there are loads of different options for compiling, flashing, and debugging your code. However most of them are expensive and designed for C/C++. The toolchain I'm using for this project is more of a pick-and-mix than a specialized IDE:

Visual Studio Code for editing, with the Rust extension
GCC + GDB from ARM - mostly for the GDB. Make sure you get the Cortex-R/M version
The thumbv7em-none-eabi target, installed using rustup target add thumbv7em-none-eabi
OpenOCD for connecting GDB to the ST-Link debug hardware present on the Nucleo boards. You can get binaries from the GNU MCU Eclipse OpenOCD fork.
The native debugger extension for debugging in VS Code

When combined, these items provide a rather streamlined coding and debugging experience.

Finding libraries

crates.io is the search engine for Rust packages. For hardware support, the libraries are mercifully named closely after what they do - stm32f4xx-hal is a general-purpose abstraction layer crate for STM32F4xx microcontrollers, and ssd1306 is a driver for the SSD1306 display chip present in all these cheap 128x64 and 128x32 OLED displays you can get from the usual suspects. We will be using both of these later on.

Reading datasheets

Because this is an embedded project, and we are not using Arduino or Mbed, we need to know at least a little about how the specific chip works. These can be found on the STM32F446RE page on ST.com. There is a number of documents on this page, but the most important are those two:

Combined, these two will give you a detailed picture of the peripherals and clock configuration options available on the MCU. On the other hand, they are vast, complex, and utterly dull - take the HAL option if you can. The important part is that these two should be treated as reference documents - don't read them cover to cover, grep through them to find what you need. Unless you have no idea how the chip works to begin with, in which case - ask yourself, what peripherals could you string together to achieve what you need?

What we will be making

The project discussed in this post will be a simple stopwatch. The requirements are as follows:

The stopwatch starts at 00:00.000
Pressing the user button on the board starts the stopwatch
Pressing the button again stops the stopwatch
No lap or reset - to reset the stopwatch, an MCU reset will be required.
Stopwatch resolution should be 1ms
The screen should be updated at least every 100ms

To meet them, the following peripherals will be used:

A hardware timer firing an interrupt every 1ms
SysTick for providing slightly less accurate display update timing
I2C for interfacing with the display
A GPIO input to handle the button

And because this is an embedded system, we should produce a state transition diagram to help us model the thing. For something as simple as this stopwatch, the value of creating one is minimal, but for more complex systems these become very useful for trying to figure out what states the system can reach, and to get an overview of how it behaves overall.

Iteration 1: A non-interactive stopwatch

This is a stopwatch that is even dumber than the final product of this post - it will simply count how much time has passed since the last reset and display it on the screen. It doesn't mean there aren't quite a few things going on already!

For one, we have to set up the internal clocks. I chose to run this example at a respectable core frequency of 48MHz (which is probably overkill but it's easy to set up like that).

// Code is for example only and may not run.
#![no_std]
#![no_main]
extern crate panic_semihosting;
extern crate stm32f4xx_hal as hal;

use crate::hal::{
    prelude::*,
    rcc::{Rcc, Clocks},
    stm32,
};
use cortex_m_rt::{entry};

#[entry]
fn main() -> ! {
    if let (Some(dp), Some(cp)) = (stm32::Peripherals::take(), cortex_m::Peripherals::take()) {
        let rcc = dp.RCC.constrain();
        let clocks = setup_clocks(rcc);
    }

    loop {}
}

fn setup_clocks(rcc: Rcc) -> Clocks {
    return rcc
        .cfgr
        .hclk(48.mhz())
        .sysclk(48.mhz())
        .pclk1(24.mhz())
        .pclk2(24.mhz())
        .freeze();
}

A few things of note already:

Notice that #[entry] annotation on main? It means that it will be the user program's direct entry point, called right after the RAM is initialised.
The function never returns - because there is nothing to return to. No operating system to clean up your program after it exits, no processes, nothing. When you're done, just enter an infinite loop.
Following from (2) - there's no standard library and no allocator. Vector's won't work. Formatting strings requires external crates. It's a weird world.

Alright, that set up our first physical peripheral - the I2C display. To do that, I first have to initialise I2C. And to do that, I have to find two pins that can be used as I2C SCL and SDA lines. To do that, you need to open the datasheet of the specific MCU you have and do some text searches for "SCL" and "SDA" until you know which pins map to which I2C (there are several), and which alternate function the pins need to be in in order to connect to the I2C peripheral. I will be using pins 8 and 9 on port B because that's what strikes my fancy (and those pins are conveniently broken out and labelled as SCL and SDA on the Nucleo board). And they need to be in alternate function 4 because that's what the designers at STMicroelectronics thought will be suitable.

The Rust code, then, to take those GPIO pins and connect them to I2C1 is as follows:

let gpiob = dp.GPIOB.split();
let i2c = I2c::i2c1(
    dp.I2C1,
    (
        gpiob.pb8.into_alternate_af4(),
        gpiob.pb9.into_alternate_af4(),
    ),
    400.khz(),
    clocks,
);

Now, if you're slightly confused about which alternate function you need, Rust will helpfully tell you when you're wrong, and possibly even what you need to do to fix it. It's nice like that.

Now that I have I2C up and running, it's time to set up the display itself. It's easy.

let mut disp: GraphicsMode<_> = SSD1306Builder::new().connect_i2c(i2c).into();
disp.init().unwrap();
disp.flush().unwrap();

The ssd1306 library contains some basic text and drawing functions, so you don't have to worry about writing individual pixels if you don't want to. I also have a simple, display-only example up on github.

And then I had to set up the timer and spend quite a lot of time trying to figure out how exactly I was going to do it, and then even more time debugging why my interrupt service routines are being called back to back. So:

You have to clear the interrupt flag on the peripheral
At the time of writing, there was no way to do that with the HAL
The actual code is very simple, but because it wasn't part of the HAL I had to first try it as unsafe
So I went ahead and opened a PR, which got accepted, merged, and released during writing. Thanks!

Furthermore, the way to share data between the ISRs and the main thread is suitably arcane. However, it looks something like this:

use core::cell::{Cell, RefCell};
use core::ops::DerefMut;
use crate::hal::{interrupt, timer::{Timer, Event}};
use cortex_m::interrupt::{Mutex, free};


// Outside of main():
// Set up two global, mutable, concurrency-safe containers. One is
// simple and holds our milliseconds value. The other holds the
// TIM2 reference which will be available after the setup has finished.
static ELAPSED_MS: Mutex<Cell<u32>> = Mutex::new(Cell::new(0u32));
static TIMER_TIM2: Mutex<RefCell<Option<Timer<stm32::TIM2>>>> = Mutex::new(RefCell::new(None));


// Inside main()
let mut timer = Timer::tim2(dp.TIM2, 1.khz(), clocks);
timer.listen(Event::TimeOut);
// Free enters a critical section and this is necessary to access
// references held by a Mutex<T>.
free(|cs| *TIMER_TIM2.borrow(cs).borrow_mut() = Some(timer));

stm32::NVIC::unpend(stm32f4xx_hal::interrupt::TIM2);
// Unmasking interrupts is inherently unsafe, but this one's fine
unsafe { stm32::NVIC::unmask(stm32f4xx_hal::interrupt::TIM2); };


// The ISR
#[interrupt]
fn TIM2() {
    free(|cs| {
        if let Some(ref mut tim2) = TIMER_TIM2.borrow(cs).borrow_mut().deref_mut() {
            // Clear the interrupt flag so that the ISR does not get retriggered
            // immediately.
            tim2.clear_interrupt(Event::TimeOut);
        }

        let cell = ELAPSED_MS.borrow(cs);
        let val = cell.get();
        cell.replace(val + 1);
    });
}


// Back inside main(), this time accessing the elapsed value
let elapsed = free(|cs| ELAPSED_MS.borrow(cs).get());

This is quite a lot of work too, but that's what you get with concurrency and interrupts. First, we make sure that both the main thread and the ISR can access the elapsed milliseconds value safely - adding critical sections where necessary in order to prevent situations where the ISR is writing the value while the main thread is about to read it. A similar protection has to be applied to the TIMER_TIM2 variable which holds the timer state, since the ISR will need to access it to clear the interrupt. Then, the interrupt has to be enabled, and in two places - one is TIM2 itself, and the other is the NVIC - Nested Vector Interrupt Controller - which triggers ISRs. The ISR then needs to clear the condition that caused the interrupt somehow - otherwise the interrupt will get retriggered immediately. In this case, the clear_interrupt method is called on TIM2.

However at this point, we have our very basic stopwatch! You can see a snapshot of the code on github. And a demo in this crappy gif!

Iteration 2: User input

Alright, so with that first hurdle out of the way - what do we need to make the user button work? Well, we need three things:

We need to make the button pin an input. I use a pull-up resistor so that when the button is not pressed, the line is high, and when it's pressed, it goes low.
We need a way to tell that the button is being pressed. I used, for my sins, another interrupt.
We need something to keep track of the state we're in - recall the transition diagram from above.

So, for #1:

let gpioc = dp.GPIOC.split();
let mut board_btn = gpioc.pc13.into_pull_up_input();
board_btn.make_interrupt_source(&mut dp.SYSCFG);
board_btn.enable_interrupt(&mut dp.EXTI);
board_btn.trigger_on_edge(&mut dp.EXTI, Edge::FALLING);

Very nice API. The HAL really shines here. I did however need to make the Some(dp) a Some(mut dp).

For #2, things get a little more sketchy. I needed to put both the EXTI and the button into global RefCells. Check out that >>>>>!

static EXTI: Mutex<RefCell<Option<stm32::EXTI>>> = Mutex::new(RefCell::new(None));
static BUTTON: Mutex<RefCell<Option<PC13<Input<PullUp>>>>> = Mutex::new(RefCell::new(None));

What is EXTI, anyway? It's a thing (peripheral?) on STM32 microcontrollers which handles EXternally Triggered Interrupts. Or at least I think that's how the initialism works. Honestly the configuration options for the EXTI confuse me to no end and I dread to think what I'd need to do if I have several buttons I want to put interrupts on - as they may go into the same interrupt. Not in this case - I only have one button, so I can just cheat and treat the whole interrupt as coming from that one button press.

#[interrupt]
fn EXTI15_10() {
    free(|cs| {
        let mut btn_ref = BUTTON.borrow(cs).borrow_mut();
        let mut exti_ref = EXTI.borrow(cs).borrow_mut();
        if let (Some(ref mut btn), Some(ref mut exti)) = (btn_ref.deref_mut(), exti_ref.deref_mut())
        {
            btn.clear_interrupt_pending_bit(exti);
        }
    });
}

I still need to clear the interrupt, and then turn that button press into something useful. Which is what #3 is about. I created an enum for the state, and then added it to the global state. I needed to add the Clone and Copy traits in order to get it to work with a Cell, but luckily those can just be derived automatically.

#[derive(Clone, Copy)]
enum StopwatchState {
    Ready,
    Running,
    Stopped,
}

static STATE: Mutex<Cell<StopwatchState>> = Mutex::new(Cell::new(StopwatchState::Ready));

Then, inside the button interrupt handler, I check the state, transition to the next one, and fire appropriate actions. In general this shouldn't be done in an ISR, however because my main thread purposefully sleeps 100ms every cycle, I needed a place where stopping the stopwatch would actually give the correct time. So into the ISR it goes:

let state = STATE.borrow(cs).get();
// Run the state machine in an ISR - probably not something you want to do in most
// cases but this one only starts and stops TIM2 interrupts
match state {
    StopwatchState::Ready => {
        stopwatch_start(cs);
        STATE.borrow(cs).replace(StopwatchState::Running);
    }
    StopwatchState::Running => {
        stopwatch_stop(cs);
        STATE.borrow(cs).replace(StopwatchState::Stopped);
    }
    StopwatchState::Stopped => {}
}

And what are stopwatch_start and stopwatch_stop? You can actually activate and deactivate TIM2 at will, however I felt like it would take too much effort for this example. Instead I do the next best thing and turn the interrupts on and off:

fn stopwatch_start<'cs>(cs: &'cs CriticalSection) {
    ELAPSED_MS.borrow(cs).replace(0);
    unsafe {
        stm32::NVIC::unmask(hal::interrupt::TIM2);
    }
}

fn stopwatch_stop<'cs>(_cs: &'cs CriticalSection) {
    stm32::NVIC::mask(hal::interrupt::TIM2);
}

By the way, those <'cs> things - they are lifetimes, and together with the CriticalSection argument they ensure that this method can only be called from a context where interrupts are disabled.

Finally, there are some changes to the display routine, but those are trivial compared to all the above. And hey - here's a slightly better gif showing the stopwatch in action. This one's hosted at imgur because dev.to broke while uploading :(.

And you can also see the result on github.

A moment to reflect

Take a deep breath. Count to five. You will need it if you decide to implement something like this for your own microcontroller. One of the things that stuck with me from this whole experience is that Arduino and Mbed are about as high-level as you can get in the embedded world without bringing a whole garbage-collected runtime. The HAL I was using is somewhere in between that and writing bits to cryptically named registers (serious note to embedded systems designers - "rcc.apb2enr" is not a good name for anything). It's also definitely incomplete, as Rust is not an officially supported target language by ST. I'm already not looking forward to making USB work. On the other hand, the people involved in the Rust embedded community are amazing. The main hangout is the #rust-embedded channel on Freenode. And you can make PRs to the HAL libraries directly which is not something that can be said about the STMCube-generated code.

Oh yeah, I'll be getting to that - but this post is already too long.

Practical tips on how to not be stuck for too long

Even if you're working with embedded devices in a language officially supported by their vendor, chances are someone has already had your problem and they may even have published something of a solution somewhere. The hardest part is finding those examples and this is where you might need to turn to unconventional sources. Google might not help you - but if you're trying to figure out how to use input.make_interrupt_source() then maybe throwing the method name into github code search will bring something up. And in this case, it did.

It's that or ask on the IRC because I doubt StackOverflow will be particularly forthcoming. What, actual physical things? Variable names with numbers in them? No Tony the Pony for you, my friend!

That's very cool but what's it got to do with biometrics?

Nothing at all, except that I am planning to use the same platform for that actual product too. And it does mean I now know what to expect from the HAL (that I'll need to do some more PRs) and the underlying STM32 device (that I'll definitely want to make those PRs).

Next one though is when I look at the fingerprint sensor. Stay tuned.

My personal dev.to wishlist - what's yours?

Filip — Tue, 17 Sep 2019 13:44:13 +0000

dev.to is pretty cool - I like the relatively stripped-down editing interface and very quick reading experience thanks to the team's amazing work with service workers and other fun stuff.

However no piece of software, or indeed no piece of design is ever perfect. I found a few places where dev.to could be made better - and this is the curated list.

The post editor

I like how simple the post editor is, however in a few places where the "no simpler than it needs to be" principle doesn't quite hold up. For instance, saving drafts still triggers a full page reload that also takes you to the post draft - so if you want to save your post midway through writing or editing it, you will have to click 'Edit' again and find where you were. This is actually at odds with the Preview button which renders the post preview in place, but doesn't actually save your draft.

Wish: Save Draft should not reload the editor and definitely should not take me out of the editor.

I also like the simple image uploader, however in longer posts that can be a little cumbersome as I have to scroll up to find the image upload button.

Wish: The image upload button should be floated next to the editor.

While I'm in the image upload screen - I sometimes have to use dodgy connections and would like to know the progress of my upload. This is generally possible with XMLHttpRequest, and would help me judge whether the upload is just slow or if something's broken.

Wish: Have a progress bar there!

The difficulty system

I like the idea of the difficulty system - perhaps you want to see fewer beginner articles and more in-depth pieces on the pros and cons of particular patterns - but as it stands it seems a bit limited and not very well documented. It's not intuitive when setting the difficulty level for a post - you have to go into the Manage Post menu - and definitely not intuitive when setting the difficulty level for your feed - you have to go into Settings > Misc to set your desired level. I don't think many people change it.

Wish: Make the difficulty setting more prominent for reading

Ideally I would like to see the difficulty slider right beside my feed, and possibly allow me to set specific difficulties for each tag - I might be quite experienced in Java or Vue, but not so much in Rust or hardware development.

Wish: Indicate what you can do in the Manage Post page, or add some of the widgets from it to the bottom of the post.

Conclusion

I hope these suggestions end up reaching the dev.to team - after all, we'll all benefit from a better platform. I also don't think they are must haves, but would definitely be super nice to have.

What about you? What features would you really like to see on dev.to?

Designing a biometric password manager

Filip — Sun, 08 Sep 2019 13:05:33 +0000

Password prompts. Password prompts everywhere. Between logging into my work VPN every day and sudo access on my personal machine, I have to enter multiple passwords multiple times every day. I'm a lousy typist, which means I'll often mistype the passwords in question (especially on those godawful butterfly keyboards) and frustrate myself to no end.

Compare that with my phone, where in most cases I can use my fingerprint to log in and even authorise transactions. Entering passwords or PINs is a back-up option rather than the default. Convenient and secure authentication, based on something you are rather than something you know. Wouldn't it be brilliant if I could do this on every device I use?

Yes, yes it would be. And here's how I want to do it.

The goal

I am taking a more design-led approach in this section, where I outline what task I want to achieve and then flesh out how I want to achieve it. And what I want can be summarised in a sentence:

I want to be able to enter my passwords on any computer with a touch of my finger, but still be secure.

I decided that this can be broken up into three distinct sub-goals:

Security: The password should only be unlocked for the right person. Someone who got hold of the device should not be able to retrieve the passwords without significant effort.
Compatibility: The device should be able to enter passwords on any reasonable computer without special software or drivers.
Simplicity: Ideally I'd only store a handful of passwords on the device, I want to be able to quickly scroll through the list and confirm my fingerprint to enter the password.

I will discuss the implementation details in more depth later, but for now I would like to draw your attention to the inherent conflict between the security goal and the usability goals (2 and 3). This is the inherent challenge in designing security systems, as increasing a thing's usability often also increases its attack surface. I think the biometrics approach is better than secure entry keypads or miniature card readers such as the Mooltipass for this tradeoff - a secure keypad still requires you to enter a code which can be guessed, and the Mooltipass cards can be lost. A fingerprint-based system provides a reasonable level of security and convenience - a third party can't get to your passwords without cracking open the device and spending some time with a debug probe, and if you lose your finger you probably have bigger immediate problems than keeping your data secure.

Motivation

The key reason for doing this project is that I'm tired of mistyping my password which we also have to change every three months. My ideal device would be something that sent that particular password down USB with a simple button press, however that's not super secure! As mentioned above I think fingerprint authentication is ultimately more secure in the average case than a typed-in password, because once you're verifying who you are rather than what you know, you can make the "password" as long and secure as you can because no human will ever see it. It also makes sense to go with a keychain approach for storing a handful of passwords.

The other big reason for me starting this is that I want to learn something new. To that end I decided that I want to go back to ARM microcontrollers which I know and hate from university, but on slightly different terms this time - using Rust instead of C/C++, and using a microcontroller much more popular in the maker circles. I settled on the STM32 family, and more concretely on the STM32F446RE part simply because there's a development board for it that costs £13 and it's a powerful little chip.

I chose Rust because I think embedded projects are better suited to learning this systems programming language. For most projects I do on desktop, I usually prefer using something more high-level and portable, such as Python or JavaScript. However I will try out desktop Rust when writing the configuration program.

The device

Given the overall goals of this project, I decided on a USB dongle form factor. With USB, I can register the device as a keyboard and send the password keystroke by keystroke to the host. USB keyboards work on any system that has USB - so no extra drivers are necessary. The configuration interface can be a virtual serial port, which also should not require extra drivers. Finally, USB can be used for firmware updates.

I decided to use a scroll wheel control to select the password to enter. The scroll wheel should have nice detents and should be able to rotate freely. I want the interface to scale well to 10s of passwords stored, and so buttons are right out. Notably, the Mooltipass also uses this approach.

An OLED display will be used to show the user which password they have selected, as well as other information such as the status of the device if in configuration or DFU modes. I am also considering adding a Neopixel-type RGB LED for extra indication - perhaps I'll want to let the user associate each password with a colour.

Further on the user interaction - because the fingerprint reader I have in mind for this can also act as a button, I decided that placing one's finger on the reader will confirm the selection and acquire the fingerprint and try to enter the password. A fingerprint confirmation will also be necessary for entering configuration mode and updating firmware. For extra security, I may add a feature which erases the password list if no successful authentication is made a certain number of times, with exponential backoff to prevent the user accidentally erasing their device.

As for the encryption - I will need to come up with a reasonable scheme that would require an attacker to have physical possession of the device and at least some lab equipment to recover the password list. At the moment, I am thinking of combining the main microcontroller's unique ID and the user's fingerprint template as a symmetric encryption key.

I would have liked the fingerprint module itself to be able to generate a cryptographic value based on the user's fingerprint and then only release it if the authorised finger was detected - however this functionality is not available on the module I have chosen.

Implementation

While I mostly chose Rust because I wanted to learn the language, I also know that it is a much safer language than C/C++ when it comes to memory access. Unless code is explicitly marked as unsafe, Rust will attempt to validate memory access at compile time, catching entire classes of bugs such as use-after-free or buffer overflows.

I chose this particular STM32 part for several reasons. One, the cheap development board - the chip itself is about $6 so I would not be surprised if ST sold the things at cost price. Two, it's a pretty powerful part. And three, the STM32 family is popular with makers and hobbyist electronics people. As a consequence, there is lots of documentation, both from the vendor and the community. There are also Rust libraries for accessing the chip's peripherals in a relatively nice way.

The fingerprint sensor was the hardest thing to find. While there are some Arduino-friendly devices sold by Adafruit (with clones from the usual suspects), they are rather big. Good for safes or doors, not good for portable devices. It did take some research time to find a part which was small and had a reasonably convenient interface. Predictably, it comes from a relatively unknown Chinese supplier, with many clones on the market. It is the Grow R502, a module roughly the size of a 10p coin, with a UART interface. It can be ordered through AliExpress or Alibaba and comes relatively quickly. However, documentation in English is a bit lacking, and I could not find demo software to go with the module. I have emailed the vendor.

The Grow R502 does not do everything I'd like it to do. For one, I'd love a single piece of functionality to be added to it: when the fingerprint is first enrolled, a token is generated, which is then only returned on successful matches against that fingerprint. This would simplify my design and make the whole system more secure, as I could use that as the encryption key. Bit of trivia: the fingerprint module has a GD32 MCU, an STM32 clone from GigaDevice.

Given the features I want to include on the device and the constraints imposed by the parts I want to use, I decided to lay out the system like this:

The plan

I will blog my way through this project, and possibly even make some demonstration videos along the way. I want to share notes from the development process with you, and I want to get some feedback on my plans. For now I am planning 11 blog posts.

Rust on the STM32F446RE Nucleo board - where I skip the blinky and go straight for getting something on the OLED display. I will also try to cover initialisation code generation in STM Cube IDE and whether it's a good idea to do first before translating into Rust.
R502 exploration - where I try to find some existing software to test the module with and start writing a test STM32 program in Rust.
USB keyboard - where I try to create a simple USB Rubber Ducky clone from SPI flash
Basic prototype - where I build a device which sends one password stored in plain text when the fingerprint is correct
Configuring passwords - where I create a composite USB device which has both a USB keyboard and a virtual serial port, and then use that to configure the password list
UI prototype - where I connect the encoder and use it to navigate up and down the list of passwords, and talk a bit more about the overall UX of the thing
Encryption - where I start integrating encryption routines into the firmware
Full breadboard prototype - where I put everything together on a breadboard and talk through what's going on
Electronic engineering - where I create a full schematic and design a PCB for the USB dongle
The one where I put together the device on the PCB and hope that it works
Reflections - where I spend some time talking about what I learned through this project and where I want to take it; with some usage commentary if the thing even works after I put it together

There's a lot on here and I hope to be able to do it all in reasonable time. For now I'd like to invite you all to follow this series and send in some comments on this project. Until next time!

An Air Quality Update

Filip — Fri, 21 Jun 2019 21:09:18 +0000

A few weeks back I showed you my air quality monitoring device. I've since tweaked it, ran into problems and fixed them, and added some functionality. I also gathered some interesting data using the sensor itself - and it might be a little surprising.

Finally, I posted the source code for the program running on the ESP32 as a GitHub Gist - there's more on it below.

Adding some stability, of the mechanical kind

To prevent the components from rattling around too much inside the enclosure, I designed a backing board in Fusion 360 and used the laser cutter at the South London Makerspace. This is just a piece of plywood with some holes, allowing me to secure the SDS-011 sensor and the ESP32 breakout board with some nylon screws. I went through a couple of design iterations of these backing boards, trying to fit everything inside the enclosure I had. The final one (highlighted in the screenshot below) packs the components in about 2/3rd of the enclosure, allowing the battery holder to stand on its side as was the case when everything was wibble-wobbling around in the box.

Needless to say, the wibble-wobbling was reduced and the pieces are now much easier to work with if I ever need to take them out of the box.

Batteries included

Ah yes, the battery compartment - which I previously used as just a power supply - is now occupied by actual batteries. I sourced those from Poundland power banks, at about £2 per ~2000mAh cells. They are pretty easy to get hold of, although I'm pretty sure one of these came pre-shorted - it started getting a bit smoky whenever I put any load on it. PSA: If your batteries get smoky, don't use them! Lithium batteries are usually quite safe, but if you short them out, they can catch fire and/or explode, so it's best to not mess about with them.

I also wanted to be able to measure the level of charge in the batteries. The problem I needed to overcome was that, at full charge, a Li-ion battery (or a couple of them in parallel) has a potential of up to 4.3V - which is a full volt higher than the 3.3V level that the ESP32 operates at. I needed to get the battery voltage coming into an analogue pin of the ESP32 to top out at or below 3.3v in order to measure it without damaging the microcontroller. I can drop the voltage by using a voltage divider. I built an example of the circuit here in a simulator where you can play around with the battery voltage and see how the divider circuit:

In the code, I define one of the pins as an analogue pin, and configure the ADC using some ESP32/Arduino functions. I can then read from this pin using the normal analogRead function. However, when measuring an analogue value, noise and error creeps in pretty fast - so I decided to measure the battery level several times and average the results:

// setup:
  adcAttachPin(BATTERY_PIN);
  analogSetPinAttenuation(BATTERY_PIN, ADC_11db);

// measure:
float get_battery(int n_samples) {
  float sum_reading = 0.0;
  for (int n = 0; n < n_samples; n++) {
    int batteryAdcCount = analogRead(BATTERY_PIN);
    // Battery voltage is given by the ADC as x/4096 * 3.3 for the voltage divider
    // and * 2 for the full voltage.
    sum_reading += ((float) batteryAdcCount) / 4096.0 * 3.3 * 2;
  }

  return sum_reading / ((float) n_samples);
}

There is a certain dialectic when it comes to measuring battery levels. The ADC is not magic, and it requires some current to flow while the measurement is taking place. However, you don't want that current to be too high, otherwise you'd be draining the battery rather quickly. This is where the choice of resistor value in your voltage divider is important - too low and you'll burn through the battery, too high and you might not be able to measure it accurately. I picked 36kOhm for mine at pretty much random, but it's high enough that the total current flowing through the divider is about 60uA. Compared to the SDS-011 and ESP32 running at full tilt (peaking at 270mA), it's not very much. If I was crazy about power efficiency, I would experiment more with higher resistor values, and possibly add a transistor to the circuit, so that I can turn off the current if I'm not currently measuring voltage.

In the end, the battery measurement works pretty well, and the battery itself seems to last at least two full days:

On plugging in stuff wrong

I semi-broke an ESP32 board during the development of this by accidentally plugging it with one pin shifted down in the socket, causing 5V to be applied to its ground pin. Somehow it survived that, but not unscathed - that particular board will no longer wake up from any form of CPU sleep without an external reset, but does otherwise work. Oops. Luckily, I had a spare that worked.

How to sleep right

Turns out I was using the sleep modes of the ESP32 wrong. Initially I thought of ESP's light sleep as a special case of the Arduino delay() function, except where the processor core powers down for the duration of the delay. It's kind of like that, but with one caveat: this also suspends handling of the WiFi connection, causing some instability.

Furthermore, the ESP also has a deep sleep mode which saves more power, but it actually resets the microcontroller when waking up. I decided that I should use this mode, though - I don't need WiFi between measurements, so I might as well turn everything off. It also simplified the code slightly - I could put everything in setup() and rely on the wakeup resets.

This also made the whole system more stable, and allowed me to more easily add retry features - in the version of the gist current at the time of writing (permalink), if I can't connect to WiFi within a few seconds, I turn everything off and sleep for another 15 seconds. Now, this is still a bit buggy - there can be long stretches when the ESP can't connect at all - so I will need to look at the timeout and other causes of connectivity issues. However, the device will eventually reconnect without me having to go and reset it.

Some actual observations

PM2.5 of the carbon species usually comes from burning stuff, right? Well, how about toast? Or indeed, just cooking lunch?

Most nights I see a significant increase in presence of PM2.5 species over the night, even though traffic outside my apartment is very light - could this be due to some scattered light affecting the SDS-011 sensor? Or temperatures going down causing dust kicked up high into the atmosphere during the day to settle down?

For those playing along

The gist contains the Arduino sketch running on the ESP32 inside the device. If you want to run it on your own network, you will need to change the WiFi credentials near the top of the file:

#define WIFI_SSID "CHANGE ME"
#define WIFI_PASS "CHANGE ME"

As always, there's more

The most obvious next step will be to figure out why the ESP is not connecting to WiFi - maybe it's the internal antenna not being very good, or the timeout being too short.

Further next steps would be figuring out how to control my measurements for things like cooking - if I am going to use this device to nag my local authority, I should be reasonably sure that the data I get out of it is down to actual traffic related pollution, and not me burning toast. Finally, I should write up that IoT server setup, shouldn't I...

See you then - and as always, let me know what you think about this project. I'm still liking it a lot.

Working on my IoT air quality monitoring setup

Filip — Wed, 05 Jun 2019 12:27:13 +0000

Air quality - much has been said about it in the recent years. Research is coming out saying that breathing polluted air contributes to risk of asthma attacks, allergies, and other health issues. One of the most common pollutants is particulate matter - very fine carbon dust emitted from diesel and some petrol engines. If you live near a high traffic road, you are likely breathing some in right now - and it might be giving you black lung in slow motion.

On an unrelated note, here's a view from my window:

I would like to know how much of this dust - more technically, particulate matter, is in the air outside my window throughout the day. The end goal is to use this information to set up alerts if and when pollution levels exceed government targets, and use this to keep my local authority accountable.

So, how do I start?

The SDS-011 Sensor

The heart of the operation is the nova SDS-011 sensor. It works by blowing air past a laser beam and looking for scattered reflections. It can then isolate scattering caused by specific types of particulate matter - PM2.5 and PM10 - and measure how much of it is in the air, giving its reading in micrograms per cubic metre.

The sensors are pretty cheap - less than £20 on AliExpress, with roughly similar prices on Banggood and eBay if shipped from China. Some also throw in a USB adapter for the sensor's serial (UART) interface. Neat! What's not neat is the up to 3 week shipping time, but that's just par for the course when ordering from China.

By default, the sensor will output its measurements continuously every second. This can be useful if you want to test that it is working with the USB adapter. In fact, I wrote some Python programs that rely on this mode to display the sensor's readings. The simplest one is here in its entirety:

If you also want to plot this data immediately, here's one with matplotlib: https://gist.github.com/FLamparski/c9d09153183f77c69f8c8ca7ca22e7ab#file-plot-py

Great, now I have some data coming in! But I don't want the sensor to be connected to my computer, I'd like to connect it to an ESP32 microcontroller (I have some of these around which I might as well use).

The ESP32

The ESP32 is a crazy powerful Wi-Fi microcontroller - with the most common variant boasting a dual-core 240MHz CPU, 2 or 4 MiB of flash memory, and 520 KiB of RAM. It's also largely Arduino compatible - and the board library is developed by Espressif as a first-party product.

It's also really cheap for all that power: you can get it for under £7 with Amazon Prime delivery (or look at the amazon search for variants with OLED displays, camera attachments, LiPo chargers, etc on board).

The one where I almost burn myself with a soldering iron

To connect the SDS-011 to the ESP32, I am using a perfboard - a PCB with a grid of holes in it, allowing you to quickly assemble your circuit without having to design and make a dedicated PCB. I also needed a 5-pin JST connector to take in the cable supplied with the USB adapter, and I also decided to make a socket for my ESP32 from two pieces of female dupont pin headers. This makes the ESP board stand off from the perfboard, giving me some space to work with underneath it, and also allows me to easily recover the ESP if I ever tear this project down.

I then soldered some jumper wires on the back side of the board for power and to connect the TX pin of the SDS-011 to the RX2 pin of the ESP, and RX of the SDS-011 to the TX2 pin of the ESP. I made an image in gimp to help me route the wires correctly:

TX2 and RX2 on the ESP board are available as Serial2 in Arduino sketches. The observant among you may have noticed an extra JST connector exposing the I2C bus - this is for later.

Lol embedded programming

This is not strictly speaking a tutorial, so I'll gloss over how to actually set up ESP32 boards in Arduino - this is documented in the arduino-esp32 project itself. The one thing you should note is that this only works with the desktop Arduino IDE, and only if you install the IDE through the MSI installer and not from Windows Store.

A very simple sketch, which simply formats the incoming data as text and outputs it to the debug serial connection, is also quite short:

So after verifying that this works, I wanted to hunt down some more complete documentation of the SDS-011. The reason for that is that you are not supposed to run the sensor continuously for a long period of time, as it will allow dust of all kinds to accumulate inside, causing it to lose accuracy over time. The manufacturer states that the expected useful lifetime is 8000 hours of operation - so if you don't operate it all the time, you'll get more chooch for your cash. The other reason is that I'd like to run the thing off of lithium batteries at some point, and the SDS-011 uses about a Watt of power when it's running, what with its laser and fan.

There is a good Arduino library for the SDS family of sensors, which supports the complete protocol they use and presents a nice API for it: https://github.com/lewapek/sds-dust-sensors-arduino-library. The protocol documentation is an absolute pig to find though, and I ended up emailing the manufacturer for it. The v1.5 spec is here: https://drive.google.com/open?id=0B11dfFBNOar5NHNTUVlvcFJPWUctMWZzYWRZU0RiMWxheG04. If you're implementing your own interface to the sensor, make sure to get the checksum right, otherwise it won't process your commands, and it won't tell you why either. I wrote this before I became aware of that library:

When it's mostly wired up, it looks like this:

I'm powering it through a charge port I hot glued onto the battery compartment.

At this point, I can start sending all this data to a server. I decided to use an old laptop that I had in my cupboard.

There is a big gotcha when using the SDS library with the ESP32: It will fail to compile due to SoftwareSerial not being available in the ESP32 Arduino board package. To remedy that, I downloaded the master branch of the library and put it in my Arduino libraries folder, and then deleted all the code that relied on SoftwareSerial.

Can't spell idiot without IoT

The server is running InfluxDB, Node-RED, and Grafana inside Docker. It's also running Mosquitto as the MQTT broker, and Portainer to give me a nice GUI to the Docker host. And of course, I'm also monitoring the server itself with Telegraf running directly on the host. This setup is largely based on Andreas Speiss's Raspberry Pi configuration from his videos, however you can mix and match different components - for instance, a friend of mine is using Prometheus instead to monitor her sourdough cultures on a RPi.

This took a while to set up, not least because I was following several different sources at the same time, many of them written for the RPi and not an x86 machine. However it is mostly working now - and when I'm done tweaking the setup, I will release it on github as a docker-compose application.

But finally, I was able to connect to the MQTT broker from my ESP32 and start sending data...

Haha, no. The PubSubClient library I use to connect to the server has a default timeout of 15 seconds, which is way too low for my use case - given that I take about 15 seconds to wake up the sensor and then gather measurement data to average out, and spend another 15 with the CPU sleeping to reduce power use. So I just went into the library and changed the keepalive interval to something more reasonable, like 3 minutes. Afterwards, I started getting data in much more reliably, however the MQTT connection is still kinda patchy and I want to fix that before I move on to adding more sensors to the thing.

In the end though, I get a good amount of data through, which I can see on my Grafana dashboard:

For completeness, here's the Node-RED flow:

And a photo of the setup sucking in air from outside my window to analyse:

More stuff?

For further development, I will definitely need to fix the MQTT connection. I don't know what's going on, but sometimes the ESP just plain can't connect to the server, or data gets eaten somewhere in the process. It might be a slightly too aggressive application of sleep modes, or maybe I need to tweak my WiFi settings. This is the challenge of debugging distributed systems - you just plain don't know where the problem actually is, and more often than not, it's actually many problems in many places.

I also want to actually power the thing off of batteries. I have some 18650 lithium cells I bought at very reasonable prices as Poundland powerbanks (£2 per ~2000mAh cell at a brick and mortar store in the UK? And you get some charge circuitry with it? That's super cheap for hobbyists!), and a holder with appropriate charge circuitry.

Once I assemble all of that, the box can be made mostly safe against rain water ingress with an O-ring seal along the top and some shrouding of the air inlet and outlet ports. Then I can put it outside and actually close my window.

Finally, I can also add some I2C sensors for general weather stuff - such as the ever popular BME280. I also thought about adding a display and some sort of touch sensitive pad stuck to the underside of the enclosure cover (which is transparent) to read data directly from the thing, but I think the Grafana interface is nicer.

And perhaps one day I'll design a cost reduced solution for all of this with a dedicated circuit board and put it up online for people to buy. If I can get the whole thing down to less than £30 I'd be quite happy. Yes, I will add better security if I ever sell this design, don't worry!

Closing thoughts for now

I like this project. I want to know how much crap I'm breathing in and I now can. I like how this is a nice practical way to consolidate knowledge I learned at uni in two or three separate modules. And I like how quickly I can prototype all of this. I think you should try something like this too - dev hardware is super cheap these days and software is free and relatively straightforward to put together. Electronics knowledge is also easy to obtain on the internet, and proper tools are reasonably priced. Go do the thing!

Dril Or No Dril? Building a text classifier in TensorFlow

Filip — Tue, 29 Jan 2019 18:41:50 +0000

There is a ton of different tensorflow posts on the web already, and many of them are actually good. This is not that. This is me, writing a crappy little classifier for what's essentially an elaborate shitpost.

In this post, I will walk you through how I built DRIL OR NO DRIL.

Overview

If you don't know who or what dril is, have a look. If you already do, great. If you're just coming back - isn't that one of the weirdest twitter accounts you've seen in a while? Anyway - the style is quite distinctive, so I thought I might have a stab at creating a classifier that tries to pick up on what makes dril dril.

To do that, I first need tweets. Lots of tweets, both from dril and other accounts. I ended up using myself, a few of my friends who agreed to be included in the model, and the Prime Minister (at the time of writing this paragraph, lol) Theresa May.

I also need a model. I ended up using a modified version of the IMDB review classifier from tensorfow docs.

Finally, to put it online without having to pay for anything, I needed a way to ship my model to the browser with glitch. This also has a bonus of keeping all the text you enter in that box on your machine. I achieved that through tensorflow.js, a browser-based subset of tensorflow which runs on WebGL producing loads of warnings because, really, WebGL wasn't designed to be used this way.

Getting some tweets

The first thing to do is get some tweets. This requires a Twitter API account so you can authenticate. It's that or doing some screen-scraping hacks but for convenience I stuck with the API - perhaps to my detriment. I wrote a Python script to download all these tweets which was pretty easy thanks to tweepy. It downloads tweets and saves them into a sqlite3 database. It even supports resuming from the earliest downloaded tweet (important in case it crashes). Tweepy's cursor API is also really neat - you can iterate over tweets and it'll handle pagination for you:

cursor = tweepy.Cursor(api.user_timeline, id=args.account, max_id=max_id, include_rts=False)

for status in cursor.items():
    tweet = status_to_tuple(status)
    save_tweet(db, tweet)

It's also great that you can tell tweepy to automatically wait in case of a rate-limit response - though I don't think I ran into that issue yet:

def get_twitter_api():
    auth = tweepy.OAuthHandler(secrets.TW_API_KEY, secrets.TW_API_SECRET)
    auth.set_access_token(secrets.TW_TOKEN, secrets.TW_SECRET)
    return tweepy.API(auth, wait_on_rate_limit=True, wait_on_rate_limit_notify=True)

I then ran the script on some Twitter timelines. I used dril, obviously, as well as some examples of non-dril content. Then I looked at the amount of tweets I downloaded and saw a discrepancy:

Turns out that as per Twitter API docs, the endpoint used only returns up to 3200 most recent tweets. So I guess if you really needed that archival content, you'd have to implement those screen-scraping hacks after all. I chose to not bother.

Installing TensorFlow

Because this is the real hard problem in computer science (citation needed), I'm now going to spend 5 paragraphs talking about how to install TensorFlow.

j/k, get anaconda and go here: https://www.anaconda.com/blog/developer-blog/tensorflow-in-anaconda/ - works even on exotic platforms such as Windows.

The classifier

To create the classifier you will first need to load the data into a format that tensorflow accepts, and there is only one such format - numpy arrays. This is also the first step you will need to make a decision as to how you want to represent the text you put in because you can't simply throw strings at a neural network.

There are a number of ways you could represent a piece of text in a compact way, for instance by using the bag-of-words approach which only preserves word frequencies, or by encoding each word as a number as is the case of the TF/Keras IMDB example dataset. You can also try to do fancy things like discarding the most popular words like "a", "the", and "hyperloop is a good idea". In my example I'm not doing any of that and instead I take the raw bytes of each character and shove them into a 240-element numpy array, padding out the remaining space with zeros. The idea is that any other preprocessing could remove nuance about the style of these tweets. Also I'm lazy.

def to_padded_bytes(tweet):
    bts = np.array([ord(c) for c in tweet])
    return np.pad(bts, (0, 240 - bts.shape[0]), mode='constant')

This still meant that I needed to have an embedding layer in my network that extracted features from the byte values, but it was a little bit different than in the example.

Finally, the labels are represented as 2-dimensional vectors. A dril tweet is labelled as [1, 0], whereas a non-dril tweet is [0, 1]. This is so that at the end of the process I can get the confidence value from the network - it will usually reply with a vector like [0.98, 0.02] which means "I am 90% confident that this is a dril tweet and only 2% confident that it's not". Or the inverse. Or somewhere in between.

The model itself is as follows:

model = keras.Sequential([
    keras.layers.Embedding(255, 16, input_length=240),
    keras.layers.Conv1D(140, 3, padding='valid', activation='relu', strides=1),
    keras.layers.GlobalAveragePooling1D(),
    keras.layers.Dense(512, activation='relu'),
    keras.layers.Dense(2, activation='softmax')
])

I threw in the convolutional stage because I'm hoping it's able to pick up on the stylistic differences between types of tweeter, but so far it's mostly learned that shorter tweets are more likely to be dril, and that he doesn't use emoji very often. Nonetheless, at ~89% validation accuracy, I decided that it's good enough for a joke.

If I were doing this properly I might look at existing text classification architectures and try to actually learn something from them. Then maybe I'd achieve that 99% accuracy.

Onwards to JavaScript

tensorflow.js is a little limited. From the docs:

TensorFlow.js Layers currently only supports Keras models using standard Keras constructs. Models using unsupported ops or layers—e.g. custom layers, Lambda layers, custom losses, or custom metrics—cannot be automatically imported, because they depend on Python code that cannot be reliably translated into JavaScript.

That's fine though, as my model is only using standard constructs. The first step is to save it to a h5 file, then you can run the tensorflowjs converter on it. To get the converter, you can run pip install tensorflowjs in your conda environment. Note, though, that some of the installed packages might get downgraded as the dependencies are a little out of sync - this shouldn't be too worrying as they are all within requirements of each other. The converter will generate a directory with two or more files: a model.json file which describes the structure of the model, and some groupK-shardNofM files which contain the learned attributes of your model (the weights, in the ML lingo). You can then serve these files from a web server and load them on the client side like so:

// This assumes that model.json is in the same directory as the current document
const model = await tf.loadModel('model.json');

If you don't know what the await does, read this: https://ponyfoo.com/articles/understanding-javascript-async-await. If you do and are positive you can't use it, it's still a promise so you can work with that instead. If you need to support Internet Explorer, ask your doctor if tensorflow.js is right for you. In my case I decided that being compatible with popular browsers is for losers and just use async/await as they are.

The glitch project itself is also very simple - the main issue is getting the text from a <textarea> into the same format as I used in training, namely a 1x240 tensor. The code is pretty similar to the python version:

function tweetToTensor(tweet) {
  const array = new Uint8Array(240);
  for (let i = 0; i < tweet.length && i < array.length; i++) {
    array[i] = tweet.charCodeAt(i);
  }
  return tf.tensor1d(array);
}

// later...

const batch = tweetToTensor(text).reshape([1, 240]);
const prediction = model.predict(batch);
const result = prediction.reshape([2]);

It's nice that I don't have to explicitly pad out my arrays here because allocating a Uint8Array automatically gives me a zero'd-out array so I only need to copy in the relevant byte values.

There is one issue with hosting everything on glitch though - since the group-shard-piece-whatever files are binary, glitch uploads them to a cdn and gives you a long link to the file in its bucket. This is fine for images, but tensorflow.js expects that it'll be able to get the weights files from the same base URL as the model.json file (eg. if the model file is at https://example.com/models/model.json, it'll look for files like https://example.com/models/group1-shard1of1 etc). However, since the library uses fetch(), it also follows redirects, and it's easy to set up your server script to catch requests for the weights files and point it to the right place.

Well, easy if you've got one or two files; if you need more than that, again ask your doctor if tensorflow.js and glitch are right for you.

Where's the code?

The classifier etc: https://github.com/FLamparski/dril-or-no-dril/blob/master/Dril%20Or%20No%20Dril.ipynb - the same repo also contains the tweet download scripts, but you'll need to provide your own secrets.py file.

The glitch site: https://glitch.com/edit/#!/dril-or-no-dril

Learnings

From what's essentially an elaborate joke, I learned a thing or two about conducting machine learning experiments on data that wasn't delivered to you in a neatly wrapped package with instructions. It's a harsh world out there and most data will be messy and in the wrong format. About 2/3 (or more, haven't checked) of the code I wrote deals with acquiring the data and preparing it for the model. If I was to do this again properly, I might also look into ways of getting past that Twitter API tweet limit, and gathered up much more non-dril material. As it stands, the classifier is biased towards saying the input is dril-like. I would definitely look at different text processing models, both in terms of how the neural network is actually designed, and how to encode the data going into it. The vector-of-bytes idea is not terribly efficient and would not scale well to longer documents. I might even be tempted to try and serve this model from an actual server instead of dumping it into the user's browser in hopes that it'll work (those weights files can get awfully large sometimes...). I hear that Google has an offering for production machine learning apps. Or something.

Discussion

I'd like to hear from you if you have an idea of what you'd do for an application like that, especially if what you'd do is different and actually works. I'd also like to know what's the silliest machine learning thing you've made, and whether you went through the trouble of putting it online.

Right, until next time!

Graphology: Writing a graph of nodes UI in HTML5 (Part 1)

Filip — Sat, 22 Apr 2017 10:01:25 +0000

I like Blender's compositor nodes.

It doesn't mean I know how to use them well, but I like the UI and I think it works very well in that context.

I also kinda like the JACK Patchbay, because it shows you exactly where everything is connected - and it uses a similar interface.

We will not talk about the ALSA Modular Synthesiser here.

I like these interfaces because they show you how everything is connected in a complex graph, where you can zoom in on a particular part and change some settings of a single node, or zoom out and get a good feel of how the data (be it pixels, vector data, sound, whatever) flows through the graph.

So I want to write a general-purpose graph interface for working with graphs of complex nodes. And I want to use a data-driven approach so that, if you want, node UIs will be generated automatically.

So far

A scattershot experimental approach. Here is the sort of UI I'm after. It's pretty horrible at responding to screen sizes.

Nodes UI example

Here's a simple demo of one of the interactions I'm after: dragging around Bezier curve connectors.

Note that this may very well be a horrible and hackish approach. It uses SVG to render the connector, and changes the path live as you drag its free end with the mouse.

Existing software

d3 - Seems like it might help in some respects but I couldn't find a demo that captures what I want. Also I want this UI to be compatible with React (more or less) which d3 isn't.

jsPlumb - This demo captures an essence of what I want to do. It's ugly as a naked mole rat, and the library itself is priced in $k's per year. I want my UI library to be open source (with reasonable commercial licences should this concept catch on).

Basic data model

I am assuming the following things for the following example:

Nodes are representations of functions
A node can have many inputs and outputs

import {Node, Input, Output} from 'nodes-ui';
import {Colour} from '../image/Colour';

export const ColourMixer = Node({
  type: 'ColourMixer',
  name: 'Colour Mixer',
  inputs: {
    colour1: { name: 'Colour 1', type: Colour },
    colour2: { name: 'Colour 2', type: Colour }
  },
  settings: {
    mixType: { name: 'Mix function', type: String }
  },
  outputs: {
    output: { name: 'Output', type: Colour }
  }
});

That would be an individual node's definition. Perhaps a special case might be necessary for nodes that provide external input ("sources") or describe external outputs ("sinks") in the graph. The UI will take in those node definitions do some magic to construct graphical representations of those nodes, letting you add and remove them and link them together into graphs. Finally, it will give you back a graph of objects like this (where the #'id' notation should be thought of as "a reference to a Node object with this ID):

{
  id: 'ColourMixer-35',
  type: 'ColourMixer',
  settings: {
    mixType: 'multiply'
  },
  inputs: {
    colour1: {from: #'Image-24', output: 'colourData'},
    colour2: {from: #'Colour-5', output: 'colour'}
  },
  outputs: {
    output: {to: #'Display-1', input: 'colourData'}
  }
}

(And I guess at the top level, you'd have to have an object like {sources: [...], sinks: [...]})

From there, you'd use this graph representation to construct your internal computation graph or whatever it is you want, and then run some computations on that structure.

What do you think of this idea? Am I reinventing the wheel? Is there a library that can already do this? Or do you have a suggestion for improvements? Let me know in the comments!

Hi, I'm Filip

Filip — Sat, 22 Apr 2017 08:49:10 +0000

I played with computers since the young age of 8 years old, when Scratch didn't even have lists yet, or even proper string handling. Since then I started playing with C#, Python, HTML and others in a very unstructured fashion. For a middle school IT project, I built a blog with Django, and a simple browser using the Gecko engine.

You can find me on Mastodon as @Minkovsky@mastodon.technology or on Twitter as @Minkovsky.

I live in London and study Computer Science.

I work in full stack web development. I mostly use the web languages, PHP, Java (for coursework), and many others. I would love to learn more about machine learning and data science.

Nice to meet you.

DEV Community: Filip

Universally Stupid: Battling USB on a microcontroller with Rust

WTF is USB

Now there's two of them!

A rusty old bus

The one where you get stuck

Learnings

What's up, doc? Rust doctests and you

Denial: Not a river in Egypt

Acceptance: Let it go

Enlightenment: Writing examples as tests

Galaxy brain: hiding the tests in your docs

Even more

So you want to write an embedded driver in Rust

Poking it with a stick

Make it work first, make it pretty later, don't skip steps

Hell is other people's code

A brief guide to the R502

Enrolling a fingerprint

Matching a specific fingerprint

Searching for a fingerprint

The order of doing things

What is the R502 for?

Call the forklift person

Strange parts: fingerprint reader testing

Questionable findings

"Data" sheets

Iron work

Software gore

Road rage

Up next

Rusted brains: Running Rust firmware on a Cortex-M microcontroller

Prepare for boarding

Finding libraries

Reading datasheets

What we will be making

Iteration 1: A non-interactive stopwatch

Iteration 2: User input

A moment to reflect

Practical tips on how to not be stuck for too long

That's very cool but what's it got to do with biometrics?

My personal dev.to wishlist - what's yours?

The post editor

The difficulty system

Tags

Conclusion

Designing a biometric password manager

The goal

Motivation

The device

Implementation

The plan

An Air Quality Update

Adding some stability, of the mechanical kind

Batteries included

On plugging in stuff wrong

How to sleep right

Some actual observations

For those playing along

As always, there's more

Working on my IoT air quality monitoring setup

The SDS-011 Sensor

The ESP32

The one where I almost burn myself with a soldering iron

Lol embedded programming

Can't spell idiot without IoT

More stuff?

Closing thoughts for now

Dril Or No Dril? Building a text classifier in TensorFlow

Overview

Getting some tweets

Installing TensorFlow

The classifier

Onwards to JavaScript

Where's the code?

Learnings

Discussion

Graphology: Writing a graph of nodes UI in HTML5 (Part 1)

So far

Existing software