[sdiy] MCU IDEs

[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.
>