Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!think!nike!ucbcad!ucbvax!CORY.BERKELEY.EDU!dillon
From: dillon@CORY.BERKELEY.EDU (Matt Dillon)
Newsgroups: net.micro.amiga
Subject: Re: Sending multiple chars out serial port
Message-ID: <8608211935.AA10377@cory.Berkeley.EDU>
Date: Thu, 21-Aug-86 15:35:13 EDT
Article-I.D.: cory.8608211935.AA10377
Posted: Thu Aug 21 15:35:13 1986
Date-Received: Thu, 21-Aug-86 22:30:00 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: University of California at Berkeley
Lines: 24


>\From dyon Wed Aug 20 22:35:49 EDT 1986
>Ok, this function works perfectly if "length = 1", ie if you are only
>writing one character out the port.  However, if we are writing a
>known length string out the port, say "char data[5] = {'h','e','l','l','o'} "
>and we give data = &data[0] and length = 5, then we get maybe the
>first two characters received by the serial listener fine, but the rest
>is random garbage chars.  By the way, this occurs at Baud rates as slow
>as 300, and with parity, stop bits, write bits identical on both ends
>of the serial port.

	Hmm.. I write out large buffers at a time myself, but have not
had similar problems.  Even though you have said the parity and stop
bits were identical on both sides, I think it is a problem with the 
latter (Q: what about WORD length?)... one usually gets that sort of
result (a couple good chars then garbage) when there is a discontinuity
in parity or word length.

	Are you using Xon-Xoff? 7-Wire? 

	I suggest you make sure your your SDCMD_SETPARAMS call is NOT
returning an error (due to having illegal fields).

				-Matt