Disecting UTFT "library"

Other Hardware Displays
1

I am punishing myself by rebuilding UTFT "library" to emulate standard LCD ( Hitachi controller based ) code.

The "main" obstacle in using UTFT "as is " - it is ( the class itself ) trying to be universal. Not a bad idea by itself, but it is locked to connect to "shields" pins and I have just raw TFT LCD module with 40 pins and I like to connect to my existing SAM3x8e vacant pins.

Hardware in no problem, it is the way UTFT software is build.

Here is an example in setting pin mode / direction:

void UTFT::_set_direction_registers(byte mode)
{
if (mode==16)
{
REG_PIOA_OER=0xc080; //PA7,PA14,PA15 enable
REG_PIOB_OER=0x4000000; //PB26 enable
REG_PIOC_OER=0x3e; //PC1 - PC5 enable
REG_PIOD_OER=0x64f; //PD0-3,PD6,PD9-10 enable
}
}

This function sets the direction registers just fine , but they are for some specific shield.
I did not bother to find out which one, don't need that info.

I am all for working at "registers level", but why in this case?

I am connecting to / using Due pins 22 thru 53 so what is wrong in simply setting registers to output using pinMode API?
During class instantiation speed is immaterial.

for ( int i = 22; i != 53; i++)
pinMode(i, OUTPUT);

I finding search for current source code on Github rather awkward.
digitalPinToPort is next on my search list.

Any commentary, preferably to the subject of TFT LCD, or other ideas would be appreciated.

2

UTFT is designed to be both universal and easy to use.

Yes, it expects a fixed data bus. You can alter the hardware/arm/chip.c file to suit your requirements
I have added one for the SAMD21 in a Zero.
I tend to use "mcufriend" style shields with a Uno. So I have support for that particular "data bus"

Yes, you could write your chip.c to use pinMode() and digitalWrite(). And add an extra 8 or 16 arguments to every constructor. UTFT is slow enough as it is. digitalWrite() would be painful. Even digitalPinToPort() would be slow.

OTOH, UTFT is designed to be "Universal". So the ultimate flexibility would be to use constructors with 22 arguments !!!

David.

3

David,
I really appreciate you reply, I need someone to bounce things off.
It helps not to fly solo.

david_prentice:
UTFT is designed to be both universal and easy to use.

Yes, it expects a fixed data bus. You can alter the hardware/arm/chip.c file to suit your requirements
I have added one for the SAMD21 in a Zero.
I tend to use "mcufriend" style shields with a Uno. So I have support for that particular "data bus"

Yes, you could write your chip.c to use pinMode() and digitalWrite(). And add an extra 8 or 16 arguments to every constructor. UTFT is slow enough as it is. digitalWrite() would be painful. Even digitalPinToPort() would be slow.

OTOH, UTFT is designed to be "Universal". So the ultimate flexibility would be to use constructors with 22 arguments !!!

David.

Funny thing, I am starting with this constructor:

TFT_LCD(
int disp_x_size, int disp_y_size, //size x y
byte display_transfer_mode, // data bus width
int RS, int WR, int CS, int RST, // LCD control pins
byte DB0, byte DB1, byte DB2, byte DB3, byte DB4, byte DB5, byte DB6, byte BD7,
byte DB8, byte DB9 , byte DB10, byte DB11, byte DB12, byte DB13, byte DB14, byte DB15
);

bool InvalidParameter = true; // modified by constructor since it cannot return anything

I'll thing the next one will be more "cosmetic", using array for data pins HA HA

UTFT is OK , but I find it rather typical of common classes - lack of "why is it coded this way " comments.

I am still learning how to access registers.

And another thing is puzzling to me - I hear comments about how slow the API's are , but since I have never worked with pixel LCD I need to have all my code working before I can pass a judgement on that .
For now I'll use API's to set the pixels and later replace them with direct registers access.

I think that way I'll have a "sample code" in API I can follow to make me more familiar with registers access.

Thanks for your support, have a great day.
Vaclav

4

Just in case anybody is following my travels thru the code.
Found a real gem in accessing the SAM's processor hardware.
A neat combination of struct, array of struct, macros, pointers - your name it, it is used.
Sure would like to meet the guy who dreamed this up, nice work.
Little hard to navigate thru few #include files.

Here is the foundation (struct) of all of this:

//typedef struct _PinDescription
//{
// Pio* pPort ;
// uint32_t ulPin ;
// uint32_t ulPeripheralId ;
// EPioType ulPinType ;
// uint32_t ulPinConfiguration ;
// uint32_t ulPinAttribute ;
// EAnalogChannel ulAnalogChannel ; /* Analog pin in the Arduino context (label on the board) /
// EAnalogChannel ulADCChannelNumber ; / ADC Channel number in the SAM device /
// EPWMChannel ulPWMChannel ;
// ETCChannel ulTCChannel ;
//} PinDescription ;
//
/// Pins table to be instanciated into variant.cpp */
//extern const PinDescription g_APinDescription[] ;