Adafruit-ST7735-Library
Adafruit-ST7735-Library copied to clipboard
adafruit
Better document that SPI speed is set with setSPISpeed after initR and not begin()
With other TFTs, you set speed withtft->begin(spispeed)
With ST77xx, begin() is protected in Adafruit_ST77xx.h, so you cannot call tft->begin(tft_spi_speed). The documentation in the .cpp file therefore seem unusable:
/**************************************************************************/
/*!
@brief Initialize ST77xx chip. Connects to the ST77XX over SPI and
sends initialization procedure commands
@param freq Desired SPI clock frequency
*/
/**************************************************************************/
void Adafruit_ST77xx::begin(uint32_t freq) {
if (!freq) {
freq = SPI_DEFAULT_FREQ;
}
_freq = freq;
Then we have this which basically ensures you can't call begin with a different frequency.
void Adafruit_ST77xx::commonInit(const uint8_t *cmdList) {
begin();
As a result, The only way to change the SPI speed is to do
// tft->begin(tft_spi_speed) // does not work and you don't need to call begin anyway
tft->initR(INITR_BLACKTAB);
tft->setSPISpeed(tft_spi_speed); // this works.
I'm not sure what's the best way to make this findable. Maybe put a hint in "void Adafruit_ST77xx::begin(uint32_t freq) {" ?
Sorry for the delay @ladyada , done in https://github.com/adafruit/Adafruit-ST7735-Library/pull/114
That said, back to void Adafruit_ST77xx::begin(uint32_t freq) is there any way for it to be called with a frequency, or is it always called through InitR, in which case the freq argument is a bit misleading and should arguably be removed? (I'm not pushing for this, but I was very confused to see the argument only to realize later that it didn't really seem possible to actually pass it)
@ladyada yep, looks like it. Are you ok removing it, or getting help from @makermelissa to remove it, or would you like me to send a PR?
Guys, the way we have implemented that whole init process makes display unusable. Mine goes blank white because SPI starts @ 8 MHz and even I do set the frequency later it doesn't help. Normally developer should be able to set frequency before initialization.
tft.setSPIFreqency(1000000); // set 1 MHz
tft.initR(); // init @ 1 MHz.
Hello,
I have a program that was working on STM32F103CBT6 (Arduino core STM32 support) with Adafruit GFX and ST775 libraries but not anymore with new versions. I am quite certain this is related to the SPI. Could you clarify how to set the SPI speed ?
I am currently using
SPI.setClockDivider(SPI_CLOCK_DIV2); tft.initR(INITR_144GREENTAB);
Hello, my 1.8" TFT display runs fine on SW SPI with he AdafruitST7735 library on a UNO. It needs to be initialized as a GREENTAB display. It is a tad slow, so I would like to start using HW SPI. It runs on SW SPI with all SPI-related wires connected to the pins needed for HW SPI. After many trials and reading of webpages, I have not succeeded in getting it to work on HW SPI at all.
So, I took my scope out, and connected it to the serial clock wire. In SW SPI mode, there is a clock of about 200 kHz, while in HW SPI mode, there is a clock of 8 MHz. So, I may be looking at a speed problem (in my setup, the distance from chip to TFT is about 12 cm).
As a first step, I would like to lower the HW SPI speed, and see if I can get it work. Then, I would like to see if I can increase the speed by, for example, inserting resistors in the clock and data lines to dampen reflections.
I have tried the suggestion mentioned in a post above:
// tft->begin(tft_spi_speed) // does not work and you don't need to call begin anyway tft->initR(INITR_BLACKTAB); tft->setSPISpeed(tft_spi_speed); // this works.
But this doesn't work: the initialization fails! This is confirmed by one of the later posts in this thread:
Guys, the way we have implemented that whole init process makes display unusable. Mine goes blank white because SPI starts @ 8 MHz and even I do set the frequency later it doesn't help. Normally developer should be able to set frequency before initialization.
tft.setSPIFreqency(1000000); // set 1 MHz tft.initR(); // init @ 1 MHz.
This is exactly my situation: the screen simply goes blank... I would like to set the speed to a lower value before initialization.
So the question is: how can I reduce the HW SPI speed while using the ST7735 library??
Update: given the information in the original post about what happens inside the libraries, I decided to do a hack. Playing around with the defined value of SPI_DEFAULT_FREQ was successful. First value I tried was 1000000 (1 MHz), chosen to approximately result in the SW SPI speed, and it worked right off the bat! After a bit of trying, my display stops working somewhere between 6 and 8 MHz. So for the time being, I use 6 MHz, giving me a speed increase of about a factor of 8 over SW SPI. I will try to fiddle around a bit with resistors to see if the speed can be further improved.
Despite this success however, the question as stated in my previous post remains !! (At least, I would not like to do this hack every time Adafruit decides to publish a new version....)
Update 2: After considering how the "old" way of setting SPI speed is done using a clock divider of a power of 2, I guess that my display stops working somewhere between 4 and 8 MHz, and that for the UNO controller anything in between is essentially meaningless.
Perhaps things change when I would switch to another device, if that device can make other SPI clocks. But in that case, also my setup will change in other ways, like the SPI bus length. And so the maximum clock that I can use for my display might also change (compared to my current setup).
So, given that in some systems the SPI bus wiring creates the speed bottleneck (my system may or may not be an example), then how do I set or choose the SPI frequency parameter? What does the parameter mean anyway? Is it the maximum speed of the display? Or of the physical bus? Or a combination of the two?
I understand that the display library tries to make things simple for the Arduino user, but in doing it this way, it controls a parameter that is not (fully) in its scope in the system. Example: consider what happens if the SPI bus connects to a display plus some other device, especially if that device forms the speed bottleneck?
So, given that the maximum SPI speed may be determined by more than just the display itself, the question is why the display library should set the SPI speed in the first place. At least, the system designer/constructor should have the option of setting it outside the display library. To me, it would make more sense to leave the maximum speed setting to the SPI library.
First, I would recommend ditching the uno, it can do things, but it's so old and obsolete, while costing more than an ESP32 which is vastly superior in many ways. That being said, I have had SPI displays that didn't work past 10Mhz or so, and it was often due to my wiring, length, cross talk and quality of wires. When I talked to the same display with the same chip on a circuit board with proper copper traces, I was able to use 40 to 80Mhz. Also, I recommend this TFT library, it's faster and has more options: https://www.arduino.cc/reference/en/libraries/gfx-library-for-arduino/
Hello Marc,
Many thanks for your advice and tips! Indeed, I have used the UNO with great pleasure for a long time, but I guess it is indeed time to start using something more advanced.
I think we agree that there is a good chance that the bus wiring determines the maximum speed. Unfortunately, this particular setup does not allow the wire length to be shortened, or otherwise improved. With the scope I do see significant under- and overshoot, so next I will try clamping diodes as potential improvement.
The gfx library you suggested seems an interesting one. I need some time to figure out how to tailor it to my particular setup. Once I have it up and running, I will let you know!
Cheers,
Evert-Jan
On Mon, Aug 1, 2022 at 2:05 AM Marc MERLIN @.***> wrote:
First, I would recommend ditching the uno, it can do things, but it's so old and obsolete, while costing more than an ESP32 which is vastly superior in many ways. That being said, I have had SPI displays that didn't work past 10Mhz or so, and it was often due to my wiring, length, cross talk and quality of wires. When I talked to the same display with the same chip on a circuit board with proper copper traces, I was able to use 40 to 80Mhz. Also, I recommend this TFT library, it's faster and has more options: https://www.arduino.cc/reference/en/libraries/gfx-library-for-arduino/
— Reply to this email directly, view it on GitHub https://github.com/adafruit/Adafruit-ST7735-Library/issues/107#issuecomment-1200533993, or unsubscribe https://github.com/notifications/unsubscribe-auth/A2JNRP2LZJ7INDMGFTPGMWLVW4IFZANCNFSM4KMLS3AQ . You are receiving this because you commented.Message ID: @.***>
Hello Marc,
I have tried the gfx library you suggested. After reading the wiki pages for the bus and display invocations, I tried to bring the HelloWorld example to life. The initial code I have now looks as follows:
#include <Arduino_GFX_Library.h>
#define SPI_PIN_DC 7 #define SPI_PIN_CS GFX_NOT_DEFINED
#define GFX_PIN_RST 8 #define GFX_PIN_ROT 0 #define GFX_IPS false #define GFX_WIDTH 128 #define GFX_HEIGHT 160 #define GFX_COL_OFS1 2 #define GFX_ROW_OFS1 1 #define GFX_COL_OFS2 2 #define GFX_ROW_OFS2 1
Arduino_DataBus *bus = new Arduino_HWSPI(SPI_PIN_DC,SPI_PIN_CS);
Arduino_GFX *gfx = new Arduino_ST7735(bus,GFX_PIN_RST,GFX_PIN_ROT,GFX_IPS, GFX_WIDTH,GFX_HEIGHT,GFX_COL_OFS1,GFX_ROW_OFS1,GFX_COL_OFS2,GFX_ROW_OFS2);
The defines are as suggested by the wiki pages. (My display is a 7735 greentab.)
Changing the SPI speed is the same headache as with the AdaFruit library: it is all built-in, the speed cannot be changed from user code. So, I tried to hack it, similar to the AdaFruit case.
I have tried a few things, but nothing works: the screen stays stubbornly blank. Tomorrow, I will hook up my scope, to see what serial clock is present (if any).
Cheers for now,
EJ
On Thu, Aug 4, 2022 at 7:09 PM Evert-Jan Pol @.***> wrote:
Hello Marc,
Many thanks for your advice and tips! Indeed, I have used the UNO with great pleasure for a long time, but I guess it is indeed time to start using something more advanced.
I think we agree that there is a good chance that the bus wiring determines the maximum speed. Unfortunately, this particular setup does not allow the wire length to be shortened, or otherwise improved. With the scope I do see significant under- and overshoot, so next I will try clamping diodes as potential improvement.
The gfx library you suggested seems an interesting one. I need some time to figure out how to tailor it to my particular setup. Once I have it up and running, I will let you know!
Cheers,
Evert-Jan
On Mon, Aug 1, 2022 at 2:05 AM Marc MERLIN @.***> wrote:
First, I would recommend ditching the uno, it can do things, but it's so old and obsolete, while costing more than an ESP32 which is vastly superior in many ways. That being said, I have had SPI displays that didn't work past 10Mhz or so, and it was often due to my wiring, length, cross talk and quality of wires. When I talked to the same display with the same chip on a circuit board with proper copper traces, I was able to use 40 to 80Mhz. Also, I recommend this TFT library, it's faster and has more options: https://www.arduino.cc/reference/en/libraries/gfx-library-for-arduino/
— Reply to this email directly, view it on GitHub https://github.com/adafruit/Adafruit-ST7735-Library/issues/107#issuecomment-1200533993, or unsubscribe https://github.com/notifications/unsubscribe-auth/A2JNRP2LZJ7INDMGFTPGMWLVW4IFZANCNFSM4KMLS3AQ . You are receiving this because you commented.Message ID: @.***>
update: In a flash of insight (Why didn't I think of this before?) I tried to get the display to work with software SPI.
It still doesn't work, the display stays blank. So I guess I must be doing something very wrong...
I will check the serial clock for both hardware and software SPI.
On Fri, Aug 5, 2022 at 8:47 PM Evert-Jan Pol @.***> wrote:
Hello Marc,
I have tried the gfx library you suggested. After reading the wiki pages for the bus and display invocations, I tried to bring the HelloWorld example to life. The initial code I have now looks as follows:
#include <Arduino_GFX_Library.h>
#define SPI_PIN_DC 7 #define SPI_PIN_CS GFX_NOT_DEFINED
#define GFX_PIN_RST 8 #define GFX_PIN_ROT 0 #define GFX_IPS false #define GFX_WIDTH 128 #define GFX_HEIGHT 160 #define GFX_COL_OFS1 2 #define GFX_ROW_OFS1 1 #define GFX_COL_OFS2 2 #define GFX_ROW_OFS2 1
Arduino_DataBus *bus = new Arduino_HWSPI(SPI_PIN_DC,SPI_PIN_CS);
Arduino_GFX *gfx = new Arduino_ST7735(bus,GFX_PIN_RST,GFX_PIN_ROT,GFX_IPS,
GFX_WIDTH,GFX_HEIGHT,GFX_COL_OFS1,GFX_ROW_OFS1,GFX_COL_OFS2,GFX_ROW_OFS2);
The defines are as suggested by the wiki pages. (My display is a 7735 greentab.)
Changing the SPI speed is the same headache as with the AdaFruit library: it is all built-in, the speed cannot be changed from user code. So, I tried to hack it, similar to the AdaFruit case.
I have tried a few things, but nothing works: the screen stays stubbornly blank. Tomorrow, I will hook up my scope, to see what serial clock is present (if any).
Cheers for now,
EJ
On Thu, Aug 4, 2022 at 7:09 PM Evert-Jan Pol @.***> wrote:
Hello Marc,
Many thanks for your advice and tips! Indeed, I have used the UNO with great pleasure for a long time, but I guess it is indeed time to start using something more advanced.
I think we agree that there is a good chance that the bus wiring determines the maximum speed. Unfortunately, this particular setup does not allow the wire length to be shortened, or otherwise improved. With the scope I do see significant under- and overshoot, so next I will try clamping diodes as potential improvement.
The gfx library you suggested seems an interesting one. I need some time to figure out how to tailor it to my particular setup. Once I have it up and running, I will let you know!
Cheers,
Evert-Jan
On Mon, Aug 1, 2022 at 2:05 AM Marc MERLIN @.***> wrote:
First, I would recommend ditching the uno, it can do things, but it's so old and obsolete, while costing more than an ESP32 which is vastly superior in many ways. That being said, I have had SPI displays that didn't work past 10Mhz or so, and it was often due to my wiring, length, cross talk and quality of wires. When I talked to the same display with the same chip on a circuit board with proper copper traces, I was able to use 40 to 80Mhz. Also, I recommend this TFT library, it's faster and has more options: https://www.arduino.cc/reference/en/libraries/gfx-library-for-arduino/
— Reply to this email directly, view it on GitHub https://github.com/adafruit/Adafruit-ST7735-Library/issues/107#issuecomment-1200533993, or unsubscribe https://github.com/notifications/unsubscribe-auth/A2JNRP2LZJ7INDMGFTPGMWLVW4IFZANCNFSM4KMLS3AQ . You are receiving this because you commented.Message ID: @.***>
udate2: SWSPI is working now. I made the changes in HelloWorld anew, and this time it worked, and it works reliably. So I suspect I made some mistake in my code yesterday.
HWSPI is still refusing coperation, though... I opened an issue on Github, simply asking how I can set a custom SPI speed from user code. Let's see what the library developer (librarian?) suggests!
On Fri, Aug 5, 2022 at 8:57 PM Evert-Jan Pol @.***> wrote:
update: In a flash of insight (Why didn't I think of this before?) I tried to get the display to work with software SPI.
It still doesn't work, the display stays blank. So I guess I must be doing something very wrong...
I will check the serial clock for both hardware and software SPI.
On Fri, Aug 5, 2022 at 8:47 PM Evert-Jan Pol @.***> wrote:
Hello Marc,
I have tried the gfx library you suggested. After reading the wiki pages for the bus and display invocations, I tried to bring the HelloWorld example to life. The initial code I have now looks as follows:
#include <Arduino_GFX_Library.h>
#define SPI_PIN_DC 7 #define SPI_PIN_CS GFX_NOT_DEFINED
#define GFX_PIN_RST 8 #define GFX_PIN_ROT 0 #define GFX_IPS false #define GFX_WIDTH 128 #define GFX_HEIGHT 160 #define GFX_COL_OFS1 2 #define GFX_ROW_OFS1 1 #define GFX_COL_OFS2 2 #define GFX_ROW_OFS2 1
Arduino_DataBus *bus = new Arduino_HWSPI(SPI_PIN_DC,SPI_PIN_CS);
Arduino_GFX *gfx = new Arduino_ST7735(bus,GFX_PIN_RST,GFX_PIN_ROT,GFX_IPS,
GFX_WIDTH,GFX_HEIGHT,GFX_COL_OFS1,GFX_ROW_OFS1,GFX_COL_OFS2,GFX_ROW_OFS2);
The defines are as suggested by the wiki pages. (My display is a 7735 greentab.)
Changing the SPI speed is the same headache as with the AdaFruit library: it is all built-in, the speed cannot be changed from user code. So, I tried to hack it, similar to the AdaFruit case.
I have tried a few things, but nothing works: the screen stays stubbornly blank. Tomorrow, I will hook up my scope, to see what serial clock is present (if any).
Cheers for now,
EJ
On Thu, Aug 4, 2022 at 7:09 PM Evert-Jan Pol @.***> wrote:
Hello Marc,
Many thanks for your advice and tips! Indeed, I have used the UNO with great pleasure for a long time, but I guess it is indeed time to start using something more advanced.
I think we agree that there is a good chance that the bus wiring determines the maximum speed. Unfortunately, this particular setup does not allow the wire length to be shortened, or otherwise improved. With the scope I do see significant under- and overshoot, so next I will try clamping diodes as potential improvement.
The gfx library you suggested seems an interesting one. I need some time to figure out how to tailor it to my particular setup. Once I have it up and running, I will let you know!
Cheers,
Evert-Jan
On Mon, Aug 1, 2022 at 2:05 AM Marc MERLIN @.***> wrote:
First, I would recommend ditching the uno, it can do things, but it's so old and obsolete, while costing more than an ESP32 which is vastly superior in many ways. That being said, I have had SPI displays that didn't work past 10Mhz or so, and it was often due to my wiring, length, cross talk and quality of wires. When I talked to the same display with the same chip on a circuit board with proper copper traces, I was able to use 40 to 80Mhz. Also, I recommend this TFT library, it's faster and has more options: https://www.arduino.cc/reference/en/libraries/gfx-library-for-arduino/
— Reply to this email directly, view it on GitHub https://github.com/adafruit/Adafruit-ST7735-Library/issues/107#issuecomment-1200533993, or unsubscribe https://github.com/notifications/unsubscribe-auth/A2JNRP2LZJ7INDMGFTPGMWLVW4IFZANCNFSM4KMLS3AQ . You are receiving this because you commented.Message ID: @.***>
Hello Marc,
Hmmmm.... the gfx lib that you recommended does not work with HWSPI, even with a lower speed setting. I opened a second issue on the forum ( https://github.com/moononournation/Arduino_GFX/issues/190) but reading the one-line responses I get the the feeling that the author does not know about hardware much, or at least that there is little interest to dive into the issue.
The remarkable thing is that HWSPI does work with the Adafruit library (hacked for lower speed). That tells me it is a software problem, as the hardware seems to be ok.
I tried a few things hacking into the Arduino_GFX library (fixing the SPI speed, issuing a reset), but no luck so far.
Anyway, I think I will stick with the Adafruit library for now! Or perhaps you have another suggestion for me?
Cheers for now,
Evert-Jan
On Sat, Aug 6, 2022 at 1:57 PM Evert-Jan Pol @.***> wrote:
udate2: SWSPI is working now. I made the changes in HelloWorld anew, and this time it worked, and it works reliably. So I suspect I made some mistake in my code yesterday.
HWSPI is still refusing coperation, though... I opened an issue on Github, simply asking how I can set a custom SPI speed from user code. Let's see what the library developer (librarian?) suggests!
On Fri, Aug 5, 2022 at 8:57 PM Evert-Jan Pol @.***> wrote:
update: In a flash of insight (Why didn't I think of this before?) I tried to get the display to work with software SPI.
It still doesn't work, the display stays blank. So I guess I must be doing something very wrong...
I will check the serial clock for both hardware and software SPI.
On Fri, Aug 5, 2022 at 8:47 PM Evert-Jan Pol @.***> wrote:
Hello Marc,
I have tried the gfx library you suggested. After reading the wiki pages for the bus and display invocations, I tried to bring the HelloWorld example to life. The initial code I have now looks as follows:
#include <Arduino_GFX_Library.h>
#define SPI_PIN_DC 7 #define SPI_PIN_CS GFX_NOT_DEFINED
#define GFX_PIN_RST 8 #define GFX_PIN_ROT 0 #define GFX_IPS false #define GFX_WIDTH 128 #define GFX_HEIGHT 160 #define GFX_COL_OFS1 2 #define GFX_ROW_OFS1 1 #define GFX_COL_OFS2 2 #define GFX_ROW_OFS2 1
Arduino_DataBus *bus = new Arduino_HWSPI(SPI_PIN_DC,SPI_PIN_CS);
Arduino_GFX *gfx = new Arduino_ST7735(bus,GFX_PIN_RST,GFX_PIN_ROT,GFX_IPS,
GFX_WIDTH,GFX_HEIGHT,GFX_COL_OFS1,GFX_ROW_OFS1,GFX_COL_OFS2,GFX_ROW_OFS2);
The defines are as suggested by the wiki pages. (My display is a 7735 greentab.)
Changing the SPI speed is the same headache as with the AdaFruit library: it is all built-in, the speed cannot be changed from user code. So, I tried to hack it, similar to the AdaFruit case.
I have tried a few things, but nothing works: the screen stays stubbornly blank. Tomorrow, I will hook up my scope, to see what serial clock is present (if any).
Cheers for now,
EJ
On Thu, Aug 4, 2022 at 7:09 PM Evert-Jan Pol @.***> wrote:
Hello Marc,
Many thanks for your advice and tips! Indeed, I have used the UNO with great pleasure for a long time, but I guess it is indeed time to start using something more advanced.
I think we agree that there is a good chance that the bus wiring determines the maximum speed. Unfortunately, this particular setup does not allow the wire length to be shortened, or otherwise improved. With the scope I do see significant under- and overshoot, so next I will try clamping diodes as potential improvement.
The gfx library you suggested seems an interesting one. I need some time to figure out how to tailor it to my particular setup. Once I have it up and running, I will let you know!
Cheers,
Evert-Jan
On Mon, Aug 1, 2022 at 2:05 AM Marc MERLIN @.***> wrote:
First, I would recommend ditching the uno, it can do things, but it's so old and obsolete, while costing more than an ESP32 which is vastly superior in many ways. That being said, I have had SPI displays that didn't work past 10Mhz or so, and it was often due to my wiring, length, cross talk and quality of wires. When I talked to the same display with the same chip on a circuit board with proper copper traces, I was able to use 40 to 80Mhz. Also, I recommend this TFT library, it's faster and has more options: https://www.arduino.cc/reference/en/libraries/gfx-library-for-arduino/
— Reply to this email directly, view it on GitHub https://github.com/adafruit/Adafruit-ST7735-Library/issues/107#issuecomment-1200533993, or unsubscribe https://github.com/notifications/unsubscribe-auth/A2JNRP2LZJ7INDMGFTPGMWLVW4IFZANCNFSM4KMLS3AQ . You are receiving this because you commented.Message ID: @.***>
thanks for trying. HWSPI can be tricky, it either works or doesn't. The only advice I have for you is wiring. I had issues with mine not working because of too many wires that were too long, causing cross talk and failures. The same code that didn't work with the same ESP32 and same screen, worked when I used a PCB where everything had nice copper traces instead of my flimsy wires.