Sorry all; thought this was addressed to dev
> Begin forwarded message:
>
> From: will sanfilippo <wi...@runtime.io>
> Subject: Re: hal organization and multiple smaller packages
> Date: February 22, 2016 at 3:42:15 PM PST
> To: sterl...@apache.org
>
> See comments
>
>> On Feb 22, 2016, at 2:58 PM, Sterling Hughes <sterl...@apache.org> wrote:
>>
>>
>>
>> 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.
>
> Sorry, I did not mean to imply that there should not be more granular
> capabilites. I think there should 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?
>
>> 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?
