Given the current state of the Mynewt hal, I think the question we need to answer is whether or not the mbed hal provides the functionality we think developers will need. Looks like what mbed is doing and mynewt is doing are very similar. Why not just co-opt the mbed HAL entirely? I cant think of a good reason not to, but I have not looked at the mbed hal in enough detail, especially in regard to bsp.
Anyway, i dont think it will be hard to map mynewt to mbed. I just dont like it if it adds another layer of indirection (i.e. efficiency). Wll > On Feb 27, 2016, at 1:55 PM, Sterling Hughes <sterl...@apache.org> wrote: > > Hi, > > I posted: > > https://issues.apache.org/jira/browse/MYNEWT-174 > > If folks have a little spare time to look at this over the weekend, I'd be > super appreciative for any thoughts people have. > > I've spelled out what I'm thinking in the comments section. But the summary > here is: it would be good to have some re-use of the mbed-hal work, and not > force chip vendors who are doing new microcontrollers to implement both > mbed's hal and ours. > > The ideal case would be that we can map our HAL to Mbed's HAL, and then find > someway that we can use our package system to include all the mbed-hal > libraries. That way, for ARM Cortex-M* platforms, we can share effort on the > HAL. > > And the benefit to keeping our HAL, and developing against it -- we can be > microcontroller architecture (i.e. non-ARM) agnostic. > > Anyhow, please do look through the mbed-hal, and an implementation: > > https://github.com/ARMmbed/mbed-hal (top-level HAL apis) > https://github.com/ARMmbed/mbed-hal-silabs (general silabs hal) > https://github.com/ARMmbed/mbed-hal-efm32gg (EFM32 silabs chipset impl) > > (there are more links in the ticket) > > Thoughts? Issues? > > Sterling
