finnegan@bonnie.ics.uci.edu (Greg Finnegan) (09/25/88)
I need to send ASCII characters out a serial port to another (ancient) device
that uses hardware handshaking. My application has to detect whether output
has been suspended within one (actually two, but why take chances :-)
character.
Here is the code fragment I'm using:
{Preface: I'm using the RAM serial drivers}
{error handling and other non-essential code eliminated for clarity}
for i := 1 to NumChars do begin
Err := SerStatus(outRefNum, serSta);
if serSta.ctsHold > 0 then begin
SysBeep(1);
exit;
end;
Err := FSWrite(outRefNum, oneChar, @MyChar);
end;
This works only intermittently (I imagine when force the device off-line
at just the right time). Usually, it just hangs within FSWrite until
I put the device back on line. I hope that it is just something I'm not
setting up properly, or another call I need to make...
Could anyone out there lend some advice?
Greg Finnegan
finnegan@bonnie.ics.uci.educhrisj@cup.portal.com (09/26/88)
W.r.t. Message-ID: <746@paris.ics.uci.edu>, here are a few thoughts on
Greg Finnegan's (finnegan@bonnie.ics.uci.edu) problem of driving a serial
output device which requires prompt attention to its deassertion of CTS:
Consider the following possible sequence of events:
Byte 0 has been transmitted completely to your device. The output data
register (o.d.r.) of the Serial Communications Chip (SCC) became empty,
so the driver deposited byte 1 into it, and returned from your second
FSWrite. Byte 1 is now on its way through the SCC's shift register, the
cable, and the printer's receiving hardware, to the printer.
You return to the top of the FOR loop, find that ctsHold is still 0, and
issue another FSWrite, for byte number 2. While byte 1 is on its way out,
the serial driver loops until two conditions are true simultaneously: the
o.d.r. must be empty, and CTS must be true. While the driver is busy-
waiting for this condition, the device decides that it doesn't want any
more characters for a while, so it makes CTS false, and the change of state
propagates along the cable to your Mac (taking non-zero time which depends
on the cable's length and transmission characteristics (capacitance etc),
but is probably much less than the time to send a byte out through the SCC).
Your Mac will now stay in that loop in the serial driver until the device
once again asserts CTS.
====
I suggest the following:
1. Trust the serial driver NOT to send out characters while CTS is
false: don't try to second-guess the system software unless you KNOW
it's buggy. (I assume that you call SerHShake to enable hardware
handshaking.)
2. If you want to get control back after the write even if it does
not complete promptly, use the Asynch option of the low-level call,
PBWrite (@myParamBlk, TRUE), then loop until either the write operation
completes (myParamBlk.ioResult <> 1), or serSta.ctsHold becomes non-0,
whichever happens first.
Since you exit the procedure if the device drops CTS, myParamBlk must NOT
be a local variable of the procedure: it must stay around until either
1) the operation completes, or 2) you issue a PBKillIO. Don't change the
contents of the buffer pointed to by myParamBlk.ioBuffer, either.
You could even do a single asynchronous PBWrite for many bytes, and
put a check for either the completion of the write or the deassertion
of CTS, whichever comes first, into your event loop.
Christopher Jewell chrisj@cup.portal.com sun!cup.portal.com!chrisj
"I figure the people who close zoos at night know what they're doing."
Mike Royko (on night baseball at Wrigley Field)tel@adimail.UUCP (Terry Monks) (03/26/91)
I bought an excellent 4-port serial card from Taniwha systems so that I could run my bulletin board on a Mac IIfx and still have more serial ports to play with. My (naive) assumption was that I could put the Imagewriter printer, MacRecorder MacVision, Localtalk, MIDI and anything else I wanted on this card. Well I can...but the Chooser doesn't know about the card - because it is not aware of the Communications Toolbox? And Farallon tells me that it is impossible to have the MacRecorder software be aware of any other port. This I frankly disbelieve, but the telephone contact was not a programmer. He claimed that the Communications Toolbox was so buggy they did not want to use it! Farallon is one thing, but Apple is different. I do not see why the Chooser is not aware that there might be other things available besides Modem and Printer outputs. Why does it not knwo about the things that the Communications Toolbox knows about? I am running system 7.0b4 in case anyone cares. -- Terry Monks Automata Design Inc (703) 472-9400