Firmware Programming

Embedded Systems
Why called Embedded? Since SW is embedded into it for specific use. The user has specific task and works on pre-loaded software. Embedded system is not like PC where different programmes can be executed to fulfil multiple tasks.

Embedded system is a computer/processor based system designed for specific usage.

MicroController: CPU with integrated memory or peripheral device.
MicroProcessor: CPU without inbuilt memory or peripheral interfaces.

The key in modern computing is not how fast a program can be executed from start to end, but rather how fast CPU can respond to largely unpredictably ordered/timed event. Embedded systems are largely reactive, i.e. more focus on reacting to events rather than focusing on doing a job start to end.

State Machine
As a result, the key for firmware is to identify appropriate action to be executed when a given event occurs. This  action can be function of two factors
- nature of event
- context (current state which is sequence of past events)
If it is not handled properly, the code end up having more switch-case/if-else statements which reduces maintainability, testability by reducing code execution paths. The solution is state machine which takes care of both factors listed above, as it captures system's history (context) as well as knows about nature of current event.

Challenge: 
State machine require an execution context and event dispatching mechanism(extract event from HW, or global variable). This means, event queuing and timing is required. 
Redundancy: Event demultiplexing is already performed once based on event type, while state machine requires redoing de-multiplexing based on event type and current state.

Possible Representations:
1. Nested switch statements
switch(state)
{ case 0: switch(event) { ..}; break;
   case 1: switch(event) { ..}; break;
..}
2. State table containing array of transition for each state
event -> event1                          event 2
state |  
state1     action; next_state        action; next_state
state2     action; next_state        action; next_state

3. Dynamic tree like structure of state and transition objects (similar to 2, but memory optimized)


Finite State Machine (FSM)
Memoryless basic state machines. Must take new state for change in behaviour.
E.g. Figure 2a on State Machine Coding

Extended State Machine
E.g. Figure 2b of State Machine Coding [

Complete condition of system is combination of 
- qualitative aspect(state)
- quantitative aspect (extended state variable, like time-out counter). This is why it is NOT memoryless.
E.g. extending timeout for an operation in ESM will be quick, while it would require heavy change in finite state machine.

Tempting to add another extended state variable and guard condition(another if/else) to meet required architecture delay.

e.g. In calculator, hitting . and using extended state variable DecimalOn to record is not best solution. It is better to enter 'fraction calculation' when . is hit and handle remaining part thereon. Danger: If forgot to reset DecimalOn flag? 
Another issue is, changing qualitative aspect (extended state variable) requires re-compilation, it is always preferred to have device doing things at runtime.

State machine(event driven) performs action only in response to explicit event, while Flow Chart (transitional) does not need event triggering, but work on transition upon completing action.

Firmware Development
The embedded software firmware is about more thinking than just doing trial and error. Since it is small, it can easily expose basic mistakes related to design choices, implementation flaws and can even look very dirty if not given thorough though before implementation.

The sense required to design good state machine is to isolate,
- which part goes into qualitative aspect, and
- which part goes into quantitative aspect.

List down below items in design phase:
  • Purpose
  • Challenges
  • Counter-Measure for challenges
  • Detailed Plan: List of files, peripheries of micro-controller required, how to setup peripherals properly. GPIOs, PLLs, ADCs, LEDs etc.
Starting Implementation
  • Setup empty header and source files with folder structure, place them safely in version control system (like, GIT, Mercurial, Perforce, IBM Rational etc.)
  • Setup clock and configuration registers
  • Lots of macros to talk to GPIOs in cleaner way
Since we talked about firmware, I thought it is good to put some electrical/electronics terms.

Inductor: Passes DC with zero resistance. Resistance increase proportionally to frequency.
Capacitor: Blocks DC. Resistance to AC signals diminishes as frequency increases.
Passive Devices: Resistors, Capacitors, Inductors. Cant amplify applied signal. Can operate on themselves without external source.
Active Devices: Vaccum Tubes(valves), Transistors. Can clip, amplify, distort, change applied signal. Allows electron flow, some allow voltage to control current(voltage-controlled), other allow current to do this flow(current controlled). Transistors can act as either voltage- or current-controlled. Vacuum tubes are voltage controlled. Require external source for operation.
Presence of active devices make a device electronic.


References


No comments:

Post a Comment