EDNE November 2012 - (Page 29)

By K e v in Kin g • R e n e s a s e l e c t R o n i cs a meRi ca Managing the 8- to 32-bit processor migration B To prevenT seeMingly lillipuTian processor dispariTies froM haTching a swarM of bugs, applicaTion developers working in c MusT keep naTive processor size and endianness in Mind and wriTe Their code wiTh an eye Toward porTabiliTy. ack when I started in electronics, working on discrete, 4-bit processors, I couldn’t have known I would one day have to worry about how big an integer was or discuss processors in a Gulliver’s Travels context. As geometries shrank and prices dwindled, however, there was a great migration of applications from 8- to 16- and then to 32-bit processors. Along the way, tools evolved to bring code generation and application development to new levels of efficiency—generating more headaches in the process. The problem had its genesis in the engineers working with the first microcontrollers who assumed 16 bits for an integer would be “good enough.” Indeed, the early mainframe and minicomputer architectures differed in word length as well as in bit and byte ordering; the number of bits in an integer related to the architecture’s word length and varied from machine to machine. With apologies to Jonathan Swift (Reference 1), engineers have revised the Lilliputians’ argument to debate which end of a number—the largest (big-endian) or smallest (littleendian)—should come first in memory. There are valid arguments on both sides of the “endianness,” or byte-order, debate (Reference 2), but this article focuses on the ramifications for developing applications using C code. An engineer embarking on a project using a 32-bit, littleendian processor, for example, might dismiss discussions of native processor size and endianness as merely academic for a new design. Then, once the project is under way, the engineer might discover that: • The company has code intellectual property that is “tried and true” but has never been tested on a 32-bit, little-endian processor and must be recompiled from C source code; • The code IP must be reusable by another internal group; • The little-endian processor will pass data structures over the communications link to a big-endian processor; and • The project must also use a 16-bit, big-endian memorymapped device that the company’s ASIC group has provided. Any of those scenarios can cause problems if the engineer does not keep in mind the native size and endianness of the processor. Variable size Consider what happens when our hypothetical engineer is given code that appears to be a very simple structure for the calendar portion of a real-time clock: union date_union{ unsigned long year_month_day; struct{ unsigned int year; unsigned char month; unsigned char day; }word_and_byte; } date = { 0x20121022}; static unsigned char read_day; static unsigned int read_year; read_month = date.word_and_byte.month; read_day = date.word_and_byte.day; read_year = date.word_and_byte.year; The code was built without yielding errors, but neither does it yield the expected results. The structure is so simple; what could have gone wrong? The engineer looks at the variables in the watch window, which shows the following: read_month read_day read_year H'00 '.' H'00 '.' H'20121022 It turns out the code had only been used on 16-bit processors up to this point. The first problem is that ANSI C does not define the number of bits in an integer; that number is typically related to the native size of the accumulator in the processor. Thus, the first point is to write your code so that the size of the variables is known. The C99 standard addresses this issue through fixed-width integer support (Reference 5). So, our hypothetical engineer plugs in his solution to correct the variable size (he happens to use the C99 conventions, so if his compiler were C99-compliant he could have just included in his file): #define uint32_t unsigned long #define uint16_t unsigned short #define uint8_t unsigned char endianness and portability The engineer then uses those definitions throughout the “tested” IP and runs the code. Now the watch window, which www.edn-europe.com NOVEMBER 2012 | EDN EuropE 29 http://www.edn-europe.com

Table of Contents for the Digital Edition of EDNE November 2012

Digi-Key
Cover
Agilent Technologies
Contents
International Rectifier
Microchip
Digi-Key
Masthead
EDN comment
Microchip
Pulse
Analog Devices
Maxim Integrated
Maxim Integrated
Texas Instruments
Silicon Laboratories
Test & Measurement World
FTDI
Digi-Key
Strategies for extending product reliability
Managing the 8- to 32-bit processor migration
PCIM
Pickering Interfaces
Mechatronics in Design
Baker's Best
Digi-Key
Emerson
30 years of DSP
Hirose
Vicor
The nuances of variable-frequency drives
Digi-Key
National Instruments
Volt’s battery-stack manager aids Chevy’s drive
Digi-Key
EDNE
Design Ideas
RS Components
RS Components
RS Components
Product Roundup
Tales from the Cube
RS Components

EDNE November 2012