Re: Stdio redirection?

["Russ.Shaw" <russell at webaxs dot net>]

Kai Ruottu wrote:
> 
> "Russ.Shaw" wrote:
> > Aklilu Noah wrote:
> > >
> > > I use my own linker scripts so there is little chance of that happening.
> > > If you installed a board support package, then it should come with
> > > code for these support functions as well as a linker script.
> >
> > Ah, but iirc, libgloss does the board-support stuff, and libgloss
> > is currently un-implemented for the h8300-hms.
> 
>  Why you should care about this?  Just remove the low-level routines
> from all your libc.a's and provide your own glue libs with them inside.

If i knew what the right low-level functions were, i would. However, looking
at stdio.h and the newlib sources, there's too many conditional compilations
controlled by variables from unknown places, compounded by all the extra
re-entrant library functions.

 
>  Of course having all kind of BSP-packages in 'libgloss/h8300' for
> different Hitachi EVB's and chips would be nice, but some people must first
> provide them. If Hitachi pays now Cygnus enough for providing the freely
> downloadable tools, we should expect Cygnus to provide these. If the sum
> is so small that it only pays the build job from the current FSF-sources,
> then there isn't any help from that direction...

I was going to add to libgloss myself, but there was not sufficient information
in the source docs, on the web, from newsgroups, or mail-lists.


>  This is the way things will happen. If someone wants to get the
> 'libgloss support for H8/300', ie. get one or more BSP packages for
> H8/300[HS] systems, then if quoting from the same message again:
> 
> --------------------------------------------------------------------------
> If your company needs some particular feature, you have the following options:
> 
> 1. Implement it yourself
> 2. Contract with us to implement it
> 3. Hire someone else to do it
> --------------------------------------------------------------------------
> 
>  Very simple...
> 
>  I think that the majority of the GNU CC for H8/300 users simply delete the
> 'read()', 'write()', 'open()', 'lseek()' etc. from their libc.a's, then
> implement these for their own hardware, or don't use them at all, don't use
> the very big printf() etc...

I had not found anywhere that definitely said that those functions were at
the bottom level with all higher functions using them. A message by j.johnston
referred to a build-time way that suggests these functions, by modifying
configure.in etc (i'm still getting around to trying it).


> When a very common question among the m68k, ppc, mips etc. newbies is why
> these routines aren't in their libc.a's, the H8/300 newbies should be happy
> that they already are there and the first 'Hello World'-program links ok and
> can be run in GDB or in the standalone run-simulator, without having yet seen
> the final target board... The first "experience of success" will be got and
> the newbies will be happy.

I wire-wrapped my own system and didn't want to add more variables by using
a monitor. I'd be completely happy if there was a straight-forward obvious
method for doing the low-level functions, knowing that nothing will get
broken. And it should be stated prominantly in docs such as 'using gcc'
or similar.


>  The Hitachi-EVB manuals have ready routines (polling ones) for handling the
> SCIx-ports, so implementing read() and write() routines for these should be
> quite easy. For example:
> 
>    read(0,...) and write(1,...) ie. stdin/stdout could use the SCI0
>                    write(2,...) ie. stderr could use the LCD-display ???
>    read(3,...) and write(3,...) could use the SCI1 ???
>    read(4,...) and write(4,...) could use the SCI2 ???

Yes, but i wanted to use interrupt driven ports.

 
>  BTW, when you asked about these things already a month ago and got an
> answer from me:
> 
> ------------------ clip -------------------------------
> Subject: Re: Getting stdin, stdout
> Date:    Sun, 03 Sep 2000 14:06:13 +0300
> From:    Kai Ruottu <kai.ruottu@luukku.com>
> Reply-To:  karuottu@freenet.hut.fi
> Organization: Freenet Finland
> To:      "Russ.Shaw" <russell@webaxs.net>
> CC:      crossgcc@sources.redhat.com
> 
> "Russ.Shaw" wrote:
> >
> > Hi all,
> >
> > I'm using a hitachi H8/3048F micro in a wire-wrap system,
> > and want to use scanf and printf, which requires stdin and
> > stdout. I wan't to use a serial port for stdin/out.
> >
> > There are io functions and macros in stdio.h, but its not
> > obvious how i should modify or overide them in my own
> > program. Anyone know how?
> 
>  The low-level I/O-routines read() and write() handle these
> things, so just modify them for your needs. The calling
> conventions etc. are handled in the newlib, GNUPro etc. docs.
> The newlib docs come with newlib sources, the GNUPro docs
> come with the GNUPro distributions, like those from Hitachi
> (the '98r2' in their free 2000 CDROM and the '99r1p1' now
> available via download).
> 
>  Here is the default 'write()' coming with newlib in 'write.c':
> ------------------- clip ---------------------------------------
> 
> and there pointing to the read() and write(), so what on earth
> went wrong with this?  What you didn't understand in it when you
> are again asking about the same things?  Why you simply didn't
> asked me to elaborate?


Starting from simple functions such as fopen(), fwrite(), etc, i traced
thru the newlib sources to find the lowest level functions. However,
i found multiple read and write functions with similar names, and
re-entrant versions, suspended in a bowl of tortuously twisted
spagetti controlled by switches for conditional compilations,
just getting completely lost.

Without a more concrete how-to, no one could have much confidence
in whether the result will be right (unless they had prior knowledge).

I've got as much info as anyone is likely to get (still a bit vague),
and if i can't do it after experimenting for a week, i'm never using
a gnu compiler for an embedded system again.

-- 
*******************************************
*   Russell Shaw, B.Eng, M.Eng(Research)  *
*      email: russell@webaxs.net          *
*      Victoria, Australia                *
*******************************************