I have been developing C++ driver for the a/d converter and I have been thinking about its interface. In other words I have been thinking about how the client software will interact with the driver. My proposal of the driver interface is following:
So my intention is to use a sort of buffering of the samples of the analog signals in the internal array analog_inputs. The idea is that the client software calls the initialize and the startConversion methods. These calls results in periodic invoking of the endOfConversionCallback behind the scene. Here the analog_inputs array is filled by the samples. In case the isReady method returns true the analog_inputs array contains first samples of all the analog inputs and the client can start to access them via the getRawValue mehod call. Do you think that the suggested approach is appropriate?
#c++, #device driver, #oop
Your defined interface appears to cover most of the bases. However, to answer your question regarding whether your driver definition is appropriate or not, you need to define the Use Case for the data your driver is capturing. In other words, what is your intended use for the data, are any of your processing algorithms for the data dependent on a periodic process, and what tolerance do your data processing algorithms have for non-deterministic, varying sampling times?
As part of your software design, you may wish model the dynamic behaviour with a sequence diagram.
Since most MCU ADC's generate an End of Conversion interrupt, your ISR can use the callback method, read the RawValue and post an RTOS notify event for processing by a pending task thread.