For things like bit twidding I am confused as to why anyone would want a library, C is **GOOD** at that stuff, I might write a macro but that is highly situation dependent and only sometimes makes the code clearer.
Sure I could write a macro pair something like
BIT_SET(t,b) (t |=(1u <<(b)))
BIT_CLEAR(t,b) (t &= ~(1u <<(b)))
But is
BIT_SET(PORTB, LCD_EN_BIT)
BIT_CLEAR (PORTB, LCD_EN_BIT)
actually any clearer then
PORTB |= LCD_EN;
PORTB &= ~LCD_EN;
I am not sure the macro version is really much of a win.
You see library code used for things like USB and TCP/IP stacks which are inherently big enough projects to make the time spent learning the library less then the time spent writing it from scratch, but for the trivial sorts of peripheral (SPI, I2C, PWM and such like trivialities) one usually writes their own or has a house collection of useful fragments.
Very often such 'libraries' are really just a C file and a header that you build into your project.
The issue is that there is just a lot of project to project variability, sometimes you want interrupt driven, sometimes a polled state machine, sometimes DMA is indicated, and if you need one style, the others are really no good to you except as reminders of register names.
There have been tries at embedded frameworks, There is that ST thing and Microchip "Harmony" springs inexorably to mind, they tend to be universally despised.
Certainly for DSP, all the vendors have their own examples of how to write things like FIR convolutions in the way that best suits their particular chip and compiler, and not only are they all different, but the memory alignment requirements going in are also all different.... DSP pretty much has to be specialised.
Regards, Dan.