Title: Embedded Systems

Those of you who still have the old ACCU handbook from the era when I was Hon Sec may note that my biography had the comment "Biggest mistake: Telling the ACCU Chair person that I had a good idea..." After making some suggestions to The Editor about some things I would like to see in C Vu I find myself agreeing to an Embedded Feature for C Vu!

I did put out a request for some support but this fell of deaf ears. This is unusual as I am informed (by Adrian Gothard at his talk on Embedded Systems at the ACCU Forum in Oxford) that embedded systems out number desktop systems by 10 to 1!

However a lot of these are mass-market consumer products. For example a team of 4 SW Engineers might turn out 4 embedded systems in a year that go in a car that sells 20,000. (80,000 systems). Actually many cars have more than 4 systems. Then there are lifts and entry systems, microwave cookers and washing machines, aircraft, ships, robots (thousands of them that make cars, cookers, washing machines etc.) radios, telephones and mobile phones (and additionally the SIM card in a mobile is an embedded system with a CPU in it's own right!) The list goes on and on.

So you can see how embedded systems might outnumber desktop systems. Then there is the philosophical problem that most desktop systems are likely to contain one or two embedded systems...

What makes an embedded system different to a desktop system? Embedded systems are usually but not always dedicated to a single task, have task specific IO and often only expect to communicate with another computer. Screens and [full QWERTY] keyboards are uncommon. The "software" is often burnt in to an EPROM or PROM (and then called firmware) this makes code patches difficult and in some cases impossible. The systems tend to have a minimum amount of memory and the 8bit CPU still rules.

Whilst some of the chips become dated as the leading edge moves on the embedded world is the opposite of the desktop. One does not write SW that will run on machines that are leading edge today and common tomorrow. One has to use a CPU that is cost effective in 100,000 off quantities today and in those quantities a 10p ($0.16) saved per CPU by using an older model is £10,000 ($16,000) in production. As the desk top runs headlong to 64, 128... bit processing and beyond the majority of the embedded world is still using 8-16 bit (and 4 bit is not completely dead) 32 bit is only the high end though the proliferation of the i86 chips and (PC based) tools has brought their cost down.

Lastly embedded systems are expected not to crash and if they do, to get themselves out of the jam. What's more they are expected to be fail-safe. I understand that Microsoft is planning to do an embedded version of Windows... You can try Ctl-Alt-Del in the lift next time it stops!

There is also another difference between "normal" and embedded systems is that the tools tend to be a lot more expensive and specialised. One Borland compiler will run on virtually any PC produce software for almost any PC. Embedded tools run on a host that is separate to the target. The targets tend to be unique and may or may not run an operating system. The tools are usually tied to a specific CPU family; occasionally a specific CPU in that family. Whilst there may be millions of embedded systems there may be only a few developers for each tool. The 80,000 systems in the car cited earlier only had 4 developers who may only have had 4 compilers and one ICE.

At the ACCU Forum in Oxford Adrian Gothard gave a talk with the title above. It was very illuminating. Adrian is "up to his neck in work" so I am doing a commentary on his slides. The slides are available from the Parkway Gordon web site.

What is an Embedded system? Generally it is a CPU, a few peripherals and a dedicated program. They tend to be physically small. Then again I have worked on an "embedded" system that had 12 486's, a Sparc and a 500Mb Hard disk in a 19" rack.

What skills are needed? Due to the intimate relationship between the hardware and the software both hardware and software skills are needed. Though it tends to be high level hardware and low level programming.

Design Challenges Typically: No screen, no keyboard, limited memory (8051 variants have 128 or 256 BYTES of RAM!), limited features, no OS. However the word to note is "typically". There are many systems that do use special embedded OS. Arguments rage over which is "the best" like all things embedded there is no clear answer.

Embedded Systems outnumber desktop systems by a factor of 10 to 1 and the ratio is growing. "chips with everything". Virtually anything that has electricity in it has a chip these days. However as the skills for embedded engineering are more specific than general computing there is a major skills shortage. UCAS admissions for degree courses in Electronic Engineering are down by 3.8% and they were never that popular to start with!

Some of the major growth areas for embedded engineering are:

In the 5 months since Adrian put these slides together the areas he was suggesting were growth areas have well and truly grown.

Development tools Tools are a major headache in the embedded world. The advent of the PC has helped. Hosts tend to be PC or UNIX based. Targets can be a huge variety. Consequently it is only recently that good integrated environments have appeared. Also due to space restrictions of the target assemblers and more recently compilers have had to be more stringent with resources that "normal" compilers. Debugging is a problem as a debugger on the host has to simulate a completely different environment. In Circuit Emulators still cost thousands of pounds. These devices are used to look into the target, replacing the CPU or micro controller.

What Processor? The choices here are crucial. A CPU with peripherals or a micro controller? Chip count and number of holes in a PCB are factors. As is heat generated in some cases. A mask for a Microcontroller can cost £100,000. Debugging tools and numbers of units you expect to sell are a factor. Then there is the choice of 4, 8, 16, 32 or 64 bit systems. Yes, 4 bit is not dead yet! Of course there is the usual RISC or CISC argument and to top it all can it be done faster/cheaper with an ASIC? As noted previously there is a skill shortage so your choice may depend on what people you can get!

Do it in hardware or software? Not a problem most SW engineers have to face. In the embedded world many things can be done in both hardware and software. The problem is deciding where to draw the line... If it is in software it could be changed later. Also it is easier to change the software than the hardware later in the development. Hardware is probably going to be faster and put less strain on the CPU. It is possible to adjust hardware characteristics in software. For example the Hubbell telescope. However this requires more software more memory. If there is no more memory then a new CPU and round we go again.

Programming Languages For many years there was only one language for embedded work: Assembler. However C has been the mainstay for a while with pockets of Pascal and Forth. Some parts of the automotive industry used Modula2. C++ and JAVA are trying to get in on the act and some of the larger systems will use them. However Assembler and C will always be there on the smaller systems.

Operating Systems You may note that this slide contradicted a previous one. Small embedded systems do not have room for an OS. Many systems do not need one but then again many do. There are many OS from 5K single thread monitor systems to OS like LYNX that is a multi-thread system that uses hardware MMU on (only) 32 bit systems. It might be that you are working on a system that has no commercial OS support and you might have to write your own OS. Of course it could be that your project does things that no current OS supports. There is also the type of operating system to think about. Shared memory, protected memory, flat model. How are you going to protect the data (and the program(s))?

Development. Having made your decisions do you develop and test the hardware and write the software to fit (and fit it must) or do you write the software test it under simulation and then do the hardware? Actually it's not up to you, the deadline dictates that you WILL have to develop concurrently...

Development cycle This is like one of Echser's drawings. There are the usual project definitions, requirements, functional specs and detailed design. However once construction starts there are certain "no turning back" points particularly for the hardware that mean the after certain point the software MUST fit in the space and do the job. Prototyping This is where one gets some sample hardware that is as close as possible to the target to tryout some of the ideas and software. There are many evaluation boards for most CPUs and microcontrollers. These take some of the theory and guesswork out of the system but... and it is a big but, these boards are not the production target so they may not behave exactly as the real system. Added to which it may not be possible to mock up some of the hardware.

System Reliability. "Hardware:- Software Engineers don't trust it" and" Software:- Hardware Engineers don't care" This attitude actually comes out in other parts of the project as well. This is why embedded engineers who know both hardware and software are highly sought after. However in embedded systems reliability is paramount. During the Oxford talk the engineer next to me said "How many bugs do you let an embedded system go out with?" I said "None that I know about and I test it thoroughly first." His point was that usually version 1.0 of an embedded system is the only one there is going to be. I have heard SW project managers say "We can fix it in the next release." Fortunately not working on an aircraft or car system.

Debugging Embedded Systems There are various tools and strategies to go with them. The simulator is the closest thing to a debugger that most people will have come across. Then comes the ROM emulator, In Circuit Emulator, BDM and finally the logic analyser and oscilloscope. Not all of these will be available and often one has to tailor a debugging and test strategy to the tools. Many of these tools cost into thousands of pounds, a long way from the Borland Turbo C at £50.

Watchdogs. Not the TV programs but an essential part of most if not all embedded systems. What do you do when you PC locks up? Ctl-Alt-Del. When testing your nice little embedded system on the bench you can press the reset button. What if your little embedded system is not on your bench but at 160 W 65 N? On the Alaskan oil pipeline in the middle of nowhere, where a gentle breeze brings the temperature down to -40C! A watchdogs is circuit that resets the whole system automatically after a pre-set number of cycles or on a counter time-out unless a running system resets the watchdog during that time. However there is a lot more to watchdogs than that. They can be implemented in either hardware or software or a combination.

Harsh Environments. Leading on from watchdogs and why you may not want to personally reset a system is the environment. Most PC's live in nice air-conditioned offices or homes. Embedded systems may have to live in a temperature range of -40 to +40. Then there is vibration and EMI. No not the record company but electromagnetic interference. You can often see EMI on a television when a badly suppressed car passes or an electric drill is used. Now imagine what would happen if a glitch like that got in to a lift control circuit!

Upgrading Embedded Software. At one time it was almost impossible as in many cases software was (and still is) masked in to the CPU. Now E2PROM and Flash RAM make upgrading the software possible... if you can get to the system. Remote upgrading some systems is possible.

Quality This is not the same as reliability. It is the overall quality. Systems can be designed for ease of manufacture or testing. Software can have a built in self-test.

Software-Re-Use. This is a real hot topic. However it is a lot more difficult in embedded systems. CPU architectures are very different, memory sizes and IO. Not to mention big- and little-endian. The golden rule, as with most things, is keep it small and simple.

Adrian's last slide was this:

Y2K. Nuclear Power.

The embedded market is in two camps. The hobby market that grew out of home electronics where people buy one or two microcontrollers and shareware compilers and the professional market where 4 compilers at £1600 each (and an emulator at £5000) is not uncommon and then they buy 100,000 microcontrollers.

The companies that sell embedded products like the latter but not the former mainly because the former require a lot more support than the latter but return very little revenue.

There are a few exceptions for the hobby user. There are the Atmel range of microcontrollers with flash memory in place of ROM and the PIC series from Microchip. The BASIC Stamp is a variant of PIC from Parallax seems to be aimed exclusively at the home market. These have a large amount of free information and data around the internet.

One thing that has helped both the home and business user is the CD. It makes "databooks" so cheap to produce that data is easy to come by. Getting some of the CPUs is not

On the hobby front robots have taken off with great deal that is achievable at home. Though there are still those who delight in the 68K doorbell that play's Wagner's Ring Cycle. Robot kits start at £50 and give the programmer lots of scope. You will need you own SW development tools though. However, much can be done with the evaluation copies distributed. Keil do a demo 8051 system that is restricted to 2K program memory.

Here are a few web sites for those wishing to dabble:

At last there is an authoritative, generally available, C standard (programming guidelines) for embedded and Real-Time work [ref. 1]. It is also inexpensive at £25-00 (around £30) in the UK. It grew out of a need in the automotive industry with the rapid increase of the use of software to control the modern car. Engine management, brakes, instruments and those annoying gizmos that say "Fasten your seatbelt!"

In April 1998 MISRA [Ref. 3], the software consortium managed by MIRA [Ref. 4] released their "Guidelines for the Use of the C Language in Vehicle Based Software". Don't be misled by the title! Whilst it was developed for the automotive industry the acknowledgements page spans universities, compilers writers, R&D organisations, SW specialists, SW tools companies, a list of 36 individuals, several of which are household names (in the SW industry). Many will be familiar to members of the ACCU [ref. 4]. It also mentions that the automotive companies involved came from Austria, Scandinavia, Germany, USA, UK, and Japan.

I was told that this standard took two years to produce so it has not been done lightly though with the speed at which the ISO crowd work one might think so. (That is a subtle hint to the C, C++ and Java ISO committees!) (Actually there is a very large difference between developing a set of coding standards and writing a language standard. In the case of Java Sun Microsystems are 100% responsible because they thought they could do it faster than ISO ☺ Francis)

So much for the pedigree but what does the standard actually contain? The usual preamble of the why's and wherefore's, scope and usage. The real meat is in The Rules. There are over one hundred and twenty of them. The are split in to seventeen sections such as Environment, Types, Control Flow, and Functions. The rules are further sub-divided into "Required" and "Advisory".

Each rule is numbered and stated simply. For most some explanation is given with source code in a few examples. In many cases there is a reference to source documents and where possible the ISO C standard. Remember the language standard is just that, it defines the syntax and semantics. Good practice is not defined in ISO9899. At the end is a very useful cross-reference to ISO 9899. So those of you without it can write your own in-house coding standard using these guidelines and be able to reference ISO C as well.

Some (most?) of the "Required" Rules are obvious common sense... well I thought so until I discussed one or two with some programmers and discovered I had a different interpretation on "obvious" and "common sense" to some of them. These guidelines will be useful just to keep your engineers on their toes. See how many know why some of the rules are there. As I said many should be obvious common sense but...

These rules are for use on all the MISRA safety levels (0 to 3) except the highest, level 4, which requires "a certified language with proven formal semantics". Level 4 will not be using C. (So what will it be using?) This guide will get you as safe as you are going to get with C, not withstanding the disclaimer on page ii. Even with a good programming standard some programmers can make a right mess of it. (Good enforcement tools such as QA C can do much to help there. Francis)

What MISRA C will not tell you is what to put in the source file identification, history copyrights etc., file naming conventions, code layout, indenting. It does not delve into the religious argument of where the {} go, there is an internet newsgroup for that! None of these issues will affect the reliability of the software even if it does have a bearing on readability and maintenance.

Whilst mentioning readability I have to read a lot of standards and this is the most readable one to date. When I took it in to the office I actually had engineers reading it with interest! MISRA C is written with the idea that a real engineer, rather than a theoretical standards guru, will be using this guide.

Having previously dismissed the preamble before the rules, six sections, it does contain a lot of useful information more than one would think, on first glance. Information such as what the compiler does and does not do. That will surprise a few people. How many programmers do you know who say "It must be correct: it compiles."?

There is a section on compliance matters that is a useful idea on it's own. Basically it says we know what the rules are but where are they tested? More importantly can we prove that they have all been tested?

There is information on how to claim compliance to the standard. For those not in the automotive trade it is a very sensible list of things we should all be doing anyway. All ISO9000 companies should have no trouble with the proof of conformance.

Do make sure you read the sections (1 to 6) before The Rules. Though it will probably be after you have gone through the rules.

I am looking hard to find something to complain about but apart from the title there is nothing. The title comes about because previously they have produced the "MISRA Development Guidelines for Vehicle Based Software" and they wanted the names to match. Given the standard of these guidelines I am minded to look at their development guidelines.

So no complaints but a wish list. This is a generic guide for all embedded use. Perhaps in the next version "they" could do a series of appendices for the 8051 family, 166, H8 68* etc. Some of the RTOS manufacturers might like to produce their own addendum. (Talk to MISRA.) These MUST be complementary to this guide. They will cover some of the idiosyncrasies of these families and RTOS. I am thinking of things like defines for the 8051 xdata. Also a portability matrix for writing code for use on more than one target. I would see these addenda as tightening things up. Thus there will be additional "8051 rules" containing things like: Rules 2,10, 40,86 move from "advisory" to "required". I would not expect to see any going the other way.

By the way, MISRA stands for the Motor Industry SOFTWARE RELIABILITY Assn [author's emphasis]. We all need reliable software and not just in cars. So whilst the standard has been done primarily for the automotive industry it is applicable to all embedded safety critical work. Given the cost and clarity of the standard there is little excuse for not using it as a guide on all embedded C. Come to that any C, embedded or not. I expect (hope) "MISRA-C" to become an industry wide standard for embedded coding.