Lpc2000

Robert Adsett wrote:

>At 04:54 PM 1/11/06 +0000, ee_gary wrote:
>  
>
>>Thanks Tom,
>>
>>I was looking for something that would let me do:
>>
>>if(LED1)
>>  LED2 = 1;
>>
>>This would require associating LED1 and LED2 with a particular bit in
>>the appropriate IOPIN register.  Judging from your response, this is
>>not possible with GCC and ARM?
>>    
>>
>
>  
>

Bit fields simply do not exist in gcc.  Initially when porting a massive 
amount of 8051 source I had looked to see how I could construct them.  
Then I realized that the only reason I used a bit field was to conserve 
memory, the 8051 has such a miniscule amount of "Fast Access" RAM, 
external RAM required either a DPTR operation or register indirection 
(e.g. mov P2, #HIGH variable ; mov R1, #LOW variable ; mov ACC, @R1 ; ... ).

Since MIPS were comparatively low, the bits located in IRAM were hugely 
important, mostly as semaphores between various functions  / 
interrupts.  With ARM, the instruction set allows inexpensive access to 
the memory field and , therefore, inexpensive IRAM bitfields are moot.


>You could go to C++ and overload the assignment operator appropriately.  If 
>the only benefit you are getting is bit manipulation that seems a little 
>overboard to me but it would work.  Toms solution did rely on some C99 
>construct which as yet are far from widespread.  The C++ version might 
>actually be more portable.
>  
>
Then there are the legion of discussions that we could have regarding 
C++ value, or lack of, for use on an embedded platform...  ;-)


>Or you could simply realize that there is a legion of embedded 
>microcontroller families out there without bit manipulation instructions 
>and addressing and become comfortable with the common methods of dealing 
>with those in C with out the use of either extensions to the language or 
>C99s additions.
>
>  
>
<RANT>

The portability issue seems a bit silly to me.  Probably this is due to 
the fact that I support the code I write on a single type of processor 
and am not moving constantly from MIPS, to ARM, to 80C188, to ColdFire, 
to...  processors on a regular basis.  Write once, sell many.  heh.

Portability does become an issue when moving from an Archemedes C 
compiler to a GNU C compiler.  But, the recent move of my code from 
Archemedes to GNU was relatively painless.  I did some sed operations to 
change "BOOL" to "bool", "set_bit(foo)" to "foo = True", etc..  For the 
most part, the transition from an ancient 8051 development environ to a 
GNU environ was relatively painless.

I can see people who use a development system which allows cute little 
things like "AT" to dictate where sections are placed, or "BIT" to 
automagically built psuedo bitfields.  IMO, those are the people that 
will suffer vendor lock-in and run into portability issues!  Keep 
relying on stuff outside of ANSI and you will run into problems.

</RANT>

I'm just an old K&R programmer, fairly conservative in how I write my code.

Regards,

TomW


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