narealport: NET+RealPort Example Application

This application demonstrates the RealPort COM port redirection server API.
The application does the following:

1.  The development board is initialized and the POST tests
    are executed.
2.  The ThreadX kernel is loaded.
3.  The device drivers are loaded.
4.  The TCP/IP stack is loaded.
5.  Serial COM ports are registered for use with the RealPort server.
6.  RealPort server daemon is started, and the application is suspended.

BSP setup:

For Digi Connect ME 9210:

1. Make sure the serial port PORTA is enabled as UART port. This
is done by setting the following define in bsp_serial.h:

#define BSP_SERIAL_PORT_1       BSP_SERIAL_UART_DRIVER

2. Make sure the CLI does not use the above PORTA ("com/0") in bsp_cli.h.

3. Make sure the stdio port does not use PORTA ("com/0") in bsp_sys.h.

4. Connect a loopback connector to PORTA.

5. Change the following line of code in root.cxx

#define REAL_PORT_DEVICE              "/com/1"
to:
#define REAL_PORT_DEVICE              "/com/0"

For other platforms:

1. Make sure the second serial port PORTB is enabled as UART ports. This
is done by setting the following define in bsp_serial.h:

#define BSP_SERIAL_PORT_2       BSP_SERIAL_UART_DRIVER

2. Make sure the CLI does not use the above PORTB in bsp_cli.h.

3. Make sure the stdio port does not use PORTB in bsp_sys.h.

4. Connect a loopback connector to PORTB.


PC setup:

    You must first install Realport on your PC.  Realport can be found on 
    the tech support web site:

    http://www.digi.com/support/productdetl.jsp?pid=3037&osvid=0&s=261&tp=1

    Select your computer's OS (i.e., Microsoft Windows XP), download and 
    extract into a clean directory.  Then follow the directions in the 
    readme file.

    The simplest Rptest test is send data slowly to the port. Suppose 
    you have a 1-port device on COM5 (COM5 is the virtual PC COM port 
    and is corresponding to your board's physical port PORTB) and you want 
    to send data at 9600 baud with no hardware flow control.  The following
    will do this:

    rptest -bxp 5 -bps 9600
    
    The test will succeed after 10 packets of 1152 bytes each for TX and RX.

    A more rigorous Rptest scenario is to flood the port with data. When 
    doing so, hardware handshaking should be enabled, otherwise data can get
    dropped, and rptest will fail.  To enable hardware flow control, setup
    the appropriate BSP serial channel for either 4-, 6-, or 8-wire serial 
    multiplexing.  For example, in gpio.h:

        #define BSP_GPIO_MUX_SERIAL_B   BSP_GPIO_MUX_SERIAL_4_WIRE_UART

    And to send data at 115200 baud with RTS/CTS hardware flow control, do this:

    rptest -bxp 5 -bps 115200 -rts 2
    
    The test will succeed after 10 packets of 1152 bytes each for TX and RX.	

    Rptest is very configurable; type rptest /? to see the comprehensive 
    on-line help. There are quite a few options.
    
    You'll notice that rptest displays average throughput and bytes sent/received 
    as it runs. Hit Ctrl-c to stop the test and see the final results. If youd 
    instead like the test to stop on its own, change the number of buffers with 
    -nob to something positive, or set the time to run w/ the -ttr option, i.e., 
    -ttr 60000 would run a 60-second test. 

    Note this test will fail without RTS/CTS handshaking.  That requires the
    BSP to configure the serial port with at least 
    BSP_GPIO_MUX_SERIAL_4_WIRE_UART multiplexing.

One GNU make file is provided.  Build the target 'image' to
generate an image that can be debugged with gdb, and the file 
image.bin which can be written to flash if the bootloader is used.


The following files are provided with this application:

appconf.h           sets application configuration settings
makefile            Make file for the GNU toolset.
readme              this file
root.cxx            contains the applicationStart() function, that
                    creates an application thread
                    
In addition, the following files in the BSP directory are built
as part of this application:

reset.s         contains the reset code
appconf_api.c   contains run time access to the application configuration

The application uses the following files located in the
netos\src\linkerScripts directory.  These files are generated
when the BSP is built.

bootldr.dat     bootloader configuration file used to generate the
                file image.bin.  It controls the information placed
                in the bootloader header of the image.

image.ldr       GNU linker script used to build an image that can
                be debugged and used with the bootloader.
                
customize.ldr   Customizable GNU linker script
