I have been developing software driver for the analog to digital converter in C++. The a/d converter is primary intended for conversion of the temperature signals. The temperature signals are then used for the algorithms of temperature protections. My goal is to design the driver interface in such a manner that the driver can be used in the RTOS based application and also in the bare metal application.

Based on the above mentioned requirements I have designed the interface of the driver in this manner

enter image description here

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 method for initialization of the adc peripheral and then calls the update method from within a RTOS task or from timer interrupt service routine. The periodic call of the update method (which basically calls the startConversion method) 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_inputsarray contains first samples of all the analog inputs and the client can start to access them via the getRawValue mehod call.

My question is whether you think that the approach which I have suggested above is suitable for my requirements or whether you see any potential problems in this approach?

  • What features does your microcontroller have? Some allow an ADC to be triggered directly from a timer, which removes the need for an callback from the timer interrupt. If you're using more than one ADC input, DMA typically will allow all channels to be copied into an array automatically, giving you just one interrupt once they're all finished. I think you need to answer those questions before designing your class. Jan 10 at 16:24
  • @SteveMelnikoff thank you for your reaction. Let's say that my MCU doesn't have the DMA and I need to have the driver universal so I don't want to be fixed to triggering by the timer. Do you think that in such circumstances my approach could be a simple and robust solution?
    – L3sek
    Jan 10 at 19:33
  • 1
    The reality of embedded systems is that you cannot write a universal driver implementation. At best, you can write a universal interface for a driver which specifies how the outside world can/should use the driver. In the implementation you will need to use MCU-specific code to, for example, read out the registers of the ADC hardware. Jan 11 at 7:24
  • @BartvanIngenSchenau thank you for your reaction. What do you think about the suggested interface of my driver and its usage? Do you think that it fulfills my requirements or do you see any possible issues?
    – L3sek
    Jan 11 at 9:39
  • You seem to have covered your bases with the interface of your driver. I don't see any issues. Jan 11 at 10:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.