RE: [avr-gcc-list] introducing a new section in data memory
> -Original Message- > From: Georg-Johann Lay [mailto:a...@gjlay.de] > Sent: Friday, February 20, 2009 4:05 PM > To: Weddington, Eric > Cc: partha_nay...@yahoo.com; avr-gcc-list > Subject: Re: [avr-gcc-list] introducing a new section in data memory > > Weddington, Eric schrieb: > > The trouble might return if .data/.bss will grow and then overlap(s) > with .test section again. The problem is that you cannot > introduce holes > in a section, i.e. start with .data, reserve a hole of 0x100 (or put > .stuff in it) and then proceed with .data. Therefore, there may be a > waste of RAM of up to 0xff bytes. > > The only safe way to do this is > -- supplying own linker script that introduces alignment as needed. > -- supplying own linker script that introduces sections .data.lo at > 0x60, .test at 0x100, .data.hi at 0x200. But depending on the > size of .data, you will have to split .bss instead and explicitely > say that has to go in the .data fragments. Not nice. > -- or allocate 0x1ff bytes and compute the effective address > at runtime. > But then you must access indirect through a pointer. > -- Maybe it's best to take the space from the top of RAM. > Then you will > waste just 0x60 bytes (or can put some other stuff there), and you > can use direct addressing if you prefer or need that. > Yust init the > stach pointer to an other value by means of -minit-stack > from command > line or simply by __builtin_alloca (0x160) resp. auto char > test_buffer[0x160] upon entering main(). Agreed, on all of the above. I was just merely testing that the toolchain was not giving some weird error, and that, in theory, it could be done. > > Just realize that because your variable is now in the .test > section, don't expect the toolchain to automatically > initialize the variable to zeros in the future. It may do > that now, but the toolchain will change to not include the > __do_clear_bss if it detects that there is nothing in the > .bss section. The variable is now outside the .bss, so there > are no guarantees that it will be initialized to a known > value (zeros) in the startup code. > > This can be fixed by renaming the section to .bss.test, as far as you > refer to > http://lists.gnu.org/archive/html/avr-gcc-list/2009-01/msg00162.html > But note that the linker assumes one monolithic section, and > resp. does > the code in __do_clear_bss resp. __do_copy_data! Hmm. If the OP puts it into .bss.test, that may work for the clearing code in the startup, but then you may not be able to relocate that section with just a command line switch. My guess is that you will have to use a custom linker script. > Also nothe that there are some bugs in the patch cited above. Such as? It works well for most purposes AFIACT. > I will fix them as soon I will find the time for it. Thanks. > By the way, what is the specification for the handling of orphans? > Seems as if they are assumed to be adopted by .data? Could you be more specific? ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] introducing a new section in data memory
Weddington, Eric schrieb:
-Original Message-
From:
avr-gcc-list-bounces+eweddington=cso.atmel@nongnu.org
[mailto:avr-gcc-list-bounces+eweddington=cso.atmel@nongnu.
org] On Behalf Of Parthasaradhi Nayani
Sent: Thursday, February 19, 2009 11:37 AM
To: avr-gcc-list
Subject: [avr-gcc-list] introducing a new section in data memory
Hello all,
I needed to create a buffer of 256 bytes starting at a page
boundary (xx00) in the RAM memory (Mega8).
I added this line in the makefile
LDFLAGs = -wl,--section-start=.test=0x800200
and defined a variable in the .C file (shown below)
unsigned char mem3 __attribute__ ((section(".test")));
However variable mem3 is being assigned address 0x60 in the
controller???
also if I define another global in next line to mem3 I get
error that .data and .bss overlap lma 0xa0??
I am of the opinion that all variable defined with attribute
.test will be located in that memory area and all other
global variables will be located in their native memory.
Perhaps if I ma able locate the .test section properly the
overlap error may vanish. Can you correct the problem please?
Thank you.
It works for me.
See attached demo. After the build look at the .map file and the disassembly
file (.dis).
Hi. Without having read all this thread...
The trouble might return if .data/.bss will grow and then overlap(s)
with .test section again. The problem is that you cannot introduce holes
in a section, i.e. start with .data, reserve a hole of 0x100 (or put
.stuff in it) and then proceed with .data. Therefore, there may be a
waste of RAM of up to 0xff bytes.
The only safe way to do this is
-- supplying own linker script that introduces alignment as needed.
-- supplying own linker script that introduces sections .data.lo at
0x60, .test at 0x100, .data.hi at 0x200. But depending on the
size of .data, you will have to split .bss instead and explicitely
say that has to go in the .data fragments. Not nice.
-- or allocate 0x1ff bytes and compute the effective address at runtime.
But then you must access indirect through a pointer.
-- Maybe it's best to take the space from the top of RAM. Then you will
waste just 0x60 bytes (or can put some other stuff there), and you
can use direct addressing if you prefer or need that. Yust init the
stach pointer to an other value by means of -minit-stack from command
line or simply by __builtin_alloca (0x160) resp. auto char
test_buffer[0x160] upon entering main().
Just realize that because your variable is now in the .test section, don't
expect the toolchain to automatically initialize the variable to zeros in the
future. It may do that now, but the toolchain will change to not include the
__do_clear_bss if it detects that there is nothing in the .bss section. The
variable is now outside the .bss, so there are no guarantees that it will be
initialized to a known value (zeros) in the startup code.
This can be fixed by renaming the section to .bss.test, as far as you
refer to
http://lists.gnu.org/archive/html/avr-gcc-list/2009-01/msg00162.html
But note that the linker assumes one monolithic section, and resp. does
the code in __do_clear_bss resp. __do_copy_data!
Also nothe that there are some bugs in the patch cited above.
I will fix them as soon I will find the time for it.
By the way, what is the specification for the handling of orphans?
Seems as if they are assumed to be adopted by .data?
Georg-Johann
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
RE: [avr-gcc-list] introducing a new section in data memory
> -Original Message- > From: > avr-gcc-list-bounces+eweddington=cso.atmel@nongnu.org > [mailto:avr-gcc-list-bounces+eweddington=cso.atmel@nongnu. > org] On Behalf Of Ruud Vlaming > Sent: Friday, February 20, 2009 2:33 PM > To: avr-gcc-list@nongnu.org > Subject: Re: [avr-gcc-list] introducing a new section in data memory > > On Friday 20 February 2009 19:41, Weddington, Eric wrote: > > > Attachment error. Trying again for the list. > > Just to inform you, the first post contained readable and correct > attachments, whereas the second one needs manual uudecoding. > I saw this before on your posts. Somehow it seems posts appear > differently to you as it does to me, or may be others. > I keep forgetting that it's just the avr-libc-dev list that is set strangely that it doesn't take my attachments. I remembered that after I sent the second email. Oh, well. :-/ ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] introducing a new section in data memory
On Friday 20 February 2009 19:41, Weddington, Eric wrote: > Attachment error. Trying again for the list. Just to inform you, the first post contained readable and correct attachments, whereas the second one needs manual uudecoding. I saw this before on your posts. Somehow it seems posts appear differently to you as it does to me, or may be others. regards Ruud ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
RE: [avr-gcc-list] introducing a new section in data memory
> > -Original Message-
> > From:
> > avr-gcc-list-bounces+eweddington=cso.atmel@nongnu.org
> > [mailto:avr-gcc-list-bounces+eweddington=cso.atmel@nongnu.
> > org] On Behalf Of Parthasaradhi Nayani
> > Sent: Thursday, February 19, 2009 11:37 AM
> > To: avr-gcc-list
> > Subject: [avr-gcc-list] introducing a new section in data memory
> >
> >
> > Hello all,
> > I needed to create a buffer of 256 bytes starting at a page
> > boundary (xx00) in the RAM memory (Mega8).
> >
> > I added this line in the makefile
> >
> > LDFLAGs = -wl,--section-start=.test=0x800200
> >
> > and defined a variable in the .C file (shown below)
> >
> > unsigned char mem3 __attribute__ ((section(".test")));
> >
> > However variable mem3 is being assigned address 0x60 in the
> > controller???
> >
> > also if I define another global in next line to mem3 I get
> > error that .data and .bss overlap lma 0xa0??
> >
> > I am of the opinion that all variable defined with attribute
> > .test will be located in that memory area and all other
> > global variables will be located in their native memory.
> > Perhaps if I ma able locate the .test section properly the
> > overlap error may vanish. Can you correct the problem please?
> > Thank you.
>
> It works for me.
>
> See attached demo. After the build look at the .map file and
> the disassembly file (.dis).
>
> Just realize that because your variable is now in the .test
> section, don't expect the toolchain to automatically
> initialize the variable to zeros in the future. It may do
> that now, but the toolchain will change to not include the
> __do_clear_bss if it detects that there is nothing in the
> .bss section. The variable is now outside the .bss, so there
> are no guarantees that it will be initialized to a known
> value (zeros) in the startup code.
>
> Eric Weddington
Attachment error. Trying again for the list.
Eric
begin 666 build.sh
M(r...@+v)I;B]S: is...@+7@*879R+6=C8R M+79EPH@(" @;65M'0Z#0H-"C P,# P,# P(#Q?7W9E
M8W1O#0V(#Q?7V)A9%]I;G1E#0V(#Q?7V)A9%]I;G1E#0V
M(#Q?7V)A9%]I;G1E#0V(#Q?7V)A9%]I;G1E#0V(#Q?7V)A9%]I;G1E#0V
M(#Q?7V)A9%]I;G1E#0V(#Q?7V)A9%]I;G1E#0V(#Q?7V)A9%]I;G1E#0V
M(#Q?7V)A9%]I;G1E#0V(#Q?7V)A9%]I;G1E#0V(#Q?7V)A9%]I;G1E#0V
M(#Q?7V)A9%]I;G1E#0V(#Q?7V)A9%]I;G1E#0V(#Q?7V)A9%]I;G1E#0V
M(#Q?7V)A9%]I;G1E#0V(#Q?7V)A9%]I;G1E#0V(#Q?7V)A9%]I;G1E#0V
M(#Q?7V)A9%]I;G1E#-F+"!R,0D[(#8S#0H@(#)a...@ec9b!e-2 @(" @(" )
M;&1I"7(R."P@,'@u...@d[(#DU#0H@(#)c...@ed-"!E," @(" @(" );&1I"7(R
M.2P@,'@P- D[(#0-"B @,F4Z"61E(&)F(" @(" @( EO=70),'@S92P@# P"3L@, T*(" S-#H)83 @938@(" @(" @"6QD
M:0ER,C8L(#!X-C ).R y...@t*(" S-CH)8C @93 @(" @(" @"6QD:0ER,C#-C(#PN9&]?8VQE87)?8G-S7W-T87)T/@T*#0HP,# P,# S82 \+F1O
M7V-L96%R7V)S#0X(#QM86EN/@T*
M(" T-#H),3@@8S @(" @(" @"7)J;7 )+BLT." @(" @"3L@,'@W-B \7V5X
M:70^#0H-"C P,# P,#0V(#Q?7V)A9%]I;G1E# P"3L@, T*(" T83H).3(@93 @(" @(" @"6QD:0ER,C4L(#!X,#()
M.R R#0H@(#...@dv82!e82 @(" @(" );&1I"7(R,BP@,'A!00D[(#$W, T*
M(" T93H)-S @93 @(" @(" @"6QD:0ER,C,L(#!X,# ).R P#0H@(#...@dt
M,"!E," @(" @(" );&1I"7(R,"P@,'@P, D[(# -"B @-3(Z"34Q(&4P(" @
M(" @( EL9&D)# Q"3L@,0T*(" U-#H),#...@9# @(" @(" @"7)C
M86QL"2XK,3@@(" @( D[(#!X-C@@/&UE;7-E=#X-"B @-38Z"3...@u(&4U(" @
M(" @( EL9&D)#4U"3...@.#4-"B @-...@z"3...@p(#DS(#...@p(# R( ES
M=',),'@P,c...@p+"!R,C0-"B @-6,Z"3...@s(&4P(" @(" @( EL9&D)# S"3L@,PT*(" U93H).# @.3,@-C,@,# @"7-T# P-C,L('(R- T*
M(" V,CH).# @93 @(" @(" @"6QD:0ER,C0L(#!X,# ).R P#0H@(#...@dy
M,"!E," @(" @(" );&1I"7(R-2P@,'@P, D[(# -"B @-C8Z"3 X(#DU(" @
M(" @( ER970-"@T*,# P,# P-C@@/&UE;7-E=#XZ#0H@(#...@ed8r P,2 @
M(" @(" );6]V=PER,C8L('(R- T*(" V83H),#...@8s @(" @(" @"7)J;7 )
M+BLR(" @(" @"3L@,'@V92 \;65M#9C
M(#QM96US970K,'@T/@T*(" W-#H),#@@.34@(" @(" @"7)E= T*#0HP,# P
M,# W-B \7V5X:7...@t*(" W-CH)9C@@.30@(" @(" @"6-L:0T*#0HP,# P
M,# W." \7U]S=&]P7W!R;v=r86...@t*(" W.#H)9...@8v8@(" @(" @"7)J
F;7 )+BTR(" @(" @"3L@,'@W." \7U]S=&]P7W!R;V=R86T^#0H`
`
end
begin 666 test.map
M07)C:&EV92!M96UB97(@:6YC;'5d...@8f5c875s92!o9b!f:6QE("AS>6UB
M;VPI#0H-"F,Z+W!R;V=R86UM92]W:6YA=G(M,C P.3 R,#$O8FEN+RXN+VQI
M8B]G8V,O879R+S0N,RXR+V%V&ET*0T*8SHO<')O9W)A;6UE+W=I
M;F%V6UB;VQS#0I#;VUM;VX@F4@(" @(" @(" @(" @(&9I;&4-"@T*;65M,B @(" @(" @(" @(" @
M(" P>#4@(" @(" @(" @(" @("!T97-T+F\-"@T*365M;W)Y($-O;F9I9W5R
M871I;VX-"@T*3F%M92 @(" @(" @(" @("!/# P.# P,#8P(" @(" @(" @,'@P,# P9F9A
M," @(" @(" @(')W("%X#0IE97!R;VT@(" @(" @(" @(#!X,# X,3 P,# @
M(" @(" @(" P># P,#$P,# P(" @(" @(" @ T*;&]C:R @(" @(" @(" @(" P># P.#,P,# P(" @(" @(" @,'@P
M,# P,#0P," @(" @(" @(')W("%X#0IS:6=N871U# P,# P-# P(" @(" @(" @6YS>6T-
M"B J*"YD>6YS>6TI#0H-"BYD>6YS='(-"B J*"YD>6YS='(I#0H-"BYG;G4N
M=F5R'0N*BD-"B J*"YR96QA+F=N=2YL:6YK;VYC92YT*BD-"@T*+G)E;"YF
M:6yi...@*b@N'0@(" @(" @(" @(#!X,# P,# P,# @(" @(" @
M,'@W80T*("HH+G9E8W1O#(V(&,Z+W!R;V=R86UM92]W:6YA=G(M,C P.3 R,#$O8FEN
M+RXN+VQI8B]G8V,O879R+S0N,RXR+RXN+RXN+RXN+RXN+V%V# P,# P,# P
M(" @(" @(" @(" @(" @(%]?=F5C=&]R7V1E9F%U;'0-"B J*"YV96-T;W)S
M*0T*("HH+G!R;V=M96TN9V-C*BD-"B J*"YP# P,# P,#(V(" @(" @(" @(" @(" @("X@/2!!3$E'3B H
RE: [avr-gcc-list] introducing a new section in data memory
> -Original Message-
> From:
> avr-gcc-list-bounces+eweddington=cso.atmel@nongnu.org
> [mailto:avr-gcc-list-bounces+eweddington=cso.atmel@nongnu.
> org] On Behalf Of Parthasaradhi Nayani
> Sent: Thursday, February 19, 2009 11:37 AM
> To: avr-gcc-list
> Subject: [avr-gcc-list] introducing a new section in data memory
>
>
> Hello all,
> I needed to create a buffer of 256 bytes starting at a page
> boundary (xx00) in the RAM memory (Mega8).
>
> I added this line in the makefile
>
> LDFLAGs = -wl,--section-start=.test=0x800200
>
> and defined a variable in the .C file (shown below)
>
> unsigned char mem3 __attribute__ ((section(".test")));
>
> However variable mem3 is being assigned address 0x60 in the
> controller???
>
> also if I define another global in next line to mem3 I get
> error that .data and .bss overlap lma 0xa0??
>
> I am of the opinion that all variable defined with attribute
> .test will be located in that memory area and all other
> global variables will be located in their native memory.
> Perhaps if I ma able locate the .test section properly the
> overlap error may vanish. Can you correct the problem please?
> Thank you.
It works for me.
See attached demo. After the build look at the .map file and the disassembly
file (.dis).
Just realize that because your variable is now in the .test section, don't
expect the toolchain to automatically initialize the variable to zeros in the
future. It may do that now, but the toolchain will change to not include the
__do_clear_bss if it detects that there is nothing in the .bss section. The
variable is now outside the .bss, so there are no guarantees that it will be
initialized to a known value (zeros) in the startup code.
Eric Weddington
build.sh
Description: build.sh
test.c
Description: test.c
test.map
Description: test.map
test.dis
Description: test.dis
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] How to force GCC to not to remove "nop" statements?
On Fri, Feb 20, 2009 at 08:00:00AM +0100, Joerg Wunsch wrote: > David Kelly wrote: > > > Strangely the JTAGICE mkII didn't work on the above hardware where the > > ICE Cube did. I put a small 50 mA or maybe 100 mA linear regulator on > > the 3.3V supply and the mkII drew more power off the target than the > > regulator would provide. > > The JTAG ICE mkII cannot be powered from the target circuitry. It > needs either a separate power supply, or can be powered directly from > USB. Whatever, it didn't work on my circuit but worked on a purchased ATmega128 board. But the ICE Cube did work. I believe the company is currently using mkII's to support it. -- David Kelly N4HHE, dke...@hiwaay.net Whom computers would destroy, they must first drive mad. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
RE: [avr-gcc-list] introducing a new section in data memory
First off, is that a typo above? It's suppose to be an uppercase 'W' like so: LDFLAGs = -Wl,--section-start=.test=0x800200 Hi, Checked the 'W' and it was indeed capital letter only. The problem persists!! Any more suggestions please? Thank you. Nayani ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] How to force GCC to not to remove "nop" statements ?
On Fri, 20 Feb 2009 08:03:52 +0100 (MET)
j...@uriah.heep.sax.de (Joerg Wunsch) wrote:
> Vincent Trouilliez wrote:
> > lcd.c:96: error: »asm« undeclared (first use in this function)
>
> That's because you are using a -std setting the prevents GCC from
> using its extensions by a name ("asm") that is in the application name
> space, like -std=c99. Either use -std=gnu99, or (as you already did)
> use the implementation namespace counterpart __asm__.
>
> --
> cheers, J"org
You are a magician Joerg.. how could you know ! ;-)
Yes indeed, 2 weeks ago I added the --std=c99 flag to my makefile, as
advised by the avr-libc manual, in order to get the ATOMIC_BLOCK()
macro to work !
Using gnu99 fixed the problem indeed, thanks ! :-)
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
