

The linSerial class provides a simple, basic framework
for managing a serial port.  The design of this class 
is focused on making serial port easy to use.  The 
methods are simple and take simple arguments, hiding
the complexity of the full Linux/Unix termios interface. 
Only a small portion of the full termios function is 
exposed; to get at additional function, study the 
termios(3), stty(1), setserial(8), and statserial(1)
manual pages.

One convenience offered by this class is fairly verbose
error message reporting.  Although most methods return
a non-zero value to indicate that an error has occured,
one can instead have error, warning and informational
messages printed to stdout.  See the ErrLog class for 
details on enabling, disabling, and changing the amount
of error reporting.

--linas

DEBUGGING:

> I have problems writing to the COM2. I'm loosing an undefined amount of
> data at a speed of 9600bps. 

I have not had a similar problem, and I can only guess.
-- are you writing binary data? then you want to put the port
   into "raw" mode, so that data isn't mistaken for carriage 
   returns, form feeds, etc.

-- ascii data -- make sure parity, number of stop bits, etc are ok.

-- is the device your connecting to an async serial device?
   synchronous serial devices won't work with COM ports,
   and usually need specialy serial controllers.

-- are you using hardware flow control, or software? w/ software flow
   control, the bytes ctrl-q and ctrl-s are interpreted as start-stop
   messages.  Most modern hardware support hardware flow control;
   set te uart itself to run at 115200 baud (with seterial), and use 
   the termios programming interface to run at 9600.  The hardware 
   will do the rest.

-- do you have interrupt and/or port conflicts?
   use setserial, statserial to determine port status,
   cat /proc/interrupts cat /rpoc/ioports to see where the serial ports
   are configured, and to search for conflicts ...

------------------------------------------------------------------

> After I open and close /dev/ttyS1 once, when I try to open it a
> second time, it hangs in the open() call.  What's wrong?

I beleive that this is the correct behaviour.  Normally, /dev/ttyS* are 
used to handling incoming calls, while /dev/cua* are used to make
outgoing calls.  The first time you open /dev/ttyS*, you can configure
the modem.  The second time, it will hang in open() until someone calls
the modem, the modem auto-answers and connects.  This allows daemons
(e.g. fax servers) to wait until they are called, without having to
waste CPU cycles polling the status of the modem.


