I don¹t think this needs to be overly complicated either and I think the discussion is great and will lead us to the simplest solution that meets our customers needs (and hopefully not too hard for us either).
I think the smaller the supporting libraries are the better for the community because each one is going to be more complete and consistent. Since we have a fantastic package manager with dependency support there should be no additional burden on the user for this. In fact they are likely to be happier for it. Will, I think that customers of this may be total newbies or they may be quite sophisticated. That¹s kind of why I wanted to consider different packages with different support for the same peripheral. Something like Polling ADC which supports arduino type readAnalog function and then other libraries that are performing more sophisticated polling, DMA and or buffering of samples. I don¹t¹ necessarily believe that these sophisticated libraries can or will be built on top of the simple ones, but will rather be totally different implementations using different underlying hardware functionality and os support features. If you take an example from linux and search for a package to support JSON or kafka for example, you may find many different packages all offer different levels of features and functionality. Some are designed to be really simple and others quite complicated and feature rich. They are all the right libraries for someone and that¹s the beauty of this open source effort. They can all be catalog¹d, incorporated and used with their dependencies without tying someone to a specific feature set. So I have no doubt there will be many flavors of hal just for ADC or maybe even SPI. Support I write a library for a touch screen display that is SPI and want to add that library to mynewt. I may not be someone who is actually building anything. I might (and would likely be) the manufacturer of the display that wants to add support for their product to the most popular embedded OS for IoT. So they go and write the library which is a set of function calls to initialize the display, load some code into it, and then offer the API to program GUI widgets and get notifications when the widgets are touched. There¹s probably not much mynewt specific stuff in there, but there will be hooks to threads, callbacks, or to timers and interrupts or something. What do I as the write of this say in the yaml file about dependencies. In my mind, I think this HW customer will want to say that this depends on: Hw/hal/spi-polling Hw/hal/interrupt Libs/os And of course, the underlying polling-spi driver might need Hw/hal/gpio (for chip select) I don¹t think we need any resolution at runtime. Compile time is all great, but if we could give more hints as to what subset of hal functionality is required that will be really important. For example, some chips may implement hal-spi and some may not (since HW may not be present). On 2/22/16, 5:35 PM, "Sterling Hughes" <[email protected]> wrote: >be. Having ways to insect packages for these capabilities so developers >can easily see what our HAL supports is a good idea. I just dont think >this needs to be made overly complicated is all. >>> >>>> >>>> i.e. a driver can require a hal-adc, or hal-gpio capability, and an >>>>MCU can export these, rather than the just "hal." >>>> >>>>> * I think the HALs should allow for the user to choose which >>>>>³peripheral² to bind to and that is done through the BSP or the HAL >>>>>API itself. For example, the user should be able to pick ADC #1 or >>>>>ADC #3. >>>>> * I do agree that sometimes it is difficult to know that you need to >>>>>call functions like bspProvideADCconfig() and the like. Not sure how >>>>>this gets solved other than documentation and looking at examples >>>>>that we provide. >>>>> >>>> >>>> IMO, the HAL should provide APIs to do this, and the BSP should call >>>>those APIs. >>> Not sure what you mean exactly. Is it the same as our current >>>structure? The project code calls hal api which in turn call bsp api? > >I think so. > >One example where this is an issue is HAL UART, which gets the config >from the BSP. I think, in general, the MCU files should not rely on the >BSP for symbol definitions: unless absolutely necessary. In this case, >I'd rather have the BSP call into the HAL rather than have the HAL call >out to the BSP. > >I don't think this is the biggest issue however... > >>> >>>> Did you see other email: what do you think about flash? Should the >>>>HAL APIs just apply to internal flash / should we get rid of HAL Flash >>>>altogether, or should HAL flash encompass both internal & external >>>>flashes...? >>>> >>>> Sterling >>> I did :-) I have not given it enough thought so I dont think I have an >>>intelligent answer. However, the idea of a HAL flash appeals to me. >>>Question: if we said the hal flash should be internal only, how do we >>>deal with external flashes? Library code calls driver code? >> >> > >Yup. We have a flash driver API that handles both internal & external >flashes. For internal flashes it uses hal_flash*, for external flashes, >it uses hal spi, and has a bunch of drivers written for it. > >Sterling
