is there any way to force PlatformIO to use the latest Arduino_Core_STM32 as the core of ststm32 platform, as you can see so as to being able to compile TFT_eSPI library for STM32F103RC the core STM32 lib should be compile by the latest Arduino_Core_STM32 but when I define (genericSTM32F103RC) for the board option, it seems the PIO uses another core or the olde one of STM32 core, so it doesn’t compile, but when I set (bluepill_f103c6) it uses the right core but it’s not my board, what shuld I do ?
is the any way to add it manually to the project ?
the errors are because of using maple core instead of STM32Duino which is used in tfT_eSPI library, if I change the board to bluepill_f103c6, it uses STM32Duino core to compile the code and it compiles, but my prefered board is genericSTM32F103RC, so as STM32Duino has support of STM32F103RC how to set board to STM32F103RC without switching the STM32 core to maple ?!!
Note though that Generic F103R(6-8-B-C-D-E-F-G) support will be as of the yet to be released v1.9.0 of the STM32Duino, hence why PlatformIO doesn’t have a separate board profile for it. And depending on what support is present in v1.8.0 for it the F103RC, the above parameter may result in a broken compile.
Hm… that does smell like a bug… as it indeed should support the F103RC, and genericSTM32F103RC is a valid board target. I’ll have dig around and see if I can see what’s causing that.
So, I was able to reproduce this on my end, and then realised once I saw the error messages that the compiler couldn’t find the variant configuration file because the wrong path was being used when instructed to use the stm32duino core.
Use the following two overrides to use the stm32duino core with the genericSTM32F103RC board.
Given how PlatformIO seems to treat the maple core as a special case, and does remapping of variants based on the board name, I feel that the need for the variant override is a bug, have raised an issue here for discussion/review.