[En-Nut-Discussion] Nut/OS port for H8/300H.

[Jan Dubiec]

On 16 Mar 2004 23:51:53 +0100, Jan Dubiec <jdx at plonk.slackware.pl> wrote:
[.....]
> On Tue, 16 Mar 2004 19:55:23 +0100, Harald Kipp <harald.kipp at egnite.de> wrote:
> > I noticed a few lines, where you replaced program memory
> > strings by standard literals in NUTDEBUG sequences. Some
> > application may now fail to link with NUTDEBUG, because
> > they simply run out of RAM.
> Indeed, it seems that for some reason (???) I have done a few mistakes
> (e.g. in osdebug.c). I have declared some format strings as static
> char while they should be static prog_char. I hope you will fix it. :-)
OK, I know why I did it. Lets take a look at osdebug.c:

#ifdef ARCH_32BIT
static prog_char qheader[] = "\nHandle   Name     Prio Sta Queue    Timer    StackPtr FreeMem\n";
#else
static prog_char qheader[] = "\nHndl Name     Prio Sta QUE  Timr StkP FreeMem\n";
#endif
[.....]
void NutDumpThreadQueue(FILE * stream, NUTTHREADINFO * tdp)
{
#ifdef ARCH_32BIT
    static prog_char fmt[] = "%08lX %-8s %4u %s %08lX %08lX %08lX %9lu %s\n";
#else
    static char fmt[] = "%04X %-8s %4u %s %04X %04X %04X %5u %s\n";
#endif

    fputs_P(qheader, stream);

    NutEnterCritical();
    if (tdp == SIGNALED)
        fputs("SIGNALED\n", stream);
    else {
        while (tdp) {
            fprintf(stream, fmt, (uptr_t) tdp, tdp->td_name, tdp->td_priority,
[.....]

I thought that if puts_P is used to print "prog_char" strings then a function
without _P suffix (fprintf in this case) is used for simple "char" strigs. 

But I have just noticed a possible bug. Lets consider two programs:

1. fprintf(stream, "a text");

2. prog_char fmt[] = "a text";
   fprintf(stream, fmt);

A compiler should emit almost the same code for both cases and put format
string into a read only section which is usually located in ROM. It is
meaningless on H8, but on AVRs IMO there should be fprintf_P used instead
of plain fprintf because format string is stored in program memory.
Have I found a bug? :-) There are much more such places in the Nut/OS sources.

Of course I agree that format strings should be "static prog_char" in order
to save RAM.

> [.....]
> > >- AVR interrupt functions/variables definitions should be put into one file.
> > 
> > No, because they consume a lot of space.
> > 
> > In general I'd recommend to split even more files. The
> > linker will always add a complete module, even if the
> > application needs a single routine only.
> OK, although I am not sure. Is there really difference between passing to
> the linker an object with functions and passing two separate object files?
> I will check that when I find some time.
Well, I have checked this. There is a difference. ;-) It seems that H8
interrupt stuff should be also splitted into separate files. I will do
in April - I will not have tim euntil the end of March.

A note to the latest cvs snapshot: I am not the author of h83068f.h so
I am not sure if copyright may be placed there. The original file is
called 3068s.h and has no copyright. I have downloaded it from
http://www.renesas.com/eng/products/mpumcu/tool/crosstool/iodef/index.html
I have only changed its name and fixed a bug (one register hadn't been
defined).

I have found also a typo bug in chat.h and a possible bug in atom.h -
I used __AVR__ macro which is defined in avr-gcc but I don't know if
Imagecraft does that. The patch is attached.

Regards,
/J.D.
-- 
Jan Dubiec, jdx at slackware.pl, mobile: +48 602 101787

Głęboka wiara wymaga płytkiego rozumu i nikłej wiedzy.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: qf.diff
Type: text/x-patch
Size: 773 bytes
Desc: not available
URL: <http://lists.egnite.de/pipermail/en-nut-discussion/attachments/20040317/87125d7b/attachment-0001.bin>