An improvised weeknight mole using roasted poblanos and fresnos, with peanut butter and cocoa for depth — no tomato, no added salt.

Last week, I received my Lumatone keyboard. I have a basic setup, and it turns out there is a lot to learn. There will be more posts to come about the keyboard, but I wanted to start with the idea of layouts.

The Lumotone has software called the Lumatone editor, which for each key, sets several things:

• The kind of key it is (key, continuous controller, etc)
• What MIDI channel it sends
• What MIDI note it sends
• What color the key should be.

It comes with 10 presets, and I want to talk about that briefly.

The first mode that I implemented for my keyboard was a QWERTY mode. I needed this, because I already know how to type on QWERTY (and fairly quickly at that, over 100WPM). However, one of the goals of the more compact keyboards is to reduce the amount of reaching that is needed to access all of the keys normally.

Traditionally, this is done through multiple layers, with things like numbers and symbols mapped to these other layers. Accessing these, is then done with additional shift-type keys that access these other layers.

For the past year and a bit, I have been designing and builging my own keyboard. The current iteration, the proto3, is my daily driver, and I like it enough that I bring it with me when I travel. It supports several input modes, that are in different states of completion:

• QWERTY: This is the closest layout to a traditional desktop keyboard. The next post will summarize how I fit a fairly standard QWERTY keyboard into just 42 keys, while still being able to type nearly everything I could on a regular keyboard.
• Steno: This is a strict chord keyboard (multiple keys are pressed together and released) built around 23 keys (plus two extra in my design). On the proto3, this uses the top two rows, and the thumb keys. The lower finger row is treated entirely as the number bar, except that it isn’t in the right place, and ends up not being particularly useful. Instead, I use what are affectioniately known as “thumber” keys–the keys to the outside of the traditional vowel keys. My theory, Phoenix, does not require the number bar, so this works out. I have started incorporating number shifts into my shortcuts I use for programming language constructs.
• Local Steno: Intended as the same use as the above steno mode, but instead of sending the raw strokes over a special protocol on an CDC/ACM USB endpoint, the dictionary lookups and translations are done locally on the keyboard. This is incomplete. The dictionary lookup is implemented, but I need to work through all of the rules for stitching text together, while supporting an undo stroke.
• Taipo: The last layout, and the subject of this post.

Taipo, is a slightly chorded keyboard. When I first looked at Taipo, it just looked like another variant of something like Artsey, but with use of two thumb keys making for less state, and no holding down of keys.

Today’s exercise is going to be an exploration of two lines from the Zephyr “blinky” sample to understand better how devicetree support works in Zephyr, and explore how we might do something equivalent in Rust.

#define LED0_NODE DT_ALIAS(led0)
static const struct gpio_dt_spec led = GPIO_DT_SPEC_GET(LED0_NODE, gpios);

There is quite a bit of complexity going on behind this fairly simple seeming piece of code. As we start to look at how this might work, the first thing we discover is that there are a lot of macros involved, and many of these macros stitch names together to form the names for other macros.

MCUboot is a bootloader for microcontrollers. It has a fairly long history and has been under development for a number of years. Over the years, it has gained some significant functionality, and is used as the bootloader for a number of projects (TF-M and Zephyr coming to mind).

MCUboot is somewhat unique as an embedded application in that it tends to be fairly isolated. There are a lot of other projects that make use of MCUboot itself, but MCUboot itself does not have a large number of dependencies. It needs the ability to run as an early application on the target, operate on the flash device, and perform some cryptographic operations. It optionally can support some types of logging to help with debugging and development.

Zephyr is Amazing.

I suspect most people working with embedded devices are building products.

I have been asked several times about whether the log4j vulnerability affects Zephyr. There is kind of a tendency to give a glib answer “Zephyr is an embedded RTOS, and doesn’t run Java.” Although this is true, it is important to understand that Zephyr doesn’t live alone, especially as devices become more connected, and evaluating this vulnerability should still be done.

The first place to look is indeed the source code to the Zephyr project itself. For the most part, Zephyr targets small embedded CPUs (microcontrollers) that frequently have memory sizes that are measured in tens or hundreds of kilobytes, with megabytes being available in a large system. A simple glance at the latest Apache log4j shows that the core jar file is 1.8 megabytes itself. Just the jarfile alone is larger than the memory on the targets that Zephyr supports.

Introduction

• Where have we been, and where are we going. AS asdlkfjasfd wojf wjof znfi wurqo fije wnqoiw riuewo qiuro wiueo roiuqiw eourouqi woueo woiuroe uwiuqo ruowoiue

Documenting

Best Practices

Vulnerabilities

Automating

The Future