Support for ST7735 128x128

[olikraus]

this is a display, which is in my lab, but is still unsupported

[gitcnd]

Ucglib_ST7735_18x128x160_SWSPI almost works with this board http://forum.arduino.cc/index.php?topic=378158.new#new

[olikraus]

thanks for the link

[olikraus]

postponing this

[a-schommer]

I guess i have the same module, but it is unlabelled (part of a bundle) and i can't see anything but a dumb bus driver chip. There is one nasty point about it: it seems to have some offsets to the x/y coordinates even changing with the rotation. I get it almost working with the ST7735 setup. And i also have sources (copyright unknown!) that really work - commented in chinese (i guess), but mentioning "ST7735R" - whatever that may be; maybe someone understands. I'd try to extend ucglib myself, but i have no idea how to implement the offsets without lots of effort (or corrupting every other devices support).

[olikraus]

The problem is this: There might be a x/y offset between the display itself and the controller memory. Especially this can happen if the display is smaller than the controller memory. For example if the controller supports 132x162 pixel, but the display only has 128x160 pixel. In such a case, the display window may appear anywhere in the RAM area of the display (actually this is defined by the wiring of between display controller and display matrix). Ucglib had been developed under the assumption, that this offset is always 0: Either the controller RAM size and the display size matches or the display is placed at the RAM origin (which does not seem to be true in your case).

In some cases the display controller is able to move the origin for its own memory to a different position, but it looks like that this is not supported by the ST7735. Well, it needs to be checked. If this is possible, then you could simply apply those commands here: https://github.com/olikraus/ucglib/blob/master/csrc/ucg_dev_tft_128x160_st7735.c#L41

If the driver ic does not support setting a none zero offset, then it will be more complicated: You need to modify the ic subsystem of ucglib at different places, e.g. here https://github.com/olikraus/ucglib/blob/master/csrc/ucg_dev_ic_st7735.c#L144

Unfortunately a none-zero offset is not foreseen by ucglib.

[ftjuh]

My display, too, shows these 2 pixel wide borders on one side with random data, i.e. a wrong offset, similar to the one shown here.

Adafruit_ST7735 will show the same offset, but it can be eliminated by chosing the INITR_144GREENTAB initializer in setup():

tft.initR(INITR_144GREENTAB); // Init ST7735R chip, green tab 

So I had a look at the differences between the default INITR_BLACKTAB initializer and the INITR_144GREENTAB one. I found that they add offsets in the CASET and PASET commands (interestingly in another initializer). I fiddled around a bit with the respective initializing code in ucg_dev_tft_128x160_st7735.c and found that subtracting the Adafruit offsets gets the job done, i.e. will eliminate the 2 pixel border:

  UCG_C14(  0x02a, 0x000, 0x000, 0x000, 0x07f - 2),              /* Horizontal GRAM Address Set */
  UCG_C14(  0x02b, 0x000, 0x000, 0x000, 0x07f - 1),              /* Vertical GRAM Address Set */

However, this will only work in Rotation 0, with the other rotations the border is there again. Also, of course, the display size is wrong, but I assume this is a minor problem to solve.

So, I feel I'm on the right track here, but it'll need some further digging in the code. As the sequence is the same for all rotations, I'm not sure exactly where to dig, though. So I'm not confident I will be able to make this into a PR without possibly breaking things.

Oli, any ideas, or would you be willing to take over from here?

Jan

BTW: you might be interested to learn that I used Ucglib in my I2Cwrapper project to control TFTs over I2C.

[olikraus]

So, I feel I'm on the right track here, but it'll need some further digging in the code.

Mostly yes.

The problem seems to be, that the upper left corner of the visible display area differs from the upper left corner of the graphics RAM in the controller. I see two options:

A) If the display controller is powerful enough, then this offset can be handled by the controller. B) If not, then a compensation of the offset in software is required.

I think A) can not be fully done, so B) is required here.

The problem with ucglib is, that such a compensating offset is not available. The assumtion in ucglib is exactly that this offset is 0 for x and y.

A pure software solution could be to introduce the offset into https://github.com/olikraus/Ucglib_Arduino/blob/e21641a6c1ddb0e71f7b9e01501fa739786c68b1/src/clib/ucg_dev_ic_st7735.c

For example this https://github.com/olikraus/Ucglib_Arduino/blob/e21641a6c1ddb0e71f7b9e01501fa739786c68b1/src/clib/ucg_dev_ic_st7735.c#L131-L133

needs to be changed to this:

      case 0: 
        tmp = ucg->arg.pixel.pos.x;    // store current x value
        ucg->arg.pixel.pos.x += x_offset_compensation;  // offset compensation
    ucg_com_SendCmdSeq(ucg, ucg_st7735_set_pos_dir0_seq);   
        ucg->arg.pixel.pos.x = tmp; // restore x value
    break;

This has to be applied to all cases in all procedures in that file.