0

I am trying Visual Studio's new feature of importing an STM32CubeIDE Project (making it a CMake Project) and have a problem: Visual Studio Import Feature only works with single-core boards, and unfortunately, I only have dual-core boards; Anyways... it asks for the .cproject file, but we kinda have 2 of them - one for each core;

VS allows you to import only 1 .cproject at a time, which means you'd have to do the importing process 2x, but then VS thinks these are 2 separate projects and makes no linking, whatsoever.

In the CubeIDE we build the project and we also get to choose the debug configuration, thereby I choose, for example, another port for CM4-debugging, connect under reset, that I want CM7 to load the code for CM4, and so on.

We then get this <project_name> Debug.launch file inside each core folder.

I'd would like to replicate that (launching of one core using the other) using CMake.

Does anyone have an idea how I could accomplish that?

I am already working on the other configurations. For example, importing the 2 .cprojects separately, and once we get the CMakeLists.txt and the /cmake, I create a root CMakeLists.txt that only sets up the project(instead of already "adding an st-target" with the name of the project, as the generated ones do), then to go into the CM4 and CM7 folders and, by using the rest code of the generated CMakeLists.txt files, create the target, this time with 2 separate names reflecting the CM7 and CM4 cores.

I'll also modify the generated CMake modules (gcc-arm-none-eabi.cmake and st-project.cmake) to perform a check (if CM4 or CM7 is passed) and then modify the files/directory/names accordingly.

There should be something like creating the CM4_Target as a library, and the CM7 one as an executable; then, statically link the CM4_Target (lib) to the CM7_Target (exe) and then run/execute it.

See the picture below to have an idea of what I am trying to accomplish ahah. Also note that those .c files will most probably be .cpp files (I intend to develop in C++).

project_tree

I also asked the ST Community and also commented on Microsoft's Post(more than a week ago, actually), but still waiting for a response :/

Thank you very much.

Kelv
  • 43
  • 1
  • 7
  • I would say: forget about VS is you work with embedded targets. It only works on simple led-flash apps but not when you try to do something more sophisticated. Stick to Eclipse-based IDEs as they work. If you use VS you will spend 90% of your time trying to work around its limitations, bugs and misconceptions. – 0___________ Mar 09 '23 at 12:36
  • Thank you for those heads-up. Yeah, that's what I noticed. They shouldn't even advertise that. I mean, the idea is nice - converting the Cube project into a CMake Project - but if that doesn't work, then why bother? Anyway... I just thought I could have everything in one place, etc. haha, but that ain't happening yet. – Kelv Mar 09 '23 at 12:49
  • My boss likes VS but he uses it only for editing - but compiles and debugs using the proper embedded IDE. I do not bother - Eclipse editor is working the same fine as VS but I do not have to waste my time patching the build system. On top of that eclipse has plenty of handy Cortex-M and STM plugins saving you plenty time (for example hard fault resolver reading the registers and stack for you and displaying it in the convenient form - you can even jump to the code which is at the address shown by the registers. – 0___________ Mar 09 '23 at 13:00
  • I see! But I'm kinda sad; I wish I could do some Embedded stuff in a C+++CMake way, even if doing it from the CubeIDE (hence, taking advantage of Eclipse/STM stuff); but that's rubbish; CubeIDE doesn't even react when you choose C++ as the language upon project creation; I don't even understand why they offer that haha - they create the main's.c etc. the same way. Nothing changes. – Kelv Mar 09 '23 at 17:07
  • Basically it cant change. What would you expect from the C++ project? HAL is written C style, CMSIS too. Only your code can be C++. So the process creation will be 100% the same unless HAL & CMSIS are object oriented – 0___________ Mar 09 '23 at 17:36
  • HUH, I see your point. Good point haha! Well, then I guess I should just accept that programming STM32 MCUs is C and that's it haha - all the workarounds may not be worth it the time. – Kelv Mar 09 '23 at 17:50
  • No - your code can be C++ or you will need to rewrite HAL library to be OO – 0___________ Mar 09 '23 at 17:52

0 Answers0