Black Pill with adafruit ST7789

[fpiSTM]

The 1.9.0 kernel is very fine with this type of hardware arrangement, but the 2.0.0 kernel has its own ...

@TFTLCDCyg there is no change on usage. Only new way to access ALTx pin in the peripheral pins, that's all.

I've bought the same TFT 2 inch and received it 1hour ago. I've tested with a Nucleo F411RE using the graphics tests example and all works as expected.
I've also testing with a STM32F401CE board:


and it works as expected:

PybLiteST7789.png (56.78 KiB) Viewed 4519 times

[fpiSTM]

Just for the fun, I've build using the Black Pill F411CE target and tun it on a Nucleo F411RE.
I've just change the HSE_VALUE and change the clock config to use the HSE bypass of the Nucleo F411RE.
And it works fine. So the variant has no issue.
My guess is that the hardware has an issue. Is it really a Weact one ? It seems they are a lot of counterfeits:
https://github.com/WeActTC/MiniSTM32F4x1#important-note

Or the board is damaged. Check each used pin as a GPIO.

And please try with default Adafruit example first.

[ag123]

nice board

[heretop]

[s]oh i noted something else about STM core, pin naming convention is PA_xx not PAxx. if you use PAxx [/s], <del chances are that all those pin evaluates to *zero* that would cause that Adafruit lcd library to treat all those pins as *non-existent* as the code is
https://github.com/adafruit/Adafruit-GF ... T.cpp#L641

Code: Select all

