dyon@batcomputer.TN.CORNELL.EDU (Dyon Anniballi) (08/18/86)
From dyon Sun Aug 17 18:28:22 EDT 1986
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.edudaveb@cbmvax.cbm.UUCP (Dave Berezowski) (08/22/86)
> 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 The above code should work verbatum. HOWEVER, if you are using SendIO instead of DoIO then LET THE BUYER BEWARE! If you call an asynchronous routine like SendIO for the serial port then you must assume that it owns the variables you pass to it until it has completed NOT neccessarily when it returns from the call. In this case you are passing a pointer to your data. If you alter the pointer OR change the data in the buffer before the serial device is finished sending it, you'll get garbage chars. I had this bug and fixed it by copying the data to a local buffer before doing the SendIO so that I could use my other vars while the chars were being sent out. I know that I didn't answer your question directly but I wanted to give you some insight into what would happen if you ever use SendIO. Hope you find your bug! Regards, David Berezowski.