Embedded Systems October 2000 Vol13_11

Issue link:

Contents of this Issue


Page 8 of 181

Parity Bit Readers to the Rescue A n astute reade r, Aa ro n Be rke n, po inte d out a n erro r in th e PRE (x) macro in my a rticl e, "Design by Contrac t fo r C Programme rs" Uuly 2000, p. 100) . The asse rtion test was in adve rte ntly left o ut o f th e macro d e rinition o n page 10l. Unfortunate ly, thi s o miss io n re n- d e red th e macro useless. Wha t I meant to write was: #define PRE(x) { if (testPre &&\ !(x» reFailed(VALUE( __ LINE __ )\ , __ FILE--, #x) ; } This change a pplies to both the macm defin ition on page 10] as well as the macro expansion o n page 102. Myapologie fo r the inaccuracy. Steve Kapp EM8EDDJ.: O R": /\L. - T I M E skapP@(' II1r1 ,C OIll t I have some comments in response to Cha rlie Carothe rs' le tte r regarding the May a rticle "A 'C' Test," (p. 11 9) . The expression (60 * 60 * 24 * 36S)UL is not valid because UL is not a postfix operator that can be applied to any integer expression. There is no UL operator in the C language. Instead, U and/ or L can be used as pan of th token that specifies a lite ..... dl integer con- stant These suffIXes must immediately follow the digi ts of the integer constant and are part of the constant itself, rather than a modifier that is applied to the constant. For example, 60UL is a con- sta nt of type unsigned long_ (See sec- tion 6.1.3 of the ANSI C standard.) I believe the C++ standard requires rna l- loc (0) to return a non-zero pointer, but the ANSI standard states in section 7.10.3: "If the size of the space requested -e a re a couple of bugs in the cod e tha t accompa ni es Michael 1e1 Ba rr's a rticle "Software-Based Memory Testing" Uuly 2000, p. 28). 1. The documentation in the code (memtest. c) suggests that if you want to use the aJgorithm to test memory that has a data bus wider than an 8 bits, you should change ule typedef for datum to a type that is as wide as the data bus. Fo r a 16-bit memory device, you would change the typedef for datum to typedef unsigned short datum;. However, this pre 'ents a problem for the loops in Ule address line test because the initiaJizer in many of ule loops is offset = si zeofCdatum);. In this case offset is 2. The first access to memol)' 'hould be at ule address correspo nding to the least significant non-zero address line . For 8-bit memory, this add ress is 1, but fo r 16-bi t memol)" this address is 2. Since the va riable baseAddress is of type volati le datum *, ule expression baseAddressCoffsetJ baseAddressC2J, and since datum is an unsigned short, this cOITespond to the becomes is zero, the behavior is implementation- defined; the value renlnled shall be either a null pointe r or a unique point- e r." Therefore, you cannot count on either behavior if you want your C pro- gram to be portable. With implementa- tions that do return a valid poin ter, I would guess that ule library acnlaJly does aJlocate some memory. (malloc typicalJy aJlocates some exu-a overhead memory for in te rn al bookkeeping uses.) However, the result is likely to be unde- fined behavior if the programmer acnl- ally tries to store something in this "zero- sized" memory block. Rod Spade toll 11 datum at memol), address 4, instead of ule desired address of 2. To fix this problem, the variable offset (or testOffset) should always start a t 1. 2. The test for address lines stuck low and shorted doesn't work when an add res line is stuck low. When an address line is stuck low, a write to an address at some power of two will cause an unintended write to address O. The current test only checks for Ule non-ze ro addresses, and wi ll miss a bit stuck low. Also, Mr. Ba rr referred to problems expe rie nced with missing memo ry chips, indicating Ulat it is possible to write to a memory location , and Ula t the capacitance on the dat.:1. lines may sto re ule written value. I would add tha t ulis could only happen if the microprocessor cached or pipelined its instruction fe tches, or if the re we re sepa ra te data buses for data and code. On aJl of the embedded systems that I've worked on, afte r writing a value to RAM, the micro must do at least one instruction fe tch at its PC in orde r to even know to read back from that RAM location. In doing so, the addl-ess and data lines change be tween writing the value to RAM and reading it back. William Moon EA STMA N KODAK C OM I'A N \' ERRATA In a recent article on Linux ("Linux, [nterruIJ/ed," 77wmas Besemer, August 2000, I). 49), the name of th.e author of the original aO-CTR05 driver was omiUed. code was developed and is maintained Uy Dr. Wam>n f aslJer, Associate ProftSS01; North Carolina State University. Source code is I~ vided with no warranty under the terms of the GNU Public License and derivatives of the driver, Lille Ml: Besemer's, must "I1w.intain the same licl'nsing terms. -Ed. Embedded Systems Programming OCTOBER 2000 7

Articles in this issue

Archives of this issue

view archives of EETimes - Embedded Systems October 2000 Vol13_11