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 :-) Will > On Feb 28, 2016, at 9:40 PM, marko kiiskila <[email protected]> wrote: > > >> 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
