[sdiy] MCU IDEs

[rsdio at audiobanshee.com]

In the TMS320 HAL, only the foo_init() functions take an array of 16 or 32 but members. The understanding is that init() should only be called once, before timing critical code. All of the TMS320 HAL API for making changes to a peripheral state do not take such structures. There might be both mask and value for a GPIO change, but these are often combined into a single opcode by the compiler assembler.

Why would you call init() multiple times during firmware operations? Is there no simple API for changing a pin? I guess I shouldn't carry on too long without looking at the ST HAL in detail.

I do remember thinking that the init() functions were rather inefficient, but I realized that optimization at init time doesn't really buy much at all. All of the critical path TMS320 HAL code was very optimal, but perhaps that's because I could handle everything without calling init() more than once.

Brian


On Feb 20, 2016, at 1: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.