2018-02-15 07:02 AM
I can't remember the last time i could use a complete set of project files generated by CubeMX without having to patch something in the project that isn't user code.
I am kind of tired maintaining backups of the patched files, or a live 'MODs list' of things to repatch when i won't to go back to CubeMX and change a setting or add a peripheral etc.
I would like to see some method of marking individual files as do not overwrite on Cube project regeneration.
I tried just marking the files as READ ONLY. but CubeMX just ignores this and overwrites them anyways. This would be the simplest, just respect the Readonly settings!!!
If you want to do it the hard way, then after initial generation, you would left me mark as protected from overwrite, either by perpherial/middleware, or by individual file.
Alternatively, add a comment section at the beginning of every file, that can be altered by the user, to mark it as 'leave me alone'! CubeMX is smart enough to not overwrite my code between 'USER CODE BEGIN' and 'USER CODE END'. I am sure it could just leave the whole file alone if some comment were added to the top of the '/* !!! PLEASE DON'T MAKE ME PATCH THIS AGAIN !!! */'
Its one thing to have to deal with all the issues is HAL and the many workarounds and to find them and fix it once. Its whole different level of annoyance to have to so the same thing over and over!!! STM please while your improving CubeMX and HAL/LL, please don't make me hate it due to useless repetition!!!
2018-02-15 05:57 PM
what you are asking is fairly easy to do: if you don't use cube, you don't have to patch cube.
seriously, we have fairly limited ways of dealing with a given peripheral. If you can look at the most common tasks you do with a given peripheral, it is not that difficult, certainly much simpler than to constantly patching up code, to write a set of your own routines that deal with that peripheral, either on top of vendor libraries like cube / spl, or directly.
take a shot at it and you may like it. it certainly simplified my (programming) life greatly.
2018-02-15 08:43 PM
I acknowledge that not every user, is using CubeMX or HAL.
But i don't go out of my way to suggest they switch to Cube or HAL! To each his own!
But I have not intention of writing my own libraries for the peripherals!
I use what the vendor recommends/provides for tools, libraries and docs.
I build solutions not bricks. If STM can't provide, tools and bricks, my time is wasted and i will move on to a vendor that can give robust tools and libraries (bricks).
Its definitely far from perfect, but I don't find anything in CubeMX or HAL that is a deal breaker at this point.
But STM could make issues less annoying, and this is just one way i see them making thing easier while they fix the underlying issues.
Their tool already manages avoid deleting my user, i am just asking for a simple extension of the that concept, if i mark the file, don't overwrite it, user-code or not.
2018-02-15 10:08 PM
Give him time...
2018-02-15 10:21 PM
You ask for a generator that must learn not to generate...
The only valid solution is for them to make the code right and stop breaking things according with their current mood.
Sometimes It seems that the CubeMX development is some kind of secondary task, as if they are in the middle of a major change and all the man power is massed on the first task. I think here are others that said something similar...
You get what you get...
Maybe someday, someone will start his own open-source code generator...
2018-02-16 08:20 AM
Again thanks for your contribution here!
But, my request was not for alternatives to using these tools and libraries.
It was a simple feature request to make me and others more productive in an imperfect world.
I find your suggestion that I should just 'give in' and accept your view that ever STM developer must someday just abandon everything provided by STM and just dig in develop their own libraries for scratch for every processor and peripheral completely absurd!
2018-02-16 08:20 AM
Sounds like you need a Revision Control System ...
2018-02-16 09:54 AM
'
just dig in develop their own libraries for scratch for every processor and peripheral completely absurd!'
it may sound absurd but for decades that has been the standard practice, and i think will continue to be one of the practices for many of us.
to me, the opposite would be absurd: relying on buggy tools or tools that sink your productivity, OEM or otherwise.
2018-02-16 10:25 AM
Someone has to know how things actually work, and how to fix things, otherwise you'll end up with button pushing millennials watering plants with sports drinks because it's got electrolytes.
These parts aren't intractably complex, while the number of parts and the minutia keep expanding, the trick is to understand the underlying mechanics and where to look for the detail when you need it. The SPL was a thin abstraction that enabled a lot of portability, HAL is very thick and dense and tries to solve a problem of expanding scope, by hiding salient detail all over the place. If it goes wrong, or doesn't support your use case or paradigm cleanly, expect to spend many man days fixing seemingly simple issues.
2018-02-16 12:23 PM
I don't think a revision control system can address the underlying problem, that being the need to merge changes/fixes to the HAL source code that had to be done outside the USER CODE blocks.