Ulster.ac.uk Embedded Systems Designing the high level structure of your embedded system Ian McCrum School of Engineering.

ulster.ac.uk

Embedded SystemsDesigning the high level structure of your embedded system

Ian McCrumSchool of

Engineering

• Assume you have to design an embedded system; your machine will read temperature, have a keypad, have a seven segment display or LCD as well as a number of switches, pushbuttons, LEDs, relays, solenoids and motors. It also has a serial communication capability

• Actually that system is typical – it doesn’t matter if it is a washing machine, a central heating controller or a complete automated house – nearly all systems have inputs from sensors, interfaces to and from humans, outputs to actuators and connections to other devices… (in general!)

• The rise of the “Internet of Things” IoT means we will see a lot more Wifi, Bluetooth, Zigbee or point to point linking of machines, Ethernet and even humble RS232 all matter. (RS232 can link GSM units to an embedded system) – so can SPI or I2C.

• But assume you have a number of C functions that provide robust input and output (“drivers”), and that functions exist to process and calculate the data.

• How do you connect together all this functionality?

Method one:

While(1){do_task1();do_task2();do_task3();do_task4();

}

Method Two:

While(1){do_a bit_of_task1();do_a bit_of_task2();do_a bit_of_task3();do_a bit_of_task4();

}

main(){…while(1){

do_task4();do_other();do_more();

}

Method Three:

ISR_task1()

ISR_task2()

ISR_task3()

Events & Timers elapsing

Interrupt happens

Interrupt happens

Interrupt happens

main(){…while(1){

do_task4();do_other();do_more();

}

Method Three:

ISR_task1()

ISR_task2()

ISR_task3()

Events & Timers elapsing

Interrupt happens Interrupt happens

Interrupt happens

Interrupts can be a powerful tool

• Dangerous! – hard to prove will work under all scenarios

• Hard to test, any mistake hangs the machine but this might only happen once every three months

• Last minute changes, upgrades to hardware all massively impact reliability of the system

Method Two:

While(1){do_a bit_of_task1();do_a bit_of_task2();do_a bit_of_task3();do_a bit_of_task4();

}

How can we implement this?

Implementing embedded systems using state machine methods

In the infinite while loop we can have a switch statement that tests a variable to see where we are in the system. Switch/case statements test an int and have a multi-way branch structure – remember the role of break; though

This state variable can be assigned meaningful names, rather than 1,2,3…

This can be done using #define statements, or enum.

Advanced state machines can use a table or array to hold the sequences of tasks, often a 2D array or an array of structs is used.

Sometimes function pointers are used

In our code we will avoid complex C and just #defines

State machines require a State Variable (SV).

The SV is essentially a pointer that keeps track of the state that the microcontroller is in, and directs the program flow to the corresponding software module.

The SV can be modified in the software modules (or states) themselves or by an outside function.

while(1){ // execute finite state machine switch(st){ INITIAL: start_timer();

st = WAIT_1_MSEC;break;

WAIT_1_MSEC: if( time >= 1000 ){ st = GETTING_ADC}break;

GETTING_ADC: If( adc_done() ){ update_average(); count++; if( count == 10 ) { st = DO_KEY_SCAN; // ev 10 ADC readings count = 0; }else{ st = CHECK_ALARM; }//-- end inner if --//}//-- end outer if --//break;

DO_KEY_SCAN:

scankeys();

if( keyhit()

alarm_limit = getkey();

st = CHECK_ALARM;

break;

}

CHECK_ALARM:

If( alarm_limit <= average_temp )

buzz = 1;

else

buzz = 0;

// better code would add hysteresis}//-- end switch –}//-- end while NEVER REACHED AS LOOPS FOREVER

#define INITIAL 1#define WAIT_1_MSEC 2Etc.,Or use enum states { INITIAL , WAIT_1_MSEC,…} st;

DO_KEY_SCAN: scankeys(); if( keyhit() & keynumber == 0) { // first time key hit dig1 = getkey(); keynumber=1; // remember state of entered keys st = CHECK_ALARM; // don’t block waiting for next key break; } if( keyhit() & keynumber == 1) { // 2nd key hit alarm_limit = dig1 * 10 + getkey() ; // xx keynumber=0; // reset state of entered keys st = CHECK_ALARM; // don’t block waiting for next key break; }

If we need to wait for 2 keystrokes we could use the code below

What if we split our system into separate functions – called tasks or

processes and had robust interprocess communications (IPC)

This is what Operating systems do(they also can handle all i/o, manage memory, disks, cpu temperature and

all respources of the computer)

How to design such systems?• In the (very) old days we used “system analysts” who

worked out what to do – they wrote the specifications for the programmers

• We evolved CASE tools (computer aided software tools) to try and help organise these systems

• We evolved various types of diagrams to pictorially represent systems.

• Current practice is to use UML - a set of diagrammatic methods; excellent way to model a system. But a complete course in their own right.

• We shall restrict ourselves to simple state diagrams, Algorithmic state diagrams and simple process diagrams using a subset of Mascot.

Mascot ( a subset)

Activity - a task

A channel - a queue, first in first out

A pool – a global variable (could hide it a bit…)

A device – Input/output

A signal - a Semaphore (used as a flag)

A system reads a temperature, averages it and checks it against an alarm limit. It also receives RS232 messages that it either passes on or intercepts

and sends temperature data back, and to the PC.

We can use this technique to specify exactly what to do if using FreeRTOS.

Temp

Temp data

RS232 in

RS232 out

RS232 to PC

keypad in

ALARM

Alarm limit