Just wanted to pass on some thoughts I had today about the hal ...
I was thinking about how much is in a hal, how it will grow over time and how
to tell "how complete" a given hal is. And more importantly how to provide
simple stuff that does basic HW (like polling GPIO) while allowing advanced
features of chips that support it.
Let's consider one example: ADC.
For now assume that the customer wants a simple way to poll ADC. So they go to
newt and look at possible packages with "*adc*".
The find
Libs/poll_adc
Libs/adc_periodic
Libs/adc_compare
And perhaps some custom ADC libraries that are not hardware agnostic written by
HW vendors that want to provide the best interfaces to their products (open
source is great)
Which is my trying to say that there is different functionality that they may
want from adc and generally folks don't want to learn anything more than they
have to especially with these frameworky things that are already hard to get
your head around.
The chose the simple one since they are not ready to do anything fancy and just
want to see it working. And add it to their project.yml file.
Now lets consider their Hardware platform they have. Suppose the customer has
the following different combinations of hardware
1. A board with an MCU with ADC channels built into the MCU
2. A board with an MCU with no ADC channels
3. A board with an external SPI ADC device (possibly to replace the internal
ADC that was not accurate enough).
They include libs/poll_adc into their project ... if it were me I'd want the
dependency system to say that "unresolved dependency, libs/poll_adc requires a
driver that implements hw/simple_adc_driver. The following packages implement
hw/simple_adc_driver:
* samd21/adc
* nr52/adc
* ..
* sim/adc
* stub/adc
* mcp3008/adc (This is an external SPI ADC)
The customer now knows what is available or what they need to write. This may
be an important step. For example suppose they have both #1 and #3 and have
internal and external ADC for different purposes (not accurate enough etc).
How to they select that they are binding the ADC to #3 or #1. Or do they get
to? Do we need to make sure its their choice, but we give them enough guidance
to make it easy? What if the customer wants both an internal and external ADC
through our simple API?
They just chose the one for their internal ADC and move on. Now they build and
get some unresolved external
Unersolved reference to bspProvideADCConfig()
They gather that they need to provide the info in this function and go fill it
out. This seemingly would have a different API for every device since the
different devices might have the need for different settings. For example, the
external one might be looking for a spi port while the internal ones may be
looking for pins. The sim version might be looking for a function pointer
that for a function that returns a fake A/D sample.
Either way they implement this using the prototype in the adc package they
selected and they are off and running. Done...
They might have the same experience for ADC, DAC, SPI, GPIO, PWM, I2C, CAN,
ZIGBEE, WIFI, Bluetooth, etc. I would think we would want all of these
peripheral components to work the same way. Given that, maybe the hal should
be reserved for OS critical functions only and the rest should be libraries.
Comments from folks. Do you think that this is too complicate. Do we want to
ensure that chip vendors making spi components can write drivers for mynewt
that have a dependency on an MCU SPI port without knowing which SPI port
implementation they are using. In other words, they provide hw/simple_adc and
that depends on hw/spi .
Just food for thought. Not sure whether this is doable or even worth it, just
trying to imagine when all hardware vendors just write a mynewt driver for
their sensor, MCU, etc as standard practice to sell them. Want to make sure
that is possible, easy and flexible enough to support non MCU parts.
