YOU KNOW YOU WANT TO BUILD AN EMBEDDED APPLICATION, and you know you

Transcription

1 1 Software Cosideratios YOU KNOW YOU WANT TO BUILD AN EMBEDDED APPLICATION, ad you kow you wat to use Liux as the operatig system.where do you start? With the hardware. The hardware choices you make processor, memory, flash, ad so o drive what you will do with the software. Because o software licese cost is associated with Liux, most of your cost will be i the hardware itself.the more uits you sell, the more true that is.therefore, i ay high-volume applicatio, it s importat to get the hardware right before you ever worry about the software. Liux has bee adapted to may differet microprocessors ad microcotrollers, ad more are supported all the time. Chaces are that Liux already supports the processor you ll choose i some way. If ot, ad you have the time ad expertise, you ca support it yourself. After you select the hardware you wat to use, it s time to see how well Liux supports that hardware. So fire up your browser ad search the Iteret for Web sites devoted to Liux + your hardware device. Here are some good places:

2 4 Chapter 1 Software Cosideratios After you ve fially decided o your hardware platform, it s time to ail dow exactly what you wat the software to do.this chapter presets several software-related issues you ll eed to cosider. Note: If you wat to support a soft modem (also kow as wimodems), you ca write the driver for Liux ad istall it as a module at boot time. Lius does t like this, but admits that it does t violate the GPL. Embedded Liux Toolkits Portig Liux to a ew hardware platform ca be a dautig task. Fortuately, several embedded Liux toolkits are desiged to simplify the job of buildig the biary that rus your device. Some toolkits, such as Lieo s Embedix ad Mote Vista s Hard Hat Liux, are broadly focused, ad are able to work o may processors for lots of differet applicatios. Others are from smaller compaies ad focus o arrower processor sets ad more limited applicatio rages. Still others, such as PeeWeeLiux, are ot products distributed by compaies, but rather projects built by a set of like-mided hackers i the traditioal Ope Source model. Here are a few thigs to cosider whe you re lookig for a embedded Liux toolkit: Hardware support. Does the Liux toolkit iclude support for the processor you wat to use? If the toolkit does t already support that processor, does the toolkit vedor have the ability to develop that support quickly eough for your purposes? If so, how much will it cost? Does it fit i your budget? Documetatio. Is the toolkit well documeted? Are all of the programs ivolved documeted? Does the documetatio cover both high-level cocepts such as architecture white papers ad low-level documetatio such as how to build biaries, how to add your software to the code base, ad referece mauals to the build ad rutime software? Adaptability. How adaptable is the embedded Liux toolkit to the particular applicatio you re goig to use? If it s a very arrow toolkit ad you ll use it for several projects, how much work will be ivolved i chagig the toolkit to the projects for which it s ot as well suited? Developer support. What kid of developer support does the toolkit compay offer, ad how expesive is it? If you eed a bug fixed, a questio aswered, or a device driver writte, how quickly ca you get a respose from the compay? Is a listserv available for the users of the product? If oe is available, how active is it? Is ayoe from the compay aswerig questios o the list? Field upgradeability. Are facilities available i the toolkit for upgradig the software i the field? Does the toolkit compay offer ay meas for deliverig those upgrades, or is that left to you?

3 Kerel Features 5 User iterface. If your applicatio requires some sort of user iterface, what are your optios? Does the embedded Liux toolkit offer some sort of embedded video iterface? If so, how much room does it take? If ot, is there some sort of Web-based iterface available for cofiguratio? Note that the toolkit itself may ot have ay support for a graphical iterface. Several Ope Source projects ad several commercial products are aimed at buildig small-footprit graphical user iterfaces. For more iformatio, see Track record. Does the toolkit vedor have ay examples of customers who have created a similar product out i the field? How successful was that vedor with the toolkit? Kerel Features The Liux kerel rus o a vast array of hardware architectures everythig from hadhelds to maiframes.to support this sort of scalability, the kerel is highly cofigurable. There are several ways of cofigurig the kerel (ote that I m usig the word cofigure quite loosely here): Typig make cofig, make meucofig, or make xcofig i the root of the kerel source rus the stadard kerel cofigure routies.you ca tur optios o or off or sometimes compile them as modules so they ca be loaded at rutime. There are hudreds perhaps eve thousads of kerel patches floatig aroud the Iteret. Some are very small eough to fix a small bug i oe file. Medium-size patches may affect a half-doze files ad add support for a particular hardware device. Some large patches add or affect may dozes of files ad add support for ew architectures. Ofte applyig a patch adds ew questios or etire screes to the kerel-cofiguratio screes previously described. The Oe True Method of really cofigurig the kerel to do exactly what you wat is to hack o it yourself. Util recetly, this was a exercise oly for those who have lots of time ad patiece the Liux kerel source code is well structured but somewhat obtuse. Lius does t believe i clutterig up the source with commets for the uiitiated (see Chapter 5 of Documetatio/Codig Style i the Liux source tree). Fortuately, times have chaged ad there are ow several good overviews of the Liux kerel. Perhaps the most lucid is Uderstadig the Liux Kerel by Daiel Pierre Bovet ad Marco Cesati (O Reilly, 2000).

