[En-Nut-Discussion] gcc, large programs, corrupted variable or memory space? :( --> :)

[Jelle Kok]

As far as I can see those strings (as defined by Brett) are both stored in
sram and not in flash memory as you wanted. Can anyone verify this ?

What I looked for was the following lines in the map file: (the file where
the strings are defined is named client.c)
.progmem.data  0x00000570      0x1f1 client.o
.data          0x0080022c      0x339 client.o

When inserting the strings in the existing listing, I only saw the ".data"
entry grow. The ".progmem.data" line didn't change at all.

Jelle Kok

void test (void) {
 // takes 10 bytes of sram memory
 puts("A12345678");

 // takes 10 bytes of flash memory
 puts_P(PSTR("c12345678"));

 // takes 20 bytes of sram memory (and not flash as wanted)
 static char *states1[] = { "String1", "String2" };

 // takes 20 bytes of sram memory (and not flash as wanted)
 static prog_char *states2[] = { "String3", "String4" };
}


----- Original Message -----
From: "Harald Kipp" <harald.kipp at egnite.de>
To: <en-nut-discussion at egnite.de>
Sent: Tuesday, April 22, 2003 12:49 PM
Subject: RE: [En-Nut-Discussion] gcc, large programs, corrupted variable or
memory space? :( --> :)


> Yes, Ralph, that's the missing part. However, isn't %P or
> %p used for pointer values in some dialects?
>
> printf_P() expects the format string in program space, not
> the parameters. For transfering large parameters to program
> space, use puts_P().
>
> Harald
>
> At 06:59 21.04.2003 +1200, you wrote:
> >I do the same, except I have made some modifications to putf so that you
can
> >use %P to insert a progstring into the output.
> >
> >I did this in a printf I wrote a couple of years ago and think it makes
lots
> >of sense given the avr architecture.  It could probably be part of the
> >standard distribution.
> >
> >Ralph
> >
> > > -----Original Message-----
> > > From: en-nut-discussion-admin at egnite.de
> > > [mailto:en-nut-discussion-admin at egnite.de]On Behalf Of Brett Abbott
> > > Sent: Saturday, 19 April 2003 10:27
> > > To: en-nut-discussion
> > > Subject: Re: [En-Nut-Discussion] gcc, large programs, corrupted
variable
> > > or memory space? :( --> :)
> > >
> > >
> > >   Hi
> > >
> > > I have used the prog_char "macro" to shift char strings into Flash,
away
> > > from precious sram (and using the _P functions) which works well
except
> > > for char arrays.
> > >
> > > Before I launch into finding either a fix to fprint_P or my misguided
C
> > > programming, I humbly ask if this should even work or if there is a
> > > better way.
> > >
> > > Examples: (from the httpserv.c demo)
> > >
> > > // Works:
> > > static char *states[] = { "TRM", "<FONT
> > > COLOR=#CC0000>RUN</FONT>", "<FONT COLOR=#339966>RDY</FONT>",
> > > "SLP" };  fprintf(stream, "<TD>%s</TD>", states[tdp->td_state]);
> > >
> > > // Doesnt work:
> > > static prog_char *states[] = { "TRM", "<FONT
> > > COLOR=#CC0000>RUN</FONT>", "<FONT COLOR=#339966>RDY</FONT>", "SLP" };
> > > fprintf_P(stream, "<TD>%s</TD>", states[tdp->td_state]);
> > >
> > > The latter version seems to output some sort of corrupted string, the
> > > original using normal "char *" works fine as Harald intended.
> > >
> > > Many Thanks
> > > Brett
> > >
> > > Igor V. Tchibirev wrote:
> > >
> > > >Hi Brett,
> > > >I faced the same problems a couple months ago. The reason is very
simple.
> > > >All the variables you have in program will be allocated by
> > > linker either in
> > > >.data or in .bss section. Take a look at your *.map file. The
> > > trick is that
> > > >total amount of memory is 4K bytes - it is internal data memory of
> > > >processor. Good news:
> > > >1. you can either allocate static initiated variables in program
memory
> > > >using prog_char instead of char and NutOs special functions to
> > > have access
> > > >to these variables. For example NutProntString_P(...) instead of
> > > >NutPrintString(...).
> > > >2. Big peaces of data without initialization you can allocate in
external
> > > >data memory using NutOs hash functions. For example
> > > >#define DATA_LEN 5000
> > > >u_char* p_crypto_heap;
> > > >.....
> > > >// with "garbage" (random) init
> > > > p_crypto_heap = NutHeapAlloc( DATA_LEN );
> > > >// with zero initialisation
> > > >p_crypto_heap = NutHeapAllocClear( DATA_LEN );
> > > >
> > > >After this string you can us
> > > >e pointer p_crypto_heap the same way as any
> > > >other pointer.
> > > >
> > > >Hope it helps.
> > > >Regards
> > > >
> > > >Igor Tchibirev,
> > > >System software developer
> > > >Intech 21, Inc.
> > > >50 Glen Street,
> > > >Glen Cove, NY, 11542
> > > >516 656 5581 x228
> > > >http://www.intech21.com
> > > >
> > > >
> > >
> > > --
> > > -----------------------------------------------------------------
> > > Brett Abbott, Managing Director, Digital Telemetry Limited
> > > Email: Brett.Abbott at digital-telemetry.com
> > > PO Box 24 036 Manners Street, Wellington, New Zealand
> > > Phone +64 (4) 5666-860  Mobile +64 (21) 656-144
> > > ------------------- Commercial in confidence --------------------
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > En-Nut-Discussion mailing list
> > > En-Nut-Discussion at egnite.de
> > > http://www.egnite.de/mailman/listinfo/en-nut-discussion
> > >
> > > ---
> > > Incoming mail is certified Virus Free.
> > > Checked by AVG anti-virus system (http://www.grisoft.com).
> > > Version: 6.0.461 / Virus Database: 260 - Release Date: 10/03/2003
> > >
> >---
> >Outgoing mail is certified Virus Free.
> >Checked by AVG anti-virus system (http://www.grisoft.com).
> >Version: 6.0.461 / Virus Database: 260 - Release Date: 10/03/2003
> >
> >_______________________________________________
> >En-Nut-Discussion mailing list
> >En-Nut-Discussion at egnite.de
> >http://www.egnite.de/mailman/listinfo/en-nut-discussion
>
> _______________________________________________
> En-Nut-Discussion mailing list
> En-Nut-Discussion at egnite.de
> http://www.egnite.de/mailman/listinfo/en-nut-discussion
>