 Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me. |
Forum Index : Microcontroller and PC projects : MM2:My favourite RGB display,1.8" SPI
| Author | Message | ||||
| matherp Guru  Joined: 11/12/2012 Location: United KingdomPosts: 8603 |
One of the 1.8" SPI full colour 128x160 displays arrived yesterday: 
e.g. 1.8" TFT Display The datasheet for the controller is available on: 7735R Datasheet As always the magic initialisation numbers were copied from a known working Arduino example. The challenge to make it work on the Micromite was to try and control the SPI bus from inside a Cfunction. It proved reasonably easy, but because the 7753R controller needs the chip-select line to pulse between input bytes the code has to wait on the SPI data being completely clocked out of the Micromite's SPI shift register rather than just loading the SPI FIFO and keeping it full. The advantage of SPI is of course fewer pins used than the parallel bus displays. The disadvantage is a lower bus bandwidth so a complete screen write on this display takes 40msec, slightly slower than the update on the 240x320 display despite only having a quarter of the number of bytes of data to send. The cFunction uses pins 4 and 5 for chip-select and command/data (marked A0 on the display) respectively (pins 21 and 22 on a 44-pin micromite) and there is also a reset line handled in Basic that is currently set to pin 6. This display is an excellent size for many uses and using SPI at 10MHz is reasonably rapid. In particular normal 8x6 fonts are properly legible (characters in blue on the picture). There is a 2x further improvement I could probably make to character output but it is a fairly major rewrite of the character handling cFunction. The 7735R controller is quite interesting in the way it works and more sophisticated than the 7783. Rather than setting the internal cursor to a particular pixel a section of memory is identified: x-start, x-end, y-start, y-end. Then consecutive data writes fill this start to finish, x first. This means writing a rectangular block of the screen is very efficient as there is no need to re-position the cursor at each "x-end" column. The downside is that writing an individual pixel has a rather a lot of overhead. The controller also supports hardware rotation of the screen so I have been able to remove all the xy mapping needed to rotate the other types of display. Full basic library and test routines and C source attached 2014-12-14_172119_TFT18.zip |
||||
Zonker Guru Joined: 18/08/2012 Location: United StatesPosts: 761 |
Sweet..!! You convinced me... Got 10 of these on the way... A board designed to this form factor would be awesome... Humm... Could be worth it... |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 8603 |
Zonker with that level of committment I thought I'd better make the speed improvements. This version speeds up text write. For normal 8x6 sized text a full screen write of 416 characters now takes 127msec vs 2000 before 
2014-12-15_114917_TFT18.zip |
||||
 Print this page |