4 6 Chapter 1 Software Cosideratios Networkig, Filesystems, ad Executable Formats Some embedded Liux applicatios have o use for the etworkig code. Be sure to cofigure the kerel so that the etworkig code is skipped if you do t eed it; it takes up a lot of space. Also, make sure that your kerel supports oly the oe or two filesystem types you actually eed. Fially, you probably eed oly oe executable format, ELF (Executable ad Likig Format), for your embedded applicatio, so be sure to tur off all the rest. For details o the ELF file format, cosult the followig documets: I geeral, it s a good idea to look through the documetatio for all the choices i the kerel build meu. If you re usig make meucofig to cofigure the kerel, you ca press the questio mark (?) at ay time to get iformatio o the choice you have highlighted. While you re developig your embedded device, it s hady to eable loadable module support i the kerel.that way, if you eed support for a feature that you had t aticipated, you ca go back, recompile the modules you eed, copy them oto your device, ad load them.without loadable module support, you have to recompile the whole kerel, which ca be a bit of a pai.whe you re doe developig the device, you ca save some amout of RAM ad ROM space by recompilig the kerel without loadable module support ad with your drivers compiled directly ito the kerel. However, you should figure out exactly how much of a savigs this is ad whether it s worth it havig loadable module support may be useful for upgradig drivers i the field. Execute-i-Place (XIP) Oe way you may be able to save a lot of RAM requiremets is to ru your executable programs directly from the log-term storage (ROM or flash) where they reside.this is called execute-i-place (or XIP for short). O a desktop system, your applicatio lives o the hard disk ad must be read ito RAM for executio. However, most embedded applicatios do t have a hard drive for log-term storage; istead, they have some sort of memory device, such as ROM or flash. Ulike a hard drive, these memory devices may be directly addressable by the CPU, like RAM.You ca use the direct addressability of these memory devices to reduce your RAM requiremets. Istead of copyig the executable code from the memory device ito RAM, a XIP system sets up the kerel structures that ormally poit ito the RAM copy directly at the log-term storage locatios.the code executes just as it would if it were copied to RAM. Depedig o the speed of the processor, memory, ad flash, there could be a performace pealty for usig XIP.

5 Kerel Features 7 Figure 1.1 shows the differece betwee ormal executio ad executio i place (XIP): Process 123 MyProg Istructio Poiter Filesystem RAM 1) The user executes the MyProg commad from the shell 2) The MyProg executable is copied from the hard drive to RAM 3) A process (123) is created that poits to the RAM copy of MyProg Normal Executio - Execute i RAM Process 123 MyProg Istructio Poiter Filesystem Flash RAM RAM 1) The user executes the MyProg commad from the shell 2) The MyProg executable is already addressable i flash so o copy is ecessary 3) A process (123) is created that poits to the flash image of MyProg Execute i Place (XIP) Figure 1.1 XIP illustratio. Real-Time Operatig Systems Most of the time, it s ot very importat exactly how log a specific task takes to complete o a computer. For istace, whe someoe hits a key o the keyboard, they expect a letter to appear istatly but how fast is istatly? It could be aywhere from a few tes of millisecods to a couple of hudred millisecods.you re probably ot goig to otice the differece betwee ay two timigs uder 50 millisecods (about 1/20th of a secod). However, the timig of some operatios i some computer applicatios is crucial. For istace, if your applicatio moves a robotic arm to a precise locatio so that it ca pick up a chip from a stack, the to aother locatio so it ca lay dow the chip at a precise locatio o a PC board, the timig of the movemet operatios must be exact.this is whe you eed a real-time OS.

