CMP EMBEDDED.COM

Login | Register     Welcome Guest ESC Boston  esc india  Call for Abstracts
 

An architecture for designing reusable embedded systems software, Part 2
Want to make your application software more reusable? Don't change the hardware, operating system, or your tools. Instead change the architectural framework within which you do your design. Part 2 in the three-part series shows building blocks for the portable code software structure.



Embedded.com

As discussed in Part 1 in this series, the linchpin in making this reusable embedded systems software architecture work is the software interface layer, which consists of three components:

1) Microcontroller specification (ECU_HSIS.H).

2) I/O signals interface specification (I/O Signal #1, #2, #n).

3) I/O interface macros (Interface.h, Interface.c).

ECU_HSIS.H:
Hardware/software-interface specification

The ECU_HSIS.H file would contain references to three external files that are used to further define the microcontroller architecture, as shown in Figure 1. The base ECU_HSIS would define the I/O parameters from the microcontroller pins out a wiring harness used to interface to the sensors and drivers. Each one of the subheader files is specific to the internal workings of the CPU and will be discussed in detail later in this series.

SIGNALS.H:
I/O signal specification

For the I/O signals interface specification, define a file called SIGNALS.H. This file contains, almost verbatim, the specification of the sensors/actuators in the system as defined by the sensor/actuator supplier. For example, a system that uses an acceleration sensor supplied by company X has given the specification (shown in Table 1) that defines the signal.

View the full-size image

In addition, defining a fixed-point scaling will make it easier to debug the variables since all of the parameters are in one location. In the accelerometer example, the scalar used is 210, which translates into a resolution of the accelerometer sensor of 1/1,024 m/s/s.


#define VOLTS_PER_G ( 1.0 )
// Sensor Specification (V/g)
#define ONE_G (9.812 * COUNTS_PER_M_PER_S2)
#define VOLTS_PER_MPS2 ( 0.101916 )
// Sensor Specification (V/m/s^2)
#define ACCEL_ZERO_PT_PROP ( 0.5 )
// proportion of Vss for 0 m/s/s 

Define the scaling for fixed-point processors. In this case, 1mps^2 = 1,024 units, which stated differently defines the software resolution of the signal to 1/1024 mps^2 = 1 Least Significant Bit (LSB).


#define MPS2_ACCEL_SCALE (1024.)
// 1 m/s/s = 1024 units
#define ACCEL_RESOLUTION (1.0 /
MPS2_ACCEL_SCALE
// m/s^2
#define ACCEL_SCALE (MPS2_ACCEL_SCALE /
COUNTS_PER_M_PER_S2)
// = 49
#define ACCEL_ZERO_VALUE
(HW_ADC_STEPS * ACCEL_ZERO_PT_PROP)

The ACCEL_SCALE parameter is calculated and used to derive the value of the fixed-point scaled sensor signal by multiplying it to the raw A to D count value. Given the defined parameters, the formula for determining the fixed point, scaled acceleration input signal is:

Accel(mps^2) = ACCEL_SCALE (mps^2/counts) * 
(A2D_PortValue (counts) - ACCEL_ZERO_VALUE (counts) )

The parameters for VOLTS_PER_MPS2 and HW_ADC_STEPS are defined in the hardware definitions header file. Optionally, it's possible to define the signal resolution in real units instead of voltage. The resolution of the sensor at the software input level is 1/1,024 volts, which can translate the volts into either mps^2 or Gs. These additional constants can be used throughout the software product for the specification of the signal resolution in real units.


#define M_PER_S2_PER_COUNT
( HW_ADC_VREFHI / VOLTS_PER_MPS2
/ HW_ADC_STEPS )
#define COUNTS_PER_M_PER_S2
( 1.0 / M_PER_S2_PER_COUNT )
#define COUNTS_PER_G
( COUNTS_PER_M_PER_S2 * 9.812 )

One of the specifications for the sensor is the start-up time. The start-up time is the time that the sensor signal is valid after the power-supply voltage is applied to the sensor. LOOP_TIME_SEC is defined in another file and in this example is set to 10 ms. The ACCEL_SENS_POWER_UP_TIME is a counter of the number of main operating-system loop counts that equates to 1 second (i.e., 100 loops = 1 sec).

#define ACCEL_SENS_POWER_UP_TIME
( 1. / LOOP_TIME_SEC )
// LATA_SENS_POWER_UP_TIME=1 sec

It is also beneficial to define the filter scaling in this file if the signal is being software filtered for noise. In this case, a first order low-pass filter is used so we define the Beta constants for the filter. The real units are used (i.e., 0 < Beta < 1.0) and converted to a fixed point by multiplying it by a predefined filter scale.

// FIRST ORDER FILTER CONSTANTS FOR Z
// ACCELERATION SIGNALS 
#define ACCEL_BETA (0.04321 * FILTER_SCALE)
// 50 Hz filter

This would be done for each of the I/O signals in the system. In summary, the SIGNALS.H file consists of information about the I/O signals and should contain, if applicable, the following information:

1. Sensor specifications.

2. Fixed-point scaling.

3. Real unit conversions.

4. Filter parameters.

The SIGNALS.H file almost takes on the form of a data dictionary for the I/O signals since all the information about the signals is defined in this header file.

1 | 2

Rate this article: Low High
Current rating
  • .
Embedded.com Career Center
Ready to take that job and shove it?
SEARCH JOBS

Browse all jobs

SPONSOR
RECENT JOB POSTINGS


 :