This post continues after Interrupts squred. Since all I do is playing with things I feel like, and designing the bits to make this a usable keyboard sounds like work, we got another intermediate step to have some fun with. There’s an LCD display connected to the board as I bought them. So let’s get that up an running. Can’t be hard, right? During some earlier research, I had found an lcd library on github that claims to support DMA, which apparently the vendor lcd example does not. So I grabbed the code from github, and got started. There’s even a commit for it.

This post continues after Interrupts Squared. This is just a quick update to show off the changes done to add a secondary mcp23017. The hardware change is pretty simple, just add it to the existing lines. Pictures Most important is probably that the A0 address pin is set to high instead of low. Schematic: And new pictures (notice some re-wiring): Code Changes On the code side this commit contains the interesting changes. The following are mostly cleanup and re-enabling interrupt style setup. The uint16_t state became a uint32_t state to fit all bits. Doesn’t really change anything about execution, since it still fits into a register.

This post continues after Keyboard from scratch. We are on the same set of hardware as before. Starting point in code is commit bd6d3eeaad. You may have noticed, that a main loop that simple sleeps until we get an interrupt isn’t very “interrupt based execution”. So this time, we’ll take a look into getting at least the setup step of our mcp23017 interrupt based. Simply because it’s the easiest starting point for now. Bunch of Plumbing Since I2C only allows for a singular device to communicate with the controller at a given time, we have to do time based multiplexing. OTOH this allows us to just pass through any event of the I2C hardware to a device specific handler relatively unfiltered.

This post continues after Keyboard from scratch. or Back to Blinky for a debugging session. From a hardware perspective, there’s only a minor change. The interrupt line from the mcp23017 is connected to PA3 on the longan nano. I picked that one arbitrarily, since I was testing on this one before. This time, no picture. But here’s a circuit diagram. It’s .svg, so you can open it in a new tab and zoom as much as you want. Going down the interrupt route While the current plan for the firmware is not to have very piece of code in an interrupt context, the main loop should block in wfi as much as possible.

This post continues after Keyboard from scratch. I messed up. I don’t know the exact details yet, but for some reason with the code linked in the previous post, the interrupts don’t come through. So, back to blinky we go. Blinky? Blinky is quite literally the example that just lights up an LED for a second then turns it off for a second again. The code is pretty simple and just downloaded from upstream. So, stepwise we iterate on building up interrupt driven code again, to see what’s going wrong here. Add GPIO IN Step one, add GPIO read to see whether what we are doing on the outside of the device actually has the impact on MCU state that we want.

Like the blog title says, I like to tinker with things that make no sense. I recently got msyelf an irix keyboard for work. Since I like the split design and my MX Blue switches at home make it impossible to listen and write at the same time, I want to build another set. It’d be boring to just build another iris though. So I decided to go down another route. One that’s more custom. Way more custom… I had some longan nano laying around. So I decided to base my new keyboard on those. As I soon realized, that’s not supported by qmk.