6 8 Chapter 1 Software Cosideratios For istace, most moder cars have atilock brakig systems. I these systems, special sesors detect whe oe or more wheels begi to lock up a dagerous situatio that ca cause the vehicle (ad its occupats!) to slide. I these situatios, it s imperative that whe the sesors detect a wheel begiig to lock, the brakig o that wheel be reduced immediately. Have you ever worked o a computer system where you started a ew program ad the etire computer became uresposive for several secods? Imagie what would happe if the computer cotrollig your atilock brakes was similarly busy ad uresposive right whe a deer jumped i frot of your car! This is a situatio where you eed what s called hard real time. A hard real-time OS guaratees that, without fail, o matter what else happes, a respose to a evet will occur withi a specified fixed time. For example, whe wheel lockup is detected, brakig for that wheel must be reduced withi a certai umber of millisecods. I this example, a hard limit exists o how log the system ca take to respod to the wheel lockup coditio.this hard limit meas that this is a hard real-time task first, because there s a absolute limit o the amout of time available for a respose, ad secod, because bad thigs will happe if the system fails to respod withi the specified time limit.these two features of the task to be performed make it clear that the task requires a hard real-time operatig system. Whe workig with a soft real-time OS, o the other had, whe a evet occurs the system will try its best to service the evet withi a average respose time. For example, whe playig a game of Quake III, whe a player fires a rocket at aother player there s a expectatio that the game program will draw a fiery explosio oscree, make explosio oises, ad dutifully subtract health from your oppoet. With all of this complexity added to the existig evets i the game, it s very likely that the frame rate of the game may drop slightly while rederig the explosio ad playig back the additioal audio, sice these tasks require additioal CPU time. If the frame rate should drop from 50 frames per secod (fps) to, say, 40 fps for the duratio of the explosio, o harm is doe the player cotiues to ejoy her game, sice the system is still fast eough. Beig fast eough is a defiig characteristic of soft realtime systems. I this case, o fixed frame rate is required of the system, ad o harm occurs should the frame rate decrease slightly. Both hard ad soft real-time systems are useful, but they have distictly differet uses. I fact, a hard real-time OS usually accommodates tasks requirig both hard ad soft real-time respose. Several attributes differetiate a real-time operatig system from a stadard operatig system, as show i the followig list. Respose time predictability. A hard real-time OS guaratees that the timig of some operatios will be precise withi its stated limitatios.these respose times are much faster tha those of a typical operatig system they re measured i tes of microsecods (millioths of a secod) istead of millisecods (thousadths of a secod).

7 Creatig or Acquirig a Developmet Eviromet 9 Schedulability. I a hard real-time operatig system, a process ca be scheduled to perform at a very precise time i the future or at a very precise iterval. Agai, the precisio is dow to the microsecod level istead of the millisecod level. Stability uder pressure. I a hard real-time system, the processor ca become iudated with far more sigals from differet sources tha it ca hadle; however, some of those sigals are much more importat tha other sigals ad must be recogized ad dealt with.the ability to prioritize a vast array of differet sigals quickly ad efficietly is aother hallmark of a good real-time system. For more details o embedded real-time systems, see Raj Rajkumar, et al, The Cocise Hadbook of Liux for Embedded Real-Time Systems Versio 1.0 (Pittsburgh, Pesylvaia: TimeSys Corporatio, 2000), p. 5. I additio, provides a lot of iformatio about real-time Liux. Several real-time Liux kerel projects are uderway, as show i Table 1.1. Table 1.1 Real-Time Liux Projects Address Title Site Sposor RTLiux Real time Liux New Mexico Istitute of Techology RTAI Real Time Dipartimeto di polimi.it/projects/rtai/ Applicatio Iterface Igegeria Aerospaziale Politecico di Milao KURT The KU Uiversity of Kasas Real Time Liux RED-Liux Uiversity of Califoria, RED-Liux/idex.html Irvie Creatig or Acquirig a Developmet Eviromet Before you ca eve start codig, you must either create or acquire a developmet eviromet for your chose microprocessor or microcotroller.you ll eed a C compiler, assembler (part of the compiler), liker, rutime library, debuggig tools, ad perhaps a emulator.the fastest way to acquire a developmet eviromet is to get it from oe of the embedded Liux toolkits. Usually this is free or a omial price.

8 10 Chapter 1 Software Cosideratios Bootig the Kerel How the computer loads the operatig system ito memory ad starts it is a issue that most software developers ever have to thik about. Most of us work o PCs or similar platforms that have a BIOS that does the dirty work of settig up the computer s hardware ad fidig ad loadig the OS loader (for example, LILO or GRUB) ito RAM so that the kerel ca start.the most we ever have to thik about is which OS loader to use ad how to cofigure it properly. Welcome to the world of embedded devices, where you may start with a maual that says oly somethig like this: Hard Reset (HRESET) Iput causes the hard reset exceptio to be take ad the physical address of the hadler is always x FFF PowerPC 601 RISC Microprocessor User s Maual (IBM Corporatio, 1993), p It s ow up to you to write the assembly code to do the followig: 1. Iitialize all of the hardware. 2. Move the OS loader ito memory from storage (or perhaps you just load the OS itself). 3. Jump ito the code you just loaded. Fortuately, most developmet boards for the various microcotrollers ad microprocessors come with ample documetatio ad sample code for startup.there are also may examples o the Iteret for the may differet processors that Liux supports. Software Size Ulike a geeral-purpose computer system, a embedded system oly requires eough software to actually get a specific set of jobs doe.this meas you ca do without a lot of the fluff that ormally goes ito a geeral-purpose computer system such as X widows, ad ewsreaders, games, ad so o. By doig this, you ca make the software image much smaller.this is importat because you ormally do t have a hard drive i a embedded applicatio. Eve whe you do have oe for storage, it may be better to put the system software ad applicatios i ROM or flash so they are t as vulerable to corruptio. Both ROM ad flash are much more expesive byte-for-byte tha space o a hard drive, so it s importat to iclude just the software that your embedded applicatio actually uses. Aother reaso to limit the software that ships i your embedded applicatio is simple; if it s ot there, it ca t break. It s usually very icoveiet to upgrade the software i a embedded applicatio sometimes it s impossible.

