Black Pill with adafruit ST7789

[heretop]

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.

I got the blackpill (also my first STM32 board) two months ago. I followed the guideline in the STM32duino github guideline used the 2.0.0 version core. I haven't heard about deal with different core version until I saw it in this forum. I got the problem with display at the beginning that I test my code (with all three methods to call the adafruit library), that is before I did anything related to different core version.

[fpiSTM]

I talk about core version because you made some tries to switch from 2.0.0 to 1.9.0.
STM32 core has several version (release) like any other software.

[ag123]

there is one possibility which is that some platforms / ide did not parse the include files and dependencies properly, that can cause definitions to be missed out and those PAXX may evaluate to zero. one way out of that is to #include the header file for your board.
e.g.

Code: Select all

#include <variant_BLACKPILL_F411CE.h>

or even

Code: Select all

#include <STM32F4xx/F411C(C-E)(U-Y)/variant_BLACKPILL_F411CE.h>

i'm not sure which one works
in linux as i used makefiles rather than 'proper' arduino ide, my makefiles stumble with the brackets, i can't reference them.
so some of the resorts i used include copying the variant files and placing them in the sketch directory and add the include that works

i think stm32 is more complex than the original uno like setups as the stm32 portfolio is diverse. this cause some challenges that the 'simpler' cores don't encounter. build tools like arduino-cli is pretty much 'bleeding edge' i.e. they are actually actively being developed while we are already using them, this isn't even 'beta', or rather it is called 'beta' in which some features are possibly 'missing'. e.g. in arduino ide 2.0, the field definition lookups fail because a file needed by clangd is not generated if the build ends with some errors or warnings (e.g. missing includes). that kind of remains 'unresolved' for now.

there are 'better' build tools e.g. gradle,but i'd guess it isn't used partly as arduino et.al. may have concerns about licensing or ide issues etc.
makefiles are 'very fluid' in linux but in windows, some consider it 'non portable', but i think there are things like cygwin etc that caters to those things like make etc, short of running WSL.

[heretop]

I talk about core version because you made some tries to switch from 2.0.0 to 1.9.0.
STM32 core has several version (release) like any other software.

Yeah, I know that. However, I only switched between 2.0.0 and 1.9.0 ten days after I posted this thread. When I post this thread, I only have used 2.0.0 and my code is same as the one you posted today, and it does not work.

[heretop]

there is one possibility which is that some platforms / ide did not parse the include files and dependencies properly, that can cause definitions to be missed out and those PAXX may evaluate to zero. one way out of that is to #include the header file for your board.
e.g.

Code: Select all

#include <variant_BLACKPILL_F411CE.h>

or even

Code: Select all

#include <STM32F4xx/F411C(C-E)(U-Y)/variant_BLACKPILL_F411CE.h>

I can import this

Code: Select all

#include <variant_BLACKPILL_F411CE.h>

display does not work with this and PAXX.

I cannot import this

Code: Select all

#include <STM32F4xx/F411C(C-E)(U-Y)/variant_BLACKPILL_F411CE.h>

[ag123]

to troubleshoot this, you would need to try to figure out what is 'not included'.
this could include trying things like

Code: Select all

Serial.print('PA5 :');
Serial.println(PA5);
Serial.print('PA_5 :');
Serial.println(PA_5);

etc. if PA05 evaluates to zero then some includes is 'missing', e.g. that header file.
if for some reason PA_XX works, you could live with that for the time being while this remains a 'mystery'. until the next time it breaks.

other possibilities could involve the use of 'fast pin io' macros say in the adafruit spi libraries. those macros 'bypass' all the usual 'arduino'ish pin definitions, and using PAXX instead of PA_XX may evaluate to the 'wrong' pins. But i'm not sure really, that'd take digging into adafruit lcd libraries and 'debugging' them as first person. this problem is likely going to be 'platform specific' i.e. not all setups will show the same problem, some could compile ok no issues. then some with issues.

but other than stumbling with this 'missing' definition include problem, one thing to note is those lcd apparently requires doing the pin lcd reset, so if all else being the same and you are in a 'rush' for a solution, one way is to make some codes to do that 'pin lcd reset', to toggle the lcd pin reset before calling the lcd init() or lcd.begin() codes. once that is done, normally things 'should' work again.

