You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mynewt.apache.org by "paul@wrada.com" <pa...@wrada.com> on 2016/02/19 01:32:19 UTC
hal organization and multiple smaller packages
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.
Re: hal organization and multiple smaller packages
Posted by Sterling Hughes <st...@apache.org>.
On 2/22/16 1:24 PM, will sanfilippo wrote:
> My 1/2 cent on this topic (and I certainly dont think you killed the discussion; it is a difficult topic):
>
> * I think the HAL is meant to be a fairly general, simple, abstraction. Hopefully over time we will be able to incorporate more advanced HAL features, but most HALs I have seen implement the basics and I bet that works for most folks.
> * I think the HAL should live in hw/mcu. Well, api in hw/hal and implementation in hw/mcu.
> * As sterling says, drivers can be built that use the HAL. Take the external ADC example. There would be a driver for that ADC chip that would use a SPI HAL if it had SPI. For internal ADCs, the HAL provided in hw/hal should be enough as I suspect it will (eventually), implement what most folks want.
> * As far as being able to see what features of a HAL are implemented, I dont see why this is such a problem but it is probably because I am not thinking of “beginner” users. Doesnt seem terribly difficult to document, on a per mcu basis, which features of the HAL are supported by that particular MCU. And if the developer calls an API with some parameters that are not implemented on this MCU they get an error. Part of the problem I have with this is is my own personal bias: I would never blindly call HAL functions without first reading the chip documentation. I dont see why anyone would do such a thing :-)
> * I am not a fan of runtime HAL introspection APIs. To me, that is just extra code that serves very little useful purpose.
I agree with no runtime, but think there should be capabilities on a
more granular basis.
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.
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
Re: hal organization and multiple smaller packages
Posted by will sanfilippo <wi...@runtime.io>.
My 1/2 cent on this topic (and I certainly dont think you killed the discussion; it is a difficult topic):
* I think the HAL is meant to be a fairly general, simple, abstraction. Hopefully over time we will be able to incorporate more advanced HAL features, but most HALs I have seen implement the basics and I bet that works for most folks.
* I think the HAL should live in hw/mcu. Well, api in hw/hal and implementation in hw/mcu.
* As sterling says, drivers can be built that use the HAL. Take the external ADC example. There would be a driver for that ADC chip that would use a SPI HAL if it had SPI. For internal ADCs, the HAL provided in hw/hal should be enough as I suspect it will (eventually), implement what most folks want.
* As far as being able to see what features of a HAL are implemented, I dont see why this is such a problem but it is probably because I am not thinking of “beginner” users. Doesnt seem terribly difficult to document, on a per mcu basis, which features of the HAL are supported by that particular MCU. And if the developer calls an API with some parameters that are not implemented on this MCU they get an error. Part of the problem I have with this is is my own personal bias: I would never blindly call HAL functions without first reading the chip documentation. I dont see why anyone would do such a thing :-)
* I am not a fan of runtime HAL introspection APIs. To me, that is just extra code that serves very little useful purpose.
* 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.
BTW, I know I have echoed most of Sterlings comments. :-)
Will
> On Feb 21, 2016, at 8:39 PM, Sterling Hughes <st...@apache.org> wrote:
>
> BTW, I hope I didn't kill discussion on this one. :-)
>
> I think this is an important topic to get right, and I'd like other people's thoughts here as well.
>
> Sterling
>
> On 2/18/16 9:23 PM, Sterling Hughes wrote:
>> Paul -
>>
>> I think you make a number of good points here, but I'm not sure all of
>> them argue for re-organizing the HAL, but perhaps just improving the
>> existing structure.
>>
>> The purpose of the HAL is to abstract MCU peripheral functions, and make
>> that portable across various MCU architectures. This is why the HAL
>> APIs are defined in the hw/hal package, but the implementation for the
>> HAL lives in the various mcu support packages in hw/mcu (*).
>>
>> I think it makes sense to group the definition of MCU support functions
>> together. That way, as people use it, and contribute support back --
>> support for a given processor grows in a cohesive fashion. Now, of course:
>>
>> - Not all MCUs will implement all HAL interfaces (e.g. DMA v non-DMA chips)
>> - Not all HAL implementations are going to be complete: if I don't use
>> the ADC on a chip, am I going to spend my time developing a MCU support
>> package for it?
>>
>> I think, however, that this can be exposed both:
>>
>> - At runtime, with HAL introspection APIs
>> - At package/compile time, using capabilities (MCU packages export more
>> fine grained hal capabilities, e.g. hal-adc, hal-adc-outc)
>>
>> That way people who are searching for MCU support packages, can inspect
>> what aspects of the HAL are/aren't implemented (view capabilities.)
>>
>> I think then, on top of the HAL there can be more complex drivers for
>> everything you want to do with it. As an example, hal-gpio would just
>> have on/off, and read state (abstracting peripherals): but you might
>> distribute a gpio-led package on top of that, which had common functions
>> for controlling LEDs through GPIO (PWM for color, etc.) This driver
>> would require that their be a hal-gpio capability present, but it
>> wouldn't need to specify the specific support package necessary.
>>
>> Fundamentally, I think the question comes down to me: where do you want
>> the implementation of MCU specific functionality to live. Ideally MCU
>> support is in a single package/set of packages in hw/mcu that is being
>> constantly improved for all peripheral interfaces. The HAL then becomes
>> a glue to let all the higher layer drivers operate, without knowing
>> about the specifics of the underlying MCU implementation.
>>
>> Thoughts?
>>
>> Sterling
>>
>> (*) hw/hal does take some definitions from the BSP. I'm more inclined
>> to move these out of the HAL, and have the HAL just be MCU support. But
>> that is a discussion for another day.
>>
>>
>> On 2/18/16 4:32 PM, paul@wrada.com wrote:
>>>
>>> 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.
>>>
>>>
>>>
>>>
>>>
Re: hal organization and multiple smaller packages
Posted by Sterling Hughes <st...@apache.org>.
On 2/21/16 8:39 PM, Sterling Hughes wrote:
> BTW, I hope I didn't kill discussion on this one. :-)
>
> I think this is an important topic to get right, and I'd like other
> people's thoughts here as well.
And I should further add, one issue I'd also like to discuss -- Should
the HAL abstract away flash implementation?
To me, the HAL is designed to abstract MCU peripheral specific
functionality, not BSP level functionality. I wonder if flash shouldn't
be it's own thing, and not in the HAL, given that its BSP dependent.
Sterling
Re: hal organization and multiple smaller packages
Posted by Sterling Hughes <st...@apache.org>.
BTW, I hope I didn't kill discussion on this one. :-)
I think this is an important topic to get right, and I'd like other
people's thoughts here as well.
Sterling
On 2/18/16 9:23 PM, Sterling Hughes wrote:
> Paul -
>
> I think you make a number of good points here, but I'm not sure all of
> them argue for re-organizing the HAL, but perhaps just improving the
> existing structure.
>
> The purpose of the HAL is to abstract MCU peripheral functions, and make
> that portable across various MCU architectures. This is why the HAL
> APIs are defined in the hw/hal package, but the implementation for the
> HAL lives in the various mcu support packages in hw/mcu (*).
>
> I think it makes sense to group the definition of MCU support functions
> together. That way, as people use it, and contribute support back --
> support for a given processor grows in a cohesive fashion. Now, of course:
>
> - Not all MCUs will implement all HAL interfaces (e.g. DMA v non-DMA chips)
> - Not all HAL implementations are going to be complete: if I don't use
> the ADC on a chip, am I going to spend my time developing a MCU support
> package for it?
>
> I think, however, that this can be exposed both:
>
> - At runtime, with HAL introspection APIs
> - At package/compile time, using capabilities (MCU packages export more
> fine grained hal capabilities, e.g. hal-adc, hal-adc-outc)
>
> That way people who are searching for MCU support packages, can inspect
> what aspects of the HAL are/aren't implemented (view capabilities.)
>
> I think then, on top of the HAL there can be more complex drivers for
> everything you want to do with it. As an example, hal-gpio would just
> have on/off, and read state (abstracting peripherals): but you might
> distribute a gpio-led package on top of that, which had common functions
> for controlling LEDs through GPIO (PWM for color, etc.) This driver
> would require that their be a hal-gpio capability present, but it
> wouldn't need to specify the specific support package necessary.
>
> Fundamentally, I think the question comes down to me: where do you want
> the implementation of MCU specific functionality to live. Ideally MCU
> support is in a single package/set of packages in hw/mcu that is being
> constantly improved for all peripheral interfaces. The HAL then becomes
> a glue to let all the higher layer drivers operate, without knowing
> about the specifics of the underlying MCU implementation.
>
> Thoughts?
>
> Sterling
>
> (*) hw/hal does take some definitions from the BSP. I'm more inclined
> to move these out of the HAL, and have the HAL just be MCU support. But
> that is a discussion for another day.
>
>
> On 2/18/16 4:32 PM, paul@wrada.com wrote:
>>
>> 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.
>>
>>
>>
>>
>>
Re: hal organization and multiple smaller packages
Posted by Sterling Hughes <st...@apache.org>.
Paul -
I think you make a number of good points here, but I'm not sure all of
them argue for re-organizing the HAL, but perhaps just improving the
existing structure.
The purpose of the HAL is to abstract MCU peripheral functions, and make
that portable across various MCU architectures. This is why the HAL
APIs are defined in the hw/hal package, but the implementation for the
HAL lives in the various mcu support packages in hw/mcu (*).
I think it makes sense to group the definition of MCU support functions
together. That way, as people use it, and contribute support back --
support for a given processor grows in a cohesive fashion. Now, of course:
- Not all MCUs will implement all HAL interfaces (e.g. DMA v non-DMA chips)
- Not all HAL implementations are going to be complete: if I don't use
the ADC on a chip, am I going to spend my time developing a MCU support
package for it?
I think, however, that this can be exposed both:
- At runtime, with HAL introspection APIs
- At package/compile time, using capabilities (MCU packages export more
fine grained hal capabilities, e.g. hal-adc, hal-adc-outc)
That way people who are searching for MCU support packages, can inspect
what aspects of the HAL are/aren't implemented (view capabilities.)
I think then, on top of the HAL there can be more complex drivers for
everything you want to do with it. As an example, hal-gpio would just
have on/off, and read state (abstracting peripherals): but you might
distribute a gpio-led package on top of that, which had common functions
for controlling LEDs through GPIO (PWM for color, etc.) This driver
would require that their be a hal-gpio capability present, but it
wouldn't need to specify the specific support package necessary.
Fundamentally, I think the question comes down to me: where do you want
the implementation of MCU specific functionality to live. Ideally MCU
support is in a single package/set of packages in hw/mcu that is being
constantly improved for all peripheral interfaces. The HAL then becomes
a glue to let all the higher layer drivers operate, without knowing
about the specifics of the underlying MCU implementation.
Thoughts?
Sterling
(*) hw/hal does take some definitions from the BSP. I'm more inclined
to move these out of the HAL, and have the HAL just be MCU support. But
that is a discussion for another day.
On 2/18/16 4:32 PM, paul@wrada.com wrote:
>
> 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.
>
>
>
>
>