Yahoo Groups archive
Thread
2005-11-09 by szemzoandras
Hello,
Is it possible to place a variable to a fixed memory location in gcc,
like in keil, i mean:
unsigned int dd _at_ 0x81000000;
Or I can only do it with separate section in linker script?
__attribute__ ((section (".ysection")))
and
-Wl,--section-start=.mysection=0x81000000
thanks
Andrew2005-11-09 by Gromann, Klaus
Sure, no problem the best way is to use a macro instead of a variable : i.e.: definition : #define fix_adr (*(volatile unsigned long *)0xe0000000) code : fix_adr = something_else; best regards Klaus
-----Original Message-----
From: lpc2000@yahoogroups.com [mailto:lpc2000@yahoogroups.com] On Behalf
Of szemzoandras
Sent: Wednesday, November 09, 2005 3:15 PM
To: lpc2000@yahoogroups.com
Subject: [lpc2000] fixed address variable
Hello,
Is it possible to place a variable to a fixed memory location in gcc,
like in keil, i mean:
unsigned int dd _at_ 0x81000000;
Or I can only do it with separate section in linker script?
__attribute__ ((section (".ysection")))
and
-Wl,--section-start=.mysection=0x81000000
thanks
Andrew
Yahoo! Groups Links2005-11-09 by Tom Walsh
szemzoandras wrote:
>Hello,
>
>
>Is it possible to place a variable to a fixed memory location in gcc,
>like in keil, i mean:
>
>unsigned int dd _at_ 0x81000000;
>
>
>
unsigned int * dd = ((unsigned int *)0x81000000);
*dd = <value>
--
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net, http://cyberiansoftware.com
"Windows? No thanks, I have work to do..."
----------------------------------------------------2005-11-09 by Tom Walsh
szemzoandras wrote: >Hello, > > >Is it possible to place a variable to a fixed memory location in gcc, >like in keil, i mean: > >unsigned int dd _at_ 0x81000000; > > > > FWIW, I wonder why Keil added an extension to their C compiler? I've been using "int * dd = ((unsigned int *)0x81000000)" for many many years. Not only with gcc, but other compilers as well. TomW -- Tom Walsh - WN3L - Embedded Systems Consultant http://openhardware.net, http://cyberiansoftware.com "Windows? No thanks, I have work to do..." ----------------------------------------------------
2005-11-09 by Richard
While we have not done exactly that type of extensions to our compiler, usually requests like this come down to being able to declare multiple vars at consecutive locations (usually some sort of checksum and copyright message) or shared memory port... I do usually steer users to solutions similar to the one you suggested though. Much cleaner IMHO. At 08:26 AM 11/9/2005, Tom Walsh wrote: >szemzoandras wrote: > > >Hello, > > > > > >Is it possible to place a variable to a fixed memory location in gcc, > >like in keil, i mean: > > > >unsigned int dd _at_ 0x81000000; > > > > > > > > >FWIW, I wonder why Keil added an extension to their C compiler? I've >been using "int * dd = ((unsigned int *)0x81000000)" for many many >years. Not only with gcc, but other compilers as well. > >TomW // richard (This email is for mailing lists. To reach me directly, please use richard at imagecraft.com)
2005-11-09 by Charles Manning
On Thursday 10 November 2005 05:26, Tom Walsh wrote: > szemzoandras wrote: > >Hello, > > > > > >Is it possible to place a variable to a fixed memory location in gcc, > >like in keil, i mean: > > > >unsigned int dd _at_ 0x81000000; > > FWIW, I wonder why Keil added an extension to their C compiler? I've > been using "int * dd = ((unsigned int *)0x81000000)" for many many > years. Not only with gcc, but other compilers as well. There is a difference. When you do something like: unsigned int dd _at_ 0x810000; often the linker will check for overlaps etc. Depends on the compiler/linker though. Also, you need to look at the their offerings to understand it. Their older compilers (8051 etc) had this feature and so did PLM (now that was a fantastic language for 8051s)! They don't want to make their newer compilers seem less capable. When you do int * dd = ((unsigned int *)0x81000000 you're bypassing everything. That's probably fine for accessing hard locations like peripherals etc. IMHO, using extensions is a very bad thing. It was OK in the days of 8-bitters where "C" code was just a C representation of assembly and code was very non-portable. With most code though, you need portability. Heck I still use code I first wrote 15 years ago and have been dragging from project to project. Using any non-standard things breaks portability. I prefer to not do any of this sort of thing (except for hardware-specified stuff like peripherals) and instead use linker scripts to do any placement.
2005-11-09 by Tom Walsh
Charles Manning wrote: >On Thursday 10 November 2005 05:26, Tom Walsh wrote: > > >>szemzoandras wrote: >> >> >>>Hello, >>> >>> >>>Is it possible to place a variable to a fixed memory location in gcc, >>>like in keil, i mean: >>> >>>unsigned int dd _at_ 0x81000000; >>> >>> >>FWIW, I wonder why Keil added an extension to their C compiler? I've >>been using "int * dd = ((unsigned int *)0x81000000)" for many many >>years. Not only with gcc, but other compilers as well. >> >> > >There is a difference. > >When you do something like: >unsigned int dd _at_ 0x810000; > >often the linker will check for overlaps etc. Depends on the compiler/linker >though. > >Also, you need to look at the their offerings to understand it. Their older >compilers (8051 etc) had this feature and so did PLM (now that was a >fantastic language for 8051s)! They don't want to make their newer compilers >seem less capable. > >When you do >int * dd = ((unsigned int *)0x81000000 >you're bypassing everything. That's probably fine for accessing hard locations >like peripherals etc. > >IMHO, using extensions is a very bad thing. It was OK in the days of 8-bitters >where "C" code was just a C representation of assembly and code was very >non-portable. With most code though, you need portability. Heck I still use >code I first wrote 15 years ago and have been dragging from project to >project. Using any non-standard things breaks portability. > >I prefer to not do any of this sort of thing (except for hardware-specified >stuff like peripherals) and instead use linker scripts to do any placement. > > > Yeah, like trying to get portability between Intel 8051 vs. Archemedes v3 vs Archemedes v4 compilers: it just ain't gonna happen! Each dev system had its own funny little linker rules, bit access functions, C language extensions and assembly language file structure. Each to deal in some weird way with code acess vs ram access. ARM and gcc is so much simpler. Linear address space and ANSI C. TomW -- Tom Walsh - WN3L - Embedded Systems Consultant http://openhardware.net, http://cyberiansoftware.com "Windows? No thanks, I have work to do..." ----------------------------------------------------
2005-11-10 by szemzoandras
Hi,
First, sorry for long mail.
Thanks everybody for reply.
Yes, I know I can address fixed address like:
unsigned int *a = (void * )0x81000000;
*a = 0x11223344;
or
#define something (*((volatile unsigned long *) 0x81000000))
Ok, I have 2 problems.
I would like to convert my 320x240 GLCD routines to work with
framebuffer, because sed1335 not a fast IC.
I need 2 buffer 9600byte each, in the external space of Lpc2292.
One buffer where I write lines, pix etc, other that store the actual
picture, what is on the GLCD. Then I only copy the CHANGED bytes.
Is this ok?
So, how may I declare and use that 2 9600byte arrays in external ram?
My second problem. Here is a little prog:
unsigned int *a = (void * )0x81000000;
*a = 0x11223344;
unsigned int *b = (void * )0x81000004;
*b = 0x55667788;
printf("Memory0.4: %x\r\n",*a);
printf("Memory4.4: %x\r\n",*b);
unsigned char *ss = (void*)0x81000001;
printf("Memory1.1: %x\r\n",*ss);
printf("Memory0.4: %x\r\n",*a);
ss = (void*)0x81000002;
printf("Memory2.1: %x\r\n",*ss);
ss = (void*)0x81000003;
printf("Memory3.1: %x\r\n",*ss);
*ss = 0x99;
printf("Memory3.1ch: %x\r\n",*ss);
printf("Memory0.4: %x\r\n",*a);
ss = (void*)0x81000003;
*ss = 0x77;
printf("Memory0.4: %x\r\n",*a);
ss = (void*)0x81000000;
*ss = 0x88;
printf("Memory0.1ch: %x\r\n",*ss);
printf("Memory0.4: %x\r\n",*a);
And here is the output:
Memory0.4: 11223344
Memory4.4: 55667788
Memory1.1: 33
Memory0.4: 11223344
Memory2.1: 22
Memory3.1: 11
Memory3.1ch: 99
Memory0.4: 99223344
Memory0.4: 77223344
Memory0.1ch: 88
Memory0.4: 77223344
Why can I change the 1-3 byte of a 32bit location, but not the 0.?
Thanks.
Andrew2005-11-10 by Sten
szemzoandras wrote:
> Hi,
>
> First, sorry for long mail.
>
> Thanks everybody for reply.
>
> Yes, I know I can address fixed address like:
> unsigned int *a = (void * )0x81000000;
> *a = 0x11223344;
>
> or
> #define something (*((volatile unsigned long *) 0x81000000))
>
> Ok, I have 2 problems.
> I would like to convert my 320x240 GLCD routines to work with
> framebuffer, because sed1335 not a fast IC.
> I need 2 buffer 9600byte each, in the external space of Lpc2292.
> One buffer where I write lines, pix etc, other that store the actual
> picture, what is on the GLCD. Then I only copy the CHANGED bytes.
> Is this ok?
> So, how may I declare and use that 2 9600byte arrays in external ram?
>
> My second problem. Here is a little prog:
> unsigned int *a = (void * )0x81000000;
>
> *a = 0x11223344;
> unsigned int *b = (void * )0x81000004;
> *b = 0x55667788;
> printf("Memory0.4: %x\r\n",*a);
> printf("Memory4.4: %x\r\n",*b);
> unsigned char *ss = (void*)0x81000001;
> printf("Memory1.1: %x\r\n",*ss);
> printf("Memory0.4: %x\r\n",*a);
> ss = (void*)0x81000002;
> printf("Memory2.1: %x\r\n",*ss);
> ss = (void*)0x81000003;
> printf("Memory3.1: %x\r\n",*ss);
> *ss = 0x99;
> printf("Memory3.1ch: %x\r\n",*ss);
> printf("Memory0.4: %x\r\n",*a);
> ss = (void*)0x81000003;
> *ss = 0x77;
> printf("Memory0.4: %x\r\n",*a);
> ss = (void*)0x81000000;
> *ss = 0x88;
> printf("Memory0.1ch: %x\r\n",*ss);
> printf("Memory0.4: %x\r\n",*a);
>
> And here is the output:
>
> Memory0.4: 11223344
> Memory4.4: 55667788
> Memory1.1: 33
> Memory0.4: 11223344
> Memory2.1: 22
> Memory3.1: 11
> Memory3.1ch: 99
> Memory0.4: 99223344
> Memory0.4: 77223344
> Memory0.1ch: 88
> Memory0.4: 77223344
>
> Why can I change the 1-3 byte of a 32bit location, but not the 0.?
>
> Thanks.
> Andrew
>
Mmmmh... It looks strange. What kind of hardware or memory is located at
0x81000000?
Sten
--
/************************************************
Do you need a tiny and efficient real time
operating system (RTOS) with a preemtive
multitasking for LPC2000 or AT91SAM7?
http://nanortos.net-attack.de/
Or some open-source tools and code for LPC2000?
http://www.net-attack.de/
************************************************/2005-11-10 by derbaier
--- In lpc2000@yahoogroups.com, Sten <list@n...> wrote: > > Mmmmh... It looks strange. What kind of hardware or memory is located at > 0x81000000? > > Sten > > -- For one thing, you can have external RAM there on an LPC2292. I have an Embest card set up that way. -- Dave
2005-11-10 by Sten
derbaier wrote: > --- In lpc2000@yahoogroups.com, Sten <list@n...> wrote: > > >>Mmmmh... It looks strange. What kind of hardware or memory is located at >>0x81000000? >> >> Sten >> >>-- > > For one thing, you can have external RAM there on an LPC2292. > I have an Embest card set up that way. > > -- Dave > Yes, but it look like that this byte is write-once. I can't see any mistake too. Sten -- /************************************************ Do you need a tiny and efficient real time operating system (RTOS) with a preemtive multitasking for LPC2000 or AT91SAM7? http://nanortos.net-attack.de/ Or some open-source tools and code for LPC2000? http://www.net-attack.de/ ************************************************/
2005-11-10 by derbaier
--- In lpc2000@yahoogroups.com, Sten <list@n...> wrote: > > derbaier wrote: > > --- In lpc2000@yahoogroups.com, Sten <list@n...> wrote: > > > > > >>Mmmmh... It looks strange. What kind of hardware or memory is located at > >>0x81000000? > >> > >> Sten > >> > >>-- > > > > For one thing, you can have external RAM there on an LPC2292. > > I have an Embest card set up that way. > > > > -- Dave > > > > Yes, but it look like that this byte is write-once. I can't see any > mistake too. > > Sten > OOPS! Sorry that I just looked at your question without refering to the code that you were asking about! Now I am at a loss for an explanation. -- Dave
2005-11-11 by Robert Adsett
At 07:23 AM 11/10/05 +0000, szemzoandras wrote:
>My second problem. Here is a little prog:
>unsigned int *a = (void * )0x81000000;
>
> *a = 0x11223344;
> unsigned int *b = (void * )0x81000004;
> *b = 0x55667788;
> printf("Memory0.4: %x\r\n",*a);
====> a first dereferenced here ^^.
> printf("Memory4.4: %x\r\n",*b);
> unsigned char *ss = (void*)0x81000001;
> printf("Memory1.1: %x\r\n",*ss);
> printf("Memory0.4: %x\r\n",*a);
> ss = (void*)0x81000002;
> printf("Memory2.1: %x\r\n",*ss);
> ss = (void*)0x81000003;
> printf("Memory3.1: %x\r\n",*ss);
> *ss = 0x99;
> printf("Memory3.1ch: %x\r\n",*ss);
> printf("Memory0.4: %x\r\n",*a);
> ss = (void*)0x81000003;
> *ss = 0x77;
> printf("Memory0.4: %x\r\n",*a);
> ss = (void*)0x81000000;
> *ss = 0x88;
> printf("Memory0.1ch: %x\r\n",*ss);
> printf("Memory0.4: %x\r\n",*a);
>
>And here is the output:
>
>Memory0.4: 11223344
>Memory4.4: 55667788
>Memory1.1: 33
>Memory0.4: 11223344
>Memory2.1: 22
>Memory3.1: 11
>Memory3.1ch: 99
>Memory0.4: 99223344
>Memory0.4: 77223344
>Memory0.1ch: 88
>Memory0.4: 77223344
>
>Why can I change the 1-3 byte of a 32bit location, but not the 0.?
I suspect the one word answer is aliasing. You have two pointers a and ss
pointing to the same area and the value read from dereferencing a at the
line noted above is simply kept in a register until needed. Since it is
re-used so many times that makes it quite a worthwhile optimization. And
before anyone asks that is not a compiler bug.
Two ways of fixing it
1) the best way is don't alias. Sometimes it may be necessary
although I've not run across a case where it caused anything other than
confusion when in a single block of code like this.
2) qualify the pointer location as volatile so that read and write
access's are forced to occur every time. Not a good general solution since
it forces unnecessary access to work around what is essentially a bug in
the code. Might be needed if the alias is buried deep in existing code though.
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/