| FAQ |
| |
|
|
FAQ for GNUH8 Mailing List
Subject: GNUH8 mailing list FAQ
Organisation: PC Services
X-Changes: Minor
Last Updated 2nd February 2005
Last Change Add linker ALIGN confusion
Version 2.4
Frequently Asked Questions about GNUH8 tools for Embedded Processing
--------------------------------------------------------------------
But often Frequently Answered...
Contents
0. Introduction
*0.1 Distribution and copying
1. What is GNUH8 mailing list for
1.1 What the mailing list is not for
1.2 Who runs the mailing list
1.3 My mail is not getting to the mailing list?
1.4 Configuring your Email software for use with this mailing list
1.5 Is there an archive for this mailing list?
2. Software Tools
2.1 The latest releases of the tools
2.2 Where to find the tools and other information
2.3 Alternatives
2.3.1 Useful Starter pages
2.3.2 Useful Starter Application
2.4 Known workarounds for associated tools
2.4.1 FLASH.EXE not working for many programming cycles
2.4.2 FLASH.EXE (V2.02) has no H8/3334 support
2.4.3 FLASH.EXE (V2.02) does not work with my target board
2.4.4 "Can I FLASH the H8xxxx ONLY 100 times?"
3. Documentation Errors
3.1 Implementation Specific behaviour
3.1.2 Bit field storage
3.2 Hint and compiling special versions
3.3 Hardware documentation errors
3.3.1 H8/3048
3.3.2 H8/306x
4. Workarounds
4.1 Getting libc and libgcc to link into your application.
*4.2 Linker errors
*4.2.1 Linker 'undefined end statement' error
*4.2.2 Linker places stack in wrong memory area
4.3 I don't know what crt0.o is doing?
4.4 I want to do some system tests/diagnostics before starting C programmes?
4.5 Serial Ports
4.5.1 Changing Baud Rates
4.5.2 Interupt Handling Routines
5. Contributors
* denotes changes
0. Introduction
This FAQ is a list of information about Embedded Processing on the
Renesas[1] H8 and H8s series of processors and writing code using the
GNU tools, primarily in assembler and C/C++.
This information is gathered from many sources, and this FAQ is copyright
1998 (and onwards) by Paul Carpenter, PC Services and is issued under a
GNU license. I.E. No liability or warranty is given for its use, and is
offered on an as is basis.
Having said that any information given here is from personal experiences
of the FAQ Maintainer and list members, so any fixes or answers MIGHT
solve your problems, but any testing or adaptations to your application
is YOUR responsibility.
*0.1 Distribution and copying
*
* Copyright for this FAQ remains with PC Services, and cannot be included
* in publication or media for re-distribution without prior permission.
*
* This FAQ can be copied and distributed using any media WITHOUT CHANGES
* freely by users for reference purposes, and cannot be modified in any
* way. Any modifications to this FAQ pass ALL responibilities to the
* modifier, who may be charged for use beyond its intended purpose.
*
* Those wishing to publish this document in ANY FORM, whether for profit
* or not, should contact the FAQ maintainers first.
*
* The definitive version is always the one available on
*
* http://www.gnuh8.org.uk/
*
* Any other website is free to link to the website above, but not to
* publish the FAQ on their website directly or indirectly (e.g. in a
* frame).
1. What is GNUH8 mailing list for
As Cygnus no longer support the tools at the version available from
Renesas[1], (see section 2), this mailing list was set up in order that
developers could exchange information and support amongst each other.
Rather than be left out in the cold, or asked to buy things more than
what was originally thought to be required.
1.1 What the mailing list is not for.
From our end as list maintainers we are NOT gatherers of email addresses
or the like for Unsolicited email of any kind. Therefore we promise that
the list of subscribers will NOT be published on the mailing list or
anywhere else, without the express permission of *all* the users of the
mailing list. No messages are censored. See also section 1.3 .
From the users point of view, basically anything that is not helpful,
or courteous to other users or the mailing list:-
a) Long copies of code or files (only the telco's get any benefit)
b) Flame wars.
c) Soliciting or advertising for work, products or services.
d) Getting someone else to write your application.
e) Reselling or giving away of email addresses or other
personal details about any user of the mailing list to
external parties, or for other unsolicited uses.
f) Any other anti-social behaviour to other recipients on the
mailing list, not covered above deemed to be anti-social
or any other nuisance factor.
Any complaints received about messages, or actions pertaining to
information taken from the mailing list being used for any of the
above purposes, will cause the following to happen:-
i On first minor breach -
A polite message to the offender requesting they desist.
ii On second minor breach or first major -
Instant removal from the mailing list and depending on type of
breach an email to the offender's postmaster/ISP.
1.2 Who runs the mailing list
This mailing list is run by Paul Carpenter of PC Services, on our
systems as a FREE service, to assist developers like myself, when
all other avenues are closed.
Those wanting more information about how the service is run, or where
PC Services are or such requests, (relating to the mailing list), send
an email to webmaster, NOT to the mailing list.
Please note that the mailing list is run via a dial up modem so
don't expect instant turnaround or large messages containing lots of
files to be appreciated by anybody but my telco.
1.3 My mail is not getting to the mailing list?
Unfortunately due to spammers and UCE/UBE merchants flooding peoples
mailboxes certain domains and in some cases countries are blocked
from this site, to reduce the noise level. Some EXAMPLES are:-
any domain name containing 'cyber'
any domain name containing '@web'
geocities.com
hotmail.com
bigfoot.com
If you know of somebody having this situation, ask them to email
postmaster@gnuh8.org.uk and they will see what can be done
about making it possible for some domains. Hotmail and the like
will never be allowed.
Another reason is people forget to send emails as text only (Plain Text)
as these messages are binned as unreadable by the mailing list. Mainly
because this is the main method of virus distribution, and gives no
extra information to a message anyway. See Section 1.4 below.
1.4 Configuring your Email software for use with this mailing list
In order to assist this site and users of the mailing list, please ensure
that the software you use to send email is set to send PLAIN TEXT only.
For users of email software (primarily Microsoft offerings) go to the
Properties or Options function and ensuring that sending of Email is in
Plain text only.
Ensure that options for sending email as HTML or RTF or Rich Text or Web
page are turned off, as you cannot be sure what systems are being used to
read the emails. Several users are using Linux/Unix/DOS email software
which will find the additions of extra formats unreadable.
! Ensure that the Delivery Notification, Read Notification functions
! are turned OFF also do NOT use Return-Receipt-To: headers. This is
! because Microsoft Exchange IGNORES who it is to and sends all the
! messages to the GNUH8 bounced messages mailbox, which usually means
! I get 30 to 50 emails for EACH message sent.
1.5 Is there an archive for this mailing list?
Yes there is, but it is only available from an email server, like
this FAQ is.
To get instructions, retreive message lists and old messages
send an email
to: arcserver@gnuh8.org.uk
Message BODY of
help
end
Instructions will be returned to you. Make note of requirements in
Section 1.4 above as a lot of HTML/Web Page/RTF format emails are
just binned as unreadable by the software.
2. Software Tools
2.1 The latest releases of the tools
For latest versions of the GNU tools for Linux or DOS/Windows follow
the links on the GNUH8 web site, (see section 2.2 Alternatives).
Linux or DOS/Windows users especially look at the alternatives on the
sourceforge site.
2.2 Where to find the tools and other information
Shipped on CD-ROM with Renesas[1] evaluation systems, from their web site
http://www.renesas.com/, and probably many other sources not yet
revealed. This site has been known to be slow loading with heavy graphics.
Some other sites to look at are:-
Linux -
Recommended tools are at:-
http://sourceforge.net/projects/h8300-hms/
Windows -
Recommended Versions for Windows/DOS is the MingW version
http://sourceforge.net/project/showfiles.php?group_id=24580
Older distributions -
ftp://ftp.franken.de/pub/win32/develop/gnuwin32/cygwin/porters/Ruottu_Kai
http://www.multimania.com/legos/
Also look at http://www.renesas-eu.com/ if you are using IAR tools,
some of the application notes are useful whatever compiler you use. When
you eventually can get to them. Yet another large on non-helpful graphics
web site.
As soon as time permits other information and code snippets will be
available from the GNUH8 web site http://www.gnuh8.org.uk/.
All donations gratefully received and will be available on an
'as is' basis.
2.3 Alternatives
There are many around which can be found via the Renesas[1] and Cygnus
web sites, and Cygnus http://www.cygnus.com/ link to EGCS GNU compilers.
Look also at the Sourceforge and main gnu website http://gcc.gnu.org/.
This section will be expaned later when a list of resources has been
found. For the latest set see the GNUH8 web site links page, as this will
contain the most up to date list of alternative web resources.
Also files, links and pointer to the mailing list subscription are up on
the GNUH8 website http://www.gnuh8.org.uk/files.htm (additions when time permits).
2.3.1 Useful Starter pages
Complete list as notified to us is available on the GNUH8 web site links
page. Please forward any sites that should be added to the list on
http://www.gnuh8.org.uk/ links page.
Of particular note is the H8S and Cygwin starter page on:-
http://www.eclectic-web.co.uk/index.php?jump=mike/esource/h8300-dev.htm
2.3.2 Useful Starter Application
So you have the tools, an H8 and not quite sure how to build it up into
an application that does more than flash an LED, now what?
You could try looking at the example serial applications on the GNUH8
web site, that contains a fully flashable version of an application to
'talk' with the PC via a serial interface, using any terminal emulator
programme.
This application and source includes versions compiled into a S-Record
file to flash into
Standalone
H8/3067F in mode 5, with 20MHz clock.
H8/3048F in Mode 6, with 16MHz clock
EVB
H8/3067F in mode 5, with 20MHz clock.
H8/3048F in Mode 6, with 16MHz clock
See files section of http://www.gnuh8.org.uk/files.htm
2.4 Known workarounds for associated tools
This section is for problems with tools associated with the suite of
programmes normally received with GNU compiler from Renesas[1].
2.4.1 FLASH.EXE not working for many programming cycles
This is often seen as devices not programming reliably after a few
successful programming sessions. Some devices will fail on a couple of
programming sessions, others after 10 or 20 cycles.
Check the version of FLASH.EXE that you have installed (usual run the
programme and select Help - About), if the version is LESS than V1.55
get the latest version V2.1 or above. The programme downloaded is called
SETUP.EXE and is a straight executable that decompresses and configures
the software including backups of old versions.
This file is available from the Rensas[1] website look for Evaluation Systems
Support Center.
2.4.2 FLASH.EXE (V2.02) has no H8/3334 support
When installing the Flash.exe there is no support shown for H8/3334.
However it has been found that selecting H8/3434 works.
=======
Caveat Check this on your system.
2.4.3 FLASH.EXE (V2.02) does not work with my target board
Some people have reported problems mainly with Windows95 and Flash.exe
when connected to their target systems not finding the hardware. That
is timing out on trying to connect.
This appears to be a serial I/O problem in Windows 95 as the same
software and configuration will work under WfW V3.11.
As a general note serial comms and Windows is notoriously fraught with
problems of missing characters and improper FIFO support, such that
even for Windows for Workgroups Microsoft would recommend third party
drivers be used.
2.4.4 "Can I FLASH the H8xxxx ONLY 100 times?"
This must be the MOST asked question on the mailing list. Yes the Renesas
data sheets do state that they only guarantee the parts to be able to be
programmed for 100 times. However please bear in mind the following factors:-
(a) This is for the WHOLE temperature range of all the devices and variants.
(b) These are WORST case specifications.
(c) This is to guarantee the data retention life of the part meets the 10 or
50 years life in its data sheet.
(d) That the device can be programmed in the time specified.
(e) Renesas do not want to be sued.
As a device gets programmed more often, the data retention time of the device
MIGHT get shortened, it MIGHT take longer for the device to erased or
programmed.
Then bear in mind many users of the list have programmed the same device
300 to 1000 times without problems on their prototypes. Your production device
should not really need to be programmed more than 100 times in its lifetime
or its initial testing was not good enough.
If you need a device that is programmed that many times (storing images or audio
or logs), you generally need much more FLASH memory area, and something that can
be programmed a byte at a time, without special mode swapping of the processor.
Basically no one has come across life time issues or programming problems that
have not been overcome by newer programming tools or device types, that was sorted
out before 2000. We are well past the problems that older devices had.
Renesas have issued an update on a technical note that says that for MOST processors
the number of rewrites to flash (erase & write) is 100 MIN and 1000 or even 10,000
typically. Check if your processor choice is covered by theis or a later technical note.
The technical note is available from
http://www.renesas.com/avs/resource/japan/eng/pdf/mpumcu/tech/tnmc002ae.pdf
Or a copy fetched on 25th October 2003 from
http://www.gnuh8.org.uk/tnmc002ae.pdf
3. Documentation Errors
This refers to some older distributed Cygnus versions of the GNU tool chain
supplied by Renesas with Evaluation Boards.
Newer version of HTML format documentation including libc descriptions
is available from http://www.gnuh8.org.uk/files.htm in the files section.
The main gripes so far are that -
a) It is not easy to search on some keywords in Infoman
b) None of the documents actually state that to make a minimal startup kernel
it must be called crt0.o .
c) The DOS version refers to problem reports information and a programme
called send-pr . The programme does not exist on the DOS version
and unless you want to talk to sales at Cygnus don't bother emailing
them. See section 2.
Any other documentation issues gratefully accepted for inclusion.
3.1 Implementation Specific Behaviour
This section is for items that are implementation (of the compiler)
specific and no documentation about it has been found.
3.1.1 Storage of Bit Fields
Whilst this is implementation specific, no reference to it has been
found (willing to be corrected).
Unlike the majority of known implementations bit field storage is
MSB to LSB on the GNU compiler. So be careful when mapping registers
and or memory as to get the correct order.
e.g.
struct bits
{
unsigned char sign :1; /* bit 7 */
unsigned char flags :3; /* bits 6 - 4 */
unsigned char dummy :1; /* bit 3 */
unsigned char go :1; /* bit 2 */
unsigned char end :1; /* bit 1 */
unsigned char little :1; /* bit 0 */
} reg;
3.2 Hint and compiling special versions
The supplied Terminal Emulator programme HINT, comes with sources. However
when recompiling with any additions IGNORE all files EXCEPT HINT.C, and
recompile this file only. The code so far has been found to be portable
no reports of problems compiling with C compilers for PC host.
All other files in this directory are not needed and should be deleted
from your system as these are specific to the system that the executable
was built on and the version of Microsoft Visual C/C++ used to compile it.
Why these extra files were put on the distribution is not known as they
serve no useful purpose. The only file you need is HINT.C .
3.3 Hardware documentation errors
3.3.1 H8/3048
The documentation is not very clear that Mode2 pin for Flash Programming
is held at +12V, but the chip ONLY withstands this if +5V is STABLE FIRST.
Absolute maximum ratings is supposedly 13V on this pin, but that must be
read as 'Vcc + 8V', where Vcc is 5V when stable.
These days the problems with this device should NOT be seen as you should
be using Rev B silicon, which overcomes most of these problems.
3.3.2 H8/306x
Early versions of the PDF files had the pin setting for MD2 the wrong
way round for entering Flash Programming Mode, ensure you have Version
2.0 or later PDF files.
8 bit timers on Port B share functions with Chip Select and other
functions however, the descriptions for 8 bit timers and Port B tables
for what will be the pin function, show the Chip Select Enable bits
in CSR as being Don't Care ('-'), when the output mode bits OISn are
set. This is not true, examination of the block diagram section for Port B
reveals that the CSR bits MUST be set to 0, to avoid Chip Select
overriding all other functions. This is true as of September 2001 even
for the new H8/3068 device.
8 bit timers have other undocuemnted features in Input Capture mode,
and it is recommended that the description of these parts of the chip
is best taken from the H8/3068 PDF file (V2.0 or later) as the current
PDFs for other devices do not describe this properly.
As of September 2001 the PDF files are known to be at versions
H8/3062 ???
H8/3067 V3.00 22/2/99
H8/3068 V3.00 30/2/01
4. Workarounds
Some workarounds that have been found to work, as with everything else
it is your responsibility to FULLY test the workaround/fix for your
application.
Note unless explicitly stated otherwise 'C' denotes 'C or C++'.
If this is wrong let me know.
Sections staring 4.x.S are the solutions so far found if any to the
section above it 4.x .
4.1 Getting libc and libgcc to link into your application?
The tools as supplied by Renesas[1] are going to be mainly used for embedded
applications with NO operating systems, so you would expect that the
libraries supplied should be able to be linked in for functions such as -
i Multiplication (integer, long integer, float)
ii Division (integer, long integer, float)
iii Mod (integer, long integer, float)
iv String functions (as you have serial ports)
As these require no operating system, it would be normal to expect these
to link in. However as you will have made your own startup kernel to call
your C programme, probably following the Renesas[1] examples called this
start.s and compiled to start.o .
The problem is that this code stops crt0.o being linked in which stops the
libraries even being scanned!!
For some reason without a module called crt0.o, gcc and ld will not even
look at the libraries.
Conspiracy theorists will probably use this as ammunition to suggest that
somebody put this in to ensure newer or different compilers/emulators etc.
are purchased in preference to GNU ones.
4.1.S solution
This answer primarily works for older versions (V2.9.2 era) see below
for other notes.
Rename your startup assembler kernel to crt0.s, compile/assemble as
before, then when linking make sure the following options are set:-
H8300 -lc -lgcc -nostdlib
This causes the libraries libc.a and libgcc.a to be scanned
H8300H -Lc:\cygnus\lib\H8300H -lc -lgcc -nostdlib
This causes the libraries libc.a and libgcc.a to be scanned, by
looking in the correct directory. For some reason the linker uses
the WRONG libraries if '-L' option is omitted.
The search order is improved by doing '-lc -lgcc', well at least the
libraries are only loaded once, not twice.
IMPORTANT NOTE: Ensure the PATH to the libraries are correct, I have
been caught out when trying to compile on different
hosts, and the libraries were on a different DRIVE!
The '-nostdlib' helps with not loading the standard 'crt0.s' and
associated information.
If using other libraries for maths and other functions the better order
for libraries is:-
-lm -lc -lg -lgcc
Note that on most versions '-lc' is the same as '-lg' as the files are
identical on linux versions libg.a ('-lg') is only a link to libc.a ('-lc').
For newer versions V3.0.0 and above most people find that ensuring your
link stage contains the '-nostartfiles' option is the best method, whether
your startup file is called crt0.s or not.
Some have found that the '-L<library path>' to specify where to find the
libraries was not necessary, this has not been this FAQ author's experience.
Some differences seem to occur depending on whether the linker (ld) is
invoked from the makefile (or command line) as part of the 'gcc' command
or as a separate stage.
*4.2 Linker errors
*4.2.1 Linker 'undefined end statement' error
As was reported...
>Having used the solution described in FAQ 4.1.S I still get the error:
>
>c:/cygnus/bin/../lib/libc.a(sbrk.o)(.text+0xe):sbrk.c: undefined
>reference to `end'
>
>when trying to do use sprintf in stdio.h.
*4.2.1.S solution
A better solution is to use Newlib versions of the GCC tools
(see section 2.3 Alternatives), the older version of the fix is below.
sbrk.c is part of the C library associated with dynamic memory
allocation as most string functions create local variables from the
heap for temporary usage.
The 'end' reference is actually defined by you for the linker in your
'.lnk' file (make sure win9x or NT4 or later do not confuse this with
a shortcut). This is the file you instruct the linker about where to
put code and data segments in memory and is referenced with the '-T'
option on the 'ld' command line.
Remember this is the file that must have the CORRECT addresses set to
ensure correct address ranges for the intended CPU Mode.
Here is an example file (3048 Mode 6 on EVB-3048)...
ENTRY(_start)
OUTPUT_FORMAT(srec)
OUTPUT_ARCH(h8300h)
SECTIONS
{
.vectors 0x0400000 : { *(.vects); }
.text 0x0400400 : { *(.text); }
.mdata 0x040C000 : { _mdata = .; _data = .; *(.data) _edata = .; }
.bss 0x040F000 : { _bss = .; *(.bss) *(COMMON); _ebss = .; }
.stack 0x040FF00 : { _stack = .; *(.stack); _end = .; }
}
In this example pay attention the '.stack' line.
For more information consult the linker manual sections on the CD-ROM
and from the DOS command line use the command 'info ld' to start you
in the right direction. These contain descriptions of all the statements
and options for the link file.
*4.2.2 Linker places stack in wrong memory area
*
* A linked application has one or more memory segments filled with the
* wrong section of the application. For example is in wrong area of
* RAM.
*4.2.2.S solution
* In some cases the ALIGN statement in the linker script has been used
* incorrectly to ALIGN a memory section with respect to the previous
* section, when what was intended was to align the section on a n-byte
* memory boundary.
*
* For example the following is intended to place the stack section
* in internal aligned on a 4 byte boundary and bss section in external
* RAM (only relevant lines shown):-
*
* MEMORY
* {
* .....
* ext_ram : ORIGIN = 0x00420000, LENGTH = 131072
* ram : ORIGIN = 0x00FFB000, LENGTH = 16320
* }
*
* SECTIONS
* {
* ......
* .bss :
* {
* _bss = . ;
* *(.bss)
* *(COMMON)
* _ebss = . ;
* _end = . ;
* } > extram
*
* .stack ALIGN(0x04) (NOLOAD) :
* {
* *(.stack)
* _stack = .;
* } > ram
*
* This aligns the stack section on a 4 byte boundary FROM the bss
* section and takes precedence over the '> ram' statement to place
* in internal RAM.
*
* Changing the stack section definition to the following:-
*
* .stack (NOLOAD) :
* {
* . = ALIGN(0x04);
* *(.stack)
* _stack = .;
* } > ram
*
* Places the stack section in the memory area 'ram' and aligns its
* start address to a 4 byte boundary in that section. This avoids
* any confusion of precedence of operators on the section.
*
* Solution provided by Stefan Schober.
4.3 I don't know what crt0.o is doing?
Other than basic initialisation of memory and the like, no one has
revealed the source for crt0.o . But you can of course download the
source files (see section 2.2 and 2.3), if you so wish to find out.
4.3.S solution
Write your own based on the Renesas[1] examples call it crt0.s and see 4.1.S .
4.4 I want to do some system tests/diagnostics before starting C programmes?
This situation is something that several developers will want to do,
in order to check hardware on power up or reset, before running the
C programme.
Why would you want to do this? Well your programme is going to fail
in the field if the RAM is faulty and the first call to a function
gets wrong results.
4.4.S solution
Write your own assembler routines to do this, as part of the startup
kernel BEFORE the stack pointer is initialised, and in some cases before
any CPU registers are initialised for port modes.
Then follow the solutions in 4.1.S and 4.3.S .
4.5 Serial Ports
See also Section 2.3.2 above
4.5.1 Changing Baud Rates
Also seen as "Why do I lose characters, often two".
The problem here is that due to the way the buffering in the Serial units
and the methods required for changing Baud Rates, often programmers
forget to wait for the last byte to have transmitted.
This will happen if the software is monitoring the transmit buffer empty
flag (TDRE in SSR), whilst the TSR (Transmit Serial Register) is still
transmitting (or just loaded) a character.
If the transmitter is disabled too quickly it is possible to corrupt the
STOP bit of the previous character to the one just loaded into the TSR.
4.5.1.S solution
Monitor the TEND bit in the Serial Status Register, which indicates that
all characters have been completely sent, BEFORE following the procedures
to change Baud Rate. The first step of changing Baud Rate, is to disable
the transmitter and receiver, hence corrupting the transmitted data.
See also Section 2.3.2 above
4.5.2 Interupt Handling Routines
Several areas of caution here:-
1/ Try to use ALL interupt sources -
Receive Data Register Full
Receive Error
Transmit Data Register Empty
Transmit End
2/ Ensure Receive Error conditions can be aligned to data.
Use of large Receive buffers, may mean that valid data
is already stored in the Receive Buffer, and the error
condition will not affect the previous data.
This can be solved in many ways but is APPLICATION specific.
Some ways include using a 16 bit wide buffer to store error
bits as well as data, or not allowing new data to be stored
until the error condition is cleared.
3/ Last byte to send, causes extra interupts.
If the software uses the TDRE interupt (TXI), beware that the
only ways to clear this interupt is to write another byte to
the TDR or clearing of TIE (SCR) or TDRE (SSR). If the interupt
enable bit is not cleared first then once the character has been
sent, another interupt will occur.
Various solutions (NOT ALL tested) exist:-
a) Disable interupt enable before sending last character
b) At extra interupt Read SSR, check TDRE is 1, then
either
i Set TDRE to 0
or ii Set TIE in SCR to 0
c) Use TEND interupt for last character, so correct checks
can be made for any other characters added to the buffer
during the character transmission.
How the application software deals with this behaviour, is dependant on
your requirements and thorough testing is recommended.
4.5.2.S solutions
There is an example file of using serial I/O and gdb (GNU debugger) stubs
on the web site http://www.gnuh8.org.uk/files.htm files section.
This example was kindly supplied by Bill Knight of R O Software.
There are now several more serial comms examples on http://www.gnuh8.org.uk/files.htm .
See also Section 2.3.2 above
5. Contributors
Currently this consists of
Paul Carpenter - PC Services
With extracts of questions from the GNUH8 mailing list
Any other contributors can have their 'name in lights' if they so wish.
[1] As of 1st April 2003, Hitachi divisions relating to H8 are now known as Renesas
|
