Driver for a SSD1963 TFT controller

[Roberthh]

I made a little progress with a driver for a TFT based on a SSD1963 controller. It's derived from the Rinky-Dink-Electronics Arduino driver. It can be found here:

https://github.com/robert-hh/SSD1963-TF ... or-PyBoard

It's at a pretty early stage, but the basic functions work and can be easily extended. Next phase is the generalization, but I have to order more display models for testing. I'm using a hand assembled interface board based on a prototype PCB, since neither Pyboard nor the TFT are breadboard-friendly, and it's better to use an external power regulator for the TFT, for not to kill PyBoard just to save 50ct for a 3.3V regulator and a capacitor.

Any comments are welcome.

[pythoncoder]

That looks most impressive! You've clearly put a lot of work into that. What display model are you using?

[Roberthh]

At the moment, I'm using this model:
http://www.ebay.com/itm/4-3-inch-4-3-TF ... l-SD-Card-
/311161631620?hash=item4872adb384:g:S1UAAOSw54xUWhRF
I did not buy it at that place, but mine looks the same, and the price was similar. I think it was called Sainsmart ..... They are available from many vendors. I just ordered a larger one for comparison and solving the dependencies of pysical resolution of the LCD vs. logical view at the controller interface.
My first approach was an Arduino Mega and a prebuild interface board. The UTFT Arduino library worked, but the interface board was lousy. I had to do so much rework on that board, that at the end it looked like a warfield.
The general Project: I want to set-up a battery operated info-device, which will be activated by an PIR sensor. Since the standby current of the Arduino board is pretty high, I had to switch it off. So I made a little extra board with an ATTiny, the PIR sensor and a PMOS transistor to switch the power. It worked, and had a standby current of about 150 µA, most of that consumed by the PIR Sensor, but it looked not nice. With PyBoard's low standby current and fast wake-up times, that all can be combined in a single unit. And, since PyBoard runs at 3.3 V, I just have one power level, compared to the 5V and 3.3 V with the Arduino, even if the TFT has to be switched off for power saving. And the SD card is faster. And ...... I may add an ESP8266 for showing a web page too. I have a handfull of them in my drawer. But thats at the far end. Mechanical design comes first.
I considered RasPi Zero, but the start time and power consumption are way too high.
For the battery I choose a sealed lead battery, 6V, ~10Ah. Space & weigth do not matter, and these batteries are affordable and very robust.

[pythoncoder]

Interesting. One area where the Pyboard truly excels is in very low power applications.

You might like to contribute to this discussion in which @Damien is soliciting comments about implementing a generic framebuffer class https://github.com/micropython/micropython/issues/1817.

I'm impressed by the speed you've achieved for font rendering. You may have seen my e-paper driver https://github.com/peterhinch/micropython-epaper.git. My approach to font rendering is based on different premises namely:

• Speed is not a major consideration as e-paper devices are slow.
• I aim for generality supporting fonts of arbitrary size including fixed and proportionally spaced.
• My driver seems rather RAM-heavy so I minimise RAM usage (at serious cost in speed) by keeping the font on the flash drive, only loading individual characters into RAM.

One factor in your favour performance wise is using a font which conveniently maps onto a bytearray. I wonder if it's possible to achieve my level of generality with something approaching your level of performance? Incidentally I claim no particular expertise when it comes to graphics.

[Roberthh]

Hello Peter, I'll look at these links. As you recall them, I remember having seen them once, but forgot them. The printString() function is quick & dirty. I took the font from Henning Larsen's UTFT-Library, but did not use his implementation and made my best to make mine fast. One decision was not to convert char-by-char, but a full scan line-by-scan line for the whole string. Luckily, the font uses a constand char width. It could easily be extended to other widths and heights, which I left open for the future.

One issue with generalization is the connection to the TFT. It seems that X1..X8 is the best place for the data port, and that should be kept. The control lines may more easily moved to other GPIO pins, but the ones I've chosen are also conveniently located.

P.S.: I was wondering how you could tell that the font rendering was fast. But obviously a display does not have to be connected for the code to run.

[Roberthh]

Hello all: I just added the two other fonts from the UTFT library for printString(), and documented the lower level functions.
The font handling in printString() is still very basic, and the supplied fonts do not really look fancy. And they consume a lot of RAM, so this part will definitely have to change.
I'm waiting for other displays. I downloaded also datasheets of other TFT controllers, and at first glance, they look pretty similar. So the trouble will be in the little details.

[pythoncoder]

Fonts do use a lot of RAM, and I've wondered if they might be stored in flash. MicroPython has a neat way of conserving flash memory whereby you can compile a build of firmware with Python modules baked into it ("frozen" modules). Alas this wouldn't help our case in that you still have to import the code so the RAM usage is unchanged. It would be good if there were some way of storing an array in flash and accessing it directly. One way might be to use a custom C module but I haven't explored that yet. I think I'll raise it in the framebuffer discussion on Github.

A minor point, but you could save some RAM by leaving it up to the user which fonts are imported. I'd put main() in a separate test program file and make font a mandatory argument to printString. Then I think you could eliminate the driver's import of font. The test program, and user programs, would issue (for example)

Code: Select all

from font import SevenSegNumFont

using only the RAM they need.

But some of the larger fonts I've used with the e-paper display would use too much RAM. It would be good to find a solution to this one apart from my too-slow (for an LCD) approach of using a random access file.

I've ordered a couple of the displays you suggested. Ordering goods from a US website sourced in China for delivery to the UK will prove an interesting test of globalisation...

[Roberthh]

Thanks for joining the game. Obviously you are right, and that font stuff is a wide area. Splitting the fonts into separate files is a good approach, which I will go. For now, I made a file called dummyfont.py, which just contains one dummy char for each font. That would at least ensure the operation. I'll upload that later on.
I have good experience for ordering stuff from china though amazon or ebay resellers. It always arrived. I sometimes had to wait a little bit. And even the support was OK. They responded to issues and questions, when asked politely. For instance I once ordered an ESP8266 for 3 € including shipping. In Europe, I would hardly get shipping for that price. There are a few chinese stores which have local warehouses, which means that the deliver within 2 days, but at increased costs. Some of them are located in UK.
I expect to get a second display today (national representative of a chinese store). Same controller, but different size.
I'm thinking also to make a PCB for a more reliable mechanical set-up. I have almost ZERO experience with Eagle or KiCad, but that one should be a pretty simple one (single sided, straight lines, just a few connectors and the power regulator, lots of free space).

[platforma]

There's a little discount on them on http://www.aliexpress.com/item/L155-Fre ... 791c67297c

I would also be interested in ordering one and participating in development. Aliexpress ships in ~2 weeks to UK in my experience.

[Roberthh]

Hello @platforma, that's great. There are a few areas where the development could be driven, so I allow myself to name them:

- Touch panel interface. Thats complete open space yet and may be the best extension for the package. There's C sample code available in the UTFT package, which I would use as a starting point. The hardware interface is SPI, so the PyBoard modules can be used.
- Support for transforming image files. That is better done externally, creating raw pixel files which then can be displayed. The Pillow library should have all required tools. And since this was my intention to start, I'll take that anyhow.
- Better text fonts. It seems that @pythoncoder has a lot of experience in that area, and I'll have a look into his package.
- Electrical interface board PCB (optional & simple; just a few connectors and a power supply for the TFT)
- more graphic support functions for standard elements.
- other TFT controllers, but that requires purchasing these for testing. I started with the SSD1963 simply because I had one.

So there are quite a few areas to participate.

Best Regards, Robert