[sdiy] MCU IDEs

[Vladimir Pantelic]

1) take the UART support in the HAL. the UART is a piece of hardware that is 
perfectly capable of doing independent reads and writes, yet the HAL has one 
lock for both TX and RX. it took me a while to realize why I cannot TX from an 
IRQ while waiting for RX in the main loop.

2) all kinds of nifty things around TIMers, including DMA - but the only DMA 
support in the TIMer HAL is to use it to write to the register of the TIM 
module. using a timer to trigger an SPI DMA is not supported at all.

3) its way too verbose. while I ignore that on F3 or F4, when using it on an F0 
with 16k flash only, I constantly replace HAL functions with cut-down versions 
because they are way too big. using function-sections will already not link the 
unused HAL functions, but the used ones are still huge.

and yes, the examples are horrible as they spread out code that could be a few 
lines over 3 or 4 files...


On 02/20/2016 10:10 PM, sleepy_dog at gmx.de wrote:
> 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
>>
>
> _______________________________________________
> Synth-diy mailing list
> Synth-diy at dropmix.xs4all.nl
> http://dropmix.xs4all.nl/mailman/listinfo/synth-diy