Black Pill with adafruit ST7789

[TFTLCDCyg]

I did a little exercise with the Nucleo F767ZI board, I copied all the pin definitions from the STM 1.9.0 core (PeripheralPins.c) and substituted it in the pin definitions from the STM 2.0.0 core (PeripheralPins.c), the NHD screen FT813 of 3.5 " now is answered without problems en el kernel 2.0.0 !!!!

May I confirm that you just overwrite the 2.0.0 core (PeripheralPins.c) with STM 1.9.0 core (PeripheralPins.c)? I did that but I got ...

You just have to copy the pin definitions inside the file, inside this definition

#if! defined (CUSTOM_PERIPHERAL_PINS)
#include "Arduino.h"
#include "PeripheralPins.h"

/ * =====
* Notes:
* - The pins mentioned Px_y_ALTz are alternative possibilities which use other
* HW peripheral instances. You can use them the same way as any other "normal"
* pin (i.e. analogWrite (PA7_ALT1, 128);).
*
* - Commented lines are alternative possibilities which are not used per default.
* If you change them, you will have to know what you do
* =====
* /

// here is the field of replacement of pinout

#endif / *! CUSTOM_PERIPHERAL_PINS * /

Don't overwrite the whole file.

With this I confirm my initial suspicion that the new 2.0.0 kernel has a different pin mapping than the 1.9.0 kernel.

[heretop]

You just have to copy the pin definitions inside the file, inside this definition

Here is the difference between 1.9.0 and 2.0.0 PeripheralPins.c (left is 1.9.0, right is 2.0.0). May I know which line to copy over? Thanks a lot!

[TFTLCDCyg]

Sorry for not specifying, for the rush to want to check the pinout on the nucleo-F767ZI.

The PeripheralPins.c file is located inside the variant definitions folder, for the bluepill it will be inside the folder

Code: Select all

... stm32 \ 2.0.0 \ variants \ STM32F1xx

I have just found the ST7735 and the bluepill F103C8, let me check which variant looks for the core and I run the test again

This is the path for the PeripheralPins.c file :

Code: Select all

...stm32\2.0.0\variants\STM32F1xx\F103C8T_F103CB(T-U)

https://www.mediafire.com/view/krkdish9wcadkni

[heretop]

Sorry for not specifying, for the rush to want to check the pinout on the nucleo-F767ZI.

The PeripheralPins.c file is located inside the variant definitions folder, for the bluepill it will be inside the folder

Code: Select all

... stm32 \ 2.0.0 \ variants \ STM32F1xx

I have just found the ST7735 and the bluepill F103C8, let me check which variant looks for the core and I run the test again

This is the path for the PeripheralPins.c file :

Code: Select all

...stm32\2.0.0\variants\STM32F1xx\F103C8T_F103CB(T-U)

https://www.mediafire.com/view/krkdish9wcadkni

Thanks for the explanation. I overwrite the content in

Code: Select all

...\stm32\2.0.0\variants\STM32F4xx\F411C(C-E)(U-Y)\PeripheralPins_BLACKPILL_F411CE.c

with content in

Code: Select all

Arduino_Core_STM32-1.9.0\variants\Generic_F411Cx\PeripheralPins.c

However, my display still not work. May I check whether my setup correct? Thanks a lot!

Here is the board.txt for Arduino_Core_STM32-1.9.0

Code: Select all

# BlackPill F411CE
# https://github.com/mcauser/WEACT_F411CEU6
GenF4.menu.pnum.BLACKPILL_F411CE=BlackPill F411CE
GenF4.menu.pnum.BLACKPILL_F411CE.upload.maximum_size=524288
GenF4.menu.pnum.BLACKPILL_F411CE.upload.maximum_data_size=131072
GenF4.menu.pnum.BLACKPILL_F411CE.build.board=BLACKPILL_F411CE
GenF4.menu.pnum.BLACKPILL_F411CE.build.product_line=STM32F411xE
GenF4.menu.pnum.BLACKPILL_F411CE.build.variant=Generic_F411Cx

Here is the board.txt for stm32\2.0.0

Code: Select all

