I use CubeMx to generate the /Core/Src /Core/Inc and /Drivers folders. Drivers is CMSIS and chip specific headers.
I want to try platform.io on VS Code, but I’m having a problem determining how to set this up.
The one source and one include folder is really handycapping me here!!
If I funnel everything into /src /inc and /lib, I’m going to have a lot of intellesense errors.
I might be able to trick PIO into building the correct things by using a build_dir_filter for SCons, and a additional build flags to add more include folders. But this seems like a lot to get something that should be more obvious.
I could have completely different repos each built, but that’s the worst case. If I change how my RGB led works in my_led.c I really don’t want to change it in the other repo too. And after some bad experiences I basically refuse to consider sob-modules again.
This is all in addition to the issues with moving the CubeMX / Core folders and files. I can write a python script to copy the correct files per multi-env build, or use stm32pio which has it’s own issues.
I considered my actual code in a library as a repo… But that would really screw up the flow of building if I need to commit and push first then build the project, not to mention how clueless intellesense would be if I reference something in code to a project local file.
I feel like I must be missing something. I looked at the multi-env options and can only see possibly effective work-arounds.
What I don’t understand is how this is so obvious in almost every other IDE in existence. You have a project file and it stores all the details about that build, seems like PIO is 95% of the way there, then made a strange choice not to allow an array of folders to build from.
In the platformio.ini, you can declare multiple environments ([env:xyz]), each of which can have their own build_flags (so you can have different includes for different envs), and they can have individual src_filter expressions so different envs only use certain code files or folders to build their firmware.
Is framework = stm32cube not usable for you? See example projects. When using that, PlatformIO will already auto-include the correct STM32Cube base (HAL etc.) for your chip. As you can see in the example project, the needed files for a firmware is then absolutely minimal.
I know you! You’re the very smart guy that recommended PIO handle the multiple ram sections properly. We are very much in agreement there!
Multiple env build flags don’t allow for adding different sources. It looks like I can add of different includes, but sources are going to be limited to the global source directory. As you got right thing, I suppose I could add too much and then limit sources with filter entries.
But tell me this isn’t super backwards!? Why do I need to add files and then filter out the wrong ones? What is intellesense going to show when I have multiple overlapping defines?
I think a workaround would be that you can seemingly have lots of libraries. So I’m not sure what would stop me from putting my universal application code in SRC, and then including everything unique to this micro as a library? Again, this sure seems like intellisense or analysis is going to not understand what I’m doing.
There are two reasons I don’t want frame=stm32Cube. One, I want everything to build the project in the project. I don’t really want to rely on PIO for anything but IDE right now. Partly a “will it still build in 10 years?” and partly because it’s just a couple folders, I don’t need a special system.
I want to solve this issue because it’ll come up even if I figured out the HAL example.
I really just want a tight IDE and to handle the code/packages on my own. But this one source folder is such a crazy decision to me.
I have found no great solution here. Just a work-around as @maxgerhardt eluded to.
As I understand it, the ini’s [env: xxx] can list my includes as -I<my_header_includes> and with build_src_filter = -<my_src_excludes> I can filter the C and S files around. Which seems like it could work for two different micros, each given it’s own [env] in the ini. It’s not any stretch of the term “clean”.
I would think a -I and src_filter = +/- would be commonized down to a common style since they’re doing something effectively similar.
It’s not like the .py scripts aren’t already adding more folders to the src path.
… Seems like there are technical reasons for the way it is. And I’m suggesting practical reasons to make it easier on the user.