"Create empty project" does not provide CMSIS files

[mark03]

I just downloaded the prerelease (3.something) of the official VS Code extension and created a new project.  By and large, I like it.  It's especially nice that there is an "empty project" option for those that don't want to use HAL or LL functions.  But I was surprised that this does *not* provide the standard CMSIS header files (stm32l4xx.h and so on, for my project on a Nucleo L476).  In fact, searching my entire hard disk, the CMSIS headers were never installed with the extension.  Was there another software bundle I should have downloaded?  I don't see anything in the list.

Besides the basic headers, it would be great if there were also a check-box to say if you want to use the DSP library (or other CMSIS libraries), then automatically configure the cmake project accordingly.  But for sure the basic header files should be included.  I mean, I guess you can argue that "empty" means "empty" ;) but in that case, why provide the startup assembly code and linker script?

Mark

[Cartu38 OpenDev]

---

"empty" means "empty"  ... I guess so 

"why provide the startup assembly code and linker script?" ... my guess still is helps at least to get bare min buildable project.

CMSIS package(s) can always be retrieved from https://www.keil.arm.com/packs/

[AScha.3]

Ok, so > Create empty project < is bad, if it creates nothing ? Thats what you asked for, right ?

[mark03]

I was somewhat joking when I said "I guess empty means empty."  I mean, sure, if you want to get legalistic about it.  But I can't imagine an application that doesn't use the CMSIS register definitions.  That's just obviously part of every project.  So an "empty" project should mean a basic skeleton, using CMSIS, but without Cube-generated libraries, HAL, LL, and so on.

It does seem to me that this is the only sane way to understand things.  But if there is a secret society of people building their STM32 projects using numeric memory addresses for registers and no CMSIS, please enlighten me :)

Anyhow, please accept this as a suggestion for the next release.  Thanks!

Mark

[Cartu38 OpenDev]

Empty project feature is supported since a while as part of STM32 ecosystem tools. STM32CubeIDE, already since years, is promoting the same empty flavor that VSCode proposal is doing.

@mark03 your suggestion is making sense but I guess hard to define proper level of such feature. Some may ask for a bit of HAL drivers, some for ... etc etc. But yes could be some extra options.

My bet is ST is shooting for a quite light solution for empty project, while if more is required STM32CUbeMX becomes your best friend.

[Kraal]

Hi, I am also very enthusiastic about the empty project feature, and as @mark03 said, it would be nice to embed the minimum CMSIS headers during the project creation.

If it seems controversial to use the word "empty" for such project, then call it bare-metal and it would be fine.

[vincent_grenet · Accepted solution]

This is the first time we are receiving so much emphasis on the empty project feature, to be fair. As shared by @Cartu38 OpenDev , this feature is not new to the STM32Cube ecosystem, but I am very happy to see more traction and comments here!

I have already committed to forwarding your requests to product marketing. We always welcome feedback to serve you better whenever possible. Please could you argue how and why empty projects are convenient to you.

I may also share that we already have some work in progress on this.

May I take this opportunity to share what it looks like on my local (R&D internal) environment at this time to get your feedback? Please comment! 
Disclaimer: I cannot commit to any date or .. having such public. However, the more votes and information we have ... 

   
To be fair, one issue we ended up with today is the CMSIS.Core pack size. The empty project disk size is more than twice as large, thanks to ... It is hard to pick only a small part due to license concerns, so we have to keep it as original.

PS: Thanks @Kraal for bare metal naming proposal may make sense.

[mark03]

Hi Vincent,

That looks promising---thanks for sharing!

Before trying out the VSCode extension, I was not a Cube user.  I would sometimes download the Cube package for my chosen MCU, in order to search through the folders and extract a few hundred kb of CMSIS header files, which I would then manually copy over to my own Makefile-based or VSCode/Cmake-based build system.  I prefer to write all of my STM32 projects using the CMSIS register and bitfield names directly, i.e. with an editor on one screen and the Reference Manual PDF on another screen.

I bet I am not alone, and this is more common than ST thinks.  And maybe ST is now attracting more of these weirdos :) to try out the new extension, as it is perceived as more lightweight and compatible with non-Cube workflows.  That could explain the renewed interest in the "empty project" feature.  Anyway, I think it would be worth doing this, to keep the STM32 power users happy.  The more users the better, right?

Mark

[Kraal]

Hi,

I have the same utilisation profile as @mark03 , I use bare metal project with just the necessary CMSIS headers, the ST header for my particular device, its startup file and the linker file. From there I add my source code and voilà.

As said in another topic, I'm really glad that this "empty project" option exists, and I really want it to stay. Even if the CMSIS headers are not incorporated automatically, I can work around that.

Overall, I am happy with the direction the "new" VSCode extension is heading to.

[Adam Hamilton]

Hi @vincent_grenet 

Bare metal is not correct when stacked up against the other alternatives, so I think calling it bare metal would be misleading.

Bare metal is an approach to coding where you develop directly for the hardware without an OS providing the hardware abstraction. Pretty much, any development you do on an STM32 is considered bare metal, perhaps with the exception of using the MPU family and writing code for Linux. It is also argued that even using FreeRTOS, it is still considered bare metal.

For the benefit of this thread and the OP, I made a post way back in 2020, Why does creating an empty project not add header files where I tried to provide some feature request to add the CMSIS device specific header files to the project.

While some might argue that the Empty project should contain nothing at all, the intent was to provide minimal working code for the selected device. Sure enough, after creating the empty project one can compile and flash the code to the device. However, its usefulness stops there and you need to go and at the very least copy the device specific header files, to which there are a few in order to produce a viable build. These are the core_*.h specific for your device and compiler, the system_*.c file and the device specific header, stm32*.h

When I create a project, I would at least like to reduce the amount of manual work that I have to do every time I create a project, otherwise what's the point?

I don't quite understand this

---

To be fair, one issue we ended up with today is the CMSIS.Core pack size. The empty project disk size is more than twice as large, thanks to ... It is hard to pick only a small part due to license concerns, so we have to keep it as original.

PS: Thanks @Kraal for bare metal naming proposal may make sense.

---

I know for the STM32CubeIDE, and STM32CubeMX, everything is downloaded to a repository directory on the PC, and the files are picked out of this and copied to the project folder when you create a HAL project. Can something similar be done here? Is it possible to create a setting in the extension that points the STM32 repository so that when we create an empty project, the files I mention above can be copied into the project folder.

Kind regards

Adam Hamilton