Menu
▾
▴
#1 New structure for the projects generated by the templates
There are two main changes:
- a new generic Hello World Cortex-M template was added
- the structure of the projects generated by the templates was completely redesigned.
I would appreciate comments on these changes, since the new structure is planned to be replicated to all other templates.
Specifically I'm interested in suggestions on the way the files are organised, on the files content and also on the configurability of the new template.
When installing, please be sure you add the feature called:
GNU ARM C/C++ Generic Cortex-M Project Template
To instantiate it, create new C or C++ projects, type Executable -> Hello World ARM Cortex-M C/C++ Project.
The new template looks very helpful for users. which are not very familiar with a new processor. Ok, maybe this is generally the reason to have a template. In my case i not familiar with the Cortex-M line. Because of this I can not say if this is a good structure. But because I have the requirement to start up with a new cortex A5 cpu in a fee months, I will be hopefully you will support this enviroment with a template too.
What I like generally are the more extensive settings to bring the project up. Cortex Type, ram size and so on. What I would suggest is to have the settings of orign of flash, ram at this point, too.
this is a completely different family, and most of the time development is done in user space, as a gnu/linux process; the low level details are handled by the bootloader provided by the manufacturer.
on Cortex-M these are fixed
just been playing a bit with it, I try Empty hello world template right now, it's an amazing amount of work thanks already for that s. It's definitively helpful to start.
There a lot of options to select during project creation semi hosting,trace etc... look complete excellent
Not all option value are fully obvious or self explain a contextual help or later coming doc would help.
Seam all u/i option preset compiler -D directive , that can be changed/turn on and off anytime after project creation that's great, .
On the end it's a few directive to know or be aware off but until it exist a recap or doc in some source file or read-me it's fine. What seam to be already the case i've seen a few word in main.c
Implementation of "no trace" is arguable , empty body still generate some code and useless call plus useless string in rom/flash and ram. These is not the case with traditional #define x(...) (void)0 macro expansion that has my preference. But both
option have pro and cons.
you use the ldscripts/libs.ld to add extra library my preference is to use the project properties in C/C++ General -> Path and symbol -> library. as it's more portable across compiler and compatible tools-chain (i'm alternatively using same or modified project/target with gnu arm and or cross gcc)
Also the dependencies with respect to project/makefile is managed what is not the case for ld file referenced by linker option (not in final output file dependencies list).
Overall project and directory strcture make sense.
A top level readme like ones in some sub-folder could help getting started.
I'll come back with more comment and feedback as i used test it more.
there is a tooltip in the wizard, but probably it is schematic. could you point to specific values, and suggest what you would like to see?
did you check the generated code? the empty body functions are all inlined, and the optimiser does not generate code for them. or at least this is my experience with this.
yes, for user libraries you are right, but there cases when the linker requires some system libraries to be grouped together. the libs.ld file is specifically for this case.
can you point some issues to be clarified by this readme?
thank you for your feedback,
Liviu