This is the mail archive of the crossgcc@sources.redhat.com mailing list for the crossgcc project.
See the CrossGCC FAQ for lots more infromation.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
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 * ******************************************* ------ Want more information? See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/ Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |