Stray Thoughts on Embedded Development

Created on: 2015-04-15 (Wed)

I have learned from the wonderful book Embedded Software Primer by David Simon that there are - generally speaking - 3 classes of embedded system architectures:
  1. 1) Infinite loop with round-robin calls
  2. 2) Infinite loop with round-robin with interrupts
  3. 3) Function-queue-scheduling
  4. 3) RTOS

When starting a project attempt to identify which of the above best fits your requirements.

Embedded development if focused on speed. One optimization I found for the von Neuman architecture that decreases latency when doing signal processing is to store calibration values that are used often in RAM. This is not only faster than dereferencing pointers to FLASH memory but it also keeps the bus clear for code retrieval.

An important interface between the electrical engineer and embedded software developer is a a table (updated regularly) containing all DAQ inputs into the uController. This table should have the following columns:
  • uController pin #
  • Controller port and line (if available)
  • type of pin (DI, DO, AI, AO, other)
  • a verbose description

The description should contain the mapping of the measured/controlled parameter if AI/AO for example:
[0V; 3.3V] -> [0ADC-4096ADC] (12bit) -> [-120mA; 120mA]
for a current sensing AI pin.

Also speaking of DAQ I find it very useful to have a header file that contains only the definition of all the uController pins.

As embedded hardware are often very close to the physical world I strongly recommend including measurement units as postfixes for all variables that can be measured (mA; A; kPa etc).

For all calibration parameters keep a table in the design spec with the following columns:
  • max, min values
  • default value
  • minimum increment value
This is valuable during validation.

Here is a list of "tricky" issues that I encountered while dealing with data acquisition development:
ADC ghosting
Many AI ports are multiplexed over the same ADC module. So when iterating over reading multiple inputs previous readings introduce a bias in the current reading.

One way in which I dealt with this was to intersperse the reading of an AI that was set to GND for every other AI reading.
ADC conversion current
When an analog signal is converted into a digital reading a small (yet significant) amount of current is pulled into the uController pin. If the electrical design has any resistances in series with the analog input pin the voltage read on the pin will be offset by the voltage drop developed due to the conversion current.

This is more of a electrical design issue but ensure that all inputs in the uController are properly buffered before reaching the uController.
Aliasing
There's a few ways to determine if aliasing occurs. One easy way is to disable and enable the ADC clock at random intervals (cannot be multiple of clock frequency) and observe if the ADC value changes. If it does most likely aliasing is occurring. As far as I can tell aliasing cannot be addressed in software. A low pass filter needs to be added as close as possible to the ADC line into the uController pin.