I think the hardest part for me to “get over” (if you will) is the fact that hal_xxx_init() does not return a pointer to something and that each of the API has to call the BSP function every time. However, I do understand why you would want to do it the way you did (at least I think I understand).
I do wish that some of the API were a bit more abbreviated but that is only because i dont like typing :-) And btw, I am interested in hearing the answer to marko’s question… Will > On Mar 23, 2016, at 4:03 PM, marko kiiskila <[email protected]> wrote: > > 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?
