This post is all about TermDriver, a USB/serial adapter that is shortly launching on Crowd Supply. Please consider subscribing there if you’re interested. Thanks.
About four years ago I was searching my drawers for an FTDI USB/serial adapter, when inspiration struck. Wouldn’t it be great if it showed the line state and traffic, just as SPIDriver and I²CDriver do? It could work just the same as other USB adapters, so there wouldn’t even be any PC software to provide. Just drop it in, and you’d get an instant serial traffic monitor. I’d definitely get one, maybe a handful.
So much for the inspiration. Then the perspiration began. FTDI chips, though very popular, don’t actually indicate the line speed. The only status outputs they have is two signals for LEDs. So I started to look at my current favorite microcontroller, the RP2040 from Raspberry Pi. It has built-in USB support, so no need for the FTDI chip. And it’s relatively speedy, with two 32-bit Cortex-M0+ running at 133 MHz. This would prove important later.
For the screen, TermDriver needed something smaller than the 2” screens of SPIDriver and I²CDriver. Looking around I found tiny 1.3” screens with a really high resolution — 240x240 pixels. I ordered a few samples, got them running and was delighted at the image quality. Bright and crisp with very wide viewing angles. Great.
And here is the very first working model. There’s a Pico running the Debug Probe for fast firmware reloads. Then the Pico that’s running TermDriver, and the display breakout that I used for early tests.
After this, it was time to make the first PCB. This is it: just a RPi Pico with the signal breakouts and the LCD panel, directly soldered to the PCB. Baby steps.
Showing it to a few embedded friends got a pretty unanimous response: it looked really cute, and the text was almost impossible to read. I noted this for later and pressed on with the first PCB design. RP2040 is very nice, but unlike the old SiLabs microcontrollers I had been using, it needs an external crystal and external flash for program storage. The routing for USB, display, and the serial ports all needed to be squeezed into a 30x30mm footprint. After many hours in the layout program, I had this.
And here is the first hand-built prototype that actually worked.
At this point, the hardware was looking pretty good. The thing seemed very stable, and it was time to focus on the firmware. The firmware was going to be written in plain old C, using the excellent SDK from Raspberry Pi. The first step was to make a proper development setup.
On the left is a Debug Probe, for instant firmware loading. The TermDriver prototype is held firmly in place in the middle. On the right is another Pico to give the TermDriver serial port something to talk to. The whole thing is on a piece of thin plywood, so development doesn’t involve a mess of fly leads. This accelerated the development loop greatly.
I’ll talk about the firmware in more detail in a later post. A lot of the time was spent making the text more readable. The sweet spot turned out to be a 6x9 pixel font, which gives a terminal width of 40 characters. There are some cunning subpixel tricks in there that improve legibility considerably.
One improvement I wanted to make with TermDriver was better screen mounting than on SPIDriver and I²CDriver, which just use adhesive. So TermDriver has a bezel. It’s 3D printed, of course, and I learned a little about mechanical design along the way. One touch I’m particularly pleased with is the grippy sides, which help a lot when pushing in the USB connector.
And that’s TermDriver’s path from prototype to product. It’s launching on Crowd Supply soon. Please sign up on that page for updates if you’re interested.
Thanks for reading.
Looks good James - can I have one of those large Freznel lenses (Terry Gilliam's "Brazil" movie) - so I can actually read it ;)
This sounds really handy, and I've long planned something similar (although not quite as small).
In addition to terminal mode, does it support hex display for binary protocols? Custom firmware for other protocol decoding?
FYI you mention "terminal width of 40 characters" above but on the CS page the specs say "Terminal text resolution 60x23 characters".