Good stuff. > On Mar 22, 2016, at 5:21 PM, [email protected] wrote: > > 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).
That’s good. > 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. How do you map from devid to particulars of HW configuration? For example, how would tell that for my Olimex board, I want to use pin X as input for my ADC? Or that my PWM for sysid 0 should go out to pin Y?
