The core feature of the Dumb Badge is to provide an 80x24 character display, with a keyboard, and a serial port. The first requirement of a high-resolution display is the hardest requirement, but there are many cell phone screens that will give you 800x480 pixel resolution, conveniently the same width as the display in a DEC VT100. The display is therefore the hardest part of this project, and demands specific engineering decisions. The purpose of this project log is to discuss these engineering decisions, while covering earlier work done by others.
Driving The Display
There are no 80x24 character displays that are cheap and readily available. Therefore, the best option for the display is an 800x480 display from a cell phone, something that can be found through the usual retailers for a few dollars. These displays use a parallel RGB interface and requires significant horsepower to drive. At the bare minimum, an 8-bit color depth display requires 29 pins on a microcontroller, and a clock speed on the order of 20-50 MHz. This isn't unheard of in high-power ARM microcontrollers (the STM32F4 and STM32F7, for example), but it does necessitate a lot of memory for the frame buffer. Basically, you can't just drop an Arduino into a circuit and expect to drive a cell phone display.
Previous work in projects like this have made the decision to use a high-powered microcontroller to drive a 4-5 inch display. The DIY-VT100 is the best example I can give in this case. This is a 5" display driven through an RGB interface, using an STM32F7. I could easily simply copy this design and add a silicone keyboard, but this is a cost-sensitive device. I don't want to spend the money on a $17 microcontroller, and this microcontroller is actually overpowered for what i need it to do; the DIY-VT100 spends most of its horsepower simply driving the display and refreshing the framebuffer. Here is a high-level system diagram of what this project would look like:
There is another option. There are several SPI-based TFT drivers available that contain the necessary RAM for a framebuffer and the hardware to drive an RGB display. These chips accept power and SPI, something every microcontroller speaks. Instead of using one large microcontroller, I could use a smaller microcontroller to emulate the VT-100 terminal, read keyboard inputs, and output to serial, while leaving the heavy lifting of driving the display to a SPI TFT driver. One such product is the Adafruit RA8875 driver board. A high-level system diagram would look like this:
In this system, a small, $2 microcontroller handles keyboard presses, the serial I/O, and sends the text-only display data to a TFT driver. Compared to the large microcontroller solution, this is the cheaper solution. A large microcontroller, like the STM32F7, costs about $15 in quantity one. A small microcontroller costs about $2, and the RA8875 driver costs about $7. That's nine dollars versus fifteen, and we have a clear winner.
But cost isn't the only reason I've chosen to go with a TFT driver over driving the display directly from a microcontroller. Because the display is separated from the logic, it is possible to 'tap into' the display. Effectively, this project also turns an RGB TFT display into a SPI display. With that, you can connect a Raspberry Pi or other single board computer, completely ignoring the 'terminal' part of the badge. All you need is some way to mux the SPI signal:
With this architecture, the keyboard is read by the small microcontroller. This can either send keypresses to the terminal emulation, or to a single board computer. The addition of some sort of mux for the SPI bus allows you to switch between video sources, either terminal emulation or a Pi. This is inherently more flexible than a single, gigantic microcontroller and ends up costing less.
TL;DL: I'm using a SPI to TFT driver with a small, $2 microcontroller instead of a gigantic $17 microcontroller. This allows me to use other video sources, like a Raspberry Pi. The terminal can now become a Raspberry Pi palmtop because I'm a cheap-ass