Rebooting Codescaling – Keyboard Kickoff

~ Codepope

I’ve not been blogging much here, but thats going to change. Fresh lick of theme, and… we’re off.

First up, this Ortho-linear keyboard from OLKB. I have a distinct keyboard fetish and I don’t think it’ll be every satisfied. Always looking for something different and this OLKB Plank kit seems to have tickled every spot. The Ortho-linear layout puts everything on a grid, and has no proven benefits but it does feel nice to type on in terms of finger positioning.

The 40% layout is compact (numbers are orange raise and QWERTYUIOP, shifted number symbols are blue lower and the same). I spend more time mapping the 40% compression more than worrying about the ortho-linear  layout.

Building was simple and fun. The PCB was lovely to solder with and the biggest trudge was making sure all the keys were well positioned while mounting the aluminium plate. The AVR controller on the board makes it more chatty than many keyboards with a small piezo buzzer playing a wake up tune and lots of customisation options hidden away. If you are curious, it’s the QMK Firmware running on the AVR chip.

And like a gateway keyboard, I’ve already got an order in for the Preonic variant which goes 60%, and an extra row. And the Planck, it’s going onto my four-system HDMI KVM to get some working time in.

 

 

 

 

ESP32s and Python and more

~ Codepope

An edifying weekend saw me looking at a whole load of ESP32 based boards – The WiPy 2.0, the Sparkfun ESP32 Thing and the Huzzah32… and in turn a whole set of MicroPython variants… MicroPython is a shrunk down Python 3 for embedded devices and it can fit in some pretty small spaces – there’s a version for the MicroBit even. Anyway, I wanted to find out if I could do a particular projects proof of concept using MicroPython. Let battle commence…

First up was – Pycom’s MicroPython for the WiPy 2.0 is well packaged and relatively complete; it includes RTC support and enough other drivers that I was able to build my proof of concept device. The VS Code integration was neatly done and so much more useful than previous attempts… But the board is literally just the processor. Supply power on the pins and bring your own USB or use their expansion boards. That was already bumping the costs up…. before I went further prototyping (as the rig was already syncing clocks, reading RFID cards and posting to REST endpoints) I thought I’d have a look around.

Next up was Adafruit’s Huzzah32 Feather.

It’s a lovely little Feather board – I do like the Feather form factor and with the new Express boards bringing CircuitPython into play things look interesting. CircuitPython is Adafruit’s fork which tries to simplify the whole thing with embedded hardware where lots of physical features turn into code for particular boards and stop things being portable. Great idea. Turns out the Huzzah32 doesn’t have a CircuitPython port yet though… CircuitPython is an interesting fork but it needs a target board with a bit of WiFi. The Huzzah32 does have the USB and LiPoly support so theoretically it could run MicroPython… let’s try straight MicroPython on an ESP32…

Specifically, lets go back to MicroPython and run from the fork for ESP32. This was to run on the Sparkfun ESP32 Thing, which is a super practical hacking board at a decent price and complete with USB and LiPo battery support. It’s not a small board, but it’s easy to shoehorn in. Then there’s the current MicroPython for ESP32 – like pretty much every API for the ESP32 it’s a work in progress, but this work in progress hurt hardest when I found no RTC clock support in MicroPython at the moment.

The weird part is… writing the Python code was pretty plain sailing for this embedded environment, so I’m guessing it can only get better.

Meanwhile for the proof of concept project…. Heading back to the Arduino framework was no less fruitful. Again, missing RTC support lead the problem set. So I’m back on the WiPy 2.0 to finish the PoC and wondering if I really want to get all C++y to use the Espressif native tool chain. At least there’s be no lack of drivers…

But, and I didn’t think I’d say this…. but I cant wait for Python to harden up in the embedded space.