Top Banner

Click here to load reader

INSE lecture 18 – Embedded systems  what they are  hardware for embedded systems  kernels for embedded systems  building embedded systems  testing

Jan 06, 2018

ReportDownload

Documents

Physical aspects  Small, to occupy minimal space  Often need to be “ ruggedized ” against  temperature (high, low, sudden change)  vibration  humidity, oil, chemical attack  nuclear shock (military applications)  Therefore often encapsulated in a resin-filled metal box

  • INSE lecture 18

    Embedded systems what they are hardware for embedded systems kernels for embedded systems building embedded systems testing embedded systems embedded systems in Java

    *Notes

  • What embedded means a computer (usually small) built into some non-computer equipment usually to monitor & control that other equipment ~98% of CPUs since 2004?

    *Small both physically and in terms of computer power.

    For examples in this lecture Ill usually take two common examplesa computer-controlled washing machine a cars Engine Control Unit (ECU)

    were all familiar with (non-computerized) washing machines and card, and therefore are probably inclined to overlook the electrical control systems in them (even when not computerized)

  • Physical aspectsSmall, to occupy minimal spaceOften need to be ruggedized againsttemperature (high, low, sudden change)vibrationhumidity, oil, chemical attacknuclear shock (military applications)Therefore often encapsulated in a resin-filled metal box

    *Notes

  • Central hardware aspectsLow cost (to not significantly raise the unit price of the whole system)Minimal CPU/ROM/RAM but that means something different every yearStill often 8-bit or 16-bit; occasionally 32-bit, now rarely 4-bitlow clock speeds but faster every year? Low-power components in battery-based systems

    *

  • Peripheral aspectsOften switches or primitive keypad (not a full typewriter keyboard)No screen or a primitive screenInput devices can include thermometers, pressure sensors, rev-counters, radar etc;Output devices are often relays or other electro-mechanical control systemsIn electronic systems (e.g. DVDs, mobile phones) I/O can be via specialist chips (e.g. audio)

    *Notes

  • Software aspectsNo need or memory-space for a full O/Sbut often a kernel of an O/Speripheral interfaces e.g. interrupt drivers

    *Notes

  • Implies new SE challenges!tighter restrictions on design freedomextra issues to design for to fit small hardwarewhether speed is adequateprogramming methodstesting methods

    *Notes

  • Kernel software many embedded systems need an O/S kernel

    *all but the simplest embedded systems need a kernel of an operating system

  • Kernel for common servicesinterrupt drivers?flash disk => a simple filing system?elementary schedulerThe kernel of a larger embedded system might go further e.g.?an elementary database

    *Notes

  • Commercial kernelsMany are availabledepends on the CPU type

    *Notes

  • Building embedded software We are not using a general-purpose computer! consequences Languages

    *Notes

  • Not a general-purpose computerSonowhere to hold source & binary files on itcant edit on itcant compile on itThereforedevelop the source and binary on a general-purpose computer => specialist IDE?cross-compile it;various means for transferring it to the target.

    *Transfer often by burning roms for plugging into the target hardware circuitry. Makes repeated testing fiddly so see later.

  • Language needsneed ability to write interrupt drivers?need to address specific memory addresses?bitwise operations?

    *Notes

  • Common languagesassemblerCC++AdaJava (later)

    *Notes

  • Testing embedded software hampered by hardware restrictions need some new testing tactics!

    *On almost all embedded systemsthere's either a very primitive keypad (not really flexible enough for full control of any sort of test), or no keypad at all; there's either a very primitive screen, or perhaps some LEDs (not adequate for observing a test), or no output at all (other than to whatever apparatus the embedded system is to control); seldom any disk or equivalent (except maybe some flashdisk, e.g. a mobile phone).

    So can we do any meaningful testing?we have difficulty controlling the target program under test;we have difficulty test-inputting to it;we have difficulty test-outputting from it; andwe have difficulty observing it!

    There are a number of common tactics: not surprisingly, there is usually a three-way trade-off betweencost;how much control and observability they give us; andthe reliability of the results.

  • Instrumenting the hardwareCollecting & observing electronics signals from the hardwareprobably doesnt change the behaviour of the system, butthe information is of limited use.

    *Notes

  • Slaving the hardwarea modified version of the system motherboard,attached to the development computer (rather than in the target environment)runs under control of the development computerdevelopment computer fakes inputs;development computer collects outputs.May affect the behaviour of the system under test

    *Notes

  • Extending the hardwareExtend a test motherboard to support keyboard, screen etc.Very likely to significantly affect the system under test

    *Notes

  • Or just simulate!Want software on the development system that fakes the behaviour of the target hardwareGood for large-volume preliminary testsMight be part of the IDEMany commercial simulators available depends on the CPU

    *Notes

  • Embedded Java A special case Commonly used where there is a simple GUI

    *Notes

  • BackgroundJava is usually compiled to bytecode not to executable machine codeThe bytecode is interpreted by a Java Virtual Machine (JVM) programOnly need a JVM for a CPU to run Java on it dont need any cross-compiler can test on anything else with a JVM

    *Notes

  • Features of embedded JavaCan use Java libraryAWT is especially useful for GUIsBytecode is compact => need less ROMVery portable e.g. can easily change CPU chipBytecode is downloadable (if there is a communications peripheral)SLOWso may be one of a pair of languages in some embedded systems

    *Mobiles (downloadable games & ring-tones)Satellite TV & digital TV (red button)

  • After this lectureKeep your eye open for new kinds of embedded systems and their new features/tradeoffs etcBe aware of the huge number of jobs in such an industry

    *Notes

  • C Lester 1997-2014

    *Notes

    *Notes*Small both physically and in terms of computer power.

    For examples in this lecture Ill usually take two common examplesa computer-controlled washing machine a cars Engine Control Unit (ECU)

    were all familiar with (non-computerized) washing machines and card, and therefore are probably inclined to overlook the electrical control systems in them (even when not computerized)*Notes*

    *Notes*Notes*Notes*all but the simplest embedded systems need a kernel of an operating system

    *Notes*Notes*Notes*Transfer often by burning roms for plugging into the target hardware circuitry. Makes repeated testing fiddly so see later.*Notes*Notes*On almost all embedded systemsthere's either a very primitive keypad (not really flexible enough for full control of any sort of test), or no keypad at all; there's either a very primitive screen, or perhaps some LEDs (not adequate for observing a test), or no output at all (other than to whatever apparatus the embedded system is to control); seldom any disk or equivalent (except maybe some flashdisk, e.g. a mobile phone).

    So can we do any meaningful testing?we have difficulty controlling the target program under test;we have difficulty test-inputting to it;we have difficulty test-outputting from it; andwe have difficulty observing it!

    There are a number of common tactics: not surprisingly, there is usually a three-way trade-off betweencost;how much control and observability they give us; andthe reliability of the results.

    *Notes*Notes*Notes*Notes*Notes*Notes*Mobiles (downloadable games & ring-tones)Satellite TV & digital TV (red button)*Notes*Notes