Hello,

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?

Hello M65C02A, thank you very much for your response. My intention is to use this driver for the a/d converter which samples 12 analog signals of temperatures of the transistors in power electronics converter. These signals are then used for the algorithms of temperature protections of the power electronics converter. The temperature protection algorithms have to be evaluated in periodic manner on the RTOS task. My intention was that the execution period of this task will be set to such a value corresponding to the time needed for the conversion sequence of all the temperatures.

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.