Black Pill with adafruit ST7789

[heretop]

Hi @heretop
I had an Adafruit shield with ST7735 so I was able to test the Adafruit library.
And it works fine with the graphic test example.
Did you try with the default sketch example from the library?

I tried the method mentioned in other thread

Try removing the 2.0.0 kernel first and then installing the 1.9.0 kernel, with this reference:

https://github.com/stm32duino/BoardMana ... index.json

Revert the stm32duino back to 1.9.0, the display is working now!!!


With all the different method to call the library, it works without problem

Code: Select all

#define TFT_CS    PA4//8
#define TFT_DC    PB1//9
#define TFT_RST   PB0//10
#define TFT_MOSI    PA7//PB15//11
#define TFT_SCLK    PA5//PB13//13

//SPIClass SPI_1(PA7, PA6, PA5);
//SPIClass SPI_2(PB15, PB14, PB13);

//Adafruit_ST7789 tft = Adafruit_ST7789(TFT_CS, TFT_DC, TFT_RST);
//Adafruit_ST7789 tft = Adafruit_ST7789(&SPI_1, TFT_CS, TFT_DC, TFT_RST);
Adafruit_ST7789 tft = Adafruit_ST7789(TFT_CS, TFT_DC, TFT_MOSI, TFT_SCLK, TFT_RST);

May I know will the developer look into the problem of 2.0.0 that cause this problem? I do want to able to use the most updated version.

[fpiSTM]

May I know will the developer look into the problem of 2.0.0 that cause this problem? I do want to able to use the most updated version.

I'm the developer and I have tested with the updated version.

[heretop]

May I know will the developer look into the problem of 2.0.0 that cause this problem? I do want to able to use the most updated version.

I'm the developer and I have tested with the updated version.

Are you able to reproduce the same problem under 2.0.0?

[fpiSTM]

Are you able to reproduce the same problem under 2.0.0?

As said I have no problem using the STM32 core 2.0.0 as stated before.

[heretop]

Are you able to reproduce the same problem under 2.0.0?

As said I have no problem using the STM32 core 2.0.0 as stated before.

As stated in another thread, there are at least several people facing the same issue. So I think it is not just me. Moreover, I bought a cheap logic analyzer which I haven't received yet. I probably will show the output under 2.0.0 in the future.

[fpiSTM]

Well, I've tested with a Nucleo F411RE as I don't have the black pill F411CE but quite the same.
The main differences btw the 2 versions of the core are how the variants are defined. No link with SPI, I guess.
As you stated I saw several user claim about issue with the Weact F411CE, the only thing I can tell is that Weact proposed several version of this board: V1, V2,.. So maybe there is an issue in the variant but looking on it I didn't see anything wrong.
Only one issue has been raised for it since the 2.0.0 release:
https://github.com/stm32duino/Arduino_C ... ssues/1369

Is your board has an HSE ?
I ask this as it seems the HSE value is not consistent on those board, see: https://github.com/stm32duino/Arduino_C ... /pull/1281

By default this variant assumes that the HSE is 25MHz

[ag123]

i think if there are other app components check things like memory and the organization of the classes etc.
for bluepill stm32f103c8 20k sram, i ran out of sram pretty often, especially when there are other modules used.
this is hard to catch but the symptom is often a hard freeze or more common, corruption during run.

then 'long' back i remembered once that for an unknown reason on stm32f4xx certain fpu instruction calls result in a hardfault if the fpu initialization (enable fpu) code is placed in the same file / class as the computation code. i'm not too sure if it may be due to some sync issues etc.
hardfaults is one thing to check for, i'm not too sure how to check that, maybe in debug etc.
running some things in debug may help locate the problem and provide more clues

[heretop]

Well, I've tested with a Nucleo F411RE as I don't have the black pill F411CE but quite the same.
The main differences btw the 2 versions of the core are how the variants are defined. No link with SPI, I guess.
As you stated I saw several user claim about issue with the Weact F411CE, the only thing I can tell is that Weact proposed several version of this board: V1, V2,.. So maybe there is an issue in the variant but looking on it I didn't see anything wrong.
Only one issue has been raised for it since the 2.0.0 release:
https://github.com/stm32duino/Arduino_C ... ssues/1369

Is your board has an HSE ?
I ask this as it seems the HSE value is not consistent on those board, see: https://github.com/stm32duino/Arduino_C ... /pull/1281

By default this variant assumes that the HSE is 25MHz

The issue I stated is this one viewtopic.php?f=7&t=1143. Other people display can work with 1.9.0 but not 2.0.0. It uses ST7735 but it is under same library as ST7789.
For the HSE thing, my board is blackpill f411ce v3.1. The crystal on board is 25MHz one. I have heard HSE before. So I did not set any value by myself. What do you mean by my board has an HSE?

[fpiSTM]

Simply this "is your board has an HSE?". So you answer yes and 25 MHz so this is not the issue.
I have no more clue for your issue. Only debug can help on this as I do not have this board.
The core is "as generic" as possible so as it works with other F411 there is no reason to not work on this one except the variant definition but do not see any issue.

[mrburnette]

Just a note that most Adafruit library users know; Adafruit has completely re-architected all of their display drivers and sensor libraries. Every week, Adafruit hardware device libraries undergo Arduino IDE updates... It reminds me of Windows OS updates in frequency!

A really biggie IMO: the hardware abstraction of SPI and I2C
The Adafruit_GFX library makes reference to the abstractions thusly:

You will also need to install the latest Adafruit BusIO library. Search for "Adafruit BusIO" in the library manager, or install by hand from https://github.com/adafruit/Adafruit_BusIO

I am certain Adafruit does regression testing, but no company can stock the variety of hardware found in the wild. (I would expect they concentrate on hardware they sell.) Re-write of the code base "could" introduce small timing differences or "tighten up" loose specifications in previous code.

Programmers can protect themselves from library skew by encapsulating a copy the selected (working) library early on in the coding and nest that code within the Arduino sketch sub-directory. Essentially:

Code: Select all

#include < library.h > 

is formatted as

#include "./library.h"

... the library ".h" and ".cpp" files will automatically become ArduinoIDE tabs. Some libraries require a particular "relative" directory structure, so take note... this may mean editing library code that has #include statements.

The very positive side-effect of the minor effort is that you can Zip-up the Arduino Sketch directory and have a complete snapshot of your program.