[sdiy] MCU IDEs

[sleepy_dog at gmx.de]

Well, the reason for its design is probably not utmost run-time 
efficiency, IIRC ST said so themselves, I forgot where.
There is more to it that I'll be able now to pop off my mind, but just a 
few small things:
- as hinted at earlier, callbacks for hardware events go through several 
layers of indirection before reching application code
- configuration of peripheral items, like just one GPIO pin, works by 
filling a struct with several 16 or 32 bit members and passig it to an 
init function.
Good luck with speed if you want to frequently recondigure a pin. Maybe 
not a typical application, but I've seen uses for it.

There are more things of that sort, even though I don't recall them all now.
I don't like the overall structure of things. Look at the HAL examples. 
There's one file with ISRs for all peripherals, calling some standard 
stuff of the HAL (you have to add that, though, for stuff you need, or 
if using CubeMX, it probably adds that... ), one file with all init 
stuff for all peripherals, one file for... you get the idea.
Perhaps you don't have to do it that way, but its the canonical way 
apparently and the tools generate code like that. Not modular by 
function, but by "what kind of thing are we doing here, for any of the 
hardware" - with global variables, lots of extern references without 
declaring uses / includingm things assumed to be there or here ... to 
patch it all together - *ugh*. And then it's expected that some init and 
deinit routines for a piece of peripheral you ant to use are present --  
they get called by the HAL skeleton from a general init routine for the 
hardware block as soon as one wants to init that. If it's not there, the 
HAL calls some weakly linked empty stub function withuot you noticing... 
you have to just know that.

Perhaps this has to do with personal taste, to me it looks like a mess.
I think from now on I shall call the Cube thing the PastaFactory.

I do know, though, that some people I knew who are hugely more 
proficient in embedded development than I am are also not very fond of 
those libraries :-)-
To me they look more like a quick help in evaluating ST's hardware, not 
for production code, and to some extent marketing: "see, we got 
libraries, too, you'll be up and runing in no time!"

Am 20.02.2016 um 21:17 schrieb rsdio at audiobanshee.com:
> When you say the ST HAL API design is atrocious, in what respect are you evaluating it?
>
> As an example of why it's important to clarify, I worked intensely with the TMS320 DSP and Texas Instrument's HAL and noticed that the C code looked a bit awkward, with headers that were full of complex macros. However, when I got to the point of optimizing the code for low power and high speed processing, I realized that this awkward-looking C code was actually taking full advantage of the DSP machine code. In most cases, peripheral manipulation through the HAL compiled down to a single DSP opcode, all while remaining "portable" to another DSP because the source was in C. Although I wrote some assembly for DSP code, I didn't have to rewrite any of the HAL in assembly because it was already optimal.
>
> My point is that sometimes an overly complex or inelegant-looking C API turns out to be highly efficient at the machine code level. This assumes that the compiler is designed to take full advantage of the machine code. I haven't used the ST HAL yet, but I'm curious whether it generates efficient ARM code at the expense of making the C look more atrocious, or is it simply just bad all around.
>
> Brian
>
>
> On Feb 20, 2016, at 5:32 AM, sleepy_dog at gmx.de wrote:
>> "Be sure to learn the new HAL library as well"
>>
>> Really? I found that to be a horrible waste of time. I had hoped that ST meanwhile improved their library stuff, but I don't see how it's better than what they used to have when the F103 was the cutting edge, even if different. Their API design is, IMO, atrocious, and my place is not the only one I've heard of thinking one is, alas, still better off just using the reference manual and initializing things on a register basis (using CMSIS, which basically comes from ARM, plus headers for implementor specific peripherals)... And I'm saying that as a software guy doing some hardware (usually you'd hear EEs having such an opinion ;) )
>> It is a running gag to refer to the ST library stuff as the "ST summer intern project", and it does look like it...
>> The CubeMX tool we found useful to at least catch some errors in clock configuration etc, but we did not use its code output in production... as it's geared towards the aforementioned atrocious API.
>>
> _______________________________________________
> Synth-diy mailing list
> Synth-diy at dropmix.xs4all.nl
> http://dropmix.xs4all.nl/mailman/listinfo/synth-diy
>