Yahoo Groups archive
Thread
2006-03-01 by Mukund Deshmukh
Hi,
A stupid question...
I am used C51 and like bit addressing in 'C', but in LPC its not possible.
1. Is there any way I can read or write a port bit by simply writing /
reading 1/0 .
Example for writing
Some_bit_P0_15=1
or reading
if (Some_bit_P0_15) {}
Best Regards,
Mukund Deshmukh.
Beta Computronics Pvt Ltd,
10/1, IT Park, Parsodi,
Nagpur-440022
Cell - 94221137462006-03-01 by Saravanakumar S
Hi,
The same question i asked 2months before .Also, i asked last week
to this forum.But all the pupils are busy with Jaysooriah question.
They didnt have much time to answer this question.Once up on a time that
pupil also,like this only.Now a days they didnt have time to share his
ideas.
Until you perform the bit operation with IOSET & IOCLR.
Hi,
A stupid question...
I am used C51 and like bit addressing in 'C', but in LPC its not possible.
1. Is there any way I can read or write a port bit by simply writing /
reading 1/0 .
Example for writing
Some_bit_P0_15=1
or reading
if (Some_bit_P0_15) {}
Best Regards,
Mukund Deshmukh.
Beta Computronics Pvt Ltd,
10/1, IT Park, Parsodi,
Nagpur-440022
Cell - 9422113746
Yahoo! Groups Links
[Non-text portions of this message have been removed]2006-03-01 by Boris Králik
var |= (1 << 5); //set 5 bit of variable var to 1
(writing)
if (var & (1 << 5)) //test 5 bit of var (reading)
--- Mukund Deshmukh <betacomp_ngp@...>
wrote:
> Hi,
> A stupid question...
> I am used C51 and like bit addressing in 'C', but in
> LPC its not possible.
>
> 1. Is there any way I can read or write a port bit
> by simply writing /
> reading 1/0 .
>
> Example for writing
>
> Some_bit_P0_15=1
>
>
> or reading
> if (Some_bit_P0_15) {}
>
>
>
> Best Regards,
>
> Mukund Deshmukh.
> Beta Computronics Pvt Ltd,
> 10/1, IT Park, Parsodi,
> Nagpur-440022
> Cell - 9422113746
>
>
Regards / S pozdravom Boris Kralik
http://www.geocities.com/kralikbo/
-------------------------------------------------
___________________________________________________________
To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com2006-03-01 by Boris Králik
OH, sorry.
Port operations:
GPIO0_IOSET |= (1 << 15);//Write
15_bit_of_port_0 = (PCB_PINSEL0 >> 15) & 0x1); //Read
--- Boris Kr\ufffdlik <kralikbo@...> wrote:
> var |= (1 << 5); //set 5 bit of variable var to 1
> (writing)
> if (var & (1 << 5)) //test 5 bit of var (reading)
>
> --- Mukund Deshmukh <betacomp_ngp@...>
> wrote:
>
> > Hi,
> > A stupid question...
> > I am used C51 and like bit addressing in 'C', but
> in
> > LPC its not possible.
> >
> > 1. Is there any way I can read or write a port bit
> > by simply writing /
> > reading 1/0 .
> >
> > Example for writing
> >
> > Some_bit_P0_15=1
> >
> >
> > or reading
> > if (Some_bit_P0_15) {}
> >
> >
> >
> > Best Regards,
> >
> > Mukund Deshmukh.
> > Beta Computronics Pvt Ltd,
> > 10/1, IT Park, Parsodi,
> > Nagpur-440022
> > Cell - 9422113746
> >
> >
>
>
> Regards / S pozdravom Boris Kralik
>
> http://www.geocities.com/kralikbo/
> -------------------------------------------------
>
>
>
>
___________________________________________________________
>
> To help you stay safe and secure online, we've
> developed the all new Yahoo! Security Centre.
> http://uk.security.yahoo.com
>
Regards / S pozdravom Boris Kralik
http://www.geocities.com/kralikbo/
-------------------------------------------------
___________________________________________________________
Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com2006-03-01 by Mukund Deshmukh
Thanks for the reply.
As I am transferring my C51 source to Arm, I wanted something as simple as
Some_io_port_0.15=1
So that I define only Some_io_port and my rest of source remains same.
Best Regards,
Mukund Deshmukh.
Beta Computronics Pvt Ltd,
10/1, IT Park, Parsodi,
Nagpur-440022
Cell - 9422113746
----- Original Message -----
From: "Boris Kr\ufffdlik" <kralikbo@...>
To: <lpc2000@yahoogroups.com>
Sent: Wednesday, March 01, 2006 12:46 PM
Subject: Re: [lpc2000] Bit addressing
> OH, sorry.
> Port operations:
> GPIO0_IOSET |= (1 << 15);//Write
> 15_bit_of_port_0 = (PCB_PINSEL0 >> 15) & 0x1); //Read
> --- Boris Kr\ufffdlik <kralikbo@...> wrote:
>
> > var |= (1 << 5); //set 5 bit of variable var to 1
> > (writing)
> > if (var & (1 << 5)) //test 5 bit of var (reading)
> >
> > --- Mukund Deshmukh <betacomp_ngp@...>
> > wrote:
> >
> > > Hi,
> > > A stupid question...
> > > I am used C51 and like bit addressing in 'C', but
> > in
> > > LPC its not possible.
> > >
> > > 1. Is there any way I can read or write a port bit
> > > by simply writing /
> > > reading 1/0 .
> > >
> > > Example for writing
> > >
> > > Some_bit_P0_15=1
> > >
> > >
> > > or reading
> > > if (Some_bit_P0_15) {}
> > >
> > >
> > >
> > > Best Regards,
> > >
> > > Mukund Deshmukh.
> > > Beta Computronics Pvt Ltd,
> > > 10/1, IT Park, Parsodi,
> > > Nagpur-440022
> > > Cell - 9422113746
> > >
> > >
> >
> >
> > Regards / S pozdravom Boris Kralik
> >
> > http://www.geocities.com/kralikbo/
> > -------------------------------------------------
> >
> >
> >
> >
> ___________________________________________________________
> >
> > To help you stay safe and secure online, we've
> > developed the all new Yahoo! Security Centre.
> > http://uk.security.yahoo.com
> >
>
>
> Regards / S pozdravom Boris Kralik
>
> http://www.geocities.com/kralikbo/
> -------------------------------------------------
>
>
>
>
>
> ___________________________________________________________
> Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with
voicemail http://uk.messenger.yahoo.com> > > > Yahoo! Groups Links > > > > > > >
2006-03-01 by Guillermo Prandi
In LPC21xx, GPIO SET/CLR registers are designed so you don't need to
read them in order to set/clear the corresponding GPIO bits:
GPIO0_IOSET |= (1<<15); <---- Unnecesary read
GPIO0_IOSET = (1<<15); <---- Changes (sets) only bit 15
GPIO0_IOSET = (1<<15)|(1<<4); <---- Changes (sets) bits 15 and 4
GPIO0_IOCLR = (1<<15); <---- Changes (clears) only bit 15
GPIO0_IOCLR = (1<<15)|(1<<4); <---- Changes (clears) bits 15 and 4
This feature allows you to modify individual bits without read-modify-
write operations which normally require disabling interrupts in order
to ensure a consistent read.
Guille
--- In lpc2000@yahoogroups.com, Boris Králik <kralikbo@...> wrote:
>
> OH, sorry.
> Port operations:
> GPIO0_IOSET |= (1 << 15);//Write
> 15_bit_of_port_0 = (PCB_PINSEL0 >> 15) & 0x1); //Read
> --- Boris Králik <kralikbo@...> wrote:
>
> > var |= (1 << 5); //set 5 bit of variable var to 1
> > (writing)
> > if (var & (1 << 5)) //test 5 bit of var (reading)
> >
> > --- Mukund Deshmukh <betacomp_ngp@...>
> > wrote:
> >
> > > Hi,
> > > A stupid question...
> > > I am used C51 and like bit addressing in 'C', but
> > in
> > > LPC its not possible.
> > >
> > > 1. Is there any way I can read or write a port bit
> > > by simply writing /
> > > reading 1/0 .
> > >
> > > Example for writing
> > >
> > > Some_bit_P0_15=1
> > >
> > >
> > > or reading
> > > if (Some_bit_P0_15) {}
> > >
> > >
> > >
> > > Best Regards,
> > >
> > > Mukund Deshmukh.
> > > Beta Computronics Pvt Ltd,
> > > 10/1, IT Park, Parsodi,
> > > Nagpur-440022
> > > Cell - 9422113746
> > >
> > >
> >
> >
> > Regards / S pozdravom Boris Kralik
> >
> > http://www.geocities.com/kralikbo/
> > -------------------------------------------------
> >
> >
> >
> >
> ___________________________________________________________
> >
> > To help you stay safe and secure online, we've
> > developed the all new Yahoo! Security Centre.
> > http://uk.security.yahoo.com
> >
>
>
> Regards / S pozdravom Boris Kralik
>
> http://www.geocities.com/kralikbo/
> -------------------------------------------------
>
>
>
>
>
> ___________________________________________________________
> Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide
with voicemail http://uk.messenger.yahoo.com
>2006-03-01 by Mukund Deshmukh
Thanks for the mail. I am porting huge code from 8052 involving lots of port and bit variable. I just want to know how a pin/bit is defined in header file of LPC2138, so that rest of my 8051 code remains unchanged. In 8051 to set a bit we use P1_7=1; Best Regards, Mukund Deshmukh. Beta Computronics Pvt Ltd, 10/1, IT Park, Parsodi, Nagpur-440022 Cell - 9422113746
----- Original Message ----- From: "Guillermo Prandi" <yahoo.messenger@...> To: <lpc2000@yahoogroups.com> Sent: Wednesday, March 01, 2006 4:06 PM Subject: [lpc2000] Re: Bit addressing In LPC21xx, GPIO SET/CLR registers are designed so you don't need to read them in order to set/clear the corresponding GPIO bits: GPIO0_IOSET |= (1<<15); <---- Unnecesary read GPIO0_IOSET = (1<<15); <---- Changes (sets) only bit 15 GPIO0_IOSET = (1<<15)|(1<<4); <---- Changes (sets) bits 15 and 4 GPIO0_IOCLR = (1<<15); <---- Changes (clears) only bit 15 GPIO0_IOCLR = (1<<15)|(1<<4); <---- Changes (clears) bits 15 and 4
2006-03-01 by Alexey Bishletov
3:47:56 PM, Wednesday, March 1, 2006, Mukund wrote:
> Thanks for the mail.
> I am porting huge code from 8052 involving lots of port and bit variable.
> I just want to know how a pin/bit is defined in header file of LPC2138, so
> that rest of my 8051 code remains unchanged.
> In 8051 to set a bit we use
> P1_7=1;
typedef struct
{
unsigned long n0:1;
unsigned long n1:1;
unsigned long n2:1;
unsigned long n3:1;
unsigned long n4:1;
unsigned long n5:1;
unsigned long n6:1;
unsigned long n7:1;
} BITS32;
#define P1 (*((volatile BITS32 *) 0xE0028014))
#define P1_7 (P1.7)
WBR, Alex2006-03-01 by Richard Duits
Be carefull with bit fields larger then 8 bits, because they do not work the same on all compilers. Check you assembler listing to see if the compiler generates the code you expected. Richard. Alexey Bishletov wrote:
> 3:47:56 PM, Wednesday, March 1, 2006, Mukund wrote:
>
> > Thanks for the mail.
> > I am porting huge code from 8052 involving lots of port and bit
> variable.
> > I just want to know how a pin/bit is defined in header file of
> LPC2138, so
> > that rest of my 8051 code remains unchanged.
> > In 8051 to set a bit we use
> > P1_7=1;
>
> typedef struct
> {
> unsigned long n0:1;
> unsigned long n1:1;
> unsigned long n2:1;
> unsigned long n3:1;
> unsigned long n4:1;
> unsigned long n5:1;
> unsigned long n6:1;
> unsigned long n7:1;
> } BITS32;
> #define P1 (*((volatile BITS32 *) 0xE0028014))
>
> #define P1_7 (P1.7)
>
>
> WBR, Alex
>2006-03-01 by Robert Adsett
Quoting Alexey Bishletov <nita@...>:
> 3:47:56 PM, Wednesday, March 1, 2006, Mukund wrote:
>
>> Thanks for the mail.
>> I am porting huge code from 8052 involving lots of port and bit variable.
>> I just want to know how a pin/bit is defined in header file of LPC2138, so
>> that rest of my 8051 code remains unchanged.
>> In 8051 to set a bit we use
>> P1_7=1;
>
> typedef struct
> {
> unsigned long n0:1;
> unsigned long n1:1;
> unsigned long n2:1;
> unsigned long n3:1;
> unsigned long n4:1;
> unsigned long n5:1;
> unsigned long n6:1;
> unsigned long n7:1;
> } BITS32;
> #define P1 (*((volatile BITS32 *) 0xE0028014))
>
> #define P1_7 (P1.7)
>
>
> WBR, Alex
Not portable even between compilers. For non-I/O code this is just
fine but for
operations involving I/O this may produce unexpected results. IE the compiler
may produce perfectly valid code from the viewpoint of what the language is
specified to do but it may not actually work with the I/O.
In particular with this construct you could get a 8 bit I/O operation,
a 16 bit
I/O operation or a 32bit I/O operation.
Also if you have a different read and write register at the same
address you may
get really odd results.
Basically bitfields are a very bad idea for I/O. Sooner or later thay
will bite
you in the fundament.
Robert2006-03-01 by 42Bastian Schick
Robert Adsett schrieb: > In particular with this construct you could get a 8 bit I/O operation, > a 16 bit > I/O operation or a 32bit I/O operation. Correct. gcc tries to optimize accesses, so if you have a register which must be read/writen as 32bits, bitfields fail for this. Other compiler read/write the size of the container. For the PPC version exists a patch for 4.0.x gcc to change this. > Basically bitfields are a very bad idea for I/O. Sooner or later thay > will bite you in the fundament. Copy that. -- 42Bastian
2006-03-01 by Steve Franks
Hi,
First, I think this topic was hashed over a bit awhile back, you might
do a search of the archives for more info.
IAR uses the following in their include files that shipped with my
2148 demo board:
/* GPIO registers */
typedef struct {
__REG32 P0_0 :1;
__REG32 P0_1 :1;
__REG32 P0_2 :1;
__REG32 P0_3 :1;
__REG32 P0_4 :1;
__REG32 P0_5 :1;
__REG32 P0_6 :1;
__REG32 P0_7 :1;
__REG32 P0_8 :1;
__REG32 P0_9 :1;
__REG32 P0_10 :1;
__REG32 P0_11 :1;
__REG32 P0_12 :1;
__REG32 P0_13 :1;
__REG32 P0_14 :1;
__REG32 P0_15 :1;
__REG32 P0_16 :1;
__REG32 P0_17 :1;
__REG32 P0_18 :1;
__REG32 P0_19 :1;
__REG32 P0_20 :1;
__REG32 P0_21 :1;
__REG32 P0_22 :1;
__REG32 P0_23 :1;
__REG32 P0_24 :1;
__REG32 P0_25 :1;
__REG32 P0_26 :1;
__REG32 P0_27 :1;
__REG32 P0_28 :1;
__REG32 P0_29 :1;
__REG32 P0_30 :1;
__REG32 P0_31 :1;
} __gpio_bits;
Which is maybe what you're asking for; if IOCLR0 is declated of type
__gpio_bits in your headers, you can say IOCLR0.P0_12
Now there's a few reasons you might not want to do this, but that's
for the experts on this list to point out, cause I was never clear
about exactly what they were. Possibly issues with endian-ness and
the like...
Steve2006-03-01 by nagarkarajay
My 2 cents:
Mukund,
Unfortunately there is seperate control over set and clear of GPIO
in the LPC 2XXX .. my initial guess is that this is not slam dunk as
you would expect it to be. You might have to rummage through the
code to see if you are setting the bits or clearing it and then
modify that line as required.
Tedious and unfortunate ...
Ajay
--- In lpc2000@yahoogroups.com, Mukund Deshmukh <betacomp_ngp@...>
wrote:
>
> Thanks for the reply.
> As I am transferring my C51 source to Arm, I wanted something as
simple as
>
> Some_io_port_0.15=1
>
> So that I define only Some_io_port and my rest of source remains
same.
>
>
>
> Best Regards,
>
> Mukund Deshmukh.
> Beta Computronics Pvt Ltd,
> 10/1, IT Park, Parsodi,
> Nagpur-440022
> Cell - 9422113746
> ----- Original Message -----
> From: "Boris Králik" <kralikbo@...>
> To: <lpc2000@yahoogroups.com>
> Sent: Wednesday, March 01, 2006 12:46 PM
> Subject: Re: [lpc2000] Bit addressing
>
>
> > OH, sorry.
> > Port operations:
> > GPIO0_IOSET |= (1 << 15);//Write
> > 15_bit_of_port_0 = (PCB_PINSEL0 >> 15) & 0x1); //Read
> > --- Boris Králik <kralikbo@...> wrote:
> >
> > > var |= (1 << 5); //set 5 bit of variable var to 1
> > > (writing)
> > > if (var & (1 << 5)) //test 5 bit of var (reading)
> > >
> > > --- Mukund Deshmukh <betacomp_ngp@...>
> > > wrote:
> > >
> > > > Hi,
> > > > A stupid question...
> > > > I am used C51 and like bit addressing in 'C', but
> > > in
> > > > LPC its not possible.
> > > >
> > > > 1. Is there any way I can read or write a port bit
> > > > by simply writing /
> > > > reading 1/0 .
> > > >
> > > > Example for writing
> > > >
> > > > Some_bit_P0_15=1
> > > >
> > > >
> > > > or reading
> > > > if (Some_bit_P0_15) {}
> > > >
> > > >
> > > >
> > > > Best Regards,
> > > >
> > > > Mukund Deshmukh.
> > > > Beta Computronics Pvt Ltd,
> > > > 10/1, IT Park, Parsodi,
> > > > Nagpur-440022
> > > > Cell - 9422113746
> > > >
> > > >
> > >
> > >
> > > Regards / S pozdravom Boris Kralik
> > >
> > > http://www.geocities.com/kralikbo/
> > > -------------------------------------------------
> > >
> > >
> > >
> > >
> > ___________________________________________________________
> > >
> > > To help you stay safe and secure online, we've
> > > developed the all new Yahoo! Security Centre.
> > > http://uk.security.yahoo.com
> > >
> >
> >
> > Regards / S pozdravom Boris Kralik
> >
> > http://www.geocities.com/kralikbo/
> > -------------------------------------------------
> >
> >
> >
> >
> >
> > ___________________________________________________________
> > Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide
with> voicemail http://uk.messenger.yahoo.com > > > > > > > > Yahoo! Groups Links > > > > > > > > > > > > > > >
2006-03-01 by Alexey Bishletov
5:08:07 PM, Wednesday, March 1, 2006, Robert wrote:
>>> In 8051 to set a bit we use
>>> P1_7=1;
>> typedef struct
>> {
>> unsigned long n0:1;
>> unsigned long n1:1;
>> unsigned long n2:1;
>> unsigned long n3:1;
>> unsigned long n4:1;
>> unsigned long n5:1;
>> unsigned long n6:1;
>> unsigned long n7:1;
>> } BITS32;
>> #define P1 (*((volatile BITS32 *) 0xE0028014))
>>
>> #define P1_7 (P1.7)
>>
> Not portable even between compilers. For non-I/O code this is just
> fine but for
> operations involving I/O this may produce unexpected results. IE the compiler
> may produce perfectly valid code from the viewpoint of what the language is
> specified to do but it may not actually work with the I/O.
> In particular with this construct you could get a 8 bit I/O operation,
> a 16 bit
> I/O operation or a 32bit I/O operation.
I agree, it should be tested. IAR uses operations according to
bit field type, GCC shorten to byte. IAR acceptable.
> Also if you have a different read and write register at the same
> address you may
> get really odd results.
My variant uses the same register for read and write. It is possible
for LPC.
There is another solution. Use C++, create class "port" and overload
operator=(int) and int(port). But some overhead will be unavoidable.
> Basically bitfields are a very bad idea for I/O. Sooner or later thay
> will bite
> you in the fundament.
Why do you think so? Or is it so only with LPC?
WBR, Alex2006-03-01 by brendanmurphy37
This indeed came up a while ago.
To recap:
The reason bit-fields are a bad idea for hardware register access, is
that it is completely undefined in ANSI 'C' as to how they are mapped
to memory (which in turn is mapped to a hardware register). Bottom
line: it may work, or it may not.
Even if you verify that the complier is doing what you expect by
looking at the assembler output, it can change (an obvious change is
if you change the optimisation setting on the compiler, or move to a
new version of the compiler, or move to a new compiler, etc. etc.).
You're faced with having to check every time you do a change like
this. Fine if your happy to do this, but...
An exception to this is where particular copilier vendors (IAR?
Keil?) have provided some degree of built-in support, where they
essentially guarentee if you use the defined mechanism for accessing
hardware registers that it'll work OK.
A standard way of accessing (reliably) hardware registers, is
something like the following, which will work with any ANSI 'C'
compiler (given the correct type definition to get the right register
size):
/* define a 32-bit object */
typedef unsigned int uint32;
/* MACRO to access hardware registers: note the use of volatile to
avoid compiler optimising out the access */
#define REG(addr) (*(volatile unsigned uint32 *)(addr))
/* define the register address */
#define GPIO_IOSET0 (0xE0028004)
/* set a particular bit position */
REG(GPIO_IOSET0) = (1 << bit_position);
/* can also be used to read a particular bit(s) */
if (REG(GPIO_IOPIN0 & bit_pos))
{
/* bit set in here */
}
else
{
/* bit clear in here */
}
It's not clear whether the original questioner on this topic wanted
to maintain the same source code to run on both 8085 and LPC2000
(which will be tough, however it's done) or just to use it as a
starting point (a lot easier: some combination of global search and
replace and use of the pre-processor should do the trick).
Hope this helps.
Brendan2006-03-01 by brendanmurphy37
Before anyone points it out, the line: "if (REG(GPIO_IOPIN0 & bit_pos))" should be replaced with: "if (REG(GPIO_IOPIN0) & bit_pos)" Sorry about this Brendan --- In lpc2000@yahoogroups.com, "brendanmurphy37" <brendan.murphy@...> wrote: > > > This indeed came up a while ago. > > To recap: > > The reason bit-fields are a bad idea for hardware register access, is > that it is completely undefined in ANSI 'C' as to how they are mapped > to memory (which in turn is mapped to a hardware register). Bottom > line: it may work, or it may not. > > Even if you verify that the complier is doing what you expect by > looking at the assembler output, it can change (an obvious change is > if you change the optimisation setting on the compiler, or move to a > new version of the compiler, or move to a new compiler, etc. etc.). > You're faced with having to check every time you do a change like > this. Fine if your happy to do this, but... > > An exception to this is where particular copilier vendors (IAR? > Keil?) have provided some degree of built-in support, where they > essentially guarentee if you use the defined mechanism for accessing > hardware registers that it'll work OK. > > A standard way of accessing (reliably) hardware registers, is > something like the following, which will work with any ANSI 'C' > compiler (given the correct type definition to get the right register
> size):
>
> /* define a 32-bit object */
>
> typedef unsigned int uint32;
>
> /* MACRO to access hardware registers: note the use of volatile to
> avoid compiler optimising out the access */
>
> #define REG(addr) (*(volatile unsigned uint32 *)(addr))
>
> /* define the register address */
>
> #define GPIO_IOSET0 (0xE0028004)
>
> /* set a particular bit position */
>
> REG(GPIO_IOSET0) = (1 << bit_position);
>
> /* can also be used to read a particular bit(s) */
>
> if (REG(GPIO_IOPIN0 & bit_pos))
> {
> /* bit set in here */
> }
> else
> {
> /* bit clear in here */
> }
>
> It's not clear whether the original questioner on this topic wanted
> to maintain the same source code to run on both 8085 and LPC2000
> (which will be tough, however it's done) or just to use it as a
> starting point (a lot easier: some combination of global search and
> replace and use of the pre-processor should do the trick).
>
> Hope this helps.
>
> Brendan
>2006-03-01 by Paul Curtis
Hi, > There was an initiative to standardize a set of macros and library > routines for ISO C for Hardware access. I havn't heard of it in a > while though. There is a TR for Embedded C. It has an unweildy set of crappy macros. No wonder users have never heard of it, compiler vendors probably don't want anything to do with it. More odeous even than C99. > >> Basically bitfields are a very bad idea for I/O. Sooner > or later thay will bite you in the fundament. > > > > Why do you think so? Or is it so only with LPC? > > Nope, all processors. The issues off the top of my head are > - Bitfield order is implementation defined Correct. > - Bitfield write is necessarily an RMW sequence which is > invalid for a lot of hardware and non-atomic on a lot of > processors. Actually, some ARM processors are now becoming available with bit-level I/O to ports. I'm thinking here of the MAC7100 series and another that's coming up soon. Writing a one or a zero to a single bit in an I/O port simply becomes a 32-bit write to the bit-addressed register, and reading that register returns a 0/1 based on the bit in the port. You can write all 32 bits at a time too, if you need to. The MAC7100's I/O is actually pretty good, you can byte-write to part of the 32-bit port register and only affect those 8 bits... > - Access size is indeterminate. Certainly with language processors there is no need to define access characteristics IIRC. > - Bitfields default to signed. Yeah, just like plain "int" and mostly unlike plain "char". Consistency? ;-) -- Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk CrossWorks for MSP430, ARM, AVR and now MAXQ processors
2006-03-01 by Robert Adsett
Quoting Alexey Bishletov <nita@...>: > 5:08:07 PM, Wednesday, March 1, 2006, Robert wrote: >> Also if you have a different read and write register at the same >> address you may >> get really odd results. > > My variant uses the same register for read and write. It is possible > for LPC. Sorry I don't understand this. This is a general issue using any sort of Read-modify-write sequence when you have hardware that maps a ready-only register and a write only register to the same address. Bit fields are almost always implemented as RMW sequences and so in that case you will not be doing what you expected to do. > There is another solution. Use C++, create class "port" and overload > operator=(int) and int(port). But some overhead will be unavoidable. There was an initiative to standardize a set of macros and library routines for ISO C for Hardware access. I havn't heard of it in a while though. >> Basically bitfields are a very bad idea for I/O. Sooner or later thay >> will bite >> you in the fundament. > > Why do you think so? Or is it so only with LPC? Nope, all processors. The issues off the top of my head are - Bitfield order is implementation defined - Bitfield write is necessarily an RMW sequence which is invalid for a lot of hardware and non-atomic on a lot of processors. - Access size is indeterminate. - Bitfields default to signed. Worse some of this may change depending on optimization conditions. And the compiler vendor is quite free to change this from version to version. Now if the compiler vendor is using this for their own defined headers there is a reasonable chance that it will remain valid (although I have seen vendors change similar details on a major upgrade). You are though locked into your particular vendor at that point. I've also found building and maintaining bifield structures to be far more painful than the alternatives. The only thing bitfields are good for is saving memory in internal data structures, where everything except the signedness is irrelevant. Robert
2006-03-01 by Robert Adsett
Quoting Paul Curtis <plc@...>: > Hi, > >> There was an initiative to standardize a set of macros and library >> routines for ISO C for Hardware access. I havn't heard of it in a >> while though. > > There is a TR for Embedded C. It has an unweildy set of crappy macros. > No wonder users have never heard of it, compiler vendors probably don't > want anything to do with it. More odeous even than C99. That's probably what I was remembering. >> - Bitfield write is necessarily an RMW sequence which is >> invalid for a lot of hardware and non-atomic on a lot of >> processors. > > Actually, some ARM processors are now becoming available with bit-level > I/O to ports. I'm thinking here of the MAC7100 series and another > that's coming up soon. Writing a one or a zero to a single bit in an > I/O port simply becomes a 32-bit write to the bit-addressed register, > and reading that register returns a 0/1 based on the bit in the port. > You can write all 32 bits at a time too, if you need to. So that would be a register per bit? 32 registers to deal with a full 32bit I/O port (plus presumably another register for full access)? Robert
2006-03-02 by Mukund Deshmukh
Thanks. Yes this is what I was looking for. Can you send me header files for LPC2138, 2148, or link. Could you care to explain in details, with disadvantage. Best Regards, Mukund Deshmukh. Beta Computronics Pvt Ltd, 10/1, IT Park, Parsodi, Nagpur-440022 Cell - 9422113746 ----- Original Message -----
From: "Steve Franks" <stevefranks@...>
To: <lpc2000@yahoogroups.com>
Sent: Wednesday, March 01, 2006 10:07 PM
Subject: [lpc2000] Re: Bit addressing
> Hi,
>
> First, I think this topic was hashed over a bit awhile back, you might
> do a search of the archives for more info.
>
> IAR uses the following in their include files that shipped with my
> 2148 demo board:
>
> /* GPIO registers */
> typedef struct {
> __REG32 P0_0 :1;
> __REG32 P0_1 :1;
> __REG32 P0_2 :1;
> __REG32 P0_3 :1;2006-03-02 by pitstock_kiwi
Bit addressing can be a lot simpler than all the stuff I have seen so
far.
Firstly the LPC214X.H is missing the byte access registers. Why write
32 bit address unless you need to? Also why use the old (slower)
legacy port IO? FAST IO should be the standard from what I see.
Use this line to turn on your fast ports unless you have some reason
to use the old stuff.
SCS |= 0x00000003; // enable FIQ on port 0 and 1
I have an led on port 0.20 so heres the initialisation for it
// LED on port 0.20, 0x10
FIO0DIR2 |= 0x10; // Led pin as output
FIO0MASK2 |= ~0x10; // Led masked for use
FIO0SET2 |= 0x10; // turn on led
And heres how I toggle the port
if (FIO0PIN2 & 0x10){ // if led is on Same as if (P0_20 == 1)
FIO0CLR2 |= 0x10;} // turn off led. Same as P0_20 = 0;
else{
FIO0SET2 |= 0x10;} // turn on led Same as P0_20 =1;
Because we have masked only one bit it could be even simpler if we
want
FIO0SET2 = 0xFF; // turn on led
FIO0CLR2 = 0x00; // turn off led
Hope this helps
Kiwi Keith
Heres what I added to the LPC214X.H so I could byte access the port
as the UM10139_1.pdf mentioned
// ******************* LPC214X.H ***********************************
// Added by Keith
#define FIO0DIRL (*((volatile unsigned int *) 0x3FFFC000))//
0 - 15
#define FIO0DIRU (*((volatile unsigned int *) 0x3FFFC002))//
16 - 31
#define FIO0DIR0 (*((volatile unsigned char *) 0x3FFFC000))//
0 - 7
#define FIO0DIR1 (*((volatile unsigned char *) 0x3FFFC001))//
8 - 15
#define FIO0DIR2 (*((volatile unsigned char *) 0x3FFFC002))//
15 - 23
#define FIO0DIR3 (*((volatile unsigned char *) 0x3FFFC003))//
24 - 31
// End: Added by Keith
#define FIO0MASK (*((volatile unsigned long *) 0x3FFFC010))
// Added by Keith
#define FIO0MASKL (*((volatile unsigned int *) 0x3FFFC010))//
0 - 15
#define FIO0MASKU (*((volatile unsigned int *) 0x3FFFC012))//
16 - 31
#define FIO0MASK0 (*((volatile unsigned char *) 0x3FFFC010))//
0 - 7
#define FIO0MASK1 (*((volatile unsigned char *) 0x3FFFC011))//
8 - 15
#define FIO0MASK2 (*((volatile unsigned char *) 0x3FFFC012))//
15 - 23
#define FIO0MASK3 (*((volatile unsigned char *) 0x3FFFC013))//
24 - 31
// End: Added by Keith
#define FIO0PIN (*((volatile unsigned long *) 0x3FFFC014))
// Added by Keith
#define FIO0PINL (*((volatile unsigned int *) 0x3FFFC014))//
0 - 15
#define FIO0PINU (*((volatile unsigned int *) 0x3FFFC016))//
16 - 31
#define FIO0PIN0 (*((volatile unsigned char *) 0x3FFFC014))//
0 - 7
#define FIO0PIN1 (*((volatile unsigned char *) 0x3FFFC015))//
8 - 15
#define FIO0PIN2 (*((volatile unsigned char *) 0x3FFFC016))//
15 - 23
#define FIO0PIN3 (*((volatile unsigned char *) 0x3FFFC017))//
24 - 31
// End: Added by Keith
#define FIO0SET (*((volatile unsigned long *) 0x3FFFC018))
// Added by Keith
#define FIO0SETL (*((volatile unsigned int *) 0x3FFFC018))//
0 - 15
#define FIO0SETU (*((volatile unsigned int *) 0x3FFFC01A))//
16 - 31
#define FIO0SET0 (*((volatile unsigned char *) 0x3FFFC018))//
0 - 7
#define FIO0SET1 (*((volatile unsigned char *) 0x3FFFC019))//
8 - 15
#define FIO0SET2 (*((volatile unsigned char *) 0x3FFFC01A))//
15 - 23
#define FIO0SET3 (*((volatile unsigned char *) 0x3FFFC01B))//
24 - 31
// End: Added by Keith
#define FIO0CLR (*((volatile unsigned long *) 0x3FFFC01C))
// Added by Keith
#define FIO0CLRL (*((volatile unsigned int *) 0x3FFFC01C))//
0 - 15
#define FIO0CLRU (*((volatile unsigned int *) 0x3FFFC01E))//
16 - 31
#define FIO0CLR0 (*((volatile unsigned char *) 0x3FFFC01C))//
0 - 7
#define FIO0CLR1 (*((volatile unsigned char *) 0x3FFFC01D))//
8 - 15
#define FIO0CLR2 (*((volatile unsigned char *) 0x3FFFC01E))//
15 - 23
#define FIO0CLR3 (*((volatile unsigned char *) 0x3FFFC01F))//
24 - 31
// End: Added by Keith
// SCS |= 0x00000002; // enable FIQ on port 1
#define FIO1DIR (*((volatile unsigned long *) 0x3FFFC020))
// Added by Keith
#define FIO1DIRL (*((volatile unsigned int *) 0x3FFFC020))//
0 - 15
#define FIO1DIRU (*((volatile unsigned int *) 0x3FFFC022))//
16 - 31
#define FIO1DIR0 (*((volatile unsigned char *) 0x3FFFC020))//
0 - 7
#define FIO1DIR1 (*((volatile unsigned char *) 0x3FFFC021))//
8 - 15
#define FIO1DIR2 (*((volatile unsigned char *) 0x3FFFC022))//
15 - 23
#define FIO1DIR3 (*((volatile unsigned char *) 0x3FFFC023))//
24 - 31
// End: Added by Keith
#define FIO1MASK (*((volatile unsigned long *) 0x3FFFC030))
// Added by Keith
#define FIO1MASKL (*((volatile unsigned int *) 0x3FFFC030))//
0 - 15
#define FIO1MASKU (*((volatile unsigned int *) 0x3FFFC032))//
16 - 31
#define FIO1MASK0 (*((volatile unsigned char *) 0x3FFFC030))//
0 - 7
#define FIO1MASK1 (*((volatile unsigned char *) 0x3FFFC031))//
8 - 15
#define FIO1MASK2 (*((volatile unsigned char *) 0x3FFFC032))//
15 - 23
#define FIO1MASK3 (*((volatile unsigned char *) 0x3FFFC033))//
24 - 31
// End: Added by Keith
#define FIO1PIN (*((volatile unsigned long *) 0x3FFFC034))
// Added by Keith
#define FIO1PINL (*((volatile unsigned int *) 0x3FFFC034))//
0 - 15
#define FIO1PINU (*((volatile unsigned int *) 0x3FFFC036))//
16 - 31
#define FIO1PIN0 (*((volatile unsigned char *) 0x3FFFC034))//
0 - 7
#define FIO1PIN1 (*((volatile unsigned char *) 0x3FFFC035))//
8 - 15
#define FIO1PIN2 (*((volatile unsigned char *) 0x3FFFC036))//
15 - 23
#define FIO1PIN3 (*((volatile unsigned char *) 0x3FFFC037))//
24 - 31
// End: Added by Keith
#define FIO1SET (*((volatile unsigned long *) 0x3FFFC038))
// Added by Keith
#define FIO1SETL (*((volatile unsigned int *) 0x3FFFC038))//
0 - 15
#define FIO1SETU (*((volatile unsigned int *) 0x3FFFC03A))//
16 - 31
#define FIO1SET0 (*((volatile unsigned char *) 0x3FFFC038))//
0 - 7
#define FIO1SET1 (*((volatile unsigned char *) 0x3FFFC039))//
8 - 15
#define FIO1SET2 (*((volatile unsigned char *) 0x3FFFC03A))//
15 - 23
#define FIO1SET3 (*((volatile unsigned char *) 0x3FFFC03B))//
24 - 31
// End: Added by Keith
#define FIO1CLR (*((volatile unsigned long *) 0x3FFFC03C))
// Added by Keith
#define FIO1CLRL (*((volatile unsigned int *) 0x3FFFC03C))//
0 - 15
#define FIO1CLRU (*((volatile unsigned int *) 0x3FFFC03E))//
16 - 31
#define FIO1CLR0 (*((volatile unsigned char *) 0x3FFFC03C))//
0 - 7
#define FIO1CLR1 (*((volatile unsigned char *) 0x3FFFC03D))//
8 - 15
#define FIO1CLR2 (*((volatile unsigned char *) 0x3FFFC03E))//
15 - 23
#define FIO1CLR3 (*((volatile unsigned char *) 0x3FFFC03F))//
24 - 31
// End: Added by Keith2006-03-02 by Mukund Deshmukh
Actually the code is quite big, and I was looking for shortcut.. Best Regards, Mukund Deshmukh. Beta Computronics Pvt Ltd, 10/1, IT Park, Parsodi, Nagpur-440022 Cell - 9422113746
----- Original Message ----- From: "nagarkarajay" <nagarkarajay@...> To: <lpc2000@yahoogroups.com> Sent: Wednesday, March 01, 2006 10:11 PM Subject: [lpc2000] Re: Bit addressing My 2 cents: Mukund, Unfortunately there is seperate control over set and clear of GPIO in the LPC 2XXX .. my initial guess is that this is not slam dunk as you would expect it to be. You might have to rummage through the code to see if you are setting the bits or clearing it and then modify that line as required. Tedious and unfortunate ...
2006-03-02 by brendanmurphy37
--- In lpc2000@yahoogroups.com, "pitstock_kiwi" <keith@...> wrote:
>
>
> Bit addressing can be a lot simpler than all the stuff I have seen
so
> far.
>
> Firstly the LPC214X.H is missing the byte access registers. Why
write
> 32 bit address unless you need to? Also why use the old (slower)
> legacy port IO? FAST IO should be the standard from what I see.
>
> Use this line to turn on your fast ports unless you have some
reason
> to use the old stuff.
> SCS |= 0x00000003; // enable FIQ on port 0 and 1
>
> I have an led on port 0.20 so heres the initialisation for it
>
> // LED on port 0.20, 0x10
> FIO0DIR2 |= 0x10; // Led pin as output
> FIO0MASK2 |= ~0x10; // Led masked for use
> FIO0SET2 |= 0x10; // turn on led
>
> And heres how I toggle the port
>
> if (FIO0PIN2 & 0x10){ // if led is on Same as if (P0_20 == 1)
> FIO0CLR2 |= 0x10;} // turn off led. Same as P0_20 = 0;
> else{
> FIO0SET2 |= 0x10;} // turn on led Same as P0_20 =1;
>
> Because we have masked only one bit it could be even simpler if we
> want
> FIO0SET2 = 0xFF; // turn on led
> FIO0CLR2 = 0x00; // turn off led
>
> Hope this helps
> Kiwi Keith
>
>
> Heres what I added to the LPC214X.H so I could byte access the
port
> as the UM10139_1.pdf mentioned
>
This is indeed a simpler approach than the version I posted.
The version I use has the advantage of being able to use the same
include file (for register definitions) for both assembler and 'C':
the MACRO is used to get the "volatile" and type correct. It's a
fairly minor advantage, though: the clarity of the above version is
probably preferable.
On your other points, most hardware registers on the LPC2000 series
are 32-bit wide as far as I know. In any case, even if they're not,
there's no advantage (that I'm aware of) to accessing them as bytes.
Finally, I used the "old style" I/O port access simply because that
was the example I had to hand. As others have pointed out, they have
certain advantages (no need for read/modify/write), but you clearly
you should use whatever's easiest/most suitable.
Brendan2006-03-02 by brendanmurphy37
Mukund, You should be aware that if you take this approach, you are essentially committing yourself to a particular compiler vendor, as the approach is non-portable. It's fine if this isn't an issue for you, or if the advantage of being closer to your current code is more important to you. See recent message posts on the topic for more details. Brendan --- In lpc2000@yahoogroups.com, Mukund Deshmukh <betacomp_ngp@...> wrote: > > Thanks. > Yes this is what I was looking for. > > Can you send me header files for LPC2138, 2148, or link. > Could you care to explain in details, with disadvantage. > > Best Regards, > > Mukund Deshmukh. > Beta Computronics Pvt Ltd, > 10/1, IT Park, Parsodi, > Nagpur-440022 > Cell - 9422113746 > ----- Original Message ----- > From: "Steve Franks" <stevefranks@...> > To: <lpc2000@yahoogroups.com> > Sent: Wednesday, March 01, 2006 10:07 PM > Subject: [lpc2000] Re: Bit addressing > > > > Hi, > > > > First, I think this topic was hashed over a bit awhile back, you might > > do a search of the archives for more info. > > > > IAR uses the following in their include files that shipped with my
> > 2148 demo board:
> >
> > /* GPIO registers */
> > typedef struct {
> > __REG32 P0_0 :1;
> > __REG32 P0_1 :1;
> > __REG32 P0_2 :1;
> > __REG32 P0_3 :1;
>