H8 logoH8 logo

GNUH8 Support

GNU compilers and Renesas[1] H8 series microcontrollers

H8 Chip logo

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


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  Interrupt 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 responsibilities 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'

    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


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

    Windows -
      Recommended Versions for Windows/DOS is the MingW version

    Older distributions -

    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 explained 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:-


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

    This application and source includes versions compiled into a S-Record
    file to flash into

	 H8/3067F in mode 5, with 20MHz clock.
         H8/3048F in Mode 6, with 16MHz clock

	 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

    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
    Or a copy fetched on 25th October 2003 from

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.

         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

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

        .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):-
*    {
*     .....
*     ext_ram  : ORIGIN = 0x00420000, LENGTH = 131072
*     ram      : ORIGIN = 0x00FFB000, LENGTH = 16320
*    }
*    {
*    ......
*    .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 Interrupt Handling Routines

    Several areas of caution here:-

        1/  Try to use ALL interrupt 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 interrupts.
            If the software uses the TDRE interrupt (TXI), beware that the
            only ways to clear this interrupt is to write another byte to
            the TDR or clearing of TIE (SCR) or TDRE (SSR). If the interrupt
            enable bit is not cleared first then once the character has been
            sent, another interrupt will occur.

            Various solutions (NOT ALL tested) exist:-
                a) Disable interrupt enable before sending last character
                b) At extra interrupt Read SSR, check TDRE is 1, then
                        i       Set TDRE to 0
                     or ii      Set TIE in SCR to 0
                c) Use TEND interrupt 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
If you encounter problems with this page please email your comments to webmaster
© 1998 onwards by PC Services Last Updated: 28th December 2006