> On Jun 2, 2016, at 5:07 PM, Sterling Hughes <[email protected]> wrote:
... > My suggestions on how to change this API, and the general design philosophy > are as follows: > > * A #define should be added HAL_ADC_MAX which indicates the number of > peripherals enabled on a given board > > * hal_adc_init() should be renamed to hal_adc_config() and should configure > the peripheral provided, which abstracted (cross-platform) values for > reference voltage, resolution and gain. > > * hal_adc_read() should be broken into a set of functions that more > appropriately map to underlying peripheral operation (e.g. > hal_adc_read_once(periph_num, callback)). > > * There should be BSP APIs that provide necessary information. For example, > reference voltage will most likely come from the board configuration, so > bsp_get_board_voltage() should be provided, as a generally implemented > function. This function could then be passed into hal_adc_config() as the > reference voltage (as an example.) > > * Power APIs will be added to the HAL (hal_adc_on(), hal_adc_suspend(), > hal_adc_off().) > > * There should be a drivers interface that runs above this, added to the base > directory of mynewt-core. Mynewt-core should come with a base set of drivers > that can use this. The drivers APIs will be what maps internal and external > ADCs, provides blocking interfaces, etc. To clear up terminology here: There should be a simple HAL API; this should be as easy to implement for hardware as possible. Simple HAL API makes it fast to bring up new MCUs. There would be a driver API; this should be as easy for application to use as possible. Simple driver API makes it fast to write new applications. Would you say that the piece of code that implements HAL ADC API to be HAL ADC driver, or something else? This would be separate from ADC driver, which implements ADC API. (There’s a lot of 3 letter acronyms here). Assuming the terms I just used above, you’d have ADC drivers which use HAL ADC API directly. But also you’d have other ADC drivers which (for example) go off-chip for external ADC. > * A default ADC driver will be developed, which uses the HAL to read > peripherals, and provides blocking functions. Over time this will be evolved > (or broken apart if too complex) to support external ADCs or directly support > more complex chip features. > * The driver will be responsible for managing power states. Sounds good. HAL APIs probably also should be augmented for power mgmt as well. So that the generic driver (using HAL directly) can do this as well. > * The mapping of SYSTEM ID -> specific ADC configuration is an exercise that > is left to the user. This can be done wherever the drivers are created / > initialized. In some cases this will be BSP, in other cases it can be done > directly by the application. This can be everything from provided a generic > sensor API that the drivers plug into, to providing a factory function that > returns the appropriate driver structure per board. I imagine this should be in BSP (not enforced, of course). As BSP knows what hardware is present. Assuming driver initialization happens in a routine within BSP, we should have 2 versions of this: one to be used by apps, and 2nd one to be used by bootloader. This so that the bootloader can bring in minimal number of drivers to get it’s job done, while app presumably would want/need all the drivers initialized. > OK, that was a long email. I’d like people’s thoughts on this — so if you’ve > made it this far, please chime in. :-) > > Sterling
