[net.micro.amiga] Sending multiple chars out serial port

dyon@batcomputer.TN.CORNELL.EDU (Dyon Anniballi) (08/21/86)

From dyon Wed Aug 20 22:35:49 EDT 1986


(sorry if you are getting this twice, but I think it didn't make it out the
first time)

   Hello again,
As readers here might have noticed, we (hsgj and I) have detected some
"irregularities" with the Amiga Kernel while writing our applications.

This time, the trouble is with writing to the serial port.  First, for
your enjoyment, some code right from the RKM:

WriteSer(io,data,length)
struct IOExtSer *io;
char *data;
int length;
{
	io->IOSer.io_Data = (APTR)data;		/* Abridged version */
	io->IOSer.io_Length = length;		/* to speed typing */
	io->IOSer.io_Command = CMD_WRITE;
	return(DoIO(io));
}

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.  At first I thought it was overwriting an output
buffer, but I guess "data" points to the output buffer.  So we can't
figure out why we can't send the string.
   Our temporary solution has been to do a for loop and just send each
individual char out with length = 1; this works fine.  But this is
not very nice at high bauds, so if anyone has any clues as to our 
problem, it would be appreciated.
   Note that this symptom appeared in Workbench v1.1.  We upgraded to
V1.2 beta 4 recently, but the problem still persists.

Thanks much, 
-- JR
UUCP: ihnp4!cornell!batcomputer!dyon
ARPA: dyon%batcomputer@cu-arpa.ccs.cornell.edu

dillon@CORY.BERKELEY.EDU (Matt Dillon) (08/21/86)

>\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

dss@cubsvax.UUCP (David Silver) (08/22/86)

In article <batcompu.915> dyon@batcomputer.UUCP (Dyon Anniballi) writes:
>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

I have had no problem sending any number of chars out through the serial
port at 31.25 Kbaud (midi rates) using appropriately set io_Length and
io_Data fields in my IO request structure.  I have exercised no voo-doo
which is not easily found in the RKM.  I'm running V1.1 WB.

Sorry I can't corroborate your findings, but maybe this will serve to
convince you to look elsewhere for the source of your difficulty.
I would be glad to mail you some code, but as I say, it's right out
of the RKM.

-- 
David Silver
{philabs,rna}!cubsvax!dss
cubsvax!dss@columbia