[sdiy] MCU IDEs

[Vladimir Pantelic]

went to the ST booth at Embedded World yesterday and had a nice chat with one of 
the reps.

basically a lot of the pain points around HAL are well known inside ST. on the 
one side they are trying to fix stuff like the UART lock issue I mentioned, on 
the other side they do realize that HAL is way too limiting in some use cases.

he said they are working on a "lower level" version of HAL that comes closer to 
basic functions. this should reduce memory consumption and make more complex use 
cases available.

he also said that users should comment and give feedback on all the issues they 
see, because they need that to pass up to the software teams

in the end I got an STM32F7 discovery board in order to make me shut up and go 
away :)


On 02/20/2016 10:26 PM, Vladimir Pantelic wrote:
> 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
>