***************************************************************************
*									  *
*		     (c) HUNT ENGINEERING 22-Mar-1996			  *
*									  *
*       Example Read and Write Performance Tests        		  *
*                                                       		  *
*   Release 2.5                                         		  *
*   Updated 12-Nov-1996                                 		  *
*                                                       		  *
*   HUNT ENGINEERING Driver Api Test Program
*									  *
***************************************************************************

			   THIS PACKAGE

The sources you have received contains example programs for reading
(reads.c) and writing (writes.c) to a C4x TIM on a HUNT ENGINEERING
motherboard using the HUNT ENGINEERING Api Drivers

Please note that these example programs, which we have explained fully in
the rest of this file are a FREE and UNSUPPORTED software package and
hence should only be used to help you develop your own applications to
your own standards whilst ensuring you are dealing with the TMS320C40
correctly.

Description
===========

Both programs boot a small program into the 'C40. In the case of reads
this is called "blow" and for writes it is called "suck". As the name
implies these are simple programs which act as universal source/sinks. No
source is provided for these routines - the TI 'C40 machine code is
embedded directly into the reads/writes programs. The machine code is
hard coded for a particular comport and so the reads/writes routine
modifies the embedded machine code depending on the Comport on the C40
used to communicate with the host.

Each program is passed a series of parameters via the command line to:

reads  Board Comport Start Increment End [BlockSize] or
writes Board Comport Start Increment End [BlockSize]

where:

Board           is the name of the API device (TIM Motherboard) - eg
                hep2d for the HEPC2M rev D, hep3b for the HEPC3 rev B,
                ...

Comport         is the Comport on the motherboard used to communicate
                with the TIM - typically A

Start           is the initial buffer size to be used

Increment       is the amount to increase the buffer size by for each
                step

End             is the final buffer size to be used

[BlockSize]     is set to 0 to indicate single word transfers

All parameters are in 32 bit Words

for example:

reads hep2d a 1000 2000 10000 0

        Uses Comport A on a HEPC2 rev D (the only Comport on this
        motherboard).

        Reads blocks of 1000, 3000, 5000, 7000, 9000 a word at a time

writes hep3b b 1000 10000 21000 1000

        Uses Comport B on a HEPC3 rev B.

        Writes blocks of 1000, 11000 and 21000

both will report the transfer rate in KBytes/sec (K=1024)

                   REBUILDING READS.EXE or WRITES.EXE
                   ==================================

It will be necessary to create either a Visual C++ V1.5 "Project" or a
V4.2 Workspace. In either case you will need to add the files

        reads.c or
        writes.c

to the project PLUS the appropriate file(s) from the API package and
rebuild. Where appropriate the LARGE memory model should be used        
Notes
=====

1) Reads and Writes have been modified to provide an example of using a
   separate device as the common reset in a system. For example on a
   board with two comports (or indeed two boards with 1 comport) and
   using a common reset on Port A but wanting to read and write on
   Comport B.

   Open ComportA, HeReset(), Close ComportA
   Open ComportB, read, write, ..., Close ComportB

   In practive you would keep the Reset port open to prevent any other
   program opening it and asserting reset!

2) These programs are written for the HUNT ENGINEERING API and so are
   designed to run without modification in all the API environments.

   In some cases (for example Master Mode on HEPC3 rev B) it is required
   that any data buffers are 32 bit aligned. Simply declaring an array of
   32 bit data items (HE_DWORDs) is not enough. As the examples show the
   best mecahanism is:

   a) Initialise a HE_DWORD array of data (eg SuckData in reads)
   b) use HeAlloc() and HeLock to get a pointer to a suitably block of
      memory (eg Suck in reads)
   c) copy the array into the aligned area and use this henceforth

   Use the HeAlloc()'d memory in all API reads and writes.
