current measurementdataloggerembeddedvoltage measurement
I have an embedded application that wakes up every 15 minutes and performs some specific function for a period of two minutes.
I need to log the current consumption of this specific function on the embedded board say for a period of two weeks and see if there was any unwanted current consumptions caused due to some unknown software cases.
I am thinking of buying a cheap NI DAQ. I would like to have some suggestion on how to go about this task.
I have used lint in the past, and I have found it useful. However, I had to stop using it as I moved onto a larger project that wasn't using it. That made it difficult to use lint, because of how interconnected the code was. The biggest problem with lint is configuring it to remove false positives and don't cares. It may be better now that they've done another release in the past year.
One company I work with has taken that large project and put it through Coverity's static analzyer. However, that's a big chunk of money to be using, so it's not recommended for small companies.
This should be pretty easy. You can detect the difference between 1.5A and 15A using a simple resistor. A value of 0.3 ohms will give 0.45v at 1.5A and 4.5v at 15A.
A digital input pin on the microcontroller will read 0 at 1.5A, and 1 at 15A.
You could wire this straight to the microcontroller's input pin, but it would probably be best to add a little filtering and protection.
RF and C1 provide a low-pass filter to make the voltage more stable.
D1 provides over-voltage protection in case the current greatly exceeds 15A.
Best Answer
My initial presumption is that software cases that will lead to increased current consumption are those that result in subsystems being powered for longer than expected.
At a first-pass (and without needing any extra hardware) I would suggest that in firmware you log the amount of time that the processor is "awake". This will check that you are in fact only in full-speed mode for 2 minutes. The longer you spend in full-speed mode, the higher the average current draw.
Also look for peripherals whose power is controlled by your embedded system and log their on/off periods. Again, any logged event that is longer than an expected deviation may be indicative of a problem.