Never mind - I was looking at something else; yeah, that byte
store won't do the right thing for APB peripherals.

Start a New Thread

> Paul Curtis wrote:
> >
> > This generates:
> >
> > E1A0C00D mov r12, sp
> > E92DD800 stmfd sp!, {r11-r12, lr-pc}
> > E24CB004 sub r11, r12, #4
> > E59F300C ldr r3, [pc, #12]
> > E5932000 ldr r2, [r3]
> > E3A03001 mov r3, #1
> > E5C23000 strb r3, [r2]
> >
> > How about that then?
> What about it? The peripheral bus has byte select signaling.

Oh for heaven's sake--even if a bus supports data width/selection signals
doesn't mean the peripheral at the other end has to honour them. The
battery-backed RAM doesn't support byte and half-word access, IIRC.

--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors

Start a New Thread

Jean-Jacques Dauchot Wrote
>You Guys must hate bit fields to bits

Bitfields are great when used for their intended purpose, compacting fields
into a smaller space. All the rules are designed to make that
straightforward and relatively efficient.

They are worse than useless for hardware access.

Even if you luck out on the code generator there often isn't a single bit
abstraction that is useful.

Robert

--------------------------------
mail2web - Check your email from the web at
http://link.mail2web.com/mail2web

Start a New Thread

Hi Robert



Now this is best explanation I had from the group so far.



THANK YOU.



I do not like to write complicated code and in the end it will catch you
out.



The topic that I started on this subject is that a lot of impressive demo
code for the OLIMEX dev board is written using IAR tool chain.

And I would like to use some of them

It is very difficult to follow at best of time; whether its deliberate I do
not know. Bit fields structures are used extensively to access hardware
registers

I do not fancy spending 3,500 on a licence to use this kit.

Even the fact the Kickstart limitation of 32k is free.



I am now, from good advice from you and others not going to use bit fields
structures HOORAY !!!!!



Regards



Jean-Jacques





_____

From: l... [mailto:l...] On Behalf Of
s...@aeolusdevelopment.com
Sent: 29 May 2009 14:16
To: l...; l...
Subject: RE: [lpc2000] Re: Using Bit Field structures to access LPC-2000
registers



Jean-Jacques Dauchot Wrote
>You Guys must hate bit fields to bits

Bitfields are great when used for their intended purpose, compacting fields
into a smaller space. All the rules are designed to make that
straightforward and relatively efficient.

They are worse than useless for hardware access.

Even if you luck out on the code generator there often isn't a single bit
abstraction that is useful.

Robert

----------------------
mail2web - Check your email from the web at
http://link. mail2web.com/mail2web



Start a New Thread

Paul Curtis schrieb:

> A slight modification:
> ...
> _pinsel1bits->p0_16 = 1;
> This generates:
>
> E1A0C00D mov r12, sp
> E92DD800 stmfd sp!, {r11-r12, lr-pc}
> E24CB004 sub r11, r12, #4
> E59F300C ldr r3, [pc, #12]
> E5932000 ldr r2, [r3]
> E3A03001 mov r3, #1
> E5C23000 strb r3, [r2]
>
> How about that then?

Saying with the 5th element: Boom-bada-boom :-)

--
42Bastian
------------------
Parts of this email are written with invisible ink.

Note: SPAM-only account, direct mail to bs42@...
Start a New Thread

Hi Robert

Again I had good look at was said. But accessing memory must be a hardware
access ?????

What do you say about that?

Regards

Jean-Jacques

_____

From: l... [mailto:l...] On Behalf Of
s...@aeolusdevelopment.com
Sent: 29 May 2009 14:16
To: l...; l...
Subject: RE: [lpc2000] Re: Using Bit Field structures to access LPC-2000
registers

Jean-Jacques Dauchot Wrote
>You Guys must hate bit fields to bits

Bitfields are great when used for their intended purpose, compacting fields
into a smaller space. All the rules are designed to make that
straightforward and relatively efficient.

They are worse than useless for hardware access.

Even if you luck out on the code generator there often isn't a single bit
abstraction that is useful.

Robert

----------------------
mail2web - Check your email from the web at
http://link. mail2web.com/mail2web



Start a New Thread

Jean-Jacques Dauchot wrote:

> 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 :-)

Ralph
Start a New Thread

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 Microsoft
Exchange - http://link.mail2web.com/Personal/EnhancedEmail

Start a New Thread

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



Start a New Thread

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@...
Start a New Thread