[fpiSTM]

Print both values is a good idea.
Could you also share a full log of the build, please? Think to enable all the verbose in the preference.

[mrburnette]

there is one possibility which is that some platforms / ide did not parse the include files and dependencies properly, that can cause definitions to be missed out and those PAXX may evaluate to zero. one way out of that is to #include the header file for your board.
...

OK, maybe I'm wrong, but the IDE does not attempt to parse such items. The "automatic prototyping" functionality does parse in a sense and all .INO files are concatenated, but all of this is handed off to the GCC preprocessor. https://gcc.gnu.org/onlinedocs/gcc/Prep ... tions.html

The GUI process is the same as the CLI process as far as file modifications...
https://arduino.github.io/arduino-cli/l ... d-process/

[ag123]

i'm not able to confirm if the problem is after all related to those 'fast pin io' macros or that it is simply due to possible missing includes not parsed, but i noted that adafruit's lcd libraries do check for the presence of 'fast pin io' macros and use them if the macros test true.
in terms of 'platforms' i think there are quite a group of platform io users, then some use vs code, some eclipse, some eclipse sloeber, some arduino-cli, some arduino 1.8 gui, some arduino 2.0 gui, them myself makefile linux. we'd never know which 'platform' is having a problem

on a side note, i still have codes which reference pins by PAXX e.g. in my 'adafruit ili9341 lcd lib fork', the last time i tried in 2.0
https://github.com/ag88/Adafruit_ILI934 ... st.ino#L72
i didn't seem to encounter a problem. but of note that i made my own version of 'fast pin io' that uses bit banding
https://github.com/ag88/Adafruit_ILI934 ... TM.cpp#L71
i need to re-test this again as there have been quite a few new updates in the 2.0 core

strictly speaking i'm somewhat in favor of doing away with the 'old' arduino pin maps and simply use encoded port - pin definitions.
after all, most 'users' would reference the pins by names such as PAXX or PA_XX, it does not matter to them what that number is.

the benefit here is that a pin can be encoded as

Code: Select all

uint8_t pin = (port & 0x0f) << 4 | (pin & 0x0f)

what is unknown is if such a scheme can be applied across the stm32 lines

another trouble is adafruit's lcd library has codes like
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);
  }

and the pin is declared int8_t which means if we set the high bit in the byte, this code is just going to be skipped

[fpiSTM]

i'm not able to confirm if the problem is after all related to those 'fast pin io' macros or that it is simply due to possible missing includes not parsed, but i noted that adafruit's lcd libraries do check for the presence of 'fast pin io' macros and use them if the macros test true.

strictly speaking i'm somewhat in favor of doing away with the 'old' arduino pin maps and simply use encoded port - pin definitions.
after all, most 'users' would reference the pins by names such as PAXX or PA_XX, it does not matter to them what that number is.

the benefit here is that a pin can be encoded as

Code: Select all

uint8_t pin = (port & 0x0f) << 4 | pin & 0x0f

what is unknown is if such a scheme can be applied across the stm32 lines

another trouble is adafruit's lcd library has codes like
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);
  }

and the pin is declared int8_t which means if we set the high bit in the byte, this code is just going to be skipped

My guess is you bring some confusion.
User have to use pin number (Dx, x or PAx) not the PinName type. Definitely they have not the same goal nor the same meaning.
I agree in this case several pin numbers and PinNames have the same value but it is only a coincidence.

I also agree that _rst pin which is defined as int_8 is risky as the pin number can be higher than 128. But in our case:

Code: Select all

#define NUM_DIGITAL_PINS        36

So no issue there.

About include issue, if the variant_BLACKPILL_F411CE.h was not included properly I could says nothing would compile.
My feeling is that the environment is not the one OP says, probably a mistake during their investigation/installation but I already saw that many times and finally issue always comes from wrong environment (files modified in the core or library, not the correct version installed or even wrong IDE when user have several one installed...) anyway as usual we have to guess what goes wrong based on user input not always aligned/understood/...

Finally, the core is also not free bug so I always try to understand what goes wrong just in case. But in this particular topic I don't think the core is faulty.