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