# BlackPill F411CE
# https://github.com/mcauser/WEACT_F411CEU6
GenF4.menu.pnum.BLACKPILL_F411CE=BlackPill F411CE
GenF4.menu.pnum.BLACKPILL_F411CE.upload.maximum_size=524288
GenF4.menu.pnum.BLACKPILL_F411CE.upload.maximum_data_size=131072
GenF4.menu.pnum.BLACKPILL_F411CE.build.board=BLACKPILL_F411CE
GenF4.menu.pnum.BLACKPILL_F411CE.build.product_line=STM32F411xE
GenF4.menu.pnum.BLACKPILL_F411CE.build.variant=STM32F4xx/F411C(C-E)(U-Y)
GenF4.menu.pnum.BLACKPILL_F411CE.build.variant_h=variant_{build.board}.h
GenF4.menu.pnum.BLACKPILL_F411CE.build.peripheral_pins=-DCUSTOM_PERIPHERAL_PINS

[heretop]

I got the debug log for 1.9.0 in here https://gist.github.com/ht93/c5c5f12034 ... 283cea5093, and I compare the debug log with the previous 2.0.0 debug log https://gist.github.com/ht93/93f4ed2667 ... 8e053403e3. The first big difference I found between two debug log is here:
left is 2.0.0 and right is 1.9.0. So the 2.0.0 does not go into the if at https://github.com/adafruit/Adafruit-GF ... T.cpp#L533

Another big difference at later, 2.0.0 does not go into the if at https://github.com/adafruit/Adafruit-GF ... T.cpp#L641

[ag123]

try copying out the lcd pin reset code and call it before tft.begin() or tft.init(), omit the if( _rst >= 0) statement.

https://github.com/adafruit/Adafruit-GF ... T.cpp#L641

Code: Select all

  if (_rst >= 0) {
    // Toggle _rst low to reset
    pinMode(_rst, OUTPUT);
    digitalWrite(_rst, HIGH);
    delay(100);
    digitalWrite(_rst, LOW);
    delay(100);
    digitalWrite(_rst, HIGH);
    delay(200);
  }

i think it'd fix the problem.

this problem can happen if the pin numbers are > 127 as _rst is a int8_t.
a trouble is pin numbers such as PAXX are structured encoded codes such as port + pin combinations and not straight forward sequential pin numbers.
this encoded port / pin combination is necessary for *fast pin io*, i.e. there are macros for fast toggling of gpio pins and it depends on the expansion of that encoded port / pin combination to achieve it.

strictly speaking this is a 'bug' in the lcd library, checking for pins should not be simply based on encoded pin numbers, or that it'd need to be a specific pin number not used everywhere. the problem can be alleviated by using int16_t for pin numbers, even then codes like if( _rst > 0) is too broad it should probably be something like if( _rst != 0xffff) { do something } the undefined pin identifier has to be a specific code not used in all implementations.

[fpiSTM]

this problem can happen if the pin numbers are > 127 as _rst is a int8_t.
a trouble is pin numbers such as PAXX are structured encoded codes such as port + pin combinations and not straight forward sequential pin numbers.

This is not exact, PAXX is not a structured encoded code. It is is a number and it is always an uint8_t. Is is the pin number used to find the PinName (PA_xx) which is the structure encoded to get the GPIO port / GPIO Pin.

About the Peripheral Pin file.The generic one is automatically generated, for the blackpill it has been customized based on the generated one. Only 4 pins have been commented.
I've compared the file with the 1.9.0 and they are the same except the PinName suffixed with _ALTx but they are not used as you do not use the pin number with ALTx. This file is only the "database" to get Peripheral info of a pin. So for the SPI one there is no issue.
The only change I can see is that with core 2.0.0 the code size is higher as more pin are defined in those arrays. So maybe a memory corruption.
You can compare the build result log you will see the flash/RAM consumption.

You can try to simply redefined the SPI arrays at sketch level to see if this change something.
https://github.com/stm32duino/wiki/wiki ... nmap-array

[ag123]

[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

[fpiSTM]

No use the pin number to library compatibility. Pin name is not arduino API compatible.

[TFTLCDCyg]

There is no way I still do not get an answer with the duo ST7735+F103C8, I have already tried with very different screens connected to SPI1 ... please fpiSTM, will you have an example to guide us to know how to use the spi bus with a screen that can be controlled by GFX-style adafruit libraries + TFT.

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

Generic F411CEU on the way to continue testing