"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.

 

[Adam Hamilton]

---

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

---

I think it is well understood that one can use CubeMX to generate a HAL based project.

The issue presented here is that the empty project is not including some key files, namely the device header files and the system_*.c file, which to me is a no-brainer. Those files will need to be copied to the project folder if you plan on doing anything useful. If the project generator can also pick these files, it is just one less manual task for the developer to do.

 

Kind regards

Adam Hamilton

[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]

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.