Subwaymate

I'm in the beginning phases of thinking about the design of the second PCB that will host the main microcontroller and wifi radio. The physical PCB itself will use the same 43x70mm form factor as the display controller, so they can be easily fitted together.

All I really know for certain at this stage, is that I'll want to stay in the ARM Cortex world, as that is what I am most familiar with. Maybe a Teensy would work well?

I will likely have the communication between the device & both the time-server and control apps be raw TCP. That way, I don't have to concern myself with parsing stringy HTTP headers and storing large HTML strings somewhere.

Finally, I'm toying with the idea about playing around with the MPR03 touch controller. I got a few samples from Freescale of this tiny (2x2mm!) 8-pin 3-channel touch sensor last week and have been looking for an application for them.

I finished the schematic for the display controller board yesterday & sent the gerbers to the manufacturer.

I am going with a two-board design for the first revision of Subwaymate, as it will help compartmentalize features and aid in avoiding silly design mistakes on the board from making coasters of the whole thing. Also, by keeping the display unit agnostic from the rest of the project, I will have a display to use on future projects.

Controller primary components

• 4 5x7 row-anode LED matrices
• 2 Texas Instruments TLC59284 sixteen-channel LED driver (constant-current sink)
• 1 CD4022B 8-output counter
• 1 74HC540 inverting buffer
• 7 IRLML5203 P-channel mosfets
• Freescale Kinetis MKL02Z32VFM4 Cortex M0+ MCU (32k flash, 4k (!) RAM)
• So. Many. Interfaces.

Brief design overview

This display is drawn row-by-row. The row to be drawn is selected by the counter, which feeds it output through an inverting-buffer, then out to the P-channel mosfets. The columns are selected by the TLC59284 which are essentially shift registers that can sink considerable (configurable) current, so you can avoid having many current limiting resistors for the LEDs.

The Kinetis MCU will be responsible for drawing the display, and receiving commands from the main controller. I have exposed the MCU's i2c, SPI and UART lines to headers.

The raw inputs for the row/column selection have also been broken out to the left side of the board - 4 pins are required (shift clk, in, latch + counter clk). This can be reduced by 1 if a solder bridge is used to tie the clock of the counter to the latch of the shift register.

Software overview

The software is still in the planning phases, but the rough plan is to use a slim RTOS like AtomThreads to both keep the display refeshed and take input from the host controller over i2c, SPI or serial.

The MCU will have an ASCII character set preloaded - but the command set will also allow the host to toggle single LEDs, rows and columns.