Hello all, I wanted to share my thoughts on two topics I've run into recently with mynewt:
I've recently finished modifying to LoRa stack to allow it to work at reduced power by having it turn the high accuracy timer on or off as needed. I'm also currently integrating the Microchip CryptoAuthLib into my application (unfortunately, there appears to be a license conflict issue preventing it being integrating into mynewt itself), which also involves turning the I2C peripheral on and off to save power. Both of these situations have raised the issue that in the mynewt hal libraries, turning peripherals on is always a hardware-specific operation that requires a hardware-specific cfg struct to be passed in to the init function. What this means is that it's not possible for a library package to turn a peripheral back on, because it can't know what to pass as a cfg. For my modifications to the LoRa stack, I ended up having to create two callbacks that the user needs to populate that do the actual turning on/off of the timer. This kind of defeats the purpose of the library being self contained and configured via syscfg. Ideally, there perhaps needs to be a standard hal_bsp call that can be used to turn peripherals on. That way, just like how libraries can use peripherals in a hardware-agnostic way, they can also turn them on and off without worrying about the hardware specifics. On a similar note, I think there's a need to wrap some of the hal peripherals (specifically SPI and I2C) into some sort of higher level driver interface using mutexes rather than have libraries call the hal_spi/i2c functions directly. At the moment, it's not possible to, say, run an I2C flash memory and several I2C sensors as independent libraries/modules, as each module directly calls the hal_i2c functions and there's no way of knowing whether the I2C bus is being used or not. Perhaps bringing this under the existing driver model may work? The BSP would register a driver for the peripheral, libraries wanting to access the peripheral would "open" the driver, do all their required comms and then "close" it, freeing it up for other peripherals. This would also make it easy to hook in power management as now the peripheral is centrally managed and so you know when it's not being used and can safely turn it off. This also solves the first problem of re-initialising peripherals - this would be taken care of in the "open" function of the driver implementation. Amr
