Wednesday, December 7, 2016

Serial Graphics Terminal

It has been a while since I last posted here, and there have been a number of fun projects under the bridge.

One of the more fun, with more work still planned, is the development of a serial graphics terminal.

Most PIC projects use an LCD for a display. It is cheap and easy, but it has pretty limited real estate, and it uses a bunch of pins.  For quick little test projects, you often spend more time hooking up the LCD than you do on the rest of the project. Serial LCDs are expensive, and don't solve the problem.

More recently there have been some relatively inexpensive TFTs available. Fairly small 320x480 displays have tended to be among the least expensive, but they take even more pins than the LCDs, and quite a bit more code.

Suppose we could connect one of those things up to the serial interface.  That would allow a competent display with only one or two pins.  If we put a lot of smarts into the terminal, the performance might be decent, and we might even end up with a small software footprint on the host project.

Unfortunately, there are relatively few PICs available in 40 pin DIP, and those that are tend to be pretty slow or have limited memory.  I wanted a fast PIC with gobs of memory in a DIP package that I could prototype easily.

By using the MCP23S17 I/O expander, I could get enough I/O to handle a TFT, and selected the PIC32MX250F128B.  Turns out that the PIC32MX150F128B is the same for this purpose, and cheaper, but at the time I could get the 250 quicker.

So I breadboarded up the thing, mounted on my breadboard dsPIC-EL as a test host, and the thing worked.



I developed first text terminal code, then graphics terminal code, and decided that a custom PCB would be worthwhile.


The serial performance, even though limited by the I/O expanders, is quite good.  I developed a graphics library for the PIC32 that the terminal code builds on. The board is capable of the things you would hope such a terminal would do.


One of the things that is a real pain is drawing decent graphs.  All the piddling around in getting the axes and legends straight is a major hassle, so I decided to put a graphing feature into the PIC32 so that a small host application could draw decent graphs.




The TFT library makes it tempting to do projects directly on the TFT board. Unfortunately, there are only a few pins left (which are brought out to a connector), but a simple logic analyzer was irresistible:




Although the performance is quite good, and for most things, even with a serial connection, speed is not an issue, there is one place where the performance falls down, and it is a common one: drawing a continuously varying graph like a strip chart recorder.

A strange thing about this particular TFT controller is that it takes as many commands (and as much time) to fill a rectangle as it does to draw a pixel. When drawing lines at odd angles, like a graph, each pixel must be drawn individually. In this case, the MCP23S17, even though SPI is running at 10 MHz, simply can't keep up.

A large buffer in the PIC32 mitigates this problem for finite lines, if you want to continuously monitor a variable at some point you overflow the buffer.  Even with a huge buffer, at some point it fills.  I have done some experimenting with XON/XOFF, but this requires more complex code in the host.


The next step will be to prototype something with the PIC32MZ1024EFH100 (the 100 pin part is necessary to get all the pins in a single register). If the prototype can substantially improve performance, then I will look at a PCB for that part.

Again, I have no plans in marketing this, but everything needed is in GitLab. PCBs can be cheaply made and all parts, except the TFT, are available from DigiKey. The TFT is a SainSmart 20-011-918.

Project Components (all gitlab projects except document):

The following is a little video to give an idea of the performance of the serial terminal: