Embedded Systems October 2000 Vol13_11

Issue link:

Contents of this Issue


Page 38 of 181

Mandating 51 standard units in embedded software is not practical when the inputs and outputs are anything but standard. Force = mass'" acceleration Al ternately: ewton = kilograms*meters/ seconds/ scconds 1 Newton = 1 kg-m/ s2 In addition, S] provides a vocabu- lary fo r scaling the standard units by powers of ten. These fam iliar prefixes are shown in Table 1. Why not use 51 units for everything? Mandating cant performance penalty when it is fo rced to use emulated floating-point o pe ra ti ons. When a floatin g-point coprocessor is available, the space required to store 4-byte floats might be too costly when 2-byte in tegers will suffi ce. For most programmers, the obvi- I standa rd uni ts in em bedded software is not pl-acticaJ when th e inputs and outputs are any- thing but standard. Such a require- ment can directly impact the pe rfor- mance and cost of tile system. For in tance, a system that measures time in one-microsecond clock ticks would need a data type mat can represent l / l ,OOO,OOOm of a second in ordel- to keep the data in I units. Since C does not provide a fixed-poin t type, me only othe r choices are to use a float- in g-point type 01- an in teger in non- standard uni ts. Cost-sensi tive em bedded systems avoid fl oat ing-po int computa tio n whenevel- possibl e. Using a CPU with- out a floating-point copl-ocessor can cu t costs. Floatin g-point computa- tio ns on an integer CPU require the use of a fl oating-point emula tio n li bra l-y to take th e place of the coprocessor. The emulation li brary takes up precious memory, which can affect th e cost of the system. Floating- point ope rations are emulated with function calls mat may be routed via an exceptio n ha ndl e r. Ope ra tions that would normally compile to a sin- gle instruction fo r an integer a re turn ed into fun ction calls for emulat- ed floating point. Even me fastest in teger processor will suffe r a signifi- ous solu tion to this problem is to use a scaled in teger, that is, an integer in non-standard units. For our one- microsecond clock tick, the simple choice is to re presen t time in units of microseconds. Strictly speaking, mis is a standard unit because we are only scaling me time by a power of 10. Scaling S] uni ts by powers of 10 is as simple as slapping on one of me pre- fixes shown in Table 1 in front of the name. Unfortunately, scaling by a power of 10 is often no help in embedded software. For example, the output of an anaJog-to-digital converter (ADC) is typically a binary value-meaning me range of output values is a powe r of two. The input range, on the omer hand, can be constrained in a com- pletely arbitrary fashion. So, in gener- aJ , the output of an ADC will be X/ 2', where X is me input range and y is the number of bits in me output. Even if me actual in put (x) is in standard units , your output will be some stan- dard unit divided by a power of two. SI doesn 't help much here, since mere is no vocabulary for representing stan- dard units scaled by powers of two. That's probably just as well , since it is not very often mat your input is an in tegral multip le of a standard unit e imer. Use and abuse of units in software It's hard to adhe re to any conven- tion, let alone SI, in your softwa re, when all your inputs are in no n-stan- dard uni ts. Devices li ke timers, ADCs, and encode rs spit out in tegers in whateve r uni ts a hardware designer can dream of. Some times mese uni ts make se nse and sometimes th ey' re just al-bitrary, but mostly th ey' re not standard . It's up to th e embedded programmer to make some sense out of the chaos. It would be easy j ust to blame hardware designe rs, but the re 's ple n- ty of blame to go a round. Programmers can also play fast and loose with me data and confuse any- one who tries to fo llow. Many a short- cut has been used to save CPU cycles tha t make the code read like a col- lege textbook whe re "the proof is left as an exercise for the reade r." While shortcu ts a re often necessa ry in embedded softwal-e, it is not neces- sary to confuse eve ryone who looks at th e code. Some common shortcuts you may have run across include inte rchang- ing terms li ke "frequency" and "peri- od," or "tinle" and "di stance" in your code. This may seem trivial as long as you are fa milia r with the design, but it can confuse a newcomer. Anothe r example would be ha rd-cod- ing scale facto rs in your code to con- ve rt from o ne sys tem of units to anoth e r, wim no me nti on as to wha t is going on. Sometimes, we hide vital info r- ma tion in a design docume nt that co uld have easily bee n included in th e code in th e fo rm of a comme nt or a n in fo rmative name. Programme rs will make assumptions with o ut always checkin g the docu- men ta ti o n- th a t 's human na ture . Some assumptio ns may seem obvi- ous to th e programme r, but can still be wro ng. It may have seemed obvi- ous to th e programme rs writing the sof twa re fo r th e Mars Clima te Embedded Systems Programming OCTOBER 2000 37

Articles in this issue

Archives of this issue

view archives of EETimes - Embedded Systems October 2000 Vol13_11