I did some research today on the mbed ADC HAL. Here is what I found: The HAL is driven from the user perspective by PINS. That is, when I create an ADC instance, I pass it the pin definition and some memory for the driver. Example Struct analogin_s; Typedef struct analogin_s analogint_t; analogin_t batteryMon; Void analogin_init( &batteryMon, PinName pin);
The structure analogin_t is defined by the target (the MCU in this case). Its different for each MCU/target. The PinName is an enum that is build for the target by some automatic means from some config files. The enum is really a word that contains the port value and the pin value for the IO Port MAP (at least it is on the target I looked at example PTA0, PTB12). The BSP can define names for the PINS in a json file in the target directory. For example it could set A0->PTB2, The underling driver does the following in its init routing: 1. determines which is the right ADC controller for this pin 2. Sets up clocks for this controller 3. Sets default ADC behavior (no configuration allowed) Analysis: * This has the advantage that no RAM is used until the application makes a object like 'analogin_t batteryMon;¹ * There is no way to support two different types of ADC at the same time. There could not be internal and external ADC going through the HAL for instance * It has the benefit of allows some pin checking in to ensure there is not duplicate pin use. * Its reasonable RAM and FLASH frugal as the PinName contains enough information to connect the pin to the right device (ADC in this case) Not sure where this is going, just wanted to share what I learned. Paul
