« first day (4920 days earlier)      last day (13 days later) » 

2:28 PM
@Lundin Can you weight in on this? (Or is it more like a full question for Codidact?)
I came across a library for a sensor, which [curiously for me] defines its own board support package (BSP). The library is created by TDK/Invensense. It’s intended for integration into larger firmware projects (it’s not a standalone demo or a code example).
Only the BSP needs to be changed to adapt the library for a given microcontroller. So, the BSP makes the library easier to port.
This is the first time I see a library which defines its own BSP. Is this a common practice? Is this a good practice?
[Strikes me as a good design, if I can say so myself.]
 
2:46 PM
@misk94555 It's common for more complex libraries like protocol stacks to sit on top of a HAL, in turn sitting on top of the drivers. Then the vendor of the protocol stack (they are usually commercial) can support multiple devices by just swapping out the drivers. Or if you use some exotic MCU you can buy such a stack and port it yourself. So yeah in terms of drivers for diverse microcontrollers, it is decent practice.
As for "board support" that's some new hobbyist term. Real embedded systems tend to use custom boards, always. There's a bunch of PC programmers thinking it's rocket science to have a PCB with a microcontroller made. It is not. Yeah you do need access to one EE with CAD experience and prototype batches cost somewhere in the range of 500€-1k€. But nobody serious does product design by integrating some "pro blue pill black raspberry x super special" board in it :)
 
3:31 PM
@Lundin BSP isn’t a brand new term for me. What was new is that a 3rd party library defines the sub-BSP which it requires. Until now I had a more monolithic mental image of BSPs.
[I knew that BSPs are a thing. I even sorted out the difference between HAL and BSP.]
I do hardware design professionally (board- and system-level). I write a my own bring-up firmware. During the bring-up I gradually turn the board to professional firmware coders. They use my bring-up code as examples when they create the production BSP (and everything above that).
Obviously, bring-up code needs a lot less structure than the product firmware.
Back in the days [say 15 years ago], I used to be on a professional enough level with firmware. But the bar for pro firmware went up, and I didn’t keep up with it. I was plowing my efforts into hardware engineering instead.
 

« first day (4920 days earlier)      last day (13 days later) »