Re: our HAL and the new mbed-hal

[Sterling Hughes <st...@apache.org>]

Howdy,

On 2/29/16 7:43 AM, will sanfilippo wrote:
> Sterling (and all):
>
>>> I think we will need to: mbed-hal is being developed only for ARM processors.  If we want to use the HAL on other MCUs (MIPS, 8051, Intel, etc.) -- it would be good to have this mapped.
>
>
> I am probably getting confused by how you worded that statement but the hal they present is generic and would work for any MCU. Yes, only MCU vendors with cortex -M processors are mapping their HALs to mbed, but if we decided to adopt the mbed HAL it would be easy to map other MCU’s to the mbed hal. Pretty much exactly the same amount of work it would take to map mynewt to their HALs.
>
> I certainly understand why we might want to map the mynewt hal to mbed: do it once and then you get all the mbed hal ports for free but like I said; we should take a serious look at whether or not we just want to use the mbed hal in that case. Yes, I am repeating myself :-)
>

I chatted a bit with Will offline on this. Wanted to summarize our 
thoughts here.

First, both this mail and Paul's mail make it clear to me just how much 
work we need to do on our HAL / driver infrastructure.  We have a lot of 
this planned for v0.9-b1 (in mid-May), I think this needs to be clearly 
release noted in our next v0.8 release, just so folks know it's coming.

Anyhow:

- I (we?) think we can't rely on the APIs defined by mbed-hal, for a 
number of reasons

1: The APIs are listed as "do not rely": https://github.com/ARMmbed/mbed-hal

"mbed hal API is considered an internal interface. It is not recommended 
to depend on this module in an application. We are planning to improve 
mbed-hal in the future, which might require changes in API."

In order to provide API compatibility, ARM has a bunch of C++ APIs that 
are supposed to map into this HAL.

2: I'd be nervous about relying on a HAL for a project that clearly 
proclaims its just for ARM processors.  I don't have specific examples 
in the current HAL (it's reasonably generic), but that doesn't lessen my 
uneasiness much.  Especially given the level of competition between ARM 
& Intel, and Intel is launching its first Microcontroller soon.


3: ARM has their own mapping of these APIs that they expect their users 
to use.  But they are all C++, and don't look to be terribly efficient 
or fun.  Plus, you know, aherm, C++ on embedded microcontrollers-- 
because references are going to work great on systems where you can't 
restart processes.

- Therefore, we need to have our own mappings of these APIs.

- HOWEVER, given ARM's power within their ecosystem, and prevalence with 
32-bit MCUs, we'd obviously want to leverage any work done here.  So, 
when we work on the HAL in v0.9-b1, we should look at designing our HAL 
APIs such that it's efficient and easy to map into the ARM mbed HAL 
APIs.  That way, any abstraction we do, will hopefully not be that 
inefficient.

An example of this is GPIOs, we designed our GPIO API 
(https://github.com/apache/incubator-mynewt-larva/blob/master/hw/hal/include/hal/hal_gpio.h) 
not to require a structure for efficiencies sake, whereas MBed's APIs 
require a gpio_t * structure to be defined by implementations, and 
passed to the GPIO functions 
(https://github.com/ARMmbed/mbed-hal/blob/master/mbed-hal/gpio_api.h). 
While we like our approach a little more, we should make that decision 
within the context of efficiently mapping into mbed's APIs as well, so 
our abstraction layer becomes a bit cleaner.

Thoughts?

Sterling