9 Upgradig the Software i Place 11 However, a tradeoff exists betwee egieerig time ad footprit size. Geerally, the loger you egieer the product, the smaller ad more efficiet you ca make it, reducig your memory requiremets, ad thus reducig the cost of each uit. However, the more time you sped o efficiecy, the fewer features the product will have, give costat egieerig resources. Also, if the product sits i egieerig too log, you may lose cosiderable market advatage to your competitors. Reducig the Software Footprit So how do you reduce the memory/storage requiremets of your embedded Liux applicatio? Geerally, there are three ways: Iclude oly the software you eed. Compile the software to reduce size. Compress the resultig software. Chapter 2, Miimal Liux, details how to reduce the size of your embedded Liux applicatio. Upgradig the Software i Place Most software systems must be upgraded at some poit i their lifetime for a variety of reasos: bugs ad security vulerabilities are foud ad fixed, ew features are required, ad so o. Embedded applicatios are o exceptio. However, if upgradeability is ot desiged i from the begiig, the upgrade process will be difficult or eve impossible. For istace, uless you wat your customers to do mior surgery o your embedded device, you should t ship the software i ROM.The oly way to replace software that s bured ito ROM is to replace the ROM chip. Also, if you oly have eough memory-plus-storage i the device to actually ru the applicatio, upgradig is very dagerous because there s o good place to put the software.you ca dowload the ew code over the old code, but oe small error ad your customer ow ows a doorstop istead of a embedded Liux applicatio. So how do you desig your upgrade process from the begiig? 1. Start by puttig oly the most low-level code i ROM ad puttig the rest i flash.the code that s i ROM will probably ever be replaced, so you have to get it right.you may wat to put the upgrade code itself i ROM; that way, o matter what happes i the field, the user ca upgrade to a workig set of code eve after messig up a upgrade attempt. 2. Cofigure the machie with eough storage or RAM to hold two complete copies of the software i the machie simultaeously. Uless you put the upgrade software i ROM as described above, your applicatio will become a doorstop if a catastrophic evet occurs, such as loss of power.you wat to reduce this doorstop time to the miimum possible. For istace, if your applicatio

10 12 Chapter 1 Software Cosideratios dowloads the ew software directly o top of the old software ad this process takes 20 secods, you have a doorstop time of 20 secods. If the customer s power is lost, a cable is kicked loose, or the cat jumps oto the keyboard ay time durig this 20 secods, your customer ow has a doorstop plus, they re agry, ad it will cost you moey. Now imagie that you have 21/2 times the amout of flash that you really eed i the device (the extra 1/2 is for growth). Istead of overwritig the old code with the ew, you store it i the extra room i the flash as it s dowloadig. Whe all the code is safely writte to flash, you the chage a few poiters to complete the update. Now your doorstop time is just a few millisecods, while the poiters are updated i flash. This procedure has other advatages. After all the ew software has come across, you ca make sure that the biary image is itact by icludig some checksum code.you ca also make sure that the user has dowloaded the right thig ad has a later versio tha the oe curretly istalled. Noe of this is possible if you overwrite the curret software with the ew as the dowload occurs. 3. Put all of the cofiguratio iformatio for your machie i a sigle place, such as a sigle file i flash.this makes all your software much easier to maage. It makes the upgrade process easier because there s oly oe file to maage (ad perhaps chage) durig the upgrade process. Remember that you may have several versios out i the field, however, ad you do t wat to force users to move from a very old versio to the ewest versio by upgradig through each versio i betwee. If your software chages a lot betwee releases, the permutatios ca become eormous quickly, so keepig thigs as simple as possible helps the user avoid losig cofiguratio iformatio. Of course, there are may ways to accomplish this objective.the process described above is more costly o a per-uit basis tha simply puttig everythig i flash memory. Depedig o your applicatio ad ecoomies, it may make more sese to put everythig i flash just realize that i some istaces you could ed up with a lot of doorstops out i the field.