Teensy3 ST7735 Library

[sumotoy]

Finally solved the problem!
In my setup I got SD cs pin connected to 16 and TFT cs pin connected to 14. With this configuration the original Adafruit TFT library worked but Paul's optimized one apparently failed only with bitmaps (not sure the rest).
The only way I can get perfectly working is use one of the following Teensy3 pins for CS: 2/6/9/10/15/20/21/22/23
I changed pin 14 to 2 et voilà, bitmap appears magically... Maybe is related to what paul's called "CS native pins"?
I hope this will be useful for someone... In the meantime I will study the SD side code to try understand why some pin works and some not.

[igor p]

Hi, is there any option to have some other type of fonts used with tis library?

[ErikRasmussen]

Thanks for the great work. This is really a good driver!
I was missing a function for frame transfer from RAM to TFT. Below an example:

Declare a RAM frame:
uint16_t tftRam[128*160];

The function:
void PutRam (void)
{
disp.setAddrWindow(0, 0, 127, 159);
for (uint16_t i = 0; i < (128*160); i++)
{
disp.writedata16(tftRam[i]);
}
}

Results on Teensy 3.6 @ 180 MHz: 48 ms to generate a test picture and upload it.

Make this modification in the driver:
Arduino modification: in the file ST7735_t3.h in C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\ST7735 _t3:
The function writedata16() must be changed from private to public.

[ErikRasmussen]

More details regarding frame transfer to ST7735 based TFT display:

//************************************************** ***********************
// TFT RAM buffer!
// RAM usage: Size = 128 * 160 * 16 bit = 40.960 byes.
// x,y = 0,0 = lower left corner, nearest to display pin 1. X = horizontal [0..159], y = vertical [0..127]
// 5 bit color depth [0..31], 31 = max. 1 pixel = 16 bit = RRRR RGGG GGGBB BBB = bit[15..0].
// buffer position for individual pixel: tftRam[x * 128 + y]
//************************************************** ***********************

[dundakitty]

I'm a little confused about not using the RESET on an ST7735-based display.
If I set up the display with

  ST7735_t3 tft = ST7735_t3(10,  15);

It should ignore the RESET pin and use the default value. The ST7735_t3.h file says:

class ST7735_t3 : public Adafruit_GFX {

 public:

  ST7735_t3(uint8_t CS, uint8_t RS, uint8_t SID, uint8_t SCLK, uint8_t RST = -1);
  ST7735_t3(uint8_t CS, uint8_t RS, uint8_t RST = -1);

So the reset pin should be optional. The ST7735_t3 library has this in the constructor code:

// Constructor when using hardware SPI.  Faster, but must use SPI pins
// specific to each board type (e.g. 11,13 for Uno, 51,52 for Mega, etc.)
ST7735_t3::ST7735_t3(uint8_t cs, uint8_t rs, uint8_t rst) :
  Adafruit_GFX(ST7735_TFTWIDTH, ST7735_TFTHEIGHT_18) {
	_cs   = cs;
	_rs   = rs;
	_rst  = rst;
	hwSPI = true;
	_sid  = _sclk = (uint8_t)-1;
}

All seems good, the RESET pin is saved into _rst, which is declared as uint8_t. The problem comes in where it is used in commonInit():

	if (_rst) {
		pinMode(_rst, OUTPUT);
		digitalWrite(_rst, HIGH);
		delay(5);
		digitalWrite(_rst, LOW);
		delay(100);
		digitalWrite(_rst, HIGH);
		delay(5);
	}

When the RESET pin is left off of the constructor, _rst is initialized to -1. _rst is declared as uint8_t, so its value is really 0xff. The commonInit() code is using _rst as a boolean.
I expect 0xff to be evaluated as True, so the reset code is executed using an invalid pin number (0xff). It probably doesn't hurt anything, but it does add an unnecessary delay.
It looks to me like the only way to not use the RESET is to specify pin number 0, a perfectly valid pin.

Am I just not reading the code right?