> On Feb 28, 2016, at 7:06 PM, Sterling Hughes <[email protected]> wrote: > On 2/28/16 10:02 PM, will sanfilippo wrote: >> 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). >> > > 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. > > It seems like a lot less work to map the API into ours (once), then have to > maintain mbed-hal separately from ARM for non-ARM MCUs.
mbed-hal has almost the same scope as ours. And we have not develop ours very far. I do not like unneeded layers of indirection either, but mbed folks might raise objections if we took their HAL and implemented it for other architectures. However, Will’s point is valid: drivers do not depend on this API only, there is also per-BSP definition of per-peripheral config. We would have to adapt that stuff as well. I have not scrounged driver sources; there might be other dependencies (probably limited though) to other things mbed. I.e. how to sleep, get system time etc. I do not know the right answer here, just wondering what we’d encounter. I guess one way to explore the space would be to try it out. Not sure if helpful, — M
