Graphic TFT library

[trastikata]

Hello all,

as I mentioned in some posts I am working on a graphic library for TFT displays. It is not a fast library, not optimized for specific devices and everything is math based, so it can be ported between devices and device families (except the SD library is for 16b devices, I'll come later to that).

-In the library there are built-in drivers for where you can dynamically change screen orientation:
-- ST7789V/ILI9341 (320x240) graphic chips - software and hardware SPI
-- ST7796S (480x320) graphic chip parallel interface
-- XPT2046 or similar touch screen IC

-There are many geometric figures with different fill and shell options.

- I've included font print options, where you can change dynamically standard fonts as well as bdf fonts. More on fonts here:
-- https://protoncompiler.com/index.php/topic,2214.0.html  - BDF fonts
-- https://protoncompiler.com/index.php/topic,2233.0.html  - Standard fonts

- You can print strings, characters, numbers and digits as well as texts from Flash tables with BDF fonts (variable size) and some basic word processing to split words in such a way that there are no single letter from the word left. Text can be printed with some visual effects (slow typing).

-Multi point (3-5-7-9) touch screen calibration procedure where you can save the coefficients for later use. There are procedures for touch screen readouts and automatic touch to pixel coordinate conversion.

- I've included a Color Name and code file for about 900 colors - basically I've converted this list here to an include file:
https://en.wikipedia.org/wiki/List_of_colors:_A%E2%80%93F

-There's an option (for 16b devices ) to print a Bitmap (*.BMP) file from the built-in SD card at any position on the screen.

There's a description for all procedures and parameters in the library but I haven't got time to write a guide or manual. It is an early version so there are probably bugs and I plan to continuously add new functions (if you have any ideas, let me know). 

For the *.BMP files - reading from the SD card and printing on the screen using the same SPI module or same SPI pins is relatively slow, you can see the video to get an idea for what speed you can expect.

The idea with the *.BMP file option is to create well designed menus of the correct size on your PC and then use it with the touch screen option to create interactive and graphically aesthetic menus.

However having the SD card sticking out of the screen is not ideal and not so really fast, thus I plan to add option for transferring to, and reading from an external memory IC (EEPROM or Flash) BMP files. But I am still not sure how to organize and simplify the procedures for uploading and reading the BMP files from the memory ICs.

Note that it is not a problem to make a PC app to convert the BMP files and or the BMP file format itself is not an issue, but rather how to make all this user-friendly? Any suggestions are welcome.

TFT_LIB_0_30.zip 

v.0.10- Initial release
v.0.20 - Add SD-BMP parallel screen
       - Add Interface type 3 SW Parallel and HW SD SPI
       - Add Interface type 4 SW Parallel And SW SD SPI
       - Reset command simplified
       - Add FLASH memory support
v.0.30 - Fixed some $define bugs
       - Modified "BMP_SD16.inc" to "BMP_SD.inc"
       - "BMP_SD.inc" now supports 16-bit and 8-bit MCUs
       - New program header 

TFT_LIB_0_30.zip

[charliecoutas]

Brilliant work Trastikata.

[Mapo]

Fantastic Trastikata,
I envy your ability to write code

[Wimax]

Trastikata is great! The advice he gave me on DMA pulled me out of quicksand ! 

[John Lawton]

Inspiring stuff indeed, well done.

John

[John Drew]

Wow, that is impressive coding.
How much memory is consumed for each Trastikata?
John

[JonW]

Really like the idea of using the bitmap as the gui and then being able to use the touch screen to select an option. I presume you can then have an area where text can be displayed and changed on top of the bitmap?

[trastikata]

How much memory is consumed for each Trastikata?

I've made the library with aliased variables so most of the procedures share the same RAM. The library itself uses about 150 bytes of RAM and then add the procedure calls, compiler math variables, fonts - in most cases about 200-400 bytes in total. Touch calibration uses some extra RAM.

I presume you can then have an area where text can be displayed and changed on top of the bitmap?

You can overlay text anywhere on the screen. If you have to change the text you can

- use standard size font with background option thus the background color erasing old text
- you can erase the old text with a solid fill figure (rectangle) and print new text with fancy BDF (variable size) font
- print another/same BMP file using print at coordinates X;Y option over the old text to remove it and/or print new text

Some TFT screens have SMD places for Serial FLASH memory or one can simply include it in the design. Now I am extending the library with external FLASH memory option where you can transfer BMP files from SD card to FLASH memory. There will be a simple file system built in the FLASH chip and you can print BMP files directly from the FLASH memory using either index or name.

The big advantage is reading and printing speed since there's no math processing - simply read image pixel bytes from memory and send them to screen. Since names can be aliased one can create quick dynamic menus - for example:

Program one transferring graphics from SD card to FLASH:

'Write P001.BMP .... to Flash memory
TftTransferSdToFlash(P001.BMP)
TftTransferSdToFlash(P002.BMP)
TftTransferSdToFlash(P003.BMP)
TftTransferSdToFlash(P004.BMP)
TftTransferSdToFlash(P005.BMP)

Program two using FLASH memory:

Symbol TickPlacedOnMenu_One = P003.BMP
'Use P003.BMP
TftPrintFromFlash(TickPlacedOnMenu_One, 150, 30)

This will read and print file P003.BMP from FLASH memory to TFT screen position x=150;y=30

[JonW]

I get it, so you can have multiple BMP instances, Ex an empty box, then add a box with a tick if selected. I guess you just need to remember what is selected if a full refresh or another screen is booted. 

[trastikata]

I get it, so you can have multiple BMP instances, Ex an empty box, then add a box with a tick if selected. I guess you just need to remember what is selected if a full refresh or another screen is booted. 

You don't always have to use BMP files. Simple shapes from the library are quite fast to print. For example an empty tick box is solid color rectangle figure with one or several pixels shell as frame. Then to remove the tick mark just print the solid color rectangle shape from library, ex:

- print empty rectangle, red color, 3 pixel thick outwards
- print inside it a solid color blue rectangle
- if clicked on it
-- toggle a bit in a variable
-- print tick mark from BMP file
...
- if clicked on it again
-- toggle same bit in a variable
-- print inside a solid color blue rectangle to remove the tick mark.

Of course a fancy tick mark extending over the tick box shell would require toggling between two BMP files.

Since BMP files can be printed at any arbitrary location, you can use two BMP files (tick on and tick off) for many menus ... just an example.

[JonW]

Oh, I am going to have to give this a go now! I'm supposed to be working on an RF project, have the USB as a side project, and now this! Tangent Tom at his best.  Great work!

[SeanG_65]

This is, perhaps, the most AWESOME thing I have seen Positron used for!

[trastikata]

Version 0.2 (TFT_LIB_0_20.zip) has been uploaded to the original post.

With the new version you can transfer BMP files from SD cards to SPI FLASH memory. As I mentioned some TFT screens have FLASH memory or SMD slots for flash memory. Or you can include it in your PCB design.



This is very useful because you can use it to store multiple pictures (in this case BMP files) and reading those BMP files to create high quality dynamic menus (discussed here: https://protoncompiler.com/index.php?msg=17489). So I've included option for transferring BMP files from SD card to FLASH memory using simple file system where you can add files and full erase FLASH memory. Then those files can be used by index of addition or by file name.

Updated library has following additional commands:

TftBmpFlashSet()
-procedure to initialize Flash memory

TftBmpSdToFlashTftBmpSdToFlash(sFileName)
- Transfer BMP file from SD card To memory

TftBmpFlashFileName(wFileIndex)
- Get BMP file name from Flash memory index

TftBmpFromFlashName(sFileName, wX_Pos, wY_Pos)
- Print a BMP file from Flash memory

TftBmpFromFlashIndex(wFileIndex, wX_Pos, wY_Pos)
- Print a BMP file from Flash memory

First I used KRITA - a highest quality opensource image editing software to create and crop the different elements from the TFT menu, and save them as BMP file. With the help of a small Excel file where I record the name, crop coordinates and image size for each BMP element, all the commands, necessary for the menu, are created automatically. Then it is a simple matter of correctly applying those commands at the correct time in the program.

The result, I think, is visually quite pleasing considering this is 2 hours work having to do it for the first time including creating the Excel file. Those files are included in the library demo.

 

[normnet]

Great project trastikata!  What are your thoughts on video by use of a 200 MHz Pic?

[trastikata]

What are your thoughts on video by use of a 200 MHz Pic?

Actually I've just finished modifying the 16b FAT32/FAT16 library included in Positron to work on 8b devices and video was my next task to try.

...

21 fps * 2 byte/pixel (16b color) * 320 width * 240 height = 3 225 600 bytes/s

Forget any kind of video decoding, should be raw pixels. Assuming there's no video decoding and parallel display port display - it's doable.

If a screen with a SPI port is used - then maybe with two SPI modules. If the SD card and the screen share the same SPI port, then it's a no-go, because you can't pause the screen transfer in bulk mode (dumping pixels into graphic memory using width*height window).

[normnet]

Cool.  There also is challenge the sourcing of video content in a suitable format?  Perhaps a cell phone or other video played back on a PC with an app capturing BMP screen grabs to be converted into raw pixel format would work?     

 

[trastikata]

I've updated the original post to version 0.30 :

v.0.30 - Fixed some $define bugs
      - Modified "BMP_SD16.inc" to "BMP_SD.inc"
      - "BMP_SD.inc" now supports 16-bit and 8-bit MCUs
      - New program header 

By the way "BMP_SD.inc" is modified version of Les' "FileSys24.inc" to support SD cards with FAT32/FAT16 systems with 8-bit and 16-bit PICs, both hardware SPI and software SPI.

I've modified the "FileSys24.inc" with regards to the TFT library, but it should have the same capabilities as "FileSys24.inc" however now for both 8-bit and 16-bit MCU's and I've add hardware SPI to the software bit-banging.

[top204]

Excellent coding, and many thanks.

I've had a quick look through the code and not noticed anything to read the LCD. I am hoping to find the time to add a simple sprite mechanism, and this will require the parallel interface and the R/W line manipulated to read and store the pixels under where the sprite will go, then place the background back when the sprite has moved.

Using one of the smaller colour modes, such as RGB323, on the LCD (if they still have that mode) means that an 8-bit value can to be read for a single pixel, and written for a single pixel. Instead of reading 16-bit RGB565, which will slow things down a bit when multiple, or larger, sprites are used.

Crickey.... I haven't created a sprite mechanism since my ZX Spectrum days, because the 8-bit computers I worked on after that had simple hardware sprites. i.e. Atari 800 and Commodore 64, but the ZX Spectrum had to be bit-bashed with high optimisation for sprites on the screen, and some of the later games for it operated like magic because of a programmer's skills, especially the later isometric games.

The good old days of having to work and study to get something done, instead of just using a larger and faster, and more expensive computer, that takes the actual fun out of it.

[DaveS]

Excellent coding, and many thanks.
I've had a quick look through the code and not noticed anything to read the LCD. I am hoping to find the time to add a simple sprite mechanism, and this will require the parallel interface and the R/W line manipulated to read and store the pixels under where the sprite will go, then place the background back when the sprite has moved.
Using one of the smaller colour modes, such as RGB323, on the LCD (if they still have that mode) means that an 8-bit value can to be read for a single pixel, and written for a single pixel. Instead of reading 16-bit RGB565, which will slow things down a bit when multiple, or larger, sprites are used.
Crickey.... I haven't created a sprite mechanism since my ZX Spectrum days, because the 8-bit computers I worked on after that had simple hardware sprites. i.e. Atari 800 and Commodore 64, but the ZX Spectrum had to be bit-bashed with high optimisation for sprites on the screen, and some of the later games for it operated like magic because of a programmer's skills, especially the later isometric games.
The good old days of having to work and study to get something done, instead of just using a larger and faster device, that takes the actual fun out of it.

I was going to write something similar years ago but never got around to it, using 16 colours, 2 pixels per byte, you then use it to get the colour from a array of what ever size the screen pixel requires, more universal.
You could just have 16 set colours or have any 16 colours the LCD can handle.

[trastikata]

There also is challenge the sourcing of video content in a suitable format?  Perhaps a cell phone or other video played back on a PC with an app capturing BMP screen grabs to be converted into raw pixel format would work?     

Sneaky preview ...

Video/Picture converter to RGB565, automatic upload to SD card writing as RAW bytes and $define/command ...





And video / picture play from raw SD card.

I still have to test and finish some small final touches, just to let you know there's a good progress