An implementation for CMSIS packs is currently under way and it is planned to update all templates to use it. Support for STM32L will be added at the same time.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
So digging around a bit more, I see another dependency: The STM32 standard peripheral libraries.
Assuming the CMSIS stuff is already in place, I see that the interfaces for the STM32 standard peripheral libraries are not the same. This implies not being able to directly migrate between chips, which I was led to believe was the whole purpose of the abstraction layers in the first place. An example of where I see this is stm32f10x_rcc.h and stm32l1xx_rcc.h files that come from the latest releases of their respective libraries. For the stm32f10xx, RCC_APB2Periph_GPIOA is defined, however for stm32l1xx RCC_AHBPeriph_GPIOA is defined. Of course I wouldn't expect that all use cases would be catered for and this is an exotic situation however it's interesting none the less.
I would be interested to hear your thoughts and if there are any plans to allow the simplification of device migration (that includes the underlying CMSIS and std peripheral libraries).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
forget about the StdPeriph library. it is no longer supported by ST.
regardless how difficult you may think it is, consider porting your applications to the new HAL interface, you'll need to do it anyway (sooner than later).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Oh, I saw they were moving away from stdperiphlib but as far as I could see it was still "active".
The existing templates for STM32 (and blinky examples) all appeared to pull the stdperiphlibs in.
What is the new HAL interface, cubeSomething? From various threads I was under the impression that they were not ready for production use, am I mistaken?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Great, register view and manipulation and out-of-the-box STM32L support are the two key features that are keeping me from using Eclipse with GNU toolchain for ARM development, and this update seems to solve both!
Thank you very much for the great work!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes Please!!!! on the L(1 in this case)... I've been waiting for some time, hoping that the L1 would get added to this. I've even gone so far and doing an F3 project and then using what I can of it on the actual L1 project, but that's getting lame.
Hopefully this will be easier now that ST released the cubeMX for the L1 in the latest 4.4.1 release there...
Any update?
Last edit: aadamson 2014-10-16
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
as soon as I finish the debugging features that I'm working on now; the next priority are the packs based templates, but realistically it'll take some few more months.
but the world turned around even before my templates, just create the STM32L1xxx project manually, save it as an archive, and then use it as a template.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
An implementation for CMSIS packs is currently under way and it is planned to update all templates to use it. Support for STM32L will be added at the same time.
Not sure I follow "implementation for CMSIS packs". Is this a separate abstraction in the plugin to handle CMSIS components and their releases?
making use of all CMSIS packs information will take time, since most of them are specific to ARMCC and Keil MDK.
for now, the device definitions (the SVD files) are used in the debugger, and the documentation is presented in the main C/C++ perspective.
in future versions the CMSIS headers and startup (vectors) will be used in a more generic project template.
So digging around a bit more, I see another dependency: The STM32 standard peripheral libraries.
Assuming the CMSIS stuff is already in place, I see that the interfaces for the STM32 standard peripheral libraries are not the same. This implies not being able to directly migrate between chips, which I was led to believe was the whole purpose of the abstraction layers in the first place. An example of where I see this is stm32f10x_rcc.h and stm32l1xx_rcc.h files that come from the latest releases of their respective libraries. For the stm32f10xx, RCC_APB2Periph_GPIOA is defined, however for stm32l1xx RCC_AHBPeriph_GPIOA is defined. Of course I wouldn't expect that all use cases would be catered for and this is an exotic situation however it's interesting none the less.
I would be interested to hear your thoughts and if there are any plans to allow the simplification of device migration (that includes the underlying CMSIS and std peripheral libraries).
forget about the StdPeriph library. it is no longer supported by ST.
regardless how difficult you may think it is, consider porting your applications to the new HAL interface, you'll need to do it anyway (sooner than later).
Oh, I saw they were moving away from stdperiphlib but as far as I could see it was still "active".
The existing templates for STM32 (and blinky examples) all appeared to pull the stdperiphlibs in.
What is the new HAL interface, cubeSomething? From various threads I was under the impression that they were not ready for production use, am I mistaken?
by the time the templates were written, some devices had HAL (like F4), some did not.
yes, HAL drivers are used by cube. I do not know if they are production ready, but they are pushed by ST anyway.
Great, register view and manipulation and out-of-the-box STM32L support are the two key features that are keeping me from using Eclipse with GNU toolchain for ARM development, and this update seems to solve both!
Thank you very much for the great work!
register view was already introduced with the latest release.
Yes Please!!!! on the L(1 in this case)... I've been waiting for some time, hoping that the L1 would get added to this. I've even gone so far and doing an F3 project and then using what I can of it on the actual L1 project, but that's getting lame.
Hopefully this will be easier now that ST released the cubeMX for the L1 in the latest 4.4.1 release there...
Any update?
Last edit: aadamson 2014-10-16
a new wizard to create empty projects based on CMSIS packs is next on the TODO list, but it'll take a while to be ready.
Any further progress on an "empty project" based on CMSIS packs?
Alternatively, does anyone have a template blinky "project" for a STM32L1xxx ?
as soon as I finish the debugging features that I'm working on now; the next priority are the packs based templates, but realistically it'll take some few more months.
but the world turned around even before my templates, just create the STM32L1xxx project manually, save it as an archive, and then use it as a template.