-
Setup of the clock before initializing static variables from flash makes sense in order to speed up. It may be a difference between 4 MHz and 160 MHz clock. Another possible cause of duplicate/redundant setup procedures. Above there was a comment about efficiency of that procedure.
Concerning main.c and main.cpp i found a comment that you can set an option in the cube project parameters to let the code generator put HAL init sequences into separate .c and .h files. Then you work with a main.cpp (including one call to extern "C" SystemInit) and an empty main.c and that pretty much keeps cube away from all your cpp files. The empty main.c is supposed to stay empty with the code generator. Didn't test that yet.
Regards, Dieter -
Setup of the clock before initializing static variables from flash makes sense in order to speed up. It may be a difference between 4 MHz and 160 MHz clock. Another possible cause of duplicate/redundant setup procedures. Above there was a comment about efficiency of that procedure.
The 32F4 starts up at 16MHz (it uses the "rough" internal oscillator) and zero wait states.
The clock setup is done at the end of the startup.s file so doesn't benefit the initialisation of DATA or the zeroing of BSS.
-
Just started using it [STM32cube IDE] , I don't know if its a bug or a feature but it why does make a main.c file instead of a main.cpp for a C++ project Every time you click "generate code". Is this a bug? If you rename it it will rename it back when you regenerate.
Is there a setting somewhere to change this behaviour?
Ignore what the other posters have said.
There is a comment here: https://shawnhymel.com/1941/how-to-use-c-with-stm32cubeide/
You can also call an external cpp file instead: https://www.reddit.com/r/stm32/comments/mx505c/why_does_stm32cube_ide_make_a_mainc_file_instead/
What I do is just copy the main.c content into main.cpp, keep both files, and choose main.c to not be compiled, but I don't use cube IDE. -
While we're talking about amusing STM32CubeIDE bugs, here's one I've run into before. I don't know if its still there, or has since been fixed, since I haven't given it a chance to reproduce.
I've been using the "u8g2" library in a lot of my projects. I do this by adding the full source checkout of u8g2 into a subdirectory of my project, then just adding the "csrc" subdirectory to the relevant parts of the project configuration.
After doing this, if I let STM32CubeIDE do its code regeneration *and* open my C source code afterwards, it would proceed to open *every* file called "main.c" that it could find under the project root. (this means the dozens of example programs in the u8g2 repo that weren't even in my actual build path). The initial workaround was just to not let it open my code after regeneration. (and the later workaround was to simply decouple myself from code generation altogether once I got to that stage of a project)
-
For thing like that, I simply clicked over the example folder / resource configurations/exclude from all build profiles.
-
Making a Makefile is an out-of-the-world thing for me.
For 5 files it's ok, but when you have 20 folders, subfolders... it's a problem.
For sure, I might be missing something, doing it in the wrong, hardest way
It's true that makefiles are not too easy to work with.
Good news is, you don't have to use most of the features of make, and can just use the same makefile over and over again. The base is like some 20 lines and then you might have another 20 lines of some automation like those make flash_ocd, make flash_uart, make flash_can commands.
Further, if make makes your head hurt, there's absolutely nothing wrong compiling with a script like .bat in Windows or .sh on Unix-y systems.
A firmware project for something like STM32F4 series device shouldn't contain so many code modules requiring 20 folders each with subfolders... My largest projects that occupy some 100K of flash on H7 series parts have some 20 .c modules total (in one folder) and full compilation takes maybe 5 seconds on a crappy laptop, <1s on a real desktop computer, so make is not absolutely required for performance. C is faster to compile than C++, if that matters. Yes I have written my own makefiles but if I didn't know how, I would just proudly run a stupidly copypasted .sh/.bat script to do that, it would do the job just fine.
For complex and large projects on PC for example, then I really think it pays off learning the basics of make. Understanding these basic tools is a requirement when working in teams, and in larger projects you have to work in teams. IDEs have the problem that everybody knows and wants to use a different one. But if the project implements a general build environment through base tools, then everyone can use whatever code editor / IDE they want. -
A firmware project for something like STM32F4 series device shouldn't contain so many code modules requiring 20 folders each with subfolders... My largest projects that occupy some 100K of flash on H7 series parts have some 20 .c modules total
How many locs are your c modules and is the design coherent with the solid principles ?
It could be that 20 modules suffice but usually you will have many more at least one per peripheral , one per protocol/service, one per type of utility, one per additional ics used, etc. Software design can also be seen as a craft with the last 30 years many good practices.
Putting a lot of different dependencies, responsibilities and interfaces in one module is the same as a hardware engineer designing a pcb and randomizing the location of the digital, analog and power parts and letting the auto router do its job. -
peter-h, init/fini arrays are for static constructors/destructors support.
In a C++ project placing an object into a global/module scope (outside a function) will add it’s constructor (if it has one) to init array and destructor to fini.
In a C project the same can be achieved with __attribute__((constructor)) and atexit().
If you (and libraries you are using) don’t use neither C++ nor those C tricks you can drop init/fini sections and __libc_init_array call.
And destructors are really uncommon in embedded projects (main() never exit usually). -
Thank you.
What I can't presumably be sure of is that "nor those C tricks" doesn't apply. I can't see any evidence that it might, but this detail is way above my pay grade, and why would ST include that stuff in a purely C environment? -
at least one per peripheral , one per protocol/service, one per type of utility, one per additional ics used, etc. Software design can also be seen as a craft with the last 30 years many good practices.
... and routinely creating a module per peripheral is like routinely creating a sub-PCB assembly for each IC pin.
No, you partition modules by functionality separated by where is the most logical and smallest interface. For example, an interface to a motor control module might be speed and current setpoints, and measured speed and measured current. If the motor control module then becomes too big for comfort, it can be refactored to a few submodules, but you want to have clean interfaces that have an actual "physical" purpose.
Think about accessing, say, an SPI-based accelerometer. The SPI peripheral is required, but then the GPIO peripheral is also required to toggle the nCS pins. You definitely don't want to split the module here! Peripherals are just resources, nothing wrong using two resources from one module. And no, you don't need to create a per project .c module to abstract something as simple as GPIO, for whatever deity's sake.
Yes, my modules sometimes end up slightly too long for comfort (1000 LoC is already too much) but refactoring by splitting on demand is easier than coming up with a massive cathedral of complexity just to see that eventually the abstractions are wrong and spend all time writing interfacing boilerplate. If I split the 20-file project into 40 files nothing fundamentally changes.
I see a lot of projects, especially in C++, where you can't get hold of anything because a project contains 1000 files each with 50-200 LoC and 95% of all that is boilerplate and it's extremely hard to find the actual few lines that do anything. C programmers don't seem to do this nearly as much. -
Yes, my modules sometimes end up slightly too long for comfort (1000 LoC is already too much) but refactoring by splitting on demand is easier than coming up with a massive cathedral of complexity just to see that eventually the abstractions are wrong and spend all time writing interfacing boilerplate. If I split the 20-file project into 40 files nothing fundamentally changes.
Oh a 1000 lines for a module I can still see as ok'ish, but 20x 1000 lines do not end up with 100k ROM code
That is what triggered me.
But to make it more tangible, it is advised to spent some time on designing the structure before starting to program and abstract it such that if you need to change for instance the motor IC from company A with one of company B (although the same interface but different opcodes and way of programming) you do not have to change the higher levels of coding, only the ic software component.
The same with the ethernet interface, if you change the PHY only one or two modules should have to be replaced/changed.
And probably you already do that, but I have seen so much spaghetti code in my life where a doxygen dependency chart would result in a black spiders web, I got allergic to that
Once I turned down an assignment because I stated to be able to finish this POS code I had to start literally from scratch.
That small startup company of four persons had spent two years with two external probably HW only engineers coding but they did not get it to work reliably (would hang each and every 5 hours upto 24 hours).
When I looked at the code I could not make head and tails from it. No abstraction at all, everything handled in a single superloop function with over 25000 lines, timing dependencies depending on the superloops looptime OMG!!!!
Nope sorry, not going to clean up that mess, you need Tom Cruise for that MI10. -
Oh a 1000 lines for a module I can still see as ok'ish, but 20x 1000 lines do not end up with 100k ROM code
That is what triggered me.
Why not? I'm sure it's the right order of magnitude. 20k LoC of no-boilerplate effective C code easily generates approx. 100k of Cortex-M7 machine code, especially if large parts of it are compiled with -O3 instead of -Os and inlining is used where performance is important (remember, that chip has large no-wait-state ITCM that can supply code to the CPU without cache miss issues like on a PC, so inlining really is effective).
OK, I actually checked one of the projects I was thinking about and it's 80KB, 22 files and 20kLoC. Probably would benefit from refactoring 1-2 largest modules (that exceed 2000 LoC, this is absolute limit I would not want to accept from myself but oh well) but really, would benefit more from simplifications and replacement of excess verbose code with simpler code performing the same job.
Clean simple interfaces and as little as possible cross-dependencies between modules allows replacement of modules indeed. But microcontroller projects can sometimes get messy when you really run close to the capabilities of the chips because you need to rely on some very specifics like how some certain peripheral instance can map to some other peripherals like a timer communicates with ADC, analog comparator and DMA! And these connections are fixed in silicon so simple fixed code matches this reality. Adding "generic" interfaces where they physically do not exist only adds a layer of complexity then. And BTW, the STM32 HAL obviously cannot support all such features even when they are the strong selling points of the devices, and I don't blame them, all this configurability is hard to abstract generically. And using all that power inside of those modern chips also pretty much means you are tied to that particular chip (or maybe a few sister models). If you want generic, then the only option would be FPGA, but then again, these also require using the "hard macro" blocks in practice so again your code is somewhat tied to a certain vendor. -
The strong point of ST vs competitors IMO is that in a certain STM32 series (with series I mean F1,2,3,4,L2,L4, etc), for a certain ic package you still have a growth path in #kB SRAM , #kBROM for the same package.
Numerous competitors do not have this or are more limited.
ST never intended easy switching between series, they even have different Arm core versions. They probably should have and tried to mitigate this as much as possible but the first gen SW interfaces were for instance completely different between F1 and F2. That legacy remains because you can not design an improved compatible version of an ood chip while it breaks backwards compatibility.
-
I don't think I would use a batch file for my current project. 225k of code and takes a few minutes to compile the whole lot. That's too long to wait for just a simple mod to say 1 file.
Incidentally, does Cube have a RESET button? Lots of people looked for one, and there are some old posts online by ST people saying it is on the list. It should be trivial, since the STLINK debugger controls the reset signal. -
I have today wasted a few hours trying to create a second project within Cube IDE.
The only way I found of doing it was this:
1) Outside of Cube, create the directory which is a copy of the 1st project e.g.
c:\devt\project1 - this was already in Cube
c:\devt\project1 - this is a copy of above
2) In Cube, right-click on the project (in the left Project Explorer pane) and Copy, then Paste. Then it asks you where to paste it to and what to call it. Choose the path of the 2nd project. It will say some files already exist; that's ok. Why step 1) was needed I have no idea.
But there are some issues. There are many irritations e.g. the various desktop items like Build Analyser do not change around as you switch projects. Well, sometimes they do... They tend to show the right thing only after you do a build, and until you switch to a different project. The 2nd worst is that the files open in the editor (the tabs) do not change as you switch projects, so if you have main.c in both you will not notice unless you hover over the tab(s) each time. Incredibly stupid. But the 1st prize goes to cross-linked files; the two projects are not really separate. Mine ended up sharing some files.
I don't have experience of other IDEs but would have never designed such a POS myself. The edit context and all the reporting windows should all switch as you switch between projects.
v1.6.1.
I need to build a 2nd project so will install Cube in a VM. That way I can also test new versions of it. It may not drive a STLINK USB debugger out of a VM (should, but you never know with VMs; I used VMWARE all the time for winXP ones for old sw for CAD/EDA) but that project will just need to create a .bin file.
-
That is not how Eclipse works. If you want the behaviour you requested, you need to create 2 seperate workbenches and open Eclipse twice.
The workflow of Eclipse is centered around using version control where your 2nd project would live in a seperate branche and you switch between projects by selecting the appriopriate branch.
However, Eclipse should be able to copy a project but you might have to tell it that you want to copy all the files and not create links. -
I can't find an option for new workbenches
Indeed; I chose to copy files, not create links.
The thing is that it almost very nearly worked ok. I did two installations (different machines) and on one of them the Build Analyser did switch as one clicked on different projects. But only after one built each one and exited Cube a few times in between.
"open Eclipse twice."
Do you mean have two instances of the executable open? That would certainly need two monitors (which I have).
I created two projects like this
Given that this is possible, what is the intention behind allowing it, and with some screen elements correctly swapping over? -
Not sure if this is the case with the new version of cube but sometimes the path to the files or the working directory are hardlinked in some project file or helper files.
So when you copy an entire directory and rename the directory the files in it are not changed.
So use a program that can scan the contents of files and search in your second directory for the name of the first directory or project name and replace it in those files, this might not work if there are extra checks, but works fine in for instance stvd an old stm8 ide of ST.
If this does not work you just create a new project quickly with the same target and compare the two directories, copy additional files and overwrite changes. At least you get to see which files have hard links and names in them.
-
Yes. Eclipse allows to open it as many times as you want but you need different work spaces (each with their own .project and files / Eclipse specific directories). A workspace is nothing more than a directory where the projects will reside.
"open Eclipse twice."
Do you mean have two instances of the executable open? That would certainly need two monitors (which I have).
Note what Kjelt wrote: any path in the project configuration which points to a project specific file must be relative to the project root and not absolute.QuoteGiven that this is possible, what is the intention behind allowing it, and with some screen elements correctly swapping over?
The idea is to have related projects in one workspace. For example microcontroller firmware, a PC application and the VHDL code for an FPGA. Having the same project twice in the same workspace is asking for big trouble though because you are bound to open / edit the wrong file at some point.
-
"sometimes the path to the files or the working directory are hardlinked in some project file or helper files."
Yes; this is happening. There is a path "IDE" which appears all over the place and doesn't appear to be configurable. Or maybe it did appear in an early project and "stuck".
This reminds me of many weird "paradigms" from the "publishing software" world, where they try to force you into a particular path. For example under Windows some try to force you to My Pictures, and there is no way to change this as a default.
"The idea is to have related projects in one workspace. For example microcontroller firmware, a PC application and the VHDL code for an FPGA."
That's what I was after. Two 32F4 build projects, but different source files and one linked for 0x08000000 (base) and the other linked for base+32k so different linkfiles.
If this worked well, it would be a very good way of working. Just click on the desired project and the whole context switches over to it. -
This reminds me of a project i once factorized into "system" and "application". The system was to load/update the application over the host interface. It was an existing MSP430 application. First i kept everything in one IDE project and made a special linkfile with two code sections and two data sections and sorted all the system parts into one section and all the application parts into the other one. When everything was working again i made two additional projects without source files, where one of the projects would refer to everything needed for the system, the other one all the application stuff. Now i could build the system without application in it. It would just send a boot message and the serial number and then scan flash to discover the application if it was there and link it dynamically. The other project would generate the application code only, like a library. It may sound a bit complicated but worked very well and is still in use. Meanwhile we even have a "SysUpdater" application that i can upload to update the system to a new version, all using the host interface.
Regards, Dieter -
"sometimes the path to the files or the working directory are hardlinked in some project file or helper files."
If your goal is to have the same project but build using different settings, then copying the project is the wrong way to do that. You have to create separate build configurations for the same source. If you need to compile slightly different functions, you can define symbols in the build configuration that will be passed to the compiler as if they where defines.
Yes; this is happening. There is a path "IDE" which appears all over the place and doesn't appear to be configurable. Or maybe it did appear in an early project and "stuck".
This reminds me of many weird "paradigms" from the "publishing software" world, where they try to force you into a particular path. For example under Windows some try to force you to My Pictures, and there is no way to change this as a default.
"The idea is to have related projects in one workspace. For example microcontroller firmware, a PC application and the VHDL code for an FPGA."
That's what I was after. Two 32F4 build projects, but different source files and one linked for 0x08000000 (base) and the other linked for base+32k so different linkfiles.
So in your code you can do:
#ifdef BUILD_FOR_RAM
--do this--
#else
--do that--
#endif
-
"This reminds me of a project i once factorized into "system" and "application". The system was to load/update the application over the host interface."
Yes that is pretty well exactly what I am doing here. Except that the binary generated for the debugger is the same as I am writing into the .bin file, with a CRC appended, and which can be sent to the target where it is stored (in a serial FLASH) and then, on next reboot, flashed into the CPU.
I don't need a second project for that.
The "second project" requirement is that there is a need to update a part of the program. This has a well defined interface. It will involve the generation of a .o library file which is linked to (often a very small) program, and this will be sent to the target. I don't yet know how to generate this library (most likely another "post build step" batch file running some GCC commands, to collect a list of the existing .o files into one). I was hoping to make this an entirely separate project, so avoid any risk of "contamination". The linkfile will also be different.
"You have to create separate build configurations for the same source. If you need to compile slightly different functions, you can define symbols in the build configuration that will be passed to the compiler as if they where defines."
That is really clever - thank you.
Cube has a vast number of build config options, variations of "C/C++ this or that", each with its own config, and its own debugger config, and usually only one of these works Last night I went around and deleted all the ones not used. There are just two options now: Debug and Release.
This thing needs a course...
I will probably do it with a VM, and that way I can have another file also called main.c, and I can test new versions of Cube without breaking something. -
Quote from: Kjelt on Yesterday at 22:12:37
Not sure if this is the case with the new version of cube but sometimes the path to the files or the working directory are hardlinked in some project file or helper files.
...
This is a real joy if you have a team of developers working on the same project, each having their own path structure.
In case anybody doesn't know the defines Eclipse uses for that, yet - here is a the path to a linker script as an example:
${workspace_loc:/${ProjName}/STM32F103C8TX_FLASH_APP.ld} -
Quote from: peter-h on Yesterday at 21:22:03
"open Eclipse twice."
Do you mean have two instances of the executable open? That would certainly need two monitors (which I have).
Yes. Eclipse allows to open it as many times as you want but you need different work spaces (each with their own .project and files / Eclipse specific directories). A workspace is nothing more than a directory where the projects will reside.
Note what Kjelt wrote: any path in the project configuration which points to a project specific file must be relative to the project root and not absolute.
...
It gets even better: since you can address a STlink/Jlink via their serial number, it is possible to open several instances of Eclipse/CubeIDE and debug as many devices at the same time as you have debuggers. This comes rather handy if you have, as in one of my current projects, three MCUs sharing one bus and you have to look into their interaction.