[En-Nut-Discussion] gcc, large programs, corrupted variable or memory space? :( --> :)
Ralph Mason
ralph.mason at telogis.com
Wed Apr 23 23:32:38 CEST 2003
In some version %p is used for a pointer, however as far as I know %P is
never used .
printf has always been case sensitive (which is why I chose %P)
My printf function also has another non-standard extension that is very
useful. %a & %A which print a uint32 as a dot formatted IP address (%a
address is in host order, %A in network order), esp when debugging.
I think the ram savings of these far outweigh the fact that the
implementation isn't standard - on versions that run in a Von-Neumann
environment I just macro out PSTR and make macro LPM to do a memory
dereference, meaning %P works the same as %s, so the code runs on both the
same.
Here is a little example (from older code) - Saving about 128 bytes of ram.
This function is called in several places
prog_char* CDPD_decode_status(u08 st){
switch (st){
case 0 :return PSTR("idle");
case 1 :return PSTR("pass physical test");
case 2 :return PSTR("can receive");
case 3 :return PSTR("can xmit");
case 4 :return PSTR("get TEI");
case 5 :return PSTR("establish MDLP con");
case 6 :return PSTR("pass key exchange");
case 7 :return PSTR("complete registration (connected)");
case 8 :return PSTR("sleep");
case 9 :return PSTR("sleep resume");
case 10:return PSTR("disconnecting");
case 12:return PSTR("wide area scan");
default: return PSTR("?");
}
}
One such example
void ReportConnectionData(void){
u08 stat;
u16 chan;
s16 rssi;
u16 spni;
u16 xmit_pwr;
u08 buff[80];
GetModemInfo(&stat, &chan, &rssi,&spni,&xmit_pwr);
p_sprintf(buff,PSTR("Chan:%d Rssi:-%d dB, Spni:%d Pwr:%d St:%d %P"),
chan,
(u16)(-rssi),
spni,
xmit_pwr,
stat,
CDPD_decode_status(stat) );
SendStringOut(buff,i_strlen(buff));
}
Using this I was able to write a 90kb app for a 103 that used no strings in
ram - easily.
I am happy to send my updates if wanted.
Cheers
Ralph
> -----Original Message-----
> From: en-nut-discussion-admin at egnite.de
> [mailto:en-nut-discussion-admin at egnite.de]On Behalf Of Harald Kipp
> Sent: Tuesday, 22 April 2003 10:50
> To: en-nut-discussion at egnite.de
> 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
>
> ---
> 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
More information about the En-Nut-Discussion
mailing list