chin-lon@puff.UUCP (04/18/87)
Sorry about a few mistakes in that last posting on serial interrupts. My question was actually on setting up interrupt handlers, not servers. And when I said SetIntVector(), I actually meant the call that would let me set a new interrupt handler. (Don't remember the name off-hand). the question still remains, though. Chin-Long Cheng
dillon@CORY.BERKELEY.EDU.UUCP (04/19/87)
I have never had problems with the EXEC serial.device ... especially with 1.2 . I would strongly suggest that you use the device instead of writing your own interrupt handler. Most people's problems with the serial.device is from a lack of understanding of how it works rather than bugs in the actual device. Assuming you use the EXEC serial.device, having multiple tasks writing to the serial port at the same time is trivial... they just do it. If you want to arbitrate exclusive access, simply have all the tasks use a Semaphore or something before doing the operation. (that is, you still open the serial.device with shared access). -Matt
chin-lon@puff.WISC.EDU (Chin-long Cheng) (04/19/87)
In article <8704190128.AA19495@cory.Berkeley.EDU>, dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: > > I would strongly suggest that you use the device instead of > writing your own interrupt handler. But I do need to use my own interrupt handler as the serial.device isn't fast enough for the midi application that I'm doing. (31.25K with quite a bit of real time data handling) > > If you want to arbitrate exclusive access, simply have all the tasks use a > Semaphore or something before doing the operation. (that is, you still open > the serial.device with shared access). > I need to do this without using Semaphores, as the tasks would be independt and each won't know how many of the others exist. So the question remains: how can I coordinate between processes using serial.device and interrupt handlers? > -Matt Chin-Long Cheng
brianr@tekig4.UUCP (04/24/87)
Responding to a plaintive posting from a frustrated novice,
Matt Dillon encouraged: "...I have never had problems with
the EXEC serial device...".
I've recently spent two days figuring out how to open the
serial device in exclusive-access mode, for TRANSMIT only,
and send a single character to another piece of equipment.
Matt's offhandedness struck me like Arnold Schwartzenegger
remarking that no, he wasn't bothered by inconsiderate or
discourteous behavior while traveling on subways.
In case it is any benefit to fellow mortals, I'd like to
explain how I managed to foul up such a simple operation:
I allocated an IOExtSer structure, filled its appropriate
slots with my desired baud rate settings, flags, parity modes,
and so forth, and then passed it to OpenDevice. I then
merrily set the io_Command field to CMD_WRITE, pointed
io_Data at my transmit buffer, and tried to do SendIOs.
It turned out that, regardless of how I initialized some of
the serial device parameter fields (such as baud rate)
in the IOrequest that gets passed to OpenDevice, they got
RESET to default settings during the device open operation.
If you don't want the default baud rate (9600 baud), you
need to use the SDCMD_SETPARAMS IO command to set the baud
rate as you want it, AFTER opening the serial device.
I looked through the Kernel manuals pretty thoroughly, and
I couldn't find any mention of this fact. In Basic,
(I used a quick Basic program to assure
myself that my hardware wasn't broken)
the same statement that opens the serial device simultaneously
sets baud rate, parity mode, and word size; it's not unreasonable
to assume that, unless stated otherwise, the OpenDevice routine
should work similarly.
Unless I'm much mistaken, SOME of the parameters of the IOExtSer
structure DO affect what OpenDevice does: the receive buffer-length
control, for instance. I probably ought to try looking at what
OpenDevice does to a completely filled-out IOExtSer form to learn
which fields get overwritten with defaults.
A question for the craftmasters: Is it possible to do "quick" I/O
for serial transmissions (CMD_WRITE with IOF_QUICK set)?
I tried it on a 4-byte message, and the IOF_QUICK flag came
back cleared, which I gather is Exec's way of saying "I'll get
back to you later".
Doesn't the serial device driver maintain a transmit buffer, into
which BeginIO could instantly copy my piddly 4-character message?
Providing amusement for the competent,
===================================================================
| Brian Rhodefer | uucp {ucbvax,decvax,ihnp4} |
| Tektronix, Inc. | !tektronix!tekig4!brianr |
| Lab Instruments Division | CSnet tekig4!brianr@tek |
| MS 39-152, PO Box 500 | ARPAnet tekig4!brianr.tek@csnet-relay|
| Beaverton OR 97077 | Verbal Net (503) 627-3898 |
===================================================================