ST7735_t3 Bug introduced between 1.46 & 1.47

UHF

Well-known member
Hello I'm using a T3.6 with the audio board. I have a ST7735s based TFT attached. It crashes on: tft.initR(INITR_GREENTAB); with nothing further. This has been introduced in 1.47, 1.46 works fine when I go back to it.

This is at the top:

Code:
#define sclk 20 
#define mosi 21 
#define cs  2  
#define dc   3  
#define rst  8  

#include <ST7735_t3.h> 

ST7735_t3 tft = ST7735_t3(cs, dc, mosi, sclk, rst);

Sorry no further information.
 
Hello I'm using a T3.6 with the audio board. I have a ST7735s based TFT attached. It crashes on: tft.initR(INITR_GREENTAB); with nothing further. This has been introduced in 1.47, 1.46 works fine when I go back to it.

This is at the top:

Code:
#define sclk 20 
#define mosi 21 
#define cs  2  
#define dc   3  
#define rst  8  

#include <ST7735_t3.h> 

ST7735_t3 tft = ST7735_t3(cs, dc, mosi, sclk, rst);

Sorry no further information.

Note, if you want the display to be fast as possible, you need both CS and DC to be on the SPI fast pins:
  • Pin 2 or Pin 10 (you can't use both 2 & 10 for SPI at the same time);
  • Pin 6 or Pin 9 (you can't use both 6 & 9 for SPI at the same time);
  • Pin 15/A1;
  • Pin 23/A9 or Pin 20/A6 (you can't use both 23 and 20 for SPI at the same time);
  • Pin 22/A8 or Pin 21/A7 (you can't use both 22 and 21 for SPI at the same time).

Given you are using alternate pins for SCLK (normally pin 13) and MOSI (normally pin 11), I would imagine that means you can't use pins 20-23 for CS or DC.
 
@UHF I will take a look - For the most part I did not even look at or I thought touch how the bit bang versions of the library worked. And in actuality wondered if it should be removed, as you could just as simply use the Adafruit library for the bit banging support.

As @michaelMeissner mentioned there are/were restrictions on what pins could be used to run with this code using Hardware SPI.
And in the older releases on T3.x boards it only supported SPI(0) in SPI mode. So while you specified SPI1 pins for MOSI and SCK, it did not care and simply did/does bit bang outputs to all pins...

Newer code has tried to add support for SPI1 and SPI2 on those chips, however it currently restricts using the hardware SPI in SPI mode if MOSI, SCK and DC are on hardware SPI pins, or it still defaults to bitbang... I believe the only SPI CS pins for SPI1 on T3.5/6 are (6 and 31). This is not counting that there are actually several others on the pins associated with the SDCard.

Again I will take a quick look to see why the banging does not work...
 
Yes, in looking at pins 20/21, I see they are used as alternate pins for SPI1 (pin 0 being the main MOSI1 pin, pin 32 being the main SCK1 pin, and pin 31 being the main CS pin), not SPI0. Given SPI1 and SPI2 only have one fast pin, I believe you can only use SPI0 for fast displays that need both CS and DC being fast pins.

I believe the fast displays use DMA to transfer data to the display in the background, while the normal SPI and bit banging SPI are blocking.
 
@UHF @mjs513 @PaulStoffregen @MichaelMeissner

I put in a fix in two different branches.

The first one is in a branch that I already have an outstanding Pull Request to fix some DMA issues with T4 when the TFT object is created in high memory, i.e. new ST7735_t3(...)

This is PR: https://github.com/PaulStoffregen/ST7735_t3/pull/3
Which is in the fork/branch: https://github.com/KurtE/ST7735_t3/tree/T4_DMA_LOW

@mjs513 - I also put the same change (more or less) in the branch that I did a PR yesterday to your rewrite branch...

It is simply making sure if we call writecommand_last it checks that we are doing hardware SPI before it tries to, and if not, it goes off and does the bitbanging.


Note: I simply verified it runs. I don't necessarily think the display is always updating correctly as probably the timings might be off...

But again if you can move your DC pin to pin 6 or 31 it will use the SPI1 hardware for this!

Also note: I have thought also about updating the code to better allow for this case, by detecting that MOSI and SCK are on hardware SPI pins and as such use hardware SPI. The code would have to not rely on PUSHR register to change DC so it would need to setup to know when it outputs something if it knows it is going to have to wait until everything completes output so that it can change the DC signal before it outputs the next.... Which the code already sort of knows. That is why there are functions like differentiation in some of the functions, like writedata versus writedata_last...
 
@UHF - You might try the files mentioned in my github in posting #5. It should work OK for your pins.

After the last posting, I also made a few more improvements for it. In particular now if it detects that MOSI and SCK are on a SPI buss, it will use that SPI buss. So no longer bit bang in this case. It still is not as optimal as if DC was on a SPI CS pin. Which would be either 6 or 31. But depending on just how fast you need it, may be sufficient. Note: I have not tried this with frame buffer and update screen code (new stuff), when we are in this case.

I am guessing that some, maybe all of it will work. But I really should probably disable some of that code when using random not CS pins.

Also may be a problem with T3.6 DMA code on this now... Again investigating.
 
@mjs513 and others,

Looks like the DMA stuff on T3.6 is not working (regardless if hardware CS on DC or not...)

Looks like having the DMASettings as part of the class structure is not working. It works if you make it static... But that does not work fully if you want multiple instances, like one per SPI buss. So may setup a static one for each possible SPI Buss...

What I found when it was part of class, it looks like it's constructor that cleared stuff out failed to run... Got garbage, tried memset to zero but that will cause system to crash as there is some internal data that must not be mucked with... Will try one more attempt before resorting to static member...
 
@mjs513 and others, have a fix for DMA on T3.6, which I pushed up to @mjs513 fork/branch, will now migrate back to my main branch that is in the current active PR to the master project.

Appears to be working now.
IMG_0136.jpg

Have it running 3 displays on T3.6 all on different SPI busses.
 
Back
Top