Lpc2000

At 02:09 PM 1/11/06 -0500, Tom Walsh wrote:
>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.

Bit fields exist, bit types don't.  Bit fields are useful for compactly 
storing small integers such as flags.  Mostly counter productive for 
dealing with hardware.

> >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...  ;-)

Yep.

><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.

Portability from chip to chip is actually the least issue for me, it can be 
nice but it ends up not being the primary driver.  I see the two biggest 
benefits of it as being

         - portability of knowledge.  If you can mostly stick with the 
standard subset then when you do switch chips and or compilers and you 
will, if not frequently, then at least occasionally.  This was the reason 
for my C99 comment.  It appears to have some nice stuff in it, but until 
it's support is more widespread I'd least stay away from those parts that 
can't be implemented with a  simple header file or library support 
routine.  YMMV
         - Tool support.  Things like lexical analyzers, code generators 
etc.. are much happier with standard C than files riddled with extensions.

Add to that, nearly every C compiler I've used has broken under serious use 
and the most vulnerable spot has always been the extensions and ... well I 
stay away from them unless I really need them (which is very seldom).  I 
long ago gave up on interrupt keywords, I always write my own shell 
function in assembly that way I know I not at the mercy of a temperamental 
compiler.

>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.

Ah we agree, after all :)

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


That's all I'm saying.

Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,   be 
they legal, genetic, or physical.  If you don't believe me, try to chew a 
radio signal. "  -- Kelvin Throop, III
http://www.aeolusdevelopment.com/