Re: Stdio redirection?

[Kai Ruottu <kai dot ruottu at luukku dot com>]

"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.

 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...

----------- A clip from a SN-maillist message from Mo DeJong -------------
> I know of more than 1/2 dozen companies in my
> area that have been forced to scale back use of SN because of many problems
> with C++ parser: 3Com, Lucent, Cienna, Concord Communications, Broadband
> Access Systems, Cisco, Fidelity... Unless C++ parsing bugs are fixed, SN
> cannot be relied upon as a development tool.

Humm, if all of these companies are having problems why have they
not contacted us about a support/development contract to improve
the C++ parser support?
--------------------------------------------------------------------------

 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...

 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.

 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 ???

 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?

 Was it something with modifying the default write() :
---------------------- clip ------------------------------------
int _write(file, ptr, len)
     int file;
     char *ptr;
     int len;
{
  int todo;
  
  for (todo = 0; todo < len; todo++) 
    {
      asm("mov.b #0,r1l\n mov.b %0l,r2l\njsr @@0xc4"   :  : "r" (*ptr++)  : "r1", "r2");
    }
  return len;
}
---------------------- clip ------------------------------------

ie. changing the loop to use your own 'transmit_SCI0()' (or something) :

---------------------- clip ------------------------------------
int _write(file, ptr, len)
     int file;
     char *ptr;
     int len;
{
  int todo;
  char c;

  for (todo = 0; todo < len; todo++) 
    {
      c = *ptr++;
      transmit_SCI0(c);
    }
  return len;
}
---------------------- clip ------------------------------------

and providing an equivalent for the read(), using a 'receive_SCI0()'
or something.  And there is that 'int file;' for splitting the handling
into different cases...

---------------------- clip ------------------------------------
  for (todo = 0; todo < len; todo++) 
    {
      c = *ptr++;
      switch (file) {
	case 1:
	case 2:
	  transmit_SCI0(c);
	  break;
	case 3:
	  transmit_SCI1(c);
	  break;
	case 4:
	  transmit_SCI2(c);
	  break;
     }
   }
---------------------- clip ------------------------------------

 Perhaps it was how to use 'ar' to delete routines from the libc.a :

---------------------- clip ------------------------------------
E:\usr\local\h8300-hms\bin>ar --help
Usage: ar [-]{dmpqrstx}[abcfilNoPsSuvV] [member-name] [count] archive-file file.
..
       ar -M [<mri-script]
 commands:
  d            - delete file(s) from the archive  <-------------- !!!!!
  m[ab]        - move file(s) in the archive
  p            - print file(s) found in the archive
  q[f]         - quick append file(s) to the archive
  r[ab][f][u]  - replace existing or insert new file(s) into the archive
  t            - display contents of archive
  x[o]         - extract file(s) from the archive
 command specific modifiers:
  [a]          - put file(s) after [member-name]
---------------------- clip ------------------------------------

 So the 'ar d libc.a syscall.o write.o' would have been the answer to this
unasked question. All the other low-level stuff except 'write()' is in the
'syscall.c' in 'newlib/libc/sys/h8300' (if I remember it ok...)

 There will always be all kind of gaps between the askers and the anwerers, but
the people working in the embedded area are expected to know some basic things
already. One of them is just this 'know how' for handling library archives with
'ar'. Of course everybody expects these things to be known already, but it is
not a shame to ask about them or ask about books where they have been explained
and so on...

 For learning about these kind of things there are books like the O'Reilly's
"Programming with GNU Software" and the "Programming Embedded Systems in C and
C++". Please see these books at your nearest bookstore or visit the 'www.ora.com'.
O'Reilly is really a well-known publisher of these kind of books... The first
was written partially by Cygnus folk and the second by an embedded engineer...
And let's not forget the Bill Gatliff's articles about the GNU tools at:
'www.embedded.com'...

Cheers, Kai