Re: [avr-gcc-list] preinit data bug in the new avr gcc tools

[David Sowa]

__attribute__((progmem)) allocates space and data that only
exists in the flash program area.  This is useful for tables or other
data that is too big for the avr's tiny working ram.

static would create space in working ram and then pre-init
those variable from a flash table at startup

the joys of doing c on an chip that has 3 independent
address spaces.

dsowa

----- Original Message -----
From: "Tony M" <address@hidden>
To: "David Sowa" <address@hidden>; "Avr List" <address@hidden>
Sent: Monday, June 17, 2002 11:08 AM
Subject: Re: [avr-gcc-list] preinit data bug in the new avr gcc tools


> I'll try to reproduce that when I get to the office.
>
> Anybody with Linux able to reproduce it?
>
> Dave: would there be any difference if you declared those static unsigned
> char ?   (I'm not quite sure the technical difference between
> __attribute__((progmem)) and static).
>
> Tony
>
> ----- Original Message -----
> From: "David Sowa" <address@hidden>
> To: "Avr List" <address@hidden>
> Sent: Monday, June 17, 2002 9:31 AM
> Subject: [avr-gcc-list] preinit data bug in the new avr gcc tools
>
>
> > First, many thanks to the great people on this list who work hard
> > to make gcc for the avr.
> >
> > Second, I downloaded Marc's windows build of the new gcc 3.2 based
> > toolchain this morning and have the following problem.
> >
> > The compiler crashes on files that have more than 32K of pre-init flash
> > data defined in them.  I have things that look like this...
> >
> > unsigned char __attribute__((progmem)) mbuf[] =
> > {
> > /*0000:*/ 0x7F, 0x45, 0x4C, 0x46, 0x01, 0x01, 0x01, 0x00, 0x00, 0x00,
> 0x00,
> > 0x00, 0x00, 0x00, 0x00, 0x00,
> > /*0010:*/ 0x02, 0x00, 0x2D, 0x00, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00,
> 0x00,
> > 0x00, 0x34, 0x00, 0x00, 0x00,
> >   .... goes on for 30k...
> > };
> >
> > unsigned char __attribute__((progmem)) mbuf2[] =
> > {
> > /*0000:*/ 0x7F, 0x45, 0x4C, 0x46, 0x01, 0x01, 0x01, 0x00, 0x00, 0x00,
> 0x00,
> > 0x00, 0x00, 0x00, 0x00, 0x00,
> > /*0010:*/ 0x02, 0x00, 0x2D, 0x00, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00,
> 0x00,
> > 0x00, 0x34, 0x00, 0x00, 0x00,
> >   .... goes on for 30k...
> > };
> >
> > and when the total of this memory usage goes over 32K then the compiler
> > crashes.  When the debugger starts up it says "Stack Overflow".  So this
> may
> > be a gcc problem or it may be a windows build issue.
> >
> > Thanks to anyone who can check this out.
> >
> > regards,
> >
> > David Sowa
> >
> >
> > avr-gcc-list at http://avr1.org
> >
>

avr-gcc-list at http://avr1.org