Port of UTFT to Teensy 4.0 available ?

Hello,

I know it is a lazy man´s question but I wanted to replace a Teensy 3.1 for a brand new 4.0 on a LCD display project using UTFT but I cannot compile even after some changes in the code, it complains about GPIOD_PDOR and other ports.

I am not skilled enough to create this port of UTFT, has anybody figured out how to do it ? The one included with TD does not recognize the IMXRT1062 chip...

Cheers,

Luiz Roberto
 
Hello. I want to up this thread. Will be realize support Teensy 4.0 in UTFT library ? Is available any graphic library support for Teensy 4.0 ?

Thanks,

Ihar
 
Hello. I want to up this thread. Will be realize support Teensy 4.0 in UTFT library ? Is available any graphic library support for Teensy 4.0 ?

Thanks,

Ihar

Hi, I got in touch with the UTFT library creator and he told me that sadly, due to the copyright infringements that his library have suffered from display manufacturers like the one I was asking support for, he would provide no support for it.

I checked some postings on the forum and found that T4.0 does not fully support the parallel mode in contiguous output pins that are required to communicate with the display and was considering creating the required core function to support the library myself but did not find the time for this yet. From the posts I found that some 12 bits would be possible to be written on a port with a single instruction but the remaining would have to be set or reset individually thus reducing the performance but I cannot imagine by how much.

For my tests I would have to run a benchmark with my current T3.2 hardware and then exchanging it for a T4.0 with my modifications to the library kernel to see if it was worth exchanging one Teensy for the other.

But now this small project is in the backburner...

Luiz
 
What screen do you want to use with UTFT?. It is possible that there is an alternative library.

Hi, it is a BuyDisplay ER-TFTM070-4 with the SSD1963 controller with a 16-bit parallel 8080 interface and a capacitive touch screen. I also have several other 7" with the same chipset and resistive touchscreen.

Hope you have some library for it.

Cheers,

Luiz
 
Until now we do not have any approximation of the UTFT library to teensy 4. For teensy 3.2 there is support, with some minor adjustment in UTFT.ccp, it is possible to extend the library to teensy 3.6 or 3.5, however it does not apply to teensy 4. The cause is the GPIO nomenclature.

Code:
#elif defined(__arm__)
	#include "hardware/arm/HW_ARM.h"
	#if defined(__SAM3X8E__)
		#pragma message("Compiling for Arduino Due (AT91SAM3X8E)...")
		#include "hardware/arm/HW_SAM3X8E.h"
//	#elif defined(__MK20DX128__) || defined(__MK20DX256__) || defined(__MK66FX1M0VMD18__)
	#elif defined(TEENSYDUINO)
		#pragma message("Compiling for Teensy 3.x (MK20DX128VLH7 / MK20DX256VLH7)...")
		#include "hardware/arm/HW_MX20DX256.h"
	#elif defined(__CC3200R1M1RGC__)
		#pragma message("Compiling for TI CC3200 LaunchPad...")
		#include "hardware/arm/HW_CC3200.h"
	#else
		#error "Unsupported ARM MCU!"
	#endif
#endif

In the tests I did on a 3.2 "ILI9341 SPI screen, it is possible to use the UTFT library with teensy 3.6. I'd like to do some testing with a 16-bit TFT, to see if it might work in teensy 3.6.

rm0szupunebni7xzg.jpg


Correcting the errors that the IDE reports regarding the GPIO in teensy 4 would be the starting point to extend the compatibility of the UTFT library. This is one of the errors in the GPIO:

Code:
UTFT\hardware/arm/HW_MX20DX256.h:83:26: error: 'GPIOD_PDOR' was not declared in this scope
   *(volatile uint8_t *)(&GPIOD_PDOR) = VH;
 
Correcting the errors that the IDE reports regarding the GPIO in teensy 4 would be the starting point to extend the compatibility of the UTFT library. This is one of the errors in the GPIO:

Code:
UTFT\hardware/arm/HW_MX20DX256.h:83:26: error: 'GPIOD_PDOR' was not declared in this scope
   *(volatile uint8_t *)(&GPIOD_PDOR) = VH;

Yeah, that was the error I got when I first tried to compile my code for the T4.0. There is no GPIOD on T4.0 so you have to write bit-by-bit the I/O to the display, which will most likely negate the speed advantage of the T4.0 over the T3.1 that I am using right now.

I studied several posts on the T4.0 forum and one of the users, Paula (kudos!), came up with a solution for writing 12 bits in parallel, which would recover a lot of the speed advantage, but as I said before I have this small project on hold due to its complexity. But your post gave me another idea : since the T4.0 is so much faster than the T3.1, perhaps I would switch the display interface from 16 bit access to 8 bit only and thus will need only to use the 12 bits parallel access that Paula has discovered.

In these lockdown days, perhaps I will put this project back on the table.

Cheers,

Luiz
 
Back
Top