All, I'm having so much fun with my newt. Please comment and help me improve this work.
I've submitted two HAL API pull requests. They are to add new HAL_xxx.h files for two new sets of core functionality: ADC and PWM. When designing these hal_xxx.h interfaces, I considered the APIs from mbed-hal and from arduino-hal. I treated these as "enough" with a few caveats. 1. Generally, APIs that set specific state of devices seems hard to maintain and the system designer will have to know about them anyway. So I made Apis in the ADC hal to query the resolution and reference voltage rather than set them. They will be set by the MCU unless configurable, then they can be set by the BSP 2. There were duplicate ways in mbed to set PWM duty cycle. Rather than implement them all, I implemented a sufficient subset. Future versions could expand on this, or someone could write a helper library on top of it to covert between the various methods. https://github.com/apache/incubator-mynewt-core/pull/22 - this is a pull requests for the hal api for the Pulse Width Modulation. . https://github.com/apache/incubator-mynewt-core/pull/21 - this is the pull request for the hal API for the Analog to Digital Converters. Underlying HAL philosophy. I tried to following this philosophy when doing the interface. 1. A given device may support multiple channels (I.e. One ADC controller can sample 8 ports). Its needs a single driver since its one device multiplexed. 2. A number of different PWM/ADC devices can be supported at the same time. 3. Its possible and likely that there will be N instances of the same Device driver with just different state (e.g. Two ADC devices with 8 channels each that are identical except for memory map). So I implemented the HAL as follows: 1. for each hal_xxx.h there is a set of sysid (system_ids). These represent individual xxx (e.g. ADC) resources in the system. The adc_sysid and pwm_sydid are different number spaces. 2. The hal_xxx apis all take a sysid to reference the device and port. 3. There is an underlying hal_xxx.c implementation in the hal that resolves the sysid into a device_id and a driver interface. This is not the implementation of the hal, just a shim to call the BSP to get the driver and devid before calling back into the driver itself. 4. There is an underlying driver that implements the driver interface that can support up to N device Ids. As a concrete example, imagine a system with two ADC devices. 1. A SPI ADC with 10-bits precision and 8 pins 2. An internal MCU ADC with 8 bits precision 16 pins The BSP will be in charge of mapping a system ID into the device drivers and Ids. For example: 1. sysID 0-7 belong to SPIADC 0-7 2. sysID 8-24 belong to MCUADC 0-15 Each individual driver will manage their devices and not need to know how they map to system Ids. Paul
