This example serves two purposes:  1) It demonstrates connection of an ethernet network driver     to the pSOS Networking Architecture (pNA),  2) It demonstrates how to write a serial communication driver     for serial host communication (the TCS "-host serial").pNA Network Driver------------------	Source files dec21140.h/dec21140.c contain an ethernet driver for a	DIGITAL 21140 Ethernet LAN controller. This driver currently works	in little endian mode only, and has to be enabled using the following	modifications in the pSOS application configuration file:		target/sys_conf.h:		/***********************************************************************/		/*                                                                     */		/*              L A N   C O N F I G U R A T I O N                      */		/*                                                                     */		/*                                                                     */		/***********************************************************************/		#define SD_LAN1               YES		#define SD_LAN1_IP            0x828c21b4  /* 130.140.33.180 */		#define SD_LAN1_SUBNET_MASK   0xffffff00						/*=====================================================================*/		/*                                                                     */		/*                    L A N   I N T E R F A C E S                      */		/*                                                                     */		/*   * BSP_LAN1            - YES if LAN is supported                   */		/*   * BSP_LAN1_MTU        - Maximum transmission unit (bytes)         */		/*   * BSP_LAN1_HWALEN     - Length of hardware address in bytes       */		/*   * BSP_LAN1_FLAGS      - Interface flags (per pNA manual)          */		/*        IFF_POLL             0x8000   interface is a polling type    */		/*        IFF_BROADCAST        0x0001   NI supports broadcasts         */		/*        IFF_RAWMEM           0x2000   driver uses "mblk" interface   */		/*   * BSP_LAN1_PKB        - Total number of packet buffers            */		/*                                                                     */		/*=====================================================================*/				#define BSP_LAN1               YES		#define BSP_LAN1_MTU           1500		#define BSP_LAN1_HWALEN        6		#define BSP_LAN1_FLAGS         0x2001		#define BSP_LAN1_PKB           40						/***********************************************************************/		/*                                                                     */		/*         M I S C E L L A N E O U S   N E T W O R K I N G             */		/*                       P A R A M E T E R S                           */		/*                                                                     */		/***********************************************************************/		#define SD_DEF_GTWY_IP        0x828c21fb  /* 130.140.33.251 */					Note that the IP address- and subnet mask values are examples here only, 	and are dependent on the user's own network.		The dec21140 driver itself contains the following configuration parameters:		target/dec21140.h:			/*---------------------------------------------------------------------*/		/* PCI address of the chip's Control and Status Registers              */		/*---------------------------------------------------------------------*/		#define LAN_PCI_IO_BASE     0x02000000		target/dec21140.c:		/*---------------------------------------------------------------------*/		/* Ethernet hardware addr, and selection of whether to use 10BaseT     */		/* or AUI interface for the LAN.  Both of these variables are hardcoded*/		/* here, but when the same binary should run on a variety of machines  */		/* (each with e.g. their own hardware address), then their values      */		/* should be read from e.g a flash file at startup, in function        */		/* 'lanInit'.                                                          */		/*---------------------------------------------------------------------*/		static UCHAR EtherHwAddr[6] = {0x00, 0x40, 0x05, 0xA4, 0x6D, 0xF8 };		#define Lan10BaseT    1				Finally, the standard pSOS makefile should enable pNA by		target/Makefile:		#-------------------------------------------		# (Sub)component enabling/disabling switches:		#				PNA = pna		Serial Host Communications Driver---------------------------------	This examples also demonstrates a serial driver that 	completes the generic serial host library that can be	used for dispatching I/O via a serial form	of communication to a corresponding rpc server.	The TM-part of the example, plus driver, is found        in the 'target' directory (driver in target/SerialRPC.c),        and the host part of the example in the 'host' directory        (host part of driver in host/SerialRPC.c).	 	This particular serial driver communicates	with the serial TM-1 application via tcp/ip,  	using a socket as serial connection. 	During initialization, this target part of the driver         waits until the serving host connects to a server port.	This port is currently hardcoded in the driver, but this         is easy to change.	 	The target part of the communication driver is implemented on top	of the pSOS Network Architecture component (pNA),	and hence can *only* be used for psos-based applications	that have network access. Network access for this        example is provided by the dec21140 ethernet driver.		Apart from this user visible aspect, using pNA	introduces the following complications, which make	the target driver somewhat more complex than its host	counterpart:	 	1) I/O initialization, which is normally performed	   at startup of the Trimedia runtime support, has to 	   be postponed until pNA is fully active. That is,	   in the root task.	   This postponing is achieved by disabling the standard	   I/O support in function SerialRPC_init, and doing	   the actual initialization in a new function SerialRPC_start.	   SerialRPC_start is to be explicitly called from the root	   task when it wants to do I/O, as in			  		     void root()		     {		       SerialRPC_start();		       ...	 	2) In pSOS/pNA, a socket can only be used by the task	   that created it. For other tasks, synonyms have to 	   be created by means of function shr_socket.	   For this reason, a reader- and a writer task is	   created to do the actual socket communication.	   Application tasks that want to do I/O communicate	   with these tasks using message queues.	  	Some implementation notes:	 	1) The initialization routine creates both queues first,	   and then both tasks. The initialization routine awaits	   until the reader task starts serving; this reader task	   will await the writer task, and then create both sockets	   before it releases the initialization routine. This 	   synchronization will prevent race conditions during startup.	 	2) Written data (to the host) is accumulated into packets	   of a specific size, when possible. This avoids the sending	   overhead of small data buffers. Buffering is done in a	   buffer 'mtu_buffer'. The packet size assumes ethernet here.	   Buffering output data also keeps the initial endian probe	   message to the host (which is sent during RTS initialization) 	   until pNA is up and running.	The example program itself--------------------------        The program does not have to do anything for enabling pNA,        since this is all steered by the modifications to sys_conf.h        and the Makefile. However, it has to perform the postponed         initialization of the serial host communication (NOTE: this         is only necessary in this particular serial driver, because         it is implemented on top of pSOS itself; in general the serial         driver is transparently started during system startup).        	target/root.c:            void root()            {                          SerialRPC_start();              ...        After this initialization, the program performs a file I/O test.How to run the example----------------------	Starting a TM-1 application and its serial server	is to be performed using the following steps:	  	1) start the TM-1 application.	 	2) start the serial server on a PC or Unix machine	   that can reach the TM-1 application via tcp/ip.           The serial server will connect with the TM-1           application; Stdin, stdout/stderr of the TM-1 application 	   will be mapped to the stdin, stdout/stderr of the	   server process (on PC or Unix), and file I/O will	   be effectively performed by this same server process.