--- In l..., Ralph Hempel wrote: >
> What is it with bitfields that leads young or inexperienced
> programmers down this path?
>
Presumably for the same reason that they would prefer to write:
pi = 3.14159265;
instead of
pi = 0x40490FD8; // sic ;-)
Unfortunately, as many have pointed out, it is not feasible to use C
bitfields as a means of manipulating bits of hardware-mapped
registers in an unobfuscated way.
If you are interested in an alternative solution to this problem I'd
refer you to the Oberon-07 programming language - I currently am
responsible for maintaining and supporting the LPC2xxx Oberon-07
compiler.
Oberon-07 has a built-in 'SET' data type that allows you to access
individual bits by their number (i.e. MSB = 31, LSB = 0). This
allows you to go straight from the definitions in the NXP LPC2xxx
User manuals to writing code without having to do the mental
gymnastics involved in converting from bit numbers to a Hex
representation. e.g.
(* P0.2 Bits 5:4 = 01 TXD UART0 *)
(* P0.3 Bits 7:6 = 01 RXD UART0 *)
SYSTEM.GET(LPC.PINSEL0, select);
SYSTEM.PUT(LPC.PINSEL0, select - {5, 7} + {4, 6})
i.e. to clear a bit, subtract that bit number, to set a bit, add
that bit number.
The use of the pseudo-functions GET and PUT make it clear that you
are either reading a register or writing a register. They actually
generate in-line code so there is no loss of efficiency.
Jean-Jacques Dauchot wrote:
> What if someone or lots of people (including me) could come up with a > standard to usie this bit field thing to access the
registers on LPC2000
> chips as IAR has obviously managed in some obscured way .
>
> Please comments?
Then they would no longer be bitfields.
You would need to add ways of specifying read-only, write-only, or
read-write (probably on a per field basis), constant write(IE field
always written to a particular value), and write width at a minimum.
That's almost certainly only complete enough to be annoying.
From the Divided by a Common Language File (Edited to protect the guilty)
ME - "I'd like to get Price and delivery for connector Part # XXXXX"
Dist./Rep - "$X.XX Lead time 37 days"
ME - "Anything we can do about lead time? 37 days seems a bit high."
Dist./Rep - "that is the lead time given because our stock is live....
we currently have stock."
Reply by Daniel P●May 29, 20092009-05-29
Hi Jean-Jacques,
could you please send me your LED sample with Yagarto.
how different is WINARM from Yagarto?
I think I'll do some code converting too.
Regards,
Daniel
________________________________
From: jdauchot
To: l...
Sent: Wednesday, May 27, 2009 11:32:36 PM
Subject: [lpc2000] Re: Using Bit Field structures to access LPC-2000
registers
Hi Daniel
Effectively the LPC2478 and LPC2378 have the same register set apart from the
LCD interface
I have got a basic LPC2478 project working OK based on LPC2378 code. Flashing
LEDs etc
I would like to convert IAR LPC2478 LCD code projects to Yargarto tool chain.
But IAR uses those bit field structures to access registers that nobody likes
for some good reasons it appears.
I have a lot work to do the convert the bit field code to more conversional
instructions
Regards
Jean-Jacques
--- In lpc2000@yahoogroups .com, "Jean-Jacques Dauchot" wrote: >
> Well I better start converting all those bit field instruction to normal
> ones.
>
> I want to convert several LCD drivers etc for the LPC-2478 STK sample code
>
> Regards
>
> JJ
>
> _____
>
> From: lpc2000@yahoogroups .com [mailto:lpc2000@yahoogroups .com] On Behalf
Of
> Paul Curtis
> Sent: 27 May 2009 17:04
> To: lpc2000@yahoogroups .com
> Subject: RE: [lpc2000] Using Bit Field structures to access LPC-2000
> registers
> Hi,
>
> > I presume you had a go at this?
>
> Nope. I know better.
>
> > I had a very brief go at it and got very confused.
> >
> > So I am asking if anyone had a go
>
> As you have chosen GCC as your compiler, I suggest you do not even try. GCC
> will optimize writes to bitfields and will happily use a reduced-width
> instruction if it pleases. Like I said, don't do this.
>
> --
> Paul Curtis, Rowley Associates Ltd http://www.rowley.
> co.uk
> CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors
>
>
>
Reply by rtstofer●May 29, 20092009-05-29
--- In l..., "Jean-Jacques Dauchot" wrote: >
> OK
>
>
>
> I am starting get very interested with this debate.
>
>
>
> What if someone or lots of people (including me) could come up with a
> standard to usie this bit field thing to access the registers on LPC2000
> chips as IAR has obviously managed in some obscured way .
>
>
>
> Please comments?
>
>
>
> Regards
>
>
>
> Jean-Jacques
Who would care?
The problem isn't with the language and it probably isn't with the
compiler. The problem is with hardware registers not reacting in the same way a
memory location would react. Read-modify-write works perfectly for RAM
(assuming the compiler understands the access rules) but hardware designers
create a huge problem when a register read clears certain flags as a side
effect. Or the more general problem where read-modify-write doesn't work
at all.
So, bit fields won't work perfectly against all hardware. Therefore, they
should be ignored and hardware compliant methods used instead. For some
processors, it is common to have a register 'shadow' value in RAM.
This shadow value is updated and the result written to the register without a
read-modify-write operation.
At least limit bit fields to RAM. There is some possibility that this might be
portable. More or less...
Richard
Reply by FreeRTOS info●May 29, 20092009-05-29
> OK
>
> I am starting get very interested with this debate.
>
> What if someone or lots of people (including me) could come up with a
> standard to usie this bit field thing to access the registers
> on LPC2000
> chips as IAR has obviously managed in some obscured way .
>
> Please comments? I have not read this whole thread so maybe am just repeating what
other
people have said, but 'standard' and 'bitfield' are
incompatible terms.
Even if you come up with your own 'standard' and it matches what IAR
do, as
far as I'm aware there is nothing in what is commonly accepted as the C
standard for embedded (please don't start a debate on that!) compilers
that
defines how bitfields should work. Therefore IAR are free to change how
they use them (not that they would as their libraries are littered with
them), and other compilers are free to do as they please. Reliance on
bitfields mapping into register bits is, in my humble opinion' a very
bad
idea and one that will eventually lead to pain.
I am by no means an expert on this, but I am lead to believe that bitfields
were in the C language to assist on severely RAM limited machines where a
variable can be just one bit (Boolean) rather than taking up a whole word.
This is presumably why there was never anything standardised on how the bits
actually map to anything.
Besides that, bit fields are ugly, make debugging difficult, unnecessary,
and against most coding standards, etc.
For me there is no debate, I just won't use them.
Regards,
Richard.
+ http://www.FreeRTOS.org
Designed for Microcontrollers. More than 7000 downloads per month.
+ http://www.SafeRTOS.com
Certified by T as meeting the requirements for safety related systems.
Reply by Ralph Hempel●May 29, 20092009-05-29
Jean-Jacques Dauchot wrote:
> I am starting get very interested with this
debate.
>
> What if someone or lots of people (including me) could come up with a
> standard to usie this bit field thing to access the registers on LPC2000
> chips as IAR has obviously managed in some obscured way .
You would be met with smug nods from experienced embedded guys
as they think about how they will enjoy their beer on the back
patio over the weekend while you are in the lab chasing down
mysterious bugs.
What is it with bitfields that leads young or inexperienced
programmers down this path?
Is it the incessant teaching of clean abstractions by their
professors?
Is it that nobody uses them for register access so they think
that they have found the holy grail of embedded programming?
Are their girlfriends impressed by the size of the brain that
must deal with the headaches and insanity that comes from
using these bitfields?
What is is, exactly?
For me bitfields are like an old Jaguar or MG. Nice to look
at, but in the garage more than they are on the road.
Ralph
Reply by 42Bastian●May 29, 20092009-05-29
Jean-Jacques
> What if someone or lots of people (including me)
could come up with a
> standard to usie this bit field thing to access the registers on LPC2000
> chips as IAR has obviously managed in some obscured way .
IAR can do so, as they do have hands on their compiler. And even might
have special versions of the intermediate code for different platforms.
GCC does not have it AFAIK. GCCs intermediate language has no idea of
the underlying architecture. So changing GCCs bit-field handling would
IMHO mean a lot of work with very little new benefit compared to
hand-crafted bit-manipulating instructions.
But since bit-fields are not portable, you would need to have such be
fixed in the C standard.
--
42Bastian
------------------
Parts of this email are written with invisible ink.
Note: SPAM-only account, direct mail to bs42@...
Reply by Jean-Jacques Dauchot●May 29, 20092009-05-29
OK
I am starting get very interested with this debate.
What if someone or lots of people (including me) could come up with a
standard to usie this bit field thing to access the registers on LPC2000
chips as IAR has obviously managed in some obscured way .
Please comments?
Regards
Jean-Jacques
_____
From: l... [mailto:l...] On Behalf Of
s...@aeolusdevelopment.com
Sent: 29 May 2009 18:12
To: l...; l...
Subject: RE: [lpc2000] Re: Using Bit Field structures to access LPC-2000
registers
Jean-Jacques Dauchot Wrote >
>Again I had good look at was said. But accessing memory must be a hardware
>access ?????
>
> What do you say about that?
I was using hardware as shorthand for external (to the processing core
hardware) and a synonym for I/O.
Memory has certain guaranteed attributes that are assumed to be true that
I/O does not
- A read will return the same value that was written
- All valid widths are allowable
- order of operations on the parts that make up the whole do not matter.
IE if you operate on two 8 bit values to manipulate a 16 bit value it
doesn't matter which order you manipulate them in.
- bit order doesn't affect anything (ie it doesn't matter where a
bit
field ends up), bit order is consistent but that's a minor restriction.
For use as memory compaction it really doesn't matter where a bitfield
ends
up.
The first three are the ones that will really cause a problem, and I/O
commonly breaks all three assumptions. The fourth is an issue but like
integer size it's one that occurs as you change processor/compilers. It
could change as you upgrade compilers and although more likely with
bitfields than integers it still won't occur often.
Some of these assumptions are broken by other I/O such as communication
streams and file stores as well.
Robert
----------------------
mail2web.com - Enhanced email for the mobile individual based on MicrosoftR
Exchange - http://link.
mail2web.com/Personal/EnhancedEmail
Reply by "sub...@aeolusdevelopment.com"●May 29, 20092009-05-29
Jean-Jacques Dauchot Wrote >
>Again I had good look at was said. But accessing memory must be a hardware
>access ?????
>
> What do you say about that?
I was using hardware as shorthand for external (to the processing core
hardware) and a synonym for I/O.
Memory has certain guaranteed attributes that are assumed to be true that
I/O does not
- A read will return the same value that was written
- All valid widths are allowable
- order of operations on the parts that make up the whole do not matter.
IE if you operate on two 8 bit values to manipulate a 16 bit value it
doesn't matter which order you manipulate them in.
- bit order doesn't affect anything (ie it doesn't matter where a
bit
field ends up), bit order is consistent but that's a minor restriction.
For use as memory compaction it really doesn't matter where a bitfield
ends
up.
The first three are the ones that will really cause a problem, and I/O
commonly breaks all three assumptions. The fourth is an issue but like
integer size it's one that occurs as you change processor/compilers. It
could change as you upgrade compilers and although more likely with
bitfields than integers it still won't occur often.
Some of these assumptions are broken by other I/O such as communication
streams and file stores as well.
> Again I had good look at was said. But accessing
memory must be a hardware
> access ?????
Not necessarily. Modern micorcontrollers have lots and lots
of peripherals, and the on-chip or external RAM can be thought
of as just another peripheral.
You have to remember that the intent of C was as a high level
programming language (some say assembler) for a few long-haired
buys at Bell Labs to use in making operating systems and application
code more "portable"
For their relatively small machines, using bitfields as a
high-level construct to store as much information into as
few bytes as possible made sense.
I don't think in their wildest dreams that they would have imagined
their bitfield construct being used in today's complex microcontrollers
with wierd register access semantics.
They would have wrapped it up in a function call and used the
assembler to to the bit-fiddling :-)
