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

[Ralph Mason]

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