if (_rst >= 0) {

i'm actually in favor of the 'structured' port - pin approach, that makes it possible for those 'fast pin io' macros to be more concisely defined and possibly faster / more optimized. however, that isn't a priority if at all. there is some merits of the pinmap approach as well.

[s]in 'conclusion' use PA_xx for STM core not PAxx, [/s] <del, and/or add that lcd pin reset codes before calling tft.begin() or tft.init().
stm32 spi can goto i think 20 mhz or higher, not every 'external' peripheral can catch up with those speeds, the lcd pin reset is needed so that the lcd would attempt to 'sync' the baud rate with stm32's higher spi speeds. i think stm32 spi can goto 50mhz? that's plenty fast for a serial pin pushing.

edit:
oops , i found the PAxx to 'arduino pins' 'mapping' in the variant files.
https://github.com/stm32duino/Arduino_C ... L_F411CE.h

nevertheless still check that PAxx is after all successfully mapped, as if PAxx is not mapped and you thought it is, it may just evaluate to *zero*. then this same problem still happens

I have the 2.0.0 working with changing all PAXX to PA_XX !!!!

Code: Select all

#define TFT_CS    PA_4//8
#define TFT_DC    PB_1//9
#define TFT_RST   PB_0//10
#define TFT_MOSI    PA_7//PB15//11
#define TFT_SCLK    PA_5//PB13//13

SPIClass SPI_1(PA_7, PA_6, PA_5);
//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);

[heretop]

Just for the fun, I've build using the Black Pill F411CE target and tun it on a Nucleo F411RE.
I've just change the HSE_VALUE and change the clock config to use the HSE bypass of the Nucleo F411RE.
And it works fine. So the variant has no issue.
My guess is that the hardware has an issue. Is it really a Weact one ? It seems they are a lot of counterfeits:
https://github.com/WeActTC/MiniSTM32F4x1#important-note

Or the board is damaged. Check each used pin as a GPIO.

And please try with default Adafruit example first.

My board is bought from weact official aliexpress shop. Since my board work with both 1.9.0 and changing PAXX to PA_XX, I would not say it is a hardware problem.

[ag123]

I have the 2.0.0 working with changing all PAXX to PA_XX !!!!

Code: Select all

#define TFT_CS    PA_4//8
#define TFT_DC    PB_1//9
#define TFT_RST   PB_0//10
#define TFT_MOSI    PA_7//PB15//11
#define TFT_SCLK    PA_5//PB13//13

SPIClass SPI_1(PA_7, PA_6, PA_5);
//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);

be careful though PA_XX isn't 'arduino' pins, i.e. they are actually not pin mapped, those are like what i mentioned specific encoding to reference gpio pins by port + pin reference.

i mean, these are the PA_XX encoded pin name and port name references
https://github.com/stm32duino/Arduino_C ... PinNames.h
https://github.com/stm32duino/Arduino_C ... ortNames.h

and these are the 'real arduino' pins, they are in the 'old' 'PAXX' convention.
https://github.com/stm32duino/Arduino_C ... L_F411CE.h

[fpiSTM]

I have the 2.0.0 working with changing all PAXX to PA_XX !!!!

Code: Select all

#define TFT_CS    PA_4//8
#define TFT_DC    PB_1//9
#define TFT_RST   PB_0//10
#define TFT_MOSI    PA_7//PB15//11
#define TFT_SCLK    PA_5//PB13//13

SPIClass SPI_1(PA_7, PA_6, PA_5);
//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);

OK let analyze PinName (PY_n) and pin number (PYn):

Code: Select all

PA_4  = (PortA << 4) + 0x04,

with PortA equal to 0. So PA_0 is 4 and PA4 is 4 because in case of this variant pin number are defined ordered so those value are the same.

PB_0 = (PortB << 4) + 0x00,

with PortB equal to 1. So PB_0 is equal to 16. PB0 is defined a 16, etc.
But PB11 is not defined as it is not available. In this case PB12 is 27 while PB_12 is 28...

It seems you try to change or redefine the SPI instance. By default 1 SPI class is instantiated named SPI and uses thoses pins:
https://github.com/stm32duino/Arduino_C ... #L104-L112

Code: Select all

#ifndef PIN_SPI_MOSI
  #define PIN_SPI_MOSI          PA7
#endif
#ifndef PIN_SPI_MISO
  #define PIN_SPI_MISO          PA6
#endif
#ifndef PIN_SPI_SCK
  #define PIN_SPI_SCK           PA5
#endif

So you do this

Code: Select all

SPIClass SPI_1(PA_7, PA_6, PA_5);

This is useless as SPI instance already exists using those pins. It works because pin name as the same value than the pin number.
It seems you try to bring complexity where there is no need.
As stated before simply use the default example and it works with the default SPI instance.

Code: Select all

#define TFT_CS    PA4
#define TFT_DC    PB1
#define TFT_RST   PB0
#define TFT_MOSI    PA7
#define TFT_SCLK    PA5

Adafruit_ST7789 tft = Adafruit_ST7789(TFT_CS, TFT_DC, TFT_RST);
[/quote]

[heretop]

This is useless as SPI instance already exists using those pins. It works because pin name as the same value than the pin number.
It seems you try to bring complexity where there is no need.
As stated before simply use the default example and it works with the default SPI instance.

Code: Select all

#define TFT_CS    PA4
#define TFT_DC    PB1
#define TFT_RST   PB0
#define TFT_MOSI    PA7
#define TFT_SCLK    PA5

Adafruit_ST7789 tft = Adafruit_ST7789(TFT_CS, TFT_DC, TFT_RST);

I have try the code you stated already multiple times. And it does not work. As I stated previously in this thread, I have try three different ways to call the "Adafruit_ST7789":

Code: Select all

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);

All these three methods does not work with PAXX/PBXX style. And all these three methods work with PA_XX/PB_XX style.

[heretop]

with PortA equal to 0. So PA_0 is 4 and PA4 is 4 because in case of this variant pin number are defined ordered so those value are the same.

PB_0 = (PortB << 4) + 0x00,

with PortB equal to 1. So PB_0 is equal to 16. PB0 is defined a 16, etc.
But PB11 is not defined as it is not available. In this case PB12 is 27 while PB_12 is 28...

Please check this video, it shows the same code work with PA_XX but not PAXX. https://photos.app.goo.gl/VpJFiecqAkeRqM2W6

[fpiSTM]

Please check this video, it shows the same code work with PA_XX but not PAXX. https://photos.app.goo.gl/VpJFiecqAkeRqM2W6

So you have probably an issue with your setup. Wrong core version, change in the core or something else you made during you try/test.
Main issue is that you will probably have further problem later with another library and we will not be able to help... but it's up to you.