Lpc2000

David Hawkins wrote:

>Alan Strickland wrote:
>  
>
>>I agree, avoid using bit fields.  How bit fields are implemented is
>>compiler dependent.  Granted many (all?) compilers give the option of
>>signed/unsigned and such, but I'd prefer to avoid that issue entirely.
>> Plus accessing individual bits can be wasteful as far as code size is
>>concerned, and flat out may not give the results you want.
>>
>>Last year I had one piece of code that crashed the system when it ran.
>> I was setting up the EMC register and GPIO for external RAM by using
>>bit fields, and the code died a miserable death.  After I replaced it
>>with simple register assignments it worked. I learned my lesson and
>>ripped out every bit field definition I had.  Bit fields are in the
>>grey area of C/C++ standards and are probably best left out of code.
>>    
>>
>
>Just to add to the 'never use bit-fields advice', here's an article
>I found a while ago (where the author calls bit-fields brain-dead) ...
>
>A 'C' Test: The 0x10 Best Questions for Would-be Embedded Programmers
>by Nigel Jones
>
>http://www.embedded.com/2000/0005/0005feat2.htm
>
>I can relate an experience with bit-fields. I was using a TI DSP and
>TI had provided a library that used bitfields. I dutifully wrote
>additional code that looked similar. When I went use the code
>over the PCI bus - things broke! The reason was that some PCI
>devices expect 32-bit accesses, since the hardware (eg. a 32-bit
>wide register) ignor the PCI bus byte enables. I took a look
>at the assembler code produced by GCC and noticed that the
>bit-field code was translated to by assembler commands.
>For comparison I took that same code and built with Visual C++,
>and it produced code that used 32-bit instructions (x86 host).
>
>So, I never used bit-fields again ...
>
>  
>
"A man should know his limiitations", heh.  Same with using code. 
Bitfields are usefull for tearing apart bit-packed fields within data or 
assembling it.  While you are correct in stating that use of a bitfield 
against a register which expects a finite length operation (32 bit in 
your case), it is not correct to condemn then out of hand just because 
you had a bad experience.  "you burn you learn"...

Take this for example, I access the LPC2138 clock this way:

======= begin regCTIME0_t ==========
typedef struct __attribute__ ((packed))
{
   uint  seconds:6;
   uint  reserved:2;
   uint  minutes:6;
   uint  reserved1:2;
   uint  hours:5;
   uint  reserved2:3;
   uint  dayOfWeek:3;
   uint  reserved3:5;
} rtcCTIME0_t;
========== snip ================

To use that structure against the clock, I do this:

========== readRTC() ============
void readRTC (struct tm *theTime)
{// read clock registers and return tm structure.
#if HAS_CLOCK==TRUE
rtcCTIME0_t ctime0;
rtcCTIME1_t ctime1;
rtcCTIME2_t ctime2;
      // grab time from consolidated.
   ctime0 = RTCCTIME0; ctime1 = RTCCTIME1; ctime2 = RTCCTIME2;
      // leisurely tear the packed time apart into individual time.
   theTime->tm_sec = ctime0.seconds;
   theTime->tm_min = ctime0.minutes;
   theTime->tm_hour = ctime0.hours;
   theTime->tm_mday = ctime1.dayOfMonth;
   theTime->tm_mon = ctime1.month;
   theTime->tm_year = ctime1.year;
   theTime->tm_wday = ctime0.dayOfWeek;
   theTime->tm_yday = ctime2.dayOfYear;
   theTime->tm_isdst = FALSE;
#endif
}
=========== snip ===============

Now, I would prefer to let the compiler figure out how it is going to 
access the bit fields within those long words instead of me ANDing and 
SHIFTing to extract data...  No?  Isn't the code more readable with 
"*theTime->tm_min = ctime0.minutes;*" instead of "*theTime->tm_min = 
(ctime0 & 0xf0) >> 4;*" ???


Regards,


TomW



-- 
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net, http://cyberiansoftware.com
"Windows? No thanks, I have work to do..."
----------------------------------------------------




[Non-text portions of this message have been removed]