be. Having ways to insect packages for these capabilities so developers
can easily see what our HAL supports is a good idea. I just dont think
this needs to be made overly complicated is all.
i.e. a driver can require a hal-adc, or hal-gpio capability, and an MCU can export these,
rather than the just "hal."
* I think the HALs should allow for the user to choose which “peripheral” to
bind to and that is done through the BSP or the HAL API itself. For example,
the user should be able to pick ADC #1 or ADC #3.
* I do agree that sometimes it is difficult to know that you need to call
functions like bspProvideADCconfig() and the like. Not sure how this gets
solved other than documentation and looking at examples that we provide.
IMO, the HAL should provide APIs to do this, and the BSP should call those APIs.
Not sure what you mean exactly. Is it the same as our current structure? The
project code calls hal api which in turn call bsp api?
I think so.
One example where this is an issue is HAL UART, which gets the config
from the BSP. I think, in general, the MCU files should not rely on the
BSP for symbol definitions: unless absolutely necessary. In this case,
I'd rather have the BSP call into the HAL rather than have the HAL call
out to the BSP.
I don't think this is the biggest issue however...
Did you see other email: what do you think about flash? Should the HAL APIs just
apply to internal flash / should we get rid of HAL Flash altogether, or should HAL
flash encompass both internal & external flashes...?
Sterling
I did :-) I have not given it enough thought so I dont think I have an
intelligent answer. However, the idea of a HAL flash appeals to me. Question:
if we said the hal flash should be internal only, how do we deal with external
flashes? Library code calls driver code?
Yup. We have a flash driver API that handles both internal & external
flashes. For internal flashes it uses hal_flash*, for external flashes,
it uses hal spi, and has a bunch of drivers written for it.
Sterling
