EEVblog Electronics Community Forum
Electronics => Microcontrollers => Topic started by: peter-h on July 28, 2021, 09:07:32 pm
-
I've just spent some hours trying to find out why code which compiled last night doesn't compile today.
Nothing was touched - also not touched according to file date stamps (as seen in windows explorer).
But I appreciate that if you leave any editor on-screen with a file open, a slip of the finger on a keyboard can "do stuff". But this should not change a file if you don't then save it.
The error was an obscure one, which I could not get my head round (not my code), to do with a typedef being "external" in a .h file (no idea why not include the .h file containing the real one, or why the typedef was not being exported from the .h in which it was). I don't really understand the intricacies of this stuff so I avoid this sort of thing in my own code. But it compiled the day before! This suggests that files can be changed and don't get recompiled after the change. Well, many times doing a Clean Project and then Build Project does mysteriously fix stuff.
Exiting Cube asked if I want to save a couple of files, suggesting they were edited, and I unchecked both and exited the program. I also found that some of the open files could not be closed by clicking on the cross (obviously this is a bug).
Also I lost the default window configuration. Took me a while to work out how to get it back.
I have backups almost daily of the whole project directory, to a network drive, but need to make sure I really do them daily :)
-
I'll tell you a secret - any manufacturer provided tools and frameworks are crap. They are a cost center, they don't directly generate money, they cost money. So they are maintained to the level that is mostly acceptable, but no more. There is no real incentive to make them excellent, it will not result in more sales.
-
I'll tell you a secret - any manufacturer provided tools and frameworks are crap. They are a cost center, they don't directly generate money, they cost money. So they are maintained to the level that is mostly acceptable, but no more. There is no real incentive to make them excellent, it will not result in more sales.
Yes, that is true. Especially since, as you can read here and elsewhere, many professionals actually use other tools than the vendor provided ones. Vendors know this, and know that customers buying the most parts usually don't care about the crap IDEs and code generators they provide.
So, for the OP, do as you wish of course, but if I were you, I would take this mishap as an opportunity to switch to better tools and say goodbye to ST Cube forever. It will take you some time and effort, but will be worth it. ;D
-
CubeIDE came from a commercial product, Atollic TrueSTUDIO. So its not really the same as in house developed IDEs.
But you are free to use many other IDEs available for STM32.
Are you using version control? Then you will actually know what might have changed instead of guessing.
-
What would you recommend?
Incidentally I see Cube (currently 1.6.1) is now at 1.7 but I don't want any ST libs getting changed. Is there a way to just update the IDE application? It may update the code generation stuff but that should affect only future usage (and anyway that aspect gets used only to generate snippets which then get moved elsewhere).
I used "make" for many years and it was great, but this thing gives you single stepping. I guess the answer will be that e.g. a Segger debugger comes with software which does that, but from what I have seen of that software, it looked like something from CP/M 2.2 ported to win3.1 :)
Not using version control; however my drift here is that files can get changed in the IDE editor without the IDE being aware of it, and apparently without their time stamps getting changed (yes I know that is hard to believe but I have a video editor - Vegas Pro v16 - which does exactly that!).
Oh and the funniest bit is that during a build a lot of the scrolling text is in white, so you can't see it. Reproduced across 3 machines, some win7-64 and one win10. But if you run it over RDP (remote desktop) you see all the text just fine :) It's actually not trivial to write an app which produces invisible text, using the windows GUI functions, but such that when it is later channeled via RDP it is visible.
-
There is little to learn from a failure report like this, since there are so many reasons for something to fail.
So let me report that i have been using a fairly recent version of STM32 cube for development and with good results, BUT: Use it to help you define pinout and initialize peripherals. For your own mental health use a serious IDE like IAR for further development. As long as i work inside the user code sections defined by Cube, that works very well and i can even modify/update the hardware setup without losing any code. Recent versions of STM32 libraries are fairly complete and absolutely useful.
Regards, Dieter
-
Some possible things that can cause problems are, of course:
* time stamp differences that do / do not get updated / processed appropriately
* pre-compiled headers that aren't updated based upon their dependencies so they don't sync with the actual inputs
* dependencies that aren't reflected properly in the build so stale objects or generated inputs are built into the output
* "clean" or "rebuild" rules aren't deleting / regenerating / rebuilding from the base configuration
But, surely, all of those are bugs? An "IDE" isn't supposed to be doing that.
If one was editing files outside the IDE, then maybe, although I would still expect an IDE to check the stamps when you trigger a build, as a robust way to do it.
-
I do not think this type of failure is specific to Cube IDE. I have seen exact same behaviour with MS Visual Studio. Compiles today, will not tomorrow. In fact, pretty much every single MS VS project (created by someone else) did not compile from the first try on my computer on the same VS version. The problem therefore is somewhere deeper.
-
I used "make" for many years and it was great, but this thing gives you single stepping. I guess the answer will be that e.g. a Segger debugger comes with software which does that, but from what I have seen of that software, it looked like something from CP/M 2.2 ported to win3.1 :)
Are you referring to Ozone here? If so, just learn to live with what it looks like. It's not that bad. Besides, it's a very robust debugger and much more robust than the typical debugger built into vendor Eclipse implementations.
-
I've got problems like that few times. Almost always, I made something and forgot it or simply didn't notice. My advice is to install and use eGit. Any single difference will be detected, saving you a lot of hassle when things go wrong.
It could be simple as forgetting to add an include path or a define in debug or release configs, then you switch the build type and bang!
If it isn't a delicate thing, I can have a look at it. I've fought a lot of times with this ide! |O
An advice: Never move files using the ide itself. I had some really bad times, where it showed a "resource busy" error. And the file I moved no longer existed anywhere!
I still remember a file where I added tons of defines for registers and bits to use a IO expander. Moved it to the working directory... gone! I would have burned down the ST headquarters!
-
What would you recommend?
Incidentally I see Cube (currently 1.6.1) is now at 1.7 but I don't want any ST libs getting changed. Is there a way to just update the IDE application? It may update the code generation stuff but that should affect only future usage (and anyway that aspect gets used only to generate snippets which then get moved elsewhere).
...
I'm not going to recommend my choice over another, I suggest people just try the options that are out there and see what suits them. Personally I use Visualgdb (https://visualgdb.com/?features=embedded), since I'm a VS fan and not a pro programmer and it does everything for me. But there is VSC/platformIO, and the other options mentioned here.
Don't know about just updating the IDE, I would test it in a VM.
If you are not using version control, you are just flying blind IMO. OK for hobby, not good for work.
-
Sure, you can select the library version in the cubeMx project settings.
-
A small hint, try different versions. Some versions have issues some do not.
Keep backups of old installers and BSP (board support packages!)
-
Just don't use it? Even if it were less buggy and crappy, it won't likely exist in 2-3 years from now. Especially in STM32, the variety in "trend IDE of the year" has been massive. Everybody uses a different one, and the "preferred" tools change all the time. This causes unnecessary learning cycles.
Just learn the underlying GNU tools, pick a code editor you like, and you are good to go for any ARM microcontroller from any vendor, and good for decade(s) in the future.
-
A lot of people seem to be doing that, and historically everybody did, but then you don't get integrated debugging.
Interesting comment about precompiled headers. Does this system use those? It would explain the last problem I had, which was a .h file which could not possibly have worked for the .c file in which in was being #included, and was last edited months ago. However, I did do a Clean Project many times during that time; doesn't that delete all compiled objects?
-
You can get vscode to debug for any cortex m microcontroller. I don't see the point in using vendor specific IDEs.
-
I'm not going to recommend my choice over another, I suggest people just try the options that are out there and see what suits them. Personally I use Visualgdb (https://visualgdb.com/?features=embedded), since I'm a VS fan and not a pro programmer and it does everything for me. But there is VSC/platformIO, and the other options mentioned here.
Don't know about just updating the IDE, I would test it in a VM.
If you are not using version control, you are just flying blind IMO. OK for hobby, not good for work.
Quoted for truth on both counts.
Visual GDB plus VS Community Edition is a very practical and powerful combo: one of the best IDE around (YMMV) and solid support for every Arm MCU under the sun (a bit of an exaggeration...) plus some the usual non-Arm ones. It's a paid product, though with reasonable prices.
It has served me well for all my hobby stuff (not doing embedded code at work) and can easily import CubeMX projects.
Using a version control system is in my view an absolute requirement even for hobby projects. Good IDEs usually include a good integration of git (Eclipse and derived are the usual pain in the neck, making everything confusing, slow, and half working).
Just don't use it? Even if it were less buggy and crappy, it won't likely exist in 2-3 years from now. Especially in STM32, the variety in "trend IDE of the year" has been massive. Everybody uses a different one, and the "preferred" tools change all the time. This causes unnecessary learning cycles.
Just learn the underlying GNU tools, pick a code editor you like, and you are good to go for any ARM microcontroller from any vendor, and good for decade(s) in the future.
And that is the equally good, if not better, alternative route.
Having a project I share with a friend and not being able to withstand MCUxpresso (another crappy Eclipse adaptation*), I convinced him to use VS Code (he's on Mac and Windows, I'm on Linux and Windows) and set everything up for him (Cmake files, compilation tasks and debug config).
The (~200 kLOC) project now compiles and link from clean in 1.8 s (Windows) from inside VS Code (Cmake/ninja + clang, not gnu but FOSS) instead of 25 (MCUxpresso = make +anoe-gcc), and we have no host platform dependency (apart some environment variable difference).
Many other smaller projects I set up in a similar way, and the independence of the build system from the IDE/editor, the VCS, and the host platform allows me to switch them at will, if the need (or fancy) arises.
A lot of people seem to be doing that, and historically everybody did, but then you don't get integrated debugging.
Interesting comment about precompiled headers. Does this system use those? It would explain the last problem I had, which was a .h file which could
With VS Code you have very good integrated debugging, I use it all the time, even with FreeRTOS and Azure RTOS (which I contributed to pyocd).
I think arm-none-eabi-gcc does not use precompiled headers, but if the IDE gets confused then it's its fault (and it's crap - but talking about Eclipse that's a tautology).
*MCUxpresso grievance notes on request, but I would have to clean up the language, not suitable to civilized company.
-
Also, always backup your project folder before updading, or use git from the beginning.
It's the 3rd time that the **** ide wipes my Src folder after updating.
The first time I was not happy because I never expected that, but since then I started using git.
Now I just don't care, the worst situation would require going to git staging window and restoring the files from HEAD :-+
-
Visual GDB looks interesting. I've emailed them with some questions re e.g. how easy is it to migrate from Cube. Am I right it does not do the code generation which ST Cube IDE does? This is useful at times to get started, but one could just have a Cube install for that, use it for the one function, and then exit.
It seems to require the MS Visual Studio to be installed.
One particularly irritating feature of Cube is that the .elf file is periodically impossible to delete/overwrite - because the ST debugger locks it! One has to close Cube and delete it from within Windows.
Another is the difficulty of installing a copy of a project on another PC. One can't just "import" it. The process involves (I posted this before) copying over the Project directory as well as the Cube workspace. Here are my notes
INSTALLING THE KDE PROJECT ON ANOTHER PC
Install Cube IDE and upgrade to v1.6.1. Exit Cube.
Copy over the \kde420\project1 directory.
Copy over the \st\.....\configuration directory (overwrite one in the new install).
Start Cube. Should just work.
Otherwise, STM32 CubeIDE will refuse to import when the project name is referenced in another project that already exists in your workspace, or referenced in another project that you're trying to import with the new one. This happens whenever you make a copy of an existing project and rename the project folder to say v2.
Another solution (not tested) is:
Manually edit (e.g. find and replace with NotePad++) the old project name references with the new project name within these files:
.cproject
.mxproject
.project
[projectname].ioc
Also, the .ioc file needs renaming to the new project name.
This is a POS. Lots of people will want to copy a project onto say a laptop. Currently I solve this by running Cube over RDP (remote desktop, over a VPN, to the location where I do most of the work) which works on a fast connection.
-
Visual GDB looks interesting. I've emailed them with some questions re e.g. how easy is it to migrate from Cube. Am I right it does not do the code generation which ST Cube IDE does? This is useful at times to get started, but one could just have a Cube install for that, use it for the one function, and then exit.
It seems to require the MS Visual Studio to be installed.
Some answers:
No, VGDB does not do code generation.
I always used it with the stand-alone CubeMX (not the one integrated in ST CubeMX IDE), in that case it's as easy as generating the project as GPDSC.
The code generation is performed by CubeMX as usual, and the import procedure is quite simple and reliable (https://visualgdb.com/tutorials/arm/stm32/cube/).
Yes, VGDB is a plug-in for Microsoft Visual Studio, so you need some version of VS installed.
For home/hobby use, VS Community Edition (https://visualstudio.microsoft.com/vs/community/) is more than powerful enough (very little is missing from the Pro/Enterprise versions), and with very few limitation (I think you can also sell your code, but I should re-check the license - checked (https://visualstudio.microsoft.com/license-terms/mlt031819/)).
OTOH, in a work environment, VS CE can be (simplifying) used only for Open Source or educational purposes - but have a lawyer read the license to make sure your use case is included.
While debugging inside Eclipse based IDEs often fails for me with no understandable reason, I very seldom had problems with VGDB, as long as the debugger - MCU combo is supported (and you can go full manual if needed).
As for your woes with moving projects, my only hint is to ditch Eclipse based crap (https://www.hp-lexicon.org/thing/black-punishment-quill/), though I must admit MCUxpresso (the crap from NXP) got it quite right in this respect and I had no issue importing and using a project in a git repo in Windows, Linux and Mac with no change - but as I said above, I then moved everything to Cmake/ninja/clang + VS Code.
Only renaming the folder is bound to fail though, and also renaming the project inside the IDE has some drawbacks.
Probably using a different Workbench per project might be easier - I find the VS way (Solutions as a containers for projects) much superior.
-
Code generation is like crystal meth. Just say no to code generation. You don't need it. Open the reference manual and write your own code. Writing out the registers is only marginally slower than clicking the same options through point&click interface, and minuscule part of total development time. You are a programmer, you should be familiar with writing code.
Simple peripherals are typically 5-10 lines of code. No need to generate it.
More complex systems like TCP/IP stack over Ethernet, or USB, or filesystems, then you use libraries, this isn't code generation either.
-
Sure; I have always done stuff that way. But now I am more or less taking over a project which was done with Cube code generation to a large degree.
It seems to be working ok. There were lots of bugs in the USB and Ethernet libraries, which took perhaps a year (of part time work) to fix.
I have never personally used the code generator, or the clock configurator, and don't plan to.
All great info - thank you!
Cube is weird in so many ways. Right now I am stepping through a project. Each time I do a new build, and before it hits the first breakpoint, it hits some random line of code in some randomly chosen .c file, and then continues to the first breakpoint, but that randomly opened file stays open, so if you do 10 builds, you end up with 10 random .c files opened in the editor, which you have no interest in :) It's only just started doing that. But the bit which gets the prize is the white font in the compiler console output, which magically is fully visible when you run Cube over a remote desktop connection :)
-
My 2 cents:
The tool is buggy, no question. I would not say it is a total piece of s**t either. Has some problems, but for hobby, if you want to start a little bit faster, without having to type 5000 lines, is ok.
Not all tools by vendors are crap. Codewarrior was very good. Have used both the free and payed version professionally, and I had good experience. At least with (relatively) small microcontrollers.
I used CUBE for a couple of projects, the integration was FreeRTOS and filesystems was just few clicks, all the work done. I would use it anytime I had a similar project at hand.
Like any other tool, serves some purposes, depending what you want may work better or worst.
-
My 2 cents:
The tool is buggy, no question. I would not say it is a total piece of s**t either. Has some problems, but for hobby, if you want to start a little bit faster, without having to type 5000 lines, is ok.
But you don't need to type 5000 lines! Beginners using Cube and other shitty code generators is the problem because these tools generate hundreds of lines of code to do something that really requires five. So now you think it's doing great job saving the hassle, while it's only creating a problem and then "solving" it.
An LED blinker is approx. 10 lines of code, bare metal (ignoring startup code and interrupt vector table), in one C file.
A UART "hello world" is 10 lines more.
-
But you don't need to type 5000 lines! Beginners using Cube and other shitty code generators is the problem because these tools generate hundreds of lines of code to do something that really requires five.
^^^^ THIS.
People look at the code generated by the frameworks and think that this is the actual amount of code needed.
In reality UART initialization though the registers takes fewer lines than filling out initialization structure/parameters for the library call. So you have not done anything useful yet and have more code than an actual solution.
-
My experience was I had to make a lawnmower robot in 1 month. I came back to programming microcontrollers after 5 years of no touching anything...
I had many IIC sensors, UART, USB, had to support low power modes, I had to make signal processing (some FIR and IIR filters) and 2 PID controllers; so I had to use DMA for the communications if I did not want to loose time.
Also had to control 3 BLDCs, including overcurrent protection.
Requirement was to have an operating system running, so it was modular with tasks (customer requirement).
In the middle of the project I had to make me an "Oscilloscope" -- long history. I did it with the USB and ADC of the controller. Took like 1/2 hour to make.
Now should I have started bare metal, MAYBE I could have made it in 6 months?. Alone reading the manual for the low power modes and clock generation would take me couple of days.
I got it running in 2 weeks (first prototype), and working correctly after another couple of weeks. For me it would have been impossible to do all without the help of CUBE.
Yes for a blinker, maybe not good. Maybe for a professional product, also no good. But for some small projects like mine, it was a big accelerator! Just my experience.
As I said, it depends on experience, ability, and project needs. I understand it may not be good for you.
-
As I repeatedly say, even if you want to use the HAL with STM32 (especially if you're beginning with them), just browse the example projects provided with the SDK instead of using Cube. It'll get you there in a short time without having to deal with code generators further "hiding" what you need to know.
Now of course if you directly want to go "bare" without the HAL, read the manuals. But still, example code with be handy, because there's quite a number of things to know when you start (configuring clocks, understanding the clock tree, and so on...)
-
Another good option for hobby projects is Segger Embedded Studio. It runs on Windows/MacOS/Linux and is free for non-commercial use. It's much faster than any Eclipse-based IDE.
The only caveat is that it only supports J-link. That's not a problem for most Nucleo and Discovery boards as you can reflash the ST-LINK firmware on the board with J-Link firmware.
https://www.segger.com/products/debug-probes/j-link/models/other-j-links/st-link-on-board/ (https://www.segger.com/products/debug-probes/j-link/models/other-j-links/st-link-on-board/)
-
Another good option for hobby projects is Segger Embedded Studio. It runs on Windows/MacOS/Linux and is free for non-commercial use. It's much faster than any Eclipse-based IDE.
The only caveat is that it only supports J-link. That's not a problem for most Nucleo and Discovery boards as you can reflash the ST-LINK firmware on the board with J-Link firmware.
https://www.segger.com/products/debug-probes/j-link/models/other-j-links/st-link-on-board/ (https://www.segger.com/products/debug-probes/j-link/models/other-j-links/st-link-on-board/)
I'm a big fan of the Segger ecosystem. A J-Link EDU + SES is a good combination for hobbyist work and I find SES works for me way better than any Eclipse based solution. Another option is CMake+some editor/IDE like VS Code or CLion but I find this is a bit harder to jumpstart the first time around.
-
Whatever tool you use, there is absolutely no excuse to not use source control. Thanks to modern systems like Git, its even easy to do source control local to your own working directory. Heck, I'll even use it for scratch projects that don't get checked in anywhere. Its an invaluable tool for tracking what changed from one moment to the next, whether the change was done by you or by some tool. Think of it like an "undo history" that lives beyond your current IDE/editor session.
The only acceptable excuse for not using source control, IMHO, is because you don't understand how. But that really just means you need to learn.
(Anyways, I've been using STM32CubeIDE and haven't really had any showstopper problems with it. I have noticed that oddity with the debugger opening a random file, but that's the only one I regularly run into.)
-
I last used source control many years ago. My main issue is having a futureproof development environment, which I can understand and is self-documenting, because I often have to revisit a project after many years. And running everything in a VM (and archiving the VM) is a tacky option, which I reserve for old software and such.
Yesterday I managed to trash my project, seconds after I backed it up. It was done by copying the project directory to a network drive, as I do now at least daily. Except instead of Copy I did Cut ;)
And I saw all the open files, and everything else in Cube, disappear, over a few seconds :)
Getting it back wasn't easy, because Cube stores some config under the project and some under c:\st (or whatever, under Configuration). And as Cube sees files disappear (due to external action) it reconfigures itself accordingly. I had to retrieve the \st directory from a machine at the office, which had an older copy of the sources I am working on. The reason was that the \st directory got trashed as the files disappeared from Cube, even though I never touched anything in \st.
Then I got it all back but the project file hierarchy (on the left) was all one level. I eventually found that doing a reindex / clean / build restored things. But I lost the debugger configs.... That took a bit longer.
A stupid mistake... Took an hour to get it all back. I'd like to know how this can be prevented, with an app which stores its config all over the machine.
I have a 3am auto backup of the project anyway, but that currently gets overwritten each time.
Obviously backup up a project while Cube is running is a less than great idea, but it does normally work. Except that you aren't backing up the "whole project".
Coming back to the randomly appearing open files, this clearly exists and has done for ages, which shows the arrogance of the people who developed this thing. If this was my business. I would fix such obvious stuff right away.
-
It'd drive me up the wall not having version control, I use it to find where I've gone wrong all the time.
-
@peter-h To me it seems you are inventing issues not known by others, and then waste time bravely battling them.
I advice investing a week into fixing the toolchain and workplace into something stable, even sth like vsc+c|make-whatever+integrating it with code generation from Cube, if you insist on that. I bet the investment will return in less than half a year.
And apart from that do git (or something) course. Put a repository on your network drive and forget the ctrlc/v crap.
Few years ago I sat with 61 years old coworker; he was doing "version control" by manually copying project trees into catalogues with timestamp, manually, all his life. I gave him some git gui client and managed to teach him that in half a day, he was gasping in awe when he saw diff tool. So really, no excuses here.
-
Yesterday I managed to trash my project
I'd be tempted to do some victim blaming, but I'll abstain and instead reiterate what was said above:
Use a version control system. (Ctr-C Ctrl-V ain't one)
You can learn git (others VCSes exist, but git is the most commonly used and has great support in all decent IDEs) from the book (https://git-scm.com/book/en/v2) or in more gamified way (https://ohmygit.org/) if you are so inclined.
I'm sure tons of other tutorials exists, for any taste - these are a bit the two extremes (but the game makes you use real commands, if you want to, being based on an actual git installation!).
Git is in a nutshell an application to manage (directed acyclic) graphs where each node is a commit (a picture of the repository at a specific moment in time) - once that is understood the "advanced" concepts like branching, merging and rebasing are easier to grasp.
Even in an extremely basic usage pattern (just periodically committing on a single history line) it helps immensely.
It's easy to revert a bad change or an experiment, globally or at the single file level.
The integration in VS C (plus Gitgraph or Gitlens extensions) is simple to use even for a git novice.
Using a remote repo of some sort will make you safe from the kind of disaster you've just experienced, but even without it, it's very difficult to hose a local repo, unless one starts poking where they shouldn't.
There are many service that offer free, private repository (Github, Gitlab etc.), or you can set up your own server (Gitlab CE, Gitea etc.) or just use another local directory in a pinch.
-
Using a remote repo of some sort will make you safe from the kind of disaster you've just experienced, but even without it, it's very difficult to hose a local repo, unless one starts poking where they shouldn't.
There are many service that offer free, private repository (Github, Gitlab etc.), or you can set up your own server (Gitlab CE, Gitea etc.) or just use another local directory in a pinch.
The best part about systems like Git, as opposed to the older version control systems (SVN, CVS, etc) is that you don't even need to setup a server to use it. You can get many of the advantages entirely within the confines of your local working directory. It makes it easy to use even in cases where you'd normally never even bother setting up a hosting solution.
(Heck, I even use it on the local output of CubeMX-generated code dumps just as an easy way of tracking the relationship between project settings and generated code.)
-
Git is like these stupid TV ads, "Git has saved my live", "I'm a new person after meeting Git", "There's never enough git"", with a difference: it's not BS!
I remember those moments when I had changed something, somewhere, and it no longer compiled, throwing a strange error that didn't identify the offending line of code.
*Deep breathing*... What the *** did I *** up? I had to read every damn line of code with a magnifying glass.
Usually something hard to catch, like a dot, space, dash, bracket... And lost 2 hours of my life with a such dump thing.
STM32 IDE has some bugs, but once you get used to it, it's pretty nice.
I don't know what skills are you having, by but no way you can code by hand all the initialization code faster than cubeMX.
After learning how to use it, the configuration takes minutes. Set up all the gpios, pullups, input, outputs, dma channels, spi peripheral, enable interrupts, change priorities...
And you're ready to start you app. Of course, it takes a lot of time to know everything because the documentation is inexistent.
I hated it so much at the beginning! Now, knowing the typical issues and how to fight them, it works really well.
-
cp * ./backup2021_08_01
works almost acceptably for a single-developer project as long as you remember to do that every day or so. You can always diff.
... But why do it that way since git does not require any more work, and basic usage (init, add, commit, checkout, diff, log, push, pull) is learnt in a few hours.
So just use git for anything fancier than a quick led blinker test.
-
After learning how to use it, the configuration takes minutes. Set up all the gpios, pullups, input, outputs, dma channels, spi peripheral, enable interrupts, change priorities...
I don't really understand this. None of this takes more than a few minutes, completely irrelevant in the large scale of things. The only exception is when dealing with some non-trivial configuration - requiring extensive and careful reference manual reading, reverse-engineering and testing - which has high chances of Cube and/or HAL being totally unable to deliver such code at all.
You need code generator to change interrupt priority because it's otherwise so time consuming?
How about writing:
NVIC_SetPriority(TIM2_IRQn, 5);
Really, if you struggle to do that to the point of requiring a point&click interface, how can you program at all? Sorry, I just don't understand, can you elaborate? Or is the Cube generating 420 lines of code to do that, as well, so you think it must be hard?
Enabling interrupts? So each time you need to enable/disable interrupt you click through the GUI, get some chunk of code, and then copy-paste it (or let the GUI insert it where you need it) in the suitable place in your program code, instead of just writing
NVIC_EnableIRQ(TIM2_IRQn);
Sorry but I just see this as a horrible waste of time.
-
That's a valid point, and you need to do that before committing to PCB design. I have been hit once by an STM32 where I simply was unable to use DMA where that would have been very beneficial and my original plan, because the stupid DMA channel mapping limitations (can't use DMA for two specific peripherals at the same time). Looking at the DMA mapping list of the manual would have solved it in 1 minute, but I wasn't that experienced with STM32 back them, I assumed you can arbitrarily map DMAs (like you now can in H7 devices) without looking it up. Cube would have revealed this, as well; Cube did not exist, I was fighting against different piece of crap tools back then. Now people who said they can't live without them don't remember those ever existed. Remember CooCox?
I would be very satisfied with just a very simple UI where I click which peripheral combinations I need, when I need to use DMA and so, and it would just print out "possible" or "impossible"; maybe list me the AltFunc numbers and DMA Channel numbers to save me the (IMHO, relatively small) task of looking them up from the manuals.
Doing that manually for a more complex project takes a few hours after all, still insignificant for projects than run for months to years.
Oh, that should be Javascript on the vendor's website.
Basically, a product selector that does not lie; one that takes into account the combinations I need. You don't need a code generator, you need a product selector which would have the advantage of being able to suggest different devices instead of you iteratively starting a project for some chip you think might be able to do the job.
But you need to understand, this has absolutely nothing to do with software, it's purely a problem of hardware design; design software can help solve it, but you don't need the generated code for that pattern to be useful. But having code generated kind of locks you in because these tools are notorious for bloating the code so it makes you feel like it did save you a lot of job; a typical 5-LoC operation becoming 50 or 100 LoC.
I always hand-calculate the PLL settings, it's elementary school math involving 1-3 multiplications and maybe 4-5 divisions, does not take "half a day", but maybe you can save 15 minutes by installing and "learning to use" a tool, working around bugs thereof? Does it ever pay back the invested time?
Complex C APIs where you cant remember which argument is which and then solve it with an IDE, and curse about the IDE being unable to help after all, that's a completely made-up problem. Microcontroller peripherals are simple, write simple abstractions, refuse to use crappy ones!
-
Another observation is about the wrong and unrealistic expectations people develop from marketing and ads. You know that in ads children are clean and friendly, the dog stays in its corner etc. If you never worked with STM32, you cannot expect a nucleo board arrive from Digikey in the morning and your project finished in the evening of the same day. Although some youtube videos may give you that impression, that is complete nonsense. You will have to register on web sites, find downloads, install them, try different tools, read some example code, read some forum threads.
Like olympic competitions: Besides lot's of exercise you may also need some coffee as doping. Take your time and learn! I think STM32 is fairly mainstream and the effort won't be wasted. In the end the Arm infrastructure is common to other brands.
Regards, Dieter
-
Another observation is about the wrong and unrealistic expectations people develop from marketing and ads. You know that in ads children are clean and friendly, the dog stays in its corner etc. If you never worked with STM32, you cannot expect a nucleo board arrive from Digikey in the morning and your project finished in the evening of the same day.
Exactly this. I stop with reacting in topics who have such a negative statement in them.
My personal experience with people who have big trouble with embedded systems categorie:
-HW engineers without much programming experience
-SW engineers without much embedded experience, (the malloc 1GB people)
- princes and princesses of the 2000+ Born generations that have been pampered by their parents, whose school assignments even if they sucked where "fantastic !" and have a perserverance to solve a problem on their own of almost zero.
If you can't get a led to blink on a Nucleo board with ST Cube within one or max two days even with the st forum help Embedded SW is probably not for you.
That said if you are a (small) business only use Cube as fast start up, rewrite critical HAL parts for yourself and create your own infrastructure. Don't expect a project that compiled, build an finished two years ago to do the same today ;)
-
"-HW engineers without much programming experience"
That's why I am here asking questions :)
-
Then I would recommend to pose open questions and prepare to put in some serious effort. As said many times before on this forum since 2010 at least, 8 bit micros are relatively easy to understand and comprehend for HW engineers, datasheets are few hundred pages and registers for peripherals are easily programmed.
32 bit Arm based uCs different breed and datasheets are scattered over the core manufacturer (Arm) and the integrator, who all use their own peripherals with their own quirks, ST for the STM32. Multiple hundreds and hundreds of pages of datasheet (AND errata!) and it just takes time to investigate step by step how to use such a device.
-
"-HW engineers without much programming experience"
That's why I am here asking questions :)
I recommend you go through one of the full cortex m courses or books. I recommend you understand the build system and linker before you start shipping anything to customers.
Do you understand how the stack works? Do you know how to avoid Malloc. How do you setup freertos? What's the difference between the PSP and the MSP. What happens when you pass note than four arguments to a function on cortex m?
All of these questions you should know the answer to before anything goes out the door. You will get weird/intermittent bugs especially if you don't have -Wall on and having the confidence to debug any problem is key.
-
" prepare to put in some serious effort."
Been doing a number of hours a day.
Today was spent on reading files (FatFS), CRC checking, and writing them into a serial FLASH (Adesto 45DBxx). Got that running nicely now. Even got flashing lights when doing it :)
"Do you understand how the stack works? "
Done megabytes of assembler since c. 1980 (see list in sig) so I think I do :)
"Do you know how to avoid Malloc. "
Wouldn't touch malloc() with a 20ft bargepole, in an embedded system.
"How do you setup freertos? "
Have had the system running with FreeRTOS for about 6 months. Rock solid.
"What's the difference between the PSP and the MSP. "
No idea.
"What happens when you pass note than four arguments to a function on cortex m?"
Hmmm, it loads the first ones in registers and the rest go on the stack? It would be obvious when watching the asm listing during single stepping, as I often do.
The questions I am posting here are on quite specific areas. One cannot learn about how good some IDE is by reading the website, because they all say theirs is a fantastic tool for modern software artisans ;)
Based on what I hear and see I think I will stay with Cube IDE :)
As regards version control, the last one I used was Polymake (PVCS), in the 1980s. I am sure they have moved on.
-
I'm sure that an experienced professional, such as Siwastaja, can do the job much faster and much better without Cube. Of course, he wasn't born that way. He spent some time at school. The, I guess he did many projects with various CPUs, made many mistakes, learned from them, and gradually became competent. And even now he continues to learn, and isgetting better and better. But this takes time.
Things like Cube are designed to "help" inexperience people to do the job without becoming competent. The result may be somewhat ugly, but there's no way for the incompetent people to judge. The Cube generated code may be 10x or 20x times bigger than the code written without Cube, and consequently would have more bugs and would be much more difficult to work with. It's also likely to be less efficient and not targeted to the specific situation. But they don't care. Funny, but at the same time they want their CPU to be faster and more efficient and they want super-optimizing C compilers.
"But I was thinking of a plan
To dye one’s whiskers green,
And always use so large a fan
That they could not be seen."
But here's the rub. IMHO, for incompetent people the best solution is to learn and become competent. This is common sense. Why in the world would you use a tool which is designed to prevent you from becoming competent?
-
As regards version control, the last one I used was Polymake (PVCS), in the 1980s. I am sure they have moved on.
Please do yourself a big favour and start using Git. I know it is another piece of complexity and learning curve but being able to go back to a working version or just check what you have changed between versions is great. Cube IDE should have integration with Git (or it should be possible to install it from the Eclipse repository). And Git also supports binary files (AFAIK Git treats any file as a binary file anyway) so you can add external libraries / binaries to your project and have them under version control as well. This makes using externally compiled binaries (think FPGA image or bootloader for example) much easier; you are always sure you have the right version together with your project.
I'm also using Git to keep track of software packages I send to customers in binary form.
-
I'm sure that an experienced professional, such as Siwastaja, can do the job much faster and much better without Cube. Of course, he wasn't born that way. He spent some time at school. The, I guess he did many projects with various CPUs, made many mistakes, learned from them, and gradually became competent. And even now he continues to learn, and isgetting better and better. But this takes time.
Thanks but I'm younger and less experienced than you might think. I still clearly remember the time I was beginner with microcontrollers so I can relate. Yes, jumping to ARM took time due to one silly bug in the stupid tutorial I was following, but if I had a non-broken linker script as an example, the time consumption would have been totally manageable, not too many hours actually.
And of course, microcontroller-based product design / firmware design&implementation is not taught (properly) at school anyway. My major was "computer engineering" so around FPGAs and some ASIC design etc. MCUs are from hobby basis originally.
The point is,
* Crappy tools like Cube waste your time and limit your abilities long term - this is quite agreeable I think, no?
* But I would go further and say - they don't save enough time short term either, to be worth the long-term cost, no matter what coeffs you put for importance of short term vs. long term as long as it's something more sane than 100%-0%.
My statement is, the sole reason beginners have to resort to such tedious, crappy and time-consuming broken workflows like Cube and ST HAL, is the utter lack of proper examples and tutorials guiding beginners, or if they exist, they are damn hard to find.
I often play with the idea of writing such tutorials but it requires a lot of time to do properly - I don't want to be part of the problem -, and I have enough to do already.
Classic principles of abstraction work really well on this problem. For example, I have a simple one-liner I can use to configure an IO pin as an alternative function, and set the AF number, instead of having to remember the register names and correct bit shift distances for the two registers involved. Coming up with such simple solutions does not take a lot of time, but saves it a lot long-term.
-
But here's the rub. IMHO, for incompetent people the best solution is to learn and become competent. This is common sense. Why in the world would you use a tool which is designed to prevent you from becoming competent?
But what if people can't reach the competence level required to do without code generation tools and hardware abstraction libraries? And what if people are not willing to learn not to use such tools? The answer to 'what it the simplest solution?' will depend entirely on the person you are asking the question to and many different answers will be right. There is no black or white / right or wrong here.
And is ST's HAL really that bad? I looked at it a couple of years ago and the code looks reasonable and seems to be MISRA compliant indeed. For sure there will be bugs and it is more bloated due to needing more flexibility but IMHO that doesn't make it a complete non-starter. Why would you write a UART driver if you have a piece of code which already does that for you in a way which is suitable for the project? Not wanting to use the HAL out of elitist thinking / not-invented-here syndrome doesn't seem sensible to me in terms of spending time efficiently. Especially given the wide variety of peripherals ST is using in their microcontrollers at least the HAL gives you some portability.
-
My statement is, the sole reason beginners have to resort to such tedious, crappy and time-consuming broken workflows like Cube and ST HAL, is the utter lack of proper examples and tutorials guiding beginners, or if they exist, they are damn hard to find.
I often play with the idea of writing such tutorials but it requires a lot of time to do properly - I don't want to be part of the problem -, and I have enough to do already.
You hit the nail on the head. There isn't anything that can compare to having good examples that work. It is so simple to take a working example, figure out the details of it, and modify it to your own needs. If a manufacturer spent the time to give us those kinds of examples, rather than on making flawed auto configurators, etc., many of us would be much better off.
-
And is ST's HAL really that bad? I looked at it a couple of years ago and the code looks reasonable...
It's not that bad per se (at least compared to the horrible former ST style copy-paste struct initialization pattern offering no abstraction at all). HAL just offers poor abstractions and forces patterns that are suitable for general purpose desktop computing over an operating system but on a microcontroller, just reduce flexibility, add another layer of extra work (because normally you need to go into the low level code inside the HAL anyway), without offering any significant upsides.
It's enough to have properly documented peripherals with working examples for the most common use cases, instead of poorly documented peripherals with one typical use case hidden inside the HAL implementation. This is exactly what AVR, PIC and similar did for decades, no problem even for a beginner. And usage of most peripherals on STM32 is same complexity as on AVR or PIC, really - typically 5 lines of code.
And this is the opposite of being elitist.
-
And is ST's HAL really that bad? I looked at it a couple of years ago and the code looks reasonable...
It's not that bad per se (at least compared to the horrible former ST style copy-paste struct initialization pattern offering no abstraction at all). HAL just offers poor abstractions and forces patterns that are suitable for general purpose desktop computing over an operating system but on a microcontroller, just reduce flexibility, add another layer of extra work (because normally you need to go into the low level code inside the HAL anyway), without offering any significant upsides.
Not everybody sees it that way. Over the years I've come across enough embedded software engineers who strongly prefer a library like ST's HAL over programming bare metal. And they do come up with software that meets the design goals.
-
CMIIW but AFAIK the Cubes implementation is so relatively more "bloated" because it has to support ALL STM32 microcontrollers, which mean M3,M4, etc. And even the peripherals from the STMF1xx are not the same as on the newer STMF4xx which also has a newer Arm core etc. Etc. Than it also supports the HW prototype nucleo boards.
If you as many hobbieists or small companies only use one specific family of the STM32 uCs you can optimize the bloated generated code varily easy, adapt it to your wishes and so make your own libraries.
But even experienced Emb SW eng. from scratch program the HAL for themselves for all peripherals even for a single uC? Probably a few months incl. debug and get it operating to satisfaction.
Most hobbieist with their own stack only support 40% of what the peripherals can do and probaly satisfies everything they want to do with it.
ST does not have that luxury, they need something for all possible usages of the peripherals in combination with all their devices.
This means abstraction layer on abstraction layer which makes it bloated.
That in it self is already a miracle they have something and it also most of the time works ;)
-
You hit the nail on the head. There isn't anything that can compare to having good examples that work. It is so simple to take a working example, figure out the details of it, and modify it to your own needs. If a manufacturer spent the time to give us those kinds of examples, rather than on making flawed auto configurators, etc., many of us would be much better off.
As you program more and more, you have more and more code. If you face something you've done before, you can just copy your old code and modify it as needed. That's the same as missing examples.
I found that copying your earlier code and modifying it for the task often works better than libraries which try to be a master-of-all-trades.
-
Why would you write a UART driver if you have a piece of code which already does that for you in a way which is suitable for the project?
Because it's just few lines of code. It's easier to write than to figure out whether the code written by someone else is suitable for your project. Besides, hardware modules typically have much better documentation than libraries. So, you'll save some time too.
-
Why would you write a UART driver if you have a piece of code which already does that for you in a way which is suitable for the project?
Because it's just few lines of code. It's easier to write than to figure out whether the code written by someone else is suitable for your project. Besides, hardware modules typically have much better documentation than libraries. So, you'll save some time too.
You say it is a few lines of code but that isn't the case when you throw in DMA, software FIFO buffers and interrupts (the latter basically means it has to be thread safe). It can get hairy pretty quick especially if the UART supports an internal FIFO as well. Not every programmer has code like this lying around.
-
And is ST's HAL really that bad? I looked at it a couple of years ago and the code looks reasonable...
It's not that bad per se (at least compared to the horrible former ST style copy-paste struct initialization pattern offering no abstraction at all). HAL just offers poor abstractions and forces patterns that are suitable for general purpose desktop computing over an operating system but on a microcontroller, just reduce flexibility, add another layer of extra work (because normally you need to go into the low level code inside the HAL anyway), without offering any significant upsides.
Not everybody sees it that way. Over the years I've come across enough embedded software engineers who strongly prefer a library like ST's HAL over programming bare metal. And they do come up with software that meets the design goals.
To be honest, I have done baremetal on a lot of MCUs, but I've always used the HAL on STM32 ones. Of course, sometimes I'll write additional functions tailored to my needs when the HAL ones are not efficient enough - but I admit that's just a few in a given project. On example would be using DMA: most peripheral drivers come with a DMA version for transfering data, and it works, but is pretty inefficient if execution time is critical, as they usually reconfigure the DMA channel every time you call them, whereas configuring it separately would be much more efficient. That's one example for which I sometimes write my own functions.
Using vendors' libraries has pros and cons of course.
Pros are not just saving time; it usually allows porting to a different MCU from the same vendor a breeze with rare exceptions.
As I mentioned in another thread, the STM32 HAL may look bloated, but obviously functions must cover as many cases as possible. That's the obvious price to pay. They also use a style that one may not like, but that mainly comes from the fact it's MISRA-C compliant.
Now I'm not advocating one way or another. It all depends on your goals, available time, coding rules you may have to comply with, and so on...
-
This discussion contains very strange statements. The capability to understand and make use of the work other engineers have done before should never be called incompetence. It is something valuable that needs training and experience, too. You cannot always work alone and start from scratch.
Regards, Dieter
-
You say it is a few lines of code but that isn't the case when you throw in DMA, software FIFO buffers and interrupts (the latter basically means it has to be thread safe). It can get hairy pretty quick especially if the UART supports an internal FIFO as well. Not every programmer has code like this lying around.
You may use DMA, or you may not use DMA. You may use interrupts or you may not use interrupts. You can use different kinds of buffering or none at all. You may split your processing between interrupts and "main" code in different ways. You may use RTOS or you may not. Now, try to write code which covers all the cases. This will be very complex code which is very hard to deal with. Or you can omit most of the cases and provide something very limited. Take your pick. That's the situation library writers are in - they don't know how their code will be used, so they unavoidably make it either too complex or too restrictive. They're not magicians and cannot write good code without knowing the task.
I like to write specific code, tailored to the task. It makes things much easier and straightforward. Just so happened that yesterday I needed a circular buffer which was, sort of, unusual - one writer but two independent readers. Not related to UART, but a FIFO anyway. Took me 20 minutes, 45 lines (including some data processing). Worked from the second run. Is it really worth digging into libraries for the code that small?
-
This discussion contains very strange statements. The capability to understand and make use of the work other engineers have done before should never be called incompetence. It is something valuable that needs training and experience, too. You cannot always work alone and start from scratch.
That's the other way around. Incompetence is not an ability. Incompetence is inability. Like inability to understand forces people to guess. Or inability to write code forces someone to use code written by others.
-
Start using git. "git diff" will tell you right away what has changed. And, yes, IDE editors are pretty poor - the only reason to use IDEs in the first place is indexing and debugger integration. If emacs had a better indexing system than etags I'd probably never touch IDEs at all; personally find it much easier to work with Makefiles than 100s of settings pages to find where, for example, you set a linker option or linker command file.
-
To be honest, I have done baremetal on a lot of MCUs, but I've always used the HAL on STM32 ones. Of course, sometimes I'll write additional functions tailored to my needs when the HAL ones are not efficient enough - but I admit that's just a few in a given project. On example would be using DMA: most peripheral drivers come with a DMA version for transfering data, and it works, but is pretty inefficient if execution time is critical, as they usually reconfigure the DMA channel every time you call them, whereas configuring it separately would be much more efficient. That's one example for which I sometimes write my own functions.
Using vendors' libraries has pros and cons of course.
Pros are not just saving time; it usually allows porting to a different MCU from the same vendor a breeze with rare exceptions.
As I mentioned in another thread, the STM32 HAL may look bloated, but obviously functions must cover as many cases as possible. That's the obvious price to pay. They also use a style that one may not like, but that mainly comes from the fact it's MISRA-C compliant.
Now I'm not advocating one way or another. It all depends on your goals, available time, coding rules you may have to comply with, and so on...
For me, I have a fairly limited number of customers, and the projects they need are generally the same general types over and over again. Meaning there's lots and lots of functions that I use over and over again. So things like UART interfaces, with similar usage, ADC and DAC used in similar ways, etc. Also, there's a variety of different MCUs I use, but it's not huge. Once in a while I need to design for a new MCU because I inherit an existing project for which just minor changes are needed, but if there's a major overhaul, I'll specify that the MCU be changed to one in my normal repertoire. Given this sort of usage, it ends up being very worthwhile for me to completely skip the vendor's libraries as much as possible/practical.
If my projects were all over the map, and using all sorts of different MCUs, there's more chances that using the vendor's libraries could save time and be of an advantage in more cases. But given my usage, it makes much more sense to me to develop my own "libraries", which are just a common way of designing/calling these functions I use again and again. At the core is code which contains no bloat, because I've tailored it to my specific usage.
So I think it really depends on the skill and experience level of each firmware engineer plus their usage as to how much/little they use the vendor's libraries. As time goes by and I gain more experience, I see less and less of an advantage for using vendor's libraries. Even if it takes a bit more time initially, I learn that again and again I save a lot of time and headaches in the long run by having as much as possible of the code being my own.
-
A lot of truth written above, but there is a spectrum and different people are in different places.
For example I am a businessman first (it is my business) and my #1 job is to look after the business. So in product development I have to "pick my battles" and do stuff which will work and crucially which can be done in a futureproof way so I can revisit a job in 10 years' time. Even if I have help now, I can be sure I will be working on it alone by then.
But if I was working for somebody else's company, I don't need to care much. I can spend a week learning some new tool. It will cost my employer 1000 quid while I am playing with that, but I don't need to care. I don't need to document anything, and actually that improves my job security (in the short term, anyway). One sees this in web (server side software) development where a new tool, worthy of a 1000 page manual, comes out every week. No doubt produced by a bright young lad who doesn't have a girlfriend so he can be incredibly productive. That tool will be forgotten in 10 years' time. Try to get somebody to work on Ruby on Rails; it may as well be Cobol/66.
"It's enough to have properly documented peripherals with working examples for the most common use cases, instead of poorly documented peripherals with one typical use case hidden inside the HAL implementation. This is exactly what AVR, PIC and similar did for decades, no problem even for a beginner. And usage of most peripherals on STM32 is same complexity as on AVR or PIC, really - typically 5 lines of code."
I agree 100%. I have just spent a few hours trying to work out, from the RM, how to set up UART1 for 9600,8,n,1, polled. This is just for debugs very early on after startup when there are no interrupts and I can't call the ST libs because this is a boot loader. I reckon it could be done in 10 lines, but setting up the pins (the various alternate function options) so the UART TX and RX actually come out is a lot more complicated; I reckon at least a day's reading and trial and error. I gave up and found another way. Rather than a bloated code generator, ST should have offered code examples, for each peripheral.
Well, it is more complicated because of inter-dependencies like clock configs, alternate functions, half the UARTs/SPIs/whatever are not usable because the pins are used for other stuff. Setting up that sort of stuff is a great use for a GUI.
-
A procedure that i remember was generating my own code examples using the CUBE framework just to extract some essential components i wanted. This may help with the "cannot use ST library for boot loader" part.
With the durability part i agree you have to write some kind of work log since GIT will not tell you the reasoning of changes. Even with notes it can be surprisingly difficult to understand the work oneself has done before (e.g. two years ago).
Regards, Dieter
-
For example I am a businessman first (it is my business) and my #1 job is to look after the business. So in product development I have to "pick my battles" and do stuff which will work and crucially which can be done in a futureproof way so I can revisit a job in 10 years' time. Even if I have help now, I can be sure I will be working on it alone by then.
If you're serious about this then there is only one way: Linux and Arm compiler and only license free software packages.
Windows, IDEs, VMs, cloud based solution, software that needs a license, they are all not 10 year proof and I have experienced that in my previous company multiple times.
In that case forget about Cube unless you create your product with it and then store the bare C code, but do not think in ten years you can start it up, change some I/O pins through the IDE and recompile, that is not going to work, probably not even in three years.
-
Windows is not that bad, and I am still running some 1990s software in a winXP VM without any problems.
Indeed; I would never use any software which uses online license checking. That is a disaster looking for a time to happen.
-
Windows is not that bad, and I am still running some 1990s software in a winXP VM without any problems.
Indeed; I would never use any software which uses online license checking. That is a disaster looking for a time to happen.
The problem is not that a license expires but that you can't move a license to a new PC. This is the reason that I only use software which is either 'free' or for which a hack is available so I don't have to depend on the supplier to continue using software that I have paid for.
-
A short example of Cube's code "quality" that hit my eye right at the start, a piece of startup.s (comments under // are mine):
* @author MCD Application Team
...
/* Copy the data segment initializers from flash to SRAM */
movs r1, #0
b LoopCopyDataInit
CopyDataInit:
ldr r3, =_sidata //mem read
ldr r3, [r3, r1] //mem read
str r3, [r0, r1] //mem write
adds r1, r1, #4
LoopCopyDataInit:
ldr r0, =_sdata //mem read
ldr r3, =_edata //mem read
adds r2, r0, r1
cmp r2, r3
bcc CopyDataInit
- each loop iteration does 3 useless mem accesses for each 2 useful (+both additions could be replaced by post-indexing) :palm:
There is no universal purpose in this, it just was written by an ARM beginner, "For gamers by gamers" (Interplay's old times motto).
(keeping the asm startup tradition on Cortex-M designed to start right to C code is another question)
-
Well, almost nobody knows assembler these days, and much promotion is based on "you can do this all in C" so no wonder the startup .s code is not optimal.
You could never do this with say a Z80, but a 32F417 running at 168MHz does most things "instantly". It's the old story about 95% of the time spent in 5% of the code, and it certainly isn't spent in startup.
-
You get those libraries for free including source. If you think you can do better and it matters for your application, edit the source, no problem. Or try other optimization settings of your compiler. I know that IAR optimizes to a degree that you can no longer debug in a meaningful way - i mean if you want that.
Regards, Dieter
-
That code is from startup_stm32f407xx.s, optimization settings wouldn't affect it. And the question is not "should we say thanks to ST or tar&feather them", just saying that code looks like written by a beginner.
-
If it's an assembly file, edit the source. If it's a C file, you can try the optimization settings first. If that doesn't help, edit the source.
Your conclusion about beginner work requires benchmarking alternative solutions. Those MCUs are complex enough to falsify simple assumptions which code will run faster.
I remember very well my first encounters with Kinetis MCUs about ten years ago and software experiments to check instruction cache size, flash memory clock, peripheral clock etc. Of course for serious work you can't use that cheap/free stuff as a black box. You need to look at some details. The vendor provided examples and frameworks are meant to get you started.
Regards, Dieter
-
This discussion contains very strange statements. The capability to understand and make use of the work other engineers have done before should never be called incompetence. It is something valuable that needs training and experience, too. You cannot always work alone and start from scratch.
... a complete strawman argument which shows nothing else that you did not read or understand anything you seemingly commented about.
It's completely unfruitful reiterating it again and again because all the points have been made and if you can't understand it, then I don't know what to do. I'm just happy I don't need to work with you in my teams.
Enjoy your echo chamber, you'll have no lack of members.
(nctnico at least gets the idea that different viewpoints can exist, and coexist, and different people have different ways of working, which I'm thankful.)
-
You could spend half your day with the data sheep and alternate pin function mappings just picking pin mux settings.
You could spend the other half of your day looking at the AC specifications / PLL reference manual / clock generator documentation just figuring out the PLL / clock division settings for the more important peripherals.
Once the GUI tool helps you visualize the pinmux / pinout and clocking and pick settings yeah the API calls aren't that hard but do you really want to read the DS + architecture manual + reference manuals / user guides + application notes cross referencing 200 different scattered pages to know what a given $7 MCU variant is capable of?
Oh and what is the magic sequence needed to program / sequence various internal voltage / power domain / clock settings registers to switch from internal RC oscillator at 1 MHz to external crystal + PLL depending on the MHz you want to run at?
For a timer capture how / where do you control the edge polarity, what interrupt channel is that again?
There are too many details even for a single modern MCU part to manually deal with that all 2000 different relevant register settings / capabilities / sequencing / alternative assignments by manual documentation process.
What you're describing is lazy engineer syndrome. Why bother understanding the capabilities and settings for a particular MCU when you can let some automated tool take a stab at it? IMO, any embedded engineer doing commercial work should understand the intricacies of the components he's using in his designs and not rely on automated tools to do his thinking for him.
Relying on automated tools leads to less understanding of how things work and how they interrelate. What are you going to do, for example, if you're at a customer site one day trying to debug an issue in the autogenerated clock configuration code with an irate customer breathing down your neck? I've actually been in exactly this situation and was able to resolve the issue quickly and defuse the irate customer because I thoroughly understood the clock configuration code I wrote myself.
-
So you had an issue in the clock configuration you wrote yourself. This is a strange example. For a beginner it is much safer to rely on vendor provided framework. The STM32 libraries are pretty mature.
Regards, Dieter
-
So you had an issue in the clock configuration you wrote yourself. This is a strange example. For a beginner it is much safer to rely on vendor provided framework. The STM32 libraries are pretty mature.
Yes, it was in clock configuration code I wrote myself. The issue turned out to be an errata in the chip that was published by the vendor after I wrote my code. I fixed it by changing the ratio between the multipliers/dividers. The chip didn't support the full range as documented in the reference manual.
-
In this thread, a bit of confusion I think, though.
Do not confuse vendor *libraries* with IDEs and code-generation tools. Even if the latter can use said libraries themselves, they are two completely different things with two completely different ways of developing.
Vendor libraries usually do not abstract all that much, so for using them properly you still need to know the underlying peripherals, clocking resources, and so on. They do not promote not reading the docs. They do save you some time (usually), and make porting code to a different MCU from the same vendor easier, but that's pretty much it. They spare you knowing the exact registers and bit fields, but not knowing what can be configured and such.
For instance, you can't setup clocks using the STM32 HAL without knowing how clocks work on the MCU, what the parameters are, etc. So you still need to RTFM.
It's using the code generation tools that "abstract" all this a lot more, and will promote not reading manuals and ultimately not really knowing what you're doing. It may be OK for beginners, but using them for anything professional is NOT a good idea.
Now using vendor libraries is a different thing. You may have good reasons for using them, or not using them. But those wouldn't be the same reasons as with the above.
Another related difference is that vendor libraries almost all come with full source code. You can study it, modify it, rewrite it, or just read it to complement manuals when those are too vague about some setting. Code-generators usually do not come with source code. You have to blindly trust the vendor.
-
What you're describing is lazy engineer syndrome.
Wait, isn't laziness one of the engineer's three major virtues? ^-^
-
What you're describing is lazy engineer syndrome.
Wait, isn't laziness one of the engineer's three major virtues? ^-^
Well - it is, as long as you follow good practices of your particular field.
Problem is, we're talking about software here. Software is a slightly different beast, and whether it's really engineering per se is still questioned. There's been a LOT of talk about this, and very competent people who themselves claimed software development could not be called engineering. A lot to be said, and I guess, a good potential for flame wars. ;D
But taking the example of being lazy as in reusing components that are standard and proven instead of "reinventing the wheel" is a good one. Unfortunately, software reuse is, most often, very far from the equivalent of, say, using a standard screw in a mechanical design. Or using proven formulas for material strength. Etc. Yeah that opens a can of worms.
-
You could spend half your day with the data sheep and alternate pin function mappings just picking pin mux settings.
You could spend the other half of your day looking at the AC specifications / PLL reference manual / clock generator documentation just figuring out the PLL / clock division settings for the more important peripherals.
Once the GUI tool helps you visualize the pinmux / pinout and clocking and pick settings yeah the API calls aren't that hard but do you really want to read the DS + architecture manual + reference manuals / user guides + application notes cross referencing 200 different scattered pages to know what a given $7 MCU variant is capable of?
Oh and what is the magic sequence needed to program / sequence various internal voltage / power domain / clock settings registers to switch from internal RC oscillator at 1 MHz to external crystal + PLL depending on the MHz you want to run at?
For a timer capture how / where do you control the edge polarity, what interrupt channel is that again?
There are too many details even for a single modern MCU part to manually deal with that all 2000 different relevant register settings / capabilities / sequencing / alternative assignments by manual documentation process.
What you're describing is lazy engineer syndrome. Why bother understanding the capabilities and settings for a particular MCU when you can let some automated tool take a stab at it? IMO, any embedded engineer doing commercial work should understand the intricacies of the components he's using in his designs and not rely on automated tools to do his thinking for him.
Relying on automated tools leads to less understanding of how things work and how they interrelate. What are you going to do, for example, if you're at a customer site one day trying to debug an issue in the autogenerated clock configuration code with an irate customer breathing down your neck? I've actually been in exactly this situation and was able to resolve the issue quickly and defuse the irate customer because I thoroughly understood the clock configuration code I wrote myself.
Well... try that with a USB or network software stack. Or SSL/TLS, Lora, Wifi, LTE to name a few.
With the exact same reasoning you could also have updated the vendor provided library to a newer version which has a fix for the problem. And likely the vendor provided library you could have used already avoids the issue you missed to address in your own code. So that could have prevented your predicament from happening at all.
Nowadays you really have to manage what knowledge you need to acquire and what not. Some of the chips I work with have thousands of pages with documentation which -despite the sheer number of pages- isn't going into much detail. Acquiring full knowledge of all the inner workings within the time span of a project just isn't feasible. I have to rely on vendor provided software and patches in order to get these chips going. Fixing a problem by updating the vendor provided software is a much quicker path compared to fixing the problem myself (which I can't always avoid though).
-
Also note the huge difference between:
* Classic STM32 "Standard peripheral library".
This is now officially obsolete, good riddance. A few years ago we had the same fight on these forums about this, you were told you absolutely must use this horrible piece of crap otherwise you are "wasting time" and being generally stupid. Then ST made this obsolete overnight, now even Good People are not supposed to use this. This sudden attitude change (while technically nothing changed) is the testament of the cargo cult engineering attitudes, all driven by opinionated feelings, not facts.
But most of the STM32 examples online use this library. In reality, this library is an utter disaster, because it does not abstract anything at all, but only adds a layer of extra boilerplate for no benefits whatsoever. 1 LoC initialization becomes unwritable 20 LoC which is either copy-pasted or autogenerated, and you still need to know what every configuration bit does because they map almost 1:1 (but not exactly, for maximum confusion).
* STM32 HAL
What a horrible name. Protip: when coining a proper noun, just don't use the well-known name of the concept. For example, if you want to establish a grocery store, don't call it "Grocery store", communication will be difficult. Similarly, when coming up with a specific HAL library, don't call it HAL.
This naming thing out of the way, STM32 HAL makes perfect sense because it abstracts. It's successful in this regard, and no one questions that. That's really the argument to use it. Because it abstracts, it hides unnecessary burden from the programmer - in theory. Also because it abstracts, it can make code portable across different devices - in theory. Finally, because it abstracts, it saves time - in theory.
Now all that is left is to answer the questions:
* Which STM32 peripherals benefit from being abstracted to a linked library at all?
* Which STM32 peripherals benefit from having a manufacturer-implemented generic abstraction instead of rolling your own?
* What does "benefit" mean? Just time saving, or maybe performance, code size, maintainability? Being able to do what is needed at all?
* Is STM32 HAL well implemented?
* Is STM32 HAL really portable?
* Does STM32 HAL really save time in the big picture?
... and so on.
But people like dietert1 can not discuss such points, they can only come up with very simplistic strawmen and attack those in some one-liners. But this is unsurprising; if you don't have such thinking capabilities, being able to program will be difficult, too, and all that's left is to try random oneliners in the hope that they happen to work. HAL is agreeably great for that, and possibly even successful, assuming you never hit complex requirements but instead build "typical" projects for which the HAL was written and tested, like "replicating" devkit projects.
One of the stupidest strawmen arguments is "oh, why would you implement identical generic library yourself, you must be stupid". Of course you won't, if you think something sucks then obviously you won't replicate it, but do something different. In this case, designing a generic abstraction layer for something that have tens of thousands or millions of functional permutations, there are two approaches:
* Reduce the available functionality, i.e., artificial limitations on what you can do,
* Make the abstraction layer complex, difficult to use, and the implementation thereof difficult to write, bloated and slow, to support all available functionality.
In reality it's a mix of the two. Thankfully STM32 HAL emphasises the former, otherwise it would be even more bloated and not easy to use. (The SPL was an example of the latter.)
You can sidestep this issue completely when writing your own abstraction (or in simplest cases, not abstract at all) in per-project basis, and this is where the time saving lies. Maybe it takes 10 minutes to write UART init and simple TX/RX functions using the HAL, and maybe it took 1 week for ST to implement that part of the HAL. But this doesn't mean it takes 1 week to do it without their HAL, no, it takes like 20 minutes, completely insignificant.
Also no one's saying you shouldn't use libraries ever, at all. Don't write a TCP/IP stack. Use existing code or libraries when they actually save time and/or improve the code quality. This shouldn't be cargo cult engineering, we can do educated choices based on facts!
-
How does actually fit libopencm3 into this picture?
-
I last used source control many years ago. My main issue is having a futureproof development environment,
Use version control. Otherwise you will have gremlins like this, period.
It isn't worth anyone's time, least of all yours to answer questions like "my project used to build but doesn't now" if you don't have version control. I'm not sure what you mean by "futureproof development" but since everyone who does software development seriously or professionally uses version control the chances that you know something that they all don't is miniscule. You should literally do this before you write another line of code.
-
A framework like cube with its integration of all useful tools has merits. You get libraries with source, you get visual configuration and code generators that "know" about the hardware of many different devices and how to properly use the libraries, you get application examples, you get operating system components, you get the IDE (editor, compiler, debugger). As a whole this is something unseen in the past. The approach isn't at all specific to STM32. I remember using similar frameworks from other vendors like Microchip. Certainly at some point they will include GIT.
The framework supports working without the natural language reference manuals. Instead of reading English text, you will review library sources. And the IDE will point you to references and definitions very fast. The HAL contains a complete description of what is in the reference manual, i mean once you get used to its naming conventions. One can even say it represents all reference manuals of all STM32 devices.
I have been using cube many times and found it useful. Most users of the framework will do some code review and that's it. Others will say: Component x of the framework is not after my taste or not good enough, i will modify it or replace it by something else. As i wrote in my first comment i prefer the IAR IDE and it integrates well with cube. Also i remember adding time measurements and counters to certain HAL functions as realtime debugging support. Sometimes i have been adding natural language comments to the files. And i mentioned that you can extract source from self invented application examples that you setup with the framework, e.g. to make a special library for a boot loader. Heroes watch out: You may create a piece of buggy crap.
Regards, Dieter
-
"This is now officially obsolete, good riddance. A few years ago we had the same fight on these forums about this, you were told you absolutely must use this horrible piece of crap otherwise you are "wasting time" and being generally stupid. Then ST made this obsolete overnight, now even Good People are not supposed to use this."
Is this the libs which come with Cube IDE i.e. the HAL stuff?
-
No the Cube HAL is the successor.
The first gen ST peripheral libraries the interface functions differed per uC family which made it bothersome to say the least.
A sr SW eng spent three manmonths porting our companies own abstraction layer from STMF1 to STMF2.
-
"This is now officially obsolete, good riddance. A few years ago we had the same fight on these forums about this, you were told you absolutely must use this horrible piece of crap otherwise you are "wasting time" and being generally stupid. Then ST made this obsolete overnight, now even Good People are not supposed to use this."
Is this the libs which come with Cube IDE i.e. the HAL stuff?
Read more carefully. I thought I made it super clear SPL and HAL are really different and SPL is obsolete, HAL is not.
These cater to different needs, though, and are at completely different level. To rephrase it again, SPL was a totally unnecessary layer, HAL has a purpose other than obfuscation so does make sense to exist.
-
Having been playing with this stuff for only about 9 months, I have no knowledge of ST ARM development before that.
I think a fair few people have a Cube IDE setup which they use just to generate some functions, based on the graphical config "wizard" in Cube, they copy out the generated code, and then close Cube without saving anything :) I can see why they do this; it saves a huge amount of RM reading, especially for all the various clock divider config.
-
Well... try that with a USB or network software stack. Or SSL/TLS, Lora, Wifi, LTE to name a few.
I have written my own TCP/IP stack (along with Ethernet and WiFi drivers) and have used the same code in projects for a dozen years now. It works and I know how it works. The last bug I fixed in it was about a decade ago.
-
That is probably 10 man-years' of a learning curve.
It's possible if working for an employer who is not monitoring work progress, or if you work for yourself and have enough cash cows to keep you afloat while you learn all this stuff.
In practice, today, one would google for the source code and adapt whatever one can find. Writing it from scratch would be a poor use of time.
-
That is probably 10 man-years' of a learning curve.
You're kidding, right?
TCP is a very simple protocol. If you ever wrote code which packetizes serial stream, it's comparable complexity to TCP. There are some quirks such as CRCs and window management, but it's all is straightforward and well documented. Even the problems which you can encounter are documented in RFCs. There were decades when people tried to abuse TCP/IP, mount DoD attacks, hurt performance. So TCP/IP is investigated and known to the very details. And it's been that way at least for 30 years. Aside of that, IP packets must be encapsulated into Ethernet frames. One extra thing you need to do is to find a recipient's mac address - you broadcast a packet "who has this IP?" and receive a response. That's all there is to it.
People are afraid of what they don't know and think it's some sort of magic. But if you look at the docs, things start to look simple.
-
That is probably 10 man-years' of a learning curve.
You're kidding, right?
TCP is a very simple protocol. If you ever wrote code which packetizes serial stream, it's comparable complexity to TCP. There are some quirks such as CRCs and window management, but it's all is straightforward and well documented. Even the problems which you can encounter are documented in RFCs. There were decades when people tried to abuse TCP/IP, mount DoD attacks, hurt performance. So TCP/IP is investigated and known to the very details. And it's been that way at least for 30 years. Aside of that, IP packets must be encapsulated into Ethernet frames. One extra thing you need to do is to find a recipient's mac address - you broadcast a packet "who has this IP?" and receive a response. That's all there is to it.
Not by a long shot. Modern day TCP/IP stacks have all kinds of traffic optimisations in them (for example having 2 packets in flight as the simplest form). The base is pretty simple but getting a rock solid and secure TCP/IP stack is a different story. Writing your own TCP/IP stack is nothing short than re-inventing the wheel anyway.
-
If you look at the source code of a commercial IP stack with multiple procols and services, ip4 and ip6 with TLS with multiple ciphers etc. You see it is not so simple especially on a uC where you have only around 32kB RAM for the IP protocol and less than 64kB ROM for that code.
And yes you can write it yourself then have to debug and still forget a couple of things that hackers will find with Kali in a couple of hours pentesting.
If you want then please start with an already tested open source codestack.
-
That is probably 10 man-years' of a learning curve.
You're kidding, right?
TCP is a very simple protocol. If you ever wrote code which packetizes serial stream, it's comparable complexity to TCP. There are some quirks such as CRCs and window management, but it's all is straightforward and well documented. Even the problems which you can encounter are documented in RFCs. There were decades when people tried to abuse TCP/IP, mount DoD attacks, hurt performance. So TCP/IP is investigated and known to the very details. And it's been that way at least for 30 years. Aside of that, IP packets must be encapsulated into Ethernet frames. One extra thing you need to do is to find a recipient's mac address - you broadcast a packet "who has this IP?" and receive a response. That's all there is to it.
Not by a long shot. Modern day TCP/IP stacks have all kinds of traffic optimisations in them (for example having 2 packets in flight as the simplest form). The base is pretty simple but getting a rock solid and secure TCP/IP stack is a different story. Writing your own TCP/IP stack is nothing short than re-inventing the wheel anyway.
Yeah, that might be important if I was implementing TCP/IP for a high-volume server, but for my typical embedded projects data rates are low and the efficiency of bog-standard TCP/IP (as documented in the earliest RFCs) is more than good enough for me.
-
Not by a long shot. Modern day TCP/IP stacks have all kinds of traffic optimisations in them (for example having 2 packets in flight as the simplest form). The base is pretty simple but getting a rock solid and secure TCP/IP stack is a different story.
He could have optimized his stack for his own use, made it more compact and more suitable for MCU. Why do you think his stack is not rock solid? May be it is.
Writing your own TCP/IP stack is nothing short than re-inventing the wheel anyway.
I guess he had his reasons. How can you judge him without knowing anything about his circumstances?
If not for the people who "re-invent" the wheel we would still use wheels made of rock.
-
You would have had to work hard to get a TCP/IP stack on a "64k" CPU like e.g. a Z80, or some other device with a 64k address space. With banking (e.g. Z180; could do 1MB with the IAR compiler, large model, banking functions in/out) it gets a lot easier. Loads of people struggled with this in the early days of ethernet, and many/most of them solved it by buying in one of the various ethernet modules which give you a serial port to connect to (rubbish data rate but ok for most applications in question, and you can claim your box "does ethernet"). And now you more or less need TLS...
You would need to be a pretty serious "anorak" (as well as a very good comms programmer) to roll your own TCP/IP stack, but my main Q would be who or what is paying for your time while you are spending it on that sort of thing.
Let me give you an example. My target right here would get DHCP allright at my office but would not do it at my house. There were various differences. Same main router. Different 16-port switches; the work LAN uses a 16 port unmanaged Netgear; the home LAN uses a 16 port unmanaged Linksys POE switch which claims to do QOS (as usual zero details published and no config). Different subnets (192.168.1.* versus 5.*). Someone suggested it might be the hacked MAC# in the target board (was something like 0x01 x02... But why should this matter, when there was no conflict? Well, this Linksys "QOS" switch was doing something! I can't believe it was looking up the MAC # online to see what this product was... Changing the MAC to one of a laptop (which did get DHCP allright) made it work!
-
You would have had to work hard to get a TCP/IP stack on a "64k" CPU like e.g. a Z80, or some other device with a 64k address space. With banking (e.g. Z180; could do 1MB with the IAR compiler, large model, banking functions in/out) it gets a lot easier. Loads of people struggled with this in the early days of ethernet, and many/most of them solved it by buying in one of the various ethernet modules which give you a serial port to connect to (rubbish data rate but ok for most applications in question, and you can claim your box "does ethernet"). And now you more or less need TLS...
You can get a long way with uIP on a small platform. I have messed with that quite a bit but in hindsight it is an utter piece of rubbish. In my most recent project which needed ethernet on a microcontroller I used a Wiznet 5500 chip (they might have newer versions which also support IPv6 by now). As an added bonus the chip also acts as a firewall between your application and the tcp/ip stack.
-
For small to medium scale production runs that is a viable solution.
Problem is the ownership and maintainability of the stack.
In case a zero day exploit is found and customer has an issue you should be able to upgrade your stack to solve it.
I do not know if this is possible with the external Wiznet solution ?
For larger scale production, it is probably too expensive and the ip stack needs to be owned and integrated in the firmware from the company.
In the real world we already see lots of hacks of home and small business networks occurring through not only PCs but older not maintained and updated internet connected electronics such as routers, NASses, VCRs, TVs, IP cameras etc.
Lots of small electronic companies do not have a security lifecycle management department that actively monitors cve reports and some even never update the firmware after production.
So it is the responsibility of the OWNER of the equipment to at least yearly check the security vulnerabilities for their equipment and not blindly attach everything to the internet.
https://www.cvedetails.com/ (https://www.cvedetails.com/)
-
This is digressing somewhat, but I looked up the Wiznet 5500. Yes; it looks like a good solution, although it doesn't have hardware crypto. In the thing I am working on now I have a LAN8742 and the stack is done on the 32F417 using the ST libs, so if some exploit comes out at least in can be fixed, whereas with a chip like the Wiznet you are stuffed.
OTOH a lot of products are used in applications where they are nowhere near being exposed to the outside internet... or so you hope ;) But then all you need is something which does NTP (for date/time; always a challenge in embedded systems) and you are immediately stuffed.
-
For small to medium scale production runs that is a viable solution.
Problem is the ownership and maintainability of the stack.
In case a zero day exploit is found and customer has an issue you should be able to upgrade your stack to solve it.
Yes and no. If the Wiznet chip gets hacked they still aren't in your application. It is only a real problem if a third party can reprogram the Wiznet chip remotely to become part of a botnet OR do a targetted DDOS attack on your device. However since IOT devices are typically behind a firewall / NAT router, the chances of a real attack are very low.
-
Yes that is very true.
One wonders whether Wiznet put more effort into their code than ST put into their ETH libs :)
-
However since IOT devices are typically behind a firewall / NAT router, the chances of a real attack are very low.
Pretty blunt assertion. Do you really think that most IoT devices in use are connected to perfectly secure networks? Yeah. ::)
Now, one thing we could say is that, particularly these days, a connection via Ethernet has chances to be better protected than via WiFi, for instance, for a number of reasons. But even so, claiming that chances of a real attack are very low?
-
However since IOT devices are typically behind a firewall / NAT router, the chances of a real attack are very low.
Only when the device is very small, the Wizz will probably be too small.
However devices such as a raspberri pi run Linux are large enough such that a hacker can easily install a reverse shell or reverse proxy rendering any firewall that only scans incoming traffic useless.
-
Yes that is very true.
One wonders whether Wiznet put more effort into their code than ST put into their ETH libs :)
Because for Wizznet it is their product they earn money with.
ST sells microcontrollers, the libraries are for getting started, if you look at st.com they list around six commercial IP stacks and vendors. Those stack vendors will also put a lof of effort in their core product ;)
-
"ST sells microcontrollers, the libraries are for getting started, "
Is there any detail available on this topic?
For example a list of known bugs?
-
"ST sells microcontrollers, the libraries are for getting started, "
Is there any detail available on this topic?
For example a list of known bugs?
Many forests have given their lives to print lists of ST microcontroller bugs.
-
I've had good fortune with lwIP and the st ethernet drivers. I have a lot worse luck with other stacks from other vendors.
I did read the ethernet HAL driver from ST completely and I couldn't find any problems.
I'd say 90% of issues are from folk not understanding data cache. You have to use the MPU to get ethernet working on any parts with data cache turned on.
-
"I'd say 90% of issues are from folk not understanding data cache. You have to use the MPU to get ethernet working on any parts with data cache turned on."
Isn't that supposed to be transparent?
I did a google on "MPU" and it seems to be just the microprocessor :)
I see Cube generating two lots of partly duplicated startup code. This bit is from SetSysClock(void) which is called from SystemInit() which is called from the .s startup (so this happens first)
/* Configure Flash prefetch, Instruction cache, Data cache and wait state */
FLASH->ACR = FLASH_ACR_ICEN |FLASH_ACR_DCEN |FLASH_ACR_LATENCY_5WS;
The second bit is from HAL_Init from stm32f4xx_hal.c
#if (INSTRUCTION_CACHE_ENABLE != 0U)
__HAL_FLASH_INSTRUCTION_CACHE_ENABLE();
#endif /* INSTRUCTION_CACHE_ENABLE */
#if (DATA_CACHE_ENABLE != 0U)
__HAL_FLASH_DATA_CACHE_ENABLE();
#endif /* DATA_CACHE_ENABLE */
#if (PREFETCH_ENABLE != 0U)
__HAL_FLASH_PREFETCH_BUFFER_ENABLE();
#endif /* PREFETCH_ENABLE */
and there was this. The yellow bit was set to 0 and I changed it to 1 (stm32f4xx_hal_conf.h) and the code runs fine
(https://peter-ftp.co.uk/screenshots/202108053012631109.jpg)
For some reason the 1st version does not enable FLASH_ACR_PRFTEN. Well, they want to do the minimum init at startup and then use the .h config setting to control the last bit. But this is yet another example of Cube generating crap code where multiple funcs do the same things. For example the clock divisors get set up in two places, too - identically as it happens but I spent some time working out why changing the SPI clocks did nothing, until I found the other place.
But this isn't the data cache, is it? How is this relevant to ethernet?
EDIT: the data cache issue seems real:
https://community.st.com/s/question/0D50X0000AnsIJeSQM/how-to-get-ethernet-working-again-after-upgrading-to-firmware-fwh7v140-
But it isn't clear if this is relevant to 32F4xx.
Here appears to be a long list of Cube bugs: https://nadler.com/backups/20200111_draft2_STM_Cube_Issues_and_Workflow.html
-
When i open the last link, i see a red warning "cube will trash your code". It happened to me once. Then i discovered that the generated code contains markup for "user code" that stays protected from code generation. Seems like the author of that web page was unable to discover the scheme, at least i did not see it on his page. Application of these frameworks requires a certain level of insight.
Concerning double generated code the same applies. Try to understand how you got the redundant initialization sequence and you will be able to resolve it. You may have to repeat the initial steps of project setup to see at which step it happens. Cube isn't a random number generator. For example i could invent a setup where the IDE and cube both insert initialization code. The IDE does it to support the CRT for easy main() testing, lets say at some default clock of 4 MHz. Cube does it in great detail according to visual configuration. Now if you include the cortex libraries from arm, it gets even more thrilling.
Regards, Dieter
-
Yes indeed the Cube generated code contains constructs where you are allowed to insert your own code:
/**
* Initializes the Global MSP.
*/
void HAL_MspInit(void)
{
/* USER CODE BEGIN MspInit 0 */
/* USER CODE END MspInit 0 */
__HAL_RCC_SYSCFG_CLK_ENABLE();
__HAL_RCC_PWR_CLK_ENABLE();
/* System interrupt init*/
/* PendSV_IRQn interrupt configuration */
HAL_NVIC_SetPriority(PendSV_IRQn, 15, 0);
/* USER CODE BEGIN MspInit 1 */
/* USER CODE END MspInit 1 */
}
However I am not sure that is anywhere near the whole story. I have just gone through the entire initialisation code and compiled the various bits into one piece of code which is inline and starts at the start of main(). The first bit of it was in SystemInit() which was called from the assembler startup code, just before it went to main(). Why from there? Why call a C function from asm startup, immediately before you go main()?
There is a number of clear duplicates, but I am not 100% sure if there might be a reason behind them, to do with subtle timing issues (like the famous Ethernet one where having a PCLK2 divisor of 8 or 16 broke the ethernet subsystem, unless timing was ensured via another route):
int main(void)
{
// This was in SystemInit()
/* FPU settings ------------------------------------------------------------*/
#if (__FPU_PRESENT == 1) && (__FPU_USED == 1)
SCB->CPACR |= ((3UL << 10*2)|(3UL << 11*2)); /* set CP10 and CP11 Full Access */
#endif
/* Reset the RCC clock configuration to the default reset state ------------*/
/* Set HSION bit */
RCC->CR |= (uint32_t)0x00000001;
/* Reset CFGR register */
RCC->CFGR = 0x00000000;
/* Reset HSEON, CSSON and PLLON bits */
RCC->CR &= (uint32_t)0xFEF6FFFF;
/* Reset PLLCFGR register */
RCC->PLLCFGR = 0x24003010;
/* Reset HSEBYP bit */
RCC->CR &= (uint32_t)0xFFFBFFFF;
/* Disable all interrupts */
RCC->CIR = 0x00000000;
/* Configure the System clock source, PLL Multiplier and Divider factors,
AHB/APBx prescalers and Flash settings ----------------------------------*/
// This was in SetSysClock(), and the settings were partly overriden later by
// stuff in SystemClock_Config()!
volatile uint32_t StartUpCounter = 0, HSEStatus = 0;
/* Enable HSE */
RCC->CR |= ((uint32_t)RCC_CR_HSEON);
/* Wait till HSE is ready and if Time out is reached exit */
do
{
HSEStatus = RCC->CR & RCC_CR_HSERDY;
StartUpCounter++;
} while((HSEStatus == 0) && (StartUpCounter != HSE_STARTUP_TIMEOUT));
if ((RCC->CR & RCC_CR_HSERDY) != RESET)
{
HSEStatus = (uint32_t)0x01;
}
else
{
HSEStatus = (uint32_t)0x00;
}
/* Enable high performance mode, System frequency up to 168 MHz */
RCC->APB1ENR |= RCC_APB1ENR_PWREN;
PWR->CR |= PWR_CR_PMODE;
// *** THIS CLOCK CONFIG GETS OVERRIDEN below ***
/* HCLK = SYSCLK / 1*/
RCC->CFGR |= RCC_CFGR_HPRE_DIV1;
/* PCLK2 = HCLK / 4 i.e. 42MHz */
RCC->CFGR |= RCC_CFGR_PPRE2_DIV4;
/* PCLK1 = HCLK / 4 i.e. 42MHz */
RCC->CFGR |= RCC_CFGR_PPRE1_DIV4;
/************************* PLL Parameters *************************************/
// These produce a 168MHz CPU clock (336/2) and a 48MHz USB clock (336/7)
/* PLL_VCO = (HSE_VALUE or HSI_VALUE / PLL_M) * PLL_N */
#define PLL_M 25
#define PLL_N 336
/* SYSCLK = PLL_VCO / PLL_P */
#define PLL_P 2
/* USB OTG FS, SDIO and RNG Clock = PLL_VCO / PLLQ */
#define PLL_Q 7
/* Configure the main PLL */
RCC->PLLCFGR = PLL_M | (PLL_N << 6) | (((PLL_P >> 1) -1) << 16) |
(RCC_PLLCFGR_PLLSRC_HSE) | (PLL_Q << 24);
/* Enable the main PLL */
RCC->CR |= RCC_CR_PLLON;
/* Wait till the main PLL is ready */
while((RCC->CR & RCC_CR_PLLRDY) == 0) {}
/* Configure Flash prefetch, Instruction cache, Data cache and wait state */
// This stuff is also partly repeated further below. What is not being done here, for
// no obvious reason, is FLASH_ACR_PRFTEN. So this line is partly pointless.
// But maybe there are timing reasons for this...
FLASH->ACR = FLASH_ACR_ICEN |FLASH_ACR_DCEN |FLASH_ACR_LATENCY_5WS;
/* Select the main PLL as system clock source */
RCC->CFGR &= (uint32_t)((uint32_t)~(RCC_CFGR_SW));
RCC->CFGR |= RCC_CFGR_SW_PLL;
/* Wait till the main PLL is used as system clock source */
while ((RCC->CFGR & (uint32_t)RCC_CFGR_SWS ) != RCC_CFGR_SWS_PLL) {}
/* Configure the Vector Table location add offset address ------------------*/
#define VECT_TAB_OFFSET 0x00 /*!< Vector Table base offset field. This value must be a multiple of 0x200. */
SCB->VTOR = FLASH_BASE | VECT_TAB_OFFSET; /* Vector Table Relocation in Internal FLASH */
// Copy of HAL_Init from stm32f4xx_hal.c
// Stripped down to NOT enable interrupts!
/* Configure Flash prefetch, Instruction cache, Data cache. These are according to the config
* in stm32f4xx_hal_conf.h which currently is:
* #define PREFETCH_ENABLE 1 The prefetch will be enabled in SystemClock_Config(), depending
* on the used STM32F405/415/07/417 device: RevA (prefetch must be
* off) or RevZ (prefetch can be on/off)
* #define INSTRUCTION_CACHE_ENABLE 1
* #define DATA_CACHE_ENABLE 1
*/
// This overrides FLASH_ACR_ICEN above
#if (INSTRUCTION_CACHE_ENABLE != 0U)
__HAL_FLASH_INSTRUCTION_CACHE_ENABLE();
#endif /* INSTRUCTION_CACHE_ENABLE */
// This overrides FLASH_ACR_DCEN above
#if (DATA_CACHE_ENABLE != 0U)
__HAL_FLASH_DATA_CACHE_ENABLE();
#endif /* DATA_CACHE_ENABLE */
// This setting is controlled from stm32f4xx_hal_conf.h which was edited to enable this 5/8/2021
#if (PREFETCH_ENABLE != 0U)
__HAL_FLASH_PREFETCH_BUFFER_ENABLE();
#endif /* PREFETCH_ENABLE */
/* Set Interrupt Group Priority */
//HAL_NVIC_SetPriorityGrouping(NVIC_PRIORITYGROUP_4);
/* Use systick as time base source and configure 1ms tick (default clock after Reset is HSI) */
//HAL_InitTick(TICK_INT_PRIORITY);
/* Init the low level hardware */
//HAL_MspInit();
// This was in SystemClock_Config()
RCC_OscInitTypeDef RCC_OscInitStruct = {0};
RCC_ClkInitTypeDef RCC_ClkInitStruct = {0};
RCC_PeriphCLKInitTypeDef PeriphClkInitStruct = {0};
/* Configure the main internal regulator output voltage */
__HAL_RCC_PWR_CLK_ENABLE();
__HAL_PWR_VOLTAGESCALING_CONFIG(PWR_REGULATOR_VOLTAGE_SCALE1);
/* Initialise the CPU, AHB and APB busses clocks */
// This is a duplicate of stuff further above
RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSE;
RCC_OscInitStruct.HSEState = RCC_HSE_ON;
RCC_OscInitStruct.PLL.PLLState = RCC_PLL_ON;
RCC_OscInitStruct.PLL.PLLSource = RCC_PLLSOURCE_HSE;
RCC_OscInitStruct.PLL.PLLM = 25;
RCC_OscInitStruct.PLL.PLLN = 336;
RCC_OscInitStruct.PLL.PLLP = RCC_PLLP_DIV2;
RCC_OscInitStruct.PLL.PLLQ = 7;
HAL_RCC_OscConfig(&RCC_OscInitStruct);
/** Initializes the CPU, AHB and APB busses clocks
* These settings override stuff set earlier */
RCC_ClkInitStruct.ClockType = RCC_CLOCKTYPE_HCLK|RCC_CLOCKTYPE_SYSCLK
|RCC_CLOCKTYPE_PCLK1|RCC_CLOCKTYPE_PCLK2;
RCC_ClkInitStruct.SYSCLKSource = RCC_SYSCLKSOURCE_PLLCLK;
RCC_ClkInitStruct.AHBCLKDivider = RCC_SYSCLK_DIV1;
RCC_ClkInitStruct.APB1CLKDivider = RCC_HCLK_DIV4; // 42MHz - SPI2,SPI3,UART2,UART3,TIM2,3,4,5,6,7,12,13,15 etc
RCC_ClkInitStruct.APB2CLKDivider = RCC_HCLK_DIV4; // 42MHz - UART1,UART6
HAL_RCC_ClockConfig(&RCC_ClkInitStruct, FLASH_LATENCY_5);
PeriphClkInitStruct.PeriphClockSelection = RCC_PERIPHCLK_I2S;
PeriphClkInitStruct.PLLI2S.PLLI2SN = 192;
PeriphClkInitStruct.PLLI2S.PLLI2SR = 2;
HAL_RCCEx_PeriphCLKConfig(&PeriphClkInitStruct);
// Stop IWDG if single stepping
__HAL_DBGMCU_FREEZE_IWDG();
// Initialise clocks. Without this one cannot set up any I/O pins etc.
B_HAL_RCC_MCOConfig(RCC_MCO2, RCC_MCO2SOURCE_HSE, RCC_MCODIV_1);
/* GPIO Ports Clock Enable */
__HAL_RCC_GPIOH_CLK_ENABLE();
__HAL_RCC_GPIOC_CLK_ENABLE();
__HAL_RCC_GPIOB_CLK_ENABLE();
__HAL_RCC_GPIOA_CLK_ENABLE();
-
It gets better.
/* Initialise the CPU, AHB and APB busses clocks */
/*
RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSE;
RCC_OscInitStruct.HSEState = RCC_HSE_ON;
RCC_OscInitStruct.PLL.PLLState = RCC_PLL_ON;
RCC_OscInitStruct.PLL.PLLSource = RCC_PLLSOURCE_HSE;
RCC_OscInitStruct.PLL.PLLM = 25;
RCC_OscInitStruct.PLL.PLLN = 336;
RCC_OscInitStruct.PLL.PLLP = RCC_PLLP_DIV2;
RCC_OscInitStruct.PLL.PLLQ = 7;
HAL_RCC_OscConfig(&RCC_OscInitStruct);
*/
The function called, HAL_RCC_OscConfig(), is:
/**
* @brief Initializes the RCC Oscillators according to the specified parameters in the
* RCC_OscInitTypeDef.
* @param RCC_OscInitStruct pointer to an RCC_OscInitTypeDef structure that
* contains the configuration information for the RCC Oscillators.
* @note The PLL is not disabled when used as system clock.
* @note Transitions LSE Bypass to LSE On and LSE On to LSE Bypass are not
* supported by this API. User should request a transition to LSE Off
* first and then LSE On or LSE Bypass.
* @note Transition HSE Bypass to HSE On and HSE On to HSE Bypass are not
* supported by this API. User should request a transition to HSE Off
* first and then HSE On or HSE Bypass.
* @retval HAL status
*/
__weak HAL_StatusTypeDef HAL_RCC_OscConfig(RCC_OscInitTypeDef *RCC_OscInitStruct)
{
uint32_t tickstart;
/* Check Null pointer */
if(RCC_OscInitStruct == NULL)
{
return HAL_ERROR;
}
/* Check the parameters */
assert_param(IS_RCC_OSCILLATORTYPE(RCC_OscInitStruct->OscillatorType));
/*------------------------------- HSE Configuration ------------------------*/
if(((RCC_OscInitStruct->OscillatorType) & RCC_OSCILLATORTYPE_HSE) == RCC_OSCILLATORTYPE_HSE)
{
/* Check the parameters */
assert_param(IS_RCC_HSE(RCC_OscInitStruct->HSEState));
/* When the HSE is used as system clock or clock source for PLL in these cases HSE will not disabled */
if((__HAL_RCC_GET_SYSCLK_SOURCE() == RCC_CFGR_SWS_HSE) ||\
((__HAL_RCC_GET_SYSCLK_SOURCE() == RCC_CFGR_SWS_PLL) && ((RCC->PLLCFGR & RCC_PLLCFGR_PLLSRC) == RCC_PLLCFGR_PLLSRC_HSE)))
{
if((__HAL_RCC_GET_FLAG(RCC_FLAG_HSERDY) != RESET) && (RCC_OscInitStruct->HSEState == RCC_HSE_OFF))
{
return HAL_ERROR;
}
}
else
{
/* Set the new HSE configuration ---------------------------------------*/
__HAL_RCC_HSE_CONFIG(RCC_OscInitStruct->HSEState);
/* Check the HSE State */
if((RCC_OscInitStruct->HSEState) != RCC_HSE_OFF)
{
/* Get Start Tick */
tickstart = HAL_GetTick();
/* Wait till HSE is ready */
while(__HAL_RCC_GET_FLAG(RCC_FLAG_HSERDY) == RESET)
{
if((HAL_GetTick() - tickstart ) > HSE_TIMEOUT_VALUE)
{
return HAL_TIMEOUT;
}
}
}
else
{
/* Get Start Tick */
tickstart = HAL_GetTick();
/* Wait till HSE is bypassed or disabled */
while(__HAL_RCC_GET_FLAG(RCC_FLAG_HSERDY) != RESET)
{
if((HAL_GetTick() - tickstart ) > HSE_TIMEOUT_VALUE)
{
return HAL_TIMEOUT;
}
}
}
}
}
/*----------------------------- HSI Configuration --------------------------*/
if(((RCC_OscInitStruct->OscillatorType) & RCC_OSCILLATORTYPE_HSI) == RCC_OSCILLATORTYPE_HSI)
{
/* Check the parameters */
assert_param(IS_RCC_HSI(RCC_OscInitStruct->HSIState));
assert_param(IS_RCC_CALIBRATION_VALUE(RCC_OscInitStruct->HSICalibrationValue));
/* Check if HSI is used as system clock or as PLL source when PLL is selected as system clock */
if((__HAL_RCC_GET_SYSCLK_SOURCE() == RCC_CFGR_SWS_HSI) ||\
((__HAL_RCC_GET_SYSCLK_SOURCE() == RCC_CFGR_SWS_PLL) && ((RCC->PLLCFGR & RCC_PLLCFGR_PLLSRC) == RCC_PLLCFGR_PLLSRC_HSI)))
{
/* When HSI is used as system clock it will not disabled */
if((__HAL_RCC_GET_FLAG(RCC_FLAG_HSIRDY) != RESET) && (RCC_OscInitStruct->HSIState != RCC_HSI_ON))
{
return HAL_ERROR;
}
/* Otherwise, just the calibration is allowed */
else
{
/* Adjusts the Internal High Speed oscillator (HSI) calibration value.*/
__HAL_RCC_HSI_CALIBRATIONVALUE_ADJUST(RCC_OscInitStruct->HSICalibrationValue);
}
}
else
{
/* Check the HSI State */
if((RCC_OscInitStruct->HSIState)!= RCC_HSI_OFF)
{
/* Enable the Internal High Speed oscillator (HSI). */
__HAL_RCC_HSI_ENABLE();
/* Get Start Tick*/
tickstart = HAL_GetTick();
/* Wait till HSI is ready */
while(__HAL_RCC_GET_FLAG(RCC_FLAG_HSIRDY) == RESET)
{
if((HAL_GetTick() - tickstart ) > HSI_TIMEOUT_VALUE)
{
return HAL_TIMEOUT;
}
}
/* Adjusts the Internal High Speed oscillator (HSI) calibration value. */
__HAL_RCC_HSI_CALIBRATIONVALUE_ADJUST(RCC_OscInitStruct->HSICalibrationValue);
}
else
{
/* Disable the Internal High Speed oscillator (HSI). */
__HAL_RCC_HSI_DISABLE();
/* Get Start Tick*/
tickstart = HAL_GetTick();
/* Wait till HSI is ready */
while(__HAL_RCC_GET_FLAG(RCC_FLAG_HSIRDY) != RESET)
{
if((HAL_GetTick() - tickstart ) > HSI_TIMEOUT_VALUE)
{
return HAL_TIMEOUT;
}
}
}
}
}
/*------------------------------ LSI Configuration -------------------------*/
if(((RCC_OscInitStruct->OscillatorType) & RCC_OSCILLATORTYPE_LSI) == RCC_OSCILLATORTYPE_LSI)
{
/* Check the parameters */
assert_param(IS_RCC_LSI(RCC_OscInitStruct->LSIState));
/* Check the LSI State */
if((RCC_OscInitStruct->LSIState)!= RCC_LSI_OFF)
{
/* Enable the Internal Low Speed oscillator (LSI). */
__HAL_RCC_LSI_ENABLE();
/* Get Start Tick*/
tickstart = HAL_GetTick();
/* Wait till LSI is ready */
while(__HAL_RCC_GET_FLAG(RCC_FLAG_LSIRDY) == RESET)
{
if((HAL_GetTick() - tickstart ) > LSI_TIMEOUT_VALUE)
{
return HAL_TIMEOUT;
}
}
}
else
{
/* Disable the Internal Low Speed oscillator (LSI). */
__HAL_RCC_LSI_DISABLE();
/* Get Start Tick */
tickstart = HAL_GetTick();
/* Wait till LSI is ready */
while(__HAL_RCC_GET_FLAG(RCC_FLAG_LSIRDY) != RESET)
{
if((HAL_GetTick() - tickstart ) > LSI_TIMEOUT_VALUE)
{
return HAL_TIMEOUT;
}
}
}
}
/*------------------------------ LSE Configuration -------------------------*/
if(((RCC_OscInitStruct->OscillatorType) & RCC_OSCILLATORTYPE_LSE) == RCC_OSCILLATORTYPE_LSE)
{
FlagStatus pwrclkchanged = RESET;
/* Check the parameters */
assert_param(IS_RCC_LSE(RCC_OscInitStruct->LSEState));
/* Update LSE configuration in Backup Domain control register */
/* Requires to enable write access to Backup Domain of necessary */
if(__HAL_RCC_PWR_IS_CLK_DISABLED())
{
__HAL_RCC_PWR_CLK_ENABLE();
pwrclkchanged = SET;
}
if(HAL_IS_BIT_CLR(PWR->CR, PWR_CR_DBP))
{
/* Enable write access to Backup domain */
SET_BIT(PWR->CR, PWR_CR_DBP);
/* Wait for Backup domain Write protection disable */
tickstart = HAL_GetTick();
while(HAL_IS_BIT_CLR(PWR->CR, PWR_CR_DBP))
{
if((HAL_GetTick() - tickstart) > RCC_DBP_TIMEOUT_VALUE)
{
return HAL_TIMEOUT;
}
}
}
/* Set the new LSE configuration -----------------------------------------*/
__HAL_RCC_LSE_CONFIG(RCC_OscInitStruct->LSEState);
/* Check the LSE State */
if((RCC_OscInitStruct->LSEState) != RCC_LSE_OFF)
{
/* Get Start Tick*/
tickstart = HAL_GetTick();
/* Wait till LSE is ready */
while(__HAL_RCC_GET_FLAG(RCC_FLAG_LSERDY) == RESET)
{
if((HAL_GetTick() - tickstart ) > RCC_LSE_TIMEOUT_VALUE)
{
return HAL_TIMEOUT;
}
}
}
else
{
/* Get Start Tick */
tickstart = HAL_GetTick();
/* Wait till LSE is ready */
while(__HAL_RCC_GET_FLAG(RCC_FLAG_LSERDY) != RESET)
{
if((HAL_GetTick() - tickstart ) > RCC_LSE_TIMEOUT_VALUE)
{
return HAL_TIMEOUT;
}
}
}
/* Restore clock configuration if changed */
if(pwrclkchanged == SET)
{
__HAL_RCC_PWR_CLK_DISABLE();
}
}
/*-------------------------------- PLL Configuration -----------------------*/
/* Check the parameters */
assert_param(IS_RCC_PLL(RCC_OscInitStruct->PLL.PLLState));
if ((RCC_OscInitStruct->PLL.PLLState) != RCC_PLL_NONE)
{
/* Check if the PLL is used as system clock or not */
if(__HAL_RCC_GET_SYSCLK_SOURCE() != RCC_CFGR_SWS_PLL)
{
if((RCC_OscInitStruct->PLL.PLLState) == RCC_PLL_ON)
{
/* Check the parameters */
assert_param(IS_RCC_PLLSOURCE(RCC_OscInitStruct->PLL.PLLSource));
assert_param(IS_RCC_PLLM_VALUE(RCC_OscInitStruct->PLL.PLLM));
assert_param(IS_RCC_PLLN_VALUE(RCC_OscInitStruct->PLL.PLLN));
assert_param(IS_RCC_PLLP_VALUE(RCC_OscInitStruct->PLL.PLLP));
assert_param(IS_RCC_PLLQ_VALUE(RCC_OscInitStruct->PLL.PLLQ));
/* Disable the main PLL. */
__HAL_RCC_PLL_DISABLE();
/* Get Start Tick */
tickstart = HAL_GetTick();
/* Wait till PLL is ready */
while(__HAL_RCC_GET_FLAG(RCC_FLAG_PLLRDY) != RESET)
{
if((HAL_GetTick() - tickstart ) > PLL_TIMEOUT_VALUE)
{
return HAL_TIMEOUT;
}
}
/* Configure the main PLL clock source, multiplication and division factors. */
WRITE_REG(RCC->PLLCFGR, (RCC_OscInitStruct->PLL.PLLSource | \
RCC_OscInitStruct->PLL.PLLM | \
(RCC_OscInitStruct->PLL.PLLN << RCC_PLLCFGR_PLLN_Pos) | \
(((RCC_OscInitStruct->PLL.PLLP >> 1U) - 1U) << RCC_PLLCFGR_PLLP_Pos) | \
(RCC_OscInitStruct->PLL.PLLQ << RCC_PLLCFGR_PLLQ_Pos)));
/* Enable the main PLL. */
__HAL_RCC_PLL_ENABLE();
/* Get Start Tick */
tickstart = HAL_GetTick();
/* Wait till PLL is ready */
while(__HAL_RCC_GET_FLAG(RCC_FLAG_PLLRDY) == RESET)
{
if((HAL_GetTick() - tickstart ) > PLL_TIMEOUT_VALUE)
{
return HAL_TIMEOUT;
}
}
}
else
{
/* Disable the main PLL. */
__HAL_RCC_PLL_DISABLE();
/* Get Start Tick */
tickstart = HAL_GetTick();
/* Wait till PLL is ready */
while(__HAL_RCC_GET_FLAG(RCC_FLAG_PLLRDY) != RESET)
{
if((HAL_GetTick() - tickstart ) > PLL_TIMEOUT_VALUE)
{
return HAL_TIMEOUT;
}
}
}
}
else
{
return HAL_ERROR;
}
}
return HAL_OK;
}
which you can immediately see isn't going to work unless the 1kHz tick is running - for the timeouts.
So they are messing with PLL config and then using a function to set that up, which relies on interrupts already enabled!
Actually it evidently does work - because with the tick not running, none of the timeouts are implemented. The code still works but would not do anything useful (it would hang) if there really was an error.
But any error here is not going to produce anything which can output a useful error message, is it?
-
When i open the last link, i see a red warning "cube will trash your code". It happened to me once. Then i discovered that the generated code contains markup for "user code" that stays protected from code generation.
As someone who loathes being forced to code within someone else's "guardrails," I've come up with an approach that lets me track and review what various CubeMX options do without trashing any code I actually care about:
- Use CubeMX to generate a template project
- Check that template project into its own private/local Git repository
- Use that generated project as a basis for my own project, but organize the code in a way that actually makes sense to me and rewrite all the "generated" code so its structure doesn't make me want to gouge my eyes out. Don't put it in the same place.
- Develop as normal off my project's source tree
- Whenever I want to change something configured in Cube-land, make the change, regenerate the output, and use the power of Git to see what actually changed on the pristine generated dump. Migrate any of these changes into my own code when/if they make sense.
This way I can keep a revision history of CubeMX-driven changes, which is independent from (and does not directly affect) my main project.
The ability to turn any random directory on your computer into a "version controlled repository" is a huge benefit of systems like Git that I use quite frequently.
-
When i open the last link, i see a red warning "cube will trash your code". It happened to me once. Then i discovered that the generated code contains markup for "user code" that stays protected from code generation.
As someone who loathes being forced to code within someone else's "guardrails," I've come up with an approach that lets me track and review what various CubeMX options do without trashing any code I actually care about:
- Use CubeMX to generate a template project
- Check that template project into its own private/local Git repository
- Use that generated project as a basis for my own project, but organize the code in a way that actually makes sense to me and rewrite all the "generated" code so its structure doesn't make me want to gouge my eyes out. Don't put it in the same place.
- Develop as normal off my project's source tree
- Whenever I want to change something configured in Cube-land, make the change, regenerate the output, and use the power of Git to see what actually changed on the pristine generated dump. Migrate any of these changes into my own code when/if they make sense.
This way I can keep a revision history of CubeMX-driven changes, which is independent from (and does not directly affect) my main project.
The ability to turn any random directory on your computer into a "version controlled repository" is a huge benefit of systems like Git that I use quite frequently.
I agree with this. I haven't used code generating tools for a very long time but when I did, this was my approach as well. Just use the generated code as a template and go from there.
-
Yes; clearly this is the way to use that tool. Generate the code and then clean it up. I have just spent a few hours condensing the above garbage into about 5% of the amount of code. Takes a while to step through it and verify the register bits though, to make sure nothing got broken.
I think two different people worked in the config code. One of them wrote in this style
/* Enable high performance mode, System frequency up to 168 MHz */
RCC->APB1ENR |= RCC_APB1ENR_PWREN;
PWR->CR |= PWR_CR_PMODE;
/* HCLK = SYSCLK / 1*/
RCC->CFGR |= RCC_CFGR_HPRE_DIV1;
/* PCLK2 = HCLK / 4 i.e. 42MHz */
RCC->CFGR |= RCC_CFGR_PPRE2_DIV4;
/* PCLK1 = HCLK / 4 i.e. 42MHz */
RCC->CFGR |= RCC_CFGR_PPRE1_DIV4;
// PLL Parameters
// These produce a 168MHz CPU clock (336/2) and a 48MHz USB clock (336/7)
/* PLL_VCO = (HSE_VALUE or HSI_VALUE / PLL_M) * PLL_N */
#define PLL_M 25
#define PLL_N 336
/* SYSCLK = PLL_VCO / PLL_P */
#define PLL_P 2
/* USB OTG FS, SDIO and RNG Clock = PLL_VCO / PLLQ */
#define PLL_Q 7
/* Configure the main PLL */
RCC->PLLCFGR = PLL_M | (PLL_N << 6) | (((PLL_P >> 1) -1) << 16) |
(RCC_PLLCFGR_PLLSRC_HSE) | (PLL_Q << 24);
/* Enable the main PLL */
RCC->CR |= RCC_CR_PLLON;
/* Wait till the main PLL is ready */
while((RCC->CR & RCC_CR_PLLRDY) == 0) {}
/* Configure Flash prefetch, Instruction cache, Data cache and wait state */
FLASH->ACR = FLASH_ACR_PRFTEN | FLASH_ACR_ICEN | FLASH_ACR_DCEN | FLASH_ACR_LATENCY_5WS;
/* Select the main PLL as system clock source */
RCC->CFGR &= (uint32_t)((uint32_t)~(RCC_CFGR_SW));
RCC->CFGR |= RCC_CFGR_SW_PLL;
/* Wait till the main PLL is used as system clock source */
while ((RCC->CFGR & (uint32_t)RCC_CFGR_SWS ) != RCC_CFGR_SWS_PLL) {}
and the other one (the auto generated code I think; I sort of inherited this project) in this style
/* Initialise the CPU, AHB and APB busses clocks */
/*
RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSE;
RCC_OscInitStruct.HSEState = RCC_HSE_ON;
RCC_OscInitStruct.PLL.PLLState = RCC_PLL_ON;
RCC_OscInitStruct.PLL.PLLSource = RCC_PLLSOURCE_HSE;
RCC_OscInitStruct.PLL.PLLM = 25;
RCC_OscInitStruct.PLL.PLLN = 336;
RCC_OscInitStruct.PLL.PLLP = RCC_PLLP_DIV2;
RCC_OscInitStruct.PLL.PLLQ = 7;
// This function requires interrupts (tick) running for the various timeouts, which is
// nonsense for something setting up the basic clocks!
HAL_RCC_OscConfig(&RCC_OscInitStruct);
*/
/** Initializes the CPU, AHB and APB busses clocks
/*
RCC_ClkInitStruct.ClockType = RCC_CLOCKTYPE_HCLK|RCC_CLOCKTYPE_SYSCLK
|RCC_CLOCKTYPE_PCLK1|RCC_CLOCKTYPE_PCLK2;
RCC_ClkInitStruct.SYSCLKSource = RCC_SYSCLKSOURCE_PLLCLK;
RCC_ClkInitStruct.AHBCLKDivider = RCC_SYSCLK_DIV1;
RCC_ClkInitStruct.APB1CLKDivider = RCC_HCLK_DIV4; // 42MHz - SPI2,SPI3,UART2,UART3,TIM2,3,4,5,6,7,12,13,15 etc
RCC_ClkInitStruct.APB2CLKDivider = RCC_HCLK_DIV4; // 42MHz - UART1,UART6
HAL_RCC_ClockConfig(&RCC_ClkInitStruct, FLASH_LATENCY_5);
*/
and the second lot (HAL_RCC_OscConfig()) is a massive long function which must have been written by a complete numpty (but one who has just come off a C course, because he is heavily into structs) who doesn't "get" that there isn't going to be a nice 1kHz timer tick even before you have started configuring the PLL and the various clocks!
I had a load of fun at one point, with all the ticks running about 10x too fast. I found that there is a global variable, SystemCoreClock, which is the CPU clock in Hz (168000000). It is referenced for timers all over the place in the HAL code. It is calculated using a convoluted procedure which obviously requires the xtal freq to be given somewhere, and from that it reads various registers to get the division values and work out the CPU clock backwards. So now I just have SystemCoreClock=168000000; :)
-
Yes same here and replace many utils with my own code as well as extend some of the strange fixed size protocol handling functions with my own variable size ones.
-
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?
-
Don't know, never had a use for C++ for embedded work, and never will in my lifetime.
-
Don't know, never had a use for C++ for embedded work, and never will in my lifetime.
Ditto. With the exception of C++ style comments, which is pretty much standard these days on all C compilers, I have zero use for C++ for embedded use. And if I ever had to take over anyone's project and it used C++, the first thing I'd do is convert it to C. Way too many chances for the C++ code to eat up memory unnecessarily and waste my time modifying the code so that it doesn't.
-
The auto generated startup .s file has some initialisation for constructors etc. It seems to generate this stuff anyway.
-
For IDE-specific questions better ask here, they usually help a lot.:
https://community.st.com/
About the matter of this thread. Do you really love setting a specific editor, debugger, linker, compiler, making the makefile from scratch and glueing everything together? My head hurts just thinking on it.
While a new project will take to youa while, it takes seconds in Cube IDE. Not to mention if you have to install and configure everything from zero.
Not that many bugs, really.
The're a few with the code builder, ex. syscalls.c, sysmem.c, startup_xxx.s won't be regenerated if deleted, neither the linker script.
Not really a bug, just don't delete your files :-DD
A very annoying one is the SWV data plot, when you set all the 4 data traces usually one of them is not updated corrrectly.
After running it for more than 30s it will slow down to the point it's unusable, requiring erasing the data plot history.
A true bug happened when you copied the project, renamed the .ioc file and regenerated the code. CubeMx would wipe the Src contents of the original project you copied it from.
Other than that, I find it to be pretty solid. Most bugs were my fault due unawareness or making mistakes.
And due their really bad documentaion.
-
I have no idea what "setting a specific linker and compiler" even means. Maybe it's the glue you mentioned, too much and I'm not surprised your head is hurting?
What configuration? I have never configured any of the GNU tools, just installed.
It seems you have some very weird assumptions how a normal firmware build environment works as you have never used one, and assume it must be colossally difficult.
-
...
As someone who loathes being forced to code within someone else's "guardrails," I've come up with an approach that lets me track and review what various CubeMX options do without trashing any code I actually care about:
Use CubeMX to generate a template project
Check that template project into its own private/local Git repository
Use that generated project as a basis for my own project, but organize the code in a way that actually makes sense to me and rewrite all the "generated" code so its structure doesn't make me want to gouge my eyes out. Don't put it in the same place.
Develop as normal off my project's source tree
Whenever I want to change something configured in Cube-land, make the change, regenerate the output, and use the power of Git to see what actually changed on the pristine generated dump. Migrate any of these changes into my own code when/if they make sense.
This way I can keep a revision history of CubeMX-driven changes, which is independent from (and does not directly affect) my main project.
The ability to turn any random directory on your computer into a "version controlled repository" is a huge benefit of systems like Git that I use quite frequently.
dkonigs, thanks for sharing your work-around. After ST-support confirmed that the "user-code-section" are hardcoded into CubeIDE, I devised a similar scheme. Before entering the codegenerator, which happens rarely after initially setting up the project, I do a check-in to GIT. After the code-generator run, I do a diff and re-apply my patches to the libraries. Annoying, but feasible.
Although I have heard bad things about ST-support, I can only share my most recent experience, when I filed a bug report with ST "online.support@st.com" last week:
Hi,
I just spent several hours debugging an issue with HAL-DeInit.
STM32Cube STM32F1 1.8.3 / 1.8.2
It turned out that stm32f1xx_hal_rcc.h has a typo in
/** @defgroup RCC_APB1_Force_Release_Reset APB1 Force Release Reset * @brief Force or release APB1 peripheral reset. * @{ */
//#define __HAL_RCC_APB1_FORCE_RESET() (RCC->APB2RSTR = 0xFFFFFFFFU) // <- original
#define __HAL_RCC_APB1_FORCE_RESET() (RCC->APB1RSTR = 0xFFFFFFFFU) // MAH2107281301 BUGFIX
I would appreciate it if you could fix that ASAP. If that patch is present in 1.8.4, my apologies, but I can't switch libraries for that project.
Much obliged,
harerod
First response, within a day:
Dear Harerod,
Below case has been updated by ST Support.
Case#: 00137742
Subject: Bug in HAL - stm32f1xx_hal_rcc.h
Status: Working
Description:
We have escalated your inquiry to our applications team for further support.
Regards,
...
Five days later:
Dear Harerod,
Below case has been updated by ST Support.
Case#: 00137742
Subject: Bug in HAL - stm32f1xx_hal_rcc.h
Status: Solution Proposed
Description: Dear customer, Thank You for notifying us. I reported this typo and it should be fixed as soon as possible. We apologize for any inconvenience. Best regards, ST MCU Support Team
Please visit ST Customer Support Portal for further information.
Link to access the case:
...
Best regards,
ST Customer Support
-
"For IDE-specific questions better ask here, they usually help a lot.:
https://community.st.com/"
I think everybody does that, which is why most questions posted there attract zero answers :)
Yes; ST do seem to prefer dealing with support tickets, and in my limited experience they do respond. I got a response out of them to my PCLK2 divider / ethernet bug thing, which needed somebody pretty good to have a dig around.
Incidentally, does anyone know what exactly this does:
In linkfile:
.preinit_array :
{
PROVIDE_HIDDEN (__preinit_array_start = .);
KEEP (*(.preinit_array*))
PROVIDE_HIDDEN (__preinit_array_end = .);
} >FLASH
.init_array :
{
PROVIDE_HIDDEN (__init_array_start = .);
KEEP (*(SORT(.init_array.*)))
KEEP (*(.init_array*))
PROVIDE_HIDDEN (__init_array_end = .);
} >FLASH
.fini_array :
{
PROVIDE_HIDDEN (__fini_array_start = .);
KEEP (*(.fini_array*))
KEEP (*(SORT(.fini_array.*)))
PROVIDE_HIDDEN (__fini_array_end = .);
} >FLASH
Note the above ends up in FLASH, not DATA or BSS.
In startup:
LoopCopyDataInit:
ldr r0, =_sdata
ldr r3, =_edata
adds r2, r0, r1
cmp r2, r3
bcc CopyDataInit
ldr r2, =_sbss
b LoopFillZerobss
/* Zero fill the bss segment. */
FillZerobss:
movs r3, #0
str r3, [r2], #4
LoopFillZerobss:
ldr r3, = _ebss
cmp r2, r3
bcc FillZerobss
/* Call the clock system intitialization function.*/
bl SystemInit
/* Call static constructors */
bl __libc_init_array
/* Call the application's entry point.*/
bl main
bx lr
A large number of people have been asking what __libc_init_array does and there are countless threads on it, but nobody knows whether any ST libs need it. I took it out quite early on in the belief that this stuff is for C++ only, and everything seems to have worked. I am told it may do some initialisation for stuff like memset, printf, etc. Does anyone know, in the ST 32F context?
Also SystemInit() is a function in main.c which sets up various things like the PLL, but then other code later on overrides that setting. None of this has any obvious point; it looks like different people were working on this stuff and didn't talk to each other. But it could be that they wanted some initialisation before __libc_init_array()...
-
...
The're a few with the code builder, ex. syscalls.c, sysmem.c, startup_xxx.s won't be regenerated if deleted, neither the linker script.
...
I would call that a feature, especially when it comes to the linker scripts. A standard production project might have several different build configurations and memory layouts.
Three sets for Debug and Release each:
- linker file for standalone application, starting at FLASH begin
- linker file for bootloader, starting at FLASH begin
- linker file for application, starting at application base address FLASH, being called by the bootloader
In that case, the memory layout for the application looks like this:
MEMORY
{
CCMRAM (rw) : ORIGIN = 0x10000000, LENGTH = 64K /* CCM File System */
RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 128K
FLASHBL (rx) : ORIGIN = 0x8000000, LENGTH = 128K /* bootloader flash memory */
FLASHAPP (rx) : ORIGIN = 0x8020000, LENGTH = 256K /* application flash memory */
FLASHDATA (rx) : ORIGIN = 0x8060000, LENGTH = 640K /* Flash File System */
}
-
Sure, but in that case you copy/rename the linker script and adjust the linker settings in the build profile.
Otherwise, a code generator should do exactly that. You should be able to mess everything up (except user code) and let it rebuild the project into fully working state.
In fact you can adjust the heap and stack sizes, and it'll change the linker script.
Although it fails sometimes and doesn't edit it.
Time ago sysmem.c and syscalls.c dissapeared from my project, and I didn't notice until months later (The files were already gone when I started using git).
After adding some new mallocs the system started to crash in very random ways. I realized I could malloc 4 petaBytes if I wanted on the 16KB RAM device.
Took me days to find out the cause. Looking at the sbrk function assembly, no checks were made!
It seems the sbrk function in sysmem.c overrides the generic one, so if you delete it there won't be any errors at compile time.
These things you learn at the beginning and never forget! :D
Maybe it's the glue you mentioned, too much
Wtf are you saying? I was the solvent I used to clean the boards :-DD
Sure, there's a lot I'm unaware of.
I coded some C in Linux, but it's a PITA when there's no code assist.
I ended using the same thing: Eclipse ide.
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 :D
-
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/ (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/ (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 :D
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
(https://peter-ftp.co.uk/screenshots/202108092612701621.jpg)
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
(https://peter-ftp.co.uk/screenshots/20210809513592021.jpg)
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.
-
"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.
Given 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."
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 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.
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 (https://www.eevblog.com/forum/index.php?topic=285824.msg3624065#msg3624065)
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.
-
Yes; I've been using that, though usually I disable it because I move debuggers around.
Right now I am trying to rebuild my project not in the current Debug mode but in Release mode, and it fails immediately. The paths the the various files are wrong. Is there a simple way to copy the path(s)
from Debug to Release?
-
Basic mistake :D, remember to select [all configurations] next time. Otherwise you will need to set up them separately!
Not a big issue, you can select multiple paths by holding down the control key, adding all folders in a single operation.
(https://github.com/deividAlfa/stm32_soldering_iron_controller/raw/master/Readme_files/Includes.jpg?raw=true)
-
Thanks :)
What I have now looks like this
(https://peter-ftp.co.uk/screenshots/20210810303605215.jpg)
and there is no obvious way to copy all the many lines from the Debug mode to the Release mode, and do this for a) asm b) compiler c) linker. Also one can add or delete only 1 line at a time in this screen.
The whole thing looks auto generated and I wonder if it is generated simply by making Release the active profile and running a project indexing operation?
-
Create a new configuration based on an existing one in order to copy all the settings.
-
I see nothing obviously applicable under File / New, but under the project itself (which must be the right place) I see some possible options, but none are called "configuration"
(https://peter-ftp.co.uk/screenshots/20210810093612117.jpg)
The project normally built is a "STM32 Cortex" one, rather than one of the numerous "C/C++" options found in Cube, none of which seem to support a config for an STLINK debugger anyway.
I have no .ioc file anywhere, and there is stuff online suggesting that that option doesn't work in ST Cube anyway.
-
I see nothing obviously applicable under File / New, but under the project itself (which must be the right place) I see some possible options, but none are called "configuration"
Eclipse...death by a thousand papercuts.
You'll find what you need under Project->Build Configurations->Manage (also in the menu you are looking at), see picture.
There one can create a new configuration copying from an existing one.
-
Thank you; that works.
Quite a bit of fiddling around afterwards to make it understand that the project I actually want built is the one set "Active" :)
There are two places where it needs to be set Active, if you want this button to actually build the one set Active
(https://peter-ftp.co.uk/screenshots/20210811553653012.jpg)
I realise there are multiple levels of indirection here, with global settings and project settings, but one would surely expect this to do what it says
(https://peter-ftp.co.uk/screenshots/20210811143663212.jpg)
They key seems to be to have Use Active here
(https://peter-ftp.co.uk/screenshots/20210811573671313.jpg)
The other thing which caught me is that the Build Analyser window shows the data for the last build, which is not the same thing as what you are sending to the debugger. This is bloody confusing. The only time the build is updated is when you edit a source file (etc).
-
The build analyzer isn't always updated as you build the project.
When that happens, clicking somewhere in the project files will update it. Or in most cases.
-
Yes that's true. Hilarious! :)
Thank you.
How can anybody release something which is so obviously broken?
Another bug:
In the c:\product\project1\release and c:\product\project1\debug directories I have batch files for crc appending. These batch files vanish on each build. No kidding. They just vanish. If I build Debug, the debug-crc.bat vanishes. If I build Release, the release-crc.bat vanishes. This f-ing program must be doing del *.* on the build directory.
So I have to put anything I want to keep elsewhere. Well, I can see rm -rf * appearing in the console, so no wonder...
Usually you also get
(https://peter-ftp.co.uk/screenshots/202108114012773018.jpg)
because the debugger has locked the file.
-
Everything gets deleted because you tell it to rebuild everything. The build directories are always temporary for any IDE. Scripts and stuff go into a scripts directory in the root of your project.
Also don't forget to set the indexer for the C language to use the active build configuration.
-
I did notice that sometimes, after I switch builds, it does a re-index. Is this a config item? I looked everywhere.
BTW, re that issue where Cube tends to fail to delete the .elf file because it is locked by the debugger, which it often is, it is the rm command which fails, presumably because it has insufficient privileges. At the end of the the build, Cube deletes that elf file ok by itself (usually; not always). I did explore solutions like Handle which can be run as a pre-build batch file to kill the process holding the elf file, but it is probably ok.
Found something else curious. This is the batch file I use for generating the CRC-appended .bin file
cd c:\kde420\project1\release
arm-none-eabi-objdump -h kde2020.elf > objdump.txt
if exist file.dat del file.dat
arm-none-eabi-objcopy -S --strip-all -R .bss -R .main_heap -R .ccmram -O binary kde2020.elf file.dat
c:\kde420\crcgen\addcrc file.dat 0xffffffff
Now look at how the 2nd line looks in the console:
(https://peter-ftp.co.uk/screenshots/202108111512784420.jpg)
Where has that "1" come from?
I don't think it is affecting the generation of the dump file. Of course > (and >> to append) can be used in "DOS" and win16/win32 command line batch files but maybe Cube is presenting some strange environment here. I googled around but found nothing.
-
In cmd.exe (the basic/old Windows shell*) '1>' means (as in Unix shells) to redirect the standard output to the following file.
You can also use 2> to redirect standard error, (and <3 if you love your batch files :P).
As this batch is invoked as a post build action by the IDE, it's probably "rewritten" to be correctly executed.
Mysteries of Eclipse.
* The good shell is PowerShell, but cmd is faster to launch in many cases, and has been widely expanded with respect to the DOS times.
It is now almost respectable (arithmetic, string parsing, conditionals etc etc).
-
I posted a short list of what I would consider required reading before voicing an opinion about about the STM32 family and its infrastructure:
https://www.eevblog.com/forum/microcontrollers/gcc-compiler-optimisation/msg3632779/#msg3632779 (https://www.eevblog.com/forum/microcontrollers/gcc-compiler-optimisation/msg3632779/#msg3632779)
Documentation for features that have no influence on the current design may be skipped. Finding those out may not be trivial.
-
The locked file is a minor bug that happens sometimes. Just restart the ide :-+
-
Quoting DavidAlfa from the GCC optimization thread:
Not that kind documentation. A proper guide/manual for the HAL.
You have a simple one, barely describing what each function does. But you still have to guess a lot of things.
I understand what you mean. However, your comment brings me to my biggest gripe about CubeIDE/"HAL": it suggests to beginners (anybody not familiar with this device family) that they can develop production quality code without working their way through the available documentation.
-
"The locked file is a minor bug that happens sometimes. Just restart the ide"
You also have to terminate the debugger process in process explorer.
But actually this doesn't matter because while the "rm" command refuses to delete the .elf file (when cleaning up the Debug, Release or whatever directory) that is due to it having insufficient privileges. Cube itself has sufficient privileges to delete the file when it finishes compilation/linking. No idea what is going on.
"that they can develop production quality code without working their way through the available documentation"
I think the "truth" is somewhere in the middle. The code generator is useful for generating functions which do what you specified, more or less, and you are free to hack them around. This is much easier than reading the 2000 page RM, which is best used to resolve specific issues. This is one example (RM page 894)
(https://peter-ftp.co.uk/screenshots/20210818533692812.jpg)
I reckon you can test 1 and 2 at the same time because if both are appropriately set then all data has been sent out, and every "UART" I have ever used works like that (and usually you can just test the "all sent" bit only) and CS can be raised (after waiting for any pre-CS delay, with a non-optimisable inline-asm delay). But the RM doesn't say that. It says you have to test one and then test the other. So I copied the RM (last two lines):
__HAL_SPI_ENABLE(hspi);
}
/* Transmit data in 8 Bit mode */
// The need for this initial byte is unknown
if ((hspi->Init.Mode == SPI_MODE_SLAVE) || (initial_TxXferCount == 0x01U))
{
*((__IO uint8_t *)&hspi->Instance->DR) = (*hspi->pTxBuffPtr);
hspi->pTxBuffPtr++;
hspi->TxXferCount--;
}
while (hspi->TxXferCount > 0U)
{
/* Wait until TXE flag is set before loading data */
if (__HAL_SPI_GET_FLAG(hspi, SPI_FLAG_TXE))
{
*((__IO uint8_t *)&hspi->Instance->DR) = (*hspi->pTxBuffPtr);
hspi->pTxBuffPtr++;
hspi->TxXferCount--;
}
}
// Wait for last byte to get shifted out - needed before CS is raised!
// Two tests done as per the RM text
while (__HAL_SPI_GET_FLAG(hspi, SPI_FLAG_TXE)==1) {} // wait for tx buffer empty
while (__HAL_SPI_GET_FLAG(hspi, SPI_FLAG_BSY)==0) {} // wait for tx shift reg empty
Also the HAL code doesn't disable the SPI. I don't see why it should... the clock stops when you stop stuffing bytes into the transmitter!
There are many discrepancies. And some of these are real, and can get exposed by compiler optimisation
https://www.eevblog.com/forum/microcontrollers/gcc-compiler-optimisation/200/ (https://www.eevblog.com/forum/microcontrollers/gcc-compiler-optimisation/200/)
-
Quoting DavidAlfa from the GCC optimization thread:
Not that kind documentation. A proper guide/manual for the HAL.
You have a simple one, barely describing what each function does. But you still have to guess a lot of things.
I understand what you mean. However, your comment brings me to my biggest gripe about CubeIDE/"HAL": it suggests to beginners (anybody not familiar with this device family) that they can develop production quality code without working their way through the available documentation.
It's actually even harder, on baremetal you must do everything yourself, but with an already made library, hah! First, decrypt how it works internally!
Something simple as using DMA UART. Does is say anywhere that you must enable UART interrupt also? Nope, then you'll find that nothing works.
Not that obvious, for example DMA SPI works perfectly without spi irq. I must admit I'm happy with HAL now. But the learning curve was not easy.
Thats' the point of the libraries, they do the hard work for you, but they also should be dwell ocumented, otherwise it's even worse.
-
While on Cube IDE...
Is there anyone here familiar with Cube and Windows 7-64?
The system requirements (such as I can find for Cube MX) suggest win8.1 is the latest supported (presumably for Cube 1.7) which in practical terms (v8 was crap) means win10 only.
However, I originally set up v1.4 (current version c. Jan 2021) on win7-64, and that still installs fine. Been testing that in a VM. However, while I was able to auto update Cube to 1.6.1 and that still runs fine on the win7-64 machine, I cannot install 1.6.1 (or update 1.4 to anything if using the Cube auto update, and v1.7 is the only option now on offer) on the VM version (win7-64 SP1).
Cube is not a standalone executable and uses a fantastic amount of resources and libraries, notably Visual C++ redist v15 and v17 and these are notoriously hard to install, with cryptic installation errors, and desperate people posting all over the internet trying to find solutions to those errors. I suspect one cannot install VC++ 2015 after MS dropped win7 support. Done a fantastic amount of googling over past 2 days and most of the error messages point to VC++ 2015 for which I can't find a package which actually installs, and I suspect that is the key to why I have 1.6.1 running ok on the two machines which were continuously auto updated before MS dropped win7 updates.
Unfortunately Java is where Windows was 20-30 years ago, when every chest-beating programmer (well, those paid per line of code ;) ) would generate one .exe and 100 DLLs. Now we have Cube with 2-3GB of Java files :) Some of the pathnames are so long that they are near the Windows max path length and if you copy them, the copy fails because the machine UNC name takes it over the limit :)
I posted also here https://community.st.com/s/question/0D53W000011uLwPSAU/cube-ide-installation-under-win764-sp1
but one rarely gets any response there due to the sheer quantity of posts.
The reason for this exercise is to produce clear installation documentation for the project I am working on. I am documenting everything as soon as I do it. Industrially, win7-64 is widely used on desktops although laptops are more likely to be win10.
-
peter-h, I checked that on a fresh, throwaway VMware Win7Home-64 (i7 4GB RAM 60GB SSD internet access):
Cube1.7 fails to start.
Cube1.6.1 fails to start.
Cube1.5.1 installs and is able to build existing projects.
Cube1.4 installs and is able to build existing projects.
Cube1.3 installs and is able to build existing projects.
CubeIDE1.3 .. 1.5 offer to upgrade to 1.7. The upgraded CubeIDE fails to start. Same error as a fresh 1.7 install, see attachment. The attachment is from 1.5.1 upgraded to 1.7.
Feel free to use this information, especially the error message, in your interaction with ST support.
-
Thank you Harerod - that confirms what I found.
However I have 1.6.1 running on two win7-64 machines, both of which were online upgraded from 1.4, so what's different?
What is the VC++ distro status on your VM? On one of the base machines I seem to have the whole lot :)
(https://peter-ftp.co.uk/screenshots/202108190212860919.jpg)
This is the other running base machine
(https://peter-ftp.co.uk/screenshots/20210819293751019.jpg)
Both also have Java although I suspect that isn't relevant because I tried installing that, and Cube seems to dump 2-3GB of its own Java libs to c:\ST...
Would it be possible for me to retain a working Cube 1.4 install package (a documented install from the ~700MB .exe, not a VM which is ~15GB) and compile my existing code to the same binary as 1.6.1 generates? Isn't the compiler a different version in Cube 1.4 to Cube 1.6.1? If it is different, could the 1.6.1 compiler be back-patched to 1.4?
I would hate to be limited to win10 for this job.
My gcc compiler appears to be 9.3.1 20200408.
-
Please see attachment. For your other questions have a look at RN0114.
https://www.eevblog.com/forum/microcontrollers/gcc-compiler-optimisation/msg3632779/#msg3632779 (https://www.eevblog.com/forum/microcontrollers/gcc-compiler-optimisation/msg3632779/#msg3632779)
-
Yes; I think VC++ 2008 is not good enough for anything past Cube 1.4. Those error messages (exactly what I get) persistently google to VC++ 2015 missing, but try installing that into your win7-64 VM ;) I've spent 2 days on it. One gets various 8 digit hex codes which then google to hundreds of posts by desperate people, answered mostly by conmen selling "fix your drivers" products, or on Micro$oft forums with useless replies :)
Funny thing is that that .dll is actually on the hard disk! But probably an old version, which is missing that call.
My gcc is 9.3.1 20200408.
-
So let's recap...
Cube and ST's HAL...
* are broken
* are undocumented
* are difficult to install
* require steep learning curve
* require lot of work around the internals, including fixing unfixed bugs
... and the reasons to use them is because
* They work well and provide high quality code, MISRA and all
* Are quick to install
* Don't require the steep learning curve you would face without them
* Don't require understanding of the internals, just use, job done
* Don't even need documentation because of the ease of use
Did I get this right?
-
As usual the truth is somewhere in the middle. >:D
-
Is the compiler a single .exe (as it appears to be) compiled for x86, or something in Java?
If the former then moving the compiler from cube 1.6.1 to Cube 1.4 should work, no?
I am going to spend one more day trying to set up a win7-64 VM with VC++ redist 2015 :)
-
So let's recap...
..
I think yes. You use what works. And work around problems. I think software design at that level isn't completely logic anymore, but more like psychology. The days of "clean design" and "bare metal" are gone. Nobody - not even the makers of those MCUs - can tell you the last detail nor predict what will happen after the next silicon or HAL revision. The SPI ambiguity mentioned above is a good example. Obviously the reference manual contains dead information that may have applied in the past but is no longer true. So it is good we have both HAL and a reference manual.
Anyway nowadays we can't rely on anything but have to implement automated test procedures to guarantee a product works. We have to repeat those tests and solve issues after each and every revision. I admire those developers who dare to publish an IDE supporting thousands of MCU variants. It starts with Arm technology being a disaster in complexity.
Regards, Dieter
-
As usual the truth is somewhere in the middle. >:D
Or there are many different "truths".
Whoever used the Cube for 20 different projects and knows nothing about the underlying hardware cannot live without Cube. Someone who knows the hardware wonders why would he need the Cube. The choice is who of these two you want to be.
-
Whoever used the Cube for 20 different projects and knows nothing about the underlying hardware cannot live without Cube. Someone who knows the hardware wonders why would he need the Cube. The choice is who of these two you want to be.
Even the latter only if that person only has to cope with single uCs family or has years of exoerience on more.
If that person knows for instance the F2 and F4 series and his boss wants to cut down costs of an existing project by switching to the F1 series, he might be in a potential minefield. Reading all the errata of the F1 series and checking all peripheral workarounds with their existing codebase might still cost tons of work not to mention the testing and certification of the end product. Guaranteed something is overseen and does not work as expected. A quickly generated Cube project and checking if the peripheral works as expected in that case might help. Checking the deviation in order of initializing and the calls for using a peripheral might than be a timesaver.
-
Also in perspective, we will use AI like systems and then there won't be a choice. Even the best chess players are loosing against computers nowadays.
Regards, Dieter
-
I think the % of people programming a 32F4 or similar who actually read the RM, and who are hardware experts as is required to understand much of that, is quite small.
I've been doing hardware for decades, including FPGA design, so I understand what I am reading in the RM, but the interaction of the various configs, e.g. the pin assignments, DMA channels, etc, is quite complex.
So a code generator which gets you started, especially with stuff like clock divider configs where a code generator works naturally well, is useful. It is a pity that ST's code generator is not more granular - see e.g. the HAL SPI function above, which tests loads of conditions which may or may not apply at all.
I am going to waste another day of my life to try to work out what actually can be made to work under win7-64. I know Cube 1.6.1 works (on two machines) but special conditions apply. And 1.7 may work also. Somebody in ST may know... but those people rarely post.
Wasn't there some site which enabled M$ updates to be applied as if they came from M$?
The usual error is 0x80240017 and with no apparent solutions.
-
Does anyone know how to copy a 1.6.1 Cube installation to Cube 1.5?
If copying 1.6 to 1.6, the easy way is to install Cube on the 2nd machine and copy over the project (in my case c:\kdexxx\project1, which also contains c:\kdexxx\ide for some reason) and then copy over the configuration directory which is under c:\ST. Then it all just starts up fine.
But this doesn't work for 1.6.1 to 1.5. I get all sorts of problems like it cannot find the toolchain, etc. And as previously discussed
https://www.eevblog.com/forum/microcontrollers/how-to-duplicate-a-st32f4-cube-ide-project-on-another-pc/msg3568595/#msg3568595 (https://www.eevblog.com/forum/microcontrollers/how-to-duplicate-a-st32f4-cube-ide-project-on-another-pc/msg3568595/#msg3568595)
the various "import" or "open project" functions in Cube don't work.
I also notice that 1.5 uses a "workspace" directory which is under c:\users which 1.6 does not use. There are bits of this crap all over the place and different Cube versions used different places.
BTW Cube 1.5 has a compiler version 7.3.1 20180622. Cube 1.6.1 is 9.3.1 20200408.
EDIT: after a few hours I worked it out. When Cube is installed initially (a clean install, with all of its directories deleted beforehand) it presents you with a list of options for opening existing projects, and one of these actually worked! You do not get that option with an existing working Cube installation if you just want to open a new project. It is a right POS.
Funnily enough -Og builds a smaller project (159k v. 162k) using the v7 compiler :) I did try to load the 1.6 .exe tools into the 1.5 directory structure but that just blows the whole thing up :)
It is quite fun to be able to build the same project on the base machine, or inside a VM. You can't share the same debugger though, or at least I have not found a way, probably due to USB conflict. But the VM Cube can certainly drive a different debugger, and could drive a different target, so you could run two targets concurrently. I believe you can do that anyway, with two copies of Cube running on the base machine, but the advantage of a VM is that you know there is no accidental cross-linking of files. The project inside the VM is 100% definitely self-contained, plus the whole VM can be moved to another machine very easily which is obviously impossible with a base machine installation of Cube, which is tightly linked into the base OS.
I just wish I could install the VC++ 2015 or later redists in the VM. I've posted the Q in various places and will advise if I ever solve this. Cube 1.5 works ok (with the same bugs as 1.6 e.g. the Build Analyser works only at xmas) but with 1.6 you would get the v9 compiler. But is v9 any better?
-
Also in perspective, we will use AI like systems and then there won't be a choice. Even the best chess players are loosing against computers nowadays.
Sure. Eventually AI surpasses humans in every aspect. This will be the end of human dominance on the planet.
-
Well, this is interesting:
https://www.eevblog.com/forum/microcontrollers/stm32cubemx-install-on-macos-broken/ (https://www.eevblog.com/forum/microcontrollers/stm32cubemx-install-on-macos-broken/)
Is anybody reading this, who has CubeMX running in an ?NIX-environment? How is your experience debugging with Segger J-LINK and ST-Link? My current setup is CubeMX 1.3 under either Win7-64 or Win10 and J-Link is rock solid.
I mean "never change a running system", but it wouldn't hurt to know alternatives to Win10++.
-
Also in perspective, we will use AI like systems and then there won't be a choice. Even the best chess players are loosing against computers nowadays.
Sure. Eventually AI surpasses humans in every aspect. This will be the end of human dominance on the planet.
Through human-made tools. :-DD
-
Just downloaded and installed en.stm32cubemx-lin_v6-3-0_v6.3.0.zip on a Debian Jessie 64. Fast and easy and started working without any complaints. Maybe i will try other parts of cube as well.
Before i have been using CubeMX 6.0.0 under W7 Pro 64 (offline workstation).
I learned FPGAs with XILINX Spartan 3 and roughly know the difference between computer aided design, an expert system and an AI system. STM32Cube is an expert system and it serves the same purpose as the expert system used for instancing logic on a FPGA. You can't do that "bare metal" and this has been a reality for 20 years or so.
Regards, Dieter
-
It's fairly easy to use non st tools, I have fully reproducible builds using docker containers that contain arm-none-eabi-gcc.
Much better than having lots of 20 GB virtual machines around
-
Well, this is interesting:
https://www.eevblog.com/forum/microcontrollers/stm32cubemx-install-on-macos-broken/ (https://www.eevblog.com/forum/microcontrollers/stm32cubemx-install-on-macos-broken/)
Is anybody reading this, who has CubeMX running in an ?NIX-environment? How is your experience debugging with Segger J-LINK and ST-Link? My current setup is CubeMX 1.3 under either Win7-64 or Win10 and J-Link is rock solid.
I mean "never change a running system", but it wouldn't hurt to know alternatives to Win10++.
All the tools work perfectly fine on Linux.
(Though to be fair, they also work fine on an up-to-date Windows system, if you're not dedicated to trying to break them in unique ways so you can then complain.)
But really, if your local user has full permission to the installation directories of these tools, you're unlikely to have any issues when updating them.
The OSX issues stem entirely from the platform's more unique approach to permissions, combined with software developed by a company that doesn't really focus on Mac support as much more than an afterthought. (Which is kinda a common issue with anything developed by a large organization who's developers aren't heavily involved in the unique peculiarities of the Apple developer ecosystem.)
My main development system is running the latest version of Fedora Linux, where all the ST stuff has worked perfectly fine for me.
(But I also run the tools on a Windows 10 machine at my lab bench, and a MacOSX laptop, depending on the situation.)
-
the only issues I have running cubemx and the cube programmer on fedora are:
Cubeprogrammer will only launch properly when running x11. will not launch on wayland
Cubeprogrammer will fail to launch the stlink firmware updater.
The installers etc are much better than they used to be now that they include a bundled version of java (openjdk). They now "just work" (tm)
-
Just heard that you can run a win10 VM under any version of Windows (and presumably other OSs) and since win10 seems to be the baseline for Cube now, that ought to work. No need for win7-64 as the lowest common denominator.
-
Just heard that you can run a win10 VM under any version of Windows (and presumably
other OSs) and since win10 seems to be the baseline for Cube now, that ought to work.
No need for win7-64 as the lowest common denominator.
A major reason why one would prefer Eclipse/GCC over IAR or KEIL in a professional context, with a long product lifecycle, is that the tool comes without a dongle and without an internal killswitch. Same as using Kicad or EAGLE7 instead of modern EAGLE. With any Windows version up to and including Win7-64, I know of a legal way to set up a virtual machine that can be reactivated offline anytime.
As far as I know, that same triviality would require a special version of Win10. I would love to have that statement proven wrong.
This is the major reason why I am interested in the development at the ?nix-front. And no, I am not married to Win7. That last machine is only operative, because it holds some old perpetual Adobe and Microsoft licenses. There are three Win10 machines and one Linux box here as well.
Another plus regarding GCC is that a broken IDE shouldn't be a showstopper for a competent developer. One could always build from the command line. And that brings me to the reason why I don't find CubeIDE all that painful - I have seen and worked with other STM32 development tools in the last fifteen years: aside from IAR-EWARM, I remember GCC with make, homebrew Eclipse with openOCD, CooCox, Atollic and now CubeIDE. The thing is - I could still use GCC with make, but somehow I find a carefully setup CubeIDE 1.3.0 more appealing for handling 435 source files in three production build configurations. (mainboard STM32F407-firmware for current project, FreeRTOS, LwIP, wear-leveling filessystem in MCU-FLASH and -CCM, several UARTS, SPI, I2C, USB, all the classic peripherals). Btw, I only started using CubeIDE/CubeMX last spring. Since then I have build five commercial designs, three STM32F4 and two STM32F1.
-
I learned FPGAs with XILINX Spartan 3 and roughly know the difference between computer aided design, an expert system and an AI system. STM32Cube is an expert system and it serves the same purpose as the expert system used for instancing logic on a FPGA. You can't do that "bare metal" and this has been a reality for 20 years or so.
Sure you can. You can manually instantiate every element - LUT, flops, BRAM, DSP. You can place them at will. You can even do custom routing at will. ISE had XDL language, sort of an FPGA assembler, which describes the elements, settings, and routing. ISE compiles VHDL (or Verilog) code into XDL then it gets transformed into a bitstream. Pretty much like the C code compiles into assembler and then the assembler code gets transformed to binary/hex.
Now Xilinx switched to Vivado, which doesn't have XDL, but you still can write pure structural VHDL/Verilog and do low-level things with TCL scripts if you wish.
-
I have paid for software I actually use, and too would avoid anything online-licensed because it will die once the license servers stop working. Look at how Adobe killed CS3; they had to give away CS2 keys for free to get around the outcry.
IMHO if you have paid for software then nobody can complain if you fix it so it continues to work for ever. I have late-1990s CAD/EDA software which works perfectly and which has been de-dongled.
WinXP seems to run for ever now; it looks like MS no longer implement deactivation if the hardware changes. Also it uses offline activation - just a key. So XP is popular for industrial/test rigs because you can be sure it won't suddenly blow up. Win2000 was even better (no online activation at all) but much less solid than XP. Also XP runs fine indefinitely with no internet access which is important in many scenarios. Win7 is heading that way; I recently changed a VM from 1 CPU to 2 CPUs (stupid move) and it said the OS is counterfeit (it wasn't) but that message never reappeared (but I am sure it did some sort of online reactivation). So MS probably is still running online activation for win7. Also there are easy hacks for win7. With Win10 it will be a long time before it reaches that "safe" stage. All that will happen soon is that when win11 comes out, you will be able to buy a legit win10 license on Ebay for 30 quid :)
I've been using Cube for 8 months now and it is certainly usable. Irritating bugs, but it does the job and is free. Sometimes I am writing and debugging code several hours a day. If there was a course on it, I would do it but nobody runs them. You just get Youtube videos which tend to be a useful overview but you can't ask questions.
Is IAR a floating license? That is a nightmare for long term projects.
-
I learned FPGAs with XILINX Spartan 3 and roughly know the difference between computer aided design, an expert system and an AI system. STM32Cube is an expert system and it serves the same purpose as the expert system used for instancing logic on a FPGA. You can't do that "bare metal" and this has been a reality for 20 years or so.
Sure you can. You can manually instantiate every element - LUT, flops, BRAM, DSP. You can place them at ..
Now Xilinx switched to Vivado, which doesn't have XDL, but you still can write pure structural VHDL/Verilog and do low-level things with TCL scripts if you wish.
No, that approach may have been practical for CPLDs, but not for FPGAs. With FPGAs you won't get anywhere within your lifetime. Nowadays we use abstraction to get things done, including constructs predefined by others, e.g. language contructs or configurable IP. And the same happens with MCUs.
Regards, Dieter
-
Don't people use "schematic capture" (a once fashionable term for drawing a circuit diagram)? I did loads of Xilinx X3000 FPGA design (using Viewlogic 4 + XACT 5 - two dongles!) and drew all the circuits. When I had to implement a state machine I used a Viewlogic utility which converted the boolean equations into a logic circuit diagram and merged that in.
Can't see where Cube would work in that way. It is just for text, AFAICT.
Nowadays CPUs must be designed using a language, which is compiled to the logic.
-
The entities in a schematic are abstract, they don't exist in the FPGA. With an MCU you use language abstractions and trust the compiler implement them right (loops, arrays, pointers whatsoever). With cube you have a graphical configuration utility to configure abstract entities and you trust it to implement it right.
Of course there needs to be verification. It can be automatic, like measuring the actual CPU clock using some other redundant clock, or checking actual RAM size. Verification can also be manual, like looking into configuration registers at debug time.
Regards, Dieter
-
Nowadays we use abstraction to get things done, including constructs predefined by others, e.g. language contructs or configurable IP.
Sure you do. But since you think that this is the only way, what's your alternative?
The entities in a schematic are abstract, they don't exist in the FPGA.
You can create a schematic which uses logic ICs, or you can create schematic which uses built-in hardware blocks in FPGA, or you can create schematic which uses discrete FETs, or you can create schematics which uses abstract logic gates and registers. These will all be different schematics, but will do the same thing. If, for some reason, you need to produce all of these, you can write abstract Verilog code and use various tools on the same code to create all these schematics automatically. Write once, run everywhere. This is an example of a good abstraction.
But, if you want to build a bitcoin FPGA farm which produces $10M/year, and then you decide to use abstract Verilog code which is 10% slower and consumes 10% more power over what you could have developed specifically for your target FPGA, this is pure stupidity which costs you $1M/year.
As any tool, abstractions may be good or bad. For example, when you write a program for PC, there are graphics drivers which create an abstraction layer. With this model, you can write your program without even knowing what PC it will run on. Your program will run fine even on PCs with graphics adapters which hasn't been designed yet. My programs from last millennium runs fine on modern PCs. How wonderful.
Or look at the TCP/IP protocol which uses abstract packets and can be used seamlessly with different transport layers. This is a useful abstraction and 50-year old TCP/IP is widely used now even though technologies made a huge leap forward.
Or C. You can use it to write code and compile it for different CPUs. Isn't it amazing?
On the other hand, nowadays "abstraction" is used to create tremendous amount of bloat making today's software 100x and 1000x times bigger, slower, and more complex that it could have been. This introduces lots of bugs which are nearly impossible to fix, and this is getting worse and worse. That's a different kind of abstraction. People get obsessed with this form of abstraction. Perhaps not so much embedded developers, but the so called "full stack" developers. They perceive all this tremendous bloat as useful and necessary, while it is clearly harmful.
So, a designer needs skills to implement good abstraction, needs guts to reject bad abstraction, and needs brain to tell them apart.
-
After a few hours' work I can confirm Cube 1.7 installs and runs under win7-64 SP1.
It also builds my existing 1.6.1 project, to a binary image of exactly the same data - crc32 checked!
Compiler version is: gcc version 9.3.1 20200408 (release) in both Cube 1.6.1 and 1.7.0
More detail:
I started with an old win7-64 VMWARE VM. Made sure there was >10GB free space left I was able to install SP1 (downloaded from https://blog.simplix.info/update7/ which is a brilliant resource).
Then applied VC++ 2019, from M$ website.
Then I applied all updates up to August 2021, again using the above site. These updates are normally available only to paying M$ contract customers (M$ stopped auto updates for win7 a while ago). I have no idea if this last step makes a difference, or whether SP1 with the VC++ stuff is enough. But I am quite sure VC++ 2015 or preferably 2019 is required for Cube 1.6.1 or 1.7.0.
Then installed Cube 1.7.
Being a virgin Cube install, it shows
(https://peter-ftp.co.uk/screenshots/20210823463774215.jpg)
Choose Import Projects
(https://peter-ftp.co.uk/screenshots/20210823193784315.jpg)
My project is in c:\kde420\project1
(https://peter-ftp.co.uk/screenshots/20210823553794315.jpg)
and it opens it and it all works!
Have ST fixed the Build Analyser not showing up bug? Not really. It does now show up on the second build :)
I can see some changes e.g. more here
(https://peter-ftp.co.uk/screenshots/20210823373805115.jpg)
so they probably did change a whole lot of stuff, none of it documented in the official change log. I notice that F5 and F6 seems to work more reliably. F6 (step over) often stepped into the function.
To run Cube in a VM you need to check the "shared STLINK" box otherwise you get verify errors on the STLINK code load.
-
There is a variety of issues running Cube in a VM if you are using a debugger, due to USB device sharing issues. Well, a USB device cannot be shared :)
I successfully ran one Cube on the base machine, to one STLINK debugger, and another Cube in a VMWARE win7-64 VM to another STLINK debugger. The debuggers were STLINK 3 & STLINK 2 but that is probably not material. So this way you could run two (perhaps interacting) targets, two debuggers - potentially useful!
What is more messy is if you have a debugger connected and then start the VM. The VM will not pick up the USB device(s) because the base machine is holding them. You have to, as a minimum, unplug and replug the debugger USB cable and then the VM should pick up the debugger. And same if running the USB VCP for debug text. It isn't all that reliable, and I've had WMWARE do a BSOD which is otherwise very unusual.
-
A further data point:
I decided to take the risk and update the 1.6.1 Cube on my win7-64 PC. I had previously tested it in a VM.
Installed the latest x32 and x64 VC++ redist package "2015-2019". This is essential, though it's not clear which exact VC++ version is needed by which Cube version. I think 1.6.1 needs VC++ 2017.
Updated Cube 1.6.1 online to 1.7.0.
It also offers to update the USB driver, and then the firmware in the STLINK V3 debugger.
As noted above, the compiler version is the same as 1.6.1 and the generated binary is identical byte for byte.
Most curiously, after 1.7 installs you get a PDF release note pop up which gives the system requirements as win7-64 or higher:
(https://peter-ftp.co.uk/screenshots/20210826083822316.jpg)
The other Cube "system requirements" I saw, somewhere on the ST website, stated win8.1 or higher. This new PDF is called DM00603738.pdf.
Fixed issues: https://wiki.st.com/stm32mcu/wiki/STM32CubeIDE:STM32CubeIDE_errata_1.7.0
It does overwrite the project dir irreversibly so you can't go back to a previous version (it says).
SWV ITM data console is now much more reliable; that's an immediate benefit.
-
There is a variety of issues running Cube in a VM if you are using a debugger, due to USB device sharing issues. Well, a USB device cannot be shared :)
I successfully ran one Cube on the base machine, to one STLINK debugger, and another Cube in a VMWARE win7-64 VM to another STLINK debugger. The debuggers were STLINK 3 & STLINK 2 but that is probably not material. So this way you could run two (perhaps interacting) targets, two debuggers - potentially useful!
What is more messy is if you have a debugger connected and then start the VM. The VM will not pick up the USB device(s) because the base machine is holding them. You have to, as a minimum, unplug and replug the debugger USB cable and then the VM should pick up the debugger. And same if running the USB VCP for debug text. It isn't all that reliable, and I've had WMWARE do a BSOD which is otherwise very unusual.
Maybe they are VMWare issues, not "VM" issues?
Ive run my STM32 Eclipse devel environments under VirtualBox (Win10 host, Linux clients) for 5+ years. I've had very few USB problems.
-
Yes it works ok if you aren't trying to use the same debugger from either the VM or the base machine, and keep swapping around.
Maybe it can be done reliably if one knows about the VM config intricacies.
BTW I have just done the same 1.7.0 update on a freshly updated win10 machine and that also needed the VC++ "2015-2019" update. Win10 doesn't do that automatically.
-
The latest Cube, 1.7.0 still has not fully fixed the "invisible lines" issue, where much of the text scrolling up the console window during a build is invisible, probably due to being in a white font.
The issue has improved, with two win7-64 machines now ok, one win10 ok, one win10 not ok. The last one is used by a guy writing software and he has to swipe the invisible text and paste it to Notepad, to see the error messages :)
In all cases, if the machine is accessed via Remote Desktop, the text is fully visible.
-
The latest Cube, 1.7.0 still has not fully fixed the "invisible lines" issue, where much of the text scrolling up the console window during a build is invisible, probably due to being in a white font.
The issue has improved, with two win7-64 machines now ok, one win10 ok, one win10 not ok. The last one is used by a guy writing software and he has to swipe the invisible text and paste it to Notepad, to see the error messages :)
In all cases, if the machine is accessed via Remote Desktop, the text is fully visible.
I will half-heartedly pretend to defend ST here:
That's Eclipse crap for you. I have exactly the same in MCUxpresso (not that I use it unless I feel masochist).
In frigging 2021 Eclipse can't still have a decent dark theme...
Pedant mode on: Cube is actually the library/driver packages or more generally speaking the whole ecosystem including STM32CubeMX, STM32CubeProg, and STM32CubeIDE (and other stuff, probably).
-
I never had the invisible lines bug, mayeb it's related to windows 7 and/or the java version.
I've always used w10 - now w11- and definitely not happening.
Unless you install themes. Themes are custom mods, might not be correctly done or be outdated.
I recall having such text issues after installing a dark theme, text color was the same as background's.
It's not ST's or Eclipse's fault, it's the theme.
-
The latest Cube, 1.7.0 still has not fully fixed the "invisible lines" issue, where much of the text scrolling up the console window during a build is invisible, probably due to being in a white font.
The issue has improved, with two win7-64 machines now ok, one win10 ok, one win10 not ok. The last one is used by a guy writing software and he has to swipe the invisible text and paste it to Notepad, to see the error messages :)
In all cases, if the machine is accessed via Remote Desktop, the text is fully visible.
I will half-heartedly pretend to defend ST here:
That's Eclipse crap for you. I have exactly the same in MCUxpresso (not that I use it unless I feel masochist).
In frigging 2021 Eclipse can't still have a decent dark theme...
Pedant mode on: Cube is actually the library/driver packages or more generally speaking the whole ecosystem including STM32CubeMX, STM32CubeProg, and STM32CubeIDE (and other stuff, probably).
Well, I have to defend Eclipse here.
I am using native Eclipse for years and didn't have any issues like that.
Maybe the vendors mess something up?
-
It's not ST's or Eclipse's fault, it's the theme.
Not a platform problem, I have the same on Linux, Win 10 & 11. nVidia or AMD graphics, Intel or AMD CPUs.
The dark theme is the one available in both STM32CubeIDE or MCUxpresso, and as far as I know provided by Eclipse, not a vendor thing.
But hey, IDEs are a personal preference. I simply can't stand it.
-
I never had the invisible lines bug, mayeb it's related to windows 7 and/or the java version.
I would also strongly suspect it's related to the specific JVM that's bundled with their IDE for this specific platform.
I do also strongly dislike Eclipse anyway. To each their own. But if you use your own favorite tools while going a little bit more baremetal with the MCUs, you'll become a much happier camper in the end. That's almost a guarantee.
-
I am using native Eclipse for years and didn't have any issues like that.
But that's exactly the problem.
JW
-
Well, it is more complicated because of inter-dependencies like clock configs, alternate functions, half the UARTs/SPIs/whatever are not usable because the pins are used for other stuff. Setting up that sort of stuff is a great use for a GUI.
What they COULD focus on is a resource planning tool, as this puzzle is an NP-complete problem. That's all. Document the peripherals properly (which they mostly do, but you better read ALL the fine print), use canonical nomenclature, and explain how to set up common use cases (which they also mostly do). Leave the code end to me, because looking both at code using HAL and its implementation makes me just go... WUT. :-// It looks like someone's school project.
-
Well, it is more complicated because of inter-dependencies like clock configs, alternate functions, half the UARTs/SPIs/whatever are not usable because the pins are used for other stuff. Setting up that sort of stuff is a great use for a GUI.
What they COULD focus on is a resource planning tool, as this puzzle is an NP-complete problem. That's all. Document the peripherals properly (which they mostly do, but you better read ALL the fine print), use canonical nomenclature, and explain how to set up common use cases (which they also mostly do). Leave the code end to me, because looking both at code using HAL and its implementation makes me just go... WUT. :-// It looks like someone's school project.
Nothing is stopping you from using CubeMX to plan and then implementing the code yourself? What am I missing here.
-
Cube does not need one to separately install Java, BTW. Some of these machines have Java, some haven't.
"Nothing is stopping you from using CubeMX to plan and then implementing the code yourself? What am I missing here."
I have not used MX (the code generator) because I have just been writing the "functional" software on this project, but the other guy working on it does that. I guess a lot of people also do - because it saves hours going through the RM trying to work out which peripheral can connect to which pins, etc. I haven't yet got stuck into that part (the AF settings etc), but most people seem to do it by calling some huge ST HAL function.
The problem with MX is that if you later modify the code, it obviously doesn't reflect itself in the original design. For example the very pretty diagram of the clock config (which is useful for documentation) cannot be updated if you changed say PCLK1 in the code.
" It looks like someone's school project."
It does - like seeing a hardware design where somebody used a 10.1k resistor instead of 10k, where anything from 5k to 20k would have been fine :) But there is an amazing lot of that around; we just don't expect it in software...
-
Just installed Cube v1.8 (in a VM just in case) and
new: 341k 348,560 bytes in 1.8
old: 341k 348,560 bytes in 1.7
So, no change in the compiler version or any of the libs we use :)
The Big Q is whether they have fixed the "white text"...
-
Check the documentation, all the new stuff is explained there.
-
They only ever list a small subset of issues there :)
-
First of all, don't mix IDE and compiler.
The IDE receives updates more frequently, usually fixes for CubeMX and the IDE itself.
However the compiler is updated very few times a year. Maybe once or twice, if any.
ALso, most updates will be for newer devices, so it'll be the same thing for older ones.
-
Unfortunately, my experience with STM cube was not very good.
-
I am actually really happy the compiler isn't updated, because it seems to work faultlessly, while Cube itself looks like a bit of a hack. But it is free, which is actually a huge plus especially if you are trying to divide up a project among several people / several devices. The last thing I ever want for any serious development is some floating license thingy which works until the license server packs up or the company stops supporting it, and which guarantees that it will be hard or impossible to open the project up 10 years from now. I have some Xilinx FPGA projects from mid-1990s whose customer (I used to do FPGA & ASIC design consultancy) resurfaced 10 years later, for another £30k "improved version of the last project" :) The Xilinx software (Viewlogic4-LCA and XACT5) was double-dongled, both dongles broke, Xilinx washed their hands of the whole lot ("got to crack some eggs to make an omelette" was the sales guy's reply, when I questioned why their latest sw would not import the old project) and it was only via cracks from some Russian guy that I was able to rebuild the project. Most of the CAD/EDA business has moved to either rental or floating licenses, which is fine if you work in somebody else's company, get paid 50-100k, and change jobs every few years.
A Cube project can be archived as a VMWARE VM package which plays in any VMWARE player. It can be fully run in a VM anyway, if you want to do that.
-
Fully agree. There is a very good reason why I only buy software (with a perpetual license) for which a cracked version exists.
-
peter-h - you seem to be in an insightful and generous mood today. So why not take this opportunity to rename this thread, which you started, into something more professionally sounding? After all, we have collected quite a bit of valuable information about that collection of tools, known by the common developer as CubeIDE.
Merry Christmas.
-
peter-h - you seem to be in an insightful and generous mood today. So why not take this opportunity to rename this thread, which you started, into something more professionally sounding? After all, we have collected quite a bit of valuable information about that collection of tools, known by the common developer as CubeIDE.
Merry Christmas.
I think the original thread title is just fine, if a bit clickbaity; it's the right question to ask. Do not confuse professionalism and political correctness. Even in professional environment, such strong wording is pretty useful sometimes, but of course in moderation. But this seems to be OK since peter-h's every topic is not titled like this. Merry Christmas indeed!
-
"you seem to be in an insightful and generous mood today."
:) :) :)
I think that's known as a "backhand compliment" :)
I don't think one can rename threads. Only subsequent posts' title gets renamed.
Merry Xmas All :)
-
The title is actually pretty soft given the things I've seen/experienced in the past :-DD
-
You can edit each individual post of your own, changing their titles. The responses of others will remain with the old titles, unless their authors do the edits. Whoever happens to click the reply button on a post with edited title, will cause the new post to inherit this new title. The result is a thread where titles change on the fly randomly, and on the front page showing new posts, no one knows which thread is actually updated.
Obviously, this technical difficulty only underlines the deeper meaning: rewriting history tends to be at least stupid, if not dangerous. So it's best left undone unless you have a strong technical reason to actually do it to help others, not "just because".
-
The title is actually pretty soft given the things I've seen/experienced in the past :-DD
Yeah, if you want to do that in Professional Style, how about:
"ST CubeMX considered harmful".
-
I think Cube IDE is really nice. Great set of features and quite intuitive and easy to use.
Your problem could be a C / C++ one (especially C++). Some features when use in certain ways can produce undefined behaviour.
Could it be that another included header file elsewhere in the project is having an effect.
-
The title is actually pretty soft given the things I've seen/experienced in the past :-DD
Yeah, if you want to do that in Professional Style, how about:
"ST CubeMX considered harmful".
Oh yes. But according to some people (remind me of another thread), claiming that something is considered harmful is, itself, harmful. :-DD
-
Currently, the issues which appear fixed are
- the occassional invisible text appearing in the console window (probably text in a white font, because you could see it by swiping it and pasting into Notepad) has not been seen by me since 1.7, but this remains to be verified by a colleague on whose laptop it was last seen... but may not be since he is changing his laptop for a new one
- unreliable debugger (STLINK V2 or V3) connection, regardless of which speed was configured (I know STLINK v3 ISOLATED needs a lower speed to be set due to the optoisolators, but it depends on which of the debug cable connectors is used - I recall posting on this topic extensively in detail)
- the SWV ITM debug would always crash the target (or the debugger) after a minute or so; this now seems much improved (I mostly use a USB VCP debug instead of SWV, although SWV has the potential of being much faster, at say 1mbps or 2mbps)
New issues:
- the config for whether a breakpoint is auto-inserted at main() seems to have been removed (it is always inserted)
- in the SWV ITM debug config, the Limit SWO clock is mandatory (the newly invented auto speed detect does not work, at least not with SWLINK V3 ISOL)
Remaining issues:
- in debug mode (build with F11) a random file gets opened, so as you do debugging your source window fills up with spurious open files which you have to keep closing (looks like 1.8 has improved that a little)
A debatable issue is whether Cube should detect that a file has been modified elsewhere but in the Cube editor. You get the most bizzare issues if you do that, so after any such thing one has to re-index, Clean project, and Build project.
Obviously the ST errata never mentioned any of the above ;)
The above is from my very superficial usage of maybe 1% of the Cube features. I am sure an expert user will find many more issues. I never used the Cube MX (the code generator) portion, and looking at the bloated code it generates I am hoping to totally avoid having to ever use it on this project.
-
A debatable issue is whether Cube should detect that a file has been modified elsewhere but in the Cube editor.
Well, it's not debatable IMO. All decent editors do that. I'm trying to remember the last time I used an editor that didn't have this feature, in a multi-tasking environment. I can't.
Thanks for listing all this though, it's sad but entertaining! ;D
-
"you seem to be in an insightful and generous mood today."
:) :) :)
I think that's known as a "backhand compliment" :)
I don't think one can rename threads. Only subsequent posts' title gets renamed.
Merry Xmas All :)
If you rename the topic title in your first post all generic replies will get the new topic title, not generic replies eg quotes will get the Re:topic title of the quoted user.
In other words in a few weeks all new posts will have the new title :)
-
I don't think changing the title is deserved. Cube has a load of bugs which will be discovered within the first hour by anybody. If this was some typical open source project (the sort of thing I like to jokingly describe as "supported until the young and keen coder gets himself a girlfriend") that would be normal. A large % of source code posted online (in places like stackexchange, github, etc) doesn't even work at all. But a company with the resources of ST can and should do a lot better. More importantly they should also do a lot better with their libs, which are ridden with bugs, which everybody spends time fixing, but the fixes almost never get posted anywhere because they were done by salaried people who aren't supposed to be helping their employer's competitors.
Re the checking for external file modification - presumably the editor needs to keep track of last-modified date stamps, or maintain a CRC of each, and a decision was made (in Eclipse) to not do that. Quite how Cube fits into a multi user scenario I have no idea. Usually one implements file level locking (so multiple people can't edit the same file but can edit different ones). AIUI this is normally implemented with some sort of VCS, but I have avoided that also (a long thread here somewhere on which VCS to use) :)
Re the opening of random files - I have noticed that the file opened is not random anymore. It is now the same file every time (in v1.8 ). It just happens to be a file that doesn't contain any breakpoints ;)
-
The problem is not ST but Eclipse itself and further below deck: Java. It is a miracle that the creators of Eclipse got this far with a Java application.
-
Name one microcontroller firm that offers a free professional developed compiler ide , configurator, support forum and has no bugs.
Name one microcontroller that has no errata sheet because it is perfect. Rest my case.
Merry Xmass by the way.
-
Lamenting about presents isn't what we should do on Christmas.
There are reasons why STM32 products are mainstream and some others aren't. I'd guess one of the reasons is the availability of Cube. Everybody can try and form his/her own opinion. Engineers who don't have any choice but use a free development environment are a sad case. I understand the sorrow.
Regards, Dieter
-
There are reasons why STM32 products are mainstream and some others aren't. I'd guess one of the reasons is the availability of Cube.
:-DD
You know, you might not remember it for obvious reasons better left to the readers to see, but Cube is still fairly new. STM32 has been pretty much the mainstream ARM MCU long before. I was already commenting in these same kind of discussions here on the EEVblog when you absolutely had to use Coocox or you weren't a cool kid, because Coocox is and will always be the de facto standard of embedded development, and those who say they don't need it are boring and stupid.
It took quite some time before Cube fanclubs like yours started to form, because transitioning from one fanclub to other, closing the old down requires some mental acrobatics. Still just a few years ago, people like you were openly laughing at CubeMX. Now it's the best thing since sliced bread.
I'm glad I never wasted my time in these moving targets, and just get work done instead. I understand the appeal to beginners, though, and there's nothing wrong, it's the whole point. Beginners teaching capable professionals how to think correctly is just something that is so ridiculous it sets me off. Yes, I also used to receive a lot of criticism of not using Arduino in my professional projects back when Arduino was trendy. Now it sounds unbelievable, but it was reality a decade ago. This just goes away, and is replaced with something else.
Seriously speaking, two reasons stand out for the popularity of STM32; large availability of many different parts with varying combinations of peripherals, and affordable prices. You can (well could before the crisis) get the parts, they don't cost arm (pun intended) and leg, and get the work done. This is all so important that people accept mediocre documentation and fairly large silicon errata.
But Cube doesn't hurt because they don't force you to use it. Having options for different user groups is always a good idea, and because users of something like Cube are not very demanding, these tools can be left buggy and don't need much maintenance resources. Trainees can write them, and then a replacement comes 3-5 years later when managers come up with something new on Powerpoint. What's best, the users who "liked" Cube only nag for a a year or two but then happily start advocating the next piece of crap tool, denying the existence of anything before it, and the cycle goes on...
-
" It is a miracle that the creators of Eclipse got this far with a Java application."
That's very funny :) But true; all java apps I have used were crap. Loads of weird bugs, and dependencies on java version, on the underlying environment, etc. One java expert I know says it is good for server side programming (where the environment can be stable for as long as you can manage, and you are ultimately just squirting out HTML to the client) but is crap for client side applications. Java is a job for life, along with the Cisco certified engineer qualification, COBOL66 and Ruby on Rails :) Cube actually works pretty well considering it was written in java.
"There are reasons why STM32 products are mainstream and some others aren't. I'd guess one of the reasons is the availability of Cube."
I've been in the uP/uC scene since late 1970s. IMHO the reasons why ST are big are
- adequate functionality (who needs 10 (?) DMA controllers and 15 (?) timers?)
- good pricing; ST are actually a hidden gem in this age of chip shortage, with some little-known simple chips for designing-out Maxim parts ;)
- a big stable company with long product runs; quite similar to say Hitachi whose H8/300 ran for ~25 years
- big in the automotive market where production stability is important
- European company, benefiting from the dislike of American companies (commonplace among European champagne socialists ;) ) and benefiting from European cultural and language barriers and prejudices
In the hobbyist market (in which I include hobbyists who get a job in some company and design-in some "great chip" from e.g. Atmel which gets dropped 3 years later) lots of other devices exist. I've designed-in a few of those too :)
For ST, this table
https://www.st.com/content/st_com/en/about/quality-and-reliability/product-longevity.html#10-year-longevity§ion=FM141-10-year (https://www.st.com/content/st_com/en/about/quality-and-reliability/product-longevity.html#10-year-longevity§ion=FM141-10-year)
is probably real and will probably be exceeded in most cases.
Now, how long do you think Espressif will be doing the ESP32-WROOM-32E for? They claim a 12 year production lifetime, but who will rely on that? They reportedly do have very well debugged libs for "IOT" stuff, with TLS actually working out of the box, unlike ST's libs.
The availability of the free Cube is probably good for individuals getting started, but the big users (mostly big companies) don't care about development tool cost. The great thing about Cube is that you can get started without reading the 2000 page RM. That's how the project I am working on got started (by someone else). But once you know the chip, or more precisely the bit of it that you need to know, bare metal programming is easy enough. I've just done a waveform generator on which most of the code was bare-metal.
-
The problem is not ST but Eclipse itself and further below deck: Java. It is a miracle that the creators of Eclipse got this far with a Java application.
Ahah, this was fun indeed. I do not have much consideration for Java myself (and usually - but I try avoiding gross generalizations of course - for many Java developers either), so I'd be biased here.
One problem related to Java is its cross-platform nature, while being a general-purpose language. Certainly, detecting that files are modified outside of the current process is a task that is tricky by nature if you want to implement this in a cross-platform way. Just a general thought - I do not know Java in details enough to know if doing this is actually hard or not, or how reliable it is depending on the platform. But that consideration can be extended to many other features. Cross-platform is hard, and ridden with pitfalls.
Now I do not agree with the statement "the problem is not ST" (even though you said that to point to Eclipse). Any vendor is responsible for their products, whatever said products are made of. If ST made a poor choice for one component of one of their products, it's THEIR full responsibility. Just wanted to make this point. Oh, and, beyond Eclipse itself, I have no doubt that ST was able to introduce a few bugs of their own. ;)
-
- adequate functionality (who needs 10 (?) DMA controllers and 15 (?) timers?)
- good pricing; ST are actually a hidden gem in this age of chip shortage, with some little-known simple chips for designing-out Maxim parts ;)
- a big stable company with long product runs; quite similar to say Hitachi whose H8/300 ran for ~25 years
- big in the automotive market where production stability is important
- European company, benefiting from the dislike of American companies (commonplace among European champagne socialists ;) ) and benefiting from European cultural and language barriers and prejudices
Another reason (to me anyway): one of the few vendors with several lines of ultra-low power MCUs, still quite powerful. In particular, the L4, L5 and now U5 lines are very hard to beat from a performance/power ratio point of view, with impressive figures both for active modes and low-power modes. Sure they are not the only ones there now, but with such figures and such a large offering at those prices? Not a whole lot of competition either.
-
This is a question for the "professionals" that use bare metal programming on the ST32 family. I am not a professional developer. I only use microcontrollers for my hobbyist projects. I have been an electronics hobbyist since the 1960s. My career days were in the communications and computer fields. Not product development, just service and maintenance.
I started using STM32 parts about 3 years ago after 22 years of using Microchip parts. I used all assembly coding until I started using C about 10 years ago. With the Mchp parts I used bare metal programming. In the early days there were no automatic code generation tools. So bare metal was the only way to go and it became second nature for my projects. I never used any of the Mchp code generation or pin assignment tools.
I originally used CubeMX and System Workbench for my STM32 projects. However, I quickly switched to STM32CubeIDE as my development platform. My projects are fairly simple. I use resources such as USART, I2C, LwIP. I have never had the need for USB in any of my projects. I have never found a bug (to my knowledge) in STM32CubeIDE as all my projects work as designed.
My last project was a 6 digit LED clock (HH:MM:SS) that uses a Ublox GPS module as the time source for the clock. I used a STM32F103 for the controller. The final code size was 2.12 KB RAM (out of 10 KB) and Flash 10.6 KB (out of 32 KB). Speed is not a problem and code size is obviously not an issue. I used CubeIDE to setup the STM32 clock, GPIOs, USART, Interrupts, and Watchdog timer. All of the generated code works fine. I simply had to add my own code to make the hardware work as designed. So what would bare metal programming gain me?
It might be fun to duplicate the clock project using bare metal programming. This would enable me to see if there is any real reduction in code size. Code size reduction would obviously not gain me anything. But I guess it would be a good learning experience for my next project.
Any suggestions for the "best" site to explain how to setup a bare metal project for STM32? What tools (IDE, complier, libraries) would you use? My guess is the compiler would have to be GCC. But how do you tie everything together?
-
I have been using Cube for pin assignment and hardware init code generation. Then i worked with IAR IDE for coding and debugging. Nice tools once you got used to them. I refrained from using GCC with Arm Cortex after a comparison with IAR compiler output some years ago.
We also have reusable code for bare metal Cortex projects that were pure IAR projects for Kinetis parts. A lot of work went into those. You need somebody who works through the complete reference manual. Otherwise you risk building a system where one of thousands of registers with hundred thousands of setup bits doesn't get initialized properly. The same can happen when using a generator like Cube, but it will save some work anyway. It's good engineering practice to use tools that everybody else is using, too.
Regards, Dieter
-
The reason for popularity of stm32 IMO is the combination of the lowest price per unit in very large quantities and the fact that ST has multiple ROM/RAM sizes for the same type uC in the same package thus enabling debugging on the final pcb with the largest version available and for the final product use a cheaper version (which fits and has room left for future updates).
-
The reason for popularity of stm32 IMO is the combination of the lowest price per unit in very large quantities and the fact that ST has multiple ROM/RAM sizes for the same type uC in the same package thus enabling debugging on the final pcb with the largest version available and for the final product use a cheaper version (which fits and has room left for future updates).
The price is probably the main reason; many people look at part price only and forget about NRE. From a technical perspective the ST parts never appealed to me (a long time ago I evaluated the STR700 series and I got the impression it was designed by a 3 year old; probably the worst MCU I ever came across) and the cross portability between device series is also quite poor. All MCU vendors offer different memory sizes in the same package so that is not unique to ST.
-
The reason for popularity of stm32 IMO is the combination of the lowest price per unit in very large quantities
I don't think they ever had lowest price, but they look rather expensive now. I've looked at DigiKey, filtered out all 100 MHz MCUs (to get rid of cheap 8-bitters and such), sorted by price for 10000 units. This should give a rough picture of the prices. I found STM32 only at the end of fifth page. Here's what I encountered on the way:
Microchip (proper) - 1.43
Microchip (former Atmel) - 1.78
Kinetis - 2.21
Maxim - 2.44
TI - 2.50
Renesas - 2.84
ST - 3.10
Some of that stuff was actually in stock, but not SMT32, of course.
-
Quote from: dietert1 Yesterday at 11:09:26 pm
have been using Cube for pin assignment and hardware init code generation. Then i worked with IAR IDE for coding and debugging.
I think any commercial IDE is too expensive for hobbyist use. If there is a better free IDE that includes debugging than STM32CubeIDE I would like to know what it is.
NorthGuy, I agree with you the STM32 parts have never been the lowest cost MCU. Maybe the lowest ARM part but I'm not sure about that. For small projects that don't need a lot of processing power I still use Microchip parts. They are the lowest cost vs performance that you can get. Some of their parts have peripherals that are not available in most other MCUs. Most of their 8 bit parts appear to be in stock at Mouser and DigiKey even with the great parts shortage.
-
So what would bare metal programming gain me?
Not necessarily anything, but it depends.
You oversimplify the question a bit. There are actually more to this:
* Bare metal programming vs. using pre-made hardware abstraction libraries,
* Which hardware abstraction libraries to use, and do they help or hinder;
Then a completely separate question,
* Which tooling to use - only barebones GNU tools, or an added point&click layer on top?
Only now we can start to answer your question.
The main marketing argument for hardware abstraction layers is portability. Because of non-existence of standardized microcontroller peripheral API, and total difference of each HAL, and the fact that between different MCU families, code needs manual porting anyway, this argument is completely out of window.
The secondary argument, ease of development, has some merit to it. OTOH, as your projects are very simple, for example initialization of UART bare-metal in STM32 is three lines of code. I write it in 5 minutes from scratch, or copypaste it from previous project in 30 seconds. Either is fine. Looking up how the same is done in HAL from HAL manuals, or copypasting from previous project, or letting Cube to autogenerate is, is pretty much exactly the same amount of work. No difference here.
So all this isn't me being against Cube or HAL, all this is me being against the idea of Cube and HAL being somehow mandatory or extremely beneficial. Actually, just "Keep it simple" and "avoid excess layers" is argument enough not to use them.
Now to the "what you gain" question. Not necessarily anything, that depends. I feel I gained my whole "career" if you could say so, but this is impossible to prove without "alternative reality" to be compared against.
Again two sub points:
* Being tool agnostic (or limited to the minimum common denominator, the GNU tools), allows you to jump between different manufacturers quickly. No problem using NXP or Nordic Semiconductor in between STM32 work. All works the same! Everything's familiar! Same linker script syntax works, same initialization code works, even the way manuals are presented is familiar. No need to install anything to your computer!
* Being in total control of the peripherals becomes important right when you hit an edge case where the HAL simply is unable to do the job. For the very simplest jobs, this might not happen, but I would be surprised if you have not seen this yet. It's a very common occurrence if you read this forum, for example. And oh boy people really struggle trying to achieve something with the libraries which the library is not designed to do (even if the underlying peripheral supports it).
Examples of this is: making peripherals co-operate by existing on-chip routing; managing DMA buffers differently than the HAL designer thought; very fast ISRs (for example, just a week ago, I had to write ISR-based state machine which processes data at 555.5kHz interrupt rate. There is simply no room for any bloat, not even 10 instructions. I need to be in control! Now the common way to deal this today as evidenced on this forum for example, is just to shout "no can do" and give up. I don't have this problem because of choices I make. Addition of CPLD was considered. It was not needed, which simplified BOM and also the workload of not needing to write VHDL. See how everything's connected? By having as much choice and "power" as possible, you limit yourself the least.)
Any suggestions for the "best" site to explain how to setup a bare metal project for STM32? What tools (IDE, complier, libraries) would you use? My guess is the compiler would have to be GCC. But how do you tie everything together?
Sad part is lack of tutorials.
The quick answer is, install gcc-arm-none-eabi package. IDE is your free choice. I use text editor and makefiles. You don't even need to use makefiles if this seems difficult. Compilation really can be done with one-liner command. No libraries, except for standard C library and special needs (like filesystems etc).
Tie everything together? There is not much to "tie" so to speak. These are actually simple devices! All you need is startup code, linker script, actual code, and run gcc to provide .elf you can flash. Maybe objdump for conversion of the output file format. To write peripheral code, you look at the reference manual and register descriptions, exactly like you did on PIC or AVR.
But this is just the big picture. Small details always takes the most time. There, a proper tutorial would be helpful. As much I'd like to write it, I'm not too great doing that; also it takes a lot of time and effort to teach something, even if it feels completely trivial to oneself.
-
Any suggestions for the "best" site to explain how to setup a bare metal project for STM32?
I have a collection of very basic bare-metal projects for pretty much every MCU I touch, including some STM32. Here is one as example - https://github.com/ataradov/mcu-starter-projects/tree/master/stm32g071 And once you have this, it is trivial to make a project like this for another MCU. In most cases all you need to adjust is the vector table and the demo code to use the peripherals of the target device. The vector table can be taken from the datasheet or a device pack.
There is no tutorial, but things are pretty simple if you just look at the code. You will need arm-none-eabi-gcc (basically any version will work, I use "official" ARM one). You will also need basic tools like make. Once you have all those things, all you need to do is run "make" in the "make" directory. You will get a binary file.
One thing that bare-metal gives you is full control over your project. I often see people not use full potential of the device just because they are "afraid" to touch low level files. Not necessarily because they afraid that they will break something, but because they are afraid that new code generation after some changes in the wizard would overwrite their changes. So this may turn into the maintenance nightmare.
Some people think that going bare-metal means you have to completely abandon all the libraries and write everything from scratch. This is generally not true. While it probably more work than it is wort to use vendor UART or SPI drivers, you can absolutely integrate more complex things like USB.
-
All MCU vendors offer different memory sizes in the same package so that is not unique to ST.
Perhaps this changed the last few years but 5 years ago this was a main selling point.
When for instance NXP had two or three memsizes , ST had five or more.
The reason for popularity of stm32 IMO is the combination of the lowest price per unit in very large quantities
I don't think they ever had lowest price, but they look rather expensive now. I've looked at DigiKey, filtered out all 100 MHz MCUs (to get rid of cheap 8-bitters and such), sorted by price for 10000 units. This should give a rough picture of the prices.
No this tells you nothing. 10k units/yr no ST sales rep is going to call you back ;)
Digikey is a distributor, I am talking about fixed yearly quantity orders directly at ST , and we are talking more then half a million chips per year fixed quantity contracts and even larger.
The numbers were so big and the chips so popular even in asia that a chinese manufacturer found a business case developing a clone, the notorious GD32. Should say enough.
-
Even at 1k+ Digikey / Mouser pricing is about 2x what you pay from a proper distributor, once you get into "supported pricing" and the other gimmicks which the industry uses. These firms offer a fast service, good websites with easy product selection, often better availability than the distributor scene (but you pay for it). I use Mouser too, lots, but would not use them for production. So these firms are a bad indicator of prices actually paid, and large OEMs pay far less again. I buy 10k+ of a HP optoisolator which on the disti scene is about 60p, and a customer of mine who buys 1M+ pays 25p.
How time-consuming "bare metal" is depends on the extent to which you can re-use the same debugged platform for different projects. The thing I am working on was started entirely with MX, but to avoid "total uncontrolled bloat" the guy used a separate installation of MX, generated each function, copied it across to the real project, and disposed of the original MX setup. He was on this project part time (1 day a week). Then about a year ago I realised it would never get finished at that rate so somewhat reluctantly I got stuck into it, with quite a learning curve (no C for 10+ years, and a long career in asm coding).
And I was glad I did because it's been great to get back into coding. One of the things I found fairly quickly was that the ex-MX code was doing the same things all over again e.g. the clock divisors for APB1/APB2, the DPLL etc, were getting set up multiple times, in different auto-generated functions. One of these was even called from the .s startup code. Maybe there was some "grand scheme" behind it but I never found it. I think the MX functions are written mostly by ex-college kids. So I chopped huge duplicated chunks out of it. I had to get into the detail of it because I was implementing a boot loader which had to have all the basic config but be fairly small, etc. But once this product is working, if I want to build another product I will re-use this one completely. It would be absolutely dumb to start again. Once you have a 168MHz 32F417 board running, with the CPU power of 1 core of a Cray 1, and you have APIs for the ADCs, DAC, etc, you can do "anything" with that.
Of course this is possible only if you have lots of control over how you work; most hw and sw designers don't (which is why most sw guys in "normal employment" go crazy around 40+ and want to get out of sw, with a 2000 page RM for each new piece of silicon, but that's another story). But I own my business so can just decide to use the same platform for absolutely everything. Which is just as well since I am in my 60s :) Customers don't care what is inside so if you own the business you can choose for "least stress", and e.g. I am still strongly selling a product based on a H8/300 which I did in 1994, and which was obviously done bare-metal, mostly in asm, and while the CPU is no longer made I have a large stock of the chips. One day soon this box will be replaced with this 32F417 one, anyway.
And I've just done a little project like that: a waveform generator which uses DMA and some timers. The original project doesn't use DMA and uses only one timer (apart from hidden DMA usage like ethernet, for which one just uses the ST library otherwise it would take one 10 years to get anything finished). This little project was done bare-metal, because all the rest (including a USB-accessible file system with FatFS, FreeRTOS, etc) can be left alone, and reading up on how to config the basic regs for a timer is pretty easy. And the bonus is that you can understand what is happening, whereas if you use MX to generate a function for driving SPI you will get hundreds of lines of bloat, checking every possible option (e.g. is CRC in use?) at runtime. Or you get an interrupt handler which checks about 20 possible sources, on the way to the actual ISR; I could not believe what I saw. You also get a lot of code handling error conditions which are impossible unless the actual silicon is defective (e.g. a UART TX set up for 9600 baud and with no handshake will have space in the TX buffer every 1ms, so no need for special error handling). Only a monkey could have written such code, especially that ISR with 20+ checks.
And I can see generating a whole family of products this way. If I now wanted to do something "completely useless and just for fun" e.g. a clock displaying time on a big LCD, I would do it the same way. I have generic code for using SPI3 for an unlimited number of peripherals, for expansion, etc. I would just buy an SPI-interfaced LCD.
The benefit of this is that each new project tests all the old stuff. So my waveform generator ends up testing a great deal of the old code too.
But I can see MX gets a lot of people going, fast, if they just want to knock something up. I would be worried doing that on a key production item though, looking at how much bloat there is and what subtle interactions might be happening.
-
Digikey is a distributor, I am talking about fixed yearly quantity orders directly at ST , and we are talking more then half a million chips per year fixed quantity contracts and even larger.
Even at 1k+ Digikey / Mouser pricing is about 2x what you pay from a proper distributor, once you get into "supported pricing" and the other gimmicks which the industry uses.
What you say applies to every chip manufacturer, not only ST. Go ahead, negotiate proper prices with proper distributors for proper quantities of the chips from different manufacturers and post the results here. Until then the price comparison from DigiKey is the best we have.
Most of the manufacturers are public companies. The financial data are publicly available. Look at their revenue - this is generated mostly by sales to big customers in big volumes. This will give you a rough idea how popular are particular manufacturers among big buyers.
-
Most of the manufacturers are public companies. The financial data are publicly available. Look at their revenue - this is generated mostly by sales to big customers in big volumes. This will give you a rough idea how popular are particular manufacturers among big buyers.
That is another worthless measure. There are so many different markets out there with different margins. How would you compare a company like Intel to Onsemi that way?
-
Most of the manufacturers are public companies. The financial data are publicly available. Look at their revenue - this is generated mostly by sales to big customers in big volumes. This will give you a rough idea how popular are particular manufacturers among big buyers.
That is another worthless measure. There are so many different markets out there with different margins. How would you compare a company like Intel to Onsemi that way?
It is a measure nonetheless. It is infinitely better than statements lacking any factual support.
-
I am not allowed to share the real numbers, and the negotiations were back in 2018, so worthless now.
I shared the results from back then , take it or leave I don't care if you believe me or not, I know what I know.
Currently with the chips shortage all bets are off and you may be thankfull to get any allocation.
-
I am not allowed to share the real numbers, and the negotiations were back in 2018, so worthless now.
I shared the results from back then , take it or leave I don't care if you believe me or not, I know what I know.
I believe you (personally). You negotiated very good price with ST. Is it possible that if you negotiated with a different vendor (or vendors) you would get even better price?
Currently with the chips shortage all bets are off and you may be thankfull to get any allocation.
So true. It's hard to predict prices (or even availability) when the shortages are over.
-
I believe you (personally). You negotiated very good price with ST. Is it possible that if you negotiated with a different vendor (or vendors) you would get even better price?
For arm cortex M3 and M4 cores (f2 and f4) we were not able to get better prices from other vendors. You have to understand that with these large procurements of half a million chips every $0.01 is $5000 ;)
For the f0 we did get a good deal with Atmel however after Microchip aquired Atmel the prices were almost doubled :o
-
There is a lesson here somewhere, about SUPPORT.
I don't know how good or bad the current STMCube stuff is. I looked at STPLIB a long time ago (~2014), and then I think the first HAL library. Both were significantly unimpressive: bloated, poor code, incorrect code, not substantially readable, etc. (You can see one specific complaint here: https://www.eevblog.com/forum/microcontrollers/one-dollar-one-minute-arm-development/msg516710/#msg516710 (https://www.eevblog.com/forum/microcontrollers/one-dollar-one-minute-arm-development/msg516710/#msg516710) (and some more following in that thread.))
And then there was a NEW ST library. And another new one. And in between the initial impressions and the "churn", I have been unmotivated to see if things have gotten any better. (ST isn't the only guilty party. Atmel did libsam->asf->start, with similar complaints.
I think that means:
- The first released version of what is supposed to be a vendor library needs to be very good. It should be largely correct, make sense from an abstract point of view, and not produce horrible code. (this, of course, is difficult. I think HW vendors specifically tend to underestimate just how difficult it is.)
- Support - fixing bugs, improving functionality, and broadcasting info about what has been done - needs to be very aggressive, especially early in the release cycle. The answer to "your BRG divisor calculation sucks; here is better code" ought to be "thank you; we've replace our code with your suggestion", not "There will be a new library soon. Maybe we'll fix it then."
- Libraries are a product (whether they "generate income" or not.) You need customer input on how they should look. And testing/evaluation across all of your target markets.
- Churn is bad. Abandoning older versions is worse. Design your APIs REALLY CAREFULLY.
That's all separate from IDEs. Using a library shouldn't lock users into a particular IDE. For any IDE, there will be a significant number of users who HATE it. Libraries that are easy to integrate into "any" configurable IDE are much better than ones that assume a particular development environment.
-
For arm cortex M3 and M4 cores (f2 and f4) we were not able to get better prices from other vendors. You have to understand that with these large procurements of half a million chips every $0.01 is $5000 ;)
For the f0 we did get a good deal with Atmel however after Microchip aquired Atmel the prices were almost doubled :o
I've never came across such volumes :(
-
" every $0.01 is $5000 "
That way of looking at life is going to lead to a disaster.
The same company will be shafting its suppliers, with an aggressive buyer who (metaphorically) bangs his fist on the table while threatening to terminate the relationship unless there are NO price increases, ever, not even 0.1%. This is while the company is buying a $50M private jet. Ask me how I know :)
It will also be a really sh1tty company to work for, at every level.
$0.01 on a $5 chip is completely irrelevant - against all the other things one has to pay for.
Anyway, a digression from ST Cube IDE bugs :)
-
$0.01 on a $5 chip is completely irrelevant - against all the other things one has to pay for.
This is absolutely not the case. The biggest companies out there negotiate fractions of a cent, not just a cent. And smaller companies wish they can do the same. And yes, it is better to negotiate a smaller price and buy a jet on the saved money than just give away the price of a jet just just because you were to lazy to negotiate a better price.
If you are a car maker and you need 200 MCUs in a car, then every cent start to matter.
And MCU is not the only thing in the system. Once you are done with "one cent does not matter here" tactic, your board is a few dollars more expensive all of a sudden.
-
$0.01 on a $5 chip is completely irrelevant - against all the other things one has to pay for.
This is absolutely not the case. The biggest companies out there negotiate fractions of a cent, not just a cent. And smaller companies wish they can do the same. And yes, it is better to negotiate a smaller price and buy a jet on the saved money than just give away the price of a jet just just because you were to lazy to negotiate a better price.
If you are a car maker and you need 200 MCUs in a car, then every cent start to matter.
And MCU is not the only thing in the system. Once you are done with "one cent does not matter here" tactic, your board is a few dollars more expensive all of a sudden.
+1 on this one, fractions of a cent on each part in e.g. a modern EV can make or break the product and the company, and countless hours are spent optimizing and squeezing every last cent out of the CBOM.
-
$0.01 on a $5 chip is completely irrelevant - against all the other things one has to pay for.
That was how I saw it once and I understand your way of thinking.
I also then had the impression, why not buy the biggest chip so we can grow the firmware over the years without having to optimize everything or again refactor pieces of code so it fits?
The answer is all in the numbers, if you sell over half a million products each year for ten years and you do the math it turns out that it is a lot of money that makes the profit for that business but also allows the salespersons to put the product at a lower pricepoint in the market. And that is what sometimes is needed to survive against asian competitors to make the first deal.
Even refactoring the platform to another chip manufacturer (3 SW eng + 2 HW eng for three to four months) can make a large profit if you do the math. The only time this really went sour was when the marketing dept had over estimated the sales with a factor of ten so yes it sometimes can go wrong.
-
I don't know how good or bad the current STMCube stuff is. I looked at STPLIB a long time ago (~2014), and then I think the first HAL library. Both were significantly unimpressive: bloated, poor code, incorrect code, not substantially readable, etc.
Yeah, well. We've read that a lot everywhere, but it's not all that bad. At least not substantially worse than any other vendor library I've seen. I've worked with TI and NXP SDK and didn't find the code to be all that much better or more readable.
One thing to consider is that ST's code is MISRA-C compliant, which makes them use a certain code style, and a certain way of implementing things, that many will find cumbersome and less readable.
The other point is that vendor libraries are provided with source code these days, which is a good thing. But generally speaking, looking at someone else's source code almost ALWAYS triggers criticism. Thats something inherent to software development, I think. It's very rare when a software developer actually likes someone else's code and has nothing negative to say about it.
That's all separate from IDEs. Using a library shouldn't lock users into a particular IDE. For any IDE, there will be a significant number of users who HATE it. Libraries that are easy to integrate into "any" configurable IDE are much better than ones that assume a particular development environment.
Yes of course! Many people unfortunately shy away from doing that, because it's out of their comfort zone. They just use the vendor IDE, and then they're confident it will produce the result they expect - until, of course, they find the next horrible bug. Somehow they often seem to prefer fighting with the bugs of others, rather than configuring their own tools. Maybe because this way, they don't feel responsible for the bugs occuring in the tooling...
-
I started a new project to see if I could figure out how to directly control the GPIO registers. I used STM32CubeIDE to setup the project. I used the IOC tool to configure the system clock and to configure GPIOC_13 as an output to flash the onboard LED at a 1 second rate using the HAL_Delay() function. Nothing else was configured. Code size came out to be 2968 bytes using HAL_GPIO calls.
I then used IOC to set GPIOC_13 back to its reset state. This results in no HAL_GPIO code being generated for GPIOC_13. I used the CMSIS libraries to setup the GPIOC port. I also manipulated the GPIOC registers using the GPIOC->BRR and GPIOC->BSRR to toggle the LED at the 1 second rate using the HAL_Delay() function. Code size came out to be 2476 bytes which is 492 bytes less than using the HAL_GPIO calls.
I guess this confirms bare metal programming generates smaller code than using the HAL calls. Using the system tick instead of HAL_Delay would probably reduce the code quite a bit with the added benefit of not stalling the MCU. More bare metal learning ahead. I will need to setup a bunch of macros and #defines to make my code more readable.
-
A basic program for STM32G071 that sets up the clocks, reads a button, blinks an LED using a timer interrupt, reads and writes UART is 1052 bytes using pure bare metal code with no real attempts to optimize anything.
Same thing for STM32F4 is 1464 bytes, and significant part of the difference is interrupt table that is 428 bytes on F4 vs 192 bytes on G0.
-
looking at someone else's source code almost ALWAYS triggers criticism.
Well, yeah.
But not understanding binary fractions, and rounding by multiplying by 10, adding 5, and dividing by 10... Does not inspire confidence. (Since the clock and baud rate are variables, all that math actually happens. I guess "a CM3 has a divide instruction, so who cares?" is somewhat valid. Sigh.
Code I originally complained about (2014):
integerdivider = ((25 * apbclock) / (4 * (USART_InitStruct->USART_BaudRate)));
tmpreg = (integerdivider / 100) << 4;
/* Determine the fractional part */
fractionaldivider = integerdivider - (100 * (tmpreg >> 4));
/* Implement the fractional part in the register */
tmpreg |= ((((fractionaldivider * 16) + 50) / 100)) & ((uint8_t)0x0F);
/* Write to USART BRR */
USARTx->BRR = (uint16_t)tmpreg;
Code in current STM32F1 HLL driver library:
// .h file
#define USART_DIV(_PCLK_, _BAUD_) (((_PCLK_)*25U)/(4U*(_BAUD_)))
#define USART_DIVMANT(_PCLK_, _BAUD_) (USART_DIV((_PCLK_), (_BAUD_))/100U)
#define USART_DIVFRAQ(_PCLK_, _BAUD_) ((((USART_DIV((_PCLK_), (_BAUD_)) - (USART_DIVMANT((_PCLK_), (_BAUD_)) * 100U)) * 16U) + 50U) / 100U)
/* UART BRR = mantissa + overflow + fraction
= (UART DIVMANT << 4) + ((UART DIVFRAQ & 0xF0) << 1) + (UART DIVFRAQ & 0x0FU) */
#define USART_BRR(_PCLK_, _BAUD_) (((USART_DIVMANT((_PCLK_), (_BAUD_)) << 4U) + \
((USART_DIVFRAQ((_PCLK_), (_BAUD_)) & 0xF0U) << 1U)) + \
(USART_DIVFRAQ((_PCLK_), (_BAUD_)) & 0x0FU))
// .c file:
husart->Instance->BRR = USART_BRR(pclk, husart->Init.BaudRate);
Code that works equivalently:
Usart->BRR = pclk/baud;
(The F0 and U5 implementations are better. The F4 isn't, but it's different. I don't know if it's good that there are different implementations, or terrifying. Don't the developers talk to each other? (Oh, right. Probably someone who isn't there any more. Sigh. I once had my manager say something like "no one comes to work for xxxx wanting to develop infrastructure code." That's probably generally true, for most values of xxxx. :-( )
-
" fractions of a cent on each part in e.g. a modern EV can make or break the product and the company, and countless hours are spent optimizing and squeezing every last cent out of the CBOM."
That is part of why so many bigger companies are sh*t places to work for, and are really sh*t to have as a customer :)
A fraction of a cent will never "make or break a company". But that's another topic :)
"Usart->BRR = pclk/baud;"
That pretty well hits the "Is CubeIDE crap" nail on the head :)
Many many lines, countless macros, countless definitions, countless abstractions, just to do a trivial function. They must have had a whole team coming up with all the bit definition names :)
-
" fractions of a cent on each part in e.g. a modern EV can make or break the product and the company, and countless hours are spent optimizing and squeezing every last cent out of the CBOM."
That is part of why so many bigger companies are sh*t places to work for, and are really sh*t to have as a customer :)
Sure, but that is totally subjective. I personally enjoy fully optimizing something to the point where you can't make it any simpler/cheaper, there is a certain amount of satisfaction knowing you designed something "just right" with little to no waste or any vestigial parts. I can't fathom using some Raspberry Pi garbage to blink an LED or actuate a motor, which is what a lot of people seem to be doing nowadays and would much rather be doing optimized DSP/functional safety designs that cost a small fraction of that and are sold in the 100's of thousands.
For reference, my workhorse has been the STM32G4 series used in some UL991 and UL1998-compliant and power electronics designs and I have no strong opinions about STCubeIDE. ST provide a VDE certified class B safety library for free with it, so like, truly 0 complaints there. Sometimes the IDE is a piece of buggy crap, sometimes it's not, it really is on par with any other OEM offerings.
-
Oh yeah, if you need Class B, MISRA-C and other crap like this, then you are in a wold of hurt. Your code quality will suffer no matter what you do.
-
AFAIK The point of Misra is safety and predictability of the execution of the code for automobile industry.
Not the most optimized code.
It has its purpose, remembering the leaked Toyota software from the start of the century ;)
-
But generally speaking, looking at someone else's source code almost ALWAYS triggers criticism.
Yes, and it's always considerable amount of work integrating other's code and libraries. Because it sucks, it has to provide something back. I.e., spend 10 hours to reuse work by others, save 100 hours by not having to do the work from scratch. That would be an acceptable ratio.
That is exactly why we use large libraries to do non-trivial things. This is why we use OpenCV to help with computer vision, or use existing BSD or linux networking stack.
But 99% of what STM32 HAL does, and what Cube autogenerates, is something that is written within minutes. Very typically less than 10 LoC per peripheral. And once you have done it a few times, you have already learnt the quirks. Sometimes it gets difficult but these are difficult edge cases anyway, something usually completely impossible using the HAL.
Same thing with every other vendor. westfw's requirement list above is a good one. No one ever really succeeded with it, regarding something as simple as microcontroller peripherals. The reason is, the peripherals are flexible devices offering gazillion features, but are still relatively simple to program. Worst combination for successful abstraction.
Abstraction and libraries work well when you have one simple goal, and achieving it takes a lot of difficult implementation details. This way, API is simple, like space_rocket.launch("Moon"), and doing the implementation from scratch instead would be a lot of work.
But abstracting all 57 configuration parameters of an UART through a library layer, when you can just write those parameters directly in the registers as explained in the only existing documentation. Not going to happen, so the library only exposes "a typical case" or two, causing massive limitations on what you can do with it. This would be an acceptable tradeoff if doing what it does was difficult, but since it isn't, I absolutely see no point. The typical case tends to be extremely simple anyway. You succeed in it using any vendors any borked library, bare metal, asm, writing ones and zeroes with a stick in sand and photographing it, whatever. This makes the reoccurring HAL discussion not worth anything. The claim that HAL somehow makes life super easy is just :-DD because all the real challenges are elsewhere than getting UART to print characters.
-
MISRA is completely uninteresting. It's another tick in the box for Powerpoint managers, and completely depends on the case if it helps or hinders. Usually the latter.
It's not some holy grail of safe development practices, it's really just a small list of forbidden constructs that sometimes have caused problems. Look it up. It's a slightly more advanced and better formed version of "don't use goto". It's clearly a panic reply to actual problems.
It does not in any way help avoiding problems in all the remaining constructs. It isn't even designed to help in developing safe code (where specification of edge cases, testing, code coverage, verification and proving things come in). These are all difficult, and MISRA's purpose isn't to even comment on them.
At the same time, having to avoid large number of perfectly usable language constructs just because someone else have made mistakes with them increases risk of producing bugs using the less effective tools.
I.e., a screwdriver sometimes slips and causes damage. So forbid usage of a screwdriver. Hammer must be used instead. As a result, hammer hits your finger instead of the screw much more often. But that doesn't matter, because it's now formally on paper. Without validation of results getting better, such changes are meaningless.
Really, MISRA screams the classic "goto considered harmful" mindset, i.e., instead of getting competent programmers, limit the number of powerful tools so that fools don't make mistakes with them. This is quite OK in programming 101 class, but not in safety critical software industry (which is why actual safety-critical industry use something completely different paradigms than just MISRA; they might implement MISRA too if they consider it important box to tick).
But yeah, MISRA's great for the hobbyists role-playing safety critical aerospace industry. In this regard, I completely understand why STM32 HAL is written in MISRA compliant C. It hits the target.
-
MISRA is completely uninteresting. It's another tick in the box for Powerpoint managers, and completely depends on the case if it helps or hinders. Usually the latter.
It's not some holy grail of safe development practices, it's really just a small list of forbidden constructs that sometimes have caused problems. Look it up. It's a slightly more advanced and better formed version of "don't use goto". It's clearly a panic reply to actual problems.
It does not in any way help avoiding problems in all the remaining constructs. It isn't even designed to help in developing safe code (where specification of edge cases, testing, code coverage, verification and proving things come in). These are all difficult, and MISRA's purpose isn't to even comment on them.
But all this is coming from the suggestion that every programmer should produce code without errors and is 100% dedicated to the job. The reality is that not every programmer is perfect or sees writing excellent code as a goal. Most go home at 5 and sit in front of the TV while drinking a beer after dinner. And that is perfectly fine.
MISRA is put into place to remove common pitfalls in C from the equation and make 2 average, low cost programmers produce more code than a rare (hard to find), highly paid expert programmer. Now multiple the number of average level programmers in a team by 10 and you'll see why MISRA makes producing code that doesn't suffer from common bugs more efficient in a financial sense.
I have put together a small course myself to teach junior programmers several pitfalls of C and how to avoid them in order to make them more productive. It is not as extensive as MISRA but does cover the basics.
-
MISRA fails to remove common C pitfalls. It addresses an uninterestingly small part of actual programming errors. The problem is deep in C. It is just a powerful but somewhat dangerous language. You can't fundamentally make it better by removing half of the power, and half of the pitfalls. Mistakes will be made regardless, and the key is to find and correct the mistakes. Even better, their root causes.
The problem in MISRA & friends is that the strict avoidance of many useful C constructs makes the code less maintainable spaghetti mess, increasing risk of human errors; in worst case, necessitating copy-paste practices. This again can be mitigated by adding automated testing and verification. It can all work out, but the burden of proof is for those claiming MISRA helps reduce bugs.
Yes, people make mistakes, but I'm sure there would be softer means of finding and correcting "typical C problems" than industry-wide removal of most powerful C features.
-
But generally speaking, looking at someone else's source code almost ALWAYS triggers criticism.
Yes, and it's always considerable amount of work integrating other's code and libraries. Because it sucks, it has to provide something back. I.e., spend 10 hours to reuse work by others, save 100 hours by not having to do the work from scratch. That would be an acceptable ratio.
That is exactly why we use large libraries to do non-trivial things. This is why we use OpenCV to help with computer vision, or use existing BSD or linux networking stack.
I will give one example where vendor-abstraction-libraries collide with "large libraries to do non-trivial things" -- USB.
Every vendor that offers processors with USB has a library and some standard device-class examples, and that library and those examples are all intertwined with their HAL. Like ataradov, I have an application I port to new processors. I use the USB MIDI class. It's simple and well-defined, but at the same time somewhat open-ended: it's up to the application to deal with data sent from the computer to the micro, and also to generate messages to send back to the host.
Some are good. One one hand, Silicon Labs offers a fairly straightforward USB library for their EFM8 and EFM32 parts. Once I got their tech support to explain how a particular case was handled ("what happens when the application doesn't read from the USB OUT endpoint FIFO because it's not ready to handle the data?" "The USB hardware NAKs the transaction" -- exactly what the spec says should happen!), implementing a standard class (MIDI) was straightforward. The library lets you set up a transfer-complete callback to which it passes the endpoint number and then you can handle the data as necessary. It's then a matter of the application deciding what to do with the data received, and also how to send data back to the host.
On the other hand is NXP. On-chip High Speed PHY and a faster core look great! But good D-g, their manuals and support say, "To implement an unsupported Device Class, copy an existing example and modify it." But the existing examples are all created with their overall code generator and once you start to modify it, it all breaks, and anyway you'll get the bends doing the deep dive into their code necessary to understand it and strip away a lot of the stuff needed to support the "example" class so you can implement your own thing. Why can't they just offer a callback and let the application programmer manage the data?
On the gripping hand is TI with their Tiva TM4C and MSP432 parts. They absolutely want you to use their libraries for everything. The USB library is overcomplicated in how they have goofy structures to handle composite devices. Part of it is that by "composite device" they mean a device with more than one instance of the same device class, for example two UARTs. But USB Audio and MIDI are composite classes because they use more than one Interface, not that there are two MIDI devices. Another complication is just how there are pointers to structures and their library wants to handle descriptors in a weird way. But I got it to work without too much fuss. The USB library code expects to use the rest of their HAL, so there's no real way around it. The chips have driver code in ROM, which is useful in that it saves flash, but less so because they can't update that code, so to use their library you have to use a "map" function which knows whether to use the ROM code or new source you compile in. Arrgh.
I follow the TinyUSB (https://github.com/hathach/tinyusb) project, which aims to provide a common user-facing solution for the device classes it supports, while handling the chip-specific stuff in the background for you. As you can imagine, it's got a lot of preprocessor macros that sort out which USB peripheral and which processor are used. I haven't had a chance to really test any of it, but at least there's work going on in this area.
-
I follow the TinyUSB (https://github.com/hathach/tinyusb) project, which aims to provide a common user-facing solution for the device classes it supports, while handling the chip-specific stuff in the background for you. As you can imagine, it's got a lot of preprocessor macros that sort out which USB peripheral and which processor are used. I haven't had a chance to really test any of it, but at least there's work going on in this area.
TinyUSB seems pretty good. I have tested it both on the RP2040 and the NXP iMRT1062. First developed a small demo MIDI synth on the RP2040, then I ported it to the NXP MCU using TinyUSB (which supports both), and porting was a breeze. That was definitely the easiest path for designing a USB device that you can port with little effort to other MCUs.
Of course, it still supports only a "limited" (but decent) number of targets, and for USB HS, the number is even smaller (last time I checked I think HS was only supported on one or two targets only!). But it's an active project, so it's getting there.
-
MISRA fails to remove common C pitfalls. It addresses an uninterestingly small part of actual programming errors. The problem is deep in C. It is just a powerful but somewhat dangerous language. You can't fundamentally make it better by removing half of the power, and half of the pitfalls. Mistakes will be made regardless, and the key is to find and correct the mistakes. Even better, their root causes.
The way I understand it MISRA is not only about preventing coding mistakes but also about mitigating external effects (like memory corruption). One of the requirements is not to use function pointers. IIRC that has been altered to not to use function pointers stored in volatile memory in later versions.
-
But yeah, MISRA's great for the hobbyists role-playing safety critical aerospace industry. In this regard, I completely understand why STM32 HAL is written in MISRA compliant C. It hits the target.
MISRA is certainly questionable, as most other coding rulesets or guidelines are, actually, but great for hobbyists? Are you serious? :-DD
It's de-facto in the automotive industry, and quite a few other safety-critical ones. Of course it's not the only thing that is done, but you can hardly avoid it in general. Whether you like it or not. ST is definitely not doing this for hobbyists - they are targetting those industries, for which it's a prerequisite if you intend on using any piece of code. Whether you like this or not, or whether it really is relevant or not, I'm sorry to say, absolutely doesn't matter.
-
I've seen a lot of MISRA-C complaint code from real world products. It is very bad. Like anything Cube generated by default is the cleanest code compared to that code.
MISRA-C allows any idiot write somewhat functioning code. But this comes at the expense of actually competent programmers not being able to write good code. So you just standardize mediocrity. In theory it allows you to hire bad programmers, but as I said, in practice MISRA-compliant code looks like hot garbage and it is a miracle it works, so in the end hiring bad programmers may not be a good idea.
And the same thing comes into play - all those things I've seen are overly engineered, which also shows me complete lack of experience by people working on that stuff.
-
", there is a certain amount of satisfaction knowing you designed something "just right" with little to no waste or any vestigial parts. "
However, that disregards the massive savings you make by re-using hardware and software developed for a previous product.
Secondary benefits are big reductions in the range of components which have to be stocked.
Coming back to CubeIDE, what I don't get is why the granularity is so coarse. The result is that a lot of the generated code is reading back config register bits and then bypassing code if some feature is not invoked by earlier code. This is stupid.
-
MISRA-C allows any idiot write somewhat functioning code. But this comes at the expense of actually competent programmers not being able to write good code. So you just standardize mediocrity.
I guess you could say that, although a number of the MISRA-C rules (not all for sure, I agree with this!) are really common sense and hard to question. Yeah, others are more questionable.
But as I said, all of this doesn't (unfortunately, you could say) really matter. MISRA-C has become industry-standard in some areas, and you just can't avoid it. If you hate it, better work in a different area.
You're of course entitled to have this opinion - just saying that, no matter how good or bad MISRA is, many people just have to do with it, and to get back to ST, you can't blame them for following MISRA-C guidelines. They do it for a reason.
Now do these hard rules and methods hinder software development in some way? I think so. It's a bit like the frantic agile movement. And yes, you're right, part of it is to allow hiring less competent programmers - which means making the hiring process much easier, and making replacing people easier too.
-
I follow the TinyUSB (https://github.com/hathach/tinyusb) project, which aims to provide a common user-facing solution for the device classes it supports, while handling the chip-specific stuff in the background for you. As you can imagine, it's got a lot of preprocessor macros that sort out which USB peripheral and which processor are used. I haven't had a chance to really test any of it, but at least there's work going on in this area.
I've been using TinyUSB for the device side of a project I'm working on, and have been generally pleased with it. The niche it intends to fill, which is people who don't want to suffer the weird licensing terms of a vendor-specific stack and don't want to pay $$$ for a commercial 3rd party stack, is one that needs more attention.
My main gripe with it is that they don't seem to be putting as much effort into the host side of things. Which is a shame, because I'm working on another project where I'd gladly ditch the vendor stack if they did.
(In both cases, I've needed to make minor modifications to these stacks to deal with real world issues they neglected to cover. I'd much rather make such modifications to a full F/OSS solution where I can easily publish the change I had to make, than to something distributed under semi-restrictive terms where their source goes into a repo as periodic dumps and there's really no one on the other end to have a conversation with.)
-
I guess you could say that, although a number of the MISRA-C rules (not all for sure, I agree with this!) are really common sense and hard to question.
But those things are already a part of the coding styles, and have been for ages before MISRA came in.
If you hate it, better work in a different area.
For sure, I'm not arguing that it did not become standard. And I personally would do everything I can to avoid working in such environment, as it is a huge waste of time and productivity. This may reduce my earning possibilities, but I prefer sanity over that.
Significant part of what MISRA-C is for is to cover your ass in case of issues. The more paper you have have - the cleaner your butt.
-
"part of it is to allow hiring less competent programmers "
Surely that was the purpose of C++ ? ;)
If you have say 20 people working on one product, in C, it's likely to end up a mess, because no more than 2 or 3 of them will be good.
Kidding aside, I had never heard of MISRA, so I searched for it. Found a lot of people trying to make money out of it - presumably selling validation/consultancy services :)
This has some info
https://pvs-studio.com/en/blog/posts/cpp/0702/
and it looks like good stuff. I too avoid malloc(). This is quite funny - who does it??
"Loop counters mustn't be of the floating-point type"
Actually I have used malloc() but only in an RTOS task which is started optionally and never terminates, so there is no free(). It avoids wasting static memory, and avoids the need for a huge RTOS stack for that task.
-
If you have say 20 people working on one product, in C, it's likely to end up a mess, because no more than 2 or 3 of them will be good.
But from places that need MISRA compliance, you would expect to naturally hire better people.
Found a lot of people trying to make money out of it - presumably selling validation/consultancy services :)
Yep. That's pretty much the point.
"Loop counters mustn't be of the floating-point type"
Not only that. Loops must generally be over positive integers and don't have complex ending conditions.
There are a lot of other bat shit crazy requirements.
The issue that MISRA solved a long time ago was lack of static code checking in compilers. We have that now. Most concrete things from MISRA are now checked by the compiler. And other more organizational requirements are not really checked at all, even by those expensive tools.
Also, MISRA allows exceptions as long as you document them and explain why you need it. Which relies on a better judgment, which in this case will come from the same unqualified, but easy to hire people.
And yes, I understand why framework authors make their code MISRA compliant, but that is also a good reason to not use it - it always ends up more convoluted and complicated to workaround artificial limitations.
-
"part of it is to allow hiring less competent programmers "
Surely that was the purpose of C++ ? ;)
This is exactly what Linus Torvalds said.
C++ is a horrible language. It’s made more horrible by the fact that a lot of substandard programmers use it, to the point where it’s much much easier to generate total and utter crap with it. Quite frankly, even if the choice of C were to do *nothing* but keep the C++ programmers out, that in itself would be a huge reason to use C.
-
I have a complete solution for MISRA compliance: Pascal 1975 :)
That is roughly the level at which I use C. The other day I found this gem, which works but I have little idea why (actually I did look it up)
amplitude0 = (amplitude0 > 32768) ? 32768 : ((amplitude0 < -32768) ? -32768 : amplitude0);
(the variable is int32_t, btw)
Someone could suggest Pascal to ST, as a Cube option.
-
Well hiring better people..... they stopped teaching C in universities and colleges.
Most new applicants have C# or C++.
It takes some time to learn them the embedded C ropes and then the question remains if it is a good move for a recently graduated SW engineer to learn embedded C ?
I always said yes but the last years seeing the job advertisements I start to say no.
If you need to get another 30 years working before retirement you better do something modern that is still in demand over fifteen years.
-
Well hiring better people..... they stopped teaching C in universities and colleges.
Most new applicants have C# or C++.
You are hiring embedded people, what C#? C++ is fine, as long as they understand how to apply it in embedded systems.
if it is a good move for a recently graduated SW engineer to learn embedded C ?
If they want to do embedded work, then what are their other options?
All MISRA code I had to review was in C, not even C++. I don't anticipate this to change for some time.
-
Well hiring better people..... they stopped teaching C in universities and colleges.
Most new applicants have C# or C++.
You are hiring embedded people, what C#? C++ is fine, as long as they understand how to apply it in embedded systems.
if it is a good move for a recently graduated SW engineer to learn embedded C ?
If they want to do embedded work, then what are their other options?
All MISRA code I had to review was in C, not even C++. I don't anticipate this to change for some time.
I agree the embedded world moves slowly. Not long ago there where still debates about C versus assembler. IMHO the next good move would be C++ because it allows getting rid of using pointers (passing a struct by reference is a whole lot safer than using a pointer).
But a much better move would be to use a scripted language like Lua or Python which runs in a VM and has boundary checks built in. But that likely takes another decade to become considered as a viable option.
-
It takes some time to learn them the embedded C ropes and then the question remains if it is a good move for a recently graduated SW engineer to learn embedded C ?
If you want to work on embedded software, of course it is.
Now if you want to write financial software, not so much. Define your goal.
I always said yes but the last years seeing the job advertisements I start to say no.
If you need to get another 30 years working before retirement you better do something modern that is still in demand over fifteen years.
C will still be in demand long after we'll be all dead IMO. It may appear to vanish if you look at job ads - not because it's not used anymore in embedded dev (what else otherwise, as ataradov asked?), and we'll always need that, but because other kinds of software have literally exploded, so they are masking the demand. So it all depends on what you want to work on.
-
Let me clarify the job is called embedded software engineer because the software controlls industrial machines but there are no small 32 bits micros , but huge linux servers. Still the software is all written in C and we are looking to see if we are going to switch over to C++. But that is a huge effort and risk esp. when mixing in the transition phase.
Anyhow the question remains if say your nephew of 28 just graduated and looking for his first job, would you recommend him to go to an C embedded job ?
I personally would not anymore, too little good paid jobs and not very future proof.
-
Anyhow the question remains if say your nephew of 28 just graduated and looking for his first job, would you recommend him to go to an C embedded job ?
I would, since it gets you as far away as possible from web and javascript. But different people have different preferences, so ultimately it depends on what they like.
I'm not sure there are any fewer MCU-style embedded jobs. Someone has to program those things.
And if you want to get paid well, then be a lawyer or something like that.
-
I'm not sure there are any fewer MCU-style embedded jobs. Someone has to program those things.
There are more. MCU use is exploding.
And since there are fewer young people able to program in C, the demand is not going to plummet, but it's going to explode.
Now sure this will still be a "small market" compared to the rest of the software world. But ask yourself the right questions. As we said above, what do you want to do? Do you want to be able to apply for jobs that everyone else can also apply for, and thus, even if there are many jobs available, there's also a lot of competition - but maybe feel more like part of the herd, or do you prefer a niche? It's the whole question.
But the question of fearing to find no job is irrelevant. Heck, look at COBOL. Even if almost nobody is talking about it these days, and I bet you practically see no ad with a COBOL job, there's still high demand, and it pays very well. It will be the same with C.
Oh, and last word: someone really asking themselves what they should choose now to make sure it'll still be there in 15 years? It's definitely the wrong way to look at it. While I'm certain C will still be massively used in 15 years, and even in 30 years from now, you should not approach a career this way. Whatever happens in the next 15 years is yours to build. It's going to evolve. And, ironically, while C will likely still be relevant in 15 years and more, that may not be the case for other, more recent and hyped languages - so you need to reflect on that. And whatever you do now, keep preparing yourself for the next thing at all times. Just my 2 cents.
-
The thing which would worry me about C and embedded etc "exploding" is how much skill you need to do embedded work well, compared to e.g. server side coding, with PHP being probably most common historically but there are many other languages, and most people I know who do this have a very short experience (say 2 years) and those who have been doing it since the internet became popular (say year 2000) are doing their best to get out of it because they got sick of working in an environment where the requirements change so often.
Even those who run their own business - traditionally with a high level of job satisfaction because you can control your job spec - are trying to get out of it. I run a few websites and have had to deal with server side project spec and management and it is a bloody nightmare. I spec new projects to be done in PHP because it is IMHO the only language which will remain "in fashion" for many years. One site I run was done in Ruby on Rails and it is a nightmare unless you want to chuck 1k/day at someone. You can get a good PHP coder for $50/hr.
The way CubeIDE does C code generation is only enough to get you started without reading the RM. To do anything nontrivial you need the usual amount of embedded experience, as well as knowledge of where the skeletons are buried in real time code generally. And I don't see any way to get around this, other than re-use of working code, paying somebody (who has been doing it for many years) to write it, etc. So I see plenty of demand for C coders, and most of it will be embedded because C isn't used much elsewhere.
-
I would, since it gets you as far away as possible from web and javascript. But different people have different preferences, so ultimately it depends on what they like.
I understand. Embedded programming on small uCs was probably one of the most fun jobs I have had.
Unfortunately I have seen mostly all those projects move overseas where the results were not better but the labour cheaper. Hope that it will return so newer generations can also enjoy.
If you are single, a contractor and willing to travel the world you probably could earn very nicely.
If you have a family and bought a house, priorities change to finding a job closer by.
-
Should Cube behave differently on Linux to Windows?
I am trying to set up a copy of the project on a Linux machine and the project won't build. It fails to find some files... but they should come with either Cube (same version, 1.8.0, is used) or with the project files.
-
Should Cube behave differently on Linux to Windows?
I am trying to set up a copy of the project on a Linux machine and the project won't build. It fails to find some files... but they should come with either Cube (same version, 1.8.0, is used) or with the project files.
I'm using cube on Linux. The biggest pitfall with moving projects between Windows and Linux is that Linux is case sensitive where it comes to filenames and directories.
-
Indeed; I realised this pretty quickly.
I also reckon that the ST Cube libs won't build under unix, because of case diffs between some files and some directory names. They probably never tested the package they send out except under Windows.
If say 2 people collaborate on the same project, one windoze and one unix, the windoze guy needs to do a few edits on filenames :) And do them again if the ST libs are updated (which may not happen for ages, if ever, because it's obviously dangerous).
One also has to recompile any post-build executables, re-do scripts, etc, but that's not the fault of Cube. I am told one could avoid that if these were done in Java ;)
-
If say 2 people collaborate on the same project, one windoze and one unix, the windoze guy needs to do a few edits on filenames
2 or 20 or 200 all the same ballgame, they should use one repository, one and the same toolchain on the same os.
In any company (at least the four I worked for in the past) there is a document or wiki describing exactly which tools and toolchains , which versions etc. etc. should be installed. Some bigger companies offer an out of the box completely installed VM or VDI .
-
Sure, but I think you will find the ST libs won't build out - under unix - of the box, due to some case differences.
-
If say 2 people collaborate on the same project, one windoze and one unix, the windoze guy needs to do a few edits on filenames
2 or 20 or 200 all the same ballgame, they should use one repository, one and the same toolchain on the same os.
Why? The OS doesn't matter because the very same compiler is built for several OSses producing the exact same binary.
-
Why? The OS doesn't matter because the very same compiler is built for several OSses producing the exact same binary.
I agree with you, but I understand why - in certain types of corporate environment, dancing around complexity and uncertain tooling is the key which drives the management jobs. If a working product emerges, that is only a side effect.
I'm all for Doing The Right Thing. Limiting everyone to the same compiler version makes sense in embedded products, but it's already ugly enough that I would strongly avoid adding other tooling to that rule. IDE should not matter, let people use what makes them productive, and if this is a problem, then fix the broken process instead of working around it by forcing people to use the exact same tools that are broken in the same way.
The deliverable should be code, not an IDE project file. If an IDE does not support participating in a project without requiring everyone set up the same IDE, then this IDE is broken.
The fact that ST code does not work under everything else but Windows is totally unsurprising. Just don't use broken crap. Case-sensitive filenaming is basics of the basics. I understand some particular company might specialize in some niche such as Windows-only desktop apps or maybe small embedded projects always and only using PIC microcontrolers, where this does not matter. But ARM development Windows-only, ignoring all Unix-y systems? Give me a break.
-
Why? The OS doesn't matter because the very same compiler is built for several OSses producing the exact same binary.
If tested and 100% than it is not important.
But I recall severall issues in the past with spaces in filenames, makefile issues with relative paths even the runtime packages that differed with different versions of the same OS.
One of the reasons that realtime updates are blocked by the company, IT tests the new updates on all software packages before releasing.
-
Broken file and path names:
Options:
1) Fix the broken file and path names
2) Force everybody to use same OS and tool versions that luckily "work".
Come on.
I mean, if the project is so out of control that no one can know what the file names are, where they are located, and how to rename a file, how can anyone understand the code inside of those files?
-
Indeed. =)
-
Yep it's buggy crap. But it still saves design time as compared to writing everything from scratch or (god forbid) piece together your own toolchains.
Outside of super-high volume design, code generation tools are king when it comes to shortening software dev time, which is often a major NRE cost contributor.
And if code bloat is bad for performance in some cases, you can always register-bang that part and still use quick code generation for the rest.
-
Somehow this time-saving seems to waste a lot of time, evidenced by others struggling with it.
Somehow I have saved a lot of time by never trying to save time by using this crap.
This is a recurring pattern. Just saw it recently with nRF52. Tried for a week or two to use the SDK, to no avail. Gave up and implemented all peripheral code I needed in a few hours! The difference in productivity is at least an order of magnitude.
Don't buy the marketing. MCU peripherals are usually actually simple.
I mean, if it takes me 5 minutes to use UART bare metal, what is the saving potential. How quickly will I do it with Cube&HAL? 2 minutes? 30 seconds? 5 seconds? 50 nanoseconds?
My guess, based on actual reality, is, it takes at least 30 minutes; IF I have everything installed and set up and learned.
-
... if it takes me 5 minutes to use UART bare metal, what is the saving potential.
I noticed that when a piece of code is already written, most people attach substantial value to it. They feel that if they write their own code, they somehow waste the already existing code. Same way as a woodworker who already has a decent piece of wood may want to re-use it rather than buying a new piece of wood.
IMHO, code is different. It is intangible and easy to write. Moreover, writing new code is often easier than correcting the existing code. Hanging on to old pieces of code often creates more problems that it solves.
-
IMHO, code is different. It is intangible and easy to write. Moreover, writing new code is often easier than correcting the existing code. Hanging on to old pieces of code often creates more problems that it solves.
I strongly, almost violently agree. And IMHO, this is an indicator of programmers who are afraid of programming due to the lack of experience. Nothing wrong in that, except the end result is full-blown horror: the solution is to "reuse" whatever pieces of code, copy-pasting from Stack Overflow (the site), or using wrong kind of library code and code generation. People who fall into this trap, don't even understand their mistake; because they see how much time it takes to get all that code actually work, they assume that if they did not reuse that code, they would have needed to replicate the same code 1:1, which, as they don't understand the code, seems almost an impossible task. Thus, they think they "save time".
The right thing to do? Start programming, write new code, if code is too long, delete it all and rewrite. You get better and start to find smaller and simpler solutions. This isn't as hard as it sounds, because the point of comparison is not the 1000-LoC solution of cobbled-together piece of crap, you will never have to replicate that when you work from scratch. You will see how miraculously you get the job done in much less.
-
@NorthGuy & Siwastaja:
The truth is somewhere in the middle. It takes quite a bit of effort to get all the quirks from a reasonable sized software project with all the usual ways things are intertwined. Even if the code itself isn't optimal. On top of that it is easy to be fooled by pieces of code that look odd / weird but actually are written that way for a good reason. Rewriting larger chunks of code often is way more work than it seems at first sight. Remember the rule of thumb about the number of bugs per lines of code.
Then again, the structure of existing code may no longer line up well with the structure of new parts OR requirements of the software in which case a rewrite is something to consider. One of the projects I'm involved in is undergoing a complete rewrite because the existing code (partly inherited) no longer fits. That is likely going to take a big part of this year.
In most cases re-using existing, proven code is much more efficient than cooking up your own. Not seeing that as a benefit smells like the 'not invented here syndrom'. The sole reason libraries exist is to have people re-using existing code and not needing to re-invent the wheel everytime. Sure some libraries need time to learn but adding Lwip to your project is a whole lot quicker compared to coming up with your own IP stack with all the security related details that come with it. Spotting what pieces of existing code are useful and which not is a good skill to learn & have.
-
Not "reinventing the wheel" is - usually - a reasonable approach in engineering in general, but software is definitely a different beast (and it has been debated for decades whether software development is really engineering... and sure, feel free to insert another coin! ;D )
With software, it... depends. For instance, sure it might not be reasonable to develop your own printf function if you're writing "desktop" software. Now if you're writing embedded software, that may be.
And those who think that software written by others is necessarily better than what they would themselves write, yes maybe that comes from a self-confidence issue. And while it could still seem reasonable if said piece of software has been maintained by a bunch of developers (not just one), has been used and tested for years, ... just have a look at disasters that happen on a regular basis (think about the Log4j drama :-DD ) to convince yourself that even in that case, it may be worth writing your own, small and dedicated piece of software rather than relying on a third-party bloated library or tool that may just end up blowing up in your face. :popcorn:
-
Somehow this time-saving seems to waste a lot of time, evidenced by others struggling with it.
Well, it depends.
I have just helped someone set up Cube IDE on another machine, just using some instructions over instant messaging. He was compiling my project in about 30 mins, and that included recompiling a win32 command line executable which does some Cube post-build steps. This guy is a good programmer, although his expertise is in server side code which is mostly what he will be doing. But with Cube he can work on a particular module and single step through stuff, or just run USB VCP debugs. That's a huge amount of debug capability.
And the other day I properly broke my code. It crashed on start. It took me less than 5 mins to find it (it was some over-enthusiastic code clean-ups, resulting in overlapping mutex regions; always a great way to blow things up ;) ) by looking at the stack trace and some single stepping.
This is a vastly higher capability than I ever had in the old days. One day I might even learn the 99% of Cube which I have never used :) And I would dread having to set up a new project with it (somebody set this one up for me a couple of years ago) but I hope this basic hardware+software platform will last me past my actuarial life expectancy :)
It has stupid bugs, like often having to build the project _twice_ to get the Build Analyser to show up. That just shows ST have muppets looking after this project. But it's not a big deal.
And it is free, so you can have any number of people working on a project without paying out for some stupid floating license (I would never buy a tool with such copy protection; been there and always got burnt eventually). You could even give them a VMWARE VM and they just need to install the VMWARE player (well, there is the matter of the copy of win7-64 inside the VM ;) which is why you can't do this openly).
Hanging on to old pieces of code often creates more problems that it solves.
Depends on how much regression testing you need to do. In anything "real time", bugs can hide almost for ever. Once I get a platform solid, I stick with it practically for ever, and this is a big part of why almost nobody has ever found a bug in any product I released since about 1980. As the owner of my little business, this is a big motivation :) For me, bugs = huge hassle, especially if I have to open up code done years ago. If I was employed, bugs = wonderful employment opportunities :)
I once had a discussion with an electronics engineer regarding ROHS, and all the sh*it to do with having to scrap whole product families because a certain part could not be obtained lead-free. He thought ROHS was a fantastic new opportunity for designers, ensuring they would have jobs for many years. As the owner of my firm, I simply cannot get my head around such a way of thinking.
this is an indicator of programmers who are afraid of programming due to the lack of experience
That's true, but expertise is a finite thing. Especially if someone has a "life" outside electronics and software. It's like the debate between coding for IOS or Android. To code for Android you need more skill and above all more experience, because you need to know which parts of the API are common across the many varied devices. Many people don't bother and do IOS only. Not surprising; the vast majority of app writers are "kids". I get approx 5 emails per day offering to do an "app" for a site I run :)
-
@NorthGuy & Siwastaja
Are you hardware engineers by chance ?
The concensus of SW engineers is that re-using proven and tested code modules is far superior than rewriting from scratch. Some software code like network stacks take many manmonths development and many more writing testsuites that test all possible sunny and rainy day usecases.
Even if the software is not that great but open source or supported you have a forum or other means for support, to improve the code, or file bugs for the backlog to be solved in the future.
-
@NorthGuy & Siwastaja
Are you hardware engineers by chance ?
The concensus of SW engineers is that re-using proven and tested code modules is far superior than rewriting from scratch. Some software code like network stacks....
I do more software than hardware, but in my case, software means mostly firmware, I suck at doing large desktop application projects for example, maybe exactly because I try to apply MCU-proven workflows too eagerly, and they don't scale to everything. (Exactly the same pattern as software engineers struggling with MCU projects, just in the opposite way!)
Consensus doesn't matter, reality wins over consensus. Consensus depends pretty much on in what circles you work with. Besides, the track record of current software practices is not that beautiful (for example, in public healthcare, software systems that cost billions and then fail to work and cost human lives as a result, to be replaced after just a few years. This is all well documented. Digitalization is all great as a concept, but one could claim the software development practices are in crisis. Popularity of some practice does not prove anything beyond the popularity itself.)
Good microcontroller firmware developers are scarce. I know only a few, and they totally agree with my points. Trying to apply software-industry standard SW engineering practices, which struggle to work even there, to MCU development is a proven path to failure. The applications are just so fundamentally different. Microcontroller projects fundamentally depend on the hardware, but are also simple enough to be developed in teams of 1-3 people. The limited resources are needed in the fullest. Hardware engineers depend on the features listed on the datasheets. The software engineer needs to know how to implement that; best MCU engineers are those who can do both hardware and firmware, so that neither is a secondary trait.
No one suggested rewriting networking stacks just because of NIH. You are fighting against made up strawman. Reuse modules that are complex to implement, but easy to abstract, with well tested and proven solutions. TCP/IP stack - if you need the full stack with all the features - is the most classic example. If you want to DMA ADC readings, FIR filter that in real time, feed back into control loop, trig overcurrent limit, and communicate that over SPI to another microcontroller, this is all easier and safer and more maintainable to write yourself than using Cube autogeneration.
Comparing autogenerated, unreadable, non-modifiable, bloated crap from some trend tool of a year to well tested open source networking stacks - just no. They are not the same thing.
Reuse is tool among other tools, it should not be a religion. When in doubt, write code. Code can always be rewritten, and competition drives development. If existing code by others do better job - it shall win, then. Just don't do the mistake I have done a few times, promise a too large piece of software to be handled, struggle at making existing code work, start from scratch, but with too little resources and time. This is a game which is hard to win.
-
Code generation tools just make life easier, but their main strength is that they appeal to project managers. Writing low level from scratch will take 2 weeks, using a code gen tool, 2 days + 1 day of bugs cleanup. Convincing them that 10 work days is better than 3 is gonna be hard.
Actually, network stack and USB implementations have some horrendous bugs, but it's still much faster than brewing your own solution, code reuse or not.
-
@NorthGuy & Siwastaja
Are you hardware engineers by chance ?
The concensus of SW engineers is that re-using proven and tested code modules is far superior than rewriting from scratch. Some software code like network stacks....
I do more software than hardware, but in my case, software means mostly firmware, I suck at doing large desktop application projects for example, maybe exactly because I try to apply MCU-proven workflows too eagerly, and they don't scale to everything. (Exactly the same pattern as software engineers struggling with MCU projects, just in the opposite way!)
Consensus doesn't matter, reality wins over consensus. Consensus depends pretty much on in what circles you work with. Besides, the track record of current software practices is not that beautiful (for example, in public healthcare, software systems that cost billions and then fail to work and cost human lives as a result, to be replaced after just a few years. This is all well documented. Digitalization is all great as a concept, but one could claim the software development practices are in crisis. Popularity of some practice does not prove anything beyond the popularity itself.)
Good microcontroller firmware developers are scarce. I know only a few, and they totally agree with my points. Trying to apply software-industry standard SW engineering practices, which struggle to work even there, to MCU development is a proven path to failure. The applications are just so fundamentally different. Microcontroller projects fundamentally depend on the hardware, but are also simple enough to be developed in teams of 1-3 people. The limited resources are needed in the fullest. Hardware engineers depend on the features listed on the datasheets. The software engineer needs to know how to implement that; best MCU engineers are those who can do both hardware and firmware, so that neither is a secondary trait.
No one suggested rewriting networking stacks just because of NIH. You are fighting against made up strawman. Reuse modules that are complex to implement, but easy to abstract, with well tested and proven solutions. TCP/IP stack - if you need the full stack with all the features - is the most classic example. If you want to DMA ADC readings, FIR filter that in real time, feed back into control loop, trig overcurrent limit, and communicate that over SPI to another microcontroller, this is all easier and safer and more maintainable to write yourself than using Cube autogeneration.
Comparing autogenerated, unreadable, non-modifiable, bloated crap from some trend tool of a year to well tested open source networking stacks - just no. They are not the same thing.
Reuse is tool among other tools, it should not be a religion. When in doubt, write code. Code can always be rewritten, and competition drives development. If existing code by others do better job - it shall win, then. Just don't do the mistake I have done a few times, promise a too large piece of software to be handled, struggle at making existing code work, start from scratch, but with too little resources and time. This is a game which is hard to win.
I've done all of that using cube Mx and never had any problems, I just use the provided callbacks from interrupts. I've done 20kHz current loops for bldc motors. I compile with opt 3 on and use LTO and never worry about bloat
I don't have time to write peripheral drivers, especially things like ethernet so it's a big win being able to use the st libs. For other chips like the samd range I've done it all myself but it's a bit of a timesink.
-
Siwastaja
Ok lets focus on microcontroller dev only.
Those are limited projects and limited amount of code.
Still take Cube, if there is a bug it is likely to be found and fixed if ten thousand or even tenfold look at it and use it then you writing your own code.
Even if it is not fixed it will be discussed on the forum and you will know about it.
The only reason for rewriting it yourself is if you already done it so the investment has been done in the past, or the architecture and implementation do not suit you, or you don't understand it.
All perfectly fine reasons but it should not be the first step.
-
rewriting it yourself
See? This is the source of your confusion. Rewriting STM32HAL, or an RTOS, or Cube, would be pure madness. If this is the strawman you are discussing with, I understand how stupid this all sounds to you.
But if they are not needed at all, and the alternative solution is orders of magnitude simpler, then it's not about rewriting anything.
The key is that you believe writing new code is the same, or similar, to rewriting existing code. It is not. It completely depends.
But I can't make you understand this. You will, by yourself, or you will not.
In my microcontroller projects, most of the code goes into the actual application "logic" or data structures, something you need to write anyway. Not having to conform to any particular interface decided by others, but use tailored interfaces for the job, makes this program logic only easier; for example, if you can avoid creating buffers in the first place, then you don't need to manage buffers.
But looking at Cube projects, I understand how it all feels so overwhelming. I don't have that on my shoulders, at all, and thank <deity> I don't have to replicate any of that.
-
I've done 20kHz current loops for bldc motors
And I have done 500kHz loops. This was running in a few days.
But I know what the EEVBlog forum suggestion is:
It can't be done, so don't do it, hire an FPGA specialist.
-
I've done 20kHz current loops for bldc motors
And I have done 500kHz loops. This was running in a few days.
But I know what the EEVBlog forum suggestion is:
It can't be done, so don't do it, hire an FPGA specialist.
I'm sure it's possible to do that, the main bottleneck I had was the constant context switching between the other tasks. I profiled the current loop and it was only a couple of microseconds of calculations.
Again that can be solved by offloading the other tasks to another core like with those dual core ST parts.
-
See? This is the source of your confusion. Rewriting STM32HAL, or an RTOS, or Cube, would be pure madness.
If this is the strawman you are discussing with, I understand how stupid this all sounds to you.
I think we agree.
My whole point is if someone new wants to start with STM32 has a Nucleo board and wants to do something simple, Cube is at most one to two days and he has a blinky.
Letting him read datasheets , family reference manuals and Arm documentation to sort out which clocks to enable, output/input config, which deviders to program, which peripherals to enable how etc. etc. will take weeks and frustration.
There is where Cube shines IMO. That the underlying code is made so abstract that it needs more than three layers is also frustrating to me but understandable if you see how many different micro's and boards they have to support.
Still it could have been better, totaal agree there but it is much better than ten years ago.
In my microcontroller projects, most of the code goes into the actual application "logic" or data structures, something you need to write anyway.
Agree this is where the effort should be put in.
Not having to conform to any particular interface decided by others, but use tailored interfaces for the job, makes this program logic only easier; for example, if you can avoid creating buffers in the first place, then you don't need to manage buffers.
Depends, if you are up and running and have issues with some of the underlying code using too many buffers causing too large delays, yes but you can than also modify and tailor the underlying code.
I did this for example with the UART. Six years ago (maybe now it is better) you needed to say how many bytes you were expecting. Well the protocol did not have fixed byte packets so I had to interpret the packets as they came along.
So then just take in one byte at a time into your own protocol handler and figure it out there. Which does not mean you can not use the existing code.
But looking at Cube projects, I understand how it all feels so overwhelming.
Me too but the same goes for Libopencm3 or any other toolchain.
The most frustrating is if something changes in the years and older projects do not compile because of an interface change.
So I understand some people doing this kind of work for years develop their own toolchain and codebase and those people have enough experience to decide to do this.
I just would not recommend it on a forum to others, esp. knowing that 80% does not have that experience.
-
Oh boy I do hope that Somebody Else^tm would do a really good tutorial series on simple bare-metal development. Not for me, but for the beginners, like I once was, too. For the common good.
Because there really is no fundamental reason why it should take any longer than on the vendor's Libraries And Tools Of The Year.
I would do it but I don't have time, and I'm not really a tutorial writing kind of person.
I think ataradov's code examples are among the best examples on the 'net. If someone put that in motivational tutorial format, that would do the trick.
I mean, explain basic concepts like linker scripts and how the CPU works, without going too deep too early.
Fact is, when I started with ARM, specifically STM32, I never went the "cube way" (at that time, Cube didn't exist, but its precursors were equally horrible), I wrote "from scratch" from day one. The only tutorial I found was written by a Swedish Ubuntu fanboy and while that did really help me out, his linker scripts were broken and caused me a completely disproportionate amount of pain. I mean, there was only ONE big issue, the misaligned (by 4, not 8) stack pointer initialization value, and it caused colossal pain and wasted time, while everything else was a breeze.
The first LED blinker (unaffected by the misaligned stack pointer) was running in less than half an hour! I had some vendor toolchain downloading during that time, and got the LED blinker finished before the download finished. Only after I tried to call memcpy or do arithmetic on int64_t types, I was doomed. Think about it, this shows the importance of having correct references and examples.
If you cope by adding complexity, then risks for incorrectness add up, too. This is again compensated by strong marketing, trying to force large enough user base for the toolchain, so that bugs and issues are found and corrected, or social knowledge base on the Internet starts to build.
But, I'd prefer to see small and short examples that are of high quality and correct, not long examples of poor code quality like is typical in SDKs, or complicated tools that create totally unreadable code with a point&click interface, which can be only modified through that same pointy-clicky.
-
Traditionally, one started with a CPU/uC by reading the RM description of the registers, and configuring them one by one.
Usually I would use a table and just parse that.
You can't do that with STM32, because things have to be in a specific order to work. Lots of gotchas like the PLL config, and having to wait here and there. That is why all code I have seen does it directly, line by line, and in a pretty random order. The MX generated code is weird, doing some of it twice, interspersed with other stuff (which I think is wrong, because I cleaned that up and it still works.
Link scripts are horrible and almost nobody understands them. I never found good explanations.
-
Usually the ordering of things is pretty obvious. For example, you have to enable a DMA channel before you can start the peripheral that generates the DMA requests.
Also, if you want to run a piece of code at full expected clock speed, you need to enable the related clock/PLL before that code. But I think this is particularly easy, because you can start without understanding the clock tree and clocks, the chip just boots with the internal RC oscillator and Just Works. This is neat! Compare to programming "fuses" in some 8-bitters.
This is all fundamentally quite simple, with the few catches made much worse than they actually are by poor quality of documentation, and lack of high-quality simple examples.
Agree on linker scripts being confusing. The core issue is that you rarely work with them, and quite late in your "career" (hobby or professional) you start working with them. This, again, can be mitigated with good examples and documentation. Especially for a beginner, all you need is to have a linker script and startup code, you don't need to write them from scratch. They can be modified later when you have special needs.
The first STM32 LED blinker I made, just had the linker script and startup code directly fetched from the Swedish Ubuntu Guy's website, and less than 10LoC main() that turns on the GPIO clock and then writes to BSRR with some while(--i) delays inbetween. I flashed it with the UART bootloader available in STM32, no need to buy a programmer. The LED started blinking immediately. I indeed finished this faster than some larger toolset downloaded. Oh, and IIRC, I didn't have any devboard. Just soldered the chip on some random piece of PCB. Or maybe I etched a PCB for it, I used to do it a lot, even for small projects, I don't remember anymore.
(Back then, the argument was "why would you etch your own PCBs when you can get one professionally made for just $100!" Times have changed.)
-
... it should not be the first step.
The whole idea is that this is the only step, which saves you time which you would otherwise spent on other steps, also will decrease bloat in your code. I'll try to explain by example:
I did this for example with the UART.
Ok, Let's take UART as an example. Let's say I have to receive something by UART in my code. Here's how I would do it.
1. Thinking
I first think how I receive the characters from UART. I can create an ISR for UART, or I can poll in the main loop, or I can poll from within a timer ISR (shared with other processes), or I can use DMA. This depends on the UART speed, the overall structure of the program, the structure of the information etc.
Then I think of where and when I am going to parse and process the data. I may do parsing immediate. Or I may delayed until I have more time, in which case I need a buffer.
Then I think of buffering, which must meet few criterea:
- the buffer must be big enough to store all the data I receive until the parser is able to process it
- the buffer must be able to continue receiving characters while the parser processes it
- if the information comes in chuncks (e.g. packets or lines), the buffer must be big enough to fit full chuncks (although this might be impossible)
I may decide that I don't need any buffers at all (e.g. hardware FIFO with UART module is sufficient), or I may use a circular buffer, or I may need a ping-pong buffers (i.e. one buffer gets processed while the other is filled in), or I may decide on a linked list of packets. Whatever I can see fit.
Then I think how parser is going to read data from the buffer, and make sure that it will be easy to write the parser.
Once I thought this through, I can start writing code, but I don't write anything until all the parts of the system are thought through.
How long does the thinking take? In simple case less than a minute. But it may take couple hours if the case is unusual or difficult. I may consult the UART module datasheet, DMA datasheet etc.
2. Coding
I usually write in pieces - I write the smallest piece than I can, then I test and verify that it works, then I add the next piece.
UART is very simple, so I would probably make an exception and wrote receiving and buffering all at once. Most likely, I have already written something similar, so I find it, paste it, and edit it - this saves lots of typing. Instead of the parser, I create a small routine which outputs the data with printf or similar. This way I can see what will be received by the parser.
Once written I compile to eliminate all typos and make sure there's no compiler warning.
Coding will take about 10 minutes. But it totally depends on how much you need to type and whether or not you need intermediary testing.
3. Testing
I would create use cases trying to break my receiving mechanism by varying speed, content, limits. For example, if the receiving involves parsing the input into the lines, I would test various line delimiters, empty lines, enormously long lines etc.
Testing usually takes the longest. It is only few minutes with a simple circular buffer, but if something is not working it will need fixing. Or if buffers are more complex, it may take hours to fully test and fix all the bugs.
I don't feel that if someone would give me a code I could incorporate it into my process in any way. I would still need to do some coding interfacing the foreign code. I would have to eliminate thinking and succumb to whatever is offered by the foreign code. The data for the parser would arrive in the format dictated by the foreign code, and with timing dictated by the foreign code. This would create problems later, when I need to write parser. Overall, instead of doing my own design as I please, I would have to adjust everything to meet the requirements of the foreign code. What for?
-
Now do some code for transmitting data.
The interrupt may be generated only when the TX becomes empty. So you have to put a byte into it "manually" to get things started.
It gets a bit more involved.
-
Now do some code for transmitting data.
Transmitting UART is usually a bit easier than receiving because you typically can transmit at your own pace. But no matter what I do, I always employ the same process - design, write, test.
-
Now do some code for transmitting data.
The interrupt may be generated only when the TX becomes empty. So you have to put a byte into it "manually" to get things started.
It gets a bit more involved.
The old trick is to put the stuff to transmit into a FIFO, and then check to see if a transfer is already in process by checking a status flag. If not, then the transmit is kicked off by setting the transmit-complete bit to trigger its associated interrupt. In the ISR, you check to see if the transmit FIFO has something to send, and if so, pop the FIFO and write the byte to the transmitter.
Which I suppose is "a bit involved."
-
I have some basic code for an stm32 in C++. Getting something up and running on your own is a good way to get a feel for a particular mcu. It usually starts with getting some gpio code working, then continues from there as far as you want to take it.
https://github.com/cv007/NUCLEO_G031K8
https://github.com/cv007/NUCLEO32_G031K8_B
At some point you have to decide whether to keep going or decide to learn some other provided code/hal. I have a hard time wading through manufacturers code, so I normally stick to what I can produce myself. For something like an nrf52, I will create both my own code where I want and also create code using existing manufacturer code but will still have my own 'interface' (the app code does not have to deal with manufacturer code, as it is tucked away in my own functions). In some cases its easier to start with existing code, and after some investigation you discover there is really not that much there and can then simply replace it all with your own.
You can over time build up a library of your own that can be reused, and with C++ that becomes a little easier to do. One example is the Format class I have in the second linked example- I can use that for any mcu (I also use it for the nrf52, and can test in an online compiler and compare results to normal cout results via x86 compile). In that case I was trying to find a better way to deal with printf as newlib is a bit bloated in this area and there doesn't seem to be a good/easy way to 'hook' a put function into the FILE struct (which is huge). I originally used sprintf to do this work (for 32bit mcu), and the stack was used for the buffer since these are blocking functions but you have to know what kind of stack space you will require in advance. A printf replacement would also be somewhat easy to create, but the cout style is actually easier code to create and I am already in C++, so... The downside is the cout style, but can get used to it, and not really any other downsides as code size stays on par (similar size to the sprintf version for a 32k nrf52 project). The upside is you get an easy way to have formatted print to any device you want (lcd, uart, buffer, etc.) and can look at all the code in one page of a header.
Now do some code for transmitting data.
The interrupt may be generated only when the TX becomes empty. So you have to put a byte into it "manually" to get things started.
It gets a bit more involved.
From the above linked example basic tx uart code which is blocking, to a buffered/interrupt powered tx with just a few changes (its a little bit quick and dirty, but can be polished up with a little more effort)-
//inside Uart.hpp
static constexpr auto BUFSIZE{ 64 };
u8 buf_[BUFSIZE];
u8 bufIdxIn_;
u8 bufIdxOut_;
volatile u8 bufCount_;
public: //allow access to hook up isr to vector table
auto
isr ()
{
//not checking ISR.TXE bit (should be 1) as we only use TXEIE so only one way to get here
if( bufCount_ == 0 ) { reg_.CR1 and_eq compl (1<<7); return; } //TXEIE=0, done
reg_.TDR = buf_[bufIdxOut_];
if( ++bufIdxOut_ >= BUFSIZE ) bufIdxOut_ = 0;
bufCount_--;
}
private:
virtual bool
put (const char c)
{
while( bufCount_ >= BUFSIZE ){} //if buffer full, wait for txe isr to make room in buffer (read of bufCount_ needs no irq protection)
buf_[bufIdxIn_] = c;
if( ++bufIdxIn_ >= BUFSIZE ) bufIdxIn_ = 0;
//protect increment (needs write protection as var also written in isr)
{ InterruptLock lock; bufCount_++; }
reg_.CR1 or_eq (1<<7); //TXEIE=1
return true;
}
And resulting use (also quick/dirty as we need to 'manually' connect the isr function up)-
#include "MyStm32.hpp"
int
main ()
{
irqFunction( board.uart.irqN, []{ uart.isr(); } );
u32 n = 0;
while( true ) {
uart << "Hello World [" << setwf(10, '0') << n++ << "]" << endl;
delayMS( 500 );
board.led.toggle();
}
}
}
-
The concensus of SW engineers is that re-using proven and tested code modules is far superior than rewriting from scratch.
Um, that's the current consensus of non-embedded SW engineers writing relatively complex code on systems with essentially infinite resources in several dimensions.
I'm not sure it applies to deeply embedded systems, where your resources are more constrained.
...or when the "proven and tested code module" is harder to understand than what you need to accomplish.
... or when "proven and tested" is ... not so much.
... or when the existing modules are a poor match to what you actually want to do.
And about half of those "SW Engineers" will also complain bitterly about how modern Python/Arduino/whatever programmers "don't actually program, they just search for existing code and libraries to do everything they want.")
I'm unlikely to write a network or usb stack from scratch. But ... some subset of a UART, GPIO, or Timer? It hardly seems worth figuring out a library (and it surely doesn't help that the library isn't "portable" to other vendors.)
-
The concensus of SW engineers is that re-using proven and tested code modules is far superior than rewriting from scratch.
Um, that's the current consensus of non-embedded SW engineers writing relatively complex code on systems with essentially infinite resources in several dimensions.
Look around most industrial embedded systems be it for industrial machines, robots, IoT devices or cars are getting relatively complex and MBytes of ROM are standard with GBs of flash card storage on the side.
I am not talking about an 8b uC with 1kB here, those were the good ol' days.
Also touchscreen lcds with GUI libraries, sure you can write them yourself but why?
I'm unlikely to write a network or usb stack from scratch. But ... some subset of a UART, GPIO, or Timer?
That is my point and what if those vendor ready libraries require the vendors ready codestack ? How much time to port that to a selfmade optimized stack?
But as I said before, the persons that still do this made a conscious choice , often in the past, are used to their choices and have the experience, so all fine.
But I had trainees that have to make a PoC with ethernet and BT interconnectivity, they join for six months and with a standard stack they have something up and running in 4 to 5 months. They feel great they have done and finished something. No it is not perfect and product ready code but good enough for the stakeholders to decide to make a real project for it. Now try that from scratch for someone without much experience.
-
Kjelt, you are really hitting the nail!
You have all the key findings in place better than I ever could have said it. Trainees can make proof-of-concepts for investors!
And don't get me wrong, I'm not belittling this use case, it's necessary to do so. It's just that I can't do it, for psychological reasons, it feels wrong to me, so I let others do it. In fact, I would encourage to even drop the bar lower. Paper images of UIs, Arduino mockups of control circuits wired up in a mess of wires... Six months is already quite a long time to prove the concept.
Just that I feel a little bit frustrated because often this feels like wasted effort. If we just could communicate the investors about the importance of the projects without spending 6 months to create a proof-of-concept that then needs to be redone, we could go "straight into" the product phase.
But do you see the huge contrast here? In essence, you are saying these practices are used by trainees to make proof-of-concepts after which becomes the "real project". I completely agree with you. However, many others have given the impression that really high-quality, tested and safe (MISRA and all!) software comes out of this same process. I don't agree with them, and don't think it really works that way.
In any case, I think I see where the problem lies. It's in the poor interfaces and poor documentation of those more complex libraries. In optimum case, you would do simple things yourself, and then when in need of USB stack or LCD graphics library, you would just read clearly laid out documentation with examples, #include a .h, and link against the library. There is no place in this for code generation or any special tools, IMHO.
This is how it works classically. If I need zlib, I do sudo apt-get install libz-dev, #include <zlib.h>, and add -lz to linker, and read the documentation which exposes the very small and simple interface to it. And then there's a small tutorial (https://zlib.net/zlib_how.html).
And I don't have to follow any "framework" in the rest of my program, it's utterly irrelevant how it is partitioned.
-
As was mentioned before: Nowadays there a business models (e.g. this forum), where elaboration and optimization of scripted prototypes never happens, as nobody wants to pay that work. Commerce does not automatically bring out the best solution but one that is good enough.
Hobby or academic environments are different. People can/will put arbitrary amounts of effort into realizing their idea of something "nice".
Regards, Dieter
-
Look around most industrial embedded systems be it for industrial machines, robots, IoT devices or cars are getting relatively complex and MBytes of ROM are standard with GBs of flash card storage on the side.
I am not talking about an 8b uC with 1kB here, those were the good ol' days.
Also touchscreen lcds with GUI libraries, sure you can write them yourself but why?
I thought we were talking about the sort of software implemented by the ST Cube environment. Isn't that mostly low-level drivers?
I hope so. The higher-level you get, the more I dislike the idea of being tied to a particular vendor's library, unless it implements some widely accepted APIs. (For example, TI offers what is probably a pretty reasonable RTOS for its ARM chips, but I am not at all enthusiastic about using a TI-specific RTOS...)
-
Look around most industrial embedded systems be it for industrial machines, robots, IoT devices or cars are getting relatively complex and MBytes of ROM are standard with GBs of flash card storage on the side.
I am not talking about an 8b uC with 1kB here, those were the good ol' days.
Also touchscreen lcds with GUI libraries, sure you can write them yourself but why?
I thought we were talking about the sort of software implemented by the ST Cube environment. Isn't that mostly low-level drivers?
Depends what you need and what you configure, but no, it can be much more than just low-level. Just a quick google example an Ethernet LwIP stack and RTOS.
https://community.st.com/s/article/How-to-create-project-for-STM32H7-with-Ethernet-and-LwIP-stack-working
-
But I had trainees that have to make a PoC with ethernet and BT interconnectivity, they join for six months and with a standard stack they have something up and running in 4 to 5 months. They feel great they have done and finished something.
I don't advocate rewriting lwIP, zlib, or GUI libraries. If you were to write your own, this wouldn't be a rewrite, but rather something different. Otherwise, there's no reason to write your own, right? Without any doubts, using the ready-made lwIP is much better that writing your own TCP/IP stack in the wast majority of cases.
Although your estimates on how long it would take to implement TCP/IP + Arpa on your own are hugely exaggerated. I've never had to do this, but I know the underlying protocols and I guess it is probably a work for a couple of weeks, if not less. Definitely not for many months or years. And if your trainees did this, I don't see why wouldn't they feel good about their work.
-
I have participated in making UDP/IP and ARP implementations from scratch - on FPGA in VHDL - and these are just utterly trivial - even simpler on CPU than on hardware FSM.
OTOH, TCP is somewhat moving target because doing a general purpose, optimized TCP that performs well with most modern workloads, is more complicated than the simple UDP. But I can totally see how in special case a simple TCP implementation would be rather easy to do. It would not be suitable for watching cat videos from Youtube, necessarily.
-
It would not be suitable for watching cat videos from Youtube, necessarily.
... but but but Tim Berners-Lee invented the WWW specifically to optimize the sharing of cat photos and videos! Using gopher and archie searches were wholly inadequate for this very important task.
-
Although your estimates on how long it would take to implement TCP/IP + Arpa on your own are hugely exaggerated. I've never had to do this, but I know the underlying protocols and I guess it is probably a work for a couple of weeks, if not less.
Guess again. In my previous company we bought an commercial IP stack for ipv4 and ipv6.
Getting that correct (many bugs in the ipv6 stack) including fixing security took a team of four people over a year. So that is only getting a commercial stack product ready. You have to deal with all kinds of rainy day scenarios, exceptions, etc. Not just transferring and receiving some testpackets. Your product should be mature enough to be connected to a corporate network and be approved by the companies it department.
-
The old trick is to put the stuff to transmit into a FIFO, and then check to see if a transfer is already in process by checking a status flag. If not, then the transmit is kicked off by setting the transmit-complete bit to trigger its associated interrupt.
OK, yes, but to kick off the tx you will probably be using an RTOS thread (1kHz tick) or, in the old days, a timer ISR (1kHz tick). So if you are hoping to transmit at say 115.2k, you are gonna end up with very large gaps in transmitted data, each time the ex queue goes empty. It will work allright but not at the throughput you expected.
A better way timing-wise is to insert the code into fputc(), or whatever function you are outputting the data from.
In my previous company we bought an commercial IP stack for ipv4 and ipv6.
Getting that correct (many bugs in the ipv6 stack) including fixing security took a team of four people over a year.
I am not surprised. Most software is lifted from Stack Exchange at some point :) And a lot of it could have never worked at all.
But just because it is crap doesn't mean that what you can write in a few months will be lesser crap :)
I have participated in making UDP/IP and ARP implementations from scratch - on FPGA in VHDL - and these are just utterly trivial - even simpler on CPU than on hardware FSM.
Maybe 1% of good coders could do that. I used to do FPGA work too...
-
In my previous company we bought an commercial IP stack for ipv4 and ipv6. Getting that correct (many bugs in the ipv6 stack) including fixing security took a team of four people over a year. So that is only getting a commercial stack product ready. You have to deal with all kinds of rainy day scenarios, exceptions, etc. Not just transferring and receiving some testpackets.
Just read what you have written. You bought a library which was
- expensive
- not secure
- buggy
- written so badly that four people couldn't fix it for over a year
Assuming this stack included just TCP/IP + Arpa, you hardly could do any worse than that. You example doesn't compare favourably to the "write from scratch" variant. Besides, rather than digging somebody else's shit for a year, it's much more rewarding to spend few weeks writing your own code.
It is hard to find an example that would demonstrate my point better: people hugely exaggerate the usefulness of the existing code, and equally exaggerate the efforts necessarily to create your own code.
Surely, there are many cases when re-using the existing code is well warranted, as they are many cases when writing new code is better. All I want to say is that the "consensus" on that matter is shifted enormously away from where the reality is.
Your product should be mature enough to be connected to a corporate network and be approved by the companies it department.
If they require that you use one of the approved stacks, then you certainly don't have much choice. This is bureaucracy, not engineering. There are many companies who specialize on compliance - a mediocre product may cost good money if it gives you regulatory approval. If you buy such a product, that's what you pay for - the compliance. Don't expect any technical merit.
-
In my previous company we bought an commercial IP stack for ipv4 and ipv6.
Getting that correct (many bugs in the ipv6 stack) including fixing security took a team of four people over a year.
I am not surprised. Most software is lifted from Stack Exchange at some point :) And a lot of it could have never worked at all.
But just because it is crap doesn't mean that what you can write in a few months will be lesser crap :)
Indeed. Look at the long list of bug fixes in Lwip for example. Many of them are easy to overlook in the first pass; it is hard to write a good protocol stack. In the past I have written an ISDN2/ISDN30 protocol stack from scratch (mainly because these didn't exist as available IP). Getting something basic going took a few weeks but I think I have spend a year fulltime on it (off and on) before it was bulletproof.
-
You example doesn't compare favourably to the "write from scratch" variant. Besides, rather than digging somebody else's shit for a year, it's much more rewarding to spend few weeks writing your own code.
I don't want to repeat myself but you can not write a decent IPv4+6 stack in weeks.
Perhaps if you are already experienced and built it once and kept the design, notes etc. or took LwIP as example.
We are talking >30-40kB compiled code.
In a few months you would probably have bare minimum 75% sunny day coverage.
But then I guess you have to do it to believe it. Try it and we talk again perhaps you are a genius wizzard and myself and the programmers from my previous team are morons :-//
-
You bought a library which was
- not secure, - buggy, - written so badly that four people couldn't [make it work in reasonable time].
Well, that's the question, isn't it?
Is STM Cube "buggy, insecure, and badly written", or is it "proven, tested, and useful"?
You might not be "paying" in any sense other than that you're reducing your vendor choices and spending your time figuring it out, but that can still be "expensive."
-
you can not write a decent IPv4+6 stack in weeks.
I wrote networking code for 30-odd years (starting before IP!), and I'm pretty sure I couldn't write a good networking stack in "reasonable" time. :-(
In my retirement, I've pretty much avoided working on networking stuff. If writing a stack is difficult, using someone else's stack is TERRIFYING. Especially if they're not open to bug fixes, don't have the extensive debugging I'm used to, or if they don't have visible source. (like most BT stacks? Shudder.)
-
The old trick is to put the stuff to transmit into a FIFO, and then check to see if a transfer is already in process by checking a status flag. If not, then the transmit is kicked off by setting the transmit-complete bit to trigger its associated interrupt.
OK, yes, but to kick off the tx you will probably be using an RTOS thread (1kHz tick) or, in the old days, a timer ISR (1kHz tick). So if you are hoping to transmit at say 115.2k, you are gonna end up with very large gaps in transmitted data, each time the ex queue goes empty. It will work allright but not at the throughput you expected.
A better way timing-wise is to insert the code into fputc(), or whatever function you are outputting the data from.
Well, this was back in the days of 8051 and a super-loop, so no RTOS threads. But re-read the rest of what I wrote:
In the ISR, you check to see if the transmit FIFO has something to send, and if so, pop the FIFO and write the byte to the transmitter.
So there are no gaps in the transmission, as long as something keeps the transmit FIFO from emptying. And it's the fputc() or equivalent which writes to the FIFO and then checks to see if the transmitter is busy.
-
You example doesn't compare favourably to the "write from scratch" variant. Besides, rather than digging somebody else's shit for a year, it's much more rewarding to spend few weeks writing your own code.
I don't want to repeat myself but you can not write a decent IPv4+6 stack in weeks.
Perhaps if you are already experienced and built it once and kept the design, notes etc. or took LwIP as example.
We are talking >30-40kB compiled code.
In a few months you would probably have bare minimum 75% sunny day coverage.
But then I guess you have to do it to believe it. Try it and we talk again perhaps you are a genius wizzard and myself and the programmers from my previous team are morons :-//
Two things I use that I do not want to have to write from scratch: an Ethernet stack for TCP/IP and web server, and a USB Device stack.
Thing is, I understand USB enough to be able to do that, except the documentation for many micros' USB peripheral is dense and opaque.
-
Quoting nctnico, the truth is somewhere in the middle.
If integrating a complete existing TCP/IP stack and fixing/working around all the bugs took over a year for a team of four, clearly this process is broken and doesn't provide what it's supposed to do. You should be writing rest of the application and enjoying the library.
OTOH, that doesn't mean it could have been done from scratch in a few weeks, this is just way too optimistic. It sounds like the requirements for this stack were high, this was "the real thing". It's well known how colossally complex full TCP/IP solutions are.
The correct solution (for these more complex cases) is to use good existing code, and if not available, then commit into the large project from scratch. The benefit of the latter is that you gain full control and understanding over your solution. Though, if we are talking about commercial software development and not hobby projects, the team that did it should also document it very well to be able to transfer this hidden knowledge to their successors. This takes time!
Still, NorthGuy is completely right about the bias. People are ready to accept a year of work of just using a library without blinking an eye, as a normal, expected cost. In Orwellian way, this may be even called "saving time". But the mere idea of having to spend the same year of work doing something from scratch makes people outright crazy. People fear writing code, and management fears large blank sheets. People think reusing existing code as much as possible gives the assurance of getting at least something done, and that is true. At the same time, people are ready to accept whatever amount of work needed to make that existing code work, and irrationally use the amount of work required as a proof that the custom solution would have taken even more effort, maybe by orders of magnitude.
-
If integrating a complete existing TCP/IP stack and fixing/working around all the bugs took over a year for a team of four, clearly this process is broken and doesn't provide what it's supposed to do. You should be writing rest of the application and enjoying the library.
I think this is completely ridiculous. That is something like 200k (plus at least as much again in employer tax, office space cost, etc) spent on bug fixing.
There must be more to that story.
Maybe there were some weird security requirements. Once you get into TLS and all the possible vulnerabilities, it gets much more complex. Especially in an embedded system where you get issues like secure private key storage (which is impossible unless you use specialised technologies e.g. dedicated crypto chips) or even the "simple" task of obtaining root certificates which you know are not fake.
-
...
Still, NorthGuy is completely right about the bias. People are ready to accept a year of work of just using a library without blinking an eye, as a normal, expected cost. In Orwellian way, this may be even called "saving time". But the mere idea of having to spend the same year of work doing something from scratch makes people outright crazy. People fear writing code, and management fears large blank sheets. People think reusing existing code as much as possible gives the assurance of getting at least something done, and that is true. At the same time, people are ready to accept whatever amount of work needed to make that existing code work, and irrationally use the amount of work required as a proof that the custom solution would have taken even more effort, maybe by orders of magnitude.
Redoing existing work from scratch may just create more crap that later needs debugging. Debugging an existing library does create value. There is no alternative. This isn't about the professional experience of the pioneer, but about reuse. I mean library means reuse, so it's absolutely natural to find shortcomings and to write extra layers or interfaces to supplement the original.
Regards, Dieter
-
Debugging and improving an open source project makes a lot of sense, assuming it's not totally, fundamentally screwed to the point of fixing it being more work than redoing it.
A commercial product that is sold for the purpose of making life easy? Different story. If it requires major rework (as indicated by a timeframe of 4 man-years), the question then is, should it be a joint co-operation and how is money managed? Licensing will be challenging at least! If it doesn't come with full source code, debugging it will be a slow endeavor (with broken telephone to the vendor).
Finally, most often it's not question of redoing anything, as said repeatedly by many. Usually you would write something completely different; for example, a tiny subset which performs better in the exact use case, or simply something that does not exist at all.
In the end, balancing between competition and co-operation is a big philosophical question. It's a fact that both drive development. Without them, stone wheels would be still used. It does not map 1:1, but code reuse relates to co-operation, and writing new code to competition. Wise man knows when to do which, and how. This wisdom is hard to concentrate in a short forum post.
But the "consensus" bias is that code reuse is like a religion, with reduced level of healthy suspicion, while writing new code is belittled by concepts like "NIH". This is obvious if you look at many comments where people are really cautious about not using any library, but it's really fine as long as you use something, allowing that tick-in-the-box. This is just cargo cult engineering. Same can be seen in li-ion battery management where any BMS, it can be faulty or totally unsuitable for the job, ticks that box, creating false sense of security.
-
Honestly, I found the mentioned IDE not user friendly. Once I installed that in windows 7 and stopped working at one point. I saw many options were missing. I don't even know why. I think if any of us is confident that there is a bug in STM cube, we should directly mail them regarding the issue. Or at least post in the ST community: https://community.st.com/s/ (https://community.st.com/s/)
However, For those who are newly using STMcube and having difficulties in configuration and debugging, here is a good write-up that can help: https://www.theengineeringprojects.com/2021/10/first-project-using-stm32-in-stm32cubeide.html (https://www.theengineeringprojects.com/2021/10/first-project-using-stm32-in-stm32cubeide.html)
-
Quoting nctnico, the truth is somewhere in the middle.
If integrating a complete existing TCP/IP stack and fixing/working around all the bugs took over a year for a team of four, clearly this process is broken and doesn't provide what it's supposed to do. You should be writing rest of the application and enjoying the library.
OTOH, that doesn't mean it could have been done from scratch in a few weeks, this is just way too optimistic. It sounds like the requirements for this stack were high, this was "the real thing". It's well known how colossally complex full TCP/IP solutions are.
As I wrote before: due diligence is key when using a library. Believing the sales pitch is a huge mistake. More often than not I evaluate several libraries before choosing one.
-
Still, NorthGuy is completely right about the bias. People are ready to accept a year of work of just using a library without blinking an eye, as a normal, expected cost. In Orwellian way, this may be even called "saving time". But the mere idea of having to spend the same year of work doing something from scratch makes people outright crazy. People fear writing code, and management fears large blank sheets.
There must be more to that story.
Yes there is. The stack was evaluated for IPv4 and IPv6 was "promised" to be implemented in the future.
More stacks were evaluated but this one was choosen by the wise system architects.
The whole idea was to not write from scratch but to stick to core business so implement the companies product intellectual property and buy what was common stuff.
AND most important the guarantee for full stack support by that company.
Then after you bought the stack and went from prospect to customer and product testing begins even with some pentesting from other companies all hell broke loose.
Only then could you see the holes and things that went wrong, so the tickets to the company to support the stack were flowing but the support was bad.
Tickets would be solved not in days or a few weeks but rather months and communication was cumbersome.
Anyway to make a long story short, we ended up with most of the source code (ofcourse under NDA) so we could fix things ourselves more quickly instead of a compiled library.
And lessons learned do not only evaluate what you think you are going to buy, but also really invest time to see who and how many engineers are behind a product, to support and fix bugs.
Still my guestimate for developing a decent fast and reliable IP stack with IPv4+6 and some rudimentary services would still be at least a manyear, but probably more.
-
Check the include search path under project options.
You can use relative and absolute paths, and that might be the issue
-
... I do not want to have to write from scratch: an Ethernet stack for TCP/IP and web server
Me neither. Nor do I suggest to write their own TCP/IP stack to anyone. My point is that people grossly exaggerate efforts necessary to do so. And the responses clearly show that this is indeed so. Some people even think it may take years.
But then I guess you have to do it to believe it. Try it and we talk again ...
Unfortunately, I don't have time or need. If I ever implement TCP/IP, I'll try to remember to time it and post here. Until then this is all hypothetical.
... perhaps you are a genius wizzard and myself and the programmers from my previous team are morons :-//
That's not what I'm saying. Any programmer with few years of experience in low-level programming and good understanding of data structures can do that. If you wish, I can break it down into small tasks with time estimates, starting from an unprogrammed board to working TCP transmissions ready to be used by the application layer.
Look at the long list of bug fixes in Lwip for example. Many of them are easy to overlook in the first pass; it is hard to write a good protocol stack.
Programming is programming. It is not different whether you implement TCP or your application code. There will be bugs whether you like it or not. You will have to test and fix them.
-
... I do not want to have to write from scratch: an Ethernet stack for TCP/IP and web server
Me neither. Nor do I suggest to write their own TCP/IP stack to anyone. My point is that people grossly exaggerate efforts necessary to do so. And the responses clearly show that this is indeed so. Some people even think it may take years.
Those 'some people' have actual hands-on experience with large projects like that :palm:
If you've been in software engineering for a while you ought to know that development on a project (features added / bugs fixed versus time spend) slows down exponentially due to complexity (and if you are unlucky: poor architectural choices).
-
... I do not want to have to write from scratch: an Ethernet stack for TCP/IP and web server
Me neither. Nor do I suggest to write their own TCP/IP stack to anyone. My point is that people grossly exaggerate efforts necessary to do so. And the responses clearly show that this is indeed so. Some people even think it may take years.
I know that I do not know enough about networking and TCP/IP to even give an estimate about how long it would take me to write a stack. You have to understand the problem before you can work on the solution.
Other people have invested the time to fully understand IP, and they've written code to implement it. I'm happy to use lwIP, which is the result of a developer who took the time to understand IP and continues to maintain it as IP evolves. I'm glad it exists. I can put it in my micro and have a nice web server that lets me do what my projects need to do.
-
LWIP seems to work well.
However it seems to be the nature of "libraries" that most are buggy. And they remain buggy for ever - because most of these bugs are fixed by people who are paid for their time and who are not going to contribute their fixes to the wider community (confidentiality, an explicit policy to not assist the competition, and in many cases you could work out from forum posts what Company X is working on). So, almost the only bug fixes which are posted openly are fixes done by hobbyists, and they naturally have fewer resources.
Regarding ST libs, you can try reporting stuff on the ST forum but it is pretty obvious that if any ST staff do read it, they keep an exceedingly low profile ;) I have seen a few things fixed between Cube today and Cube 1 year ago, but only a few.
Check the include search path under project options.
You can use relative and absolute paths, and that might be the issue
Close; it was actually fixed under project / properties / settings / c compiler / include paths.
-
Those 'some people' have actual hands-on experience with large projects like that :palm:
:wtf: What hands-on experience? Nobody here ever said that they ever wrote their own TCP/IP implementation.
If you've been in software engineering for a while you ought to know that development on a project (features added / bugs fixed versus time spend) slows down exponentially due to complexity (and if you are unlucky: poor architectural choices).
Sure. IMHO the number of bugs grows proportional to the squared size of the code. That is exactly why, if you build your code base from dubious over-complicated libraries, it is likely to have many bugs, as Kjelt brilliantly demonstrated. And you will inevitably waste lots of your time working with such a code base. Smaller, simpler, to-the-point code will give you much less problem, and that's the kind of code you can write by yourself if you wish.
Why would you use lwIP if you can write your own? Because lwIP is decent and already does what you want. You probably won't encounter many bugs in lwIP, most likely none. So you expect to spend less time incorporating lwIP than you would if you implemented the usable portion of it by itself. But that doesn't mean that writing your own code is impossible or take lifetime to write. If the library doesn't do what you need, you don't go around buying unusable crap, you write your own.
-
Nobody here ever said that they ever wrote their own TCP/IP implementation.
We had our own TCP/IP.
It started out simple enough, but in the end (or "so far") there were hundreds of man-years invested.
Lots of special requirements, over the years.
It was glorious!
My favorite personal memory was when I implemented IP options, back before anyone else had done so.
We took the code to InterOp and sent broadcast Pings with IP options, just to see what would happen (it was long enough ago that you could get away with stuff like that.) Things crashed right and left. Other things sent horribly malformed responses. WE crashed when we tried to interpret the malformed responses! Lots of fun!
-
In real world, TCP/IP tries to put massive bandwidth over unreliable links in unreliable environment, this tuning takes 99% of the effort. Byte stream over unreliable packets isn't really the optimal thing to do, especially if the next layer parses the byte stream back to delimited packets. But this is what we have.
Of course if you just assume that packet loss is small and malformed headers do not occur, then it's easy enough to write it to the specification and just use a buffer of latest packets for resending purposes.
Until you see that results in unsatisfactory performance, buffer bloat, awkward delays whenever a packet is lost, the cat video doesn't play properly.
Open source implementations have the best chances of evolving in the right direction. Heck, even Microsoft used BSD code for their TCP/IP stack!
There is one particular option which is surprisingly widely used: if you need a very limited kind of TCP, just don't use TCP, create your simple code over UDP!
But NorthGuy is right that there are special cases where custom solutions are not that hard to do. The risk is in misidentification; what if the use case grows? Well, nothing prevents you from turning back at that point. But the more time you spend in the "simple" implementation, the more attached you come to it. This is the danger of NIH.
But yes, dangers of NIH, while real, are often exaggerated, while dangers of code reuse and libraries, while equally real, are often belittled. You just need to understand the particular case you are working with really well to make an informed choice.
-
There is one particular option which is surprisingly widely used: if you need a very limited kind of TCP, just don't use TCP, create your simple code over UDP!
Yes this is used where you control the other end. It is used for closed systems e.g. distribution of weather images, where one line can be lost and nobody cares. And a lot of the time you can send each packet a few times, just in case. Just got to make sure it is within any possible MTU, so say 1200 bytes max.
-
Just got to make sure it is within any possible MTU, so say 1200 bytes max.
Why would you have to do that? Fragmentation and reassembly all happen at the IP layer underneath UDP, so max udp payload should be up near 64k. IIRC, EGP was throwing around 18k UDP packets before it was replaced by BGP…
Although I have to disagree with your assertion that tcp is meant to deal with error-prone networks. For the last couple of decades the only errors it has worried about have been congestion. There are some other protocols to use if your network is actually lossy.
-
Fragmentation and reassembly all happen at the IP layer underneath UDP
I got that backwards then :)
UDP is used on e.g. low quality / huge latency satcomm connections (Thuraya/Iridium) where you can have latencies of the order of 1-3 secs which tend to just "destroy" TCP/IP.
I thought there was no guarantee of delivery whatsoever.
with your assertion that tcp is meant to deal with error-prone networks
Was that me?
There still are connections out there which drop a lot of packets, like the ones above.
Anyway, well off topic re the Cube IDE libraries :)
-
Just got to make sure it is within any possible MTU, so say 1200 bytes max.
Why would you have to do that?
For example, if you expect very high packet loss, say 20%. If a packet is broken down to 20 fragments, all 20 must go through to reassemble the original packet. With 20% loss, the probability of this happening is very low - around 1%. So, instead of 20% loss, you will have 99% loss. Moreover, the recipient's buffers will get clogged with lots of fragments of different packets which never will be fully assembled. You can actually mount a DoD attack by sending fragmented packets but withholding some fragments so that the packets can never be assembled.
-
Although I have to disagree with your assertion that tcp is meant to deal with error-prone networks. For the last couple of decades the only errors it has worried about have been congestion. There are some other protocols to use if your network is actually lossy.
But that's exactly what it needs to do in real world, outside test lab, you agreeing or disagreeing doesn't matter. Networks are what they are, broken devices also exist, and if this causes complete disconnects, or very long delays, or worst, wrong behavior, people start complaining. It's in the best interest of the "consumers" to make networks work as flawlessly as possible, and this is exactly what has gone into the typical TCP/IP implementations during the last many decades.
Buffer bloat alone is a huge issue when some links add delay (and jitter!), yet huge bandwidths are passed through those links (4K cat videos). It's a miracle how well modern TCP/IP works. Or, a lot of engineering. The difference can be actually seen, a modest amount of packet loss won't feel as problematic as it did maybe 20 years ago. The web page seems to open either in 100ms or then it takes a few seconds. Not that "need to wait for 2 minutes or manually refresh page" bullcrap anymore.
The question whether you need to replicate all that when rolling your own is the key question in this context.
-
Just got to make sure it is within any possible MTU, so say 1200 bytes max.
Why would you have to do that? Fragmentation and reassembly all happen at the IP layer underneath UDP, so max udp payload should be up near 64k. IIRC, EGP was throwing around 18k UDP packets before it was replaced by BGP…
I think you are mistaken TCP for UDP here. UDP is limited to whatever the maximum packet size is of the network layer (typically 1500 bytes for ethernet so the maximum UDP size is little over 1400 bytes). UDP has no fragmentation / re-assembly which makes it suitable for transmitting / streaming non critical data. For some embedded platforms I'm using much smaller maximum packet sizes; like 500 bytes or so which is enough for basic DHCP and DNS.
-
... Fragmentation and reassembly all happen at the IP layer underneath UDP ...
I think you are mistaken TCP for UDP here.
Both UDP and TCP run on top of the packet-based IP protocol (RFC 791), which provides its own mechanisms for fragmenting and defragmenting packets.
UDP simply uses these packets adding practically nothing on top of IP.
TCP provides byte stream interface on top of IP. It breaks the byte stream into fragments which are transmitted with IP packets then re-assembled back into the byte stream on the other end.
-
I think ntnico is right - because the MTU negotiation itself uses UDP packets. There is no more fragmentation support underneath UDP.
I have seen this negotiation broken a number of times, sometimes at "big" ops e.g. Vodafone. We have a server at work which was not visible from a Vodafone 3G/4G client, until the server MTU was reduced to 1300 :) They fixed it after a few months. I think it was a config issue between Voda and our ISP, so fairly obscure.
-
I think ntnico is right - because the MTU negotiation itself uses UDP packets. There is no more fragmentation support underneath UDP.
There's no need to guess, just read: https://datatracker.ietf.org/doc/html/rfc791
MTU is a characteristic of a network interface (for example, Ethernet frame may only carry 1500 bytes of payload). A packet goes through a number of hops from the source to the destination, all with their own MTUs. If a packet doesn't fit MTU ant any of these hops, the IP protocol (the one underneath UDP) will fragment the packet.
-
Unfortunately a lot of devices don't support UDP fragmentation (or any IP packet fragmentation). On Linux you'll get an error when you try to send a UDP packet which doesn't fit the MTU. You have to turn on IP fragmentation explicitly but it is highly discouraged because lots of devices don't even support it (well enough).
-
On Linux you'll get an error when you try to send a UDP packet which doesn't fit the MTU. You have to turn on IP fragmentation explicitly but it is highly discouraged because lots of devices don't even support it (well enough).
I don't get any errors. Try:
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <arpa/inet.h>
#include <netinet/in.h>
int main() {
int sockfd;
int bytes;
char buffer[0x10000];
struct sockaddr_in addr;
memset(&addr, 0, sizeof(addr));
sockfd = socket(AF_INET, SOCK_DGRAM, 0);
printf("sock fd %d\r\n", sockfd);
addr.sin_family = AF_INET;
addr.sin_addr.s_addr = htonl(0xc0a80a04);
addr.sin_port = htons(6000);
bytes = sendto(sockfd, buffer, 65000, MSG_CONFIRM, (const struct sockaddr *) &addr, sizeof(addr));
printf("sent %d\r\n", bytes);
close(sockfd);
}
It prints:
sock fd 3
sent 65000
-
I love seeing threads full of high-horse armchair experts like this one.
Early in my career, before I meaningfully entered the professional world, this was pretty much my only real exposure to those who worked within it. Everyone seemed to have such high expertise, and such a high opinion of what the standard skill level should be, that I couldn't help but feel grossly inferior and inadequate. Heck, by the impressions I was getting, I wasn't sure if I was even worthy of owning a keyboard, let alone using it to interface with a computer, or *gasp* using it to actually write software.
Then I got out there into the workforce, and was shocked and amazed at just how far this was from the truth. The average level of skill in the industry was far lower than I could have imagined. The true experts seemed more like an outlier than the norm. Its just that the riffraff didn't have as much online technical presence outside of their own workplaces.
-
On Linux you'll get an error when you try to send a UDP packet which doesn't fit the MTU. You have to turn on IP fragmentation explicitly but it is highly discouraged because lots of devices don't even support it (well enough).
I don't get any errors. Try:
Interesting. This must have been changed then at some point; documentation I have been able to find suggested that Linux wouldn't allow it without explicitly turning it on.
-
I love seeing threads full of high-horse armchair experts like this one.
Early in my career, before I meaningfully entered the professional world, this was pretty much my only real exposure to those who worked within it. Everyone seemed to have such high expertise, and such a high opinion of what the standard skill level should be, that I couldn't help but feel grossly inferior and inadequate. Heck, by the impressions I was getting, I wasn't sure if I was even worthy of owning a keyboard, let alone using it to interface with a computer, or *gasp* using it to actually write software.
Then I got out there into the workforce, and was shocked and amazed at just how far this was from the truth. The average level of skill in the industry was far lower than I could have imagined. The true experts seemed more like an outlier than the norm. Its just that the riffraff didn't have as much online technical presence outside of their own workplaces.
I've interviewed a lot of people for embedded developer positions and I can confirm that quite a few folks have substandard knowledge of fundamental embedded concepts. In many cases, their knowledge level is so low I can't see how they've held a job in the field.
I've found that the best people in the field also do it as a hobby--in fact, that's a very good indicator of how competent someone is, so I always ask that in an interview.
-
It has always been the case that to get good at anything you have to take a keen personal interest in it.
-
I love seeing threads full of high-horse armchair experts like this one.
... Everyone seemed to have such high expertise, and such a high opinion of what the standard skill level should be, that I couldn't help but feel grossly inferior and inadequate.
I have felt the same, but I didn't care, I kept improving myself despite this. Get better, that's the way to go. You don't need to become world class expert, but you need to get past the beginner state.
I despise the current trend of being proud of mediocrity and being proud about being stuck at beginner-level solutions and calling that professional just because you get paid for it.
You are right about the quality of many who appear "experts". It's actually quite easy to surpass most in this field. Now the problem is to make others see your excellency. The solution: don't care about it. Do the right thing.
What I at least try to do is not only brag with my excellent super skills (this is tongue in cheek because I know many on this forum for example do better), but try to teach others, see the "intermittent failures" thread going on where I elaborate on "instrumentation" which I talk about as an alternative to "just single-step in debugger until it works" by "professionals".
-
I've found that the best people in the field also do it as a hobby--in fact, that's a very good indicator of how competent someone is, so I always ask that in an interview.
This is also why "armchair experts" on the internet usually are right and have more comprehensive understanding, than "real experts".
Of course, within those "real experts", there are some truly highly experienced individuals who also do not struggle with basics (like the C standard) like most professionals do.
-
I've found that the best people in the field also do it as a hobby--in fact, that's a very good indicator of how competent someone is, so I always ask that in an interview.
This is also why "armchair experts" on the internet usually are right and have more comprehensive understanding, than "real experts".
Of course, within those "real experts", there are some truly highly experienced individuals who also do not struggle with basics (like the C standard) like most professionals do.
I think you might have misunderstood what I was saying. I wasn’t saying that hobbyists (someone with no formal training) make the best embedded engineers, I was saying that what you call “real experts” also happen to do personal work at home unrelated to their jobs. These people do have training in their field—they just don’t leave that training behind when they walk out the office door. I find that this correlates well with someone’s professional competence (although that’s not to say that someone who doesn’t do it as a hobby can’t be a good engineer).
-
It's the path, they started it as a hobby, it became a profession, but they never lose the ambition, so they participate in discussions about it on their free time, or do hobby projects, too.
-
When I started in the 90s the SW careerpath was as follows:
Start: Junior SW eng
3-5yrs: Medior SwEng
3-5 yrs: Senior SwEng
3-5yrs: Junior SwArch
3-5yrs: Medior SwArch
3-5 yrs: Senior SwArch
3-5 yrs: System Architect
So our system architects back then had at least 20yrs domain knowledge and hands down (in the mud) experience with one or preferably two workareas (mechanics, thermo, EE, SW, etc)
Nowadays a guy from India, 27 yrs old graduated five years ago from some university in Bangalore introduces himself: "Hi I am the Sr System Architect of the new product" :o
-
I am deeply suspicious of anyone in electronics calling themselves an "architect", "artisan" etc :)
But the business plays on this, and uses these terms to massage the inflated egos. This one is one of the best laughs https://laravel.com/
One thing which seems to be more or less true is that software guys hate software after about 40-50. It's a pity because they have loads of experience. They grow to hate the business because every few months there is a new "paradigm" or "framework", which one needs like a hole in the head.
Fortunately, in embedded work, and unless you are doing internet connectivity, you can ignore most of that IF you own the company.
-
One thing which seems to be more or less true is that software guys hate software after about 40-50. It's a pity because they have loads of experience. They grow to hate the business because every few months there is a new "paradigm" or "framework", which one needs like a hole in the head.
If you look closely enough most of these terms are bogus or new names for things that have existed long before. Take the term 'full stack developer' for example. That used to be called 'all round software developer'. Or grazy terms like CEO or something. When I grow my business bigger, I will be the general oversight director!
But it sucks if you want to get a project but get all these newfangled, meaningless terms thrown at you. I'm too old for that doo-doo. I write software, not namecards.
-
Something else has just popped up between windows and linux installs of Cube.
There are various compiler etc paths where you have to edit a \ to a / or vice versa.
Of course this is no big deal but it introduces interesting challenges on multiple people working on the same project. Basically, afaict, they can't unless only say the .c and .h files are the "common" stuff and everything else is local.
-
Typically the / is converted by Eclipse to \ when it runs on Windows. / is more or less the defacto standard for paths.
-
Typically the / is converted by Eclipse to \ when it runs on Windows. / is more or less the defacto standard for paths.
Also because Windows internally supports / as a path separator since (gasp) MS DOS 3.11 (not sure if already since 2.1).
C:\Users\newbrain\Git> cd ../STM32Cube/Repository/STM32Cube_FW_F0_V1.11.0
C:\Users\newbrain\STM32Cube\Repository\STM32Cube_FW_F0_V1.11.0>
-
Typically the / is converted by Eclipse to \ when it runs on Windows. / is more or less the defacto standard for paths.
Also because Windows internally supports / as a path separator since (gasp) MS DOS 3.11 (not sure if already since 2.1).
C:\Users\newbrain\Git> cd ../STM32Cube/Repository/STM32Cube_FW_F0_V1.11.0
C:\Users\newbrain\STM32Cube\Repository\STM32Cube_FW_F0_V1.11.0>
I've always been under the impression that support for / as path seperator has been added (as in being fully functional) later on (starting from Windows 7). On Windows 7 I can do: cd c:/windows/system32. On Windows XP this doesn't work; the slash after c: needs to be the backslash ( \ ). When I look at what Eclipse is feeding into the compiler (using Windows XP) is that the path to the source file contains C:/ but it works nevertheless. So appearantly it is not Eclipse doing the conversion, but the compiler itself.
-
Support for both types of separators was added to MS-DOS v2 along with the concept of directories. It should work on WinXP for sure. But different non-system utilities may have issues parsing that stuff, same with spaces in the names.
The reason for the whole mess is that they already used '/' for command line switches (like '/h' for help). But once directories became a thing, they wanted it to look like Unix, and even tried to switch people from using '/' for command line switches. This was done on a request from OEMs (I assume primarily IBM). You could set SWITCHAR variable in config.sys to anything you like (the expectation was that it would be set to '-'), and all system commands would accept that. But by MS-DOS v3 they gave up and removed that option.
-
You could try opening a file on XP with / as a path separator, using fopen() or even CreateFile() from the Windows API, to check this.
I suspect the problem you mention here using 'cd' in the cmd prompt is not with Windows XP not supporting / as a path separator per se, but the 'cmd' shell itself and its internal parser.
Likewise, a number of Windows applications still do not support / as a path separator. Not because of Windows - just because the app itself implements path handling functions that do not support it.
-
Finally, 1.9.0 has come out. ST have changed the compiler version and it doesn't compile anymore :)
Lots of "multiple definition of" with declaring a variable as a structure.
So, off looking at whether some config options have been changed.
EDIT: no obvious changes. It doesn't like
typedef struct __SPI_HandleTypeDef
{
SPI_TypeDef *Instance; /*!< SPI registers base address */
SPI_InitTypeDef Init; /*!< SPI communication parameters */
uint8_t *pTxBuffPtr; /*!< Pointer to SPI Tx transfer Buffer */
uint16_t TxXferSize; /*!< SPI Tx Transfer size */
__IO uint16_t TxXferCount; /*!< SPI Tx Transfer Counter */
uint8_t *pRxBuffPtr; /*!< Pointer to SPI Rx transfer Buffer */
uint16_t RxXferSize; /*!< SPI Rx Transfer size */
__IO uint16_t RxXferCount; /*!< SPI Rx Transfer Counter */
void (*RxISR)(struct __SPI_HandleTypeDef *hspi); /*!< function pointer on Rx ISR */
void (*TxISR)(struct __SPI_HandleTypeDef *hspi); /*!< function pointer on Tx ISR */
DMA_HandleTypeDef *hdmatx; /*!< SPI Tx DMA Handle parameters */
DMA_HandleTypeDef *hdmarx; /*!< SPI Rx DMA Handle parameters */
HAL_LockTypeDef Lock; /*!< Locking object */
__IO HAL_SPI_StateTypeDef State; /*!< SPI communication state */
__IO uint32_t ErrorCode; /*!< SPI Error code */
} SPI_HandleTypeDef;
SPI_HandleTypeDef hspi2;
The last line it complains about:
multiple definition of `hspi2'; .... first defined here
and referencing the same line!
-
Do you by any chance include the same file multiple times and declare the variable in the include? Although it would have been broken with the old compiler too.
But again, this is 100% you doing something wrong. Hard to tell what without more details.
-
It seems to be here
https://gcc.gnu.org/gcc-10/porting_to.html
A common mistake in C is omitting extern when declaring a global variable in a header file. If the header is included by several files it results in multiple definitions of the same variable. In previous GCC versions this error is ignored. GCC 10 defaults to -fno-common, which means a linker error will now be reported. To fix this, use extern in header files when declaring global variables, and ensure each global is defined in exactly one C file. If tentative definitions of particular variables need to be placed in a common block, __attribute__((__common__)) can be used to force that behavior even in code compiled without -fcommon. As a workaround, legacy C code where all tentative definitions should be placed into a common block can be compiled with -fcommon.
Yes doing literally what you suggest would break previous compiler.
I am working on a "test copy" of the project and fixed all the errors by using "extern" in front of stuff like this
extern TIM_HandleTypeDef htim6;
but I don't understand why. Right before that is
#include "stm32f4xx_hal_tim.h"
and in there is TIM_HandleTypeDef defined. So it isn't "external" in any way i.e. no need to resolve it with the linker. But I am no C expert. Now it compiles with no errors. And it runs. Somewhat bigger: 364.13 to 365.2kbytes.
The old bug that you have to build twice to get the Build Analyser to show is still there :)
-
The typedef should be on the header file, but not the variable declaration... That should be declared somewhere else.
Otherwise, all files including that header will re-declare the variable, causing that error.
If global, then declare an extern variable wherever it's used, or try doing so in the header file.
Ex.: main.c
SPI_HandleTypeDef hspi2;
Other files or ex. spi.h header (Where SPI_HandleTypeDef is declared):
extern SPI_HandleTypeDef hspi2;
-
The typedef should be on the header file, but not the variable declaration
You are right, of course...
Interesting ST have bundled in v10 from October 2021, which is quite recent. How solid is this?
I can continue work on Cube 1.8 and have just the one machine with Cube 1.9, for a while.
-
Don't worry about solidity of GCC. It is solid.
-
[...]
So it isn't "external" in any way i.e. no need to resolve it with the linker.
[...]
The old bug that you have to build twice to get the Build Analyser to show is still there :)
Just to make it clear: "extern" does not refer to the type.
Types are either intrinsically known to the compiler (e.g. int, char etc.) or defined in the current "translation unit" (simplifying: source file, with the includes included).
In this case, the type is defined in the HAL include file.
The linker does not really know about types*.
"extern" refers instead to the actual storage of the object: it tells the compiler (and the linker!) that the definition of the object is in another translation unit, so it should not allocate space for it "here" (simplification).
*Linkers can be made aware of the types by using "link time optimization" options during compiling and linking, but are otherwise mostly agnostic (which can lead to spectacular errors, as addressed by this SEI-CERT rule (https://wiki.sei.cmu.edu/confluence/display/c/DCL40-C.+Do+not+create+incompatible+declarations+of+the+same+function+or+object))
Oh, that GUI problem also happens with MCUxpresso. Especially with dark themes. Crappy, overbloated, pointlessly complex IDE.
-
Never got link time optimization to work. Saved *a lot* of space, but the stm32 would always boot completely dead.
Didn't lose more time fighting it as I managed to overcome the low space issue by other means.
-
Why would link time opt save space?
My simple-mind understanding of "extern" is that the compiler just needs to allocate that space, and the linker will resolve it at link time. It suppresses the "undefined symbol" warning. It probably also prevents the variable from being optimised-out if not used for any "final" purpose.
-
LTO is a completely unrelated thing. And on big projects it saves 15-30% flash space. It is essentially a recompilation of everything as a single unit at a link stage.
It is very easy to get working on plain GCC, but if your code relied on a lot of undefined behaviour and stuff like this, then it all might break, and you just have to work through it.
-
My simple-mind understanding of "extern" is that the compiler just needs to allocate that space, and the linker will resolve it at link time. It suppresses the "undefined symbol" warning. It probably also prevents the variable from being optimised-out if not used for any "final" purpose.
I'm not saying this is wrong, but... how weird way of thinking.
But I understand the confusion, there are many poor choices for reserved words in C; for example "extern", "static", etc. "extern" gives you an idea this is something about something being external, but this is not the case at all. The keyword controls the difference between declaration and definition.
The "extern" keyword just means you are declaring a variable or function: telling the compiler the important meta information such as type and type qualifiers; and of course, the fact that it exists. Memory is never reserved for it.
When you leave out "extern" keyword, then whatever you write becomes both a declaration and definition. Of course if you already have a declaration earlier, the types and qualifiers must exactly match.
It should be really this simple. It's made a bit confusing by the fact that
type func(); <-- note the ;
automatically works like there was extern written here, even if you omit it - i.e., declaration only. The idea was probably to save some typing time; compiler can figure out from the lack of function body that this can only be a declaration.
Another confusing thing are the "tentative definitions". Better just forget this part, and follow the logical and least confusing way:
* Explicit, clear declarations in header files, which are included wherever needed. This means extern keyword on all variables. It's matter of taste if you use extern on function declarations or leave it out. Doesn't affect the result.
* Exactly one definition in exactly one compilation unit, in a .c file.
Of course, if only a single .c file uses a function or a variable, and you know others never need it, then you make that function or variable static (another confusing keyword; really controls if the thing is exposed to the outside world or not), and do not add a declaration in .h. Most of the functions and variables usually are this way (which also makes one think, the static works the wrong way; the default behavior should be an "internal" function or variable, with a PUBLIC keyword or similar. But oh well, C is like this. At least the functionality is there! You just need to know how to use it.)
TLDR:
module1.h
#pragma once
extern int public_int;
extern void public_func(); // extern can be omitted here
module1.c
#include "module1.h"
int public_int;
static int private_int;
void public_func() {
...
}
static void private_func() {
...
}
-
Of course, if only a single .c file uses a function or a variable, and you know others never need it, then you make that function or variable static (another confusing keyword; really controls if the thing is exposed to the outside world or not), and do not add a declaration in .h. Most of the functions and variables usually are this way (which also makes one think, the static works the wrong way; the default behavior should be an "internal" function or variable, with a PUBLIC keyword or similar. But oh well, C is like this. At least the functionality is there! You just need to know how to use it.)
I always get a chuckle out of the absurdity of having to declare a variable as volatile static.
-
Of course, if only a single .c file uses a function or a variable, and you know others never need it, then you make that function or variable static (another confusing keyword; really controls if the thing is exposed to the outside world or not), and do not add a declaration in .h. Most of the functions and variables usually are this way (which also makes one think, the static works the wrong way; the default behavior should be an "internal" function or variable, with a PUBLIC keyword or similar. But oh well, C is like this. At least the functionality is there! You just need to know how to use it.)
I always get a chuckle out of the absurdity of having to declare a variable as volatile static.
I agree with the simple point of seeing static global symbols (variables, functions) as "private" and the others as "public".
One may question the choice in C to make things "public" by default, the other way around would probably have made more sense. But we are not going to redefine a 50-year old language - use another if you don't like it.
As to volatile static, I don't see what the chuckle is all about.
A typical example would be a static global variable that is modified in an ISR and used in other functions. Very common use. If not qualified volatile, access to said variable may get optimized out, we know the deal (same for multi-threaded programming). Making it static makes sense if it's not going to be used outside of the compilation unit it's defined in. That's something I've actually done quite often.
I would prefer any global object to be static by default as in my first paragraph, but it's not the case. So.
-
Every day is a school day :)
To me, "static" for a variable = located in main RAM (also means DMA can access it, in my 32F4 project, although of course one can have statics in the CCM too). For a function, it is private to the .c file (but still needs a prototype if called by code before it).
Globals have to be static (in main RAM or in CCM) although I don't use that qualifier; I just declare them before / outside of any function. Not actually true; you could have a variable declared on the stack in main() and so long as main() never terminates, these will be always accessible.
-
Globals have to be static
Global variables declared "static" behave like static functions. They "must" have permanence, but their scope is limited to the source file that they are defined in.
> cat bar.c
#include <stdio.h>
extern void bar1(int);
static int x;
int main() {
printf("%d", x);
bar1(x);
}
> cat bar1.c
#include <stdio.h>
extern int x;
void bar1(int a) {
printf("%d, %d\n", x, a);
}
> gcc bar.c bar1.c
Undefined symbols for architecture x86_64:
"_x", referenced from:
_bar1 in bar1-4f0ab8.o
ld: symbol(s) not found for architecture x86_64It is perhaps unfortunate from some academic purity PoV that C uses "static" to indicate both locality and permanence, and that global variables default to "permanent but not local" and function variables default to "local but not permanent", but that's usually the way you want things to be.
-
As to volatile static, I don't see what the chuckle is all about.
You'd get the chuckle better if you didn't know what the keywords mean in C. Look at dictionary definitions!
Yes, the keywords chosen are absolutely ridiculous. Like if you have a red hammer, you describe it in C as "blue nail". Then you just learn, learn and learn until you know that in C, blue means red and nail means hammer.
This mess is saved by the the small number of such ridiculous keywords choices. You can learn a few stupid details in matter of weeks, if you choose to do so, and have proper information available.
C could be made (seemingly) much better by maybe 5-10 small changes in the language (including making things "private" by default as you say), but on the other hand, the changes would be small enough so that we can also totally live with as it is now.
-
To me, "static" for a variable = located in main RAM
No!
Note that static has two different meanings!
Outside function body, static just controls whether the thing (function or variable) is public or private. Either way, static or not, the variable ends up in .data or .bss! The difference is whether the compiler exposes the symbol for the linker. If it's static, it's truly private; different compilation units can have a variable under the same name, and they end up being totally different. "Global" is not a descriptive word for such variable; it's "global" only for the compilation unit, but not for the project. Now, non-static is global for the project.
Inside function body, static makes the variable act like it was defined outside of the function, even though the scope of access is still within that function; i.e., it will retain the values (and be initialized like globals).
-
LTO is a completely unrelated thing.
It is for effects on the compiled code, but making the intermediate representation available to the linker (instead of a fully compiled object) enables the linker (which as Siwastaja said is now really compiling the whole thing) to catch conflicting type errors.
C:\Users\newbrain> get-content a.c
extern int *a;
int main(void)
{
return a[0];
}
C:\Users\newbrain> get-content b.c
int a[] = { 1, 2, 3, 4 };
C:\Users\newbrain> arm-none-eabi-gcc -c b.c -o b.o -flto; arm-none-eabi-gcc -c a.c -o a.o -flto
C:\Users\newbrain> arm-none-eabi-gcc -flto a.o b.o -o ab
a.c:1:13: warning: type of 'a' does not match original declaration [-Wlto-type-mismatch]
1 | extern int *a;
| ^
b.c:1:5: note: 'a' was previously declared here
1 | int a[] = { 1, 2, 3, 4 };
| ^
b.c:1:5: note: code may be misoptimized unless '-fno-strict-aliasing' is used
C:\Users\newbrain> arm-none-eabi-gcc -c b.c -o b.o ; arm-none-eabi-gcc -c a.c -o a.o
C:\Users\newbrain> arm-none-eabi-gcc a.o b.o -o ab
C:\Users\newbrain>
-
Siwastaja - I knew that bit but you put it much better than I could :)
-
As to volatile static, I don't see what the chuckle is all about.
You'd get the chuckle better if you didn't know what the keywords mean in C. Look at dictionary definitions!
Yes, the keywords chosen are absolutely ridiculous. Like if you have a red hammer, you describe it in C as "blue nail". Then you just learn, learn and learn until you know that in C, blue means red and nail means hammer.
That's cute, but kind of pointless. =)
If you insist on programming languages having the usual semantics of natural languages, you're in for a lot of chuckling. Conversely, insisting on doing just that when designing a programming language *has* been attempted numerous times in the past and often led to even more ridiculous stuff.
That said, the "static" keyword is poorly choosen in C, but it's probably a matter of legacy. The keyword may have not had the full definition in C it has these days when it was first introduced (I do not know enough of "original" C to remember that clearly.) For instance, it has a pretty different meaning when used for qualifying local variables inside a function, and used outside on global objects. The natural semantics of "static" makes more sense for the former.
-
It even gets better with "const" in C++. Reuse of keywords appears to be what experts consider "C style". Like physicists say about quantum mechanics: You don't understand it, but you get used to it.
Anyways there is enough open source available nowadays (e.g. the STM32 Cube libraries). So you just need to change your attitude and try to learn something from there.
Regards, Dieter
-
Static is one of the simplest aspects of C language, why all this?
You could pass a pointer to a static, and use the pointer inside an interrupt.
Does it make sense? I don't know... But the compiler should be aware of that condition by declaring it as volatile, right?
Static is very useful sometimes.
Declared as static global? Like private in other languages, can only be accesed by functions in that source file.
Inside a function? Same as local variables, but becomes non-volatile, always keeping its value. Very handy for machine states, timers...
-
As to volatile static, I don't see what the chuckle is all about.
You'd get the chuckle better if you didn't know what the keywords mean in C. Look at dictionary definitions!\
Dang, I wish I didn't have to explain what I mean, but ...
I know what the keywords mean in C.
I also know what the words mean in English.
"static" means "doesn't change."
"volatile" means "subject to change without notice."
The two words are antonyms.
Hence, the chuckle.
-
It even gets better with "const" in C++. Reuse of keywords appears to be what experts consider "C style".
The reuse of keywords when adding features to an existing language is most often a necessity.
Adding more keywords is problematic and always has to be carefully weighed in. It's bound to increase the probability of getting identifier clash on existing code, for instance.
Now some languages try to circumvent that by adding new "operators" when adding features, instead of keywords. While keywords can clash with identifiers, new operators (usually, but they have to be choosen carefully) can't. Up to you to decide if putting a lot of !, ?, @, @! or whatever looks less confusing than reusing keywords with a slightly different semantic. :popcorn:
-
Correct me if I'm wrong, it's const which is for "doesn't change (ever)", static is like "local variable but keeps the value".
Doesn't define anything about its volatibility.
What about changing the thread title to "Learning to use Cube IDE and stm32”? :D
-
Correct me if I'm wrong, it's const which is for "doesn't change (ever)", static is like "local variable but keeps the value".
Read above. That is only one use for static; the one which is likely the more "original" one as it makes sense in the human language meaning.
Static keyword is also reused for a completely different purpose, to control the internalness/externalness of the variable or function.
Reuse of same keywords for totally different purposes is highly confusing, but it's understandable indeed because you can't add keywords to a language as they would clash with existing programs (someone might have "int public;" in their program, so can't add keyword public).
-
They still haven't fixed the phantom breakpoints
(https://peter-ftp.co.uk/screenshots/20220311024092615.jpg)
It's been suspected that setting and unsetting a bkp at where the phantom one is suspected to be, removes it. But just now it didn't work. I had to select-all everything in this window
(https://peter-ftp.co.uk/screenshots/20220311364102715.jpg)
and delete them.
This issue has been there for years.
-
You mean that circle with a "-" in it? Are those actually breakpoints? This looks like code folding feature. Can you click on this minus and it will minimize the body of the function into a single line?
And do they really show up in the breakpoint list?
-
Yeah, that happens sometimes, but it's not so bad.
Just use the breakpoint window as you're doing.
-
Are those actually breakpoints? This looks like code folding feature
That is, yes. Breakpoints show like this
(https://peter-ftp.co.uk/screenshots/202203111913633118.jpg)
And do they really show up in the breakpoint list?
Affirm. AFAICT they don't show up anywhere at all. They don't even show up as disabled (unchecked) breakpoints in the breakpoint window.
It is as if they were in the bpt window but in white text :) So when you do control-a to select all, then Delete, they go.
Cube did have issues with white text in the console window, but it was machine-dependent (was seen on win7-64 and win10, but running Cube over RDP (remote desktop) unsurprisingly never showed that. I haven't see that problem since around 1.7 so maybe they fixed it.
Oh and BTW guess how big an "int" is in the standard 32F417 ST Cube library code?
-
Another option, if you’re using a J-Link is Segger’s Ozone debugger. I’ve found it to be much more robust and bug free than the debugger built into tools like CubeIDE.
If you’re using a Nucleo or Discovery board, Segger has firmware that converts the built-in ST-Link on the board to a J-Link.
https://www.segger.com/products/debug-probes/j-link/models/other-j-links/st-link-on-board/ (https://www.segger.com/products/debug-probes/j-link/models/other-j-links/st-link-on-board/)
-
I bought a Segger unit to try out. It worked ok but I could not see any difference. Maybe there is a difference in some situations; perhaps stuff like debugging low power modes?
I am now using STLINK V3 ISOL which is isolated and thus should make it a bit harder to blow up the target. It runs at a slower speed than STLINK V3 (there is a thread on it here somewhere) but in practice one can't tell the difference.
-
The biggest advantage of using a J-Link, IMO, is the ability to use Ozone.
-
I had a play with it and thought it was something running under MS-DOS :) A fairly typical bit of software written in the 1980s by a small company; in this case an old German one.
IMHO the debugger integration in Cube is good; they just need to improve some areas and above all make it more reliable. Frequently, Cube "loses contact" with the debugger. I don't know whether this is a timing issue or what.
-
I had a play with it and thought it was something running under MS-DOS :) A fairly typical bit of software written in the 1980s by a small company; in this case an old German one.
IMHO the debugger integration in Cube is good; they just need to improve some areas and above all make it more reliable. Frequently, Cube "loses contact" with the debugger. I don't know whether this is a timing issue or what.
Sure, Ozone looks dated on the surface, but don’t judge a book by its cover.
As Han Solo said, “She may not look like much, but she's got it where it counts, kid.”
-
OK :) but what does that actually mean in terms of specifics?
In debugging, you want breakpoints to work, and you want to examine variables when you get one. You then want to step through the code, basically.
The more pricey Segger boxes have some fancy stuff like breakpoints in FLASH (they dynamically reprogram the CPU FLASH) which gets over the 5-breakpoint hardware limit in the CPU. But this is rarely needed. And the pricey ones are really pricey.
-
OK :) but what does that actually mean in terms of specifics?
It means the basics (breakpoints, watchpoints, single-stepping) work and work very reliably. I’ve never had Ozone “lose contact” with the debugger. Ozone talks directly to a J-Link — there’s no GDB involved — and since Segger knows the internals of a J-Link intimately, I consider Ozone to be more tightly integrated with the target than most other debugger/debug pod combinations.
The internals are documented really well. I wrote an RTOS-aware extension for a custom RTOS in 30 minutes by following the details in the user manual.
There are other nice features as well. Download the user manual and give it a read.
-
Ozone looks dated on the surface
It's so ... annoying ... when something comes along and makes it obvious how "shallow" one is.I theoretically am mature and geeky enough that the bells and whistles and sheet "prettiness" of a modern desktop application are more signs of wasted hardware and developer resources than actually "important." Until I come across an older-style app, like the X-11 based MacOS implementation of EAGLE, or the Padauk IDE, or GIMP, where such modernization has been neglected. And it should be fine (and in fact I thought the EAGLE solution was an excellent compromise, back when it first came out), but it also seems so ... "Eww."
I take it Ozone is in the same category. Works fine, probably better than average, but ... you sort of wish that there were signs of more resources being deployed to do the less important stuff.
-
I've been coding since the late 1970s so am well familiar with text based tools, and "text graphics" tools. I've used the most awful ICE tools with the most awful UIs. One of them, a Japanese box sold by a UK agent for £10k, was even full of spelling mistakes in the menus. But it did work, sort of, and had real time trace which you don't get today.
However, I think if you are using an IDE for editing and compilation, then most people will expect the breakpoint and single step functionality to work in that too. And ST have almost done this. It's just not reliable; the debugger loses comms with the PC. But this could be something on the PC; who knows? Thankfully I don't need to run the target under debug for hours. Most issues are solved very quickly, and the rest can be found with debug statements.
What particularly breaks the Cube debug functionality is using the SWV ITM data console. It breaks even if I set the clock to some very slow value.
-
I updated the CubeIDE from 1.8.0 to 1.9.0. It broke things! I know it did because 1.8.0 would compile a repo, whereas1.9.0 wouldn't.
I went back to 1.8.0 and all my code and firmware is working as expected.
Anyone else had this?
Cheers,
Alberto
-
Peter and me at least. But basically because some variables were not correctly declared (In the header, instead as global inside a c file and then declared as extern in the header).
Try this:
https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/msg4059751/#msg4059751 (https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/msg4059751/#msg4059751)
Easy fix, though, just fix these variables.
-
Having casually compared compilers for decades now, its often been the case that gcc would compile things that other compilers would fail on. However, it was almost always a case of gcc being more permissive of bad things, than those other compilers failing when they shouldn't.
Over time, gcc has become less permissive of such bad things, so this problem crops up a lot less than it used to.
Its kinda surprising that these sort of changes are still happening version to version, but it likely is par for the course.
Just remember, its not that the update broke your code. Rather, its that your code was already broken, the compiler previously let it slide, and now it isn't. (Or the default on some compiler error/warning flag changed, which can be an easy fix if you look closely and figure out what it was.)
The only change in 1.9.0 that's been an issue for me so far, is the new default build output settings. However, fixing that was literally finding a box to check.
-
Is anyone using a Segger debugger with Cube v1.9?
I normally use a STLINK V3 but I tried a Segger J-Link Edu. I last tried it with Cube around version 1.6 and it worked but didn't do anything any better, plus it kept putting up a message one has to agree to regarding copyright on something, which was a nuisance.
Now, the J-Link still works but not at all reliably, loses connection to the target easily, SWV ITM debug console doesn't work at all, and the stupid message still comes up, so I will chuck it away. Might not be related to the new Cube version, but it's not worth spending time on it. I got it because so many people praised the Segger stuff.
STLINK V2 and V3 both work fine, and are very cheap. Plus I can have one on each PC on which this project is being worked on, and don't have to change the project properties if a project is restored from one to the other.
-
Is anyone using a Segger debugger with Cube v1.9?
No. It works fine and is very robust on Cube v1.8. I'll download and install Cube v1.9 this weekend and try it with my J-Links.
-
How do you get around the copyright agreement screen?
-
Is anyone using a Segger debugger with Cube v1.9?
I am, but I haven't done anything fancy with it yet.
My biggest gripe with the J-Link integration is that, for some reason, launching my code as a "Run" target never seems to work correctly. This isn't a new issue, and ST-Link has never had this issue. Sometimes it simply doesn't reset the target correctly after reloading, and sometimes it doesn't seem to load correctly at all.
However, launching it as a "Debug" target usually works just fine. (And a Debug launch with J-Link does seem to be a slightly smoother experience than a Debug launch with ST-Link)
-
Ok, so one of the problems was the declaration of a variable twice, once in .h and once in .c files. Fortunately, in the sense of compiling the code, that was that.
However, weird thing here... The firmware I'm working on allows us to jump into bootloader mode (DFU bootloader) from a command line interface. That command and jump has worked well up until version 1.80. If I recompile the code with version 1.9.0, that particular jump fails, and the firmware does a watchdog reset. Otherwise it would get stuck. The message I get without watchdog is that the USB has not been recognised.
This bootloader jump code has been used in two projects, with pretty much the same code. If I recompile the code for both projects with v1.9.0, that bootloader jump goes to hell and I either get a watchdog reset or a funky non working state.
Any ideas? Maybe something worth posting on the STM32 forum as well...
Cheers,
Alberto
-
Have you looked at the disassembly?
One of the most common unexpected optimizations in recent versions of the compilers is removal of the code when you deference a NULL pointer. This is technically an undefined behaviour in C, so compilers are free to do whatever. But in embedded systems NULL pointer is meaningful in many contexts.
-
No, I have not, but it is indeed a good idea!
Unfortunately I will need to get a PC with v1.9.0 to try it out, but that's doable. All of our code now runs on 1.9.0, and if this is an issue, then we can't update just yet.
Cheers,
Alberto
-
posting on the STM32 forum as well
That often works but only for 5 mins 30 seconds - there are so many posts that it scrolls off fast :)
Also don't post more than 10 lines of source code, otherwise nobody replies.
It is dodgy to change compiler version on any real product. I am happy to go to 1.9 because the thing I am working on won't be out for a while. Otherwise you have to do a ton of regression testing (re-testing every line in the code, basically). With 1.9 offering seemingly nothing over 1.8, and chucking in a new compiler, you can expect trouble.
-
One of the most common unexpected optimizations in recent versions of the compilers is removal of the code when you deference a NULL pointer.
So if you write safe code and put a guard in the beginning checking if pointers are initialized by verifying they are not NULL that will be removed?
Than can not be, it will cause havoc.
-
No. Comparison is not dereferencing and is not an UB.
A real case where I hit NULL deref UB with ARM gcc time ago:
unsigned *ptr = (unsigned *)0x1000;
do
{
CRC->DR = *(—ptr);
} while (ptr);
resulted in an unconditional loop, compiler’s logic is: if we really accessed *0 in the current iteration then the system have derailed already, the check in while is redundant, remove it to save space. But checking for NULL before accessing (i.e. with —ptr replaced by ptr—) worked (but I really needed to feed that last dword at 0 to CRC too).
-
C's built-in idea/assumption that memory address "0" is invalid and can't exist, but is used to signify invalid pointer instead, is nice and saves the memory and hassle of needing a separate "is_pointer_valid" variable for every pointer.
Yet, it totally breaks apart in systems where 0 actually is a valid memory address, and you need to use that. This includes many embedded systems.
I'm surprised this problem isn't widely recognized. Is there really not some command line -fallow-zero-pointers option?
-
Strictly speaking the NULL pointer doesn't need to be represented as zero internally:
"An integer constant expression with the value 0, or such an expression cast to type void *,is called a null pointer constant. If a null pointer constant is converted to a pointer type, the resulting pointer, called a null pointer, is guaranteed to compare unequal
to a pointer to any object or function".
Therefore, an implementation is free to use any representation for the NULL pointer (say -1). This way, a valid pointer to address 0 will be different from NULL. The only limitation is that void*(0) will be cast to NULL instead of to a valid pointer to address 0, but a non-constant expression, such as void*(x-x) will be cast to a valid pointer.
So, there may be a solution, but the compilers just don't use it. After all, it's not that hard to reserve the 0 address for something which is never pointed to.
-
Or live with one lost byte. The problem is about as relevant as a 32 bit unsigned tick counter that overflows every 4.3 million seconds = every 50 days. There may be a glitch or a crash. Once you are aware of it, it's easy to check and work around.
IMO this thread documents how Embedded is a moving target. Some days ago i read a paper on STM32U5 low power operation. They promote longer sleep intervals by educating developers about the extra hardware links between low power peripherals. This was difficult to learn on the MSP430 and not that important as the MSP430 remains low power even with thousands of interrupts per second. Now it seems we should learn this. And each MCU has it's own details.
Regards, Dieter
-
So if you write safe code and put a guard in the beginning checking if pointers are initialized by verifying they are not NULL that will be removed?
No, as explained above.
Specifically when applied to bootloaders, you often have bootloader placed at address 0, and this is the address that would contain the initial stack pointer for the bootloader. If you are jumping to it using a regular jump, then you would need to dereference the 0 pointer to get the value of the SP. If this is the case, you would need to do that in an assembly section.
But this is not the best way to call the bootloader anyway. A software system reset (via WDT or NVIC) is way better.
-
So if you write safe code and put a guard in the beginning checking if pointers are initialized by verifying they are not NULL that will be removed?
No, as explained above.
Specifically when applied to bootloaders, you often have bootloader placed at address 0, and this is the address that would contain the initial stack pointer for the bootloader. If you are jumping to it using a regular jump, then you would need to dereference the 0 pointer to get the value of the SP. If this is the case, you would need to do that in an assembly section.
I still find it weird that the compiler messes around with what should be an arbitrary number. It seems that GCC may remove NULL pointer checks assuming the program would crash anyway which is something I really wouldn't want to happen on an embedded (microcontroller) platform because in such a case it isn't handled by an OS gracefully.
There are some options to control the behaviour of GCC though:
-fdelete-null-pointer-checks
Assume that programs cannot safely dereference null pointers, and that no code or data element resides at address zero. This option enables simple constant folding optimizations at all optimization levels. In addition, other optimization passes in GCC use this flag to control global dataflow analyses that eliminate useless checks for null pointers; these assume that a memory access to address zero always results in a trap, so that if a pointer is checked after it has already been dereferenced, it cannot be null.
Note however that in some environments this assumption is not true. Use -fno-delete-null-pointer-checks to disable this optimization for programs that depend on that behavior.
This option is enabled by default on most targets. On Nios II ELF, it defaults to off. On AVR, CR16, and MSP430, this option is completely disabled.
Passes that use the dataflow information are enabled independently at different optimization levels.
From: https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html (https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html)
Edit: It looks like the GCC version I'm using for microcontroller targets (vanilla GCC from ARM) has -fdelete-null-pointer-checks enabled by default.
-
I still find it weird that the compiler messes around with what should be an arbitrary number. It seems that GCC may remove NULL pointer checks assuming the program would crash anyway which is something I really wouldn't want to happen on an embedded (microcontroller) platform.
This is a side effect of the optimizer that is spread over all stages of compilation. They don't internationally hunt for this use case, this removal is just a side effect of implementing the spec to the extreme.
As if was said, NULL can be anything, and 0xffffffff would be a better value in this case, but literally everything would break if you make this change.
And this may actually be useful. I ran into an issue where I inadvertently used an uninitialized pointer and the compiler removed the whole body of the function replacing it with one "udf" instruction. If the code contains undefined behaviour - just mark it as such and replace with a clear undefined instruction. This actually helped me to quickly find the source of the issue, as I've got a clear and repeatable fault.
There are some options to control the behaviour of GCC though:
This is good to know.
-
I did say pointers are the root of all evil ;)
That said, I could not completely avoid them, in things like this
data=0;
for (address=0x080e0000; address<0x080fffff; address+=4)
{
if ( (*(volatile uint32_t*)address) != data )
error++;
data+=4;
}
There was a long thread here on optimisation. GCC -O3 breaks a lot of stuff and IIRC people said that is to be expected because it is experiemental.
The daft thing is that in nearly all cases, removing code which the compiler thinks is not used, saves absolutely nothing. What % of your project is code which might do nothing? Maybe a few lines in 10000. Who would produce a compiler which does this? It is ridiculous. A compiler should optimise real code constructs. And they have been doing that for many years.
The wider issue is that if you are working on something which will also be worked on by others, you have to freeze them on version 1.8.0, and not everyone will like that.
The trouble is that nobody can guarantee their code will compile and run right on every future compiler version. People aren't perfect :)
-
As if was said, NULL can be anything, and 0xffffffff would be a better value in this case, but literally everything would break if you make this change.
That is true. But it is also the result of sloppy programming. Things like if (!my_pointer) yadayada_error(); is just bad coding since NULL can be defined as any value. BTW: IMHO you should always use conditional statements with an explicit value anyway.
-
Things like if (!my_pointer) yadayada_error(); is just bad coding since NULL can be defined as any value.
No, this is wrong on two counts:
- !my_pointer is guaranteed to yield true if my_pointer is the NULL pointer.
- NULL is defined as either the constant 0 or the same cast to (void*)
References (C11):
- 6.5.3.3 Unary arithmetic operators, §5:
The result of the logical negation operator ! is 0 if the value of its operand compares unequal to 0, 1 if the value of its operand compares equal to 0. The result has type int. The expression !E is equivalent to (0==E).
Now, 0 in a pointer context is the NULL pointer so the expression will do the right thing. - 6.3.2.3 Pointers, §3:
An integer constant expression with the value 0, or such an expression cast to type void *, is called a null pointer constant . 66) If a null pointer constant is converted to a pointer type, the resulting pointer, called a null pointer, is guaranteed to compare unequal to a pointer to any object or function.
So NULL cannot be defined in other ways, and 0 is a perfectly good NULL pointer.
If the actual machine NULL pointer needs to be something different for whatever reason, it all must happen by compiler magic.
EtA: OTOH, if one does something like (uintptr_t)p and p is a NULL pointer, I don't see anything in the standard that would prevent getting something different from 0 (but I should check more accurately, definitely nothing in 6.3.2.3).
-
Oh well this confirms again that in modern programming we do need autotesters with lots of sunny and many more rainy day scenarios, checking all desired , undesired and esp. critical behavior of the code.
If the compiler has changed something which influences the devices result, some test shall fail.
-
Yes yes. NULL and 0 are the same thing per the standard, so... as newbrain said, if it's not actually 0 behind the scenes, the compiler should silently handle this. (Now I've never encountered a platform for which the compiler would transform a 0 pointer to some other value than 0, but that may exist.)
Now obviously in cases where your own "invalid pointer" value should be something else - that you would want complete control over - just define your own constant and use it instead of NULL. That would avoid problems and avoid confusing everyone reading your code.
An example of that is in the Windows API, where the invalid "handle" value is not 0, but the largest integer that can be represented for a pointer. While "handles" are usually pointers, you're not supposed to know, and those are considered "opaque" types, so you shouldn't make any assumption. Defining your own pointer types, while often frowned upon, can be a decent alternative to limit confusion and not have to bother with what NULL or 0 really is for a pointer on your particular system, if that could be an issue.
-
Things like if (!my_pointer) yadayada_error(); is just bad coding since NULL can be defined as any value.
No, this is wrong on two counts:
- !my_pointer is guaranteed to yield true if my_pointer is the NULL pointer.
- NULL is defined as either the constant 0 or the same cast to (void*)
References (C11):
- 6.5.3.3 Unary arithmetic operators, §5:
The result of the logical negation operator ! is 0 if the value of its operand compares unequal to 0, 1 if the value of its operand compares equal to 0. The result has type int. The expression !E is equivalent to (0==E).
Now, 0 in a pointer context is the NULL pointer so the expression will do the right thing. - 6.3.2.3 Pointers, §3:
An integer constant expression with the value 0, or such an expression cast to type void *, is called a null pointer constant . 66) If a null pointer constant is converted to a pointer type, the resulting pointer, called a null pointer, is guaranteed to compare unequal to a pointer to any object or function.
So NULL cannot be defined in other ways, and 0 is a perfectly good NULL pointer.
If the actual machine NULL pointer needs to be something different for whatever reason, it all must happen by compiler magic.
EtA: OTOH, if one does something like (uintptr_t)p and p is a NULL pointer, I don't see anything in the standard that would prevent getting something different from 0 (but I should check more accurately, definitely nothing in 6.3.2.3).
:-+
Still -in general-, you have to ask yourself how robust your code is in terms of maintainability and portability across C compilers / C versions when you have to delve deep into the specifications and relying on a specific C standard for your code to do what you think it should do. I prefer code in a way that it is as unambiguous as possible to what it should (or shouldn't) do.
-
Still -in general-,
[...]
relying on a specific C standard
In general, I agree (e.g. - in general - I eschew bit fields as they are a minefield of implementation defined behaviour).
In particular, the guarantees above have been in the language since C89 (and probably in K&R), so I give them for granted.
I admit I usually write !my_pointer and feel no remorse.
(Out of curiosity, I'll check tomorrow if we have a specific design rule at work - I program for fun, very seldom at work nowadays).
-
That said, I could not completely avoid them, in things like this
data=0;
for (address=0x080e0000; address<0x080fffff; address+=4)
{
if ( (*(volatile uint32_t*)address) != data )
error++;
data+=4;
}
The compilers usually allow ways to declare an array located at the specified address. By using such array, you can avoid using pointers.
You can even build linked lists, trees, or other things alike using array indices instead of pointers.
-
Things like if (!my_pointer) yadayada_error(); is just bad coding since NULL can be defined as any value. BTW: IMHO you should always use conditional statements with an explicit value anyway.
Yeah I don't like that either at all. But not particularly because those are pointers. As you added, I dislike it in general. The reason lies in the whole confusion there has always been in C due to its original lack of a true boolean type, so any expression could serve as a condition. This looks bad IMHO and is a recipe for obfuscation. But that comes a lot from my preference for strongly-typed approaches.
Sure C has added booleans in C99 (which actually act as such, more or less), but since it has not enforced booleans for conditional expressions (for obvious compatibility with previous revisions - that would break a gigantic amount of existing code), and implicitly converts to and from integers, that doesn't change a whole lot. You can still combine booleans with integers and pointers and make a whole unreadable mess.
For fun, just look at this:
#include <stdbool.h>
bool foo(int n, void *p)
{
bool b = n > 10;
int m = b && p + 1;
return m < 2;
}
Which would not even give a single warning even with "-Wall -Wconversion".
Perfectly valid C, but what the heck. :-DD
-
Perfectly valid C, but what the heck. :-DD
I beg to differ.
Had p been any pointer but a pointer to void, that code would have been compliant.
As it is, it violates the constraint found in 6.5.6 Additive operators, §2:
Constraints
For addition, either both operands shall have arithmetic type, or one operand shall be a pointer to a complete object type and the other shall have integer type. (Incrementing is equivalent to adding 1.)
By definition, void is not a complete type, so this is not valid C.
Note that it's not UB but just plainly wrong, as the 'shall' is not satisfied inside a constraint, as oppsed to outside (UB).
Now, gcc is especially lenient here.
It will issue a warning with -std=c11 -pedantic <- That's in my default options. Maybe it says something about me :blah:
gcc accepts arithmetic on void pointers as an extension (treating them as pointers to char) - as if C needed more type relaxation...
-
Perfectly valid C, but what the heck. :-DD
I beg to differ.
Had p been any pointer but a pointer to void, that code would have been compliant.
As it is, it violates the constraint found in 6.5.6 Additive operators, §2:
Constraints
For addition, either both operands shall have arithmetic type, or one operand shall be a pointer to a complete object type and the other shall have integer type. (Incrementing is equivalent to adding 1.)
By definition, void is not a complete type, so this is not valid C.
Note that it's not UB but just plainly wrong, as the 'shall' is not satisfied inside a constraint, as oppsed to outside (UB).
Now, gcc is especially lenient here.
It will issue a warning with -std=c11 -pedantic <- That's in my default options. Maybe it says something about me :blah:
gcc accepts arithmetic on void pointers as an extension (treating them as pointers to char) - as if C needed more type relaxation...
Ahah, it was just meant as a what the heck thing. Replace the void by any type you like. I just spitted it out quickly. But it does show yet another pitfall. =)
And good catch, I'm sure many people wouldn't have noticed. But I think the point is taken.
I like C's flexibility, but IMHO, all those implicit conversions and type compatibility are atrocious from any reasonable point of view. And I think its flexibility wouldn't have greatly suffered without that.
Yes, gcc allows void * arithmetic by default, as a char *. It's pretty questionable. Clang does exactly the same by default (and like gcc, adding '-pedantic' gives a warning). Just because it essentially mimicks gcc's options and defaults as much as it can, to try and make it a drop-in replacement for gcc. (Talk about a way to push Clang/LLVM rather than strive to make it correct by default.) Anyway.
-
I eschew bit fields as they are a minefield of implementation defined behaviour
Noticed that bitfields yields significantly more optimised code with GCC on Cortex-M, an example: https://godbolt.org/z/G5ErEfrMc
-
I like C's flexibility, but IMHO, all those implicit conversions and type compatibility are atrocious from any reasonable point of view.
Not from any. You view C as an HLL. If you view C as a macro assembler, these features are not horrible, but quite desirable.
-
I don't really understand the apparently fervent requirement for "never" having to "drop down" into ASM code to do things.
I wish "they" would spend less time "undefining" behaviors that people have used for years, and more time trying to come up with a standardized way to efficiently insert ASM code.
-
All modern compilers implement bitfields the same way. The spec authors stopped paying any attention to them long time ago, but thankfully industry has established reasonable and consistent behavior. And yes, they result in good code optimizations.
I would not worry about using them too much. If you have a compiler that somehow manages to get them wrong, then you are likely to have other issues anyway.
-
I eschew bit fields as they are a minefield of implementation defined behaviour
Noticed that bitfields yields significantly more optimised code with GCC on Cortex-M, an example: https://godbolt.org/z/G5ErEfrMc
That's interesting. I had taken a look at this for x86_64, and didn't notice a difference. I just took a look with your example. And indeed, code in both cases is rather similar.
But of course it all depends on the instruction set. With RISC-V, the code is also almost the same in both cases.
So that's something to keep in mind - yes, bit fields seem more efficient on Cortex-M targets. With GCC. With Clang/LLVM, the generated code is exactly the same in both cases!
-
And this may actually be useful. I ran into an issue where I inadvertently used an uninitialized pointer and the compiler removed the whole body of the function replacing it with one "udf" instruction. If the code contains undefined behaviour - just mark it as such and replace with a clear undefined instruction. This actually helped me to quickly find the source of the issue, as I've got a clear and repeatable fault.
IMO this is an example of how deeply the C world is broken - a compiler plants a bomb in the code and we are happy about the explosion being clear and repeatable. Why not just raise a compile-time error?? Could someone show an example of deliberately leaving this "udf" in production code for good?
-
(Out of curiosity, I'll check tomorrow if we have a specific design rule at work - I program for fun, very seldom at work nowadays).
I checked, and no - no rule.
BUT: we follow SEI-CERT C rules (http://) and recommendations, and the notation if (!p) ... to check for NULL pointers is sometime used in the "compliant" examples, though I admit the prevalent one is p != NULL.
So, six of one, half dozen of the other...
-
IMO this is an example of how deeply the C world is broken - a compiler plants a bomb in the code and we are happy about the explosion being clear and repeatable. Why not just raise a compile-time error??
I do agree with that. I would much rather see an error there. I have not looked deeper (and actually could not reproduce that behaviour in an artificial test later), but with -W -Wall there were no warnings of any sort. May be even stricter set of flags would have worked.
And not being able to reproduce is easily also tells me that it is some very specific optimization that does this, not a coherent check. But at least it would be nice to see a message when the compiler decided to issue "udf" outside of the intentional assembly section.
-
IMO this is an example of how deeply the C world is broken ...
C is not broken. GCC is overdeveloped.
-
GCC faithfully implements the standard to the fullest extent. So, yes, it is the standard that is broken.
-
GCC faithfully implements the standard to the fullest extent. So, yes, it is the standard that is broken.
There are different ways to implement the standard. Nothing prevents you from implementing it in a stupid, unreasonable way. I'll try to illustrate this with an example.
Standard says "undefined" is "behavior, upon use of a nonportable or erroneous program construct or of erroneous data,
for which this International Standard imposes no requirements". IMHO "undefined" should be seen as a carte blanche for the compiler. The compiler does not need to worry about the consequences - it is up to the programmer.
For example, (x >> y) is undefined when y is 32 or greater (assuming 32-bit integers). This compiler should not worry what happens when y >= 32. This lets the compiler find the most efficient implementation. When the ISA has a shift instruction, the compiler can simply uses the instruction. What the instruction produces for y >= 32 doesn't matter. If it did, the compiler would have to generate extra code which handles y >= 32 situations properly. Thus "undefined" allows to avoid generating unnecessary code. Such is the benefit of "undefined".
Another compiler may chose a different approach - it may verify if y is indeed below 32, and if it isn't, it could produce some sort of prescribed "undefined" behaviour. As a result, instead of a single instruction, you'll get a bloated code checking for the condition which never happens.
Both approaches formally "faithfully implement the standard to the fullest extent", but the former approach is reasonable while the later one is stupid.
-
Sure, and in case of dereferencing NULL pointer, compiler chose to issue the most optimal code - a single "udf" instruction instead of a whole function that would return unpredictable results anyway. There is no check, it could statically check for this.
There is no easy way to pass judgement on what is "stupid" and what is not. It all depends on the situation and there is room to discuss.
My personal preference would be for the standard to define behaviour in all cases. The definition should make for a sensible implementation at least on the current platforms. But if not possible - then a bloated version should be implemented. But this goes back to the "high level assembler" vs a full programming language discussion.
-
What IS reasonable for a compiler is to issue proper warnings when encountering an undefined behavior per the standard. The rest is irrelevant IMO. It may implement UBs in the simplest/easiest/most "efficient" way, which sounds reasonable too, but I don't think it should really matter. Developers should just not leave UB in their code, otherwise it's their entire responsibility. If the punishment is very inefficient and convoluted code, then so be it. It's after all a possibly "reasonable" punishment.
Implementation-defined behaviors is a different beast. Developers may make use of that in particular cases, and of course in this case, they have to know what they're doing and know what the compiler is doing exactly.
Sure UBs in general are questionable. But you're not going to change this in C. So the best approach is to just avoid them in your code. If you really don't want to have to avoid UBs as defined in C, your best bet is to use another language. The rest is not reasonable. In particular, insisting on coding with UBs and expecting a specific behavior from a specific compiler and a specific version of it is face-palming material.
-
Someone else had fun here:
https://community.st.com/s/question/0D53W00001PudP1SAJ/issue-with-version-190
-
My personal preference would be for the standard to define behaviour in all cases. The definition should make for a sensible implementation at least on the current platforms. But if not possible - then a bloated version should be implemented. But this goes back to the "high level assembler" vs a full programming language discussion.
"Undefined" situation occurs when you make an error or mistake. Regardless of what happens, your program will not work anyway. By the time you test everything, errors will be removed (to the best of your ability). Thus it doesn't matter what would happen if errors were still there.
If the error can be caught at run time it's a good idea to put up a warning. If it can only be determined at run-time, the compiler needs to generate code to do this. If you like the idea, there are plenty of languages which do exactly that. Use them. There's no reason to insist that C must do the same.
I personally believe that the run-time checking is not capable of turning a poorly written software into a good one. Hence, I'd rather live without it. That's a matter of personal preference if you wish.
-
"Undefined" situation occurs when you make an error or mistake.
This depends on how you define a mistake.
As was mentioned before, if you write "a = x >> y", and compiler can trace that "y" is always bigger than 32, it can remove the entire instruction leaving "a" to have its previous value. This is nuts, but a perfectly legal optimization. And if this happens in a function where "y" depends on the parameter, the way you call the function may completely change the generated code. You wrote the function expecting the big shifts to produce 0, but you don't have the right to expect this.
Again, most modern compilers will act reasonably in cases like this, so there are no real issues. But as this thread shows, pushing optimization levels will shift what is "reasonable" and you may experience issues in edge cases. This is not a big deal in a grand scheme of things.
-
Again, most modern compilers will act reasonably in cases like this, so there are no real issues. But as this thread shows, pushing optimization levels will shift what is "reasonable" and you may experience issues in edge cases. This is not a big deal in a grand scheme of things.
I agree, the GCC maintainers are suckers for optimization. I think it's better to keep things reasonable, rather than trying to squeeze out the last drop of optimization. I think GCC already achieved reasonable level of optimizations 15-20 years ago. After that it's all diminishing returns. But certainly not a big deal. Yet.
-
compiler can trace that "y" is always bigger than 32
[...]
you don't have the right to expect this.
These are probably the two crucial points.
The compiler has limited knowledge (especially across translation units - we already had the discussion about link time optimization), and only in some case can know whether a certain statement will end up with UB.
The standard was written with an eye not to impose a heavy burden on the generated code (e.g., integer overflow, array boundary checks etc.).
A compiler could implement all checks and be compliant (aborting the program, throwing an exception or error message, and when possible giving a warning at compile time are all acceptable behaviours for UB).
Other languages are stricter, and will check a lot of things at runtime. Ariane 5, AFAICR went down for having better checks*.
Static analysers are getting better and better at discovering "bad" code, but can't catch all UB yet.
Hence, about the rights, it's fundamental with C to know where your rights begin and end.
In this respect it requires a higher level of attention than most other languages, stricter coding standards, and a deeper understanding of the rules.
* If my memory does not fail, a numeric overflow situation in some attitude sensor resulted in an Ada exception printout data to be sent on a control channel, wreaking havoc with guidance. Data from that sensor was not actually used in Ariane 5, but it was left there from Ariane 4 to simplify design.
-
if you write "a = x >> y", and compiler can trace that "y" is always bigger than 32, it can remove the entire instruction leaving "a" to have its previous value
Surely a=0 in that case, no?
How can that be a valid optimisation?
Same with x << y.
-
if you write "a = x >> y", and compiler can trace that "y" is always bigger than 32, it can remove the entire instruction leaving "a" to have its previous value
Surely a=0 in that case, no?
How can that be a valid optimisation?
Same with x << y.
What I just said, know your rights (and when you don't have them).
From ISO/IEC 9899:2011 (http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf), Chapter "6.5.7 Bitwise shift operators", §3:
[...]If the value of the right operand is negative or is greater than or equal to the width of the promoted left operand, the behavior is undefined.
Just for completeness, consider also §4 for shifts with signed integers:
[...]If E1 has a signed type and nonnegative value, and E1 × 2E2 is representable in the result type, then that is
the resulting value; otherwise, the behavior is undefined.
Why? Because not defining the behaviour makes C efficiently portable to architecture that would, e.g., throw when a shift greater than than the word size is used.
EtA: I think the rationale (http://www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10.pdf) (issued with C89, but updated for C99) should be compulsory reading (the standard, too). Then one can indulge in the extra guarantees and amenities of the common compilers, but it should be a reasoned choice (e.g., at work we have an explicit rule that allows gcc extensions).
-
If x and y are uint32_t then a=0 has to be correct.
Anything else is just setting up traps.
-
It's UB. So, you're setting your own trap.
Whether it's formally a "trap" depends on your POV. From a math POV, the result should be 0.
From a programming POV, shifting by more than the bit width of a number does not make sense.
So yeah, C has definitely many programming "quirks" regarding arithmetic. But C is not a math language. Matlab is. Kinda. =)
-
If x and y are uint32_t then a=0 has to be correct.
Anything else is just setting up traps.
Well, we have what we have. Historical reason for this behaviour is that C was just a "high level assembly". And in that respect, ">>" would be translated to an underlying assembly instruction. And the result would be whatever hardware does in that case. Most modern hardware would produce 0, but this was not the case in the 70s. So, C was originally specified to translate to the hardware as directly as possible. Nobody even thought about modern levels of optimization.
And this "reasonable" behaviour of the hardware is the result of the convergence between the hardware and the software. Nobody in their right mind would design hardware that is hard for the compilers to work with (Itanium, LOL). So, compiles and CPU architectures mostly came to an agreement, and many modern architectures include instructions to specifically match typical needs of a high level compiler. This is where defining new languages with less UB in them makes sense. But redefining that for C may mean abandoning some very old or very strange hardware, which is not inherently a bad, but C std committee will never go for that.
-
Anything else is just setting up traps.
Like, for example, the native assembler shift instruction of the PDP-11, where only the lower six bit of the shift value were taken into account, as a signed value.
So if x=0x10000 and y= 50, x << y will give you 0x0004 (a 14 bit shift right) if implemented efficiently. Traps, traps everywhere!
I am pretty sure most of modern architectures behave as you expect.
The standard tries to cater also for architectures that are not so common, leaving more leeway to corner and ill defined cases.
EtA: Heck, even the x86 uses CL mod 32 as shift count for 32 bit shift instructions!
Anyhow, you can rejoice, something is moving in a direction you may appreciate: the C2X draft (http://open-std.org/jtc1/sc22/wg14/www/docs/n2596.pdf) (C23 in the making) mandates two's complement, so at least one's complement and sign magnitude will soon(ish) be out.
-
Although even on modern ARM LSR instruction takes only lower 8 bits of the second register into account, so if R1=0xab and R2 = 0x12340001, then instruction LSR R1, R2 would result in R1 =0x55, not 0 (equivalent of shifting by 1), so it is on you (or the compiler) to ensure that the shift amount is valid.
So yeah, that's why we can't have nice things.
-
Well, we have what we have. Historical reason for this behaviour is that C was just a "high level assembly". And in that respect, ">>" would be translated to an underlying assembly instruction. And the result would be whatever hardware does in that case. Most modern hardware would produce 0, but this was not the case in the 70s. So, C was originally specified to translate to the hardware as directly as possible. Nobody even thought about modern levels of optimization.
In asm, >> is done with shift-right instructions. If you have x >> 32 then there won't be anything left in x. Simple. How can be "optimised" to anything other than 0? With a barrel shifter it is exactly the same. the ARM32 has a 32 bit barrel shifter and that will produce 0 also.
It's just a useless compiler. How can anyone pretend this is ok, with a straight face?
And a great case for not "upgrading" the compiler version, ever. When my current devt is out there, we will never again change GCC, from v10.x.
-
In asm, >> is done with shift-right instructions. If you have x >> 32 then there won't be anything left in x. Simple. How can be "optimised" to anything other than 0? With a barrel shifter it is exactly the same. the ARM32 has a 32 bit barrel shifter and that will produce 0 also.
As shown above, shift instruction does not use all the bits from the register. That's the reason for C to be specified like this - C just translates to the low level instruction and the actual behaviour is up to the hardware. Your options here is to either generate the code that would limit the value for each shift, or require the programmer to do so. C picked the later.
It's just a useless compiler. How can anyone pretend this is ok, with a straight face?
And a great case for not "upgrading" the compiler version, ever. When my current devt is out there, we will never again change GCC, from v10.x.
It has nothing to do with the recent optimizations, this behaviour has been in the standard since the beginning.
-
Here is a simple code for you:
volatile uint32_t a = 0xab;
volatile uint32_t b = 0x12340001;
volatile uint32_t c = a >> b;
Run this on any ARM MCU and look at the value of "c". It will not be 0. Volatile is just there so things don't get optimized, they have no bearing on the issue.
-
OK; I get that. Thanks.
But still if a compiler was to optimise x >> 1000, it should set x=0, not leave x unchanged.
-
But still if a compiler was to optimise x >> 1000, it should set x=0, not leave x unchanged.
No, it should not, the spec says so. It is not optimization, it is how the hardware behaves. In my example compiler issues full code, nothing is optimized out.
Although in this specific case (shift by a constant), optimizing compiler is better positioned to get things right, as it can set the result to 0 without additional overhead. Non-optimizing compiler will generate a shift instruction and the result would depend on the underlying hardware. And in case of the variables on both sides of the shift, there is nothing compiler can do, it has to issue a shift instruction.
-
OK; I guess if you are shifting by a constant and the constant is > 31 then the code is dumb anyway.
Probably in that case the # of shifts would be a result of a macro or some compile time calc because nobody will actually write x = 1 << 75.
-
OK; I guess if you are shifting by a constant and the constant is > 31 then the code is dumb anyway.
Probably in that case the # of shifts would be a result of a macro or some compile time calc because nobody will actually write x = 1 << 75.
Yep. I have inherited a piece of code that throws such a warning from a bunch of macros so I'll revisited that code some time soon.
-
OK; I get that. Thanks.
But still if a compiler was to optimise x >> 1000, it should set x=0, not leave x unchanged.
Well, you're stubborn (which is not necessarily a bad thing, but sometimes it doesn't help.) ;D
From a math standpoint, you're right. From a hardware standpoint, it depends on how the right shift is implemented. But I don't know of any CPU that can actually perform a right shift of 1000 bits in a single instruction. Now from a programming language standpoint, anything goes, and as we've said multiple times, C chose to make this UB.
As C favors efficiency, since there's usually no low-level operation that allows such a shift, then doing nothing at all is what it's allowed to do.
You may think (that's what your example seems to imply) that any compiler seeing this operation with a *literal* as the shift amount would have no difficulty optimizing this as 0. But what if the shift amount is a variable which value is not known in advance? The compiler can't do anything then: it would have to add a run-time test on all targets that do not support shift amounts that big, which is the majority. And then you'd find run-time tests sprinkled every time you use a variable shift in your code.
So out of consistency, C's behavior for this is undefined in any case - whether the shift amount is a constant or a variable.
Note that if the shift amount is a literal, the compiler will give you a warning anyway. GCC gives: "warning: right shift count >= width of type [-Wshift-count-overflow]"
But if the amount is constant, but not a literal, GCC is silent. (even with -Wall -pedantic)
So very simple examples:
int foo(int n)
{
const int shamt = 1000;
return n >> shamt;
}
=> no warning. (But Clang does give a warning for this.)
int foo(int n)
{
return n >> 1000;
}
=> warning.
cppcheck will spot the issue in both cases. I highly recommend using static analysis tools when you can. cppcheck does a decent job, it's lightweight and open-source.
-
So out of consistency, C's behavior for this is undefined in any case - whether the shift amount is a constant or a variable.
A program should produce a consistent result even if it has a bug.
This is why one pre-fills BSS with 0x00, for example: so uninitialised variables don't bite you. A perfect programmer would not need the pre-fill. And anyway you don't get the pre-fill on vars declared on the stack.
Beyond absolutely trivial code, it is impossible to be sure there isn't a bug somewhere, and it is impossible to test everything. So undefined ops are a bad thing, unless every version of a compiler does the same "undefined" thing.
-
It depends on the target hardware, not the compiler. If you don't want undefined behaviour in this case, the compiler would have to issue value check before each shift. This would lead to some very inefficient code. So, at least in the case of C it is on you to check that the value is correct where you believe it may not be. Most of the time normal program flow ensures correctness of the value, so no need to check anything.
Also, initializing BSS to 0 is a requirement, not a nice thing you do just in case. Even explicitly initialized variables with the value 0 will go to BSS section.
-
This is why one pre-fills BSS with 0x00, for example: so uninitialised variables don't bite you. A perfect programmer would not need the pre-fill. And anyway you don't get the pre-fill on vars declared on the stack.
What do you mean? That is just how the language is defined.
A perfect programmer writes good code in the boundaries set by the language definition.
I won't repeat explanations from other members or from me, you seem quite waterproof to any argument :horse:
If you don't like C, there are so many usable languages that the only problem is the time to try them all, some is also good.
Standard Pascal does not even have shift operators, but all compilers support them, so implementations might differ.
I would suggest you try Rust, which has well defined behaviour for all shift cases.
When the shift generates an overflow (https://doc.rust-lang.org/reference/expressions/operator-expr.html), the program by default will panic (abort), unless you explicitly ask the compiler not to care for overflows.
Moreover, shift operation are well defined both for signed and unsigned types, another difference with C where right shifting a negative (signed, of course) integer is implementation defined.
Implementation defined means that the compiler can do what it wants, but it must be documented; as opposed to UB, a program which includes IDB is compliant, though not strictly compliant.
But really, do read the rationale and learn the standard (C11 is nice, C17 does not change much and C2x is still in the making), if you don't want to get caught in the many pitfalls C admittedly has. Coding by expectations is going to bite you.
I highly recommend using static analysis tools when you can.
This.
Cppcheck is good, clang-analyzer (https://clang-analyzer.llvm.org/) is also very good and FOSS, and Ericsson has built a FOSS driver for both to facilitate their use for CI and large projects (with multi file checking) and to store results in a database, called CodeChecker (https://github.com/Ericsson/codechecker).
EtA: I re-checked, and CodeChecker will not run cppcheck (only clang-analyzer and clang-tidy), but is capable to ingest and store cppcheck reports, together with many other formats (https://github.com/Ericsson/codechecker/blob/master/docs/supported_code_analyzers.md)
-
Standard Pascal does not even have shift operators, but all compilers support them, so implementations might differ.
I have used Pascal in the past, but I admit I don't know the standard as well as I know the C standard. Are you sure about not having shift operators? Are shl and shr just compiler extensions?
-
I have used Pascal in the past, but I admit I don't know the standard as well as I know the C standard. Are you sure about not having shift operators? Are shl and shr just compiler extensions?
I have used Pascal (turbo) for my master thesis (a compiler, go figure) more than three decades ago - it had shift operators/keywords AFAICR, but the official standard (1990) does not.
I cannot be sure about the 1991 update, though.
I won't link to the online pdf, as I'm not sure they are legitimate copies, but your favourite search engine will find them if you search for ISO/IEC 7185:1990.
(I have all the official C and C++ standards since C99, but for them the drafts at open-std.org are absolutely OK both from the technical and property rights point of view)
Fortran90 has intrinsic shift functions, but look here (http://micro.ustc.edu.cn/Fortran/Fortran%2090%20Handbook.pdf) (not the actual standard, bold mine):
A.49 ISHFT (I, SHIFT)
Description. Performs a logical shift.
Class. Elemental function.
Arguments.
I must be of type integer.
SHIFT must be of type integer. The absolute value of SHIFT
must be less than or equal to BIT_SIZE (I)
This is exactly what UB is: the standard (manual here) does not say what happens when the constraint is not fulfilled.
The whole UB hullabaloo is because the C standard makes an attempt to warn the reader of some cases of UB (albeit defining others through omission and a general rule).
-
I have used Pascal in the past, but I admit I don't know the standard as well as I know the C standard. Are you sure about not having shift operators? Are shl and shr just compiler extensions?
I have used Pascal (turbo) for my master thesis (a compiler, go figure) more than three decades ago - it had shift operators/keywords AFAICR, but the official standard (1990) does not.
I cannot be sure about the 1991 update, though.
Just got the 1990 std, and you're right. Actually, there doesn't seem to be any bitwise operator at all (there were boolean operators, and "sets", which could more or less be used for the purpose of bitwise operations, but no direct bitwise operation on integers as far as I can tell)? Yes, all of them were in TP and other compilers. But that makes me think of the recent discussion about Pascal vs. C, and then that would definitely be a case "against" Pascal for any moderately low-level software, which wasn't raised in said discussion.
Extended Pascal (ISO 10206, that I could find in Postscript), which was a different standard, added a lot, but most things were already present in existing compilers as extensions in some form. I could not find any specific addition for bitwise operations, though? Looks like it was not a big concern for Pascal, or something.
-
which wasn't raised in said discussion.
I honestly had the idea to raise it, but in the end did not.
The Pascal standard is useless, since when it came out it described a language that was already obsolete and too limited to be really useful: not even separate compilation was considered, relegated to a note about "Many processors provide, as an extension, the directive external".
Nobody cares (and I think ever cared) about standard Pascal - it's a dead, pointless, standard.
This means that the language has been in good measure "implementation defined" for three decades (and before, in fact).
The only certainty is the behaviour of the compiler du jour.
The C89 standard, on the contrary, was forward looking at the time.
It set the course of the language by diverging radically from K&R and making clarity on a lot of dubious (sequence ;)) points, precisely defining the translation phases and the preprocessor, formalizing the modern function declarations etc. etc.
The fact that we still use it as a reference in its more modern revisions and that there's a slow but certain bidirectional osmosis between the standard and the compilers are a testament to its modernity, consistency and usefulness.
PS: C89 came out while I was in my last Uni year, and at the time I thought "That's bad, this will stifle the evolution of the language" How wrong I was.
-
Pascal was a teaching language at universities. I had to do it, in the 1970s. It was useless for doing anything practical, although Delphi was a good tool, before M$ VC++ took over the world of PC software (and multiplied the typical bug count 100x). Pascal was accordingly popular with those of my generation who found it handy to carry on with it.
I think C is a good language but I think anybody who has to rely on standard implementations of undefined behaviour is going to - at best - product illegible code. It is already "mandatory" for programmers to use the absolute minimum of comments, rendering most code unreadable unless a lot of time is wasted first. I comment C almost like I comment asm.
In 1991 I designed a datacomms product which was user-programmable, with a built-in Pascal compiler. It was really quite slick, but only because I added loads of extensions, including bitwise operators. It was Z180 based and the guy who wrote the compiler c. 1975 was still around to help with the integration. It still sells!
-
I think C is a good language but I think anybody who has to rely on standard implementations of undefined behaviour is going to - at best - product illegible code.
The crux with UB is that it's uncharted territory and should remain as such (we can split some hair here, e.g. some HW interfacing etc., but take it as a general principle).
If your code need to be reliable, vaguely portable, and correct, just do not venture there, there is no "standard implementation"* - I'm always baffled by threads you see of people trying to dissect the expected behaviour of i=i++-like stuff.
That kind of statement is outside the realm of C, compiler writers are known to exploit this to improve handling of well defined cases, just live with it.
I did not get the comment about code legibility, especially in relation to UB? That depends a lot on the programmer, style guides and design can only do so much.
*E.g, real story: friend came to me with "gcc in the new Ubuntu is broken" "fat chance, show me your code" "... a[j] = j++...".
-
I think anybody who has to rely on standard implementations of undefined behaviour is going to - at best - product illegible code.
... just don't?
See, all languages have illegal constructs, you are just forbidden to do X.
C goes so far as to spell out clearly: don't do this. But it seems some people love to still do it, and use the magic words "UB" as some kind of excuse of doing it.
But in fact, it's better that forbidden things are explicitly called out, instead of you having to understand that if it's not mentioned, it's not OK to do. This choice also makes C very well-specified, stable and robust language.
There certainly are special cases where we need to use UB. We just need to take care of only doing it when actually needed, constraint the scope (for example, decide that this code is never meant to be ported across different platforms), and document these places. But this is all a tiny special corner case. It should not affect your workflow very much. If it does, it sounds like you are just using UB as an excuse to being lazy, and writing buggy code. And that attitude problem affects code written in any language.
-
But still if a compiler was to optimise x >> 1000, it should set x=0, not leave x unchanged.
In theory, the C compiler should generate a code to produce calculations in run time. It may do the calculation at the compile time, but this would be an optimization. When applying such optimization, the compiler must produce the same result as you would see without the optimization. So, on most processors you should expect x >> 1000 be the same as x >> 8.
However, when you write x >> 1000 it is a bug, because the operation is defined for right size of up to 31. So "x >> 1000" is undefined and therefore a bug, same as "x/0". You just don't do it. If you use it for some sort of special purpose, do it at your own risk.
On the other hand, even when allowed by the specification, the compiler shouldn't turn openly hostile. Compiler is a tool, not a cerberus for the C standard. Imagine, if you pressed a wrong button on a hand drill and it would jump and drill a hole in your eye to punish you for pressing a wrong button. Who would've used such a tool?
-
I think anybody who has to rely on standard implementations of undefined behaviour is going to - at best - product illegible code.
... just don't?
I think it's just hopeless at this point. :-//
-
Pascal was a teaching language at universities. I had to do it, in the 1970s. It was useless for doing anything practical
As we discussed in another thread, this statement is just bullshit.
-
Pascal was a teaching language at universities. I had to do it, in the 1970s. It was useless for doing anything practical
As we discussed in another thread, this statement is just bullshit.
I tend to agree with peter-h here. When you try to write real applications with Pascal you quickly run into problems because the structure is too rigid. Borland has tried hard to work around that by adding all kinds of C-isms but that ended up being a hot mess with 2 programming languages mashed together. Been there, done that and won't do it again.
-
I used Turbo Pascal quite intensively for a lot of real applications with graphical UIs. I actually made first money making software in Pascal. It was fine and did not feel bad at all. Programming graphics in DOS 100% felt better than programming modern graphics.
But I did not care (and still don't) that there is a standard. To me Turbo Pascal was the standard. Same with C - I rely on GCC behaviour and extensions and don't care if something does not work in some obscure proprietary compiler. It is not may problem at all.
-
Borland has tried hard to work around that by adding all kinds of C-isms but that ended up being a hot mess with 2 programming languages mashed together. Been there, done that and won't do it again.
I think it worked great. You could do most of the things you can do in C, but Pascal is more verbose. If you didn't use Pascal strings and alike, it was actually very close to C. Borland's Delphi had very fast and efficient compiler which produced very decent code. Delphi had very buggy and bloated libraries, but you were not obligated to use them. Later on the IDE became buggy as well. But at any rate Borland's Pascal was miles better than more canonical Think Pascal.
-
Someone else had fun here:
https://community.st.com/s/question/0D53W00001PudP1SAJ/issue-with-version-190
One person wrote, "My workaround is: uninstall CubeID 1.9, reinstall Version 1.8.0 and pull the Projects out of the backup - i LUCKILY made before upgrading to 1.9."
Another "engineer" not using revision control in 2022. Sheesh.
-
I did not get the comment about code legibility, especially in relation to UB? That depends a lot on the programmer, style guides and design can only do so much.
re: undefined behavior. To me this means "anything can happy." Maybe that shift will open up a black hole under Putin's feet, saving the world? Maybe it caused that bagel with lox I had on Friday to give me food poisoning? Which one of you guys gave me food poisoning?
*E.g, real story: friend came to me with "gcc in the new Ubuntu is broken" "fat chance, show me your code" "... a[j] = j++...".
This calls for an armed response.
-
...
One person wrote, "My workaround is: uninstall CubeID 1.9, reinstall Version 1.8.0 and pull the Projects out of the backup - i LUCKILY made before upgrading to 1.9."
Another "engineer" not using revision control in 2022. Sheesh.
Revision control plus Virtual Machines with known working configuration of toolset (e.g. IDE's and libraries).
And since this a rather big hassle - never change a running system.
My group is still running CubeIDE 1.3.1, because it seems to work for all the dozen or so different STM32's that we have in active production / support.
The Virtual Machine approach is also useful for checking out different toolsets. Or all kinds of experiments that might foul up your setup.
-
Indeed; I have been running Cube in a win7-64 VM also, for various reasons. The one thing however which can be a challenge is connecting to a debugger. I vaguely recall that in Cube / Project properties / Debug you need to check the "shared debugger" checkbox, though it is not clear why. And of course you need to "archive" the debugger also :)
VMs tend to be troublesome in general when it comes to connecting to physical peripherals, although simple USB should work. What you probably can't do is use Cube with a debugger on the base machine, and use Cube in a VM with another debugger.
-
Just stumbled across some code-generation quirk and wanted to "unload" my fury somewhere...
The $%§$%§$%§$ morons at ST make code generators featuring a crapy-as-hell HAL and guess what?, they don't even get clock gating right.
DMA for the ADC doesn't work on the up-to-date dev-tools because DMA init comes after ADC init.
So all the DMA stuff in the ADC init doesn't work because the clock to the DMA is not enabled (seems to make a difference on STM32F303).
Perfect!
I just searched around for 4 hours, because I expected the most trivial thing would be generated correctly....
That's a selling feature and it does not work out-of-the-box!
Seriously, just use the GD32 stuff with vanilla eclipse with the embedded tools!
That's around 15min of work to take a STM32 template and implant the GD32 stuff.
They have decent (up-to-date) samples with their firmware-package and the docs are ok (you get used to the slightly odd wording quickly).
As a bonus, their stuff is cheaper, has better availability (to me at least) and they document quirky stuff if there is one.
15year back, I did not use a Nxp stuff because their dev-tool-package was garbage in a 500k/year product.
Now, I'll phase out ST ...
73
-
I used Turbo Pascal quite intensively for a lot of real applications with graphical UIs. I actually made first money making software in Pascal. It was fine and did not feel bad at all. Programming graphics in DOS 100% felt better than programming modern graphics.
But I did not care (and still don't) that there is a standard. To me Turbo Pascal was the standard. Same with C - I rely on GCC behaviour and extensions and don't care if something does not work in some obscure proprietary compiler. It is not may problem at all.
I also used Turbo Pascal back in the day. The feeling of getting graphical applications running on a text-based DOS was quite the achievement (the famous EGAVGA.BGI), and it provided me with a foundation that I carry to this day.
-
Cube 1.9.0 appears to now detect if a source file has been externally edited i.e. it has a later timestamp.
I am pretty sure this didn't work previously; after any external editing, or dropping in of files from elsewhere, you had to Project/Clean and Project/Build.
-
Oh boy I do hope that Somebody Else^tm would do a really good tutorial series on simple bare-metal development. Not for me, but for the beginners, like I once was, too. For the common good.
https://vivonomicon.com/ is a pretty descent write up.
-
Oh boy I do hope that Somebody Else^tm would do a really good tutorial series on simple bare-metal development. Not for me, but for the beginners, like I once was, too. For the common good.
https://vivonomicon.com/ is a pretty descent write up.
If only I could find the index on that awful site layout so that I can start from the beginning.
-
If only I could find the index on that awful site layout so that I can start from the beginning.
https://vivonomicon.com/2018/04/02/bare-metal-stm32-programming-part-1-hello-arm/
https://vivonomicon.com/2018/04/20/bare-metal-stm32-programming-part-2-making-it-to-main/
https://vivonomicon.com/2018/04/22/bare-metal-stm32-programming-part-3-leds-and-buttons/
https://vivonomicon.com/2018/04/25/bare-metal-stm32-programming-part-3-5-supporting-multiple-chips/
https://vivonomicon.com/2018/04/28/bare-metal-stm32-programming-part-4-intro-to-hardware-interrupts/
https://vivonomicon.com/2018/05/20/bare-metal-stm32-programming-part-5-timer-peripherals-and-the-system-clock/
https://vivonomicon.com/2018/08/23/bare-metal-stm32-programming-part-6-multitasking-with-freertos/
https://vivonomicon.com/2018/09/05/bare-metal-stm32-programming-part-7-embedded-c-inheritance/
https://vivonomicon.com/2018/12/28/bare-metal-stm32-programming-part-8-learn-to-debug-timing-issues-with-neopixels/
https://vivonomicon.com/2019/07/05/bare-metal-stm32-programming-part-9-dma-megamix/
https://vivonomicon.com/2020/06/28/bare-metal-stm32-programming-part-10-uart-communication/
https://vivonomicon.com/2020/07/26/bare-metal-stm32-programming-part-11-using-external-memories/
https://vivonomicon.com/2020/08/08/bare-metal-stm32-programming-part-12-using-quad-spi-flash-memory/
https://vivonomicon.com/2020/09/10/bare-metal-stm32-programming-part-13-running-temporary-ram-programs-and-using-tightly-coupled-memories/
Also some Github repos with example bare metal projects:
https://github.com/ataradov/mcu-starter-projects - quite extensive list
https://github.com/trebisky/stm32f103 - stmf103 only
https://github.com/fcayci/stm32f1-bare-metal - stmf1 only
https://github.com/WRansohoff/STM32F0_minimal_C
https://github.com/WRansohoff/GD32VF103_templates
https://github.com/WRansohoff/cortex-m-rt - minimal startup for cortex-m micros
https://github.com/WRansohoff/ESP32_minimal
https://github.com/WRansohoff/STM32_UART_Examples
https://github.com/WRansohoff/STM32_quickstart
https://github.com/WRansohoff/min_freertos_blink
https://github.com/cpq/mdk - bare metal esp32 / esp32c3 SDK
https://github.com/cesanta/mongoose/tree/master/examples/stm32/nucleo-f746zg-baremetal - bare metal stm32f7 ethernet http server
-
https://github.com/ataradov/mcu-starter-projects (https://github.com/ataradov/mcu-starter-projects) - quite extensive list
FYI: He is a large contributor on this forum ;)
https://www.eevblog.com/forum/profile/?u=26419 (https://www.eevblog.com/forum/profile/?u=26419)
-
FYI: He is a large contributor on this forum ;)
https://www.eevblog.com/forum/profile/?u=26419 (https://www.eevblog.com/forum/profile/?u=26419)
Well, kudos to Alex. There is a large deal that could be learnt from https://github.com/ataradov/mcu-starter-projects (https://github.com/ataradov/mcu-starter-projects) .
-
I do hope that Somebody Else^tm would do a really good tutorial series on simple bare-metal development. Not for me, but for the beginners, like I once was, too.
I somewhat like the tutorials and info from "EmbeddedExpertIO" (https://embeddedexpert.io/) Such as: https://www.youtube.com/watch?v=4AkKSBhYEW4 (https://www.youtube.com/watch?v=4AkKSBhYEW4)
They seem to be primarily a training company, so if you provide your email to get one of their "free" guides, you'll also get periodic (but not too frequent) ads for classes. The free documents I've downloaded and looked at are nicely concise, cover a log of "bare metal" examples, and have especially nice references from each line of code to the STM datasheets...
-
https://github.com/ataradov/mcu-starter-projects (https://github.com/ataradov/mcu-starter-projects) - quite extensive list
FYI: He is a large contributor on this forum ;)
https://www.eevblog.com/forum/profile/?u=26419 (https://www.eevblog.com/forum/profile/?u=26419)
Ah, right, that is a separate website from the one in his profile.
-
I've just spent some hours trying to find out why code which compiled last night doesn't compile today.
Nothing was touched - also not touched according to file date stamps (as seen in windows explorer).
But I appreciate that if you leave any editor on-screen with a file open, a slip of the finger on a keyboard can "do stuff". But this should not change a file if you don't then save it.
I just tried this in VS code (compiling 3D printer firmware). I changed one single digit in a number in a comment. The date of the file on disk didn't change because the file wasn't saved. But when I compiled it, the system saved the file at that time. So even if you changed something and don't save it, it will be saved right at the time you compile it. Maybe your IDE is doing that.
-
Yes as far as I am aware both microshit IDE's do this, how many times have you been asked to save your files before exiting? me hardly ever as they were saved in the last build and I usually close the IDE after a build.
-
Normally there're options for that, ex. in eclipse it's "Save files before building" or something similar.
-
Cube IDE is on V10 now
https://www.st.com/resource/en/release_note/dm00603738-stm32cubeide-release-v1-3-0-stmicroelectronics.pdf (https://www.st.com/resource/en/release_note/dm00603738-stm32cubeide-release-v1-3-0-stmicroelectronics.pdf)
Can anyone tell if the GCC version has changed again?
EDIT: probably not since v10, running in a win7-64 VM, produces an identical binary to Cube v1.9.
-
v 1.10.1 has just come out. Some bug fixes to do with file corruption in MX.
What I have been finding repeatedly over the last ~2 years is that when running under debug (compilation with F11) the system always breaks at some point, generally after some hours. This is with STLINK V2 or V3 debuggers, ISOL or not ISOL. PC comms with the debugger are lost. The problem is that this also kills the target.
It isn't a problem with normal breakpoint debugging but you can't have a target running for days looking for a breakpoint to get hit, because it will crash before then.
Can anyone reproduce this?
-
v 1.10.1 has just come out. Some bug fixes to do with file corruption in MX.
What I have been finding repeatedly over the last ~2 years is that when running under debug (compilation with F11) the system always breaks at some point, generally after some hours. This is with STLINK V2 or V3 debuggers, ISOL or not ISOL. PC comms with the debugger are lost. The problem is that this also kills the target.
It isn't a problem with normal breakpoint debugging but you can't have a target running for days looking for a breakpoint to get hit, because it will crash before then.
Can anyone reproduce this?
Running for days ....... I do not think it was ever intended for these kind of extreme long periods of time.
I would suggest for these kinds of things to write a monitor thread yourself and on the event, dump the entire stack tracing and all variables with it to an external file. Serious, even with a Keil pro of €1000+ I was glad if it would run for an hour consecutively without something breaking it up.
-
Thanks :)
I did have a dig around for ways of making the debug stack analysis longer. Often, on a proper crash, you see just 3 entries there and all of them are the CPU obviously executing garbage. Googling around suggests there is no way to make this longer. Your suggestion would solve that, and then one just needs a prog which identifies the stack trace addresses by reference to the symbol table, perhaps the .map file.
I also noticed 1.10.x updates the STLINK firmware.
-
Running for days ....... I do not think it was ever intended for these kind of extreme long periods of time.
I use Rowley CrossWorks for ARM (and Segger's licensed version: Embedded Studio) for STM32 debugging and it will run for very long periods without losing connection with the target. I have one STM32H743 board on my desk that's been running for 4-1/2 months now under CrossWorks connected to the PC with a J-Link.
-
So your pc does not go to sleep after an idle period? No system updates? Your pc is running 4.5 months continuously in debug mode ? Special cabling/shielding ?
Well congratulations you must have a record there.
I once had a debug session abort after a colleague switched just an ac load 4 meters away from my desk. Probably emc related.
So I still would not recommend to rely on it for such prolonged periods esp. if you are for instance hunting for memory leaks that occur once a month or so. Pretty expensive if the test aborts after three weeks and you still have no data. But if it works for you perhaps you can help TS for a robust setup.
-
So your pc does not go to sleep after an idle period? No system updates? Your pc is running 4.5 months continuously in debug mode ? Special cabling/shielding ?
Well congratulations you must have a record there.
From my experience with JTAG I'd say that a stable debugging environment starts with having a JTAG connection which is rock solid. A piece of flat cable or (worse) flying leads won't do. An on-board JTAG connection is better but you'll also need proper grounding of the target and the PC to avoid USB related problems. Likely an ethernet based JTAG interface will be less prone to problems related to connection between the computer and the JTAG interface.
-
So your pc does not go to sleep after an idle period? No system updates? Your pc is running 4.5 months continuously in debug mode ? Special cabling/shielding ?
Well congratulations you must have a record there.
I once had a debug session abort after a colleague switched just an ac load 4 meters away from my desk. Probably emc related.
So I still would not recommend to rely on it for such prolonged periods esp. if you are for instance hunting for memory leaks that occur once a month or so. Pretty expensive if the test aborts after three weeks and you still have no data. But if it works for you perhaps you can help TS for a robust setup.
Hey, that's nothing! Uptime on one of my web servers:
ubuntu@qwerty:~$ uptime
00:02:59 up 1260 days, 2:35, 1 user, load average: 0.07, 0.02, 0.00
-
From my experience with JTAG
It is probably only SWD but I think of something that might explain the different experiences.
You can change the SWD frequency from a couple of kHz to what is it 4MHz ?
It probably makes a world of difference which debug frequencies were used, and this might also be the reason they have a max frequency defined.
-
Hey, that's nothing! Uptime on one of my web servers:
Yeah completely different topic, Topper ;)
-
It is an interesting point whether dropping the SWD frequency a long way might help with all this. See here for example
https://www.eevblog.com/forum/microcontrollers/10-pin-debug-connector-and-stlink-v3-isol-not-reliable/msg3564782/#msg3564782 (https://www.eevblog.com/forum/microcontrollers/10-pin-debug-connector-and-stlink-v3-isol-not-reliable/msg3564782/#msg3564782)
I noticed Cube v10 starts up the debugger differently. If it can't get comms, it drops to a slower clock: 8MHz. Previous Cube versions just bombed out.
It would be unsurprising if the debugger communicated with the target continuously during running. I just don't know and haven't bothered to scope it. If it does, then a slower SWD clock should help.
-
So your pc does not go to sleep after an idle period? No system updates? Your pc is running 4.5 months continuously in debug mode ? Special cabling/shielding ?
Well congratulations you must have a record there.
I once had a debug session abort after a colleague switched just an ac load 4 meters away from my desk. Probably emc related.
So I still would not recommend to rely on it for such prolonged periods esp. if you are for instance hunting for memory leaks that occur once a month or so. Pretty expensive if the test aborts after three weeks and you still have no data. But if it works for you perhaps you can help TS for a robust setup.
Hey, that's nothing! Uptime on one of my web servers:
ubuntu@qwerty:~$ uptime
00:02:59 up 1260 days, 2:35, 1 user, load average: 0.07, 0.02, 0.00
Indeed. Run the IDE on a decent OS and you will get great uptime as well. I've had TI's Code Composer Studio running debug sessions and automated tests on a Linux box continuously for days and weeks with no glitches. And it was not a very powerful one, just a midrange machine.
Windows as a development environment is not the most suitable for the task, especially with the newer releases 10/11 that constantly harass you with updates. Unfortunately this is the OS that we need to deal most of the time due to other necessities, though.
-
Of course, a unix machine can have an uptime of years. I "run" several CENTOS 7/8 servers, Apache/NGINX, which haven't been touched for probably 5 years.
But that's hardly applicable to
- Cube (hacked in Java!!!)
- USB attached debugger (USB goes to sleep periodically, under Windoze)
- connection to the target (sometimes needs exit from Cube, sometimes Windows Task Manager and kill the ST processes)
- target power supply
- etc
On win7-64 (machines I built myself) I see uptime of several months, with a reboot necessary only in unusual situations e.g. some rogue USB device trashed something. And I run all sorts on these machines; VMWARE VMs, many apps...
-
From my experience with JTAG
It is probably only SWD but I think of something that might explain the different experiences.
You can change the SWD frequency from a couple of kHz to what is it 4MHz ?
It probably makes a world of difference which debug frequencies were used, and this might also be the reason they have a max frequency defined.
AFAIK both JTAG and SWD use synchronous (clocked) data transfer. A single spike on the clock line screws everything up no matter what the working frequency is.
-
So your pc does not go to sleep after an idle period? No system updates? Your pc is running 4.5 months continuously in debug mode ? Special cabling/shielding ?
Well congratulations you must have a record there.
I once had a debug session abort after a colleague switched just an ac load 4 meters away from my desk. Probably emc related.
So I still would not recommend to rely on it for such prolonged periods esp. if you are for instance hunting for memory leaks that occur once a month or so. Pretty expensive if the test aborts after three weeks and you still have no data. But if it works for you perhaps you can help TS for a robust setup.
Hey, that's nothing! Uptime on one of my web servers:
ubuntu@qwerty:~$ uptime
00:02:59 up 1260 days, 2:35, 1 user, load average: 0.07, 0.02, 0.00
Indeed. Run the IDE on a decent OS and you will get great uptime as well. I've had TI's Code Composer Studio running debug sessions and automated tests on a Linux box continuously for days and weeks with no glitches. And it was not a very powerful one, just a midrange machine.
Windows as a development environment is not the most suitable for the task, especially with the newer releases 10/11 that constantly harass you with updates. Unfortunately this is the OS that we need to deal most of the time due to other necessities, though.
The 4-1/2 months I mentioned was on a Windows machine. The application running on the STM32 board was continuously sending serial data to the PC over a virtual serial port implemented by the J-Link.
-
AFAIK both JTAG and SWD use synchronous (clocked) data transfer. A single spike on the clock line screws everything up no matter what the working frequency is.
JTAG has the TMS line which can be used to walk the controller to a known state. So, clock spikes are not the end of the world.
-
And SWD has a parity bit and a line reset, so synchronization recovery is possible as long as the software is prepared to detect an error.
-
AFAIK both JTAG and SWD use synchronous (clocked) data transfer. A single spike on the clock line screws everything up no matter what the working frequency is.
JTAG has the TMS line which can be used to walk the controller to a known state. So, clock spikes are not the end of the world.
Indeed. Clock recovery is not an uncommon feature of decent JTAG probes. One of the major issues I have seen are PC power down states that can trigger issues with external peripherals.
-
AFAIK both JTAG and SWD use synchronous (clocked) data transfer. A single spike on the clock line screws everything up no matter what the working frequency is.
JTAG has the TMS line which can be used to walk the controller to a known state. So, clock spikes are not the end of the world.
But how do you know whether data got clocked in correctly? It is not about recovering the JTAG controller to a know state, but being sure that what you are transmitting is correct AND then being able to recover. The latter isn't trivial (to say the least) when you are feeding a CPU instructions to access the memory. An extra (or missing) clock means you are suddenly clocking in a different instruction or address.
-
AFAIK both JTAG and SWD use synchronous (clocked) data transfer. A single spike on the clock line screws everything up no matter what the working frequency is.
JTAG has the TMS line which can be used to walk the controller to a known state. So, clock spikes are not the end of the world.
But how do you know whether data got clocked in correctly? It is not about recovering the JTAG controller to a know state, but being sure that what you are transmitting is correct AND then being able to recover. The latter isn't trivial (to say the least) when you are feeding a CPU instructions to access the memory. An extra (or missing) clock means you are suddenly clocking in a different instruction or address.
No. You recover the JTAG controller state before the transfer. There may be errors during transfer (clock or data error), but the errors do not linger after the transfer because for the next transfer you start by resetting the controller to a known state.
Are you trying to say that clocked transfers are inherently error prone while asynchronous transfers are error free?
-
Once you have clocked in the wrong address or instruction into a CPU, recovery will be hard to do. Again, the JTAG interface is a paper thin access layer on top of a way more complex debugging interface. JTAG is nothing more than 2 simple shift registers which have next to no functionality in them. All the actual intelligence & complexity that is hard to recover errors from sits below JTAG. In the past I have done some work on MIPS support for OpenOCD and that doesn't have any way for recovery once things go wrong. Where it comes to MIPS you are basically feeding instructions into the CPU one by one into some kind of a virtual memory area.
Asynchronous interfaces have better resilience against spikes (look at a UART for example) but that doesn't mean it is suitable for remote debugging perse.
Where it comes to rock solid remote debugging over JTAG or SWD it comes down to getting the signal integrity right before anything else.
-
JTAG is nothing more than 2 simple shift registers which have next to no functionality in them.
It's much more than that. JTAG is a formal state machine which transitions between states as commanded by the TMS line. It lets you reset the controller, feed commands and exchange data. The implementation will usually implement many shift registers. For example, in FPGA, some of the shift registers are implemented by hardware and can be used to configure FPGA, others may be implemented in fabric to do whatever you want - program onboard flash, get data from FPGA etc. JTAG provides mechanisms to coordinate the access to all these shift registers across multiple devices connected in a chain.
All the actual intelligence & complexity that is hard to recover errors from sits below JTAG.
Which has nothing to do with JTAG being a synchronous interface.
Where it comes to MIPS you are basically feeding instructions into the CPU one by one into some kind of a virtual memory area.
You missed all the fun with MIPS. Their debugger maps a memory area to the JTAG probe. Any reads/writes to this memory area are re-directed to the probe and the probe is responsible for supplying/consuming the data. You certainly can execute commands in this area and this way you'll have to furnish all the instructions through JTAG. This is rather dumb way of doing things though because the probe is slow and (as you have already noticed) doesn't have good recovery mechanisms.
Decent MIPS debuggers implant a resident program into the chip memory and execute from there. The JTAG-mapped area doesn't execute commands at all. Instead this area is used to exchange data with JTAG probe. This is much faster, and provides opportunity to add reliability checks if you wish.
This certainly has nothing to do with clocked protocols. The low reliability you've got with MIPS is simply a consequence of a bad design.
Where it comes to rock solid remote debugging over JTAG or SWD it comes down to getting the signal integrity right before anything else.
Sure. And with good enough SI, clocked interfaces are extremely reliable - just look at all these servers running DDR memory at very high loads and crazy speeds for years without encountering a single error.
-
Cube v10 crashes a lot more often, and needs Windows Task Manager to shut it down.
-
Someone may find this amusing.
I have a 32F417VGT6 project. The RAM goes 0x20000000 to 0x2001ffff. 1MB FLASH. A couple of boards were built with a 32F437VGT7 which is almost 100% identical but has an extra 64k RAM, so that goes 0x20000000 to 0x2002ffff. Actually I think the 32F437VGT7 has 2MB FLASH while a 32F437VGT6 would be 1MB but it is very hard to establish the part numbers (nothing in the data sheet).
It was not realised two of the boards were the 437 and indeed they run the same. In fact, speaking to one expert, the only known other difference in terms of backwards compatibility at the binary level is something around the way Vbat is measured with one of the internal ADCs.
But Cube does some funny stuff. With the 417, viewing memory (target stopped, obviously) around the top of RAM shows this
(https://peter-ftp.co.uk/screenshots/20220723514665806.jpg)
which is correct; the real physical end of memory is 0x2001ffff. I have an 8k stack at the top of memory, hence the values seen below 0x20020000. But on the 437, whose RAM continues past this, I see this data after 0x2001ffff
(https://peter-ftp.co.uk/screenshots/202207233413985106.jpg)
and I have no idea where this comes from. A watchpoint in there is never triggered, and no code of mine should be using that extra 64k. I recognise the data; it also appears lower down (it is stuff from MbedTLS) so this is a kind of mirroring thing. If I edit some of those values (say at 0x20020050) to say 0 and restart the system, they stay at zero until the very last instruction of the startupxxxx.s file and then as soon as I step (asm instruction step mode) into main.c those locations change to the values shown above. No interrupts, DMA, etc is running at this point.
I reckon Cube is just imagining data there because the CPU ID which it gets via the debugger is not the CPU type which has been configured in it.
It is possible for data in that memory to persist for ages since nothing is accessing it, but equally nothing should be writing in there.
-
(nothing in the data sheet)
What is missing in the DS?
Chapter 8 gives you the ordering info, with the different codes for various packagings and flash size, table 2 clearly shows that RAM size is the same across the 437 family.
https://www.st.com/resource/en/datasheet/stm32f437vg.pdf (https://www.st.com/resource/en/datasheet/stm32f437vg.pdf)
A 2 MB part would be VI, not VG, 6 and 7 indicate the temperature range.
-
OK; I could not find the 6 v 7 meaning. The 437 can have 1MB or 2MB FLASH. I guess mine must be 1MB.
Anyway, that RAM display is curious. I should probably write some code and try reading the RAM with some asm or C. But if the data is really there (I am sure it isn't) how did it get there? That would be a massive bug.
-
Actually I think the 32F437VGT7 has 2MB FLASH while a 32F437VGT6 would be 1MB but it is very hard to establish the part numbers (nothing in the data sheet)
How can you miss this very basic info? Section 8 "Part numbering" of the DS could not be more clear.
Flash memory size
G = 1024 Kbytes of Flash memory
I = 2048 Kbytes of Flash memory
32F437VGT7 is (V = 100 pins) (G = 1024 Kbytes) (T = LQFP) (7 = Industrial temperature range, –40 to 105 °C.)
2MB version would be 32F437VIT7
-
If somebody wants to run their application on two different MCUs, there should be two different Cube projects. The application part can be used for both of them but the system part implemented by Cube will be different. It may be tempting to save the work and try using the same Cube project for different MCUs, yet it's an error and results are not guaranteed, even for somewhat similar MCUs. Those devices are complex.
Regards, Dieter
-
If somebody wants to run their application on two different MCUs, there should be two different Cube projects. The application part can be used for both of them but the system part implemented by Cube will be different.
That's rather awful, especially if there's no way to clearly delineate the application and the "system part."For instance, I maintain an AVR bootloader (Optiboot) that can be compiled for literally dozens of different chips without being overly cluttered with per-chip dependencies. (It uses manually created source and Makefile(s); this sort of multi-target solution doesn't fit well into other IDEs (like "Atmel Studio" or "MPLabX"), either.
-
There is a legitimate case for being able to buy a 32F437 (because you can't get the 32F417, for example) and just drop it in in production.
And this works (the only known diff is around Vbat monitoring using the ADC).
What I am saying is that Cube might do some funny stuff - evidently it uses the CPU ID (which it reads back via SWD) and if this doesn't match the Cube project settings, it breaks something, at least in the memory display.
That said, it took me a year to notice the CPU markings ;) so within the 32F417 memory ranges, Cube works on a 32F437 ok. It's just that if you do something like a power-up RAM test, and then use that to size your heap size, etc, that will work, but you will have some fun doing debugging on the extra memory.
-
If somebody wants to run their application on two different MCUs, there should be two different Cube projects. The application part can be used for both of them but the system part implemented by Cube will be different.
That's rather awful, especially if there's no way to clearly delineate the application and the "system part."For instance, I maintain an AVR bootloader (Optiboot) that can be compiled for literally dozens of different chips without being overly cluttered with per-chip dependencies. (It uses manually created source and Makefile(s); this sort of multi-target solution doesn't fit well into other IDEs (like "Atmel Studio" or "MPLabX"), either.
I don't use the ST Cube IDE, due to its Eclipse descent, but I use sometimes the ST Cube MX (i.e. the stand alone code generator).
There is a way to migrate a project to a different MCU keeping the user code (the one between the /* USER CODE START nnn */ comments) - it works resonably well if you move in the same family, I changed from a STM32F072 to a STM32F042 with no issue, and IIRC provides a good amount of helpful diagnostics.
So, yes: different MCUs need separate projects.
-
One bizzare behaviour is how you can place a breakpoint on a line of code, and the code gets removed because the compiler decided that it is unreferenced or unreachable, and very funny things happen.
It can take quite a while to spot this.
Could it have been programmatically detected?
-
What funny things?
The correspondence of the source code and assembly becomes obvious after compilation is done and the final binary with the debug information is available. Often IDEs don't parse the binary until debug session is started. And when it is started and the line is not available in the code, I've seen seen different behaviour - just mark the breakpoint as disabled, move to the next available line.
Usually breakpoints are treated in two separate ways - one is the desired set and another one is the actually possible set. There are many ways setting a breakpoint can fail. One of them is the code optimization. But there may also be not enough hardware breakpoint comparator, or your function may be located in SRAM. So, debuggers typically just treat your set breakpoints as a best desired set, and check what can be done in practice once the debug session is started.
-
That sounds about right :)
The best one recently was setting a breakpoint on an ISR callback. The ISR should have never been called but I had a suspicion it was because the interrupts were left enabled. Old code done 2-3 years ago, not by me. The breakpoint was never taken (in days) but the reason was that the ISR itself didn't exist (because no vector table entry pointed at it anymore) so got optimised away, so the callback got optimised away, but the breakpoint was shown perfectly :)
-
Don't rely on the IDE. I don't know how many times you need to run into issues until you figure it out. Set breakpoints in disassembly where you control where it is set and can notice that some code is missing.
-
This would require close coupling of the compiler and the IDE at the very least. And working on individual functions would require some sort of a way to tell the compiler what to do on a per-function basis.
It is possible to do, of course, but time investment probably not worth it.
godbolt-like view should not be too hard to implement and may be a good starting point. And probably the limit of what is actually useful in a day to day life.
And yes, disassembly view in most IDEs ranges from completely hopeless to somewhat usable at best. I have not seen one that I could point as standing out from the rest.
-
Set breakpoints in disassembly where you control where it is set and can notice that some code is missing.
That would avoid the issue but clearly this is not meant to be a requirement. It is a bit like telling somebody to never change directly from 3rd gear to 5th gear because the engine might blow up ;)
It is stupid software, to fail to detect that there is no code at that address. But clearly the IDE source code display has no idea that the displayed source has no relation to what was actually left, after optimisation.
A good Q might be whether using -O0 (no optimisation) stops removal of unreachable code.
-
It is stupid software, to fail to detect that there is no code at that address.
If IDE would only allow to set the breakpoints on reachable code, then you won't be able top set a breakpoint until you recompile everything. And if you make a temporary change that eliminates some code, your breakpoints would be gone.
Also, debug information is not perfect, and the breakpoint may still not work, even if the code is technically there. You may not like it, but using assembly is unavoidable in some cases.
A good Q might be whether using -O0 (no optimisation) stops removal of unreachable code.
Not guaranteed, depends on the compiler and other settings. There is no guarantee that a line of code would correspond to anything.
-
Hint: CubeIDE projects remember breakpoints. A project may contain breakpoints that have no longer any representation in code. In the "Run"-menu you will find "Remove all Breakpoints" to get a clean slate.
-
This is interesting stuff.
The other stupid behaviour is that if say you have some source
line1
line2
line3
line4
line5 - breakpoint here
and you insert a line before line2, the breakpoint moves to line4 :) It stays in the same line # in the source file.
-
Not sure if I've posted this before.
https://www.eevblog.com/forum/programming/best-thread-safe-printf-and-why-does-printf-need-the-heap-for-f-etc/ (https://www.eevblog.com/forum/programming/best-thread-safe-printf-and-why-does-printf-need-the-heap-for-f-etc/)
and
https://www.eevblog.com/forum/microcontrollers/32f4-hard-fault-trap-how-to-track-this-down/ (https://www.eevblog.com/forum/microcontrollers/32f4-hard-fault-trap-how-to-track-this-down/)
Quite relevant to ST Cube users. The standard C library libc.a is a load of crap. It is not thread safe so it uses mutexes to protect itself. It also uses the heap (for long and float output) and uses more (recursive) mutexes to protect malloc and free. But ... wait for it ... the mutex calls are empty stubs.
So your project will crash every once in a while :)
I discovered this by accident when tracing the asm code (no source is supplied).
It looks like sscanf (in the same lib) is not as bad; I see no heap calls and no mutex references in the disassembly, and no breakpoint hits on _sbrk so it isn't doing a normal malloc(). And I am doing some %f parsing.
-
Quite relevant to ST Cube users. The standard C library libc.a is a load of crap.
Does the ST package not use newlib (like nearly everyone else) ?
-
It does. peter-h just likes to call things that don't absolutely perfectly fit his use case crap.
-
Quite relevant to ST Cube users. The standard C library libc.a is a load of crap.
Does the ST package not use newlib (like nearly everyone else) ?
IIRC, it allows to choose from newlib and newlib-nano, at least.
NXP also include their "redlib".
I generally use picolibc (https://github.com/picolibc/picolibc) though.
-
That personal attack is BS and not necessary. If you think sending out an IDE with this hacked garbage
https://www.eevblog.com/forum/programming/best-thread-safe-printf-and-why-does-printf-need-the-heap-for-f-etc/ (https://www.eevblog.com/forum/programming/best-thread-safe-printf-and-why-does-printf-need-the-heap-for-f-etc/)
is acceptable then you need to get a life.
Cube seems to come with a newlib libc.a but no sources. So anyone using an RTOS (which ST do a port of too) is in for a whole load of fun and games. It crashes only once every few days, which is ok.
-
NewLib source are available. But you don't need the sources to use the binary library. IThe mutex functions are dummy stubs, but they are usually weakly linked. If you define your own implementation, it would be used instead. This is how it is supposed to be used.
None of that is crashes if you know how to use it properly. All those components are used in the industry without any issues.
-
but they are usually weakly linked.
They are not, but if you didn't read what I posted you won't know.
I did solve it eventually, and posted the details to help others.
NewLib source are available.
Perhaps you could be helpful and point me to these? If you read my posts you would know that someone did locate a likely source for the ST Cube printf family (an ex BSD unix 1990 job with some C99 stuff) but nobody has yet found the scanf family, which I was interested in to see if it uses the heap (which the printf does for longs and floats, according to disassembly).
None of that is crashes if you know how to use it properly
Not everybody was born knowing everything. I had to learn what I know. Takes time...
it allows to choose from newlib and newlib-nano, at least.
Not in an obvious way. I posted the screenshots. But to save you looking it up (which few want to do, while being quick to criticise), for example selecting this
(https://peter-ftp.co.uk/screenshots/202208162915372310.jpg)
gives you the "1990 ex BSD" newlib regardless of whether those checkboxes are checked...
-
nobody has yet found the scanf family
Isn't that in the same place at https://sourceware.org/git/?p=newlib-cygwin.git;a=tree;f=newlib/libc/stdio;h=0f5e4dd0dc465029d0b6c0a5d03fc2cc70e8df87;hb=HEAD
-
Thanks very much!
Bad news... malloc in here
https://sourceware.org/git/?p=newlib-cygwin.git;a=blob;f=newlib/libc/stdio/vfscanf.c;h=cfeea987628b1bc5d78a5a7109ae2a47f31f3b89;hb=HEAD
Funny I didn't see that when debugging. Maybe a compile option, or maybe only with a specific scanf format.
-
Maybe a compile option
AFAIK, newlib has many compile options, as well as the assorted stubs that need to be set up correctly for a particular environment. Perhaps many of your troubles are caused by using a newlib that has not been properly configured for your particular setup.
Maybe start here: https://hackaday.com/2021/07/19/the-newlib-embedded-c-standard-library-and-how-to-use-it/
-
Not in an obvious way
Of course.
It is, after all, Eclipse.
A huge mound of user-hostile elephant dung which 2022 still has problems with a dark theme |O.
I went to the trouble of installing the monster in a Windows sandbox, but it'll be gone after this post.
Those two check boxes will only have effect if you select the "Reduced" library - i.e. newlib-nano, as per the attached screenshot.
-
Perhaps many of your troubles are caused by using a newlib that has not been properly configured for your particular setup.
For sure, but ST didn't supply the sources or any build data. What you get when you install Cube is a separate directory c:\st\all-kinds-of-stuff and in there are about 20 different libc.a versions which they precompiled. I spent many hours working out which one of these is selected for my project. Much of it was by elimination (some were for arm32 chips with DSP instructions, etc) and eventually I found the one file which was "standard C, no nano". You can tell if you have nano because int64 etc is not supported, also a sscanf can't read into a uint64_t (which I am doing). Then, as I posted on another thread, I made a permanent local copy of it, ran objcopy to weaken the entire lib, then I replaced the printf family with another one.
So far I see no evidence that malloc is getting called by the scanf family, but perhaps somebody with super C expertise can suggest which % formats might trigger that.
The modern thread-safe design is to use stack storage. If one uses statics one must have mutex calls within the code. These were originally empty stubs. If one uses the heap one must also have mutex calls to protect the heap, but these could be outside (around malloc and free). I have since secured the heap functions with mutexes, so the sscanf should be basically thread-safe even if it does use the heap, but (if calling sscanf from more than 1 RTOS task) one still gets fragmentation which will eventually crash the product.
Those two check boxes will only have effect if you select the "Reduced" library - i.e. newlib-nano, as per the attached screenshot.
Yes; I worked that out but it took more hours. I realised what was going on when I selected the nano options but my uint64_t sscanf still worked... Stupid interface design.
Anyway I wrote it all up so others don't have to do it all again.
-
(some were for arm32 chips with DSP instructions, etc)
DSP extensions are optional for Cortex-M4, but I would be hard pressed to find an M4 MPU without them.
STM32F4 (https://www.st.com/en/microcontrollers-microprocessors/stm32f4-series.html) family for sure has them.
-
OK. I can't remember the exact process I used. I posted about it e.g. here
https://www.eevblog.com/forum/programming/st-cube-gcc-how-to-override-a-function-not-defined-as-weak-(no-sources)/ (https://www.eevblog.com/forum/programming/st-cube-gcc-how-to-override-a-function-not-defined-as-weak-(no-sources)/)
Searching that c:\st\ tree yields 66 items - see attached screenshot for a part. The one I picked is 1033kb.
Then, based on the project properties settings Cube selects one of these and copies the appropriate one to a more local location, which right now I can't find. But with a lot of work I eliminated most of the candidates; most of them won't even link, due to the .elf file not compatible with something (as usual, loads of google hits). In the end I had 2 options: v7 and v8. Actually you can see them in the screenshot below. So I went for the v8 file. Then I used a linker config to hard-select my copy of the file and to get the new printf to override the relevant part of it, as described in the above link.
Everything works and is rock solid, runnin 24/7 with a fully loaded RTOS. I also traced through the printf code to make sure it really is running what it is supposed to be.
AFAICT none of this is documented anywhere. As given this code is PD, why didn't ST provide the sources, and a .h file with a load of #defines in it? It would have been a lot easier than doing 66 compilations, each with different CPU etc options. The one Cube supports the whole range of ST CPUs, hence so many libc.a files.
Maybe a paid IDE (Keil?) is better supported, but ST Cube was chosen because it is free and that was a key criterion because in some cases the customer will be writing his own modules, so I can just point them to ST Cube and give them setup instructions for importing a sample project. Years ago I did another somewhat similar product which had a £400+ compiler kit but today the customer acceptance of that is zero.
-
STM32F4xx are Cortex-M4 with SP floating point and DSP.
The core version is Armv7E-M, this is usually reflected in the library path, like the hard or soft floating point bindings (also a project choice).
ArmV8-M is for Cortex-M23,33 etc.
-
Dammit; the mystery is back :)
I managed to get a screenshot of the tails of the directories which hold the libc.a files - attached.
Would I be right that the right one is the highlighted one?
Actually probably, based on v7em, it would be the 1030k one, 2nd from bottom. Standard C library, not nano, hardware floats.
Many thanks.
EDIT: 2nd, bigger, screenshot attached.
-
In the second screenshot, if you are using soft FP, it's the highlighted one.
For hard FP it's the one in the 2nd row above the highlighted one.
In both cases, the toolchain knows what to choose, based on project settings; they should be similar to those in the screenshot below.
(From MCUxpresso (barf), for an iMX RT1062 based project, but probably almost the same).
-
I don't have an Architecture item on mine.
The 32F417 does have hardware floats (not double floats).
So it looks like the v7 e m fp. 1030k.
-
I don't have an Architecture item on mine.
The 32F417 does have hardware floats (not double floats).
So it looks like the v7 em fp. 1030k.
Ah crap...at work now, but maybe I''l put the STM32CubeIDE in a VM tonight and check where this is on that (other) crap pile.
Yes the MCU does have HW SP FP, but it's up to your choice to compile towards a hard or soft ABI.
-
WTF, I went and did it, instead of coffee (the effects of eclipse on my blood pressure is probably worse).
It's in MCU settings, still in the property page for the project, right where you select newlib vs. newlib-nano!
-
OK :)
(https://peter-ftp.co.uk/screenshots/202208173615421613.jpg)
That means that this should be the right file
(https://peter-ftp.co.uk/screenshots/202208173215441913.jpg)
Thank you very much for your help.
EDIT: @westfw I have had a look through the link you posted. I don't think the writer actually did any of that himself. As he says, one can replace the printf family with any number of the PD printfs (like the one I am using now) but the problem is that this stuff is in libc.a which contains a load of other stuff - basically the whole stdio and lots of other stuff. None of these - as supplied in the ST libc.a - are "weak" so it can't be done simply. Also I have not found a way to "edit" that library. Well, nobody else has posted a method. Even deleting modules from it doesn't work.
-
Bad news... malloc in here ...
Funny I didn't see that when debugging. Maybe a compile option, or maybe only with a specific scanf format.
You can see who is calling what in the cross-reference section of the mapfile. Here is the example from my current project at hands:
Cross Reference Table
Symbol File
malloc /opt/gcc-arm-none-eabi-9-2020-q2-update/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m+fp/hard/libc.a(lib_a-malloc.o)
/opt/gcc-arm-none-eabi-9-2020-q2-update/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m+fp/hard/libstdc++.a(eh_alloc.o)
/opt/gcc-arm-none-eabi-9-2020-q2-update/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m+fp/hard/libstdc++.a(new_op.o)
/opt/gcc-arm-none-eabi-9-2020-q2-update/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m+fp/hard/libc.a(lib_a-svfiscanf.o)
/opt/gcc-arm-none-eabi-9-2020-q2-update/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m+fp/hard/libc.a(lib_a-svfscanf.o)
/home/CENSORED/libCENSORED.a(hash.o)
/home/CENSORED/libCENSORED.a(lfs.o)
...
You can also see the full path of the library object, with thumb/v7e-m+fp/hard in it.
I am using CLion and Makefiles, so the corresponding line for gcc looks like:
LDFLAGS += -Wl,-Map,$(MAPFILE),--cref
Don't know how to do it in Cube.
-
Do you still use the soft-float libraries to get double support for chips that only have single precision hardware?
-
That cross ref was a great idea - many thanks
(https://peter-ftp.co.uk/screenshots/202208173615451019.jpg)
The result is interesting
_malloc_r ../LIBC/LIBCW\libc-weakened.a(lib_a-mallocr.o)
../LIBC/LIBCW\libc-weakened.a(lib_a-signal.o)
../LIBC/LIBCW\libc-weakened.a(lib_a-makebuf.o)
../LIBC/LIBCW\libc-weakened.a(lib_a-fvwrite.o)
../LIBC/LIBCW\libc-weakened.a(lib_a-svfiprintf.o)
../LIBC/LIBCW\libc-weakened.a(lib_a-findfp.o)
../LIBC/LIBCW\libc-weakened.a(lib_a-ungetc.o)
../LIBC/LIBCW\libc-weakened.a(lib_a-svfprintf.o)
../LIBC/LIBCW\libc-weakened.a(lib_a-reallocr.o)
../LIBC/LIBCW\libc-weakened.a(lib_a-malloc.o)
../LIBC/LIBCW\libc-weakened.a(lib_a-callocr.o)
_malloc_trim_r ../LIBC/LIBCW\libc-weakened.a(lib_a-freer.o)
I see svfprintf has sneaked through my printf replacement. But nothing uses it; it's hard enough to find any examples on google.
You can also see the full path of the library object
I now remember that was how I found which libc.a was being used. From the .map file. Then I copied over the wrong one ;)
Do you still use the soft-float libraries to get double support for chips that only have single precision hardware?
I think that is how it works, yes. Doubles are pretty fast if you have hardware floats.
-
For v7e-m+fp architecture, the compiler generates single-precision instructions, and calls to double precision functions:
1556 012a B7EE007A vmov.f32 s14, #1.0e+0
1557 012e 77EE677A vsub.f32 s15, s14, s15
1558 0132 17EE900A vmov r0, s15
1559 0136 FFF7FEFF bl __aeabi_f2d
Then the libgcc.a library is linked automagically to resolve the symbols:
__aeabi_f2d /opt/gcc-arm-none-eabi-9-2020-q2-update/bin/../lib/gcc/arm-none-eabi/9.3.1/thumb/v7e-m+fp/hard/libgcc.a(_arm_addsubdf3.o)
__aeabi_drsub /opt/gcc-arm-none-eabi-9-2020-q2-update/bin/../lib/gcc/arm-none-eabi/9.3.1/thumb/v7e-m+fp/hard/libgcc.a(_arm_addsubdf3.o)
__aeabi_dsub /opt/gcc-arm-none-eabi-9-2020-q2-update/bin/../lib/gcc/arm-none-eabi/9.3.1/thumb/v7e-m+fp/hard/libgcc.a(_arm_addsubdf3.o)
__aeabi_ddiv /opt/gcc-arm-none-eabi-9-2020-q2-update/bin/../lib/gcc/arm-none-eabi/9.3.1/thumb/v7e-m+fp/hard/libgcc.a(_arm_muldivdf3.o)
__aeabi_dmul /opt/gcc-arm-none-eabi-9-2020-q2-update/bin/../lib/gcc/arm-none-eabi/9.3.1/thumb/v7e-m+fp/hard/libgcc.a(_arm_muldivdf3.o)
...
-
... one can replace the printf family with any number of the PD printfs (like the one I am using now) but the problem is that this stuff is in libc.a which contains a load of other stuff - basically the whole stdio and lots of other stuff. None of these - as supplied in the ST libc.a - are "weak" so it can't be done simply.
I have created my implementation of snprintf() in syscalls.c file, built it, and ran in Ozone. My function is get called, instead of one in libc.a :
[attach=1]
Here are the corresponding map file lines:
.text.snprintf
0x000000000800dc4c 0x8 /home/[CENSORED]/objs/syscalls.o
0x000000000800dc4c snprintf
And this is the map file whith libc function:
.text.snprintf
0x0000000008050388 0x88 /opt/gcc-arm-none-eabi-9-2020-q2-update/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m+fp/hard/libc.a(lib_a-snprintf.o)
0x0000000008050388 snprintf
Are you trying to achieve something similar?
EDIT: syscalls.c lives in the same directory with main.c and contains the system calls which otherwise will be pulled from libc, like _open(), _close(), _lstat(), you name it.
-
Yes; this is done and working. So if you call say snprintf then you end up in the one from https://github.com/mpaland/printf (https://github.com/mpaland/printf) which overrides the one in the old newlib libc.a.
https://www.eevblog.com/forum/programming/st-cube-gcc-how-to-override-a-function-not-defined-as-weak-(no-sources)/ (https://www.eevblog.com/forum/programming/st-cube-gcc-how-to-override-a-function-not-defined-as-weak-(no-sources)/)
It's all working now. Solved. Took me about a week to work out how.
My complaint was why ST supplied a library which is not thread-safe (while also supplying an ST port of FreeRTOS) but which can't be made thread-safe without a load of acrobatics which I don't believe many people will be doing.
But I am far from the only one complaining about the ST Cube IDE. There is a guy in the ST forum (which has so many posts, mostly unanswered, it is practically useless) who spends half his time slagging off ST for supplying so much crap code. A lot of stuff which is really complicated, so you do need vendor-supplied libs to get going in a reasonable timeframe, e.g. ETH and USB, is only barely working.
-
Doubles are pretty fast if you have hardware floats.
Really? I thought I noticed that having single-precision HW doesn't help at all for doubles...
-
I was going to run some timings but can't now because I replaced the standard C printf lib :)
Logically you must be right. I can't remember where I read that single float hardware helps with doubles. A 32 bit barrel shifter, multiply, divide, etc, must help with doubles though. In the Z80 days they would be incredibly slow - of the order of 10ms for a double IEEE FP add or mult (IAR compiler), with a sscanf of %f taking 100ms.
-
I was going to run some timings but can't now because I replaced the standard C printf lib :)
Logically you must be right. I can't remember where I read that single float hardware helps with doubles. A 32 bit barrel shifter, multiply, divide, etc, must help with doubles though. In the Z80 days they would be incredibly slow - of the order of 10ms for a double IEEE FP add or mult (IAR compiler), with a sscanf of %f taking 100ms.
That sounds awfully slow even for a Z80. It would mean that the Z80 would need to execute in the order of 10k instructions for an FP addition. I suspect the soft floating point libraries wheren't very optimised.
-
I thought the same and found that IAR's sscanf was taking the string, say 123456.78, going to the end of it, adding the digits up (float add) multiplying each by 10 (float mult) and so on until it got to the first one. Then it would do a divide by 100 :)
All in IEEE floats.
This was used in HPGL data parsing, with the above data format always, and I didn't even bother trying to tweak it; I just rewrote it in Z180 asm, in about an hour, for a 100-1000x speedup.
The arm32 is a different world. None of this stuff is at all relevant now. But it is possible that a software printf (which in newlib will be Double) is quite slow, unless the CPU has hardware doubles. All the more reason for not using a printf which uses Double. It has practically no applications in embedded.
-
I'm using printf with doubles quite a lot in several projects to implement text based protocols between various devices. The soft-floating point libraries that come with GCC are well optimised. Unless you are under severe time constraints (several tens of us), I wouldn't bother avoiding floating point even if the device doesn't have an FPU. I have used soft-floating point doubles in telecom audio processing applications as well. In many cases it is just not worth the trouble of using fixed point arithmetic.
-
Using printf() per se can be problematic enough (see other thread), but scanf() functions? Eek. Please don't use them. ::)
-
Using printf() per se can be problematic enough (see other thread), but scanf() functions? Eek. Please don't use them. ::)
scanf is iffy indeed because you don't always know the input. With checks added, the atoX and strtoXX functions work well. Printf OTOH is perfectly controllable because there is no (uncontrolled) external input. Only real mistake to make is feeding the wrong type into printf that causes it to lose track of the parameters. But in the end that is a programmer's mistake.
-
This mostly comes down to programmer productivity.
Given enough time, you could do all input with atoi atol etc, atof is for wimps who didn't scale their values carefully, and you could do all output with itoa, ltoa, ftoa is for wimps who didn't scale their values carefully, etc. :) But then you spend a few hours instead of a few minutes. You just need to understand the limitations, and this non thread safe newlib printf stuff is one of these (and in a nasty non obvious way too, courtesy of STM). Given enough time you can write everything in assembler - as I have done for some decades - but even if you want to pay for it, your recruitment options these days will shrink by 99%.
Times change. The H8/323 would not be able to host a double IEEE printf and have room for any other code. It cost £9 (10k) over most of its 25 year production run. The 32F417 cost £5 (500) and with 1MB has basically no code space limits. For another £2 you can have 2MB. Most projects are RAM-limited. My point is that nowadays there is no point in using smaller chips unless it is really cost-sensitive. A high volume OEM will be getting the 32F417 for £2.
-
I may have found a reliable way to make Cube display the missing Build Analyser page:
Go to whichever directory in your project holds the .map file and click on it.
The alternative is to build the project twice.
-
I may have found a reliable way to make Cube display the missing Build Analyser page:
Go to whichever directory in your project holds the .map file and click on it.
The alternative is to build the project twice.
Try right clicking on the project and doing "refresh", or hit F5.
It'll be because Eclipse isn't aware the map file exists yet.
-
The "refresh" doesn't work for me.
Clicking on the .map file does.
-
If the build analyzer doesn't update, just click anywhere in the project file tree window, that works for me everytime.
-
Not for me :) :)
Even a right-click / Refresh doesn't do it.
But a left click on the .map file does it.
I would never release a product which just tells everybody that I didn't give a s**t about little details.
-
Having just spent a few solid weeks on debugging code, my main criticism of "HAL" is that it has poor granularity.
All the code is basically bloated. But it shows up especially in the ISRs, which people rarely look at because by their nature they are convoluted, and interrupt generation (IP bits) behaviour is often nontrivial. ISR-driven software tends to be convoluted anyway. It is only when one starts to step through one of the ex-MX generated ISRs that one sees just how bad it is. It is stepping through a large number of possible int sources (most of which are not enabled anyway). They get away with this at 168MHz and 1 clock per cycle... You would never write ISRs that way yourself; it would do only what is needed and then gets out of there.
Also a lot of the code comments are simply wrong - probably due to the coder not speaking English.
Cube v10 is a lot less reliable than v9 or earlier. I normally have to restart it a few times a day. And the ITM debug console is rubbish; works only on Tuesdays :) The ITM enable button has two displayed states and sometimes one works, sometimes the other, and sometimes it remains enabled through a compile session.
-
Here is a good one.
Cube v10 does not start over RDP (remote desktop) over a "teleworker" VPN. Neither L2TP nor PPTP VPNs work. The person using it (me) is on a 3G/4G connection.
Loads of errors saying unable to initialise screen objects etc.
However it does run over RDP over a "site-site" VPN (IPSEC).
It is as if during startup and loading the various Java objects it is making online connections to fetch some stuff, and these connections work over one type of VPN but not over another type.
Completely weird.
-
Stop using Cube. =)
-
Peter, ST won't pay you for the bug discovery ;)
-
Fixed it.
Instead of saying "your video system needs 24 bit colour and it has only 16 bit colour, you get this crap:
(https://peter-ftp.co.uk/screenshots/202209152015762306.jpg)
(https://peter-ftp.co.uk/screenshots/202209154015772406.jpg)
-
Does anyone know if Cube has a config for whether the program grabs Windows focus when it hits a breakpoint?
It's a real hassle when you run a build and then you go and type something and then when it finishes it suddenly starts consuming keystrokes :) And it does this into a randomly opened file.
-
It's Eclipse, for god sake.
I'm surprised this is the first time you have used Eclipse.
Hate IBM, they started it. I can't remember if it started as proprietary and was open sourced or if they open sourced it to save them developing their own IDE for webshere, but that's where Eclipse came form.
In terms of Eclipse "language adaption", it's not bad. The IOC editor needs optimised.
Eclipse runs in Java. So it needs MORE MEMORY. You need the Eclipse JVM to have a minimum of 1Gb of heap space and 2 of 4 if you are running any complex Java based add ins.
As a modern heavy weight IDE, it's not meant to be run on machines with low resources or over VPNs with low bandwidth, it's mean to run on a developer workstation, so it expects LOTs of cpu, LOTs of RAM and lots of screen space. If you want to work on more modest hardware, don't use Eclipse.
It is a primary Java IDE, a fairly poor C/C++ IDE (as it needs heavily configured to get indexing working properly in many more complex projects), there are probably 100 different "canned/wrapped" version of Eclipse out there. I wasn't surprised to see it being used for STM32's IDE.
Android studio, by example, uses JetBrains InteliJ platform under-neath, same as "PyCharm". Not sure if any MCU manu's are using it for the base.
The thing is... those two big IDE bases (Jetbrains and Eclipse) probably account for 70% of the market for IDEs (outside of Microsoft lock in). The reason companies are using them as the base, is obviously because they don't need to write the base application, they can just write plug ins, views and panels. Also, they retain the familiarity between the different sub species of IDE based on each. If you use PyCharm you'll be familar with Android Studio. If you are familir with Eclipse for JBoss you'll be familiar with CUBE_IDE.
A tip:
Don't become too attached to your IDE config and settings. If and when Eclipse detonates and corrupts itself the fastest way to get it working again is to create a whole new workspace and import you projects across.
Better yet. Don't create your projects in the workspace in teh first place. Create them external to the IDE and "Import from filesystem" with the "Copy to workspace" unticked. So even when you wipe or delete the workspace out of frustration, you can rebuild it in minutes.
-
On code generation. At least the STM32CubeIDE gives you choices, such that a default project starts with no peripherals configured and a minimal (debatable) amount of HAL boiler plate code.
Contrast with the Arduino IDE / Framework where it just configures everything, whether you need it or not, and makes a whole bunch of decisions to follow "Arduino conventions" and ... then hides ALL of it entirely from the user.
If you delete the comments from the default project it's actually not that bad. If you remove the generated error handler, interrupt handlers etc. etc. etc. it really comes down to a bit of ASM to start the chip, the memory mapping file, NVIC initialisers and not much else.
The advantage of using the HAL functions which generate a lot of that code bloat, is more simple than you expect. Those HAL librariles compile on a large range of STM32 micros. So in a lot of cases you can just flip the chip type, regenerate the hal boiler plate and your code still works on the new MCU.
If you had dont everything via registers directly that is unlikely to occur. No?
It's always a trade off. Bloat for convenience, bloat for safety, bloat for ease of use. Hardware is cheap developers are expensive.
-
The advantage of using the HAL functions which generate a lot of that code bloat, is more simple than you expect. Those HAL librariles compile on a large range of STM32 micros. So in a lot of cases you can just flip the chip type, regenerate the hal boiler plate and your code still works on the new MCU.
No. It won't. The API between various peripherals isn't consistent. And it can't be because peripherals with a similar-ish function are too different between STM32 controllers.
-
Is there any way to stop a Windows application from grabbing focus, and thus absorbing any keystrokes intended for another application?
-
Is there any way to stop a Windows application from grabbing focus, and thus absorbing any keystrokes intended for another application?
Under the default shell I don't think so.
It's exceedingly annoying and exceedingly insecure. I had an IM client pop itself into focus while typing a password the other day and it was only by chance I looked back up before hitting enter and sending my manager my login.
I've even had pop up error boxes and the like appear under my mouse cursor just at the moment I click something else and click the error box.
Actually, last week the "Your PC needs to be restarted...." popup appeared requiring me to restart. Except I had just typed "ls" in a terminal and when I hit enter it actually was captured by the "Restart Now" button!
-
No. It won't. The API between various peripherals isn't consistent. And it can't be because peripherals with a similar-ish function are too different between STM32 controllers.
Well, you best tell STM that. Because they called it a Hardware Abstraction API. So it's obviously not abstracting any hardware and on your advice they could save a lot of money.
-
At some point, Windows was NOT stealing focus by default, unless you enabled it through some system setting. For any process requesting focus, that was not in the foreground, the corresponding window title bar would just flash (and in the task bar too.) Pretty cool.
IIRC it was in Win 2000 and Win 2003 (the latter was a server version but was what I used for a few years instead of XP, it was easy to configure it as workstation, and it was great.) The MS geniuses probably figured that it was too much of a "mental burden" for the idiotic masses not to have the window wanting focus to just plain pop up right in their face, so they removed this feature. Or maybe that was just to annoy users, which MS is very good at.
On a different, but equally problematic vein, the OS should never allow the screen to go blank (or screensaver) without locking the session at all times. Yes I know some people find it so hard to type their password. But thing is, you may not know whether the session is locked or not. I have been trapped once typing my password when the screen was blank out of habit, thinking the session was locked. And it wasn't. So the password I typed ended up in the application that was in the foreground. Things to think about.
-
the OS should never allow the screen to go blank (or screensaver) without locking the session at all times
I think that is configurable in the screensaver config - desktop / properties etc.
You can have a screensaver without a password, which is ok for a privately used PC at home.
-
Coming right back to the OP again.
I've been using STM32CubdeIDE for a few weeks now and I am used to Eclipse appliance IDEs. I'd say it was one of the better ones.
On logging in the next day and finding you project doesn't build. This happens from time to time, it's an artefact of your build timestamps getting confused and thinking a .o file is up to date and it's not. I had it twice recently.
In both (the usual) cases of this, I just did a "Project->Clean" and it fixed it.
This happens from time to time in Java too. Although it's usually a lot more complicated and it's due to slightly out of date deps somewhere in the tree. Forcing a dep update twice in a row usually sorts it.
Building off network drives or NAS etc can cause build timestamp slew, which upsets make and most build script engines.
-
Agree 100%. I always Clean the project if editing any files outside of Cube. Cube should spot them if they are more recent (there is a config for this IIRC, somewhere deep in) but it doesn't always work and you get weird things happen.
Cube V10 is less reliable than previous, too, especially in breakpoints etc getting screwed up. One has to exit and restart Cube.
But I have never seen a solid Java application on a PC. I've used Java apps (Windows) for years in other areas and they were crap too, sensitive to all kinds of stuff. But if you look at how many thousands of files are in this kind of application, it's not surprising.
And losing the debugger is common; every 10 or so builds I have to unplug/reconnect the USB cable. That is with STLINK V3. I think STLINK V2 was more reliable but it doesn't do the ITM console debug which is sometimes useful. It is a right PITA when working remotely, over RDP; then it happens more often still. I have to message someone on the site to do the USB cable ;) The only other way (remotely) is to reboot the PC.
-
Peter, give EmBitz (https://www.embitz.org/) a try.
You might need some time to get used to it, but the speed is just mindblowing, just like older IDEs before the Java crap era.
It includes SPL, LL and HAL libraries, not sure if CubePukeMX importer is already done, the guy said he was working on it...
It also supports other architectures.
-
Thank you. I posted a Q on their forum:
https://embitz.org/forum/thread-138-post-638.html#pid638
I wonder what the dev's business model is in the long term. To emulate Cube is a huge amount of work. Even just writing the editor is probably a man-year, unless you can build on something else.
I don't need MX and don't need HAL libraries; AIUI all these are already imported in my project, aren't they?? Cube keeps its own stuff under c:\st and c:\users and AIUI it transfers those to your project. I have certainly made copies of my project on a laptop, but that had a Cube installation (obviously) so if the project had external links (say to c:\st and c:\user) I would not discover that.
-
Usually projects will import fairly easily. You can usually find a guide on what to commit to VCS and what not to. The project itself, ie copied from the "workspace" folder will contain absolute paths. The actual application files remain independent and relative.
This re-iterates the point about keeping your projects outside of the workspace folder, even if you have to create them there initially, they should be decoupled from it as soon as you can.
To re-import it use the File...Import... "Existing projects into workspace". Do not move/copy the files. Then all "your" files can be done with as you choose and the "workspace" metadata will be recreated for each instance.... and it stops people checking workspace files into git!
The caveats of course is the configuration of Eclipse. You'll not have much luck importing a Cube projecting into Eclipse for JBoss obviously, but it also applies to plugins. They will need to be installed manually, although it will probably give you a sensible or not error.
-
I second the observation of peter-h. I have never seen a rock solid java application as well. I guess that is why Google wrote their own java implementation for Android.
It is a miracle Eclipse works as well as it does though. On Linux Eclipse works considerably quicker though but it seems newer versions of Eclipse are slower. For everyday use, I'm still using the version called Kepler
-
The Java UI toolkits are horrible. Java is hideously memory intensive, not just amount, but the churn. That is far more likely to be the case in desktop applications than in enterprise. Enterprise Java runs on Linux headless of course and memory is expansive and cheap.
If you look at various java apps (including Eclipse's) "ini" files they typically allocate 256Mb or 512Mb up front and request the option to expand to 4Gb or more! I think eclipse defaults to 1Gb, in Java development that usually gets expanded to 4Gb.
That obviously has knock on effects on your CPU. That memory churn is extremely CPU intensive. So an older, weedier laptop or something on a Celery stick moving multiple gigabytes of page files around in memory takes tangible time.
Eclipse I believe uses a gtk based native accelerated UI toolkit.
-
To re-import it use the File...Import... "Existing projects into workspace". Do not move/copy the files. Then all "your" files can be done with as you choose and the "workspace" metadata will be recreated for each instance.... and it stops people checking workspace files into git!
I may be misunderstanding but when setting up a copy of a project on another machine (say, on a laptop which you are taking with you when travelling) I never found a way to use Cube to import a project, by pointing Cube to the existing location from where you want to import it to form a local copy. It never worked. Such a simple thing!
The way which works is to separately copy over the project directory, say c:\productname\project1\, where you have the whole hierarchy
(https://peter-ftp.co.uk/screenshots/202210090815984614.jpg)
(btw, I notice the .xml files are old and probably fossils from an old Cube version)
and then (or before, but separately) you install Cube on that machine and use these steps:
When a completely fresh installation of Cube on this computer is started, it shows a general information/marketing page. This should be closed. Choose Import projects then Select / General and highlight Existing Projects into Workspace. Then browse to it and eventually it discovers a valid project (not sure how it does that; probably looks for certain file(s)). Then you Import it. That "just works". Then you must do Project / Clean Project and then you can build it. I've documented the steps carefully with screenshots but the above should be obvious.
You have to import an existing working project. To create a project from zero is too complicated to even start to explain. Way too many things to configure. Looks at the days and weeks of my life spent e.g. replacing the crappy Newlib printf with its dummy mutex stubs and heap usage. Even if I had just main.c which says "hello world" I would not know how to set up Cube. But of course in an embedded context you have no "stdout" and there is no way to do "hello world" without a huge amount of supporting code, to set up the CPU, peripherals, and as a minimum configure a UART to squirt the text string to. Now that I have a solid running project I never want to do this again in the rest of my life :)
If you want to import a Cube project, you better hope everything is to be found in the project directory otherwise you will have a Cube version dependent import method. I've been using Cube since v1.3 and it has changed the usage of c:\st and c:\users\username\stm32cubeide several times.
If you look at various java apps (including Eclipse's) "ini" files they typically allocate 256Mb or 512Mb up front and request the option to expand to 4Gb or more! I think eclipse defaults to 1Gb, in Java development that usually gets expanded to 4Gb.
I have 24GB but there are other issues :)
Java is great is you work for a company paying you by the hour. Then you have a job for life.
If/when I get a reply on the Embitz forum I will give it a try, but I won't risk it unless I am fairly sure it won't trash it.
-
That obviously has knock on effects on your CPU. That memory churn is extremely CPU intensive. So an older, weedier laptop or something on a Celery stick moving multiple gigabytes of page files around in memory takes tangible time.
I don't have that problem with Eclipse. First thing I do is disable paging / swapping to disk and make sure there is enough physical memory. Disabling paging to disk makes a PC much faster (especially on Windows which tries to put as much on disk as possible in order to not use as much ram as possible :palm: )
-
I tend to end up with this "split" affair.
I tested and it seems the cube projects are pretty clean, I left the .settings/ folder behind everything else was needed. As a top tip, create your own code style file and add it to the repo, then nobody has an excuse for horror merges.
[attachimg=1]
-
My .settings directory contains
(https://peter-ftp.co.uk/screenshots/202210094815995118.jpg)
which suggests all but one are fossils, and the one contains
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<project>
<configuration id="com.st.stm32cube.ide.mcu.gnu.managedbuild.config.exe.debug.346995266" name="Debug">
<extension point="org.eclipse.cdt.core.LanguageSettingsProvider">
<provider copy-of="extension" id="org.eclipse.cdt.ui.UserLanguageSettingsProvider"/>
<provider-reference id="org.eclipse.cdt.core.ReferencedProjectsLanguageSettingsProvider" ref="shared-provider"/>
<provider-reference id="org.eclipse.cdt.managedbuilder.core.MBSLanguageSettingsProvider" ref="shared-provider"/>
<provider class="com.st.stm32cube.ide.mcu.toolchain.armnone.setup.CrossBuiltinSpecsDetector" console="false" env-hash="-1504631925663965107" id="com.st.stm32cube.ide.mcu.toolchain.armnone.setup.CrossBuiltinSpecsDetector" keep-relative-paths="false" name="MCU ARM GCC Built-in Compiler Settings" parameter="${COMMAND} ${FLAGS} -E -P -v -dD "${INPUTS}"" prefer-non-shared="true">
<language-scope id="org.eclipse.cdt.core.gcc"/>
<language-scope id="org.eclipse.cdt.core.g++"/>
</provider>
</extension>
</configuration>
</project>
and I have no idea what that is about :)
-
If/when I get a reply on the Embitz forum I will give it a try, but I won't risk it unless I am fairly sure it won't trash it.
What's the point? If the IDE works, it'll keep working even if it's no longer updated, no matter if it's 2022 or 2035.
The rest of your questions are easily answered by trying yourself.
- emBitz is not eclipse-based, so it use different project files, the stuff from Eclipse keeps unaltered, the only changes will be what you do in the source files.
In any case, just make a small blinky project in CubeIDE, then import it into emBitz, and see what happens.
- Open emBitz, go to debug, interfaces, EBLink (GDB server replacement), there's a field to adjust the ST-Link speed.
- Same about testing emBitz in W64 x64 (it worked in a Virtualbox Win64 x64 machine).
-
I did a search. It came up before here
https://www.eevblog.com/forum/microcontrollers/embitz-is-coming-back-soon/ (https://www.eevblog.com/forum/microcontrollers/embitz-is-coming-back-soon/)
I don't understand the comments about it not supporting an RTOS. How does an IDE support an RTOS? I know Cube has some RTOS support but I tried it and it doesn't do anything; apparently one has to add some hooks into one's code to get something useful there (a real time display of tasks, etc, but I have that already via an http server).
-
I guess it's CubeMX library (Part of Cube IDE) what supports RTOS (Reentry etc), otherwise, as you say, the IDE is irrelevant.
-
I have never used MX. I thought it was just a "code generator". It seems to be useful for quickly generating some config code, and that is useful (in view of the 2000 page RM, etc) but once you got a project running there is no need for it.
I agree that an IDE does not in principle need updating, and that is my philosophy too (I still use a PCB design tool from 1998 - Protel PCB 2.8 ) but in this case I am doing a product which will have some support for user-written modules, and I can't really tell people to do that.
-
AFAIK CubeMX is also included into CubeIDE as a code generator / project dressing tool. I don't know a better term than 'project dressing' for a process that just selectively copies source files into a project.
-
Yes, it comes with Cube.
You can regard MX-generated code in the same light as spending a day googling for various register names and see what code different people use to set them up. This is what 73.5% of coders spend 93.5% of their time doing :)
And 99.1% of them never post a solution anywhere because it was developed in company time ;)
The difference is that while 72.6% of code which google comes up with (mostly github but also various other "tutorial" sites) doesn't actually work, 82.8% the MX-generated code does actually work :)
-
and I have no idea what that is about :)
I looks like it's configuring an STM32 extension relating to C/C++.
The important part is it doesn't contain any absolute paths. As I left it behind, I expect it will recreate it or I'll find an extension failed somewhere. It's usually the .settings/ folders which trigger extensions and plugins and cause issues importing between IDEs.
It's usually only the first few weeks in a project there are issues sorting out the git repo and every ones different choice of IDE. Usually various version/variants of eclipse and InteliJ, although I tend to edit some files outside eclipse in vim as I'm usually making immediately and small changes to a DB script I immediately have to commit, push, login, build and deploy to run. Remembering to keep the three or four repos in sync is just a penalty of working in a high secure environment where your only point of contact outside your dev machine is through BitBucket and some heavily restricted web front ends.
Anyway. It looks like Cube's projects are fairly clean. You might have teething troubles between different versions of Cube IDE, but it should be fine.
Leave the workspace folder to eclipse. Consider it almost ephemeral. If/when it gets corrupted or Eclipse needs upgraded, it's often better to just fresh install it in a fresh empty workspace and import your projects. Protect that hierarchy, forget the workspace.
For more intense work. Splitting the workspace or importing projects into more than one workspace can allow you to run 2 copies of eclipse. I've done this for a while, while times witching 2 projects under pressure.
-
As a general tip for Java. Eclipse as well, but more "optional".
Download and install your own JRE and JDK. Make a folder, C:\Java under it put the jre and jdk and rename the folders to just jdk, jre. If you need Java 8 (Pre-Oracle) where most OSS stopped. Have jdk8, jdk11, jre8, jre11. Set your JAVA_HOME in your environment yourself.
This means if you ever need to set your JAVA_HOME and classpaths manually, you don't need to reference C:\Program Files\Java\some1241.5132 version. Not least because it has a SPACE in it and not forgetting that Java is subject to automatic updates and the path will change. Also means you don't have to rely on the auto updaters changing your JAVA_HOME and when it does cause issues you know where it is and what it is.
-
Unfortunately, that approach is ridiculous in the requirement for a whole new level of PC software architecture knowledge.
Cube is an application (a "program") which should start up and run as one expects. Even just the need for this
(https://peter-ftp.co.uk/screenshots/20221011174911312.jpg)
24 thousand files!
shows how far the "art of programming" has come. Who can ship an install package which dumps 24000 files to your PC?
Admittedly this includes the ST libraries but still... ???
-
I don't understand the comments about it not supporting an RTOS. How does an IDE support an RTOS?
E.g., during debugging, it can show additional info per thread. GDB is thread aware, but not all IDE can show the extra info, or single step per thread etc. etc.
See below a picture of VS code with Cortex-debug extension, using gdb and my gdbstub as gdbserver, running on a Teensy 4.1, showing per thread stack trace.
In the second picture, how it could appear with no threads (exactly the same code running on the Teensy).
-
24 thousand files!
It is most likely the source code for the libraries, including all the comments, the headers, the documentation, the firmware (debug archives of with symbols etc.). (As an aside I remember making my first Linux boot disc from source code. I laughed when I seen the "mini" GLibc came out at 87Mb. A quick google and "lightbulb". "strip" to remove unnecessary text symbol and all the locale stubs etc. etc. and one 400k so.
I'm not justifying the bloat, but it's real. Disk space is cheap. Engineers are expensive. It is probably, for example, far, far easier to manage sending you a complete, full set of everything, for every board you open a project for, when they only differ by 2% of files, than to manage sending you ways to layer/overlay etc. Trust me. I've been there using sparse hierarchical build repos. You don't want to go there. It's better to duplicate and buy a bigger disc.
It's funny how code reuse has multiplied the amount of code we write by a factor of over 1000. (I can find a source for that, but it's a bit hyperb-ollox ;)).
Also, if your install is older than about a year. I would make a fresh install of the IDE. A clean workspace and only import the projects you are working on.
All of the above "blobs" of files for each board class, will also be "per version" and I doubt they delete the old ones.
-
24 thousand files!
It is most likely the source code for the libraries
I was going to say that was the cause, but decided to check.
Now, not so sure about it.
My STM32CubeF7* directory contains by itself:
31 805 Files, 7 477 Folders
I don't have the STM32CubeIDE installed, but taking my MCUxpresso (NXP equivalent, just as hideous🤮) install:
19 652 Files, 2 067 Folders
So, not far from peter-h result with STM32CubeIDE.
Note that this install includes zipped SDKs for some MCUs, but they are one zip file per MCU, so just a drop in the ocean.
Actual SDKs are elsewhere.
As a point of comparison, my VS Code, excluding extensions:
1 175 Files, 474 Folders
Pretty lean, one would think, until they look at the extensions directory (I may have far too many...):
39 077 Files, 6 422 Folders(might include some caching and DBs)
Full Visual Studio 2022 (CE):
33 409 Files, 4 465 FoldersThis might include some Windows SDK, though.
*Pet peeve of mine:
- Cube, by itself, it's the whole collection of all tools and libraries.
- STM32CubeXXX is the support package for STM32XXX MCU, e.g. STM32CubeF7
- STM32CubeMX is the stand alone configuration tool
- STM32CubeProgrammer is...the programmer
- ...you get the drift...
- STM32CubeIDE is the Eclipse based monstrosity peter-h has an abusive relationship with.
Calling everything Cube when talking of a specific piece just confuses and slightly annoys me.
-
The current cube has the MX part integrated into Eclipse. As is the debugger and the programmer and everything else. With the annoying exception of no "UART Monitor" by default.
-
The current cube has the MX part integrated into Eclipse. As is the debugger and the programmer and everything else. With the annoying exception of no "UART Monitor" by default.
I know.
[pedant mode]the current STM32CubeIDE has the MX part...[/pedant mode] :horse:
-
I might have to become a bit more familiar with it. I want to use a "Blue Pill" board as a real live ARM core to play with ASM. Having a hardware debugger in the core obviously gives me single step, live register access.
This all works and I can call my ASM from C and call C functions from ASM.
The trouble is it uses the gcc ASM. I was just getting happy learning some NASM. Especially the funky "32bit literal" register load macros etc. etc. etc.
So, I'm going to attempt to add NASM to it's build chain....
-
A few determinations.
The folder, C:\Users\You\STMCube will contain your "Respostory" folder. It is here it keeps BOTH the zip file for each board types firmware, but the unzipped copies too.
That is all the source code for all the hal drivers, demos, docs, the works.
This at least can be moved to a cheaper drive in "Window->Preferences". I moved mine to network. It's slow, but it's only really needed at project start up or upgrade time.
It seems every time you enable something in MX, it copies code it needs from the FW Repo into you project. The nice part about that is, you can freely edit all the FW and driver code.... or remove it if you choose.
Not yet sure on the C:\ST folder and if any of it can be off loaded from C:\
-
The above workspace/data/config location changed within the last year; can't recall which Cube version.
I did document a procedure for creating an exact copy of a project on another machine, involving making a copy of the project (say c:\projectname) and a copy of c:\st, and back then I didn't copy over anything from c:\users\st...whatever, and that worked, obviously only with the exact same Cube version.
Later I abandoned this procedure because it seemed pointless, in favour of the Import procedure described above.
One thing which used to screw up a Cube project pretty well was if you had Cube running and then externally deleted the project source files :) Cube would notice they went missing and you had a load of fun setting it all up again. But now the Import procedure covers this too. The external deletion is used when the project had been worked on extensively on another machine. You have to exit Cube before doing such a deletion.
-
Yes. hmmm.
Unfortunately parts of CubeMX IDE get really upset about network paths. Unzipping firmware for example causes it issues. Building projects from the already unzipped firmware on network drives produces partially built projects.
This is not uncommon in windows apps, "network drives" are not as transparent as they should be at times. It's not just build timestamps which can be taken care of, it's something odd about how some applications/APIs handle file transactions which causes them to get corrupted on a network drive.
It's odd as it's fine with the workspace on a network drive, but not it's firmware folder.
The reason this is important to me is that SSD space is expensive. Things like multi-giga byte firmware template archives have no place on local or virtual SSDs. They go on cheap bulk spinning metal. Seems I might not have a choice. I'm going to try and hide the network-ness of the drive by mapping it through a Windows library folder like C:\Documents but I expect that will probably fail and write straight through the library reference to the C:\Documents physical folder anyway.
The other option of course, as network bandwidth is cheap, is to just delete the contents of the repo and re-download it all when I run MX. Sounds tedious.
I suppose I could use a new SSD anyway.
EDIT: On corruption while unzipping and file transactions. A likely culprit is case sensitivity or lack of it. I have seen cases where applications, from windows writes two different files, say, "File1" and also "file1", the underlying linux filesystem is like "Okay.", but when Windows asks for "File1" expecting "file1" things go very wrong.
-
Windows is not case sensitive but Unix is and this issue was noticed when a colleague was compiling my project on a linux machine; a few things, apparently ex ST, needed to be renamed.
-
Yea and today I wasted an hour trying to get Blinky to work on a new board. An STM32F030F4C6. It generates the project fine and it runs, but there is no SysTick interrupt firing. I can see the interrupt handler in the start ASM, but it never gets called. Nor does the Default handler. It's like nobody switched on the SysTick interupt timer, however I can see it doing so in Hal_Init(). It did this before, the first time I used this board and I fixed it, but I can't remember how.
-
I did wonder where the 1kHz tick gets initialised on my project and eventually I found it, in osKernelStart(); in FreeRTOS. That part was originally set up by someone else.
The code to start it looks like this
/*
* Setup the systick timer to generate the tick interrupts at the required
* frequency.
*/
__attribute__(( weak )) void vPortSetupTimerInterrupt( void )
{
/* Stop and clear the SysTick. */
portNVIC_SYSTICK_CTRL_REG = 0UL;
portNVIC_SYSTICK_CURRENT_VALUE_REG = 0UL;
/* Configure SysTick to interrupt at the requested rate. */
portNVIC_SYSTICK_LOAD_REG = ( configSYSTICK_CLOCK_HZ / configTICK_RATE_HZ ) - 1UL;
portNVIC_SYSTICK_CTRL_REG = ( portNVIC_SYSTICK_CLK_BIT | portNVIC_SYSTICK_INT_BIT | portNVIC_SYSTICK_ENABLE_BIT );
}
MX generated code uses huge interrupt handlers which step through every possible interrupt source without regard for which interrupts were actually enabled. It works "ok" on a 168MHz CPU but you would never write your own ISRs that way. Oh well, a consequence of software generating software :)
-
I ended up finding even more issues with the network drives. Things like parts of the project appearing and disappearing.
Went to local disk for the workspace and set a project up and... my SysTick worked.
On HAL libraries and in-efficiencies. I'm not so sure. I'm playing with an STM32F030F4 which has 16Kib Flash and 4Kib SRAM.
With RTC enabled, an I2C and an SSD1306 display I'm at 91% FLASH and 70% RAM.
I even tried saving RAM by defaulting the clock config, but, no, the RCC_OscSetup function still takes up 1.6Kib of Flash!
Even trying to enable TIM4 and using Sleep instead of Delay resulted in 103% flash.
So it's bad, but it's not that bad. It does seem to only pull in what you use.
I've kicked out all the test functions. I only loaded one font, the smallest one I can live with.
A "Release" build will bring it down to 80% flash, it's just I can't then debug that TIM4 to make it work.
There is some bloat in the Init functions that could be thinned out, a lot of conditional stuff that I can't see changing at runtime, so why bother checking, etc. I'll comment out loads of it and see if it still works :D
The idea was a little battery powered "How many sleeps to Santa" device for my 5 yo. However, looking at it and that little RTC has gained 4 minutes extra time in an hour. So, it's not going to work. Was still fun for a Saturday afternoon. It also pulls 9mA. If I sleep it and let SysTick wake it, it pulls 10mA LOL Which gives it a 10 day life on an 18650. Unsoldering the power LED and I might get that down to half that. I still need more than 20 days... and an accurate clock.
[attachimg=1]
-
One font, does that mean you have a graphics library that fits into 16K? Which one?
For battery supply, i would rather use something like a Nucleo-L432. It has 256K Flash and is available at 11 €. Recently i tested a L431 and without PLL it runs at 1.5 mA on the internal 16 MHz clock and with 1000 Ticks per second and sending UART messages. And the two DAC outputs were on.
Regards, Dieter
-
Use optimization for size when debugging, then manually unoptimize the functions by adding the directive:
__attribute__((optimize("O0"))
void my_Function(){
...
}
Only that function won't be optimized, so repeat with every function you want to debug.
What display are you using?
If monochrome, U8g2 can get pretty small, uses some sort of font compression/packing, also you can create your fonts with its tool bdfconv, adding only the required characters, cutting down a lot of space.
-
I was using a little SSD1306 screen. So it's monochrome 64x128.
https://github.com/afiskon/stm32-ssd1306
Seems to fit. As I said, you'll need to strip it down. Drop all the tests, enable a small font.
So I2C Bus + RTC + SSD1306 libs, HAL autogenerated with CubeIDE, gives a Release flash size of about 14Kb.
That doesn't leave much. Even enabling another timer for screen redraw is too expensive (with autogenerated HAL)
The MCU RTC being out of whack is kinda obvious. Not least the datasheets recommend not using it for anything you want to be accurate. But it also there is no 32.xxx xtal. So it's driving the clock at 40k which is why it's about 7% fast.
-
Yeah I always lifted my eyebrows when seeing the memory used by HAL_RCC_OscConfig.
Anyways those 1.6KB are too much, clearly you're compiling with optimization disabled.
But the issue is clear:
- HAL code includes every possible scenario
- Most HAL functions use pointers to non-constant data (Thus treated as volatile)
- So the compiler only optimizes the code, but can't stripe unused code because it expects any possible scenario.
For example, your clock initialization probably only uses HSE or HSI oscillator and never changes, but all HSE, HSI, LSE, LSI "ifs" will still be there after compiling.
Actually there's no such "bloat". The library is capable of changing the clock source at any time, on every condition, that's all.
If they removed those capabilities, people would complain anyways, "I can't change to low power oscillator! CUBEMX crap blah blah"
Once you delete these sections (Modify for your current setup), HAL_RCC_OscConfig memory usage reduces to almost 1/3:
/*----------------------------- HSI Configuration --------------------------*/
/*------------------------------ LSI Configuration -------------------------*/
/*------------------------------ LSE Configuration -------------------------*/
Giving the following results:
No optimizations: 1.25KB -> 588 bytes
Optimized for size: 824 bytes -> 360 bytes
And that probably applies to every other HAL function using pointers.
So if you know you requirements, you can strip a lot of code.
Interestingly, compiling the same tests on emBitz produces no difference, not a single byte! So emBitz is actually removing those unused parts.
Searching the differences, found that emBitz has Linker Time Optimization (-flto flag) enabled by default.
It not only reduced the overall code size by half, it also somehow causes absolutely no difference in code size when removing those code sections.
When disabling LTO, yeah, those code sections made a difference and the final size was very close to CubeIDE's.
Last time I tried LTO on CubeIDE the stm32 just booted right away into HardFault.
I didn't spend more time researching, but might worth reading, specially on that starving 16KB mcu:
https://www.disk91.com/2020/technology/programming/code-optimization-with-stm32-cube-ide/ (https://www.disk91.com/2020/technology/programming/code-optimization-with-stm32-cube-ide/)
Here it explains what probably was my issue:
When using LTO optimization, you need to make some change in the startup file.
It seems that’s a bug with weak function in the GCC version used by ST Cube IDE, so it may be fixed later.
The current problem is: when weak interrupt functions are declared in the Core/Startup/startup_stm32xxxxx.S file the irq handler in the Core/Src/stm32lOxx_it.c file are ignored and removed.
The consequence is the device is not booting.
In the comments:
James Wilson on 11 July 2020 at 23:06 said:
After some experimentation, I found that argument order matters with the linker.
The generated Makefile orders the assembler objects after the C sources (OBJECTS=main.o startup_xxx.o).
By putting the objects with weak symbols first (OBJECTS=startup_xxx.o main.o), the linker correctly processes the weak symbols with LTO, and modification to startup_xxx.s is unnecessary.
Paulon 12 July 2020 at 11:11 said:
I’ve seen that also but I did not found how to change this in a convenient way in a CubeMx / Eclipse generated project.
If you have a tips it is welcome to share it.
About the display lcd library:
The problem with those simple libraries is the memory usage by the font, if you only need the letters 'a' and 'z', the whole range a-z needs to be there, and you're stuck with the default fonts unless you try with different programs and formats until finally find the correct one if you get lucky, spending a lot of precious time in the way.
Won't say it again: U8g2 greatly enhances the font memory usage and comes with its own font generator!
UGUI is also a nice library, mainy for touch screens and windows-like interfaces, although it supports the basics too.
But had the same issue, every font had chars 0-255, eating a lot of space, so I modified it with a matching font generator program which allowed any char, any range.
Although mainly intended for color screens, works fine with monochrome screen too, and the library initialization is extremely easy.
You can check it here (https://github.com/deividAlfa/UGUI), some examples here (https://github.com/deividAlfa/ST7789-STM32-uGUI)
-
I sort of agree, however thinking it through I ran into a weird realisation from history.
Look back to the 8bit personal computer days. 240x320 display res, black and white or 4 bit color. Very similar to the displays we are writing for. 8bit CPUs with mangled address buses and barely 32K of addressable RAM. Or 1k-16K RAM with the likes of the ZX81. Very similar levels of hardware to minimal embedded stuff today.
Well, look at what they did. They pushed everything they could into that font bitmap lookup table. GUI elements, graphical niceties, everything. The question is why? What is different? What were they using that we aren't that would explain why?
I'm thinking that most of those platforms had some form of hardware supported display memory and they had at least 16Kb of fast addressable ROM, and plenty of (wasted) power making heat.
How do we replicate that? Modern low power EPROM for bulky data that's easily hardware indexed and maybe even support it with a separate MCU handling just the text->pixel translation with DMA from a "VGA style character based video memory".
I mean if you look at old 1980s "GUIs" and compare them with modern Unix "Slang" or similar console dialog UIs, like the kernel "make menuconfig" interface.... they look similar because they are done the same way. ASCII art and bitmap lookup gfx fonts.
EDIT: Thinking more. In the days prior to 8 bit personal computers, computers were entirely customised to "handing off to a teletype terminal" by ASCII, for display and input. So that's 'where' it comes from. Do we just reproduce that in hardware with an MCU processing as a "VGA text buffer" style addressable display?
-
I may have found a workaround for Cube grabbing focus during a build:
Run it on a second monitor; different to the one you are working on.
The library is capable of changing the clock source at any time, on every condition, that's all.
That is very much the ST way of doing stuff. For each Init function there is a DeInit. First time in 40+ years of embedded I have ever seen stuff like that. Who ever wants to de-init something? Fortunately GCC seems to strip out unused code...
But it can bite you badly; for example in the USB code they have a USB Init and a USB DeInit. If you are diligent you will spot a malloc() in Init and you will think the free() in DeInit will never get called so this is not a problem (malloc is safe if the memory is never freed - a good way to do product options for example). Well... windoze's USB goes to sleep every so often, say once an hour, and then DeInit gets called, so after some days you get a fragmented heap and the system crashes. The fix was to use a static buffer (it is very small; why use the heap??) and then DeInit does nothing with that buffer (obviously).
-
Don't forget today's MCUs are orders of magnitude more versatile and capable than in 1980, so the functions get more complex naturally.
For example, you might have a power failure detection, using some big caps to give enough time to save data safely.
You might want to switch to the internal very low power oscillator and turn off everything except the very essentials.
So the system clock function must support that.
If you work at very low level and you absolutely know what you need, then you can strip out every bit.
But that requires a lot of time, just initializing the all clock/pll bits manually takes a whole afternoon with the datasheet.
And you for sure, **you will** induce a lot of bugs, some easy, some sneaky and hard to find and solve.
The final result will be very much the same unless you run out of space or speed, and often you'll overcome the issue by spending time on optimizing *only** that part.
In any case, spend few cents (Talking before 2020 lol) and you get a better MCU with more speed and storage.
That's the modern way of programming. You're no longer paying $$$ for extra 64KB ram or +10MHz. (Correction: Yeah, going that route again!)
Anyways. It seems the LTO bug in CubeIDE was fixed?
I tried with the STM32 soldering firmware, booted right away, didn't modify the startup file.
Only had some "undefined function blah" errors, fixed by adding "__attribute__((used))" to them.
Some tests:
Optimization Normal LTO
O2 87.19KB 84.71KB
Ofast 93.14KB 103.78KB ???
Os 79.74KB 73.02KB
For the fragmented heap issue, try what I did for the soldering firmware, run this at the boot, at first line of main, so nothing else allocated memory yet.
// Allocate max possible ram, then release it. This fill the heap pool and avoids internal fragmentation due (ST's?) poor malloc implementation.
#define START_ALLOC 256*1024 // This is an aproximate initial value. Will gradually reduce the value until eventually malloc returns a valid pointer.
void malloc_fragmentation_fix(void){
uint32_t *ptr = NULL;
uint32_t try= START_ALLOC;
while(!ptr && try){
ptr = malloc(try);
try-=16;
}
free(ptr);
}
Explaning the issue I had:
[uninitialized pool]->allocate 1, 2, 7KB
[1KB][2KB][7KB]
free those blocks
[1KB free][2KB free][7KB free]
allocate 10KB
[1KB free][2KB free][7KB free][10KB]
free 10KB
[1KB free][2KB free][7KB free][10KB free]
allocate 12KB
[1KB free][2KB free][7KB free][10KB free][12KB]
free 12KB
[1KB free][2KB free][7KB free][10KB free][12KB free]
...
After running that code at boot, malloc sees a giant pool of ex. 100KB, and has no problem stacking and releasing blocks, the said behavior no longer happens.
[100KB free]->allocate 1, 2, 7KB
[1KB][2KB][7KB][90KB free]
free those blocks
[100KB free]->allocate 10KB
[10KB][90KB free]
free 10KB
[100KB free]->allocate 12KB
[12KB][88KB free]
Of course if you only release the 2KB block, you'll be left with that part fragmented, but still will be used by any other smaller allocation.
-
Keeping the heap defragmented in malloc and derivatives in non-trival. It will cost you more memory that it solves in many cases I imagine.
To do so requires you create a linked list of blocks and correctly manage the bi-directional linkage and indexes. Usually by blocks we would mean paging. (The actual linux implementation even includes the option to move pages of memory around, the advantage of paging and virtual addressing and consequative memory becomes an illusion anyway. except maybe in DMA buffers)
I'm going to guess that whomever's implementation of malloc it is, it's going to be optimised a lot and for very small SRAM sizes it probably excludes paging and defragmentation all together. I'd agree with that, if memory fragmentation is enough to worry about, you probably don't have enough RAM to have a generic malloc implementation that would help.
It's one of my constant battles in C/embedded is desperately trying to avoid ANY and ALL dynamic allocation. It's things like random runtime strings, damn char*s everywhere, they get tedious to store and I'm not calling malloc for them! I hate the Arduino JSON library for example because it's got dynamic shit all over it. "I just want to parse a JSON string! I don't want your demo on smart arsed C++ memory allocation and I don't need you to implement the ENTIRE damn JSON spec and use Kb of RAM to do it!" /rant.
-
I'm actually tempted to use the little STMF030F4 as an ARM assembler tutorial vehicle. The STM32 debugger is pretty awesome in the way you can open and mess with registers live. The only other place you get that really (outside of arm hardware debug) is with a chip emulator/simulator.
I doubt there is anything will be learning there that will require more than 16k flash or 4k ram.
I may well start by "bare metalling" it by bringing together MY personal setup and stripping back their "setup*.s" file and removing their libs.
I might keep all of the their constants/defines though, they are nice and handy.
-
For example, you might have a power failure detection, using some big caps to give enough time to save data safely.
You might want to switch to the internal very low power oscillator and turn off everything except the very essentials.
So the system clock function must support that.
True and I have done that here
https://www.eevblog.com/forum/microcontrollers/ideas-for-storing-frequently-updated-data-in-a-flash-chip/msg3913820/#msg3913820 (https://www.eevblog.com/forum/microcontrollers/ideas-for-storing-frequently-updated-data-in-a-flash-chip/msg3913820/#msg3913820)
https://www.eevblog.com/forum/microcontrollers/how-fast-does-st-32f417-enter-standby-mode/msg4063231/#msg4063231 (https://www.eevblog.com/forum/microcontrollers/how-fast-does-st-32f417-enter-standby-mode/msg4063231/#msg4063231)
but I decided it is much better to explicitly stop the stuff which draws a lot of power, than hope the ST DeInit function does it. In fact the biggest single draw was by the LAN8742 ETH PHY chip and that could be stopped only by sending it a special command via the "64 bit USART" which the 32F4 uses to communicate with it. I guess switching to a 32k oscillator is another thing to do but then the CPU runs much slower.
Opinions vary of course but a lot of the time one can get great "low power" result by running at normal speed and shut down most of the time. It is usually very easy to do (even if you put a PMOS FET in VCC :) ) and you can get as "low power" as you like.
-
I'm sure not that many care, but the issues I was having with network drives got worse and worse until I could no longer accept things were working as they should be.
I spent 3 hours this evening, most of my free time tracking it down to a Windows bug applied somewhere in the last year. Not a lot of info on it, I can see it being reported and queried on the MS support forums, but the answer is basically, "Oh, that, don't want to know, that will cost you money to investigate. Sorry. Bye"
The bug is, the Windows SMB client overloads the server by duplicating every single file access block request with a spammed GUEST access request on top of it.
Literally I have megabytes of error log files now with this in them millions of times:
[2022/10/18 20:03:15.804498, 1] ../../source3/smbd/service.c:353(create_connection_session_info)
create_connection_session_info: guest user (from session setup) not permitted to access this share (paul)
[2022/10/18 20:03:15.804532, 1] ../../source3/smbd/service.c:543(make_connection_snum)
create_connection_session_info failed: NT_STATUS_ACCESS_DENIED
Suspiciously and conformationally ... adding
guest user = ok
to my share security config and .... the network drives work fine again.
As a lowly Windows 10 Home user, with about 6 valid MS licenses, I don't think it's worth trying to raise it as a bug. It's windy tomorrow I'll go piss into the wind instead.
Guest access isn't that bad. I already kicked the spyware devices onto the guest network to stop work laptops hacking my file shares and politely giving me access to my porn folder on the work laptop! (True story!)
I even recall adding guest access way, way back to test authentication issues and left it enabled. I had only just disabled it a week ago, when all these issues started to occur.
-
Try NFS, works much better, and W10/11 already includes support for it.
-
Try NFS, works much better, and W10/11 already includes support for it.
Interesting. NFS. Does Windows do the UID mapping or does it require forced mappings on the server side?
It's just that traditionally NFS is a raw block network filesystem and security and access limitation is performed by the client. Which is why it terrifies network admins.
EDIT: I checked. Windows mounts the exports with -o anon. It then sends UID:-2 and GID:-2.
However, as a single user, I can hack the registry entry and have it send my actual Unix ID instead. I think.
I'll see if it works.
-
I did the same to overcome permission issues.
I had a small embedded board as home NAS (Seagate Dockstar), speeds doubled from.25-25 to 45-50MB/s.
The limit was always on the CPU, used a very old armv5 architecture, doubling the RAM and overclocking to 1.5GHz did barely anything.
Sadly It passed away recently, after almost 10 years non stop!
-
I enjoyed reading this, it should be put together and published under title "Is ST Cube a Piece of Buggy Crap", I would buy it and read it lol. :-DD
-
As a starter with STM32 5 months ago, has anyone tried maximum optimization on HAL or LL library, last time I did that (as starter) and it seems to churns out all sorts of error/warning from the complier/linker, so I had to limits optimization to Os.
I have never seen this before compared with Code Composer Studio with C28x and TM4C project which I set to 02, encouraged by TI compiler text.
-
I think optimisations beyond -O1 are likely to break some ST HAL code, because a 168MHz CPU can run code fast enough to break various things like min CS=1 time on various SPI chips.
I build everything with -Og. Possibly switch to -O0 (no optimisation) if, when stepping through code, I see "optimised out" in the debugger and I really want to see that value. Beyond -Og there is negligible improvement in code size.
-
Nah, only if your coding is shame and you don't know how to prevent critical delays from being optimized :-DD
-
As a starter with STM32 5 months ago, has anyone tried maximum optimization on HAL or LL library
The best optimisation is not to use HAL or LL ;)
-
As a starter with STM32 5 months ago, has anyone tried maximum optimization on HAL or LL library, last time I did that (as starter) and it seems to churns out all sorts of error/warning from the complier/linker, so I had to limits optimization to Os.
Yes, I have used up to -O3 without any issue. (Never used auto-generated code though, but the HAL and LL directly in my own code.)
Now let us know what those errors or warnings were. If linking errors for some opt. level, I'd suspect it was a matter of not having enough code memory available on said MCU, so obviously, the higher the opt. level, usually the larger the code size. If you are limited in code size, don't use -O3 or even -O2. I do when I have ample code memory available, but otherwise -Os appears to be a nice compromise.
-
you don't know how to prevent critical delays from being optimized
My own code is just fine; thank you.
I was talking about stuff within ST supplied code.
-
I was messing with you ;)
No idea, never had any issue though, would be strange, are you sure they're not using some directive or volatile tag to prevent optimizations?
-
I remember we had issues when they asked us to compile out stock exchange gateway with -o3.
Compile went mental about all the obfuscated types. Lot of decoupling via void* and char* pointers. GCC went, "I'm not optimizing that!". Pointer frame alignment issues. Unable to optimize on word/address access if a struct has been cast to a char*.
In the end we disabled frame alignment optimisations and spent the next week trying to find the memory leaks which made it seg fault on shutdown.
-
There is no point is playing with optimisation levels IF the product is working correctly.
All you are doing is inviting trouble.
You have to do a potentially huge amount of "regression testing". On a product of any complexity, this is impossible.
-
You have to do a potentially huge amount of "regression testing". On a product of any complexity, this is impossible.
Not impossible if you automate it and run at nights/weekends.
This is even necessary for each new fw release imo, because each code change could break functionality. Sunny day scenarios and 30% rainy day scenarios testing is standard practice in the last three companies I worked for. Tests are expanded for the new added functionality but also for any bug found in the field (which triggers an internal process to find the cause of the bug and how to prevent this in the future). In combination with (as far as possible) continuous integration, continuous delivery it is essential that each release is tested.
-
You have to do a potentially huge amount of "regression testing". On a product of any complexity, this is impossible.
Not impossible if you automate it and run at nights/weekends.
This is even necessary for each new fw release imo, because each code change could break functionality. Sunny day scenarios and 30% rainy day scenarios testing is standard practice in the last three companies I worked for. Tests are expanded for the new added functionality but also for any bug found in the field (which triggers an internal process to find the cause of the bug and how to prevent this in the future). In combination with (as far as possible) continuous integration, continuous delivery it is essential that each release is tested.
I don't think automated build/test and CI/CD has a role to play in deeply embedded mcu applications, which is mostly what is discussed on this board.
-
There is no point is playing with optimisation levels IF the product is working correctly.
Turning up the opti level is often a good way of revealing poorly coded parts of the code, revealing latent faults which might have bitten you at some later time (post deployment!).
-
I think optimisations beyond -O1 are likely to break some ST HAL code
Well, if true, that would fit in the realm of "buggy crap"... It seems doubtful to me, though.
There is no point is playing with optimisation levels IF the product is working correctly.
You have to do a potentially huge amount of "regression testing". On a product of any complexity, this is impossible.
All the more reason for doing all of your development work at the top optimization level you have in mind.
I would never do development at -O0, for instance, regardless of whether debugging "works better."
Although this requirement that keeps cropping up that "regression testing" somehow be more complete than the testing of the original code is a personal pet peeve of mine...
-
There is no credible evidence that optimization levels break ST code. The mentioned SPI CS problem is not a real issue. In any case letting libraries control your CS is not a good idea, it is an application-level thing.
-
I have used the STM32 HAL up to -O3 with absolutely no issues. While you may find the HAL bloated, too general and with questionable interfaces, it's written in perfectly standard C as far as I've seen (and checked with analyzers) with no obvious problems detected by major static analyzers.
If there was a suspect there, I would definitely place it either in my own code, or on other third-party libraries with much more dubious code quality than the STM32 HAL.
And optimization bugs (for perfectly valid code) are rare. I've been using various versions of GCC on various targets for a long time now, I've routinely used -O2 and -O3, and only ran into ONE compiler bug over all those years. It was on Aarch64, and it wasn't an optimization bug per se, it was just that GCC wasn"t properly enforcing aligned access only when using the corresponding flag. I reported the bug and it got fixed in the next release.
-
And optimization bugs (for perfectly valid code) are rare.
Well, it's more that "some things common in embedded code" are optimized in unexpected ways, resulting in failures. Delay loops and concurrency/atomicity issues come to mind.
-
If your code breaks because of the optimizer, it certainly means that your code has bugs that would likely break sometime later out in the field, unexpectedly and likely in a hard-to-reproduce fashion. I would much rather trust gcc to optimize correctly rather than trust one's own code, or one's dependencies' code, to not have subtle bugs. If anything, I would expect one to use -O3 to try to work out the bugs now, rather than to be bitten by them later.
About the STM32 HAL, I personally have not been impressed by what I have seen in them, but if it has bugs that would be elicited by optimization, I somehow bet people would have been bitten by them already.
-
Another "feature" which crept in around v10:
(https://peter-ftp.co.uk/screenshots/202211070116170914.jpg)
It shows a negative value where shown. Rebuilding a few times gets rid of it. It doesn't seem to actually stop anything working.
-
If your code breaks because of the optimizer, it certainly means that your code has bugs that would likely break sometime later out in the field, unexpectedly and likely in a hard-to-reproduce fashion.
This, this and this. And because of this, "do not change optimization settings so that you don't need to run regression testing" is bullshit. Opposite is true: you could compile the code with all possible optimization settings and run regression testing for each just to give more opportunity for bugs to stand out!
I'm never afraid of changing compiler settings or even updating to different compiler version, because that is always an opportunity to reveal my own mistakes, and get them fixed. (Choosing to use external broken code, or choosing to work in a socially broken project where bugs cannot be fixed are also examples of something to be considered my own mistakes.)
-
And optimization bugs (for perfectly valid code) are rare.
Well, it's more that "some things common in embedded code" are optimized in unexpected ways, resulting in failures. Delay loops and concurrency/atomicity issues come to mind.
Which all would be signs of wrong assumptions, thus misuse of C.
Now if it's in third-party code, as I said earlier, it may look beyond your control, except that your choice of libraries IS within your control. And again for the record, I've never personally encountered such code in STM libraries. If there is, I'd be curious to see it.
As several of us already said, any code that breaks with optimizations is, in most cases, a catastrophe lurking, just waiting to rear its ugly head at some point and bite you severely.
-
To date, all optimization bugs were caused by me. Once all were cleared up, I've neved experienced any HAL bug caused by optimization.
But it's HAL, will aways have bugs, for example, with DMA and Timers (https://community.st.com/s/question/0D53W00001XOOTRSA5/timer-dma-cubemx-inits-timer-and-dma-stream-in-haltimbasemspinit-before-dma-peripheral).
Really easy to solve, simply init DMA first, but any touch in CubeMX will recreate the bug again.
As you can see, the answer was "It's been there for years, learn to program yourself".
Translation:
"Hey, don't come here trying to change our traditions!"
-
Apparently, the problem you gave a link to is a CubeMX generation "bug", not a bug with the HAL itself. (Or you may consider that the HAL init functions themselves should check that stuff, which would make them even more bloated than they already are.)
Do not confuse the HAL with the CubeMX IDE. The CubeMX IDE definitely has bugs, the HAL itself, very few IME. And I've used the HAL without the IDE. It's not rocket science.
-
To me the wisdom of relying on an IDE to do one's code generation is highly questionable, at least from my experience of working with Java IDE's in my day job. They seem to be designed for people who could not program their way out of a wet paper bag, and generally produce brittle code that is difficult to edit manually at best (e.g. many a GUI editor will produce absolutely godawful code that is impossible to work with) and breaks if one looks at it the wrong way at worst (even though I found IntelliJ to produce okay code when automating very simple but time-consuming tasks like generating large numbers of Java accessors).
-
Another "feature" which crept in around v10:
(https://peter-ftp.co.uk/screenshots/202211070116170914.jpg)
It shows a negative value where shown. Rebuilding a few times gets rid of it. It doesn't seem to actually stop anything working.
The number shown looks correct.
If the boot memory is 32 kB and 69 kB are used, well, you have a 37 kB debt!
Check the linker scripts and memory size definition if that does not match reality.
-
I wrote above
Rebuilding a few times gets rid of it.
-
I wrote above
Rebuilding a few times gets rid of it.
Yes, but I had read that - and it just makes the fact more worrying.
To me it's still a red flag that something is not proper in that area - the tooling should be deterministic. Same code same output.
I'll be blunt: this is just one more of the many red flags that you have shared in time, and they make that whole codebase and tooling look extremely fragile to me.
-
or even updating to different compiler version, because that is always an opportunity to reveal my own mistakes, and get them fixed.
sizeof sample == 1, take it FWIW:
On a personal project I updated to clang 15 from 13.
I got a new warning (I have a couple coming from the SDK I use - none from my -Wall -Wextra -pedantic code), about returning the wrong kind of enum from a function.
It was inconsequential, given the enum-is-an-integer-with-a-fancy-name thing and the ranges in play, but it highlighted a place where I had a badly designed interface.
-
the tooling should be deterministic
Yes, but read further back up this thread, about the Build Analyser not appearing at all until the .map file is clicked (usually that works, but not always).
AFAICT this is another Cube thing. Doing a build only (control-b) has this issue in Cube v10 but doing a Debug build (F11) produces the correct output, even though the compiler and linker etc steps are identical (I build only in what Cube calls Debug, not Release).
-
Personally, I would just avoid IDE's when in doubt, which is definitely the case here with what you have been seeing out of CubeMX. (I do admit to using Visual Studio at my current day job, but I really use it just as essentially a text editor with built-in syntax formatting and highlighting, and while I have used a number of Java IDE's at past jobs, the only one that seemed to be of any real quality was IntelliJ (Eclipse in particular was painful to work with), and even that was painful to build new projects from scratch under.)
-
I had the phantom break point that wont go away tonight. Happened right after it told me I had too many. I removed a few, that "fixed" it but wherever I put the break point in the *_tim.c file it always breaked at a completely different line that I had breakpointed half an hour ago!
Restart eclipse didn't work. Unplug/replug the STMLink and restart eclipse didn't fix it either.
Also, more of a rant about HAL and STM32's documentation of same. It's insane. I spend 3 long hours tonight trying to get DMA->PWM timer output to work.
* There are ALWAYS twice as many options in the dialog as any documentation tells you about.
* The version you have ALWAYS has a different set of criteria on options.
* Your timer doesn't have the setting the tutorial wants.
* You set it up EXACTLY as per a dozen tutorial, 40 mins in the datasheet and re-re-reading the documentation and... it doesn't work.
* Most of this is because... there are so, so many options which more tutorials and documentation simply forgets to mention.
In the end I got it working, but my god it's confusing as hell compared to the lies the docs and tutorials tell you. For example, "arbitarily select your DMA word size", like it means nothing.
The CCR register is a 32 register that takes a 16 bit value. Ok. However if you feed it from an array of 32bit ints, you get different behaviour if you feed with 16bit ints. 8 bit ints don't work.
Worse yet. If you DMA transfer to the CCR register byte by byte, it goes nuts. If you transfer to it in half words it works, if you transfer to it in 32bit full words, it runs at half speed. WTF?
Also, if you are using one set of word widths for storaging and DMA transfer, then you duty cycle values will change if you change any of them, even while the frequency remains the same.
I got it working, but I feel like I've been dragged through a hedge and I don't quite understand what the hell was actually going on and the documentation and tutorial did sod all to help!
I've decide to move on and pretend it didn't happen.
To end on a funny note. The last 30 mins were spent staring at a coil of Chrismas LED WS2811s ... all cyan and grumbling at the scope going "THAT RIGHT!!! 800kHz 4uS off 8uS on. There is nothing wrong! WHY you no WORK?"
Well, the penny dropped. It was working. It was working extremely well. To the tune of well over 100 "frames" per second... which is why all the animated christmas colour animations looked Cyan... that and I had my RGB backwards :D
-
The CCR register is a 32 register that takes a 16 bit value. Ok. However if you feed it from an array of 32bit ints, you get different behaviour if you feed with 16bit ints. 8 bit ints don't work.
Worse yet. If you DMA transfer to the CCR register byte by byte, it goes nuts. If you transfer to it in half words it works, if you transfer to it in 32bit full words, it runs at half speed. WTF?
Don't know which STM32 you are using, but from several RMs, when timer registers are described one can read this:
The peripheral registers must be written by half-words (16 bits) or words (32 bits). Read accesses can be done by bytes (8 bits), half-word (16 bits) or words (32 bits)
So, no, 8 bits writes are not allowed.
-
I had the phantom break point that wont go away tonight.
Cube has always had this issue. You can set a breakpoint anywhere
(https://peter-ftp.co.uk/screenshots/202211094216181909.jpg)
In a comment (above), on code which is #ifdef'd out, on code (this one got me a few times) which is stripped out. I had one case where I set a bp on a callback function. The bp was never taken. It took me ages to discover that the callback code wasn't there at all, because the module which was calling it wasn't there, and it wasn't there because nothing was calling it anymore (which itself was very subtle and deep down).
If I was writing this tool, I would have a post-build step checking that any breakpoints are set on actual binary code. And each time a new bp is set, re-check that. Enabling bps to be set on any line regardless of what is there is just so completely dumb.
Then you get stupid issues like if you delete a line above, the code shifts up a line, but the bp stays put (not always though).
It's a lot better than nothing, but it is a hack.
-
The CCR register is a 32 register that takes a 16 bit value. Ok. However if you feed it from an array of 32bit ints, you get different behaviour if you feed with 16bit ints. 8 bit ints don't work.
Worse yet. If you DMA transfer to the CCR register byte by byte, it goes nuts. If you transfer to it in half words it works, if you transfer to it in 32bit full words, it runs at half speed. WTF?
Don't know which STM32 you are using, but from several RMs, when timer registers are described one can read this:
The peripheral registers must be written by half-words (16 bits) or words (32 bits). Read accesses can be done by bytes (8 bits), half-word (16 bits) or words (32 bits)
So, no, 8 bits writes are not allowed.
That much was apparent. I suppose I should dig in and find out how it behaves when you send it as half words or full words, especially when it contains 16 bit ints.
I'm still a little baffled, as in my normal day world of very strong types I dont have 8 bit ints masquerading as 32 bit ones or vice versa, but I do in STM C.
To explain.
My PWM "period" is 90 OCC cycles for 800kHz with a 72Mhz clock. (ARR=90) <--- Or is it? Sometimes the bus clock is 50% OCC.
My PWM duty cycles are 33% (30) or 67% (61) CCR is fed by DMA.
Normally / ideally those numbers 30, 67 fit into uint8_t to save memory. However knowing that the CCR register takes 16 bit values I decided to use uint16_t to store them. Great so far.
However the DMA transfer function takes a uint32_t* for it's data to send and an ambiguous parameter, "Length". Note, not Size, but Length. I believe I have even seen it referred to as "The number of items to send"... what are items?
Now my figuring is, if I have 2400 uint16_t values I should be passing the Length 2400/2 for 32bit pointers. However I am no longer entirely sure this is correct as to how it behaves.
So now the seed of doubt is planted we come to the DMA configuration itself. It allows byte, half word, full word. Tutorials, as I said, always just shrug and say it doesn't matter, pick half word as it's the default. Turns out it does absolutely matter.
The annoying thing is, it's so slippery and ambiguous. So, so many blind explicit casts of datatypes and pointers there is no protection at all from weird alignment disorders.
Maybe more RTFM and more investigations will make it clearer to me, but for a newbie to STM world it's always this kind of stuff that gets really confusing, really fast and wastes hours and hours on abiguity. I figure reading the entire 300+ page reference manual will help... however having been down that route in Application Notes for PCB layout, it's the SAME SHIT. The notes are stacked and apply to a dozen different MCUs ALL with DIFFERENT aspects. It makes the App Notes and Reference manuals really difficult to track. "The ABC is enabled (F0-only) when the F4 would enable it's DEF, unless you need the RRT of the F4 then ...." etc. "The widget can be used (except in F1) when the CCF1 register (Not available on all packages) is high...."
For now I am assuming... to retain sanity...
I store 16bit CCR register values in a 16bit uint array.
I send Half words, aka 16bit words to the CCR register via DMA
When I sent the array as a 32bit uint pointer, I halve the length.
If I leave all of that alone, my frequency and duty cycle values should remain non-insane.
Anyway, now that I got that working, todays "It's quiet in work" is trying to get the F030 to animate 100 WS2812s. The F1 was too easy. Note 100 LEDs will more than fill the memory twice on the F030F4. I only moved to an F1 because I wanted to stop dealing with heap and stack crashes until I got the LEDs at least working. I've been tempted to just ASM bit bang them. It's not like there will be much left of the F030F4 to do anything else while the DMA is transfering.
EDIT:
ld.exe: region `RAM' overflowed by 56 bytes
Hmmmm..... what needs to go.
-
However the DMA transfer function takes a uint32_t* for it's data to send and an ambiguous parameter, "Length". Note, not Size, but Length. I believe I have even seen it referred to as "The number of items to send"... what are items?
AFAICS (F0 HAL drivers), the HAL uses uint32_t, not uint32_t * for is source and destination addresses.
As much as I'd conceptually preferred void *, uint32_t reflects the base type of the destination DMA registers - no ambiguity here.
The length parameter is the number of items to be transferred, the size dictated by the DMA setup- it goes straight into the CNDTR DMA register.
Also note that in general you have to load one less than the count value in timer register (e.g. period 90 clock cycles -> register = 89).
Not sure STM32CubeMX (or equivalent in STM32CubeIDE) will do that for you - check the generated code.
EtA: Moving an array of uint8_t to the lower 8 bits of a 16 (or32) bit wide destination is of course possible, check the 2nd row of the table in chapter "10.3.4 Programmable data width, data alignment and endians" of the RM.
-
Exactly. Check the DMA size: byte, half-word (16bit) and word (32bit).
So the dma engine accounts for number of transfers, no size.
DMA functions works for any size, DMA can access any data, so simply recast the pointer.
Anyways using PWM and 16-bit values to transfer a single bit it's *crazy* inefficient!
You should know the timing already:
(https://cpldcpu.files.wordpress.com/2014/01/ws2812_timing_table.png)
With that, you can use the SPI running at 3MHz and reduce memory by a factor of 8.
To send a "1" transfer "110" (666ns high, 333ns low)
To send a "0", transfer "100"(333ns high, 666ns low)
So a single byte will pack 2 & 2/3 bits, one sub-pixel will use 3 bytes, and 9 bytes for a complete transfer, not 48!
r0 r1 r2 r2 r3 r4 r5 r5 r6 r7
{000.000.00} {0.000.000.0} {00.000.000}
g0 g1 g2 g2 g3 g4 g5 g5 g6 g7
{000.000.00} {0.000.000.0} {00.000.000}
b0 b1 b2 b2 b3 b4 b5 b5 b6 b7
{000.000.00} {0.000.000.0} {00.000.000}
Edit: Simply send reset signal (>50us) by sending 18 zeroed bytes (Or few more to be sure), so your structure will have:
DATA (900Bytes) RESET (18Bytes)
{ 100* RRRGGGBBB } { 18* 0x0 }
It'll go from 100x48=4800 bytes to just 100*9=900bytes! (918 bytes with reset)
You were sending 20 LED at a time (960bytes), so it'll fit perfectly.
-
On the topic of STM32CubeIDE and weird breakpoint behaviour.
I had a couple of occurrences of this last night. Scenarios were I had an if condition like (txHead!=txTail). The step over never visited that line, it jumped straight into the else clause.
It then occured to me that most ARM instructions can be conditional. So comparing 2 volatiles and jumping to the else label was probably done in the single instruction. Maybe the eclipse / gdb setup can't work that out when there are less ASM instructions than there are lines of code.
-
Yes I have seen that too.
-
I hope you're not using any kind of optimization when debugging...
-
A tip for using Eclipse. This featured saved my work!
Yesterday, having hit a small milestone in a project I decided to move it "back to the git repo". I had previously recreated the project for a different MCU.
I set about rm'ing everything in the git repo. Copying the contents of the project from workspace. Adding, commiting and pushing all the changes to git.
It was only when I went back to eclipse, right clicked the project to remove all trace from disk and re-import from the git repo... did I notice the project path.... was already the one in the git repo.... or at least it was.
A long, "Did I just...", pause followed. Until, I broke it slowly to myself that, yes, yes indeed, I had just deleted a weeks work. Checked the git log and, yep, the last commit was a week ago.
All gone. The whole display driver I wrote, all the bug fixes, the start of message parsing. All gone.
I checked the backups, but, no, they are only backing up the git repo, the live files are on the Windows VM unbacked. So I rolled the git change back again and sat sadly looking at the work from a week ago.
It was then that I noticed Eclipse had one of it's "Local History" tabs open and is was showing history for the last 3 days. "No! Could I get this lucky?"
Yes indeed I could! I was able to not only restore the versions I had saved only a an hour ago, but I could restore entirely deleted files. Took me a careful 20 minutes to restore the deleted project entirely in Eclipse. The windows recovery task I had started hadn't found a single deleted file in that time, so I stopped it.
The trick is... you can right click a folder in a project and select "Restore from local history" and it will show all the files it's aware of that have been deleted. Once you have all the files back, you can then just go through each one and select the "latest" from it's local history. "Replace with ...." "Local history.." even shows you a diff editor while you pick one.
-
That's clever :)
I work in a strange way: a master copy of my project lives at home and a copy of it lives at the office. The office copy is a "throwaway" copy on which I can test various things. The home copy gets backed up whole (whole 200MB, not diffs or using any VCS) to a network drive daily, and there is an automatic backup at 3am which goes somewhere else.
I found that if I delete any files while Cube is running, Cube gets into a right mess, because it detects them going missing within a second or two. I think there is a config for that somewhere. So if you've been doing external editing, you should exit Cube when pushing any updates back to your project.
-
Use GitHub, set the project to private! Relying on local storage is silly!
-
Your tools make me sad.
-
Yesterday, having hit a small milestone in a project I decided to move it "back to the git repo". I had previously recreated the project for a different MCU.
Why do you work like this? Like, isn't this totally counter-intuitive and making your life extra hard, even if you don't make such goofs? Copying files once few weeks, then trying to retrospectively make commits? Really, why?
Just use git as intended, i.e., work with the working tree, do frequent commits, with at least somewhat descriptive messages. Every time you compile and test some kind of feature, at very least then do a commit:
git commit -a -m "UI cleaned up"
git add pixel.c
git commit -a "pixel update function works faster now"
git add adc.c
git commit -a "ADC calibration"
git push
git add important_header.h
git commit -a -m "oh forgot a file sorry bout that"
git push
git commit -a -m "didnt feel like committing today so sorry about full days of changes not documented separately here (still better than two weeks of work)"
git push
You get the point? Not optimum use of git, but at least something remotely sane No need to learn advanced usage, and for one-person projects, working with one master branch is fine, but at least do the commits. And don't do utterly stupid things like develop elsewhere and copy files over and retrospectively try to make it look like you tried to version control them.
-
Thank you very much. I do know how to use git. When you tell me how to create a project outside of the STMCubeIDE workspace, that would help.
The only reason it was OUT of git was because I needed to recreate it. Yes, I could have (did) hack the IOC file to the new MCU, but I didn't trust it.
I don't mix git and workspace. The workspace is only on a local drive because CubIDE doesn't like network drives, other wise the whole dev folder would be backed up nightly. Projects that life beyond the first few hurdles, get extracted out of the Eclipse workspace and put into git.
Git is local git. Local git and the whole network ~/devel/ folder (along with my photos and other memorability) are rsynced to a RAID0 pair nightly, which is OFFLINE unmounted all other times. Every few months, I put an other 2 Tb drive in there and take another copy, plan was for that one to live elsewhere as a fire safe. It's not made it further than downstairs!
I also have an S3 backup, but, I'm already over the free teir. I have a tendency to dislike any cloud service, file service etc. They tend to come and go. AWS at least gives me raw access and should be around a while.
Note that github and gitlab both, I may be wrong, but have restrictions on what percentage of your projects are open source. Make them all closed source, private and I believe at least gitlab charges you?
Beyond anything else, they are personal projects, I take liberties I can't in work with personal projects, because I can :)
-
There is a simple solution: create a bare (*) git repository (with shared group rights) that is on your network drive. Everytime you push, git copies your work from the Eclipse work directory onto the network drive. Added bonus is that you can clone that repository onto different computers as well. I have organised most of my projects that way. Sometimes even with multiple remotes so I can push into customer's git repositories directly. This makes sure I can never make a mistake with deleting files etc from projects that causes me to lose work.
* A bare git repository is a 'special' git repository which is for archival and sharing purposes. Not to checkout / work from.
-
Using a version control system is a good idea, even for relatively small projects. I personally do prefer mercurial for this. For people finding git intimidating or with annoying quirks, that's worth a look.
Now once you use a VCS, if you are a lone developer, it can of course be all in local repos, that you can back up on a regular basis. No problem with that. (It seems like people increasingly believe they can't back up their own data, but they sure can.) You can alternatively use local repos and "server" repos on a machine in your LAN.
I really recommend staying away from "cloud" services as much as you possibly can, especially if you don't need to share development with remote people. If you do, then of course it's a completely different matter. But even so, unless you absolutely want/need a worldwide audience, you can set up your VCS on a server using Linode or similar instead of relying on github or the like. It's not free, but not that expensive.
This doesn't appear to be a very popular option, but I don't really care about that. I'll never fail to suggest options to make people more independent. You can of course do whatever you want.
-
For reasons I leave out. I do not mix git/project files and IDE workspaces. The only thing that stays in the actual workspace are "scrap book" projects. Even when I started using the Arduino I got my files out of there and symlinked things to fix it up.
Ideally, everything should be under the one (logical) folder, including the local git repos and just accessed from any machine without spreading files around.
Yes, using git religiously, committing and pushing on every session means you can check it out else where and work on it. Which is fine, though a bit of overhead. You also need to be careful you DO commit or you can end up doing your own made merge hell.
-
I started a VCS thread a long time ago and soon there were as many opinions as posters :)
I understand the reasons for a VCS but utimately it just moves the decision on where to backup the whole thing. I backup the whole project each time and to different locations. With a VCS you have to backup the whole "database" at the same frequency if you want the same "safety".
-
VCS includes all the history.
-
Sure; you can retrieve v1.23, v1.22, v1.21, etc. The database is incremental and it sorts it all out. I first used this in the 1980s. But for myself now, I have no use for it, any "cloud" database has to be considered as totally insecure, so what's the point.
-
A bit of an over simplification on the versions.
Also... git is not a cloud service. git is not a server. There is no service. its the same command on both ends. "Remote" git is just an SSH shell with the right key and group perms for the repo. So you can create one locally just by creating an empty repo and giving yourself SSH access to it.
-
A bit of an over simplification on the versions.
Also... git is not a cloud service. git is not a server. There is no service. its the same command on both ends. "Remote" git is just an SSH shell with the right key and group perms for the repo. So you can create one locally just by creating an empty repo and giving yourself SSH access to it.
That is even too complicated. A git remote can be as simple as a directory.
-
I started a VCS thread a long time ago and soon there were as many opinions as posters :)
I understand the reasons for a VCS but utimately it just moves the decision on where to backup the whole thing. I backup the whole project each time and to different locations. With a VCS you have to backup the whole "database" at the same frequency if you want the same "safety".
You make a decent point, but you don't need to have all your projects on the same "database". Actually they'd each have their own repo that you can back up individually.
There is no "single database" with all your repos in most distributed VCS. Each repo is its own "database".
Now if you put all your projects in the same base repo, which would be a big mess, then that would be a problem. But you shouldn't do that anyway.
-
Obviously in a team environment some form of VCS is critical. However I find amateurs often see it as a burden too far. I myself have a limit before which projects do not go into git or any VCS. I just leave them, usually, in a bulk nightly backed up folder. It's only recently I've had issues with network drives and IDEs from VMs.
Anyway. Reasons for hobbyists/amateurs...
You have the history of all committed changes.
You can rollback/forward individual files or just reference files from the past. (I know I had this working last week!)
You can easily migrate the project to a cloud service if you wish to.
Probably the biggest driver for me and when most of my hobby projects get moved to git.... when I want to try a new direction or try adding a new feature that will require refactoring. I can take a branch. I can make hell in that branch and completely break the code for weeks, however, I always have the working branch to return to. This is very useful if you happen to be using the code day to day is a kinda-production setting, but still want to develop possibly breaking changes.
Even without branching you can just remember a point in time when you had it all working, tested and where happy with the known bugs. You tear on breaking the code adding new features. At any time, you can simply "checkout" that point in time and deploy working code even if your current working folder or branch (even master~HEAD) is completely trashed.
There are at least 2 copies of your project.
Reasons not to use VCS/Git.
It can be an admin overhead. If you don't keep it up and let code and repo depart significantly whle you have open branches and unpushed code etc... you can get yourself in a bit of a tangle that might be off putting to solve. I know the first dozen trashed git repos I've had to fix were very off putting, but you learn by your mistakes in hobby land, in work it's often learning the hardware after someone elses mistake.
-
Obviously in a team environment some form of VCS is critical. However I find amateurs often see it as a burden too far.
For team projects, definitely.
For me, I don't really see the point. My biggest concern has always been security, in the sense of losing data. And data loss can be produced by accident. One keystroke is all that is often needed. And with Cube popping up random files during a build (and these absorb any keystrokes at the time, because each one grabs the windows focus) this is a real risk.
I do have others working on the project but only on separate modules which can be plugged-in.
I want to keep my life simple :)
-
Anyway. Reasons for hobbyists/amateurs...
You have the history of all committed changes.
You can rollback/forward individual files or just reference files from the past. (I know I had this working last week!)
You can easily migrate the project to a cloud service if you wish to.
You can experiment a lot using branches, and keep all the experiments while choosing one.
You can easily develop, even as a lone hobbyist, in different sites (if you use a cloud service, or have other ways - I use a home run instance of Gitea) as I often do across SE and IT.
It can be an admin overhead. If you don't keep it up and let code and repo depart significantly
Committing It's just a couple of clicks away in most decent IDEs, as is synchronizing with a remote (which can be a local dir, as already pointed out).
Is that really more admin overhead than copying around stuff and keeping track of what goes where and which version is that?
My terminal laziness says it isn't.
-
For me, I don't really see the point. My biggest concern has always been security, in the sense of losing data. And data loss can be produced by accident. One keystroke is all that is often needed. And with Cube popping up random files during a build (and these absorb any keystrokes at the time, because each one grabs the windows focus) this is a real risk.
This is exactly one of the things git/vcs saves you from. You can immediately ask it what is different and ask it to undo whatever you want.
When you have VCS you don't have just one copy of files, you have several. You can rm -fr the whole folder and restore it in seconds... as long you have up to date commits.
-
What I don't get is why a VCS is not integrated into Cube.
-
It is.
Right click-> "Team"-> Share project...
-
It is.
Right click-> "Team"-> Share project...
Well, you need to install the right 'collaboration' plugin first (there are several different version control systems) but this is pretty simple to do. After that you'll have a nicely integrated version control system.
As I wrote before: I have everything in version control (preferably git). It is a huge help for trying things but also to check whether things went right after restructuring code. What is nice about Eclipse (Cube) is that you can compare the files you are working with, with any previous version. So if something has stopped working, you can easely check where you messed up.
-
you can compare the files you are working with, with any previous version
There is another way to do this which I saw working but never tried it myself: set up another project and then you can do a "diff" graphically.
I avoid multiple projects in Cube because it is easy to get into a mess, with some config applying to all of them.
-
Well, you need to install the right 'collaboration' plugin first (there are several different version control systems) but this is pretty simple to do. After that you'll have a nicely integrated version control system.
I just checked and it is a disappointment that the Cube eclipse does not come with git as standard. Pretty much every other one does.
-
What is nice about Eclipse (Cube) is that you can compare the files you are working with, with any previous version.
I honestly find Eclipse git plugin to be baroque, bloated, and incomprehensible, but that's just me and Eclipse == water and oil.
The same is of course possible with other IDEs, e.g. any git plugin supports it in VS Code.
In the one I use (Gitgraph) you can click on any commit (or the uncommited changes line) and ctrl-click on any other to get all the files changed between the two (and of course open them in a nice diff editor).
-
and right away we are into complexity :)
Just like always.
For experts this is all simple.
I just backup the whole project. Not just the source code.
-
There is a learning curve, but once you're over that, and really start using it, you regret not tackling it sooner.
As I understand it, peter is developing an STM32 app which will be delivered to clients in source code form.
I can't imagine trying to manage that over the years ahead without using a VCS.
-
There is a learning curve, but once you're over that, and really start using it, you regret not tackling it sooner.
I agree. A long time ago I just to work with a guy that was hell bound on not using version control. On top of that he never kept copies of old versions. So when there was a bug in the software in the field (which is always the case), customers would need to wait for months until the new version got finished which -hopefully- didn't had too many new bugs. We almost litterally had to twist his arm to get him to use version control.
But yes, there is a learning curve. So far I have used subversion and git and I must say I like git better (partly because it doesn't need a server).
-
developing an STM32 app which will be delivered to clients in source code form.
Not really. They will be able to write some modules. I will supply them with a bare Cube kit, which compiles something like hello.c.
If one of these wants to use a VCS, they can. Nothing whatever to do with me :)
But I definitely don't want to support anything complicated like that. I will support them building hello.c and will support the API for accessing other product features. I will not support Cube and its 10000000 config options. That's simply impossible.
Also you have to think into the future. Cube, if you download it from ST, will change over time. It is impossible to support that. In reality I will try, but ultimately there may come a point where one has to say to a customer "this product builds with Cube v10.1.0, and you can find the 1GB installer at this URL".
I have another vaguely similar product running since 1995. It sold in large numbers, and still does to people who did their own code years ago, but the development environment - a HiTech H8/300 C compiler for which I bought a large quantity of reseller licenses, before Clyde Smith-Stubbs sold out to Microchip, who I see have now dropped those compilers anyway - now needs either DOS or a winXP DOS box, or (under win7+) a winXP VM, so this gets a bit ridiculous. But ultimately a VM with a complete dev kit inside it is the way sometimes. Unless VMWARE vanish (unlikely) or there is no VMWARE Player available for Windows v123.5 (unlikely) this will always run. There are VMs which give you DOS, win3.11, you name it, and they still run today.
he never kept copies of old versions.
That's dumb.
-
On the complexities and experts ... I agree. I have battles about it in work periodically. There are VCS experts who want to immediately deploy all the bells, whistles and advanced practices. I mean these people exist in every engineering domain (I'm sure). They are just those who engineer for engineerings sake. Either that or they have learnt to do it one way and only one way and so they drive the project towards their comfort zone. That or they just want to take dominance and control over an aspect of the project they want control over.
Not based on practical need. Asking on the internet for opinions and you'll get a million and 1. Even start a basic, "First steps, help" in the beginner section on here will derail into detailed arguments over irrelevant details by pedants.
Keep it simple. Don't do anything which means you lose cognitive control over it. If a propoent of a particular advanced (or even intermediate) technique tries to force a pattern on you push back until you understand it well enough to give them a definitive "No" or "Yes".
Read the basic official how-to, getting started. Then google to find other variants in tutorials. Just the basics. I highly recommend starting with the command line unless you are completely adverse to that interface. When a GUI goes nuts and produces non-sense errors, the command line will still always be there to fix things.
I would actually suggest starting with (even a burner) GitHub or GitLab account. Pointy-clicky-draggy-droppy yourself a repo on their site.
All you need to be able to do initially, is...
clone that repo locally.
copy your source code into it.
add and commit all of it.
push it.
Go elsewhere, clone it etc.
Realise you made a mess, committed a bunch of binaries in the Debug and build folders.... Delete the whole thing, repeat.
Everything else is learning curve, but the above provides benefits immediately.
When you are happy you are comfortable. Switch the actual project IDEs over to point into the local repo. Add the git plugin to the IDEs. Start maintaining the git repo with care and proper hygene and it will save your arse on so many occasions.
When people start babbling at you about forks and recursive rebasing of releases, switch off. None of it is needed until it is and if and when it is, you can learn then if you need those features.
I have lived through several iterations of "experts" enforcing overly complicated VCS structures only to see them degrade into chaos because only the experts who demanded it understood what was trying to be achieved. One example was a team who thought every developer should have his own fork of the entire project and work on that through a sprint in isolation. Then after the sprint and testing they would have a big merge-athon to bring all the forks together into a "Golden repo". It lasted a year before it had blown up on them one too many times.
In other parallel developments the company switched to using BitBucket with integrated Jira.... which out of the box supported a much simplier, easier to understand and far more robust branching model. I felt somewhat vindicated when most teams moved to adapting that, whlie our team just had to add "feature/" and "release/" to our existing model for full integration. KISS!
-
ead the basic official how-to, getting started. Then google to find other variants in tutorials. Just the basics. I highly recommend starting with the command line unless you are completely adverse to that interface. When a GUI goes nuts and produces non-sense errors, the command line will still always be there to fix things.
A word of warning: be careful in what you google, there is a lot of over-complex advice around.
If you find yourself in pinch do as paulca suggest: nuke it and restart.
If you follow some of those "repair" advice, you'll find yourself in situations impossible to get out from, without understanding how you got there. git is a sharp knife, it can do wonderful things, but you should keep your fingers far from the blade until you master it (I can now barely put mine on the dull side of the blade).
This is a resource that I found both funny and clear enough: Oh my git (https://ohmygit.org/), it helped some people who were allergic to VCS in general, and git in particular. It's a gamified git course, but it uses the real thing.
And of course the basic resource to start with is the book (https://git-scm.com/book/en/v2).
Then you can move onto the full online documentation (https://git-man-page-generator.lokaltog.net) :D.
But I have this nagging déjà vu feeling, as if I (and many others) had already wrote the same previously (https://www.eevblog.com/forum/microcontrollers/is-st-cube-ide-a-piece-of-buggy-crap/msg3618280/#msg3618280)...to very scarce effect, AFAICS :-//
-
My setup (really small team): git (new projects), svn (legacy projects).
Remote development server with RAID 1 mirroring.
Periodic "git bundle" backups onto a removable storage.
I like bundles, because they can be used in the same way as any remote repository.
-
This is a funny one
(https://peter-ftp.co.uk/screenshots/202211274616243816.jpg)
Using /* */ instead worked, after after that the original // worked also in that no more warnings get generated, but the little icon to the left of the "81" won't go away :)
-
It says "printf_", you commented "printf".
-
... no more warnings get generated, but the little icon to the left of the "81" won't go away :)
Remove the trailing semicolon. Don't know about Cube, but this tricks SonarCloud (https://www.sonarsource.com/products/sonarcloud/).
-
Nope...
(https://peter-ftp.co.uk/screenshots/202211271216255022.jpg)
It says "printf_", you commented "printf".
That I don't get either because it clearly refers to line 81, and the printf_ is in the declaration of printf.
(https://peter-ftp.co.uk/screenshots/202211274816265422.jpg)
-
That issue exists on one Cube installation but not another. It also isn't linked to the file; Cube clearly keeps the locations of these markers elsewhere (well obviously, as .c files are just plain text).
V1.11.0 is out now. I uninstalled the old one, installed new, rebuilt the project, and the end result matches with the same CRC. So they haven't changed any of the tools. The version description doesn't mention that, either.
Will be interesting if any bugs have been fixed. Nothing listed in the release note DM00603738.pdf.
-
What a horrible idea to redefine standard library functions and replace them with functions that do something else.
If you want to use a "tiny_print" then just call it "tiny_print" and be done with it.
I can even understand adding in a macro that throws an error if printf is ever used on a memory constrained system, but your kind of obfuscation is simply a bad idea.
-
That printf is almost identical to the "classic 1990" printf which is just bloatware, using bignums to implement that "perfect IEEE float" stuff from the 1980s. Various threads on that.
It isn't an integer-only printf or some such.
-
HAL is great for the start, I mean, coming from much more simpler Pic/Avr, you'll get completely blown away by the endless registers, bits...
After some weeks/months doing stuff, analyzing the generated code, the HAL libraries, all the gears in your brain will slowly start spinning again.
Then switching to LL is much easier.
Still takes a considerable amount of work if you have a lot of code interfacing the hardware, but gets done eventually.
The savings vs time invested depends on your application, if you had to take a more expensive stm32 due running out of space and you're buying 1000s of them, might well deserve the effort, specially nowadays when the same thing with extra 128K flash might cost easily 2x, 3x more because it's hard to source.
Otherwise, it's not a miracle either, removing the HAL handlers and the bloat might save 20-30%, but it's not LZMA :-DD
I've been practicing LL by porting the soldering firmware, not yet done, but getting there.
As always with ST, there's a lot you must figure yourself!
Honestly, did zero RTFM, might have a look but I don't expect anything useful there!
-
Following the previous message:
Currently the difference is just 3-7%, and I'm not done yet, still lacking the flash programming functions, there's zero code for it in LL, not even macros!
Adding that, it'll probably get pretty close.
Does the effort worth 5% saving? It's up to you! My opinion? I don't think so.
Tweaking HAL, customizing the ISRs, removing unused checks, will be a much more efficient approach and get your job done in no time.
LL is nice for small devices, where the HAL handlers alone will eat 50% of the RAM.
(https://www.eevblog.com/forum/microcontrollers/is-st-cube-ide-a-piece-of-buggy-crap/?action=dlattach;attach=1666012)
-
What a horrible idea to redefine standard library functions and replace them with functions that do something else.
If you want to use a "tiny_print" then just call it "tiny_print" and be done with it.
I can even understand adding in a macro that throws an error if printf is ever used on a memory constrained system, but your kind of obfuscation is simply a bad idea.
No. Please don't ever venture in this direction! Having non-standard printf sucks. You'll end up with tiny_printf(), medium_printf(), johns_printf(), ect which makes it hard to share code between projects and maintain it. Do you know which printf to use 2 years later? And people default to printf anyway so may not be aware they should be using a different function. And there are more reasons: compilers will check the parameters for printf() for you. For tiny_printf() not. And snprintf is very useful for copying & concatenating strings safely with an added 0 at the end (there is no other standard C library function which does that!).
So what is a better solution? Replace (typically) vuprintf() with a version that caters to your system's needs. You can actually make supporting types optional using a project specific define which is given as a compiler option or in an options.h (or whatever you like to call such a header file). You could even opt to emit a warning that says what the printf is configured for or not. The designers of C already where clever enough to make the symbols of the C library 'weak' to functions can be overridden without the linker throwing an error that there is a duplicate symbol.
In the past I have come across several projects that use non-standard printfs and maintaining these has been horrible and time consuming.
-
The designers of C already where clever enough to make the symbols of the C library 'weak'
Except, with ST Cube, they didn't make them weak.
I posted various threads on that long saga previously :)
-
Good morning!
As I'll be playing with the HK32F030 soon, I decided to investigate how CubeIDE detects fake devices...
This is for personal use only, I'm not having any benefit from it, it's just for fun!
Lastest IDE versions have additional checks, the OpenOCD hack no longer works.
STLINK GDB server (ST-LINK_gdbserver.exe) has its own checks which will need additional research.
With this simple mod I was able to program and debug clones with JLink, or ST-LINK+OpenOCD (Didn't modify OpenOCD).
Tested with:
- STLink+OpenOCD: Air32F103
- J-Link: Air32F103, HK32F030M (HK needs specific flahs algorithms, only supported by J-Link)
Edit:
I moved the patching details inside the file so it doesn't become too obvious, just in case some ST guy searchs those strings.
-
HK32F030 has 2k memory frames, standard printf() won't fit there, it needs at least 38k flash memory and 4k memory frames.
I have the cure https://github.com/AVI-crak/Rtos_cortex/blob/master/sPrint.h
printo("text", double, float, uint(8-16-32-64)_t, int(8-16-32-64)_t )
printo() is capable of executing when debugging in a stm32f030f4 memory frame (no flash resource), all functions are complete. There are also 2k, and that's enough.
Also, unlike printf(), printo() removes code when it's not needed. To print integers you need quite a bit ~ 200 bytes.
-
:-// Who said I was going to use printf? Searching non-existing problems?
This mcu is only going to togle some IOs and measure signals using input capture.
Anyways, it's always nice to know about it :-+
-
HK32F030 has 2k memory frames
“Memory frames”?? What’s that?
-
Ram.
(translation errors)
-
Ram. (translation errors)
But STM32F030 has at least 4k of RAM, and HK32F030 seems to have 10k. Where did 2k come in?
(I know that the RPi RP2040 does some weird stuff with "banks" of RAM, though they end up looking like one chunk.)
-
HK32F030M has 16 K of flash and 2K of SRAM. Example device https://www.lcsc.com/product-detail/Microcontroller-Units-MCUs-MPUs-SOCs_HK-HK32F030MJ4M6_C907709.html (https://www.lcsc.com/product-detail/Microcontroller-Units-MCUs-MPUs-SOCs_HK-HK32F030MJ4M6_C907709.html)
I don't get their naming convention. Normally this "M" place would men package type. But "M" part is available in multiple packages and other letters in the name define the package.
Non-M devices have 16K-256K of flash and 10K of RAM.
-
It actually has 4KB!
Could be something like ST's untested extra 64KB flash, but it's there.
Been developing in it yesterday's entire afternoon, else than the usual "Why is this not working!" and the intensive RTFM, I am impressed for what it packs in $0.25.
So superior to equivalent pic/avr!
Jlink programs and starts the debugging session in 5 seconds, rarely hangs, ask that to the pickit and MplabX!
Another thing is ST IDE performance has greatly increased in the last versions, I remember somewhere in 2021, it was freezing all the time and using massive amounts of RAM, which no longer happens.
-
I tend to agree; fewer problems with Cube v10.
Still suffers from the "can't insert breakpoints" even though you have not reached the max 5. Exit Cube and restart... Fortunately I manage most debugging with 1 or 2.
-
(I'll say one thing for ST. They seem to be continually working on their development environment. That's probably a good thing, despite the pain caused by the "churn." If their original attempts (STLIB?) looked like they might have been written by a summer intern, at least it looks like they have permanent people working on it now (and continuously.))
-
If their original attempts (STLIB?) looked like they might have been written by a summer intern
Cause software is not important. It'll be developed... somehow! BOM rules.
-
I tend to agree; fewer problems with Cube v10.
Still suffers from the "can't insert breakpoints" even though you have not reached the max 5. Exit Cube and restart... Fortunately I manage most debugging with 1 or 2.
I find deleting the breakpoints is good practice. I don't mean deactivate either. Double clicking the breakpoint icon on the line just deactivates that breakpoint, the breakpoint itself is remembered. In JavaEE there are few practical limits on break points and I see people with dozens of them, stepping or "Continue"ing past them one after the other. I'm like, "Go to your break points, click Delete All, now make the one or two you need and stop wasting time!"
So when I get that warning about hardware breakpoints, I just go and delete all the breakpoints in the breakpoint viewer except the one or two I'm actually using and relaunch the debug context.
I have only once or twice had to restart because the debug launch context got a few stuck breakpoints which persisted even after the code was moved around them. They were not registered with eclipse suggesting they are stuck in the GDB context.
-
I think most larger volume chip users don't use free tools. They want tools which are supported, and there is zero support for Cube IDE/MX. And ST will be aware of this. They own a big chunk of the "industrial" business, with little threat from say Espressif due to the political risk and most of those applications being in short market life retail products.
Just looking at the project I am working on, no way this could have been done in a big company. You just could not waste coders' time fixing all that stuff. It happened in my company because of an initial lack of direction and a general a lack of time and money. But having spent much of 2 years on it myself, it is nearly done now; I hope to finish it in January. Would I do anything like this again? NO. But this platform will do anything I want to develop in the rest of my actuarial life expectancy :)
I still find it rather depressing how much half working sh*t there is out there, how little support there is, how so much stuff on say github doesn't work, how the main ST forum is near-useless with near-zero ST participation, not to mention a lot of nastiness coupled with posts containing no useful information, how forums and lists are full of posts by desperate people who are getting no replies (but the issues must have been solved; it's just that those who solved them don't tell anybody how they did it, partly because they are more leechers than contributors and partly because of commercial confidentiality). Never again...
I find deleting the breakpoints is good practice. I don't mean deactivate either. Double clicking the breakpoint icon on the line just deactivates that breakpoint, the breakpoint itself is remembered
Yes; I do that now, but that is just crap software though :)
Along with the ability to set a breakpoint where there is no actual binary code (due to optimisation driven removal, etc). Already discussed.
I remember tools like that from 1980, Z80 days.
-
They seem to be continually working on their development environment
Because they had to! In the last decade they had a tour through all the available IDEs: EWARM, Keil, IAR, TrueStudio, SW4STM32...
Each having their their own specific things, making porting hard and painful, sometimes requiring lengthy steps to enable advanced functionalities.
Also they replaced their libraries, so all the old code was no longer supported.
Now we have a stable platform getting better everyday.
After 2 years of DIY learning all ARM from 0, all the register bits (Not easy at first!), the HK32 is a breeze to develop for.
Also, I remember some terrible ST code when I got my F429-DISCO circa 2013, tried the most simple thing, toggling a LED, opened some sample code and the GPIO init alone was using 2 screens!
Used to "TRISB=0xA1", felt like I was developing some stage-4 cancer and ran away :-DD.
Same as when I "really" tried to use Arduino in the ESP32-S3!
It's easy to run do.begin(), but if you want to go deeper, now you must have a PhD in C++!
Who thought it was a good idea? That's why I I hate Arduino so much!!
Things can be really tidy even at low level, for example, this is current GPIO init running on the HK32.
The "for" loops are a bit convoluted, but provides really compact initialization ;)
typedef struct {
GPIO_TypeDef *port;
GPIO_InitTypeDef init;
} GPIO_Init_t;
typedef struct {
GPIO_TypeDef *port;
uint8_t pin;
uint8_t af;
} GPIO_AFInit_t;
const GPIO_AFInit_t GPIOAF_cfg[] = {
{ GPIOC, GPIO_PinSource5, GPIO_AF_2 }, // SPI SCK
{ GPIOC, GPIO_PinSource6, GPIO_AF_2 }, // SPI MOSI
{ GPIOD, GPIO_PinSource7, GPIO_AF_4 }, // TIM2 CH1 CCP INPUT
};
const GPIO_Init_t GPIO_cfg[] = {
{ GPIOA, { GPIO_Pin_3, GPIO_Mode_OUT, GPIO_Speed_10MHz, GPIO_OType_PP }}, // LED
{ GPIOB, { GPIO_Pin_4, GPIO_Mode_OUT, GPIO_Speed_10MHz, GPIO_OType_PP }}, // OLED CS
{ GPIOC, { GPIO_Pin_5, GPIO_Mode_AF, GPIO_Speed_10MHz, GPIO_OType_PP }}, // OLED SCK
{ GPIOC, { GPIO_Pin_6, GPIO_Mode_AF, GPIO_Speed_10MHz, GPIO_OType_PP }}, // OLED MOSI
{ GPIOC, { GPIO_Pin_3, GPIO_Mode_OUT, GPIO_Speed_10MHz, GPIO_OType_PP }}, // OLED DC
{ GPIOC, { GPIO_Pin_4, GPIO_Mode_OUT, GPIO_Speed_10MHz, GPIO_OType_PP }}, // OLED RST
{ GPIOD, { GPIO_Pin_4, GPIO_Mode_OUT, GPIO_Speed_10MHz, GPIO_OType_PP }}, // DEBUG SIGNAL
{ GPIOD, { GPIO_Pin_7, GPIO_Mode_AF, GPIO_Speed_10MHz, GPIO_OType_PP, GPIO_PuPd_UP, GPIO_Schmit_Enable }}, // TIM2 CH1 CCP INPUT
};
for(uint8_t i=0; i < sizeof(GPIO_cfg) / sizeof(GPIO_Init_t); i++) // GPIO init
GPIO_Init(GPIO_cfg[i].port, (GPIO_InitTypeDef*) &GPIO_cfg[i].init);
for(uint8_t i=0; i < sizeof(GPIOAF_cfg) / sizeof(GPIO_AFInit_t); i++) // GPIO AF init
GPIO_PinAFConfig(GPIOAF_cfg[i].port, GPIOAF_cfg[i].pin, GPIOAF_cfg[i].af);
-
I think you are doing what I always did: table-driven initialisation of everything.
I don't think many people do it these days, and the ST devt environment discourages it, with an individual "HAL" function for initialising every device, and a corresponding "HAL" function for de-initialising every device (which almost nobody uses, but you have to watch it because some of these e.g. USB use the heap).
-
Yeah, tables are great for organization, but will often waste space...
Most of the existing struct can be reused for the next initialization by changing only few elements.
But that "waste" might not be so important when you need instructions to fetch the values.
Anyways it's constant data, won't hurt too much...
I'd chose it everytime, instead of moving through 500 lines searching the one that loads the parameter into the struct.
-
The other thing about a table is that the device gets initialised as per that order. Whereas if one is calling a load of init functions all over the place, it is easy to get the order mixed up. Usually it doesn't matter but sometimes it definitely does e.g. (IIRC) you cannot initialise some peripherals if their clock is not enabled. This stuff is mostly poorly documented.
-
Yeah, I make several tables for different peripherals, but first of all it goes the RCC, so no issues..
-
Why not do a single table?
One could have "delay" codes in the table, to wait x us etc. In some cases this is needed e.g. waiting for the PLL to stabilise (there is IIRC a polling method to detect stability there, but you get the idea). Perhaps a little tricky since the CPU starts at say 16MHz so your delay code needs to know that ;)
-
“Memory frames”?? What’s that?
;)
https://en.wikipedia.org/wiki/Magnetic-core_memory#/media/File:KL_CoreMemory.jpg
-
Perhaps someone will come in handy. https://github.com/AVI-crak/gpio_one
I have my bike "gpio_one_pin(zap_gpio. )" for stm32f4xxx series (for all cases in this series). Done once, so you don't have to look at the documentation again. The macro first translates the structure path into text, then processes the text to a compact unique number of 32 bits, and finally runs a function - which uses this number to fill the peripheral registers.
When optimization is enabled, the parsing of the structure path is fully optimized before the ready value is called from memory. With optimization disabled, path parsing will be in a separate function (take up space).
When you type the name of the structure in the macro gpio_one_pin(zap_gpio. ) - ide starts suggesting options for filling the path. And everything is set up so that false paths do not exist. Well, the most important thing is that all alternative states (AF0-15) are already in the macro.
One line for one leg, one time.
/// SPI4
gpio_one_pin(zap_gpio.E.pin02.v_af05_spi4_sck.speed4.pull_up.lock_on); /// spi4_sck
gpio_one_pin(zap_gpio.E.pin04.out.speed4.lock_on); /// spi4_nss
gpio_one_pin(zap_gpio.E.pin05.v_af05_spi4_miso.speed4.pull_up.lock_on); /// spi4-mo
gpio_one_pin(zap_gpio.E.pin06.v_af05_spi4_mosi.speed4.pull_up.lock_on); /// spi4_mi
The macro is very difficult to adopt for the stm32f1 series, even more difficult for the stm32H. But for large stm32f4 cases - it fits perfectly. Setting up 160 pins in the STM32Cube way is literally a thousand lines. In my case it is 160 lines.
In order to reduce the error rate, I use a text report from STM32Cube. I just replace the copied text with my code. It is impossible to completely abandon the STM32Cube - this is the only quick search for an alternative connection of legs to the MK.
-
The ST Cube IDE "HAL" code includes exactly such functions - for setting up a single pin.
They are quite handy but I would not have done it that way if I was starting bare-metal. I would work through every page of the RM and use a table. But that's ~2000 pages and you can see why this is impractical.
-
They are quite handy but I would not have done it that way if I was starting bare-metal. I would work through every page of the RM and use a table. But that's ~2000 pages and you can see why this is impractical.
Then do it for every model of mcu.
This is why we need a small number of monoglots, those people who specialise into the n-th degree on a platform.
However, I prefer to be a polyglot and learn a small amount about a large array of platforms. Learn enough to be of practical use at least.
The HAL libraries still fall short on easy of use, rapidity of development. In my experience, nothing actually works first try out of the box, there is always some little niggling little bit of config you forgot. Forgetting to tick and interrupt, setting the DMA item size wrong whatever. It's always a struggle, always a fight, you always end up learning far more than you felt you needed to do get the job done... if and only if... their HAL libraries did it's job properly and made these things easy.
To that end, I believe they need to apply a good solid dose of "convention over configuration". They need to facade a lot of the overly complicated BS which is so complicated because it's trying to handle everything from the "high school hello world" right up to their latest, greatest most complicated variant of it that nobody is going to use. It's just too much, too different goals which are not compatible. In my opinion the HAL library needs split up into "common" and "advanced" where the common handle the 90% of the simple things easily, even with canned or default config for the most common use case and then a HAL_ADV library for handling the bizarre and massively complicated scenarios like 3 chained timers using PWM capture, output capture and tiggers with DMA.
That way when you have a simple prototype to knock up with a bread and butter UART it's just a half dozen clicks and it's ready.
HAL Libraries are 100% useless if you have to spent as long working out how to use it as it would have taken to read the datasheet and set the resisters yourself.
Oh... and I know it's an MCU library set, but for the love of god can we have some f...ing logging in it? Even compile out macros or something. Having no logging mechanism in your HAL library... in my opinion would be 25 lashes in front of the whole software department.
-
HAL libraries are written with very little attempt at separating hardware/user code levels. Because it is allowed to access the hardware from the user code. In fact, these are several wrappers over the standard cmsis - many layers of abstractions with a variable meaning and description of states. It's like piling up fixes for an initially stupid decision.
I use my own cmsis-level functions for each chip series, my own unique functions for each unique chip on a unique PCB, and many user-level functions for all chips without limitation. It turned out to be quite convenient.
For example, for a timer, one of the many options for a given MK series, and the legs are adjusted for a specific project (this is below the level of the series). From the iron code, only the timer function is visible, which in itself is standard for the user level, and at the same time the user does not see and does not work with peripheral registers. Differentiation of visibility levels according to all rules.
As a result, my IDE shows a small number of functions and variables in the right quick use column - which are directly connected to the user's file. In the HAL version, there will be an endless list of everything that is in the project, literally millions of lines. Do you need it?
It seems to me that the main problem with HAL is that it was written by arduino programmers, and for arduino users. This type of user always writes all the code to one file. This is an unspoken rule for them. ;D
-
That part of ST code works fine. Example:
void Configure_GPIO(GPIO_TypeDef *port, uint32_t pin, GPIO_PinState pin_state, uint32_t mode, uint32_t pull, uint32_t slew)
{
GPIO_InitTypeDef GPIO_InitStruct;
GPIO_InitStruct.Pin = pin;
GPIO_InitStruct.Mode = mode;
GPIO_InitStruct.Pull = pull;
GPIO_InitStruct.Speed = slew;
HAL_GPIO_Init(port, &GPIO_InitStruct);
HAL_GPIO_WritePin(port, pin, pin_state);
}
and the two functions called above are ST-provided. The 1st one is really horrible though:
/**
* @brief Initializes the GPIOx peripheral according to the specified parameters in the GPIO_Init.
* @param GPIOx where x can be (A..K) to select the GPIO peripheral for STM32F429X device or
* x can be (A..I) to select the GPIO peripheral for STM32F40XX and STM32F427X devices.
* @param GPIO_Init pointer to a GPIO_InitTypeDef structure that contains
* the configuration information for the specified GPIO peripheral.
* @retval None
*/
void HAL_GPIO_Init(GPIO_TypeDef *GPIOx, GPIO_InitTypeDef *GPIO_Init)
{
uint32_t position;
uint32_t ioposition = 0x00U;
uint32_t iocurrent = 0x00U;
uint32_t temp = 0x00U;
/* Configure the port pins */
for(position = 0U; position < GPIO_NUMBER; position++)
{
/* Get the IO position */
ioposition = 0x01U << position;
/* Get the current IO position */
iocurrent = (uint32_t)(GPIO_Init->Pin) & ioposition;
if(iocurrent == ioposition)
{
/*--------------------- GPIO Mode Configuration ------------------------*/
/* In case of Alternate function mode selection */
if((GPIO_Init->Mode == GPIO_MODE_AF_PP) || (GPIO_Init->Mode == GPIO_MODE_AF_OD))
{
/* Check the Alternate function parameter */
assert_param(IS_GPIO_AF(GPIO_Init->Alternate));
/* Configure Alternate function mapped with the current IO */
temp = GPIOx->AFR[position >> 3U];
temp &= ~(0xFU << ((uint32_t)(position & 0x07U) * 4U)) ;
temp |= ((uint32_t)(GPIO_Init->Alternate) << (((uint32_t)position & 0x07U) * 4U));
GPIOx->AFR[position >> 3U] = temp;
}
/* Configure IO Direction mode (Input, Output, Alternate or Analog) */
temp = GPIOx->MODER;
temp &= ~(GPIO_MODER_MODER0 << (position * 2U));
temp |= ((GPIO_Init->Mode & GPIO_MODE) << (position * 2U));
GPIOx->MODER = temp;
/* In case of Output or Alternate function mode selection */
if((GPIO_Init->Mode == GPIO_MODE_OUTPUT_PP) || (GPIO_Init->Mode == GPIO_MODE_AF_PP) ||
(GPIO_Init->Mode == GPIO_MODE_OUTPUT_OD) || (GPIO_Init->Mode == GPIO_MODE_AF_OD))
{
/* Configure the IO Speed */
temp = GPIOx->OSPEEDR;
temp &= ~(GPIO_OSPEEDER_OSPEEDR0 << (position * 2U));
temp |= (GPIO_Init->Speed << (position * 2U));
GPIOx->OSPEEDR = temp;
/* Configure the IO Output Type */
temp = GPIOx->OTYPER;
temp &= ~(GPIO_OTYPER_OT_0 << position) ;
temp |= (((GPIO_Init->Mode & GPIO_OUTPUT_TYPE) >> 4U) << position);
GPIOx->OTYPER = temp;
}
/* Activate the Pull-up or Pull down resistor for the current IO */
temp = GPIOx->PUPDR;
temp &= ~(GPIO_PUPDR_PUPDR0 << (position * 2U));
temp |= ((GPIO_Init->Pull) << (position * 2U));
GPIOx->PUPDR = temp;
/*--------------------- EXTI Mode Configuration ------------------------*/
/* Configure the External Interrupt or event for the current IO */
if((GPIO_Init->Mode & EXTI_MODE) == EXTI_MODE)
{
/* Enable SYSCFG Clock */
__HAL_RCC_SYSCFG_CLK_ENABLE();
temp = SYSCFG->EXTICR[position >> 2U];
temp &= ~(0x0FU << (4U * (position & 0x03U)));
temp |= ((uint32_t)(GPIO_GET_INDEX(GPIOx)) << (4U * (position & 0x03U)));
SYSCFG->EXTICR[position >> 2U] = temp;
/* Clear EXTI line configuration */
temp = EXTI->IMR;
temp &= ~((uint32_t)iocurrent);
if((GPIO_Init->Mode & GPIO_MODE_IT) == GPIO_MODE_IT)
{
temp |= iocurrent;
}
EXTI->IMR = temp;
temp = EXTI->EMR;
temp &= ~((uint32_t)iocurrent);
if((GPIO_Init->Mode & GPIO_MODE_EVT) == GPIO_MODE_EVT)
{
temp |= iocurrent;
}
EXTI->EMR = temp;
/* Clear Rising Falling edge configuration */
temp = EXTI->RTSR;
temp &= ~((uint32_t)iocurrent);
if((GPIO_Init->Mode & RISING_EDGE) == RISING_EDGE)
{
temp |= iocurrent;
}
EXTI->RTSR = temp;
temp = EXTI->FTSR;
temp &= ~((uint32_t)iocurrent);
if((GPIO_Init->Mode & FALLING_EDGE) == FALLING_EDGE)
{
temp |= iocurrent;
}
EXTI->FTSR = temp;
}
}
}
}
/**
* @brief Sets or clears the selected data port bit.
*
* @note This function uses GPIOx_BSRR register to allow atomic read/modify
* accesses. In this way, there is no risk of an IRQ occurring between
* the read and the modify access.
*
* @param GPIOx where x can be (A..K) to select the GPIO peripheral for STM32F429X device or
* x can be (A..I) to select the GPIO peripheral for STM32F40XX and STM32F427X devices.
* @param GPIO_Pin specifies the port bit to be written.
* This parameter can be one of GPIO_PIN_x where x can be (0..15).
* @param PinState specifies the value to be written to the selected bit.
* This parameter can be one of the GPIO_PinState enum values:
* @arg GPIO_PIN_RESET: to clear the port pin
* @arg GPIO_PIN_SET: to set the port pin
* @retval None
*/
void HAL_GPIO_WritePin(GPIO_TypeDef* GPIOx, uint16_t GPIO_Pin, GPIO_PinState PinState)
{
if(PinState != GPIO_PIN_RESET)
{
GPIOx->BSRR = GPIO_Pin;
}
else
{
GPIOx->BSRR = (uint32_t)GPIO_Pin << 16U;
}
}
The above shows the classic HAL issue: code bloat. There is a lot of code to deal with EXTI but if you aren't using EXTI then this is just wasted code.
-
As you have the source, you can insert an #ifdef #endif switch in order to make it a compile time option, thus saving on code size. This isn't code bloat, as EXTI support by hardware is a reality and required in the HAL.
Regards, Dieter
-
Still much easier/faster to tweak HAL code for your needs than making everything from scratch.
-
Yes indeed; I tend to do exactly that.
-
Quote from: paulca on Yesterday at 05:46:02 am (https://www.eevblog.com/forum/index.php?topic=285824.msg4621441#msg4621441)HAL Libraries are 100% useless if you have to spent as long working out how to use it as it would have taken to read the datasheet and set the resisters yourself.
Yes, exactly. The entire post reflects my opinions!
A really useful HAL library would have the same APIs across multiple vendors.
The individual vendors have very little motivation for making this be so - locking you in to their own products is much preferable!
Also, vendors like to add special feature that a fully generalized HAL would have difficulty supporting.
-
I think a lot of posts reflect different developer circumstances.
Those who have their own business will re-use the same CPU as far as they possibly can.
Those who work for a company and get paid by the hour are happy to change CPUs to suit different tasks.
The first category is served OK by Cube MX and the generated "HAL" code but will probably do this only once and never again. Re-using existing hardware, software, and expertise can save man-years of work which is crucial to getting bug-free products out of the door.
The second category will find Cube MX and "HAL" a useful way to get going with a new project. Months will be wasted on each project but that's OK because it all puts bread on the table at home.
-
Unified libraries between manufacturers? That's some nice pills you're taking! :D
In any case, peripherals are not universal, everyone makes their own, so there's no such thing and hardly ever will.
Wait, there's such thing! It's called Arduino!
And due having to support everything, bloat is gigantic and the code painfully slow ;).
You can't have everything. Either device-specific, fast, efficient libs, or terrible universal libs.
It's ok to rant under realistic terms, but most I've seen lately it's just demagogy, you're asking for shiny unicorns.
-
And due having to support everything, [arduino] bloat is gigantic and the code painfully slow
Gee, isn't that the same complaint we have about vendor libraries?
-
Then use the low level libraries, they've always been there.
They're almost macros, assume nothing, have no bloat and require a lot of RTFM.
Now are you going to complain because they're too hard and slow to develop for? :-DD
-
Unified libraries between manufacturers? That's some nice pills you're taking! :D
In any case, peripherals are not universal, everyone makes their own, so there's no such thing and hardly ever will.
You can't have everything. Either device-specific, fast, efficient libs, or terrible universal libs.
If that where true, operating systems wouldn't exist. The trick is to find a unified API that works well for a type of device. Take I2C for example. In the end you want to transfer a couple of bytes. The API the Linux kernel uses is efficient and versatile without a lot of bloat. The problem is to find an optimum between veratility and bloat. What do you shove into user space and what do you handle at the driver level? IMHO ST's HAL is not optimal in a lot of places -from what I've seen so far- but it doesn't mean it can't be done.
-
If that where true, operating systems wouldn't exist.
Operating Systems exist for totally different reasons. Say, you have software which you want to sell to thousands (or millions) of users which have totally different PCs - big, small, desktop, laptop, with hard drivers, SSDs, different kinds of displays, mice, keyboards, living in different countries and speaking different languages. Here's where the OS come in. It creates an abstraction layer. This allows you to write software which can run on any PC. This also allows hardware manufacturers to write drivers for their devices so that they can work with your software through the OS. This would be completely and utterly impossible without OS.
With embedded, you sell both hardware and software at the same time. So none of such issues exist. You have an ability to chose your hardware and software to meet your goals, which greatly simplifies things.
-
Can anyone explain this
(https://peter-ftp.co.uk/screenshots/202301135416415619.jpg)
The value of the boolean 'fail' is false, and 'written' is 512 which is right.
-
What optimisation options are you using? Is it -Og?
If you have a disassembly window, you can check the instruction where the BP is set. (I am not familiar with Cube)
-
I always add a asm("nop") for these, breakpoints can be a bit tricky sometimes.
-
How many times are you going to complain about (essentially) "optimized code is hard to debug, and the debugger does things I don't expect"?
Give up and learn to deal with it, already. Even if that means learning to read the assembly language...
-
Simply watch rx_count, if it increases, it's all right!
-
It's not even optimisation it's the standard instruction set:
https://developer.arm.com/documentation/dui0473/m/condition-codes/conditional-execution-in-arm-state
-
He's clearly refering to compiler optimization, which as you know, anything over -Og starts optimizing the code, removing variables, steps, lots of stuff, basically making your code un-debuggable.
BTW, -flto is even worse, packs functions together and further optimizes them. I've seen 25% performance gain from it, but depends a lot on the context.
Sadly it's uncompatible with the stack analyzer, so you can't know how much stack you'll be using.
-
I am well familiar with optimisation removing code, and I know that in Cube you can set a breakpoint where there is no code (even on comments :) ) but I am surprised at the above. Perhaps the implementation uses some kind of conditional instruction(s) so there is no actual code anywhere implementing that if() structure as code which gets executed only then.
The solution would be the above asm code (asm never gets removed) or simply add some code which cannot be a part of conditional instructions like
volatile int fred=0;
fred++;
Normally I find that works ok, in delivering a bit of code which you can breakpoint on.
-
AFAIK, Arm have optimized instructions that can run conditionals without branching.
-
anything over -Og starts optimizing the code
Over and including. The documentation (https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html) says:
Otherwise -Og enables all -O1 optimization flags except for those that may interfere with debugging:
-fbranch-count-reg -fdelayed-branch
-fdse -fif-conversion -fif-conversion2
-finline-functions-called-once
-fmove-loop-invariants -fmove-loop-stores -fssa-phiopt
-ftree-bit-ccp -ftree-dse -ftree-pta -ftree-sra
-
I mean, Og optimizes some, but can still be debugged.
O2+ will make a nonsense nightmare when stepping it.
-
AFAIK, Arm have optimized instructions that can run conditionals without branching.
That's right. ARM Thumb-2 architectures (for example, Cortex-M3) have an "IT" (if/then) instruction that allows up to 4 following instructions to be executed conditionally.
- https://developer.arm.com/documentation/ddi0308/d/Thumb-Instructions/Alphabetical-list-of-Thumb-instructions/IT?lang=en
FWIW, if I remember right, the 32-bit ARM architectures allow pretty much any instruction to be conditional.
-
I mean, Og optimizes some, but can still be debugged.
O2+ will make a nonsense nightmare when stepping it.
That is my experience too. I find I can work with -Og all the time and just sometimes adding some code enables a breakpoint to be set.
FWIW, if I remember right, the 32-bit ARM architectures allow pretty much any instruction to be conditional.
Of course all the experts here know this :) but many will be surprised - myself included.
Would -O0 really suppress the use of all conditional instructions??
I've never known a debugging environment which was so opaque and so full of gotchas.
-
Would -O0 really suppress the use of all conditional instructions??
In x86 the -O stuff, in part uses all the microcode extensions and what not. These are not part of the x86 instruction set "persae", they are microcode and peripheral instructions. Like the ones that can take 50 clock cycles to complete.
My understanding and I could be wrong, but the ARM codes provide those conditional instructions as part of the primary instruction set. Therefore compiling C code to ARM ASM, in my view, is free to use those instructions with optimisation completely disabled. Why would it not be able to use those? They are ARM instructions and not using them you can bet a lot more people would be complaining.
On optimisation, in software engineering we have a kinda rules.
1. Make it work.
2. Optimise it.
3. Make it work again.
Always in that order.
-
Warning: Extreme, annoying, and pointless pedantry follows.
persae
Persae, genitive case of Persa (migth also be dative).
I don't think that some X86 instructions can belong, in general, to a Persian person, or possibly to the nymph Persa, mother of the enchantress Circe.
But you probably intended "per se", as "in itself/themselves".
-
if I remember right, the 32-bit ARM architectures allow pretty much any instruction to be conditional.
Yes, but in the Thumb instruction set used by the cortex-M, instructions can only be conditional if used in an IT block.
Cortex-M0 doesn't have the IT blocks, so the only way it can handle conditions is with "traditional" conditional jumps.
-
It's funny to observe this in another context.
My board has a firmware upload feature and this skips flash programming where the data has not changed. This is readily visible where you change e.g.
int x=0;
to
int x=1;
which does not change the code size.
But I also found that I can add several lines of conditionals and it still programs "instantly".
-
Changing a single initial value from 0 to non-0 could result in a quite significant binary difference due to reassignment from BSS to DATA section. Vars allocated after this one would be moved, changing their addresses in code section.
-
OK; I should have said changing from 10 to 20 :)
-
Cube has been updated to 1.12.0.
The tool version has not changed - at least not automatically, which is good. It says in the release note that it is "enabled"; no idea what that means. The binary is identical byte for byte.
Errata
https://wiki.st.com/stm32mcu/wiki/STM32CubeIDE:STM32CubeIDE_errata_1.12.0
does not list any of the biggest bugs e.g. the random file opening when debugging.
In the release note is this
(https://peter-ftp.co.uk/screenshots/20230309425264914.jpg)
which I sort of understand (it appears to do the same thing as zeroing BSS does to global statics) but the path above does not exist.
-
Errata
https://wiki.st.com/stm32mcu/wiki/STM32CubeIDE:STM32CubeIDE_errata_1.12.0
does not list any of the biggest bugs e.g. the random file opening when debugging.
With the random-file-open bug, I can't help but wonder if they're somehow oblivious to that bug even being there at all.
-
It sounds like you've encountered a frustrating and confusing situation. In general, it's always a good idea to save your work frequently, even if you haven't made any changes recently. This can help prevent accidental changes from going unnoticed and potentially causing problems down the line.
Regarding the issue with the typedef, it's possible that the code was relying on a certain order of includes or other dependencies that changed without your knowledge. It's also possible that the code was relying on some behavior or functionality that has changed in a new version of the compiler or other toolchain that you're using.
As for the files that couldn't be closed and the loss of your default window configuration, it's hard to say what might have caused those issues. It's possible that there was some sort of bug or glitch in the software you were using, or that something else on your system was interfering with it.
In any case, it's always a good idea to have backups of your work, as you mentioned. It's also a good idea to try to track down the root cause of any issues you encounter, as this can help you avoid similar problems in the future. If you're not sure how to do this, it might be worth reaching out to the developer community for the software you're using, or seeking out resources such as documentation or tutorials to help you better understand the underlying concepts involved.
-
Nice nickname. :-DD
-
The text sounds like chat gpt, doesn't it? Who knows..
Regards, Dieter
-
Probably a spammer. The language is out of chatgpt. Totally bland. Sickly-sweet and nice and positive.
-
Uh, I thought changing the password would do it. I renamed it chat GPT, better than going around deleting every post.
-
Probably a spammer. The language is out of chatgpt. Totally bland. Sickly-sweet and nice and positive.
Seems like good trolling for sure lol
-
If the AI got out it will start contributing to forums :-DD
-
If the AI got out it will start contributing to forums :-DD
... and ruling the world :)
-
So far, I see no bug fixes on v12 other than an apparent reduction of the random file opening issue during debug.
-
They also need to fix the Search function.
A lot of the time it simply doesn't find some variable name. Sometimes the "free text" search does find it. Other times you have to use some external file search which (obviously) works.
-
I believe the lack of "Find references" working is partly the way the indexing is setup and partly, being honest, the code. The HAL code for example has many a dead end regarding references. Anonymous structs are a good example. Like a lot of the ones in HAL that were clearly written in C++ and ported to C by a machine.
-
The Find Refs is even worse than Search :)
So I wasn't going to mention it.
What do you think is wrong with the indexing?
-
What do you think is wrong with the indexing?
I haven't bothered to look. I probably do exactly as you do.
CTRL+Click... nope.
<grumble>
Find References in workspace... nope.
<growl>
File search... yep!
<tut>
Things that will probably make it difficult for the indexer.
* the custom project layout
* the dynamic includes/cpp files
* the autogenerated code
* anonymous structs and void pointers.
* The sheer volume and complexity of the IFDEF and MACRO soup.
EDIT:
Even in Java land, eclipse's home territory it can run out of steam on complex projects and simply stop resolving references. Double nested, anonymous factorn patterns buried in a double nested visitor pattern certainly did. To dry run that stuff I used the debugged and stepped into the code to find out what actually got run as Eclipse had no idea either.
-
Here you go. And there is nothing difficult about SysTick_Handler. The one in yellow, the #define, is findable only with that "quick search". The last (3rd) image should be the 1st but there is no way to edit a post to do that.
-
I am getting a bit tired of everything that is not good or ok.
It is free man, if you find it to be such crap why not buy from Keil or IAR and start finding out that also there life ain't perfect.
-
They also need to fix the Search function.
A lot of the time it simply doesn't find some variable name. Sometimes the "free text" search does find it. Other times you have to use some external file search which (obviously) works.
I always use 'search text'. Make sure to give the indexer enough memory to work with and enable indexing on large files as well. The default maximum is a couple of thousand lines. I use Eclipse's indexer on the Linux kernel and it works well once the indexer is configured. But be aware that the first index of a Linux kernel takes a good part of an hour.
-
If there is something that I like about Eclipse is its editor and search capabilities. In the early days I was also very confused with the better search (Ctrl-H) but over time I got to learn how it works with the code, its dependencies and #ifdefs. Pretty good is also the perspective context switch, which I hated at the beginning but I was so used to have all the code dev and debug windows cramped on the same screen that I didn't realize how liberating it was to not have to resize and move stuff around between these tasks. (Project management, build console, disassembly, memory, registers, stdout console, breakpoints, watchpoints, etc.)
YMMV, but it is indeed free. 😁
-
The default maximum is a couple of thousand lines
Make sure to give the indexer enough memory
Interesting. Where is the config for this?
and start finding out that also there life ain't perfect.
Nobody said it was :)
What is probably most puzzling is that a $14BN company can't fix this - a primary tool for generating code for its chips. Or maybe they feel that only hobby programmers use it?
-
What is probably most puzzling is that a $14BN company can't fix this - a primary tool for generating code for its chips. Or maybe they feel that only hobby programmers use it?
It is not their core business. Only recently they started investing in this.
You can better ask yourself why this company does not fix known issues in their microcontroller peripherals which is their core business ;)
And yes big companies use the sorts like IAR because they have better support if the s*it hits the fan, that is why they pay, service insurance.
-
Interesting. Where is the config for this?
-Xms256m
-Xmx1024m
C:\ST\STM32CubeIDE_1.10.1\STM32CubeIDE\stm32cubeide.ini
These are quite small. Note, plugins and extras can use additional memory if they use additional processes.
-
What is probably most puzzling is that a $14BN company can't fix this - a primary tool for generating code for its chips. Or maybe they feel that only hobby programmers use it?
I have used Eclipse for 20+ years. I have also used Eclipse CDT since about 2012. The later has always been a bit rough around the edges. Back in 2012 it was far worse, with virtual zero build integration and only useful as an indexed editor.. and the indexer had issues then.
It is a little odd that STM picked eclipse. However, the options you have today to create an IDE without undergoing the arduious decade length product project of making it from scratch.... are:
Eclipse
VSCode
JetBrains
Given the nature and scale of the business, options 1 will be the only "Free" entry. Microsoft will doubtless charge handsomely for the consultancy and any licensing required beyond the base VSCode. JetBrains are also going to charge handsomely and probably extended that charge to the user for the "real feature set".
Eclipse CDT is 90% there, so they started there. They could also integrate their MX configurator/geneerator into it.
The debugging system is all "off the shelf", just like 99% of the build chain.
I honestly think the code goes a few steps too deep into nested IFDEF and MACRO chains and the indexer loses track in many locations. As I said, my personal most common view of this is the dead ends caused by "Anonymous struct"....
-
The random files opening during Run and Debug and the whole process there in needs to be thrown in the bin and rewritten. IMHO.
It is just too riddled with bugs. You can see it struggle each and every time with timing between the programmer the device and the whole process seems fragile and hanging together.
The issue with the files opening is reported by STM to be an issue with the connection to GDBServer. Something about a race condition between the ARM debug core signalling and the GDB. When they connect the GDB to the ARM debug it immediately starts emitting signals/symbols to Eclipse. Eclipse then opens those files as the debugger has fired an event for a line in them.
It sounds plausible, but my question is... how come every other language virtual machine or debug protocol can wait and synchronise with GDB without all these issues.
In terms of Java and I believe C elf exe's GDB can work in tandem with the language runtime to "Wait for debugger" where it will automatically pause on your ENTRY_POINT and wait for everything to sync up first.
The reason I think STM have issues relating to this is that their process of "Connect under reset" is itself broken. Watch the logs. It restarts the device at least twice, not once. All while saying "Waiting on debugger....".... "Waiting on debugger...".... all while random ASM files are opening. When you device under test is in communications with other devices this alone destroys your test harness if you forget it happens. You test harness sees the MCU reset, starts its test and the thing promptly resets again.
It's got too many issues. What it needs is STM to take their most keen mid level engineer and lock him in a room, give him whatever he needs and let him have hte full flexibility to come up with a solution that works, void from legacy or corporate BS.
-
That is why you shouldn't use a debugger to do behavioural verification. Use a serial port with text output for that (and commands to set parameters). Debugging is only useful to find bugs that are not simple to find otherwise (like pointers going wrong or software getting stuck somewhere).
-
That is why you shouldn't use a debugger to do behavioural verification. Use a serial port with text output for that (and commands to set parameters). Debugging is only useful to find bugs that are not simple to find otherwise (like pointers going wrong or software getting stuck somewhere).
Yes. Try it. During the flashing process it restarts the device multiple times making it difficult to set up a test harness which looks for output and then expects a series of data to confirm. What it actually gets is 3 different attempts to run the MCU. It doesn't matter if you hit Run or Debug it will restart the MCU multilpe times.
Of course, you can decouple from that too by running the test harness outside of eclipse and not tying it to the build. Fine for the 1990s and fine in hobby land, but that is not how it would be done in the "real" world.
EDIT: Anyway, it's neither here nor there, because I'm a hobbyist in this space so while I do ponder about setting up actual automated integration and system test harnesses and even unit testing. I have more interesting things to do with my free time. :) And it's only ME who comes harassing me about bugs and low quality code... because it's only me going to suffer from it in this case.
-
Interesting stuff.
STM apparently denies all knowledge of the multiple random file opening bug.
C:\ST\STM32CubeIDE_1.10.1\STM32CubeIDE\stm32cubeide.ini
Jesus, how the hell was one supposed to know about this?
That is why you shouldn't use a debugger to do behavioural verification
What is "behavioural verification"?
Running under a debugger is limiting. AFAICT there is no way to just reset the CPU; one has to (with say F11) reload the project and run it again. Once loaded, and in Debug mode, one can Restart it OK, over and over.
But (as posted in various threads) Cube usually loses the STLINK debugger connection after a while. Some say after minutes, some say after hours. I usually find that it is ok for maybe an hour. It doesn't matter how short the SWD wires are, etc.
https://www.eevblog.com/forum/microcontrollers/st-32f4xx-debugging-and-njtrst-mystery-does-it-do-anything/msg3564987/#msg3564987 (https://www.eevblog.com/forum/microcontrollers/st-32f4xx-debugging-and-njtrst-mystery-does-it-do-anything/msg3564987/#msg3564987)
https://www.eevblog.com/forum/microcontrollers/10-pin-debug-connector-and-stlink-v3-isol-not-reliable/msg3564782/#msg3564782 (https://www.eevblog.com/forum/microcontrollers/10-pin-debug-connector-and-stlink-v3-isol-not-reliable/msg3564782/#msg3564782)
https://www.eevblog.com/forum/microcontrollers/st-32f4xx-debugging/msg3577722/#msg3577722 (https://www.eevblog.com/forum/microcontrollers/st-32f4xx-debugging/msg3577722/#msg3577722)
It's a bit sad when one does a search and most applicable hits are your own ;)
-
C:\ST\STM32CubeIDE_1.10.1\STM32CubeIDE\stm32cubeide.ini
Jesus, how the hell was one supposed to know about this?
True. All that changes is the memory parameters for the JVM Eclipse itself runs in. The first param is how much to allocate to the VM on start up and the second is how much it can allocate it total dynamically. In work I tend to have mine set around 1Gb and 4Gb.
YMMV, a lot of build chains items and some plugins etc. Will actually spawn additional processes and use additional RAM uneffected by that setting.
I am actually going to go and change mine a bit too. The reason is because I make frequent use of CubeMX and when that gets evicted out of memory and you open it again... well... I minimise the VM and watch YouTube while I wait on it reopening. Hopefully if I give it another 1/2Gb it may stay in memory.
-
Interesting stuff.
STM apparently denies all knowledge of the multiple random file opening bug.
That is why you shouldn't use a debugger to do behavioural verification
What is "behavioural verification"?
Testing the software to check whether all the functionality works as expected. Personally I very much prefer to do this using log output over the serial port so I can check all kinds of things.
-
The SWV ITM Console (available in STLINK V3) output should do the same job, and generally it does. What it can't do is use say printf from a boot loader ;) Then, outputting straight to a UART is the only way, but that will hang the code down to the baud rate speed.
-
The fact that it's built on eclipse automatically means it will be a buggy piece of crap.
I would suggest learning CMake and finding a suitable IDE with plugins. CLion (JetBrains IDE) works well, and VSCode can also work. By doing this, you can just use the standalone CubeMX tool to generate the project files and import them, no longer worrying about hidden changes.
I do not have any proof, but anecdotally, I ran into many issues with ST's IDE. It was nice when it worked, but many times there were small changes in header files which caused a project to stop compiling.
-
The fact that it's built on eclipse automatically means it will be a buggy piece of crap.
I would suggest learning CMake and finding a suitable IDE with plugins. CLion (JetBrains IDE) works well, and VSCode can also work. By doing this, you can just use the standalone CubeMX tool to generate the project files and import them, no longer worrying about hidden changes.
I do not have any proof, but anecdotally, I ran into many issues with ST's IDE. It was nice when it worked, but many times there were small changes in header files which caused a project to stop compiling.
In my experience it is a much better workflow to let CubeMX create example code (in a seperate scratchpad project) and then use that in your own project that doesn't use any automatically generated code. I've learned a long time ago (long before ARM microcontrollers where a thing) that automatically generated code is asking for the trouble you describe. It has nothing to do with Eclipse in itself but the code generator tool that has been created by ST.
Which IDE to use is a matter of personal preference. IMHO Eclipse is very useable though with some tweaking and tuning (which any IDE requires anyway).
-
In my experience it is a much better workflow to let CubeMX create example code (in a seperate scratchpad project) and then use that in your own project that doesn't use any automatically generated code
Yes that is a good way to do stuff. Use the Cube MX code generator and then cut it down to what is actually needed.
For example if transmitting via SPI the code generator adds all kinds of junk like checking if CRC checking is enabled (by reading back some flag) but if you didn't enable that feature then you obviously don't need that. The auto generated code does actually (usually) work so this is an easy starting point, even for a "bare metal" project.
The fact that Cube is free is generally pretty important, though maybe not for the obvious reasons. A corporate user can buy say 10 licenses for a paid product but in general paid products "phone home" regularly to check licenses, which will eventually bite you in the bum when the vendor stopps running the license server. So the project you last worked on 10 years ago "blows up" because the tool no longer runs. Not even in a VM. So while I happily pay for software which I actually use, I totally avoid any software which "calls home".
-
It's complicated.
As soon as you want to use CubeMX for a MCU variant you did not use before, it will call home to install support packages. In that moment you not only depend on their servers but they may also have a look at what you are actually doing with their software. Of course we won't know whether they do that but in general it's enough to know they can.
Is there a reliable way of installing support packages offline?
Regards, Dieter
-
Yes you can do everything manually.
AFAIK only Cube MX (the GUI editor + code generator) needs explicit support for the CPU type. Obviously it does because it displays the package, the pins, and you can choose what the pins do, etc.
Cube IDE is just an editor + makefile generator.
The "HAL" libs pull in #defines from .h files for the CPU type, so a HAL function for setting some pin state may use different code for different CPUs, and certainly for setting up the clocks, but you don't need to use that code. You can just write it bare-metal from the RM, and probably should do that anyway, although you may use the HAL function as a starting point to save time.
IME, once a product is out, one rarely just changes the CPU. People did this during the covid craziness shortages, replacing STM chips with ESP32 etc, but this is rare. Normally, you archive the old product (PCBs, schematics, code, IDE, the lot) and generate a fresh one.
There is some telemetry in Cube and they ask you if you agree, but I choose No and anyway could not care less. There is no licensing, floating or otherwise. The other day I had a conversation with some EDA vendor about their floating licenses and asked him what I am supposed to do if (when!) their license server stops working. He said I can run my own license server, to enforce the max # of concurrently running copies. Later it turned out that their code is tied to the MAC # of the ETH card in that "server" PC. So if that PC blows up, you are screwed. Unless you bought a spare ETH card, of a type whose MAC # can be user-programmed (most can't but some can) and then you can create a duplicate server.
In the corporate world people pay for this sh*t because they think if they pay they get support (true, to an extent) but nothing is for ever. I had this lesson with $20k Xilinx software many years ago. They simply washed their hands of if when the two dongles eventually broke (they were flimsy) and I carried on when I found a Russian crack for both Viewlogic 4 and XACT 5.
With $$$-licensed products you get this crap. It's a big advantage of free tools to not have that. You can archive a project, perhaps even in a VM (and I actually have that right now, albeit the VM is ~30GB) for ever, for free.
Of course the extent to which this matters depends on whether it is your company, or you just work somewhere. In the former case you have very specific archival and futureproofing requirements. In the latter case, bread on the table at home = bread on the table at home ;)
-
So the project you last worked on 10 years ago "blows up" because the tool no longer runs. Not even in a VM. So while I happily pay for software which I actually use, I totally avoid any software which "calls home".
You want 10 year old software to "just work". Right. Unless it's been maintained it wont. Projects in work, maybe a year, maybe a little more, but all projects need to keep moving or they build up cobwebs. Cobwebs - "This used to work, why does it not any more?"
Just wait till you get to some area which has legal certifications for what you do. Then try and use ANY software that is more than a few months old to meet those requirements.
MCUs are not completely immune to these issues, the crypto space etc. and military probably have a careful eye on the security space there in. As for the banking sector, MCUs are generally treated like the plague. All USB ports and all comms ports on physically machines are locked down to prevent rootkit USB keys and other exotic MCUs.
Based soley on the sheer volume of "Lets hack a hardware device" - in 99% of cases it's not hacking, they leaves the front door open and even give you a nice map to find the valuables.... and the increasing annoyance of the general consumer base around MCU security, it won't be long before people like OWASP, GEM, CVE etc. get into your space.
When that occurs they will define a whole range of security vulnerabilities existing in your space. "Open UART" for example. Releasing a consumer product riddles with known vulnerabilities is perfect fine "today" for most cheap MCU devices, but that is changing. Soon doing so and then having that consumers device get hacked, they get scammed etc. Your devices fault. Soon that won't be a shrug and "its the nature of the devices", "it's the consumers fault."
I don't think those dogs are far from your door.
When the InfoSec/PenTesters have to pass your product. When every Monday you receive a new updated list of libraries, tools and framework versions which are now BANNED outright from use. Every single project in current use, must be upgraded immediately.
If that happens to be a bug in STM-HAL Verion 1. 2. 3 and version 1.2.4 won't be released for 2 weeks because STM are slow.... it's YOUR problem. At worst you have to ask for an temporary "capability" but that requires a lot of higher up people to approve why you want to put/leep insecure software into production.
-
I feel it fair to give back one point to the MCU pros.
You do have a partly unique challenge. In software security we would consider "Physical access to the hardware" == "Game over". If the perp can sit down at the physical machine, you are not stopping getting at least access to the machine, if not the data.
In MCU space, 99% of the time the device is sitting in the user or abusers hands.
In my view the MCU should always be considered compromised and zero-trust principle regarding any and all communications or otherwise it has with the outside world... such as when it phones home. That's pretty much how we treat client connections, almost across the board. "Least Trust principle."
-
You want 10 year old software to "just work". Right. Unless it's been maintained it wont
That's not my experience at all, and I probably push the boundaries here more than anybody else ;)
I run a ton of 20 year old tools in a XP VM. They were basically pre-XP, even WFWG tools, like Protel PCB 2.8, 1995. But they ran under XP OK. Win7, especially win7-64, breaks them, hence the VM.
I got 10-20 years out of these before moving them into the VM.
Just wait till you get to some area which has legal certifications for what you do. Then try and use ANY software that is more than a few months old to meet those requirements.
Never seen such a thing, and would not touch such a liability.
All USB ports and all comms ports on physically machines are locked down to prevent rootkit USB keys and other exotic MCUs.
That is a long term drift now, for many years. Corporately, you roll out locked-down PCs.
Soon doing so and then having that consumers device get hacked
In 99% of embedded cases there is no physical (access control) security so there is no security whatever.
Every single project in current use, must be upgraded immediately.
I would not work in such a field :)
In MCU space, 99% of the time the device is sitting in the user or abusers hands.
That's what I typed above, before I read your 2nd post :)
Hence back to the old debate that if you are selling IOT boxes, your customer simply must not install them on some "open port". Lots of reasons, starting with the impossibility of deploying firmware updates. If you are selling a box which sits on an open port, the ch-i-n-k-s will be in there in hours if not minutes (faster if there is a published DNS record) and no IOT box will withstand that, if it has any sort of "attack surface" e.g. an obvious remotely accessible file system. A lot of IOT boxes are running linux and they have basically no hope because everybody knows where to start. Whereas if you sell a box which is fully custom, has no evident OS, with a 32F417 whose attack surface is a RJ45 + PHY + ETH + LWIP then somebody might DOS it and maybe crash it (I am sure LWIP can be crashed with malformed packets) but that's about it. Obviously HTTPS does not help at all.
If I was making remote access gear for substations in Ukraine then that would be different :)
But this is digressing. I just don't see what advantage a commercially licensed IDE would have over Cube, in these scenarios. It is just an editor + compiler platform. Would your customers object to using some free PCB software?
-
You want 10 year old software to "just work". Right. Unless it's been maintained it wont
That's not my experience at all, and I probably push the boundaries here more than anybody else ;)
I run a ton of 20 year old tools in a XP VM. They were basically pre-XP, even WFWG tools, like Protel PCB 2.8, 1995. But they ran under XP OK. Win7, especially win7-64, breaks them, hence the VM.
Agreed. Having the ability to run old stuff in VMs is a real blessing. I'm very sure I can support all the projects I have made over the past 25 years. I have all the software available on my PC (I mean, on my PC as a file I can access in seconds, not somewhere on a floppy disk in a box). And if a VM doesn't do the trick, you can always use an emulator.
-
You want 10 year old software to "just work". Right. Unless it's been maintained it wont. Projects in work, maybe a year, maybe a little more, but all projects need to keep moving or they build up cobwebs. Cobwebs - "This used to work, why does it not any more?"
Non-sense. I use lots of software from last millennium. It all works very well. Believe me or not, there were times when software wasn't as buggy as it is now.
BTW: The "maintenance" is one of the root causes which makes the modern software so buggy.
-
For many years it was very clear that the best version of a given program was the last release before it was either abandoned or replaced by a new major version.
And it makes perfect sense if you think about the software business cycle.
It applies to all software. CAD/EDA, which was always full of bugs (due to complexity right on the edge of computing), and the vendors were constantly releasing new versions because - absent the rental option - the only way to maintain the money stream with a product which basically works just fine was to constantly pack in new features. It is true for all M$ stuff too; the last versions of winXP were outstanding and XP remains popular in industry, running all kinds of process monitoring and test stuff (the "lack of security" is BS in these applications). Same for win7-64, for which there is still an update process (simplix). Same for graphics apps.
With Cube, we aren't there yet and may never get there because
- it is based on Eclipse which is not an ST product
- ST seem to think Cube is for hobbyists
- it is not a direct money generator (but ST don't have to support it, and indeed don't, as is obvious from their mostly dysfunctional forum)
- it is written in Java, so it is beyond any hope of "fixing" because with this lot you have no hope
(https://peter-ftp.co.uk/screenshots/202303260916780218.jpg)
Yes I know only a small % of those 18k files are directly related to Cube and its operation, but still... no hope.
-
With Cube, we aren't there yet and may never get there because
- it is based on Eclipse which is not an ST product
- ST seem to think Cube is for hobbyists
- it is not a direct money generator (but ST don't have to support it, and indeed don't, as is obvious from their mostly dysfunctional forum)
- it is written in Java, so it is beyond any hope of "fixing" because with this lot you have no hope
(https://peter-ftp.co.uk/screenshots/202303260916780218.jpg)
Yes I know only a small % of those 18k files are directly related to Cube and its operation, but still... no hope.
Good you finally understand it, good that you are a hobbie-ist and not a company that depends on that Cube crap to make products to generate revenue. ;)
-
Those files as I have repeated told you are mostly documentation and examples.
Delete them and stop whining about them.
I gather there is an ocean between us in terms of software development. You pair honestly sound exactly like amateurs in terms of software.
It all comes down to complexity. MCU projects are so often Single, One man band endeavours you will never actually have to do any software engineering, so you just don't understand it, evident from this thread.
Since you know what's wrong with Eclipse. Would you mind telling which parts you think are written in Java and which arent?
-
No idea, of course, and why would I need to know?
Why get "personal"? Why not write something helpful? Well, this is the internet, of course ;)
-
Does anyone know if there is a way from Cube to get the versions of the GCC tools?
The only way I know is to change into the directory where the tool executables are and run something like
arm-none-eabi-gcc --version > toolsversion.txt
-
Why get "personal"? Why not write something helpful? Well, this is the internet, of course ;)
Sorry, I was in a particularly grump mood yesterday. You are right, no need to be personal.
-
From th
Does anyone know if there is a way from Cube to get the versions of the GCC tools?
The only way I know is to change into the directory where the tool executables are and run something like
arm-none-eabi-gcc --version > toolsversion.txt
Not sure about from the GUI. But if you want to know for the purpose of your build process, look for info on adding "makefile.defs" and "makefile.targets" to an Eclipse project. I've used those to add extra defines and steps to my build process, while still being able to keep it within STM32CubeIDE, to do various things. You could certainly add something in there to run the above command, and then place the output somewhere useful.
In my case, its stuff like embedding build information in the binary, embedding checksums, and producing output in formats suitable for UF2 and DFU.
-
The default maximum is a couple of thousand lines
Make sure to give the indexer enough memory
Interesting. Where is the config for this?
and start finding out that also there life ain't perfect.
Nobody said it was :)
What is probably most puzzling is that a $14BN company can't fix this - a primary tool for generating code for its chips. Or maybe they feel that only hobby programmers use it?
i spent 12 hours trying to use it and gave up. I'm sorry but if you are willing to use a tool that is so clunky to the point that a clock division register entry does not subtract 1 from the number you put as it will add one in the hardware then yes, if you use this in your professional work, you must be some damn amateur.
What happens when you need to use counters that share a clock source? Micro controllers are not computers, to try and treat them as such is childish. Any application you create will need to take into account the workings of the chip because the combinations are endless and no "configurator" will ever be able to do that and be easy to use, it's easier to just use the damn chip. so grow up, and realize that you will spent 10 times the time writing your application code anyway, and if you write the code for your peripherals you will be able to make your life easier. Configurators are for people who just don't know what they are doing, it's simply a marketing tool for the stupid to get sucked in by.
-
I hope you are better now.
Let's not forget how complex STM32 products are. Many developers have to use these imperfect tools and building blocks to be efficient. One cannot get TouchGFX or the AI components going if one starts reading reference manuals about the clock system. If there are errors that deserve research, no problem, as all components are open source, so one can debug into them.
There are people making good money using this approach.
Regards, Dieter
-
in order to setup basic hardware you have to be very familiar with the chip, you have to read the datasheet (manual) and understand it, or you won't get anywhere with the configurator as nothing is explained. My junior colleague told me to look at examples and watch videos. Yes I have to watch a 10 minute video for a 10 second segment that told me the function name I needed to turn the damn counter outputs on.
It took me hours to get a counter working, I then took up my SAMC and wrote code to generate a PWM in half an hour, a counter type I was not familiar with... because I understand the hardware of these sorts of things.
With an ST device I still have to read the datasheet and then figure out cube, it actually takes longer. Yes high level stuff cannot be written quickly and I'd like to find that off the shelf, but then if it comes glued to a system that is just a nightmare, well it's as good as proprietary.
I don't know if this higher level stuff ever comes in a form where they just describe the hardware access required and you provide it.
No ST make no HAL, they make a HHAL - Hardly Hardware abstraction layer, I write a hardware abstraction layer.
-
Setting up basic hardware.... yawn.
I want to innovate. F you.
-
From what I saw of the STM configurator setting up hardware was as much work as just doing it. Yes sure, you get to use drop down lists, how cute, but if you don't know what the terms mean you are screwed, so you have to consult the datasheet, oh and watch random youtube videos because they created a system with no documentation, sweet. i spent half an hour setting up a PWM output from scratch (versus 4 hours with ST configurator) I've spent a week using that small bit of code as the final stage of pages of code for motor speed control loops, why do I even care if it took me 4 seconds, 4 minutes or 20 minutes, never mind 4 hours.
There is a class of electronics engineers that miss the whole point of their profession, they think that the solution to their project is always on google and they just need to set up some code in a configurator.
that is how the last subcontractor that my employer used made such a mess of a design that tens of thousands of pounds later I declared unworkable when i started and was asked to fix it. All because someone played engineer, could not even lay a PCB out that involved power and signals and after having it explained at least three times to them still do not understand what ground bounce is and keep talking about using thicker copper. They spent months trying to program around the issues they made and charged a fortune for their own mistake.
On the other hand I produced a basic working example of a more powerful machine using the same type of equipment with no problems. But I don't do code configurators so I can't possibly innovate, like design a machine that works, translating physics problems into software and appropriate hardware, no that's not me, you need a code configurator for that because it allows you to quickly try as many coding solutions as chat GPT could come up with to try and find the magical combination to a problem i made for myself.
-
The point is electronics people insist on building everything from scratch. I can't understand how you innovate if you have to do everything from the smallest possible blocks every, god damn time.
Software Engineering is about NOT doing that.
-
My first encounter with Arm Cortex was Kinetis. They did not provide the entry level tools, so one spent some two months to carefully implement the startup sequence including the necessary transitions from one clock generator to the other one, plus the NVIC stuff and so on. For someone infamiliar with ARM it was kind of an adventure. I remember testing for instruction cache efficiency and details of DSP support. When Kinetis disappeared we started using STM32. I also had an encounter with ATSAMC. There were small examples for each peripheral (like ADC, CAN, DAC, I2C, SPI) and one could combine them into an application, rapidly getting results.
In comparison the STM32 CubeMX tools and their libraries aren't bad. If somebody thinks he can do better, why not. No reason to rant about others.
Probably the rant is about something else. Maybe the pressure to use predefined libraries of unknown quality. Also it's a nasty situation for an embedded person if the ARM family one learned disappears, like it happened to us.
Regards, Dieter
-
The point is electronics people insist on building everything from scratch. I can't understand how you innovate if you have to do everything from the smallest possible blocks every, god damn time.
Software Engineering is about NOT doing that.
The problem is that you need to have a good framework / library to start with. ST's HAL is not that. I have tried to use it myself as well but it is horribly inefficient, non consistent, poorly documented and cumbersome to use so I understand Simon's position 100%. Fortunately I have my own libraries that are easely adapted to different hardware.
-
STM32HAL is a good framework / library to start with. Everybody can use it do derive their private version.
Others will use it all the time, only with minor changes. Many entry points in the HAL are defined as weak, so they are meant to be modified for each application.
Regards, Dieter
-
Only total experts would suggest going to an ST ARM32 just by reading the 2000 page RM.
I did read every word of the DS (300 pages?) when designing the PCB, and that worked 1st time, but doing the software by reading the RM would be horrible. A lot of the time the required information is just not there. Try interfacing LWIP to ETH on a 32F4, by reading the RM. It would take you years. Actually ST do provide some code for that but it needs fixes.
The Cube MX code generator does work well enough to get yourself started. I cut out the crap out of that code and it is then fine. Nowadays I write new code from the RM. But I am not revisiting the ETH and USB stuff; I don't want to go back to that in the rest of my life! That was originally done by someone else, working half a day a week, but he is no longer involved.
Nobody is suggesting that Cube should disappear, but it could be bug-fixed and more robust. Why exactly this is not happening, I don't know. Not a priority for ST, evidently.
-
The point is electronics people insist on building everything from scratch. I can't understand how you innovate if you have to do everything from the smallest possible blocks every, god damn time.
Software Engineering is about NOT doing that.
The problem is that you need to have a good framework / library to start with. ST's HAL is not that. I have tried to use it myself as well but it is horribly inefficient, non consistent, poorly documented and cumbersome to use so I understand Simon's position 100%. Fortunately I have my own libraries that are easely adapted to different hardware.
Yes. It's just that that is not what I see "out there". Maybe the content I am reading on here and on several other forums is unrepresentative, but all I see is people struggling with the same code as MCU engineers where in the 1990s. It's the same shit, the same routines the same problems over and over and over again.
When I start a new project on an MCU I get annoyed almost immediately because I have to rewrite the debug UART routines. Even with HAL this takes time. I get annoyed because it's completely against my grain. Yes, of course I can wrap my own library up and package it for re-use in my projects, but the fact this isn't just an off the shelf component for every MCU project baffles me.
Each and everytime you rewrite it you always introduce new and unique bugs. Because nothing is encapsulated it's all sitting on jelly and when one thing changes everything else falls over. It's just so ... eugh. Wasteful.
Write a UART debug library. Write it once. Test the wazoo out of it. Package it. Reuse it.
Add a bit of functionality to allow adding timestamps to debug UART output, write it once, test it, package it, reuse it.
Can you not see how exponentially faster development becomes? Yes, it becomes less efficient, especially if it's done badly. Yes space and power is limited on MCUs. Yes we in big iron waste vast amounts of hardware. The thing is. Hardware is cheap. Engineers aren't. Easy adaptable, flexible, scalable, reusable code scales exponentially with effort. The software I take to a week to write, includes other works from other engineers where the total amount of effort require to get from the low level MCU style code in the bottom end of the OS up to the business logic code in the application... you are taking about many, many life times of effort.
If you are rewriting that each and every project. It is of exactly zero surprise that MCU projects are so often riddled with bugs and miss-features. To be honest I don't think I have ever used an MCU based device that wasn't full of undocumented "features".
Even when you give an electronics hardware team a 32bit ARM core with 512Mb of RAM and 32Gb of Flash.... they still produce 1990s "VCR menu like" junk. The same stuff that infuriates the users the application is intended for. Case in point. Every single network appliance's built in web interface. That is what happens when you give a low-level C engineer the task of writing a UI. I can bet it's almost entirely based on "printf" templates and string subs with hardcoded HTML and Javascript in the C code. It probably took their team of engineers over a year to complete that UI which an experienced front end developer would have for demo the next morning... and theirs would adhere to the user interface best practices, accessibility, internationalisation, localisation, security and use of use.... all pre-canned because he didn't write it, he re-used it. He reused code that has been used in millions of projects around the world and has been extensively tested by researchers far beyond you and I.
Just try and go on github and find yourself some re-usable MCU code. Try and find yourself some 'testable' code. You will struggle. Why?
-
An example is the ESP32.
Rumour has it that Espressif hired some guy from some forum, who "knew everything" :) and they paid him to integrate it all properly.
So you got a good package which works out of the box...
Whereas ST is providing a "90% working" package which everybody has to independently fix. The same wheels have to be re-invented many times, because most people who have fixed code are not publishing it, due to laziness, having done it in company time, the company banning social media participation, etc.
-
Trying to pre-counter the "straw man" appealing to extremes replies...
I agree just because someone makes a fully automated CNC based wall drilling machine, does not mean you should use it, even if it's "free", to drill 2 holes in the wall to put a shelf up.
However it would seem in MCU world, you don't even have a basic masonry hammer drill. What you get is a collection of parts, a motor, a weight, a selection of gearboxes you take a week to configure after reading the manual.
You can go and look for other people's "drill code", but your mileage will vary because, that person will have used the collection of parts to make HIS drill for HIS project and HIS project alone and you will find it's not a perfect fit. His code is not configurable, flexible or dynamic enough to reuse, so you have to rewrite it.
Why would that person want to write code for other people anyway? This right here is where we get into professional ethics, disipline, future proofing, building relationships and understanding that if it takes more than one person to build, then a lot of the problems you will need to tackle are not at all technical, but they are still part of the engineering.
-
An example is the ESP32.
Rumour has it that Espressif hired some guy from some forum, who "knew everything" :) and they paid him to integrate it all properly.
So you got a good package which works out of the box...
Have you used it? The IDF? It's got it's own issues. It's monolithic for a start.
Also, that story about the forum guy was not about the IDF at all. It was the a subset of the bluetooth interface for the ADF. He already had an opensource implementation that surpassed Espressif's. So they re-used his.
That's perfectly normal in the software world. We like to help each other because we will receive in kind. You reap what you sow.
-
Not used the ESP32. It became popular during the covid madness when ST etc were not shipping (to distribution) but the chinese stuff was available. Last I heard was somebody having loads of fun integrating tinyUSB on the ESP32, and finding some quite subtle bugs.
I would never use a key part from china. The political risk is way too high. This guy acks that but says they got nice orders whereas with ST they would have shipped minus zero.
It's funny... my project was being developed when ST weren't shipping; I got 500 32F417 chips just before the world went mad, and it is approaching finishing just as the world recovers :)
Nothing is perfect, which is why I prefer to get good with one thing and stick to that. The investment in a CPU, dev tools, PCB design, etc, is massive.
-
The ESP32 however is not even in the same class of MCU as the STM range. It's a sooped up wireless module that happens to have more core power than it really needs and someone figured out if you strap 2Mb of flash to it, makes a great little Wifi/Bluetooth MCU platform. Once you start to try and use it you find it rather limited. The 8266 far more so. I believe the ESP32 has only 2 simplex I2S. Two hardware UARTs. One hardware SPI. One I2C and very little else. It is not highly featured.
I found it's IDF a bit like importing the entire STM32 firmware for not just your particular micro, but the whole range all at once, wrap it in at least 3 layers of C++ ObfuscationOritentedProgramming and then release at least 2 or 3 different incompatible versions and a matrix of compatibility with other IDF add-ons. Getting anything detailed work with external hardware simply doesn't work and forces you into those layers of OOP to try and work out WTF is happening.
After 3 evenings trying to get a codec to work with I2S with with 3 "working" examples, I failed. One of those working examples probably did have the correct config, but it was too confusing to tell what config was what through the whole "kernel style" project configurator and the build config, output platform settings and flash partitions.
I still intend to return to the ESP32 and learn it a bit better, but I prefer using CubeMX and keeping my code separate from HAL, or warpping HAL up into little boxes where it can't intervene unintentionally. If I am to create a new project today that requires Wifi or bluetooth I will use my dual MCU board and just use the ESP32 with it's default factory AT firmware as a wireless module.
STM32 HAL isn't perfect. In some places it's a step in the right direction. In others it's a mess. I think it tries to do to much within the limited facade it presents. This makes the layer between high level config and low level details too thin and usually requires the inner workings be understood to diagnose the problem. A clear sign the "library" is not ready to be a library. The fact they provide the code should just be a reference bonus and debug assistence, it should not be required to understand how to use it.
On a more grander scale. If I ask myself how I would fix the issues in MCU world and what I would suggest for reusability? I don't know. Not an easy task. How do you encourage code reuse and sharing in a mostly proprietary drivin industry?
Take STM32-HAL for example. Let's get that bad boy out of STM32's malpracticing paws and get it on a proper open source eco-system and start encouraging feedback and pull requests for people who contribute bug fixes, facades, features and big prizes for those who contrib documentation.
-
Take STM32-HAL for example. Let's get that bad boy out of STM32's malpracticing paws and get it on a proper open source eco-system and start encouraging feedback and pull requests for people who contribute bug fixes, facades, features and big prizes for those who contrib documentation.
But then how would every single engineer take pride in writing their own HAL, brag about how it makes them superior on forums, and then never share the fruits of their labor with anyone?
In a more specific example this, there is the "opencm3" project, but I don't think it covers very much of the ecosystem or necessary feature range. And its general to the ARM Cortex series.
-
Take STM32-HAL for example. Let's get that bad boy out of STM32's malpracticing paws and get it on a proper open source eco-system and start encouraging feedback and pull requests for people who contribute bug fixes, facades, features and big prizes for those who contrib documentation.
Isn't that what libopencm3 was supposed to be ?
Besides now you preach another song, first it was re-use what is there and HW engineers re-invent and build everything from scratch,
and now you say lets again invent another HAL ;)
BTW: from my own experience, at least embedded SW engineers are just as bad as HW engineers when it comes to : not invented by me so lets start over again.
I think it is not HW or SW related, it is everywhere, from authors of novels to artists to managers.
Every person is unique and that unique way of looking at things makes another persons unique creation not as it should be.
-
Yes. It's just that that is not what I see "out there". Maybe the content I am reading on here and on several other forums is unrepresentative, but all I see is people struggling with the same code as MCU engineers where in the 1990s. It's the same shit, the same routines the same problems over and over and over again.
When I start a new project on an MCU I get annoyed almost immediately because I have to rewrite the debug UART routines. Even with HAL this takes time. I get annoyed because it's completely against my grain. Yes, of course I can wrap my own library up and package it for re-use in my projects, but the fact this isn't just an off the shelf component for every MCU project baffles me.
Each and everytime you rewrite it you always introduce new and unique bugs. Because nothing is encapsulated it's all sitting on jelly and when one thing changes everything else falls over. It's just so ... eugh. Wasteful.
Write a UART debug library. Write it once. Test the wazoo out of it. Package it. Reuse it.
Add a bit of functionality to allow adding timestamps to debug UART output, write it once, test it, package it, reuse it.
And this is a common enough use case, that you really shouldn't have to write that code... at all. You should just be able to take some off-the-shelf logging package, write a few support functions unique to your platform's UART peripheral and/or other requirements, and go with it.
In the world of normal software engineering, logging libraries like this are extremely common. There are many to choose from, both built into frameworks and standalone. So I was flabbergasted at the response I got on these very forums when I tried to ask for suggestions about one for embedded. Most of the replies were from people who simply had no clue what a logging library was, and simply thought I needed help figuring out how to write a UART function (or suggestions for an alternative that runs over SWD, of which there are several). The rest were of that "why do you need this, just DIY" nature.
Among the mess, I did finally find something. But it very much had the feel of one guy's side-project, and is likely not that well known, but it got the job done.
-
The point is electronics people insist on building everything from scratch. I can't understand how you innovate if you have to do everything from the smallest possible blocks every, god damn time.
Software Engineering is about NOT doing that.
within my line of work as with most people you do the same things over and over with the same chip or same series and you reuse your code. That is the point. If you write code that works for you you will reuse it over and over, which beats the hell out of having to sort out the next little gotcha in some system that has no documentation.
-
Among the mess, I did finally find something. But it very much had the feel of one guy's side-project, and is likely not that well known, but it got the job done.
Well, there is always the tradeoff between debugging somebody else's code / adapting it to make it fit or writing your own. In the end it depends on what is the least amount of work.
-
Probably the rant is about something else. Maybe the pressure to use predefined libraries of unknown quality. Also it's a nasty situation for an embedded person if the ARM family one learned disappears, like it happened to us.
Regards, Dieter
My rant is about the dumbing down of the industry. Every kid now that can use a code configurator thinks he is an electronics engineer. My junior colleague sneers at the idea of setting a register up, he uses the ESP32 and expects to never have to deal with the hardware. Until I tell him that the serial port must reject unwanted bytes but not reject every message just because the message start byte is not at the start of the ring buffer he gets dumped by the serial driver.
I use what I like, I don't feel pressured to use what someone else thinks is best. But if the time that these kids young and old spent watching endless tutorials that contain tiny pieces of information or trying to copy "examples" on actually learning something meaningful the industry would not be full of amateurs.
I'll explain again if you can distract yourself for 5 seconds from the configurator. You cannot properly develop a complex project without reading the datasheets even with a configurator. For example, often counters share a clock source. So you make look at a chip and see how many counters it has and then want to set each one up to do something different. Oh but the configurator will warn you of this - yes sure dick head, you want to get that far into your project before you get the chips constraints forced on you by reality as the configurator tries to hold you little hand. Just grow the hell up, take the little time it takes to learn about what you are using and what it does rather than stumble on how it works by accident.
If I have to read the datasheet anyway what is the point of the configurator. Interrupts in ST world are nuts. So the uart has an interrupt, each port has an interrupt line, so do you write code for this? no of course not that would be too efficient. You instead write code to handle the specific event, this code gets called by the interrupt, you know an event linked specifically to that port, whereupon the first thing you do is figure out which port is having the interrupt for the type of event - totally backwards. I don't know if this is all just optimized out in compilation but I am not comfortable with it at all.
There is single application programming and there are operating systems, lets not confuse them. Because no pure computer programmer is going to make a good electronics engineer unless he learns about electronics instead of treating everything like a PC.
-
There is single application programming and there are operating systems, lets not confuse them. Because no pure computer programmer is going to make a good electronics engineer unless he learns about electronics instead of treating everything like a PC.
That statement highlights it works both ways.
In your example, in your way you need to know the interrupt exists and the code it calls... in advance. In an HAL it cannot know that and must provide functionality to all cases.
If HAL was done right the answer to your question on how it work would be "None of your business", you don't need to know.
As you do need to know, it's not done right.
Also, to throw confusion, if you studied computing you'd find that a HAL IS a component of an OS. You could argue that the STM32HAL is a partial OS. Certainly moving up to RTOS and Embed it gets closer to such.
The whole point of an operating system is to provide a basic layer of functionality for managing hardware and resources, usually between multiple programs. Mostly well overkill for MCU simplicity, but the notion is there.
Take a look at how the Unix specification is constructed for ideas. In particular look at the basic GNU pallete of shell commands. Do you see how each does a tiny little job. Just that job. No other job. They are absolutely fucking useless for anything (really) in isolation. However, armed with pipes and redirects there are very little basic applications you can't fabricate on a single line. THAT is software engineering. Take small units of software, make them work to do a small part of the other all job, then build a bigger more useful application out of those components. In enterprise you end up on top of hundreds of layers. A few layers really will help MC dev.
However, I'm sticking to my guns the issue to partly that electrical engineers are just trained to repeat everything. If they have 14 products to create and each differs every slightly, they will create 14 different designs with 14 different sets of components and write the MCU code bespoke for each... BECAUSE they differ in the n'th degree. Learning how to abstract the common and concrete the variable at each level and encapsulate it such that only the differences need catered for in each of the 14 projects, makes 1 very hard project to write and 14 configs.
The other large part is proprietary lock ins. Hardware companies just don't share software it's not in their nature.
-
There are some parts of HAL which look like they started down a good route, but then promptly stopped when the electrically engineers started whining about change.
The callback and handlers system. You will spot efforts to decouple that across the board. However most of the upper layer functions are IFDEFed to disable it.
It allows things like "laymans" dependency injection. Basically, if they continue that endeavour it will lead to a uncoupled code with multiple "hook points" to hang your own code in.
It's reversion of control pattern. You use a big generic function call to do all the wonderful things. When that big generic function call gets to the bits and bobs of your actual application it hands that single part over to your "deligate" or "handler". Done to the extreme, all components used within the larger framework can be swapped out and replaced with custom overrides.
That leads to another pattern. "Convention over configuration". You make the frame work, out of the box default to something sane and useful in terms of "boiler plate code" such that nobody need to write boiler plate code and only need to touch it if they want to over-ride the convention.
I can see the sparks the later would introduce to an electrical engineering team.
-
It cannot be cost effective to embark on a project where the CPU has a 2000 page RM, without having working code examples.
Some people here say so but they are super clever and already know it all.
The proper way would be for ST to spend a totally miniscule % of their $14BN revenue, say $80k, on a "social media specialist" who is also a really good hardware and software dev.
The truth is that they are scared. I have seen this fear all the way back to early 1990s, with Compu$erve forums. These companies never learnt how to manage social media.
A part of my day job is a forum admin and I see the same there now. Companies which dominate that industry, and companies which could and want to compete with them, are too scared. They have (basically) told me so.
And the ones that do participate mess it up by employing stupid people who offer input which is banal, over-simplified, arrogant, downright rude... And then they complain that it didn't work for them!
As a data point, take my project.
32F417
FreeRTOS
LWIP
TLS
FatFS
ETH
USB (MSC & CDC)
A ton of stuff which I mostly wrote e.g. boot loader, loads of essential functionality. Factory test code...
A guy who is more clever than I am spent about 3 years worth of Monday afternoons on all but the last one. He used mostly Cube MX to generate code snippets and then googled all over the place to find patches to make it all work. This is despite e.g. LWIP was an ST port of the generic open source LWIP! He would not post questions on forums, which probably doubled his time spent.
So he spent ~100 full time days (I have allowed a bit for half a day a week being pretty unproductive) making stuff work which should have worked.
Why was he part-time? Because I could not afford someone full time. A very small business, etc. Also it was to some extent a technology demo project, to see what could be done, and the final form defined afterwards.
That amount of work is totally unacceptable.
I spent about 2 years, about a 50% duty cycle but actually many hours and days working at home, doing the last item. Learning C, learning Cube (of which I know about 1%). That's would also be unacceptable in a normal job but it's because it is my company, I am not young, not that clever, and I am extremely careful in writing and testing code (did 30 years of assembler, and hardware, on simpler chips).
There is no easy way. These chips are immensely complex and the above "open source" software varies from great (e.g. FatFS) to not good (LWIP or TLS). And all of it is totally unsupported - partly because it is old (LWIP goes back > 15 years) and the coders sorted out girlfriends years ago and moved on, and partly because the whole open source scene is like that. In some cases people make money integrating OS software but not in this case. I have not seen a "Magento-like" ecosystem in embedded.
As a lone operator, some things you just can't do. A product like this will take a few years to do, if you start with no experience. In the Z80 days, it would be a few months. Today it is 5x longer even for basic code, and much longer if integrating modules (like above) which nobody supports, almost nobody understands, almost nobody can test if you did it right...
-
It cannot be cost effective to embark on a project where the CPU has a 2000 page RM, without having working code examples.
Some people here say so but they are super clever and already know it all.
The proper way would be for ST to spend a totally miniscule % of their $14BN revenue, say $80k, on a "social media specialist" who is also a really good hardware and software dev
The truth is that they are scared.
The ugly untold truth is that they are not interested in small businesses that buy 1 reel stm32 per year. Peanuts.
They are interested in the big numbers. My previous company negotiated about a few million microcontrollers a year!
As a software dev you get a personal registration at ST where you can ask your question, you can sent code snippets , you get a personal answer within 24 hours. Not that they directly solve it but they will help you as much as they can.
My experience with ST as a sw dev eight years ago for a major company was excellent.
-
The ugly untold truth is that they are not interested in small businesses that buy 1 reel stm32 per year. Peanuts.
They are interested in the big numbers. My previous company negotiated about a few million microcontrollers a year!
That makes sense, and it's not particularly "ugly". A company needs to make profits. Profits for a big MCU vendor is not with hobbyists and 1-person companies.
Good thing is that it's still doable with some effort. While it wasn't like this 20 years ago (which Microchip at the time completely changed, and then ATMEL.)
This is why the RPi initiative with the RP2040 is an interesting alternative, but unfortunately it's only 1 chip so far (and relatively entry-level performance) and only 1 vendor. A bit restrictive.
-
That makes sense, and it's not particularly "ugly". A company needs to make profits. Profits for a big MCU vendor is not with hobbyists and 1-person companies.
Good thing is that it's still doable with some effort. While it wasn't like this 20 years ago (which Microchip at the time completely changed, and then ATMEL.)
Totally agree.
Remember embedded microcontroller development late eighties/90s.
For hobbieists small firms impossible to do anything:
- Datasheets unobtainable.
- samples ? How many boxes were you planning to order ?
- debugging? You have to buy a Lauterbach ICE for $4000
Etc. Etc.
But I do understand peter frustration but to be honest it is pretty naive to think that 12 year old example code of LWIP is still relevant these days. There a specialized firms that will sell you IP+TLS packages and most important they will update them with the latest security vulnerabilities. Unfortunately also there yet again is that steep price you have to pay. I don't know the current market of these I left that field six years ago, it was an unwinnable fight. Every month there came more hacks and vulnerabilities, my point of view never ever do this yourself, you just can't update. You need the specialist firms.
Look at big company NAS makers from all the brands havingbthousands of employees only Synology was not affected.
-
Every month there came more hacks and vulnerabilities, my point of view never ever do this yourself, you just can't update. You need the specialist firms.
I don't agree; if you want a box which is open to the internet and needs to be resistant to the best of chinese and russian attackers then forget any embedded solution. For a start you probably can't upgrade it, and the upgrade process itself is a huge back door, so you need certificates, but these are worthless unless you have 100% solid physical security of the product.
Most IOT boxes are in the hands of the attacker :)
That level of resistance needs a proper server, like Centos or Linux, and NGINX or Apache, the usual heavy duty heavily tested server side stuff used these days. And firewall them; in some applications accepting traffic only from an IP range.
Nothing wrong with LWIP and anybody telling you otherwise is making you pay for nothing :)
-
It all depends on the application. Any discussion without context is useless.
-
The context is whether the Cube-packaged stuff like LWIP/MbedTLS is actually insecure and will get successfully trashed if deployed on an open connection.
It certainly is - it has to be simply because it has not had the attack exposure of the full size server systems - but I am saying this doesn't matter, for the reasons given.
Quite what I would do if I was building something like a domestic heating controller with remote control capability, I don't know... TLS is of little help because it runs on top of LWIP.
Maybe LWIP is a lot better than people say, and the commercial alternatives are just getting money for snake oil?
I am on mailing lists for LWIP and MbedTLS. The LWIP one is pretty quiet and there are very few replies to questions. Very little going on. The MbedTLS one is more "energetic" and regularly talks about security improvements, but the stuff in there is the same stuff we have been heating for many years. For example the latest version zeroes some buffers before heap de-allocation, which is "nice" but what the hell does that do? Nobody is going to get access to freed block RAM until they have totally penetrated the product; basically running their own code on it, but how would you do that? In most scenarios there is no filesystem on which you could install some executable, so the attacker's code would need to be running in RAM. I think this is mostly snake oil.
-
Every month there came more hacks and vulnerabilities, my point of view never ever do this yourself, you just can't update. You need the specialist firms.
I don't agree; if you want a box which is open to the internet and needs to be resistant to the best of chinese and russian attackers then forget any embedded solution. For a start you probably can't upgrade it, and the upgrade process itself is a huge back door, so you need certificates, but these are worthless unless you have 100% solid physical security of the product.
Most IOT boxes are in the hands of the attacker :)
With ADR this is such a typical understanding of IT security that it's usually the number one type of case study we look at.
They don't need an open port. Very few hacks actually come via vectors you know about.
As an example. You can take control of a Tasmota device and use it to infiltrate a network, gain full access. Without even getting out of your car. The attack is very simple. Blast it with jamming until it reboot, repeat. Eventually it will come up in it's "Emergency Access Point" mode with a default password. BOOM we are in. Quick OTA flash of the red-carpet payload. Then where can we get to from this poxy little ESP. Well, that's usually simple. The Wifi password is stored un-encrypted in the flash in a known location provided in the Tasmota code. No need for a red carpet root kit, just ask it for the password and you have FULL access to the house/building network.
It's not even like these are really smart diligent people. They aren't. They just buy exploit scanner packs and tools. Run them in as many places you shouldn't as possible you will get hits all over the place from Wifi devices. My network neighbour hood has a few unsecured devices on it and a few which known hacks.
Now some of the hacks and attacks you see on the news are over-inflated and not really of consumer interest. They are more of interest to large companies who have people with physcial access they do not trust. Security does NOT end if you have physical access. Consider a bank cash machine.
A would honestly suggest even a quick dip into the world of modern IT security to see how much of a wildwest it is and just how creative and innovative hacks can be.
I found that unless you think like a scum bag criminal you won't think yourself ahead of them.
-
Well, yes, if somebody has set up a WIFI AP which contains the credentials to connect to your factory LAN, and that AP is physically accessible to an attacker, then your security is zero. Because that AP must store the credentials in plain text somewhere. Or encrypted under a key but that key must be stored...
I too remember the days of Netstumbler, WIFIfofum, etc :) They probably still work in some places. In the old days, I could drive 10 miles and log 600 unsecured WIFI APs...
But you cannot control your customers' stupidity. What you don't want to do is sell a box which can be hacked remotely. Unfortunately IMHO this is not avoidable if running "simple" embedded products. I think most IOT devices can probably be easily crashed by malformed packets, but that in itself won't get you anywhere.
Cash machines use a special tamper-proof module to store important stuff, like the key which is needed to change the PIN number on your card. This is a surprising weakness of the whole system. Someone told me many years ago the PIN number is (or was) encrypted with DES and stored on the card thus. So the cash machine needs to contain the DES key. DES is highly secure in a commercial context (yes I know the hype all over the internet about deprecation). It uses a module which (I know only how it used to be done years ago) you have the circuit board, encased in glass which contains a wire, and if you get in you break the wire, and the SRAM holding the key(s) is erased. This stuff was developed to a high degree in the 1990s onwards. I had a customer in that field. Nowadays, smartcard chips claim to be as good but probably are not. If you need key and certificate storage which is resistant even in the hands of an attacker (a cash machine is easy to steal, with a JCB) then you need to use something like this. And it is a hassle, not only because you need to use the CPU in the smartcard for some processing. I designed a product many years ago with the Siemens 44C200.
-
The context is whether the Cube-packaged stuff like LWIP/MbedTLS is actually insecure and will get successfully trashed if deployed on an open connection.
It certainly is - it has to be simply because it has not had the attack exposure of the full size server systems - but I am saying this doesn't matter, for the reasons given.
You can discuss if the STM32 has enough beef to be interesting to hackers. But as paulca already stated it can be the first step into the network to jump from there to other more interesting and capable equipment.
Anyway security is a specialists job, to the outsider every hack looks like "oh that is far fetched no-one is going to do that".
The problem is that those hacks even the ones from academic perspective are published and every hacker follows those publications and sift through the interesting ones.
-
But you cannot control your customers' stupidity.
But... you CAN find yourself liable for it.
Consider the volume of "Smart" devices being sold. Do you really think they are all being bought by IT smart people? Do you think people understand if their Ring Doorbell is being watched by pe-dos? No.
However, if you are a large organisation selling that platform to customers in enough quantity that it gets national press coverage surrounding its vulnerabilities. If you are shipping a few 100 or a few 1000 products, you might get away with the 2 or 3 people who get hacked. If you are shipping a million products a month and 10s of millions of people are using your devices. You will absolutely find yourself becoming responsible for your customers security or being put out of the market by other means.
-
However, if you are a large organisation selling that platform to customers in enough quantity that it gets national press coverage surrounding its vulnerabilities. If you are shipping a few 100 or a few 1000 products, you might get away with the 2 or 3 people who get hacked. If you are shipping a million products a month and 10s of millions of people are using your devices. You will absolutely find yourself becoming responsible for your customers security or being put out of the market by other means.
What I saw in the past for instance with the famous "babywatch camera's" that the company can not fix it and just declares the product obsolete , stops any (external server / update) support and emails the customers that did register their product that it should not be used anymore.
Really nice huh? People bought a $99 babywatch camera and two months later they are mailed with don't use product it is unsafe, support ended.
I don't think a EU/US company would get away with this, on the other hand who is going to file a lawsuit against them ?
-
I don't think a EU/US company would get away with this, on the other hand who is going to file a lawsuit against them ?
Yes, getting the liability to stick is an issue. Localities have outdated "unsafe product" legislation which is incompatible with the current import market on ebay and amazon.
Amazon have been fined, called out etc. repeatedly and repeatedly they remove products from sale, based on "consumer" and "consumer lobby groups" are dodgy fake CE stamped goods. Yet, I'm sure it's now just a balanced line item with efforts to prevent them appearing in the first place. I'd figure Amazon can get away with a little "better to ask forgiveness than permission".
If you buy from a UK seller you have more rights in the UK, it's not meant to work that way, but it does.
Most people know this. If you buy from a chinese supplier, you are NOT sending it back, even if it arrives smashed. It's buyer beware. If you want more consumer security you have to buy from someone who has made their product meet those more stringent tests, that's been through industry approved pen testing, electrical testing etc. Then if it sets fire to your bed or lets hackers in through negligence you might have an avenue to claim, if the company still exists.
-
Let's get to something specific.
I want to make a "babywatch" camera.
Does this come up on an open port, having used its installation utility to open a port in your "PnP" domestic-grade router? Or does it just have a wifi connection to your LAN, and you point a browser to that IP (etc) when you are in the room next door?
What is the attack surface, and how would a commercial TCP/IP stack help compared to LWIP?
If you think you can sue the company from which you licensed the commercial TCP/IP stack, you are kidding yourself :) First you will find anything really hard to prove i.e. how did pics of your baby appear
on dodgy Russia-hosted websites... Most likely because you used credentials of admin, and your birthday :) And if this device was LAN-internal only, then somebody parked outside your house and logged into your home WIFI with some obvious credentials, and then what exactly did you get by paying for that stack?
-
You can start here:
https://www.hackers-arise.com/post/google-hacking-the-ultimate-list-of-google-dorks-to-find-unsecured-web-cams (https://www.hackers-arise.com/post/google-hacking-the-ultimate-list-of-google-dorks-to-find-unsecured-web-cams)
Google will find you some.
However, most of the high profile "hacks" regarding baby cameras have been online cloud services. Almost all consumer camera devices these days do this. Consumers cannot be expected to figure out how to provide their own remote access, so videos get uploaded. That focuses the attacks onto a bigger basket of eggs.
-
That is at least 20 years old. It started when AXIS started selling lots of ethernet connected cameras. These had an HTTP server which could stream the video. Most people installed them and didn't change the default credentials. As the article shows, google finds these and using suitable search terms you can find them.
It is the same procedure as finding all PHP-BB forums which run on a specific version of PHP and a specific version of PHP-BB. Or Magento online shops which have not been patched to a specific level.
Marketing a "cloud server" is the right way for "IOT" boxes to be online (they are thus a client not a server) but it crucially delivers a steady income stream to the mfg because he charges for the server :)
I still see nothing on the topic :)
-
If your online embedded device has an unique identifier for instance shodan can find every one of them that is accessible.
And that is amateur time, real hackers have uncountable bots looking 24/7 for all kinds of devices, entry points etc.
https://www.shodan.io/ (https://www.shodan.io/)
-
Marketing a "cloud server" is the right way for "IOT" boxes to be online (they are thus a client not a server) but it crucially delivers a steady income stream to the mfg because he charges for the server :)
True if all your ports are closed for the outside and the IoT device just phones home and mutually uniquely identify themselves to the server according to the latest security specifications that is pretty safe.
-
No disagreement there. In fact far less "security" is needed then, because the IOT box is
- behind NAT
- doesn't need a published DNS record
- can be firewalled to not accept inbound traffic outside an established session, and allow outbound traffic only to a known server IP
- not accepting inbound traffic anyway (no server service) by design
- it's hard for an attacker to even discover that it exists, let alone what it is
But, still nobody has offered a view on why a commercial TCP/IP stack is better than LWIP :)
-
But, still nobody has offered a view on why a commercial TCP/IP stack is better than LWIP :)
Because they keep developing, testing and you get support. At least the good companies will.
Although you mentioned 100 mandays work, which sounds much, that is pretty much on par with my previous company experience.
Does ST nowadays also give code for the PHY because I remember that was also a PITA to get that properly working.
-
And indeed commercial of the shelf can also be a pitfall:
https://www.eevblog.com/forum/microcontrollers/anyone-used-the-wiznet-ethernet-chips/msg717973/#msg717973 (https://www.eevblog.com/forum/microcontrollers/anyone-used-the-wiznet-ethernet-chips/msg717973/#msg717973)
-
Interesting thread from 2015. Yeah - all been done before.
The 32F417 talks to the LAN8742 via a funny 64 bit USART. ST supply the code for that and it seems to work. I played around with that a little bit when doing a fast data save function on loss of power; shutting down the LAN8742 saves about 50-100mA immediately and was the lowest hanging fruit of all the chips I have. I posted the full details here :)
I don't believe a commercial stack is better than a free one, inherently. Commercially, you have far fewer users writing code, especially ones doing different stuff and exercising edge cases, especially if you charge 4 figures. And a key thing is that in the commercial sphere you will always cover up issues. If one of your dev customers posts about a problem on some forum, his throat will be cut immediately (his support will be terminated). I've seen this many times in other areas.
True about support, but LWIP is about 16 years old now. Nobody is too interested in it. Those who could help have written it all before (mostly).
-
Is there any solution for Windows to Cube's focus capture?
When you build a project, Cube IDE captures the keyboard focus at the end of it, so if you were typing something in another application while building the project, a number of keystrokes will be captured into the current Cube IDE edit window.
-
Is anyone using Cube IDE with a Segger debugger and, if so, is the interaction any different?
I had a play with the Edu a while ago and it seems to work fine for simple breakpoints.
Can anyone comment on reliability? The STLINK connection fails usually after some hours but users report this as normal.
-
Can anyone comment on reliability? The STLINK connection fails usually after some hours but users report this as normal.
Call me stupid but I am glad that a high speed debug session will last an hour. Those are running at 10MHz or more. Any pulse in the environment (something heavy relay switching) can cause an error.
If I need to debug something that occurs sporadically over multiple hours or even days, I use my own breakpoint debug code. Just write to any interface/memory that is not part of the issue.
Usually I reserve a small part of RAM , fill it with the data if the issue occurs (breakpoint is replaced with small piece of code) then write it to an external NV storage device.
-
Interesting.
Yes of course normal debug output will always work.
I actually wonder if one could use the breakpoint system in that way. AIUI, the CPU implements ~5 hardware breakpoint (address) registers, and executes some piece of code when one of these gets hit. The ST / Cube / Eclipse handling of this is obviously marginal, but the original trap is probably 100% reliable.
It should not be too hard to do i.e. use breakpoints but not via the debugger. You need to write some code which, at the simplest, collect the register values. The Cube stuff collects variable values as well, which is more work but feasible where they are in RAM. Statics can be extracted from the .map file. Locals, not sure.
Bypassing the crappy SWD interface would be great.
One can drop the clock speed but it doesn't help much.
I don't think it is some simple signal integrity issue because sometimes the debug mode runs for days. For example I found that using the SWV ITM console for debugs breaks the debug mode pretty fast.
-
Can anyone comment on reliability? The STLINK connection fails usually after some hours but users report this as normal.
Call me stupid but I am glad that a high speed debug session will last an hour. Those are running at 10MHz or more. Any pulse in the environment (something heavy relay switching) can cause an error.
JTAG has an ability to recover from failures, so there shouldn't a problem if something goes out of sync.
-
Should, but does not :)
I have run a number of targets with a number of PCs and all of them lose debugger connection eventually. There is for sure much commonality there but almost everybody else has reported this problem.
Reducing the debugger clock speed, even down to silly values like 1MHz (and remember the STLINK V3 ISOL won't run above about 8MHz anyway) does not help. Actually, the AUTO clock speed setting is hardly going to be reliable because ST probably step through the clock speeds until it fails and then step back a bit.
ST uses SWD, not JTAG, but I don't know the difference.
-
I think I have found what is causing the random file opening in Cube.
In Debug mode, if you click this to restart the target
(https://community.st.com/sfc/servlet.shepherd/version/renditionDownload?rendition=THUMB720BY480&versionId=0683W00000c0r6b&operationContext=CHATTER&contentId=05T3W00001caeqx&page=0)
then it opens a "random" file but the file opened is the code which was running when the target was reset. Which file is opened, is wherever the CPU was when the above button was pressed.
So the file opened is not "totally random" but is not desirable to have it opened; it serves no purpose. It means that if you restart the target say 20 times, you get 20 file openings, and depending on where the CPU spends most of its time, you may get 20 different files, or fewer. If for example CPU spends a lot of time waiting on some mutex, then over 20 restarts you will get mostly tasks.c (the FreeRTOS main file) opened, but you may get other files so if e.g. the mutex is around some SPI code, you will get tasks.c and sometimes spi.c. Eventually you will get loads of different files opened.
This probably explains why some people get it much worse than others.
-
You can disable the whole feature. The issue then becomes, it won't open or switch to any files automatically on break points. You can still click the stack trace though.
-
Where is this config?
Not switching to the file where the breakpoint was is useless, however.
-
I finally found the config for disabling the automatic breakpoint in main().
Until a few versions ago it used to be under Debugger but then they moved it. In the new location, it was however grayed-out. But somebody found how to do it:
https://stackoverflow.com/questions/66566866/stm32cubeide-run-configurations-how-to-disable-set-breakpoint-at-main-if-gra
If you go into the config via this other route (which is totally not obvious) the option is not grayed-out.
Project / Debug As / Debug Configurations / Startup
(https://peter-ftp.co.uk/screenshots/202305191217094906.jpg)
And it works. F11 takes me straight to a running project. No more breakpoint at main().
-
One thing I find, which may or may not be specific to Cube and/or STLINK debuggers, is this:
If something happens on the PC with USB, say you plug in a USB drive and the PC does some sort of re-enumeration, it can mess up the debugger (via its USB cable) which then crashes or just reboots the target.
And Windoze sometimes does "funny USB stuff" on its own, without you doing anything.
A bit hard to deal with if you want to run debug mode for hours...
If you just want to run code, best to exit Cube and that seems to prevent the debugger getting screwed up. Better still unplug the USB cable. Unplugging the debugger from the target may be harder, depending on the connection.
And this is with STLINK V3 ISOL i.e. isolated, so it doesn't appear to be just a "spike", but who knows?
-
If something happens on the PC with USB, say you plug in a USB drive and the PC does some sort of re-enumeration, it can mess up the debugger (via its USB cable) which then crashes or just reboots the target.
I don't have much experience with ST, but I haven't seen this happen with other manufacturers (TI, FSC, etc.)
And Windoze sometimes does "funny USB stuff" on its own, without you doing anything.
A bit hard to deal with if you want to run debug mode for hours...
That can happen with anyone, especially if Windows is set to use weird power modes that, among other things, may put the USB subsystem to sleep.
-
It could indeed be some low power mode switch on USB (not supposed on a desktop PC but one never knows) but should a debugger affect the running target?
Obviously I can see Cube IDE shutting down a Debug mode (thus losing the ability to set a breakpoint etc) if the USB port goes to sleep, but the target should keep running. So I am suspecting something to do with the Reset signal from the debugger.
-
Disconnect it (RESET) then? It is not so important if your firmware doesn’t remap SWD pins. The core still can be reset by a write to AIRCR reg and usually there is a setting which kind of reset to use.
-
You mean here?
(https://peter-ftp.co.uk/screenshots/20230531285591816.jpg)
From the Cube IDE manual https://www.st.com/resource/en/user_manual/um2609-stm32cubeide-user-guide-stmicroelectronics.pdf (https://www.st.com/resource/en/user_manual/um2609-stm32cubeide-user-guide-stmicroelectronics.pdf)
(https://peter-ftp.co.uk/screenshots/20230531555602016.jpg)
Two of those options look like a register write...
-
It could indeed be some low power mode switch on USB (not supposed on a desktop PC but one never knows) but should a debugger affect the running target?
Obviously I can see Cube IDE shutting down a Debug mode (thus losing the ability to set a breakpoint etc) if the USB port goes to sleep, but the target should keep running. So I am suspecting something to do with the Reset signal from the debugger.
Once the Debug Probe is shut down from its USB port, there is a chance it will be inadequately powered from the target via a JTAG/SWD line or even via a secondary UART channel (if the Probe is furnished with such capability). This can cause inadvertent/spurious signaling that can disrupt the target (even your hypothesis of inadvertently resetting the target board).
-
Just a comment -->
I use to use cube IDE along with cube mx at my previous work. And noticed that these tools are sometimes especially buggy when updates have been done on both cube IDE AND OR separately by eclipse itself.(STMIDE is basically a "Distro" or flavor of eclipse). So according to me the biggest issue is that there are two different independent developer companies both doing updates that might effect each other.
Realized that it is best to avoid all updates as far as possible, and only updating when it is necessary for the current project. Also in the past I have had problems when I update cube mx but not cube IDE or rather vice versa.
Is anyone else think the same way?
-
Yes, updating is usually a mess.
I always delete the entire cubeIDE installation directory, including the hidden metadata folder in the workspace, then install the new version.
I have to reinstalll the plugins (Egit, etc) but nothing too serious, then import the existing projects and done.
-
Yes; my procedure, which I have tested many times, is
- do a clean install of Cube (having also deleted the previous version's c:\st directory tree)
- copy over the project to say c:\projectname
- import project into Cube using the project import into workspace function
- Clean project
- Index project
Most Cube settings reside in the c:\projectname in some .project .cproject .xml etc files so this copies them over. Not all; stuff like spell checker you have to set up in Cube itself.
Never used MX but seeing what it does I never want to :)
-
Meanwhile, for the past couple of years, I just install updates normally via the usual mechanisms, and it kinda just works fine. Its been a long time since anything broke my workspace.
I don't have 32 pages of rants and complaints, and the only major annoyance I have is that part where the debugger randomly opens a file.
Am I doing something wrong?
(Of course I probably avoid a lot of the minor annoyances by using CubeMX to generate the initial project code "out of band" and don't even have a .ioc file in my Eclipse/CubeIDE project for it to try to do anything with.)
-
Welcome to the club!
Currently I like it pretty much, it was a lot worse 1-2 years ago, the computer felt like was 15 years older, but it seems they finally fixed most of the issues after v1.7.0 or so.
The random file opening issue has been there for ages, nobody know how to *** stop it ::).
-
As we discussed elsewhere, your projects should be independent of any and all IDEs.
In most places checking in IDE files is considered taboo. IDE settings, paths, local build envs etc. etc. They are up to the individual dev.
Most problems come from customisations. The more you fiddle things away from default the harder it will be on you and... anyone else who uses your project, especially if you didn't follow the first two points.
If it is done right, then I can open your project in the IDE I choose and work on it along side you. Everyone should be free to check the project out and get it building in their IDE of choice.
IDEs however have other ideas. They would like to take ownsership of your project, put it's preference files, settings and caches in it. You just intervene, most don't put up much of a fight.
-
As we discussed elsewhere, your projects should be independent of any and all IDEs.
That's right. There were always problems with various IDEs. I use a text editor instead. Never had a problem.
-
it was a lot worse 1-2 years ago
(Back when this thread started.)
I think we have to have a major debate on whether it's a good thing that the ST-provided "stuff" has undergone so much improvement (even two years ago, people were claiming that it had improved a lot since versions PRIOR to that), or whether it's terrifying that there is so much "churn" in what ought to be simple and stable code. :-(
-
You mean here?
Two of those options look like a register write...
Yes, that’s it. Disconnect the hardware RESET signal and select either a “Software” or “Core” reset there.
-
Yes indeed.
The random file opening bug has been well characterised (Cube opens whichever file contained code executing when the CPU is reset/restarted) but it needs somebody familiar with the ST SWD debugger implementation in Cube. Other manufacturers' Eclipse + debugger implementations reportedly do not have this problem. That is where the problem is. For some reason ST are unable or unwilling to do this, and with c:\st containing 18442 files (the actual value on my PC!) and a lot of them being java, probably nobody else wants to get stuck into it. Especially as ST are not really responsive to bug reports (they make all the "right noises" on the ST forum) and then whatever fix is developed will be overwritten by the next Cube update.
The "contact lost with the debugger" problem has always been there, and makes it hard or impossible to run a program in Debug mode for more than a few hours. It is just not a robust implementation. I suspect the problem is in the USB code, because I can have the same target running in Debug for minutes or (rarely) days before it loses contact, so it isn't a problem with my SWD wiring. And USB is unbelieveably complex...
I am on v 1.12 which apart from the above works satisfactorily.
Disconnect the hardware RESET signal and select either a “Software” or “Core” reset there.
Thanks. I will try that. So the debugger must somehow force the CPU to execute that code - like discussed previously - without modifying the FLASH and, presumably without placing the code in RAM.
-
I might be mistaken, but my understanding of the SWD is it connects via the ARM debug subsystem and provides the PC direct control over the main clocks. No "STEP" on computer, no run. There should also be a heartbeating mechanism which allows "is connected" to be determined.
I suspect that "keep alive" protocol is being failed by Windows, WinUSB, Cube or the STM drivers.... or any/all of the above.
When one launches GDB on a target you have the option of connecting in stopped state. ie. It will stop on the first instruction of the binary. Alternatively you can have it stop on a symbol, having given is a symbol rich binary or a symbol file.
So the process is to launch GDB to connect via the SWD driver to the ARM core. STM have claimed they cannot, for whatever, stop GDB emitting all symbols it's passes while they are waiting on the entry point of main().
To be honest, that might very well be the problem. "main()" is NOT the first instructions executed. As we know from all the startup.s etc. it launches before main. So they can't be firing GDB up properly, configuring it properly or using it properly. It's not firing "Break point caught" events as it doesn't stop, so they appear to be consuming the full symbol output or something?
EDIT:
Cube does not deploy the symbol rich binary. So one would assume they launch GDB with a symbol file which is aware of the target's memory model. (That's remote connection based cross-compile debugging, not exactly easy). They may be intercepting these to do some memory model translations to determine true symbol addressing. In that case they may be unable to stop Eclipse from recieving all those same events.
I have breifly used ESP32's JTAC based Eclipse debugger and I don't recall the phantom breakpoint noise there either.
-
I might be mistaken, but my understanding of the SWD is it connects via the ARM debug subsystem and provides the PC direct control over the main clocks. No "STEP" on computer, no run. There should also be a heartbeating mechanism which allows "is connected" to be determined.
It's at the same time simpler and more complicated than that.
The debug host can let the core run and wait for a breakpoint to be hit. A gdb "stepi" will just exercise the machinery described below by setting up a halted core to execute the next instruction, then stop. It can also let it run freely until a set breakpoint etc. etc.
A brief description of the debugging mechanism on Arm, literature reference will follow:
1. Debugging Arm cores is based on CoreSight DAP - Debug Access Port
2. A DAP can be accessed with either JTAG or SWD transport, it's up to the implementer to choose one or both - I'll talk about SWD as that's the most common interface used, but there's not much of a difference.
3. A DAP contains in general one DP (Debug Port) and a number of APs (Access Ports)
4. The DP provides access to the APs through a JTAG or SWD state machine, in turn the APs can read and write memory, processor registers, and debug only registers (e.g. to set clear breakpoints, allow for a single step etc.). The available APs can be detected by scanning the DP, and specific capabilities are described in ROM tables inside each AP.
5. Protocol (e.g. SWD, Serial Wire Debug) exchanges (i.e. reads or writes) between a debugger and the DAP are always initiated by the debugger. There is no spontaneous signalling from the DAP.
6. The DAP just acknowledges every read or write.
7. This means that setting a breakpoint and letting the core run (or performing a single step) must be followed by polling to know when the breakpoint has been hit.
8. All this low-level churning on the wire is hidden partly by the protocol between the debugger probe and the gdb server on the debugging host. The abstraction level can range from essentially zero (e.g. the first version of the picoprobe), to very low (e.g. CMSIS-DAP protocol), to medium (ST-Link protocol) to high (J-Link protocol).
9. the gdb server translates the debugger protocol to the gdb remote target protocol.
10. gdb manages direct user inputs (through CLI) or IDE inputs (usually through the machine friendly MI syntax) and issue the relevant remote target commands towards the the gdb server.
So, it's a complicated journey from the core to gdb command interpreter...
References:
Understanding DAP (https://developer.arm.com/documentation/102585/0000/What-is-a-Debug-Access-Port-)
ARM Debug Interface Architecture Specification ADIv6.0 (https://developer.arm.com/documentation/ihi0074/b)
The CMSIS-DAP protocol (https://arm-software.github.io/CMSIS_5/DAP/html/index.html)
The Remote Target protocol (https://sourceware.org/gdb/onlinedocs/gdb/Remote-Protocol.html)
The gdb MI protocol (https://sourceware.org/gdb/onlinedocs/gdb/GDB_002fMI.html)
Bonus:
gdb uses the remote target in a redundant and predictable way, requiring only minimum state in the gdb server:
Common debug sequences (https://www.embecosm.com/appnotes/ean4/embecosm-howto-rsp-server-ean4-issue-2.html)
Why I (pretend to) have an idea of all this:
- contributed legacy picoprobe implementation to pyocd
- contributed Thread-X RTOS support to pyocd
- wirtten a debug monitor for the debug impaired Teensy 4.1 - single thread works very well, not ready for prime time as FreeRTOS multi thread stepping is still a bit flaky.
-
Bloody hell this is incredibly complicated... no wonder nobody can fix that bug.
FreeRTOS multi thread stepping
What is that? AIUI, IME, single stepping in Cube just executes the source code, one line at a time (or one asm line at a time if stepping in the asm mode) and the RTOS is frozen.
OTOH I have this setting in Cube
(https://peter-ftp.co.uk/screenshots/20230612495654814.jpg)
and there is another setting somewhere (I can't find it right now) which stops the timers also once a breakpoint has been hit. With the watchdog this is obviously essential otherwise you could never debug anything. And stopping the timers running also stops RTOS task switching (systick); if the RTOS continued to run you could also not step through any code. I must be missing something obvious :)
Funnily enough even though I have the above setting set to No Configuration (the screenshot shows Disable), the watchdog does not reset the target during stepping. Maybe the timers-stop setting overrides the watchdog options...
Breakpoints usually break the target (ETH or USB can withstand a few hundred ms IME) so they are a one-off debug feature; the target has to be restarted afterwards.
I never used the Enable RTOS Proxy and IIRC one needs to write some code to make that do something, like displaying RTOS tasks in "real time".
-
Bloody hell this is incredibly complicated... no wonder nobody can fix that bug.
FreeRTOS multi thread stepping
What is that?
[...8<...]
I never used the Enable RTOS Proxy and IIRC one needs to write some code to make that do something, like displaying RTOS tasks in "real time".
Note: I do not use Eclipse based crap, I value my time and blood pressure. So I don't know whether that "RTOS Proxy" is something else entirely. From what I can read it enables stack traces on non-running tasks. I get them for free with my monitor, pyocd, and VS-Code - no instrumenting needed, and the same should be for you. Instrumenting i needed if one wants details on the stack percentage used or on the execution times of the threads.
If you are not using the RTOS awareness at all, I imagine you cannot see the names of the threads, or see easily which one are stopped and for which reason, if you not using just the proxy you are missing out on the stack trace.
It's quite helpful: you get good stack traces for each thread/task (gdb/FreeRTOS name) instead of only the one for the currently executing task, you can step a single thread - of course this means the others may run until the step is completed - and you can inspect and modify their local variables.
Note also that gdb supports two modes for multi thread debugging, one where everything stops when one thread is interrupted (e.g. BP or Ctrl-C) one where only that single thread is stopped, while the others still run (my monitor only supports stop mode now - working on it).
gdb will negotiate with the debug server using the remote target protocol to understand its capabilities, e.g. whether it supports the extra messages to gather and set thread data, and non-stop multithread mode, if not it will just use basic protocol and single thread debugging.
The problem (I mean, feature) with Teensy is that to make it as much Arduino like as possible for programming/booting all the debugging has been crippled: JTAG/SWD is completely taken over by the extra Kinetis MCU on the board, and it is not even possible to enable the Debug Monitor exception that would allow simple gbserver-like handling via serial port (TBH: I have very few gripes with Mr Teensy, his code is usually very good, a step above 99% of the Arduino libs I happened to look at).
So I had to use a SVC call to emulate breakpoints, making sure not to interfere with FreeRTOS (which luckily just use SVC-00, and only at startup), meaning that breakpoints can only be set in RAM code (and no, I did not manage to make address translation work, probably tied to the same settings that prevent the use of debug monitor and HW breakpoints).
Moreover, to implement reasonable single instruction stepping etc. I need to calculate the length of the replaced instruction, keep track of IT instructions and so forth, quite a deep dive in the Arm architecture and instruction format(s)!
Making this pseudo debug monitor FreeRTOS aware entails also some introspection in the RTOS data structures, as gdb expect to be able to unwind the stack of all the threads it finds and needs the SP and registers of each one.
Implementing the sending and receiving of the protocol messages on a dedicated UART was in fact the simplest part of the endeavor.
Everything seems to work, with the exception that gdb gets confused by some of my answers when I try a single step on a thread that's not the active one at the moment.
-
OK; thanks.
I have RTOS data but via a different route: an RTOS task which is within the HTTP server and which displays a status page like
(https://peter-ftp.co.uk/screenshots/202306121117213818.jpg)
where the RTOS stuff is generated by interrogating FreeRTOS data structures. The FR doc supplies the code for that.
I also have a win32 app which displays the entire FR memory block, graphically, so I can see stack usage for each task. I posted this before. It is really good.
Amazing that one can step through one RTOS task while other tasks are running normally. Could be very useful because ETH or USB can run in the background. The way I use Cube, everything stops on a breakpoint - interrupts, the whole lot.
-
I think it's time to change the thread title? No only because it's missleading, but because it's more like "CubeIDE bits and odds" (Not sure how to call it in English, like small details, everyday issues, howtos...).
We've talked about almost everything about it. The IDE might not be perfect, but it's pretty good.
Some dinosaurs still argue emacs/text editor is the way to go...
But no thanks, it's like saying hand-made iron smelting in clay furnaces by sweating slaves is better than modern industrial techniques :-DD.
- Real-time syntax checking just great, makes your life easier. I appreciate my time, with a simple text editor, you won't notice if you accidentally typed "rpintf" until compiling.
- Control+click and mouse hovering are great to have a quick glance/fly to the declaration/definition, it's incredibly useful, otherwise you hav to remember everything.
- Embedded debugging, variables, expressions, all-in-one package makes it extremely simple to setup...
- Making Makefiles by hand? Erm, no thanks, I already waste a lot of time with those heeecking registers and buggy peripherals :)
-
I changed roles/companies in work. Out of banks back into exchanges. Breath of fresh air.
Also a breath of fresh air is ... IntelliJ. I'm quite used to Eclipse. IntelliJ and me haven't really got along right, yet. It's even more annoying than Eclipse in many ways I have found so far. It's got so many integrations and add-ons, utility panels and support features, but it seems like none of them are "connected up" together. You can have one build interface showing your a 100% green built and ready project, but your editor shows every import as "Not found". That's just one annoyance that you need to configure all of the support features, sometimes independantly!
-
Cube v 1.13 has just come out and broke a few things :)
Mostly GCC v10 -> v11.
https://www.eevblog.com/forum/programming/stm32f4-gcc-v12-to-v13-some-weird-error-messages/ (https://www.eevblog.com/forum/programming/stm32f4-gcc-v12-to-v13-some-weird-error-messages/)
-
To be fair, I'm currently being tried by MCUXpressoIDE from NXP. I needed a few too many pins to make the STM's work, so I'm trying out an i.mxrt1176 (the higher speed doesn't hurt, either - even the "slow" core is almost as fast as the ST one...)
Anyway, long story short.. Come back ST, I forgive everything. Well, most things... A lot... Ok, some. But still...
It tries to do a lot for you, because the chip is actually pretty complicated and the pin routing is also complicated, but then when it fails with an unspecified "error" or "warning" and refuses to update the code from the pin-map UI, you're left with not knowing where the issue is. It 'helpfully' says it's a 'tool error' in the "problems" pane - I ought to spell that "pain") but there's no indication of which preference, which tool, which part of the code, what setup, anything that could point you in the right direction.
It's a bit like STMCube just failing to calculate your desired clock speed (as in: the one the chip is advertised to run at) because the default power-envelope is set to "trickle in power as if it were gold-dust". Again, no indication on the clocking screen why you can't have (eg:216MHz) but 16MHz is apparently your limit...
Anyway, I got "blink a led" up and running pretty quickly on the i.mxrt chip, but a quick test of 'put an interrupt handler in place' is failing dismally. I can see the signal going into the pin, I have the correct pin on the eval board (helpfully shown in the UI), I have the GPIO set to be an actual GPIO not a separate function, and I have the interrupt set up the same as their example one AFAICT. It just won't actually trigger. Most of the above I've done by hand, copying and adapting from example source, because the darn UI has thrown a wobbly and won't update the separated-off areas of the code that it's supposed to [sigh]
And, NXP's forums have been down for days now. All you get when you go to sign in is a "Sorry, this sh*t is broke".
Gah.
-
Found another workaround for the Cube IDE missing Build Analyser.
It doesn't need a second Build (ctrl-b) really. A right-click on the Debug directory and selecting Refresh does it. The .map file appears then, too.
-
As a general tip, those "Build profile folders" like Debug and Release are "ephemeral". You can enjoy simply deleting them... or tampering and then deleting.
Usually the "I can't ars'd working out why it's got stuck, rm Debug/ -fr"
Honestly I haven't been in CubeMX in a few months and I recently switched to IntelliJ in work. In Java space in either we don't use "build profiles" like debug and release. I'll not digress beyond we create builds which are environment agnostic and we use 'platforms' to deploy and run them.
It's almost what CubeMX is trying for in ways, but Java and C/C++ are very different animals. "Polymorphic" build artefact platforms do exist for MCU platforms, the trouble is they are usually MCU specific. An arbitrary example might be "ESPHome" and "Platform.io"... although again, they are typically compile/link time controllers. Which is understandable given the targets.
-
Not happy with 1.13.0...
- Broke my CubeMX script, which cost me blood and suffering to make because docs where close to non-existant.
- eGit detected changes at the beginning of each line in all of my source files, must be a newline thing, no idea what.
- Asks for login to download the firmware pack. From their website:
Authentication
Users familiar with STM32CubeMX will now notice that the software is requiring them to log in to their my.ST.com account before downloading a package. While users always had to enter their credentials when downloading a piece of software from ST.com, the new version slightly tweaks the experience so everything happens within the software for better cohesion. It’s still possible to use STM32CubeMX without an account. However, by asking for a login and password, like on the website itself but from the software, users enjoy a more cohesive experience.
What a pile of BS! Please take your cohesive experience away!
-
The line-endings is a git setting which if you don't set will modify all the code you commit to meet the line ending requirements of the repo.
This is a bit of a legacy setting, if you are using a modern IDE as they work with all combinations of newlines.
It is intended for people who wish to end "Unix" text files on Windows apps which do not support \n, but only \r\n.
So git has a feature to translate line endings on pull and commit. So you can have a Unix type repo with only \n, but when you check it out on Windows they get translated to \r\n in your local working dir. When you commit them, they get converted back to \n.
The other possible "Oh My God, why is my status showing every file!?", is often as a result of permissions. Usually this is simply disabled on windows and git tracks the unix perms separately. There are ways to configure it and different git clients with different default config and occasionally one of them picks up the windows 777 perms and has a freak out. Also if someone does a mass permission and ownership update in the repo the Windows client can show a massive amount of changes, which appear to have no actual deltas and nothing happens when you pull them.
-
Hmm it could be the permissions, as I reinstalled Windows and migrated the files from my old installation.
AI doubt it was an actual change on the files or git config, I never had to do anything, worked right away after installing and that's all what I did.
Windows equivalent is setting ”Everyone" owner, exactly the opposite as "nobody" in Linux :)
-
V1.13 has not fixed the random file opening... It still opens the file containing code currently running when you stop the target during debug.
It also does oddball stuff I can't put my finger on, and Cube needs to be restarted.
It also breaks a part of the "makefile" concept: it always rebuilds the whole project when you first do a build (say ctrl-b) after Cube was started up. There is a setting deep in there somewhere. Does anyone know where it might be? Basically it run an rm *.* on the whole Debug directory, which deletes all the .o files... obviously :)
-
Turn off the debug file opening feature if you don't like it.
In most project IDEs these days we don't even have "save" it just happens, this triggers a build in the IDE in the background. So as you are typing code it's rebuilding it. Eclipse does have manual save, but in Java land it will trigger a build in the background. This can be very progressive inducing as you get the compiler errors immediately in context while you type.
Cube however violates the reasoning behind this by not making any attempt to support "build servers" or "CI/CD". Without these infra components the only build is the build on the developers insecure machine. So making the build process old-school manual and adding "required" IDE integrations to function is the only way to make it work.
-
Turn off the debug file opening feature if you don't like it.
Where is it? This came up before; there is no option which actually controls this.
Eclipse does have manual save, but in Java land it will trigger a build in the background.
Not in Cube.
-
Firstly, you can disable the auto persepctive switch, which might help. Then it won't switch to "DEbug" layout when you hit Debug or when it hits a break point
https://stackoverflow.com/questions/4258746/disable-automatic-perspective-change-in-eclipse
and
https://help.eclipse.org/latest/index.jsp?topic=%2Forg.eclipse.jdt.doc.user%2Freference%2Fpreferences%2Frun-debug%2Fref-run_debug.htm
Activate the workbench when a breakpoint is hit This option brings attention to the debugger when a breakpoint is encountered, by activating the associated window. The visual result varies from platform to platform. For example, on Windows, the associated window's title bar will flash. On
Activate the debug view when a breakpoint is hit This option brings attention to the debug view when a breakpoint is encountered. If the view is already open it will be activated. If the view is not already open it will be opened automatically. On
-
Then it won't switch to "DEbug" layout when you hit Debug or when it hits a break point
Yes; we've had this before :)
Breakpoints not triggering code view of the breakpoint is not very useful.
-
Then it won't switch to "DEbug" layout when you hit Debug or when it hits a break point
Yes; we've had this before :)
Breakpoints not triggering code view of the breakpoint is not very useful.
How does it know the ones you want and the ones you don't?
If you disable the automatic switch, you get to choose if you want to go to the Debug view or not.
if it doesn't open the file and advance to the breakpoint, then just click the stack trace for where you want to look.
Note, this is separate to Cube opening "rouge" breakpoints at restart. That is an STM bug with GDB.
i'm fairly sure I disabled it. via the popup which it pesters you with everytime you run Debug asking if you want it to switch. Eventually I decided, says, "No" and saved my choice. All it means is I have to switch manually to debug and back again. Which is fine.
-
How does it know the ones you want and the ones you don't?
Indeed; this was debated previously, somewhere. Probably on the ST forum... The key to it is to determine whether the trigger for the view change is a user inserted breakpoint, or a reset (or whatever Cube uses to stop the CPU when doing a stop). One would need to dig deep into the java sources.
EDIT: the build-all mode can be fixed, apparently, by changing the Builder Type from External to Internal. No idea what this does, but why does it change?? It should be under Project / Properties, so a Cube update should not change this setting.
-
Another issue which arrived with v1.13 is that after some tens of seconds it says "trace buffer full". Various suggestions online don't work. The trace buffer is pretty big too, and this is nothing to do with SWV ITM console output.
-
And now we have 1.13.1 update which, guess what, prevents further updates by removing the update site URL ;)
You have to google for the URL and add it manually.
-
https://www.jetbrains.com/help/clion/embedded-development.html (https://www.jetbrains.com/help/clion/embedded-development.html)
-
https://www.jetbrains.com/help/clion/embedded-development.html (https://www.jetbrains.com/help/clion/embedded-development.html)
Shouldn't you start a new "Is CLion a piece of buggy crap?" thread for this? ;-)
JW
-
https://www.jetbrains.com/help/clion/embedded-development.html (https://www.jetbrains.com/help/clion/embedded-development.html)
Shouldn't you start a new "Is CLion a piece of buggy crap?" thread for this? ;-)
JW
In other partially related news, an MCUxpresso extension is now available for VS Code (https://www.nxp.com/company/blog/the-new-era-of-mcuxpresso-starts-today-with-vs-code-and-open-cmsis-packs:BL-THE-NEW-ERA-OF-MCUXPRESSO). Maybe it will be a piece of (slightly) less buggy crap.
I have installed, it but all my projects are based on custom CMake scripts (apart the RPi pico stuff, I use theirs + mine), so I did not do any real testing.
It was able to understand and compile one of my CMake projects, though not a big deal, it correctly handled all the custom toolchain and picolibc stuff.
That said, even waxed tablets and a broken stylus are better than Eclipse.
-
Adding https://sw-center.st.com/stm32cubeide/updatesite1 (https://sw-center.st.com/stm32cubeide/updatesite1) seems to work. Yeah, ST just broke it by changing their website around. Unintended consequences ;)
Cube contains a load of http:// URLs which "of course" no longer work.
-
That said, even waxed tablets and a broken stylus are better than Eclipse.
Alternatives? Because if it's using olain text editor and/or custom makefiles + setting 20 different programs for everything, no thanks!
Vscode is a mess too, I really hate the interface, plus the json files for everything.
-
That said, even waxed tablets and a broken stylus are better than Eclipse.
Alternatives? Because if it's using olain text editor and/or custom makefiles + setting 20 different programs for everything, no thanks!
Vscode is a mess too, I really hate the interface, plus the json files for everything.
Sorry, I cannot help you.
If you hate the interface I have no suggestions - it's a very personal thing.
In many years I've tried a lot of different ones all either not configurable enough, or looking like a Win 3 program, or not multi platform, or slow or buggy or all of it at the same time (◐).
VS Code is the only editor/light IDE that managed to make me abandon Emacs, I started at version 0.13 IIRC and never looked back - the only thing I miss are keyboard macros, but multiple cursors cover 90% of my needs.
I like VS (not Code) a lot too, but that's Windows only - not using it much since Code came around.
-
So attaching the debugger to a running target couldn't be easier.
Set reset type to None, disable downloading - that's all!
-
Could anyone suggest why I am getting this all the time I restart the target
(https://peter-ftp.co.uk/screenshots/20230809515811017.jpg)
It seems to be clearly related to code I am running. Cube crashes as I step (F6) from the diff = abs... line to the one below.
-
In many years I've tried a lot of different ones all either not configurable enough, or looking like a Win 3 program, or not multi platform, or slow or buggy or all of it at the same time (◐).
VS Code is the only editor/light IDE that managed to make me abandon Emacs, I started at version 0.13 IIRC and never looked back - the only thing I miss are keyboard macros, but multiple cursors cover 90% of my needs.
I like VS (not Code) a lot too, but that's Windows only - not using it much since Code came around.
Have you tried Qt Creator ? It is optimized for Qt development but it is multiplatform and supports C/C++ development and debugging with any GCC or CLang toolchain for Windows, Linux and Mac OS/X.
The latest version also has a "Bare Metal" plugin that directly supports ST-Link, J-Link, OpenOCD etc. (it is disabled by default, but you can enable it).
To use Qt Creator you don't have to download the full Qt SDK, just the application and point it to where your toolchain, debugger (and eventually CMake) are.
-
Could anyone suggest why I am getting this all the time I restart the target
Because... CubeIde 1.13? ;)
-
I am just amazed this is even possible... the code you wrote bombing the debugger.
-
I am just amazed this is even possible... the code you wrote bombing the debugger.
Could you step it in assembly? You can pinpoint the exact location where it happens and what is going wrong.
-
I will do that next time it happens. Now I have moved on...
One possibility is that the source code doesn't exist. This is often the case with arm32 and conditional instructions - as in the case above. The debugger needs to deal with this and it is not going to be trivial. When stepping, you see it happening when a piece of sourcecode is just skipped, as it discovers that there is no machine code present. The debugger may not be handling all the possible cases.
-
C / C++ folks have always been hard to please. Traditionally you basically had a text editor (maybe a fancy one or a fully configured Vim) and a terminal for Unix development. For Windows development you had Visual Studio or a selection of other payware options from the likes of Borland.
My 3 years in C/C++ dev in stock exchanges was 90% Vim + Shell + Sconscript. Later Eclipse CDT was "played with". As it couldn't integrate the SConscript or the PerForce source control (with had it's own GUI) so the only bonus it provided was code indexing and CTRL+Click to follow references... which it didn't do all that well either and "Grep" was far more reliable.
Eclipse was born and bred in IBM as an IDE for IBM WebSphere Java application platform. IBM have a long history of "Trading" with OSS and so they created the Eclipse Foundation and open sourced the main IDE, keeping only the IBM WebSphere integrations prop. You can immediately see where the model eclipse uses comes from, core functionality shared and enabled with more specific integrations.
Eclipse therefore was and still is primarily a Java IDE. Yes efforts have been made to keep the core functionality agnostic, but the truth is the user base is orders of magnitude more likely to be Java developers. It has far more functionality and far more stability and is far more "prolific" in use for Java.
Eclipse CDT is fairly mature, however the C/C++ build and deploy environments aren't. The best you get is the GNU stack, the rest is bespoke, custom or proprietary, so a small and uncompetitive market with no "consensus" like exists in Java where there are only 2 dependency and build management systems and only a few deployment management systems. So almost all of those have direct integration in Eclipse (and other IDEs). In C/C++ they would need to implement dozens and dozens of combinations. Even when only targetting a single platform (STM32) it's complicated by different versions of the dependencies and the targets themselves. C/C++ is not cross platform. So using a cross platform IDE is a little puzzling... however , STM have basically choosen it as the base of their proprietary IDE. They could have tried Inteli/CLion or any other, but they choose Eclipse CDT. The rest is up to STM.
Out of interest (found on my travels). Python is just about overtaking Java as the main Enterprise language. The reason behind that is, Java costs too much, Python is easy to learn, you can hire anyone and give them a crack at python. It's quick to write and dog slow to run, which works for many organisations.... until it doesn't. The other issue with Python, and why myself and others defend core infra from it, is "latent syntax errors". Almost always in untested error handling code, compounding the issue.
C/C++.. it depends on where you read and if they just harvested CVs and think that HTML/CSS is the most common language, it's sub 15% of the market.
In fairness that should elevate salaries... however I suspect micro-controller platform companies may still be far-shoring development.
-
People use STM32 Cube because it is free, so maybe it should compete with other free stuff. Anybody who can spend a little money will get IAR or the like and just use CubeMX and the HAL libraries to get things started. Or go bare metal if the sponsor can pay.
Debugging problems often stem from optimization. Compilers come with defaults and you have to turn it all off in order to be able and debug along a source file. In IAR we have "Release" and "Debug" at project level and they provide library sources just like STM. I remember a project with severe problems only in the "Release", so we had to setup a third stage in between to debug those problems.
Regards, Dieter
-
All possible but it still should not crash like that, because the whole program has to be restarted.
The whole Debug v. Release paradigm is that you can define different build options and then just build one or the other by ticking the box. I don't use it because it is a massive hostage to fortune to build a working product in Debug and then rebuild in Release and send out 100 or 1000 of them to customers! Regression testing is simply impossible on anything which does more than toggle an LED ;) (you get my drift). So much is timing sensitive; I have just spent all day chasing one such issue with ADC timing... I build with -Og all the time and will ship with -Og. There are a few times in Cube when you can't see variables properly (unless you build with -O0) but it is easily fixed for the few minutes by putting "volatile" before the variable :) But even then, conditional instructions can mean there ain't no code there!
Sure corporates will pay because it makes them happy but IME pricey tools are not necessarily good. I have used £10k ICE boxes, £1k+ IAR tools (1980s pricing) which were horrible, etc. Licensed tools tend to bite you in the bum because the floating license server has broken, a remote one is no longer supported (the Adobe CS3 case is a notorious example), you can't get others working on your project remotely without a load of hassle and cost... and the "support engineers" are generally guys who failed to be good at anything that actually works so they move into tech support, marketing, etc. Mostly they are a waste of space unless they have a direct channel to God (the actual guy in the actual company which wrote the tool).
IMHO Java is shit. Everything I have used in Java was only just hanging together. The language has always suffered from a million of version dependencies so with every product you have to ship a gigabyte of java libs (because the Java you installed on your PC will be useless). Java is great for earning a lot of money in a big company because nobody else can maintain the product. In theory it is cross-platform but that is buggered by so many subtle version dependencies. Some of the worst examples are within ATC which uses vast Java applications which cost millions to write, have UIs from the DOS6.22 era, and nobody can do anything to fix or improve them.
But Eclipse was done in Java so we are stuck with it. Just reboot it fairly often :)
The box I am working on will be used by other coders and no way could I sell it with a paid devkit. Those days have long gone.
-
I remember a project with severe problems only in the "Release", so we had to setup a third stage in between to debug those problems.
Probably due crappy programming causing issues when enabling optimizations? That's the usual.
I like the IDE a lot. HAL and MX not so much. But you can use it as you like.
Lately I'm using just Low level libs for the cheap chinese arm chips, everything initialized by hand.
In the end it's just Eclipse with few addons to make it ready for ARM programming and debugging.
-
Many of these "IDEs" are based on Eclipse, but that's not like using bare Eclipse distributions. I don't think you can update the Eclipse part of it as you would with bare Eclipse (let me know if I'm mistaken about that though), so you're stuck with the version the vendor tool was released with, and if it contains bugs that the Eclipse team has long fixed in the meantime, you're stuck with them too.
Also, specific addons written by the vendor for supporting their parts may themselves add their batch of bugs.
As to Java-based software in general, I have my opinion too but this time I'll probably keep it to myself so as not to trigger a flamewar.
-
What are you afraid of? Java provides great portability at a huge performance/memory cost.
For me it's like Surströmming to programming languages.
The same thing on C++ would blast to orbit while using 256MB :D.
-
What are you afraid of? Java provides great portability at a huge performance/memory cost.
For me it's like Surströmming to programming languages.
The same thing on C++ would blast to orbit while using 256MB :D.
A 96 core server with 256Gb of RAM cost less than a Java developer does for 2 months and produces less serious runtime bugs, java devs are easier to find, and java an order of magnitude faster to write. Java is, whether you like it or not, a better language for the largest portion of the industry.
-
Java is great for java developers and oracle.
PITA for everyone else.
-
Presumably there is no way to build Cube IDE any other way today, is there? It's been written in Java and will always have the general portability and runtime version dependence of Java. They ship the entire runtime with it
(https://peter-ftp.co.uk/screenshots/202308150217841517.jpg)
but it still has various issues which cannot apparently be fixed because the whole tool is so complex. But maybe it has to be this complex... there is a lot of functionality. OTOH this is functionality which has accreted over years.
-
I'm not sure if that's correct.
Eclipse core is Java. However a large part of the GUI has been ported to native C binded GTK+.
CubeMX may, or may not be Java based. It is basically the standalone app, but with it's entry point wrapped in the Eclipse plugin wrapper so it appears as a view.
The 3.7Gb folder is about 70% documentation and example projects.... for ALL platforms, including the ones you don't have. Go browsing. I'm not even sure it's go the firmware in it. I moved it to another drive (a slow spinning network disk). I can't find it now, must have deleted it. Not to worry, it's 100% reference material. Nothing more. 100% replaceable. Delete, restore.
The Java JRE required to run eclipse is usually provided by Windows, which it comes packaged with these days. A wiser developer will fix that. <wink>. I don't know the size of the basic JRE these days, but it's not more than a 100Mb.
As a sanity inducing exercise for you. Go create a new machine. Even a VM. Create your dev environment on it from scratch. Review it. This will help you understand all your config overheads/complications. It will also allow you to identify when it's the "upgrading" process or the new version of the IDE which has broken your build. It will also help make you decouple your project from "A development environment.". Even if it's multilple instances of Cube/Eclipse. You absolutely need to spawn and rebuild a 'reference' IDE setup. If all goes mamaries up ... rebuild the reference IDE and it still doesn't work. it's really broken.
-
The 3.7Gb folder.
Wow. I used lots of IDEs in the past. Now I rarely use them. Most of the time I use a text editor which has few features - like syntax highlight, compiling by a button press, show the output, find the location of an error, invoke a programmer, a few other things. That's basically all I need. Two files - 110k executable and 80k DLL. Roughly 200,000 times smaller than your Cube. I understand that other people want more functionality, but I can't imagine anyone needing 200,000 times more than I do.
-
As it was pointed out, that size includes example projects generated for all possible MCUs. Nobody "needs" all of them, but at any given time any person may need one of them. Whether it is worth installing all of that by default is a matter of opinion. If you don't do that, then there will always be people complaining that they need extra steps to get their example projects. And 3.7 GB is not that much.
Plain basic Eclipse is way smaller. It is still bigger than a basic text editor, but it does a lot more too. And again, it would depend on your needs if you need any of that.
I just looked at Harmony 3 directory on my computer, and it is 20 GB. But that includes a lot (not all though) core components and examples for majority of ARM-based MCUs. I don't have anything checked out for MIPS.
A lot of it is redundant code, of course. But storage is cheap and it is way better to have a dedicated project for each peripheral and each MCU rather than have a #define monstrosity. After all, a person really cares about the MCU they have, so it is better to get a clean example for that MCU only and ignore the rest.
-
Eclipse CDT from 2021, with a support for MingW, folder size is 550MB.
It's a nice tool.
Helped me to figure-out some huge codebases relatively quickly.
And it had a good support for almost every crap that project leads pushed onto their slaves team members.
I can understand why embedded engineers and one-man-band people hate it, but in an "enterprise" environment it was really useful.
These days, having to use VSCode instead feels like going from Unimog back to horse and cart.
And that horse has a limp, flatulence, and diarrhea.
-
The size is not a problem.
Opening a project and freezing for 10 seconds in a fast 5GHz 8-core machine it is!
-
The size is not a problem.
Opening a project and freezing for 10 seconds in a fast 5GHz 8-core machine it is!
They both are symptoms of the same - excessive complexity and poor design. Bugs are another symptom.
-
Eclipse CDT from 2021, with a support for MingW, folder size is 550MB.
It's a nice tool.
Helped me to figure-out some huge codebases relatively quickly.
And it had a good support for almost every crap that project leads pushed onto their slaves team members.
I can understand why embedded engineers and one-man-band people hate it, but in an "enterprise" environment it was really useful.
These days, having to use VSCode instead feels like going from Unimog back to horse and cart.
And that horse has a limp, flatulence, and diarrhea.
Yep. I agree. VSCode is nothing more than a code browser with a nice(?) plugin interface. It's free, makes VS people feel at home and gives MS a better footing into the developer space they had been pissing off for a decade prior. You can now sign up to a dozen different "online IDE" setups and online code review/interview systems, all of which use the "online" version of VSC.
There are a list of features in Eclipse (and VSC to be honest) which just wouldn't interest most "one man band" outfits. Almost the entirety of the enterprise integrations will go unused. Nothing to integrate with. Although surely most of the wise use git at least.
Most embedded folks just like to install a full platform, pre-canned, just make it work, for MY MCU. Understanding what goes into that is, at least today, often left in the pile "If I really, really have to..."
I'm pretty sure you can use a basic GNU cross compile stack with Makefiles, Autoconf etc without an IDE being involved.
This is how it would be handled in enterprise. At least in the sense the build process has to be executable on a controlled environment (security/reproducability). The developers can use whatever IDE they like. In a team there may be one main IDE, but there is usually someone trying to be different. So projects exist in two distinct layers. What gets checked in and thus built on the build servers and what exists on the developers machine, in terms of tooling and techniques, which is entirely up to them.
If you separate your build and possibly deploy process from STMCube your reliance on it will drop significantly. Your flexibility to "build, deploy and test" your way, in an automated fashion on a server running test harnessed MCUs... the world is your oyster.
While you rely entirely upon STMCube... you are a boat on their river. Just get yourself a paddle.
I have not looked into cross compile build servers for STM32. I have built the stack previously for Atmel AVR. I did not put a build server on it, but it was a basic GNU cross compile stack so in theory any CI/CD platform which supports Makefile projects and shell script deployments should work fine. Commit, push, build, deploy, test, fail, repeat.
-
I don't see how integration is related to IDE. Integration is done through Git (or similar). Nobody cares (or even knows) what IDE you use, or if you ever use any. Look at Linux Kernel, for example. Their code base is huge and they have enormous number of developers working on it.
-
What do you call "integration"? Git is only one part.
It's also the toolchain, code editor, programming/debugging support... Install and go, that's what IDE stands for.
I tried PyOCD yesterday. Oh man, same broken crap like all Linux stuff.
F** Python mess, because you can't simply run pip update, you must issue a 30" long command to get it done.
Then the package is installed but can't be executed...not found.
After long search you find a 8-month old git issue, "we've fixed it but its not released yet". Ok....
Everything in Linux seem to need two days to set up, mastering in sed and Linux insides, several hours searching the errors...
This is what ** me up. It's *** 2023, stop relying on 300 external commands for everything.
People argue at Windows, but all I need is to install C++/.Net libraries, jdk... And they don't f** each other , they all live in peace.
That's why, though sometimes slow and buggy, I'm fine with cubeIDE or eclipse, it's stable enough, if something breaks I can simply reinstall it, instead waiting for the day something breaks in my mind and I run outside with a shotgun :-DD
-
What do you call "integration"?
I was replying to the posts about integrating a developer into an enterprise system.
-
Ah, sorry!
-
Go create a new machine. Even a VM.
Indeed - use VMWARE routinely for this, and actually the right way to archive a Cube IDE project (for long term) would be to archive such a VM. You could even distribute the kit to other devs that way - a setup which is "guaranteed" to run out of the box (windoze copyright is one issue though, but the recipient could buy a win7-64 on Ebay and replace the product code from that).
Re MX, I don't use it and don't care for it. Yes it may well be a standalone C++ module. I know someone who uses it to generate code fragments for some peripheral, takes them to bits, and dumps the rest. It saves time... much faster than reading the RM.
Most of the time I use a text editor which has few features
Sure; me too. But the average coder who is not an expert benefits from this kind of integration. Especially if this has to be documented for someone else ;)
I spent years on Brief (editor), Polymake, etc, running a Japanese £10,000 Z180 ICE for breakpoints... times have moved on and expectations have moved on. Also Cube is free, which addresses major issues (cost, project archiving, etc).
Whether it is worth installing all of that by default is a matter of opinion
ST Cube IDE does not offer a choice.
About that irritating issue with Cube IDE opening spurious files from you Debug, there are now two threads running on the ST forum. One guy described a process for fixing it but it isn't trivial. I also got asked by one ST employee for some logfile but he failed to tell me where I might find it, and never came back :) It is obvious what it is: Cube opens the C source for whichever point in the binary the CPU was running when it was halted. Normally this is not anywhere relevant; it is random. It tends to be waiting on some mutex, or in the RTOS Idle task (as you would expect). That file opening needs to be made conditional on the context in which the CPU halted. If it is not due to a breakpoint, do not open the file.
-
Just how you do it with a text editor?
You have to keep jumping back and forth within 50 header files to check how one of many functions has to be called, or its name, what arguments it takes, or what is the actual value of __TIMEOUT define, or where is it declared.
Autocomplete and hyperlinking are true game changers.
Any structure, typedef, define, function... control+click and you instantly spawn to their declaration/implemenation.
I had to code few times in Linux using gedit, it was a ** nightmare, only increased my hate against it.
-
Just how you do it with a text editor?
It can open multiple files and look at them simultaneously. The current project contains 30 compilation units. I have 12 files open at the moment, mostly remnants from the past. But I could've closed 9 of them. Today, I am actively editing only two of these files. Typically, I have one place where I add or change the program. I bookmark this place, so I can easily return back any time. Once I'm done with that, I move to a different place an put the main bookmark there. If I wander away, I can return back in a click of a button.
To navigate, I also use other bookmarks, searches, clicks from compiler errors. I guess I could've added shortcuts to declarations, but it doesn't seem like something I would use often.
I set up buttons to do things for me. For example, when I press F9 now, it saves files, compiles, programs the chip, runs it, reads information from the chip and prints it to the output window. Nothing hangs. Nothing crashes. That's what important for me.
-
One of the key things is that in Cube you can right-click on something to see where it is defined, etc, and the file with the definition opens even if it wasn't open.
This needs a lot more than a powerful editor. And it is a huge timesaver.
-
That's what I'm saying.
Let's face it: Northguy wants to call a new function, he'll need to search it in the other files or use a cheatsheet. Waste of time!
In the IDE, if you remember it was "SPI_Something", just type SPI.. Press control+space, all possible matches are shown.
Etc etc etc... I will never understand emacs fanboys (Who's creator sadly recently died.. RIP).
It's like those defending asm programming.
In the time I make 1/2 program you 'll make just one function, and if you have to access large amounts of data it'll be a nightmare!
-
Let's face it: Northguy wants to call a new function, he'll need to search it in the other files or use a cheatsheet. Waste of time!
In the IDE, if you remember it was "SPI_Something", just type SPI.. Press control+space, all possible matches are shown.
Etc etc etc... I will never understand emacs fanboys (Who's creator sadly recently died.. RIP).
It's like those defending asm programming.
In the time I make 1/2 program you 'll make just one function, and if you have to access large amounts of data it'll be a nightmare!
NorthGuy spends most of the time thinking, not typing. He doesn't use libraries with gazillions of functions. He operates directly on the registers which are documented in the datasheet. Moreover, it's a good chance NorthGuy wrote something like this before. So he will copy, paste, modify to the occasion, and it'll be all done by the time you pick the required set of SPI functions from the suggested dozens.
I would use all these functions if everything was fast, didn't have bugs, didn't crash etc. I actually did use IDEs most of my life, but then I decided that speed and reliability is more important, and never looked back since. That's a personal choice. I certainly don't insist that this is the best way for everyone. Best way is making your own decisions.
-
Have you even tried? I've spent entire afternoons coding on it.
The only crash I ocassionally have happens when opening other projects, suddenly the mouse starts switching very fast between "busy" and normal cursor.
Close the IDE, open again and continue working 20 seconds later.
It has its ugs but there's no need to exaggerate it.
-
Etc etc etc... I will never understand emacs fanboys (Who's creator sadly recently died.. RIP).
Did you seriously just mix up Emacs and Vim there? That's how wars get started :-)
-
My finding is that Cube runs fine for a day or two and then something happens and it needs to be restarted.
What makes it go "funny" is debugging. If you are just editing / building (ctrl-b) it runs fine for much longer.
Does it use the Java runtime installed under Windows? I thought it came with its own copy. Relying on the host JRT is a cause of many problems.
-
It has its own jdk.
-
Is anyone able to build Cube IDE i.e. is it all open source?
-
Nope. It's based in Eclipse but AFAIK ST's part is private.
-
Does it use the Java runtime installed under Windows? I thought it came with its own copy. Relying on the host JRT is a cause of many problems.
It's cross platform, you realise that right? What use would shipping the native part of the run time with the product be?
STM32Cube runs in Linux also for example.
The Java parts will also run in IA64 or on Raspberry PI.
-
The downloads for different platforms are different.
-
I say so because I know it, I use the built-in JDK in the building script for the soldering firmware, to launch CubeMX (Also built-in) and rebuilt HAL libs and init code automatically.
No idea about Linux or others, but in Windows it does pack its own.
-
It would be a huge hostage to fortune to not do so.
-
You say so? Linux is that. If the package exist in the apt repo, nice, but if it doesn't or it's outdated you'll have to build yoru own, and you can get into an endless dependency tree nightmare very quickly!
Everything feels like
"I just made my part, how to build, use, dependencies... not my business"
"welcome to OSS... bye!" :-DD
-
Well, linux is used only by experts who love to tinker, and if they spend all day to dig out some libs they are happy :)
Windows users just expect to install a program and expect it to work.
There is enough trouble with MS VC++ distributables. This is from the project notes I've been writing as I went along:
System requirements
These are unclear for Cube IDE but current (Aug 2021) CubeMX documentation says win8.1 or higher. It has been determined experimentally that Cube v1.8.0 installs fine on win7-64 SP1 with VC++ 2019 redistributables installed.
Cube 1.5.1 has a compiler version 7.3.1 20180622.
Cube 1.6.1 has a compiler version 9.3.1 20200408.
Cube 1.7.0 is the same as 1.6.1.
Cube 1.8.0 is the same again (no change in compiler or linker)
Cube 1.9.0 has a compiler v10 which does stricter checking of various things
Cube 1.10 is same as 1.9 but crashes more often
Cube 1.12 is as above, and mostly works ok
Cube 1.13.1 has a compiler v11.3.1 20220712
Cube is not a standalone executable, is written in Java, and uses a fantastic amount of resources and runtime libraries. It installs these by itself (the computer does not need Java installed) but it also needs Visual C++ redistributables (v2015 and possibly v2019 for later Cube versions like 1.8.0) and these can be hard to install on a win7 machine especially one which missed out on Microsoft updates just before they stopped doing them for win7. It has been experimentally determined that if you cannot go above VC++ 2013 then the latest Cube which will install is 1.5.1 (which works fine, incidentally).
It is however possible to bring a win7-64 machine fully up to date, using the Simplix route described here:
https://www.sevenforums.com/installation-setup/426198-possible-create-w7-64-install-never-needs-internet-access.html (https://www.sevenforums.com/installation-setup/426198-possible-create-w7-64-install-never-needs-internet-access.html)
and then you can download the MS VC++ 2019 x64 redistributable package.
-
I love to tinker too. But I love to tinker with what I want.
I don't want to tinker with 400 things before being able to tinker in what I wanted to tinker since the beginning.
It's so tiresome!
-
What use would shipping the native part of the [java] run time with the product be?
Sort-of like "Why would I need to save old versions of the compiler I used to build my code?"
History has shown that relying that the system-installed version of the Java Runtime be compatible with the runtime used to develop the original Java application is prone to causing non-operation. I didn't follow the details, so I don't know whether that's because the apps had "bugs" that were called out in later versions of the runtime, or whether the runtime just stopped being backward compatible. But Arduino, for example, started bundling a "known compatible" JRE quite some time ago, after "bad things happened."
-
Java is notorious for having runtime version dependencies.
This is why I cannot understand why Oracle keep forcing people to install Java runtimes on every PC. Most Java apps do not use these because the coder knew they are a hostage to fortune. I guess a few apps demand these and then you get update requests for ever, and disabling them does not work (a bug, obviously).
Java works well in server-side usage, because there you 100% control the whole code and if it runs now it will run for ever.
It's been a fantastic money generator in certain "professional" situations. ATC software in particular, which is mostly utter crap and which cost millions to write...
-
Peter. To be honest. I'd give up. All of your posts in this thread just say you aren't cut out to be a developer.
If you did my day job you'd go postal in weeks.
-
You are of course right. I've not had a proper job since I left univ :)
-
This is an example of some nasty crap in Cube - this time in ex ST Cube-MX-generated code
(https://peter-ftp.co.uk/screenshots/20231030256041814.jpg)
Normally one is pretty careful where one does a return() from a function, so everything needing a cleanup gets cleaned up.
-
But there's nothing wrong there?
Try to lock the handler, if already locked it means something else is using it, so return BUSY, nothing to clean!
-
Peter. To be honest. I'd give up. All of your posts in this thread just say you aren't cut out to be a developer.
That's probably true, but what he said about Java just above holds 100% true. Most Java apps are distributed with a compatible JRE that the app has been tested against, and a whole range of issues can occur if you use another JRE.
Java has never been all that stable in terms of compatibility, unless maybe you used only very basic libraries. Anything using fancy GUI Java libraries is a compatibility nightmare.
If you did my day job you'd go postal in weeks.
Don't know what your day job is, but certainly a pure software development position would make a lot of us go nuts very quick. It's become, uh, very special.
-
I think hiding a return() in a macro like that is crappy coding. It is OK in that function, but this code is generated for people to use as example in general.
Similar to having a macro in a .h file which actually generates executable code.
Re "cut out to be a dev" well obviously not, because a real dev
- comments nothing
- documents nothing
- uses esoteric pointer code which nobody else understands
- has no stake in the company staying in business (always on LinkedIn looking for his next job)
- could not care less if a product sells well for 10 years (never mind 25 like some of mine!) and has to be maintained after that time
- documents nothing
:)
-
because a real dev ...
Real programmer may or may not know the name of his spouse, but he knows all the ASCII codes.
-
I think hiding a return() in a macro like that is crappy coding. It is OK in that function, but this code is generated for people to use as example in general.
I agree in general, but that code is literally a HAL library. It's not generated for you to modify.
-
I still see no problem here.
Whats's the problem of inserting a return in a macro? Why would it be a bad coding practice?
this code is generated for people to use as example in general.
Absolutely not.
You should call the HAL function (SPI send, UART TX, whatever) and check the return code, not randomly call __HAL_LOCK, which is meant to be internally used by HAL, not by you!
It would be 100% your fault if you randomly call it without understanding what it does.
-
Re "cut out to be a dev" well obviously not, because a real dev
- comments nothing
- documents nothing
- uses esoteric pointer code which nobody else understands
- has no stake in the company staying in business (always on LinkedIn looking for his next job)
- could not care less if a product sells well for 10 years (never mind 25 like some of mine!) and has to be maintained after that time
- documents nothing
:)
It's not always the fault of the programmer. Often the company puts tight deadlines and doesn't want to spend
time & money for testing and documenting.
"Release quick, if people complain, we can fix it later with an update."
p.s.: I do use pointer arithmetic a lot, simply because I like it and because it's usually the most efficient way.
-
It's not always the fault of the programmer. Often the company puts tight deadlines and doesn't want to spend
time & money for testing and documenting.
People used to have integrity and would refuse to do crap if asked to.
"Release quick, if people complain, we can fix it later with an update."
But then new update will have two new bugs for every bug fixed.
I had to upgrade my Mac to Monterey OS because Apple has changed their "notarization" rules. This covers about 5 years of updates. It has become very slow and acquired new bugs.
-
that code is literally a HAL library. It's not generated for you to modify
We will have to agree to disagree.
This is not the age of the Z80 when you had to read a few pages, and to get a working system you copied a Nascom 1 circuit - basically a CPU+EPROM+RAM and some latches for I/O.
This is the age of a 300 page DS and a 2000 page RM. Lots of people use Cube MX to generate code fragments (they are fragments really because MX is great for knocking up quick demos and then you have to do lots of real work to get a finished product) to save time and save many hours of googling to see how others did something e.g. drive the SPI controller.
Lots of times one picks up a function and uses the "body" of it. Yesterday I picked up the "HAL" function for the random # gen and put a mutex at the start and end of it (because it is called both by TLS and other user code) and a macro which contains a return() will obviously blow it up, because the mutex will never get released. I would not be randomly calling just hal_lock, obviously.
Everybody posting here is an expert (except me; I am learning from a low base and 40 years of asm) but this is a great way to get bitten in the bum.
-
that code is literally a HAL library. It's not generated for you to modify
We will have to agree to disagree.
I guess to be more specific, what I meant was:
It's intended use is to be generated and used wholesale. They are not trying to provide a template, and so are free to do literally whatever. If you want to use it that way, you just have to be mindful of what it is you are taking. I think we agree that it is kindof poor form to hide a return behind a macro that, to me, is named is if to imply "wait until ready", not "if not ready, bail". Trailing on that:
I still see no problem here.
Whats's the problem of inserting a return in a macro? Why would it be a bad coding practice?
Nothing at all, as long is it isn't slightly misleading like __HAL_LOCK, where my first impression would be a wait until not-busy. __HAL_LOCK_OR_RETURN(), no problem there, clear as day what happens. Should you pay attention and understand what it is that means? Absolutely, but there can be friction in doing so where it is not obvious what something does.
-
Well, yeah, I do most of the time, specially "__HAL_” stuff, before taking anything for granted I find its declaration and check what it does.
-
Quite apart from anything else, the whole HAL_LOCK "system" doesn't do anything useful. It gives the impression of a mutex or semaphore but it is actually just a "busy" flag around each function which is completely useless AFAICT. Lots of other people have commented accordingly over the years. Whenever I use any of these functions I always remove that stupid "lock".
-
Its a mutex to prevent anything messing with the handler, for example in multithreaded systems, it does exactly what it should.
-
Its a mutex to prevent anything messing with the handler, for example in multithreaded systems, it does exactly what it should.
No it does not under any non cooperative threading model (time slicing, preemptive, multi core etc.).
Checking and setting the lock flag should be an atomic operation, and it's clearly not.
It's just a place holder for a possible RTOS compliant HAL.
-
Sort of. Still ST quality :)
-
Quite apart from anything else, the whole HAL_LOCK "system" doesn't do anything useful. It gives the impression of a mutex or semaphore but it is actually just a "busy" flag around each function which is completely useless AFAICT. Lots of other people have commented accordingly over the years. Whenever I use any of these functions I always remove that stupid "lock".
You can re-define the macro to nothing. Having an easy way to annihilate unneeded locks is a good thing.
-
I just fresh installed Cube on Windows 10.
I cloned an old (year) project from git and opened the IOC. It said I could upgrade it, so I said, "Aye on ya go then."
Then I hit Run. Did the your STLink has a new firmware dance and .... it worked.
It worked. Just worked.
Nothing to report here, nothing to see.
-
Yes; apart from Cube IDE occassionally changing the GCC tool version and introducing different default compiler/linker options which bring up new warnings, I have found Cube updates to "just work".
Occassionally I uninstall Cube totally and reinstall fresh, just to make sure.
-
>> a macro which contains a return() will obviously blow it up, because the mutex will never get released
If you use C++, you can define mutexes that release automatically when leaving their scope. Very handy and safe IMO. Example:
https://github.com/zapta/daq/blob/main/controller/platformio/lib/data_queue/data_queue.cpp#L98
-
TL;DR, using CubeIDE for configuration only and platformio for the rest.
A few months ago I started a STM32H7 project and had a dillema which IDE to use. My favorite IDE is platformio, for all MCUs, but realized the value of the CubeIDE value in generating the initial and updated configuration code from the .ioc file. As a result I setup an environment with a combination of the two. A CubeIDE project is used only for editing the .ioc file and generating the code, with no manual editing whatsoever, and a platformio project is used for the rest of the code development. I use a small python script to automatically update the platformio library when I make configuration changes in the CubeIDE project.
Overall it works great for me, being able to use the CubeIDE configurator with the platformio project.
This is the python script I am using. It does a few patches to the CubeIDE code to simplify having a separation between the CubeIDe files and the code files I edit in platformio.
https://github.com/zapta/daq/blob/main/controller/cube_ide/update_platformio.py
-
Just updated Cube IDE from v13 to v14 and the binary generated is identical. So thankfully they haven't changed the tools.
The random file opening issue (basically when you stop a running project, breakpoint, etc, a random .c file gets opened) has not been fixed. It still opens whichever .c file the CPU was executing at the time, which tends to be some bit of FreeRTOS in my case. The way to solve this has been worked out and documented but clearly ST don't want to do it.
-
Documented where?
-
I believe there is a post somewhere here where somebody found a way
https://community.st.com/t5/stm32cubeide-mcus/jumping-to-random-file-after-pressing-run-button/td-p/246693/page/9
Basically it involves putting a bit of code into the debugger interface so that when the breakpoint (which can be a Stop i.e. not necessarily an explicit user BP) is taken, it checks whether there is a user breakpoint at that address and, if not, it carries on. Or some variation of that... the inner workings of Eclipse (as modified by ST) and the debugger interface are a mystery to me.
-
ST may have done something to the random file opening issue
https://community.st.com/t5/stm32cubeide-mcus/jumping-to-random-file-after-pressing-run-button/m-p/633716/highlight/true#M23914
However I have forgotten the exact circumstances under which it was a really bad problem :)
-
Cube IDE is now v15. They changed the compiler etc version, and the generated code changes... gone from 483,332 bytes to 482,308 bytes! So (-Og) 1k less code :)
(https://peter-ftp.co.uk/screenshots/20240320486254215.jpg)
Sometimes a new GCC version changes the meaning of compiler/linker command line switches, but not this time, at least not for my project [NOTE at this point I did not test code execution; I just did a Build with ctrl-b]
Well, they broke the STLINK V3 debugger. Cube v15 offers up upgrade the debugger firmware and trashes it.
Encountered Error when opening C:\ST\STM32CubeIDE_1.13.2\STM32CubeIDE\plugins\com.st.stm32cube.ide.mcu.externaltools.cubeprogrammer.win32_2.1.200.202311302303\tools\bin\STM32_Programmer_CLI.exe
Error in STM32CubeProgrammer
and then
(https://peter-ftp.co.uk/screenshots/202403202118914818.jpg)
Does anyone know what this is? I now have two dead development systems and two dead targets which don't run even if the software is loaded using the ST Utility.
That "missing" ...CLI.exe file is in the right place, with the correct case too.
Update: downgrading to Cube 1.14.2 runs ok. The STLINK V3 upgraded using the firmware from Cube v1.15.0 also runs ok with Cube 1.14.2, which is just as well!
I am sure that GCC tools v12 break the code in some subtle way. Even loading the software using ST Utility produces a dead target. I will probably not spend much time on this since a) I do not need to just blindly keep upgrading Cube (it's actually a stupid idea to make work for yourself, since every tool update ought to need regression testing of the product) and b) I can't debug the target since the debugger also does not work with Cube v1.15!
-
Don't update, It always breaks things.
Instead, uninstall old, install new, delete workspace .metadata folder.
-
I did both (suspecting as you suggest) but the same result.
Yes on a proper installation I always uninstall (both Cube and the driver), delete c:\ST, and download a fresh .exe (1GB now ;) ).
There is something funny about the GCC v12 generated code, because my target dies when I do a firmware update over http (the target has an http server for this), or using ST Utility (which runs via the STLINK debugger). The most direct method, Cube IDE -> STLINK debugger, does not work, as described. There are hundreds of config options in Cube and the tools and the new install failing to pick these up correctly (from the project files) could bugger it up.
There is however one thing which I changed together with going to Cube v1.15: I removed the call to __libc_init_array() as described here
https://www.eevblog.com/forum/microcontrollers/mcu-programming-101-writeup/msg5402906/#msg5402906 (https://www.eevblog.com/forum/microcontrollers/mcu-programming-101-writeup/msg5402906/#msg5402906)
My project does not use C++ so this should be safe. However I am not 100.000% sure; I have some note in the project that __libc_init_array() is also needed for the libc printf(). Maybe I will revisit this one day. But if ST cocked-up there will be Cube IDE 1.15.1 out soon ;)
I don't have the sources to the __libc_init_array() in the libc distributed by ST. But e.g. this
https://stackoverflow.com/questions/49708591/use-of-libc-init-array-call-stm32 (https://stackoverflow.com/questions/49708591/use-of-libc-init-array-call-stm32)
is ambiguous about __libc_init_array().
Update: with the libc stuff put back in, Cube v1.15.0 still a) fails on the debugger and b) the compiled code does not run even with the libc put back in.
I am going to leave the libc init call in there. Google hits tend to suggest is applies to C also, not just C++, and is used to set up some statics in some libc functions. Entirely possible since ST do not distribute libc.a in source form, and some of the functions e.g. malloc() had to be mutexed for my project. This is not worth the risk. I have started various threads in the past on the mystery of libc.a and some people found probable sources, but nothing definite.
-
Doesn't __libc_init_array initialize all system variables? ???
-
This is the age of a 300 page DS and a 2000 page RM. Lots of people use Cube MX to generate code fragments (they are fragments really because MX is great for knocking up quick demos and then you have to do lots of real work to get a finished product) to save time and save many hours of googling to see how others did something e.g. drive the SPI controller.
Yeah, Cube is a kind of library of code snippets which helps to write initialization code with no need to read a bunch of datasheet and manuals, but then you're adapt generated code snippet for your needs :)
I even think that it will be better to not generate entire project, but to allow user to generate a short code snippet for specific peripherals with different options and then just copy-paste it into your project :)
-
Doesn't __libc_init_array initialize all system variables?
Not according to about 80% of google hits (which say C++ only, like wek in the linked thread) and the other 20% are non-specific (meaning it could be C also).
As I said, I strongly suspect the ST supplied libc.a does use this function to set up other stuff like static variables, but the time I spent messing with this was c. 2021, and my final decision back then was to leave it in there.
If you have a reference, I am all ears :)
I have just stepped through the code (has to be done with Cube switched to displaying assembler) and there is very little code being run.
I also posted the Q here
https://community.st.com/t5/stm32cubeide-mcus/the-mysterious-libc-init-array-in-cube-ide-is-it-only-for-c/m-p/652829#M25352
and got the usual vague reply.
I even think that it will be better to not generate entire project, but to allow user to generate a short code snippet for specific peripherals with different options and then just copy-paste it into your project
Well, yes, thera are two schools of thought on this. The experts say you should read the 2000 page RM (the bits which your project uses, plus other stuff because the code won't actually run if you do just that) while others use Cube MX to generate chunks of code for the project (and these people then get stuck after they got the LED flashing :) and end up posting "please help" all over the internet). I think the best approach is halfway: use MX to generate bits of code, see what it generated, and then edit it to do what you actually want, only.
-
I don't have the sources to the __libc_init_array() in the libc distributed by ST. But e.g. this
https://stackoverflow.com/questions/49708591/use-of-libc-init-array-call-stm32 (https://stackoverflow.com/questions/49708591/use-of-libc-init-array-call-stm32)
is ambiguous about __libc_init_array().
Update: with the libc stuff put back in, Cube v1.15.0 still a) fails on the debugger and b) the compiled code does not run even with the libc put back in.
I am going to leave the libc init call in there. Google hits tend to suggest is applies to C also, not just C++, and is used to set up some statics in some libc functions. Entirely possible since ST do not distribute libc.a in source form, and some of the functions e.g. malloc() had to be mutexed for my project. This is not worth the risk. I have started various threads in the past on the mystery of libc.a and some people found probable sources, but nothing definite.
I believe that __libc_init_array() is only for calling the array of C++ constructors - which will be empty if your program is just C. If ST is providing minimal functions using the newlib library, then the sources are available: https://sourceware.org/newlib/ (https://sourceware.org/newlib/)
For easier viewing on github, a google search of an unofficial newlib mirror, the function is here:
https://github.com/bminor/newlib/blob/master/newlib/libc/misc/init.c
-
1) See here
https://www.eevblog.com/forum/microcontrollers/is-st-cube-ide-a-piece-of-buggy-crap/msg4363183/#msg4363183 (https://www.eevblog.com/forum/microcontrollers/is-st-cube-ide-a-piece-of-buggy-crap/msg4363183/#msg4363183)
for a discussion about the libc.a sources. This is extremely tricky. Sure, one can find some src on github etc... For example which printf() source was used??
2) Stepping through the __libc_init_array(), in assembler of course, one can see a loop taken about 3 times, so it isn't completely empty.
From my project notes, from c. 2021:
The likely original printf source in libc.a was
https://sourceware.org/git?p=newlib-cygwin.git;a=blob;f=newlib/libc/stdio/vfprintf.c;h=6a198e2c657e8cf44b720c8bec76b1121921a42d;hb=HEAD#l866 (https://sourceware.org/git?p=newlib-cygwin.git;a=blob;f=newlib/libc/stdio/vfprintf.c;h=6a198e2c657e8cf44b720c8bec76b1121921a42d;hb=HEAD#l866)
Probable scanf sources
The likely scanf source in libc.a is
https://sourceware.org/git/?p=newlib-cygwin.git;a=blob;f=newlib/libc/stdio/sprintf.c;h=be66ec6f5d73589e5147afeb7634b9de0daba09d;hb=HEAD (https://sourceware.org/git/?p=newlib-cygwin.git;a=blob;f=newlib/libc/stdio/sprintf.c;h=be66ec6f5d73589e5147afeb7634b9de0daba09d;hb=HEAD)
or
https://sourceware.org/git/?p=newlib-cygwin.git;a=tree;f=newlib/libc/stdio;h=0f5e4dd0dc465029d0b6c0a5d03fc2cc70e8df87;hb=HEAD (https://sourceware.org/git/?p=newlib-cygwin.git;a=tree;f=newlib/libc/stdio;h=0f5e4dd0dc465029d0b6c0a5d03fc2cc70e8df87;hb=HEAD)
and that does use malloc but it’s not clear if the one in the Cube lib uses it. A breakpoint on _sbrk is not hit.
Other Newlib sources can be found here
https://developer.arm.com/downloads/-/arm-gnu-toolchain-downloads (https://developer.arm.com/downloads/-/arm-gnu-toolchain-downloads)
Probable heap sources
If looking for heap source code, this may help:
https://www.eevblog.com/forum/programming/heap-analysis-tool-for-embedded-systems/ (https://www.eevblog.com/forum/programming/heap-analysis-tool-for-embedded-systems/)
Note that our libc.a contains the heap code also.
The current heap code seems to allocate 4 bytes for each block, and sometimes 4 more bytes are added for alignment. See here
https://www.eevblog.com/forum/programming/heap-analysis-tool-for-embedded-systems/msg4835657/#msg4835657 (https://www.eevblog.com/forum/programming/heap-analysis-tool-for-embedded-systems/msg4835657/#msg4835657)
However the suggested candidate source code
https://github.com/devkitPro/newlib/blob/master/newlib/libc/stdlib/_mallocr.c (https://github.com/devkitPro/newlib/blob/master/newlib/libc/stdlib/_mallocr.c)
appears to not be the one (unless fixed since) because the problem described here
https://stackoverflow.com/questions/39088598/malloc-in-newlib-does-it-waste-memory-after-one-big-failure-allocation/76138157#76138157 (https://stackoverflow.com/questions/39088598/malloc-in-newlib-does-it-waste-memory-after-one-big-failure-allocation/76138157#76138157)
(which does refer to the above source) is not present in ours. A malloc of a block larger than heap space fails correctly but subsequent reduced mallocs work fine.
A more likely candidate sourcecode is the “nano”
https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=blob;f=newlib/libc/stdlib/nano-mallocr.c;h=13b72c99ffd7007b53c2e3270a56da237857742a;hb=HEAD (https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=blob;f=newlib/libc/stdlib/nano-mallocr.c;h=13b72c99ffd7007b53c2e3270a56da237857742a;hb=HEAD)
but it probably is not, or not quite
https://www.eevblog.com/forum/programming/help-needed-with-some-heap-test-code/msg4845821/#msg4845821 (https://www.eevblog.com/forum/programming/help-needed-with-some-heap-test-code/msg4845821/#msg4845821)
-
Cube 1.15.0 emits this warning
Description Resource Path Location Type
xxxx.elf has a LOAD segment with RWX permissions
But it happened only once. Others have seen it
https://community.st.com/t5/stm32cubeide-mcus/stm32cubeide-1-15-0-elf-has-a-load-segment-with-rwx-permissions/td-p/652335
and the solution is pretty complicated.
Anyway 1.15.0 is unusable.
Here is the function
(https://peter-ftp.co.uk/screenshots/20240321556260712.jpg)
and
(https://peter-ftp.co.uk/screenshots/20240321036271012.jpg)
The code from 306: to 31e: is executed twice.
The whole thing is weird with 1.15.0. The debugger fails as posted above. And when that fails, ST Utility, while programming the chip OK, also fails to deliver a running target, suggesting that code generated by 1.15.0 is faulty in some way. But when I reinstall 1.14.1 everything immediately works, including the ST Utility loading working code. And obviously without a working debugger there is no way to track down the problem.
-
To remove that warning just add "--no-warn-rwx-segments" and "--no-warn-execstack" to the linker flags under "Miscellaneous" tab.
Source: https://lore.kernel.org/all/20220802083023.1488625-1-joel@jms.id.au/T/
-
The linker RWX warning appeared in more recent versions of binutils and is likely to be triggered by most linker scripts for ARM Cortex-M targets.
Adding the "--no-warn-rwx-segments" option to the linker is enough to silence it.
The rationale for this warning is rather simple, but it's pretty annoying for the usual "embedded" targets.
-
This started with GCC 12.
Does it affect code generation?
I never had a running target with any ex-GCC12 binary, but could not debug it because Cube IDE 1.15.0 fails on the debugger :)
-
No, it doesn't affect code generation. It's only a warning from the linker.
Here are more details about these warnings: https://www.redhat.com/en/blog/linkers-warnings-about-executable-stacks-and-segments (https://www.redhat.com/en/blog/linkers-warnings-about-executable-stacks-and-segments)
-
Executable stacks... !!
But I wonder where GCC gets the idea that my stack is executable. In reality it is because it is RAM and STM32 does not have exec protection on selected RAM areas (AFAIK). But I am not declaring the stack in the linkfile. It is defined by loading SP and making sure there is room below it. And in the RTOS environment, each task has its own stack, quite a small one because there are many of these.
-
Doesn't __libc_init_array initialize all system variables?
Not according to about 80% of google hits (which say C++ only, like wek in the linked thread) and the other 20% are non-specific (meaning it could be C also).
It runs constructors. For C++ this obviously means any static object that has a constructor gets it run at this stage. But any C function can be annotated with __attribute__((constructor)) - this will cause a call to this function to be added to the constructor list. It's not quite the same as C++ (where ctor's are called with a reference to what's to be initialized). You need to be careful not to omit these, because they are used by libraries. Take a look at for example libssp, the stack protector support library: https://github.com/gcc-mirror/gcc/blob/7a5a4a4467b2e18ff4fe24f565e120280d3e6ba7/libssp/ssp.c#L72 - just a quick example that's probably never used in bare metal type scenarios, just pulled it up to illustrate it's actually used.
While it's not frequently used, assuming it's not present is a good way to introduce incredibly subtle bugs caused by uninitialized data deep in some compiler support library... It's also a moving target, so would need to be reverified (through manual inspection) every time the tools are changed. I'd just leave the ctor init list in place. (If your code never exits, which firmware typically doesn't, the destructor table can be completely omitted, including the code sections it refers to, assuming section-per-function code generation.)
-
Sorry, I know is slightly offtopic and havn't had time to install ST Cube IDE 1.15.0 just yet.
I'm still on 1.13.1.
I've just tried a breakpoint on a led blink sample with the Nucelo 144 STM32H753ZI dev board. In mine, the same code is only executed once.
Line 2400c065 is a jump to the empty _init() stub function, which simply push/pop (save and restore some registers), executes a nop instruction and then returns.
Lines 2400c07d to 2400c083 corresponds to reading the .init_array list of C++ constructors. The newlib library added in a frame_dummy() function to the init_array list and that is what blx r3 jumps to. The execution goes in and shortly returns, and since there are no constructors the loop ends.
-
I forgot to mention, you can see that the .init_array section is 4B (bytes), which means there is only the one function pointer in the list, which is the frame_dummy().
-
Executable stacks... !!
This is what happens when one only reads titles or just the beginning of articles.
It deals with both executable stacks and executable segments in different sections of the article. For your case, read the section about executable segments.
-
STM32 does not have exec protection on selected RAM areas (AFAIK)
Many STM32 (and other vendors'MCUs) have an MPU, even the cortex-m0+ ones.
E.g: https://www.st.com/resource/en/datasheet/stm32g071c8.pdf (https://www.st.com/resource/en/datasheet/stm32g071c8.pdf)
Depending on core type and vendor implementation, it can have either 8 or 16 memory areas, from 32 bytes to 4GiB (plus the default optional background attributes) and control RW privileges, memory ordering, caching and executable permissions.
FreeRTOS can be MPU aware: https://www.freertos.org/FreeRTOS-MPU-memory-protection-unit.html (https://www.freertos.org/FreeRTOS-MPU-memory-protection-unit.html)
-
OK, so to summarise, if you declare a function in C using the Constructor attribute (which I have never heard of but potentially anybody can do this) that adds that function to some list of function addresses (the list being stored "somewhere" in RAM) and then calling __libc_init_array() calls every function address in that list, once.
Yeah, potentially useful but also why would anyone do something so relatively opaque? If you need to initialise a UART you just call init_uart() or whatever. Then you know exactly when that happens, rather than using some indirect method where you don't actually know the order in which the list is processed. Presumably the order is according to when the compiler comes across the Constructor attribute, which could bite you in the bum big-time. A lot of hardware initialisation is order-critical.
Many STM32 (and other vendors'MCUs) have an MPU, even the cortex-m0+ ones.
OK; many thanks. My 32F417 does have an MPU but with just 8 areas whereas I have some 20 RTOS tasks. Still, unless your product has an LCD or some accessible error log, there is no way to report access violations :) It is the old embedded problem, around since for ever, with stuff like division by zero traps.
It could be useful. In my system I can display RTOS stack usage with a graphical utility (custom written for me by a guy on Freelancer) which shows unused parts of stacks, so I can check, over time, the max usage.
-
OK; many thanks. My 32F417 does have an MPU but with just 8 areas whereas I have some 20 RTOS tasks.
Have you read the linked FreeRTOS article?
Protecting each task individually is not really advisable (or even possible without pointless contortions).
I use the MPU to prevent caching for some DMA buffers, while I am at it I also make the ITCM and external QSPI not writable, and all data RAM areas not executable, so FreeRTOS stacks and heap (and all the rest) are 'protected'.
This happens after static variables (optional) and ITCM (mandatory) are initialized by the startup code.
This helps not for security, given the application, rather to give a MemFault error in (some) case of a rogue function or data pointer.
Not that the linker is aware of this, though. :-//
As for the "constructor" attribute, it might be useful to initialize HW needed before main starts, like e.g. external memories.
I have my own startup code, so I don't really have an use it, but it comes handy if you want to use the standard one.
OTOH the vendor/CMSIS standard startup code declares a SystemInit() weak function to put your stuff into.
-
Yes; thank you. Unfortunately I am on FR V10.0.1. But I get the drift. You reconfig the MPU as you switch tasks, so for protection in the RTOS task context you just need one protected block.
It may also be possible to aggregate all FR task stacks into one block which could be exec-protected in one go?
Protecting flash address 0 (well 0x8000000 or whatever) from writing might yield interesting results in many running products ;)
The general stack (used by ISRs, startup, etc) could be protected. One day I might give this a go. I have some personal hobby applications for this product and can play then :)
Yes I can now see the intention behind systeminit() etc. I re-hashed that ex-cube-mx code greatly, discovering e.g. that some of the init was duplicated. No surprise that nobody noticed ;) The project was started c. 2016 by a 0.5 day a week colleague, was on the back burner for years while he was doing stuff like setting up a Magento online shop, etc, and he used MX to generate the original code. Predictably it was a right mess.
-
OK, so to summarise, if you declare a function in C using the Constructor attribute (which I have never heard of but potentially anybody can do this) that adds that function to some list of function addresses (the list being stored "somewhere" in RAM) and then calling __libc_init_array() calls every function address in that list, once.
Correct. The implementation of __libc_init_array() can be easily found and scrutinised: https://github.com/bminor/newlib/blob/master/newlib/libc/misc/init.c
Yeah, potentially useful but also why would anyone do something so relatively opaque?
This mechanism is mostly used by libraries, Newlib being one of them. You link the library into your binary, and the (opaque) library stuff is being initialised automagically, before your main() is called. You don't need neither to remember nor to know that some (opaque) library feature needs initialisation. Who ever reads the boring implementation notes of snprintf() or rand()?
If you need to initialise a UART you just call init_uart() or whatever. Then you know exactly when that happens, rather than using some indirect method where you don't actually know the order in which the list is processed. Presumably the order is according to when the compiler comes across the Constructor attribute, which could bite you in the bum big-time. A lot of hardware initialisation is order-critical.
Correct. Sane design should not use gcc constructors to initialise hardware, for exactly these reasons.
-
Thank you. That all makes sense, and explains why I have project notes from 2021 saying about putting this back in because weird stuff was happening, even though 80% of the internet says it is C++ only :)
What is the difference between the 1st and the 2nd loop?
count = __preinit_array_end - __preinit_array_start;
for (i = 0; i < count; i++)
__preinit_array_start[i] ();
#ifdef _HAVE_INIT_FINI
_init ();
#endif
count = __init_array_end - __init_array_start;
for (i = 0; i < count; i++)
__init_array_start[i] ();
IOW, what is the difference between preinit_array and init_array? I've had a dig around but can't see anything. Well, apart from finding yet more posts from experts on the ST forum saying this is only C++ :)
The fini_array should never be called in an embedded system.
-
... even though 80% of the internet says it is C++ only :)
Sounds like a Pavlov's dog reaction: "constructor" --> "C++"
IOW, what is the difference between preinit_array and init_array? I've had a dig around but can't see anything.
Newlib, in its embeddable flashable static-library variant, originates from bigger systems where shared libraries are loaded into RAM and linked dynamically with an executable object in RAM. Some parts of that shared libraries might require early initialisation just after mapping but before the main initialisation happens. Consider preinit_array a rudiment, it doesn't play any special (or useful) role in embedded systems.
-
That suggests that the preinit_array list is populated with an attribute other than constructor?
-
Having __attribute__((preconstructor)) would be too easy, life is struggle!
preinit_array should be populated manually.
-
Something like
static void funcA(void) { ... }
static void funcB(void) { ... }
static void funcC(void) { ... }
__attribute__((used,section(".preinit_array"))) static void (*blah[])(void) = {
funcA,
funcB,
funcC
};
-
... even though 80% of the internet says it is C++ only :)
Sounds like a Pavlov's dog reaction: "constructor" --> "C++"
Can you please point to a good source thoroughly documenting what "constructor" might mean?
JW Pavlov's dog
-
Can you please point to a good source thoroughly documenting what "constructor" might mean?
For explanation of "constructor" in context of C programming language and corresponding compilers, you might have a look at ARM documentation (https://developer.arm.com/documentation/101754/0622/armclang-Reference/Compiler-specific-Function--Variable--and-Type-Attributes/--attribute----constructor-priority----function-attribute) or GNU documentation (https://gcc.gnu.org/onlinedocs/gcc-13.2.0/gcc/Common-Function-Attributes.html). Good enough source for me, but YMMV.
For broad sense of "constructor", there is Cambridge Dictionary (https://dictionary.cambridge.org/dictionary/english/constructor). The page comes with multiple useful examples.
-
Can you please point to a good source thoroughly documenting what "constructor" might mean?
For explanation of "constructor" in context of C programming language and corresponding compilers, you might have a look at ARM documentation (https://developer.arm.com/documentation/101754/0622/armclang-Reference/Compiler-specific-Function--Variable--and-Type-Attributes/--attribute----constructor-priority----function-attribute) or GNU documentation (https://gcc.gnu.org/onlinedocs/gcc-13.2.0/gcc/Common-Function-Attributes.html). Good enough source for me, but YMMV.
Okay, so, would you agree, that in C, "constructor" means "function in user code, which has the 'constructor' attribute (which in turn implies it will be run before main())"?
This would then be different from "constuctor" in C++, which means "code added automatically by the compiler, which in case of static constructiors will be run before main()". The difference is, that it's *compiler generated* rather than written by user (read, user has less control on the former than on the latter).
Or, I might've rephrased the question, is there any code output by compiler for C which will be run before main()? And, if yes, is there a comprehensive documentation for individual compilers (and I am particularly interested in gcc) of these codes, and under which conditions are they generated?
Thanks,
JW
-
For those who are curious, here is an example of the compiler automatically adding to the .init_array list:
By adding some C++ files to my STM32 led_blink project, the .init_array section is now 8 bytes - an extra pointer was added automatically for the global class object instance (with default constructor):
static led_state_class ls0;
Demonstration C++ and C wrapper files:
Minimal class class_test.h:
#ifndef INC_CLASS_TEST_H_
#define INC_CLASS_TEST_H_
#include <stdbool.h>
class led_state_class{
public:
bool is_enabled;
led_state_class(){
is_enabled = false;
}
};
#endif
class_test_wrapper.h
#ifndef INC_CLASS_TEST_C_H_
#define INC_CLASS_TEST_C_H_
#ifdef __cplusplus
extern "C" {
#endif
#include <stdbool.h>
bool get_enabled(void);
void set_enabled(bool is_enabled);
#ifdef __cplusplus
}
#endif
#endif
class_wrapper.cpp
#include "class_test_wrapper.h"
#include "class_test.h"
#ifdef __cplusplus
extern "C" {
#endif
static led_state_class ls0;
bool get_enabled(void){
return ls0.is_enabled;
}
void set_enabled(bool is_enabled){
ls0.is_enabled = is_enabled;
}
#ifdef __cplusplus
}
#endif
-
is there any code output by compiler for C which will be run before main()
We may be talking cross-wires since you obviously know this, but AFAICT with GCC there is none other than what it does for any other C function.
The name "main()" has a special meaning to Cube IDE (and maybe to other IDEs) only in that there is a feature to auto-insert a breakpoint on the main() source line. Actually this feature has been moved and I can no longer find it, and it may have been removed because I no longer get that breakpoint. I am not aware that the compiler cares about the function main() other than insisting that it is type int and is a void, though that may be because there is a prototype for it (but I cannot find one).
The code execution starts at the 2nd word in the vector table and that starts execution at whatever code happens to be at that address (the linkfile.ld controls that). That code then eventually calls main().
I have just stepped through some code and at the start of main() I see this (the memcpy line is just further code; not relevant)
(https://peter-ftp.co.uk/screenshots/20240325046292616.jpg)
I think it is just setting up a stack frame for variables, but there aren't any.
So the answer to the Q above seems to be NO.
Mysteriously, the disassembly listing no longer works (Cube 1.14.1); maybe Cube has got confused
(https://peter-ftp.co.uk/screenshots/20240325346303216.jpg)
It shows it as the bottom if I Open New View. Fixed, by deleting the empty Disassembly window and dragging the working one from the bottom to the top right. Oh well...
-
Okay, so, would you agree, that in C, "constructor" means "function in user code, which has the 'constructor' attribute (which in turn implies it will be run before main())"?
If the expression "in C" means "in some implementations of C language standard by some compilers", then yes, I would agree.
This would then be different from "constuctor" in C++, which means "code added automatically by the compiler, which in case of static constructors will be run before main()". The difference is, that it's *compiler generated* rather than written by user (read, user has less control on the former than on the latter).
My rather limited knowledge of C++ tells me that C++ constructors are hand-written by a live person. Consider the following piece of code:
class Schwartz {
public:
// This is constructor
Schwartz() {
cout << "WHOA! Liquid Schwartz!!";
}
};
int main() {
Schwartz theSchwartz; // Calling the constructor
return 0;
}
In C++, the developer has the complete control over when and what constructor is called (there could be constructors with parameters for the same class).
In C, the constructors are called in undefined order, if special means are not taken by a developer. As documented, they are called before main(), period.
Or, I might've rephrased the question, is there any code output by compiler for C which will be run before main()?
I am not a compiler engineer, but to the best of my knowledge, and from my experience, no code before main() is generated by C compiler. Instead, the start-up code is hand-written by a person -- an end-user of the chip/compiler or the chip vendors' engineers. The start-up code even calls main(), otherwise it will never be executed. We are talking now about narrow niche of MCUs and armcc/gcc/llvm compilers which generate flashable code.
And, if yes, is there a comprehensive documentation for individual compilers (and I am particularly interested in gcc) of these codes, and under which conditions are they generated?
Sure!
Embedded Artistry:
Exploring Startup Implementations: Newlib (ARM) (https://embeddedartistry.com/blog/2019/04/17/exploring-startup-implementations-newlib-arm/)
Memfault:
From Zero to main(): Bare metal C (https://interrupt.memfault.com/blog/zero-to-main-1)
From Zero to main(): Bootstrapping libc with Newlib (https://interrupt.memfault.com/blog/boostrapping-libc-with-newlib)
From Zero to main(): Demystifying Firmware Linker Scripts (https://interrupt.memfault.com/blog/how-to-write-linker-scripts-for-firmware)
Tellurium (a member here):
A bare metal programming guide (https://github.com/cpq/bare-metal-programming-guide)
-
In C++, the developer has the complete control over when and what constructor is called (there could be constructors with parameters for the same class).
Here is the code where sequence of constructor calling is undefined, the compiler can call it A, B, C or B, A, C it depends on compiler:
#include <iostream>
class A {
public:
A() { std::cout << "A()\n"; }
};
class B {
public:
B() { std::cout << "B()\n"; }
};
class C : public A, public B {
public:
C() { std::cout << "C()\n"; }
};
int main() {
C c;
return 0;
}
Another example:
#include <iostream>
class A {
public:
A() { std::cout << "A()\n"; }
};
class B {
public:
B() { std::cout << "B()\n"; }
};
class C : public A, public B {
public:
C(int x) : B(), A() { std::cout << "C()\n"; }
};
int main() {
C c(0);
return 0;
}
Here we declaring that constructor C should call B and A, but the sequence of calling is undefined and depends on compiler.
This is one of examples why multiple inheritance is not good... :)
-
In C++, the developer has the complete control over when and what constructor is called (there could be constructors with parameters for the same class).
Here is the code where sequence of constructor calling is undefined, the compiler can call it A, B, C or B, A, C it depends on compiler:
...
The order is defined, see here: https://en.cppreference.com/w/cpp/language/constructor
direct bases are initialized in left-to-right order as they appear in this class's base-specifier list
-
Having bits of code called in an order which is compiler version dependent, with only "before main()" being assured, is really dangerous, and difficult to debug.
-
Having bits of code called in an order which is compiler version dependent, with only "before main()" being assured, is really dangerous, and difficult to debug.
And yet it happens all the time, e.g. to initialize static variables in C. Those without explicit assignment are initialized to zero. Or it can put a data pattern to later detect stack usage/errors. You can work without using all that if you prefer so. There are compiler switches.
Regards, Dieter
-
is there any code output by compiler for C which will be run before main()?
In avr-gcc, this is done by putting code in “.initN” sections, where values of N are well defined to happen at various points of the code initialization.
https://www.nongnu.org/avr-libc/user-manual/mem_sections.html (https://www.nongnu.org/avr-libc/user-manual/mem_sections.html)
Some sort of provision for pre-main code seems important for embedded development (say to set up a non-standard stack), but having multiple different implementations is confusing.
-
Some sort of provision for pre-main code seems important for embedded development
In theory yes but with ARM GCC it only sets up a stack frame, which you can chuck away immediately with 1 line of asm
int main(void)
{
asm volatile ("ldr sp, = 0x20000000 \n");
etc
}
-
is there any code output by compiler for C which will be run before main()?
In avr-gcc, this is done by putting code in “.initN” sections, where values of N are well defined to happen at various points of the code initialization.
https://www.nongnu.org/avr-libc/user-manual/mem_sections.html (https://www.nongnu.org/avr-libc/user-manual/mem_sections.html)
Yes, but that does not imply that it's the *C compiler* which inserts code there.
having multiple different implementations is confusing.
I continue to agree (https://www.avrfreaks.net/s/topic/a5C3l000000UL5rEAG/t094877?comment=P-607188) ;-)
JW
-
with ARM GCC it [pre-main code] only sets up a stack frame
Really? What about, zeroing bss and copying initialized data from flash to ram?
-
The compiler does not do that. The code which main() { } generates is just as I showed - the stack frame for main().
Zeroing BSS, copying ROM init data to RAM, you have to do somewhere else before reaching main() - in ARM GCC anyway.
-
Isn't all that covered in startup.s in STM32?
-
... and does the "elf" executable format not get used on STM32?
So if you are looking for how to setup the memory maps and all the rest it would be in the ELF part of the build, which I believe is the linker?
ELF's just is to load the application and provide what is needed to call main... and take the return code (don't test this, it goes badly wrong on STM32 and their docs says as much).
-
... and does the "elf" executable format not get used on STM32?
If you mean that an ELF file is flashed to bare-metal STM32 (or NXP S32K, or Ambiq Apollo), then no. Even if it contains FreeRTOS, or NuttX, or Zephyr -- no.
So if you are looking for how to setup the memory maps and all the rest it would be in the ELF part of the build, which I believe is the linker?
Kind of correct, but an ELF file is produces based on linker script. That is the source and description of memory maps.
ELF's just is to load the application and provide what is needed to call main... and take the return code (don't test this, it goes badly wrong on STM32 and their docs says as much).
ELF is used during the build as an intermediate format to generate binary and hex files. And these will be be loaded onto the MCU.
-
In C++, the developer has the complete control over when and what constructor is called (there could be constructors with parameters for the same class).
Here is the code where sequence of constructor calling is undefined, the compiler can call it A, B, C or B, A, C it depends on compiler:
...
The order is defined, see here: https://en.cppreference.com/w/cpp/language/constructor
direct bases are initialized in left-to-right order as they appear in this class's base-specifier list
In both gcc and clang __attribute__((constructor(<priority>))) can be used to, explicitly, specify the execution order of static constructors. Not exactly elegant, but working.
-
Isn't all that covered in startup.s in STM32?
Yes.
and does the "elf" executable format not get used on STM32?
AFAIK the ELF is used only to load up the STLINK debugger, which writes the FLASH.
But if you want a binary for some reason, say to distribute firmware updates:
rem generate x.dat
arm-none-eabi-objcopy -S --strip-all -R .bss -R .main_heap -R .ccmram -O binary x.elf x.bin
Probably this is used internally to load the debugger?
-
Does this Cube IDE feature literally allow the installation of different versions of GCC, without weird side effects?
When you open this form, it just shows the current version (11.3) and then it says "fetching index..." and it fills in all the others visible here
(https://peter-ftp.co.uk/screenshots/20240409146364714.jpg)
I struggle to see how this "just works" given that different versions have different default command line options, etc.
-
Idea behind more version of tools in toolchain manager is to be able to use newest IDE with older projects.
When I need to check something on old project now I can use configuration(IDE version) that I have currently on the PC.
Think ST was motivated by people like me that were pissed when IDE auto updated and code that was compiling with older GCC fine with newer version refused to compile.
Newest GNU tools are always the best, but sometimes I just need to make debug session on old code without modifying it.
-
Newest GNU tools are always the best
That's quite a philosophical debate actually :) What is the "best" when you have a solid product which is selling, and you recompile it with GCC v n+1 and it no longer runs. You may have to spend loads of time on a) finding out why and b) regression testing a potentially large project. It is extremely poor business risk management! The correct way is to freeze the tools version some considerable time before the product is released.
It reminds me of the old debates back when I used to do FPGA design consultancy in the late 1990s - Xilinx. You were of course supposed to design the whole project fully synchronously, so you have just a single clock net (or multiple clock nets doing different bits) and control the clock routing by gating it. That way, in theory, when Xilinx changed the silicon without telling anybody and made it 5x faster, the thing "should still work". There were many problems with that e.g. a) the power consumption was maximised because basically the whole die was going up and down at the clock speed b) if you were doing ASIC prototyping you were often targeting power consumption which is incompatible with a), c) the same "good business risk management" approach as with the STM32 above.
A purist will argue puritanically because that is what a purist does, but the purist is most likely paid by the hour and doesn't care if something breaks, because fixing stuff puts bread on the table at home :)
I froze my project at Cube 1.14.1 / GCC 11.3.
But my Q stands: does this really work? What I mean is e.g. in Cube IDE you specify compiler options (indirectly by checkboxes which indirectly select the libc.a version which uses the specified newlib with hardware floats, etc) but in this tools version selector which can select a GCC version which does not 1:1 map with that. Or does GCC always 1:1 map with the compiler and linker (library / printf type) switches? Not sure I am making sense.
-
That's quite a philosophical debate actually :) What is the "best" when you have a solid product which is selling, and you recompile it with GCC v n+1 and it no longer runs. You may have to spend loads of time on a) finding out why and b) regression testing a potentially large project. It is extremely poor business risk management! The correct way is to freeze the tools version some considerable time before the product is released.
In depends on what you are developing. In my world... Tool chains have security vulnerabilities. It is not uncommon for the toolchain (and build infrastructure) to be shared between many projects and they are usually upgraded, with warning, when vulnerabilities are raised. If a particular project runs into issues with the new toolchain, there is usually a way to manually configure an "exceptional" toolchain config. This will however give the project an "Out of compliance" flag which is summarised to management weekly. You can't stay out of compliance without higher and higher up approvals as time goes on.
Even AFTER release when a vulnerability is discovered in either the app code or the toolchain/libraries a new release is created within 2 weeks (or more out of compliance).
Now lets say that you "own" project A. Project A, it's tool chain and it's libraries are squeaky clean. However, you depend on Project B's service. Project B has red flags and needs to do a release. You need to test your project against their new release (or they do!). You can then encounter "breaking changes" and start into negotiations, but usually end up fixing it on yourside if they have a more upto date release.
I mean, not all software has an active and frequent release cycle. Not all software or toolchain output is affected by security vuls.
I have a Casio calculator that has the same firmware it had back in 1994. It still works. I have not checked Casio's errata on it, but I would imagine there have been bugs found, but due to the vintage, there is no way to fix them, other than returning them to the factor to replace the blob IC.
A lot of embedded projects have so little external influences they have a tiny security surface area to consider. So old stale releases with bugs are fine.
We talked about this before. A large part of embedded software is now working on the modern "agile, constant release" project cadence. This is what causes all those pesky "Update Available" for firmware in modern 'IoT' eco-systems. Hell even if you use an Arduino and depend on a board file and a lib, they get updated frequently too!
The "Maintenance" phase of the software life cycle is not one you can simply ignore. Depending on how long a life the software has the "Maintenance" and "Support" phase is usually the most expensive bit.
EDIT: Also, in my world, we have quite a lot of processes, techniques, tools and prior work to lean on when it comes to testing. Most projects slowly grow in automation. In the first instance of an upgrade in shared dependencies or toolchians, the pipeline will automatically build, run the unit tests, check the code for smells and even in some setups run the full end2end integration tests automatically and produce a report. If all that comes back green, then the only thing you need is a pre-prod sanity check when it's deployed, to sign it off for PROD.
-
I wonder if somebody out there has actually used that feature - other than in the simple scenario of reverting to the last version of GCC upon upgrading Cube.
Re bug fixes, one doesn't need to update the IDE or the tools at all.
STM fairly comprehensively broke Cube 1.15.0 anyway, so as well as GCC 12 breaking some stuff you have Cube breaking the debugger etc.
-
Retired sw guy here. Yes, it's buggy. It was buggy 6 years ago when I last worked with it. It will always be buggy as it's chasing the latest flavor of stm cpu. It's part of marketing the stm hw chips.
The cube is a way to help get projects off and running fast, not bug free running. No project leader wants the team to struggle through 20 chapters or 2000 pages of hw register descriptions with a prototype pcb coming. STM knows this. We all should understand this too.
The cube will put down some code to initiate the cpu and get run of the mill code up fast. Run of the mill being some io, ethernet, irq's and setup some calls to your preferred os slicer etc. The idea of leavng the code as a base is horrible with so many bugs.
If you want a quality product, the cube generated code will have to be frozen, debugged, patched, whatever and never updated again. It will converge to a stable base after a while.
-
You are talking about Cube MX - the "code generator". I would never recommend using that other than to generate a code fragment for a particular peripheral and then see what it did and rewrite it in your own style etc (stripping off all irrelevant crap).
MX will do working code for stuff like SPI and such. The chances of getting MX to produce properly working code for complex stuff like ETH (with LWIP) or USB (VCP, MSC, etc) is basically zero. You need to google for fixes and apply them. One problem is that probably only 1% of the devs who fixed something go public with it; the rest are doing it commercially and don't want to help a potential competitor.
Cube IDE is the editor / compiler / "automatic makefile generator" package, which does work but has a few annoying features - see further back up this thread.
-
Just use LL, no magic behind the curtains, optimized and universal don't dance together.
No more ranting, full HW control, still mu h easier than sleeping with the RM.
-
Today I had a real hard time trying to uninstall the latest STMCubeProgrammer. I installed it in a non-default place, IDK if that did it, but I had to go try and uninstall it by deleting it and the registries.