Dec 242017
Asynch classes for Smalltalk/V for OS/2 (32 bit). | |||
---|---|---|---|
File Name | File Size | Zip Size | Zip Type |
ASYNCOS2.ST | 30886 | 5492 | deflated |
READAOS2.TXT | 3450 | 1475 | deflated |
Download File ASYNC2.ZIP Here
Contents of the READAOS2.TXT file
READAOS2.TXT May 28, 1993
To Install ComX Device support for OS/2, fileIn 'ASYNCOS2.ST'.
Briefly, the following describes how to use the AsyncDevice
class, and objects instantiated from it:
1. Set the input buffer size for the class by sending the
AsyncDevice class the message #bufferSize:.
You probably will only do this once for each application,
and it should be set to a value which will never be exceeded
by the number of bytes sent by the externally attached device
before your application can read them.
2. Send the AsyncDevice the message #open: 'COMn', with the n
replaced by the appropriate number.
3. Send whatever configuration messages to your new AsyncDevice
instance as are appropriate to your communications needs.
#bitRate: will almost certainly be one of them, and others
may be those which change the line control characteristics
of the OS/2 device driver.
4. Read, write, and be merry. See below for your reading choices.
5. Send the #close message to the device. If you're using the
#readProcess mechanism. the reading Process will then commit
suicide, as it should.
Reading from the Device:
You have three choices for how you can process the incoming
data stream:
1. Send the #readProcess message to your AsyncDevice object,
then send #readNext and/or #readNextByte to get one byte
at a time. The buffers will clean themselves up whenever
you do a read with nothing in the buffer to read, so it's
very important to get ahead of the incoming data with some
regularity. You can mix #readNext and #readNextByte at will.
2. Send the #readProcess message to your AsyncDevice object,
then send #readString to suck up everything in the buffer
at once. The buffers will clear themselves with each
#readString, so in this case you have to send #readString
often enough to never let the buffer get full between any
two #readString messages. You CANNOT mix #readString with
#readNext and #readNextByte, unless you're very careful about
jumping through all the right logical hoops.
3. If you're really brave, you can dispense with the AsyncDevice
readBuffer altogether, and send #readQueue to simply return a
String containing whatever OS/2 has in its 5120 byte buffer.
This is really included only for simplifying testing, but it's
there if you think there's some advantage to it.
Writing to the Device:
Just send either #write:,
or #writeCharacter: to your AsyncDevice object.
To see if you've got it working, and to show a simple example,
edit, select, and DOIT the following after connecting a Hayes
compatible modem to your serial interface:
| ad |
ad := AsyncDevice open: 'COM1'.
ad bitRate: 19200.
ad write: ( 'at&v' , ( String with: (13 asCharacter) ) ).
DosLibrary sleep: 1000.
ad readQueue.
What's Missing:
1. Support for DMA/Enhanced Com Devices
2. Error/Status interpretation and monitoring
Thanks go to Gurujees Khalsa for the original!
Send comments and questions to Bob Gleason, CI$ ID 70473,77
To Install ComX Device support for OS/2, fileIn 'ASYNCOS2.ST'.
Briefly, the following describes how to use the AsyncDevice
class, and objects instantiated from it:
1. Set the input buffer size for the class by sending the
AsyncDevice class the message #bufferSize:
You probably will only do this once for each application,
and it should be set to a value which will never be exceeded
by the number of bytes sent by the externally attached device
before your application can read them.
2. Send the AsyncDevice the message #open: 'COMn', with the n
replaced by the appropriate number.
3. Send whatever configuration messages to your new AsyncDevice
instance as are appropriate to your communications needs.
#bitRate: will almost certainly be one of them, and others
may be those which change the line control characteristics
of the OS/2 device driver.
4. Read, write, and be merry. See below for your reading choices.
5. Send the #close message to the device. If you're using the
#readProcess mechanism. the reading Process will then commit
suicide, as it should.
Reading from the Device:
You have three choices for how you can process the incoming
data stream:
1. Send the #readProcess message to your AsyncDevice object,
then send #readNext and/or #readNextByte to get one byte
at a time. The buffers will clean themselves up whenever
you do a read with nothing in the buffer to read, so it's
very important to get ahead of the incoming data with some
regularity. You can mix #readNext and #readNextByte at will.
2. Send the #readProcess message to your AsyncDevice object,
then send #readString to suck up everything in the buffer
at once. The buffers will clear themselves with each
#readString, so in this case you have to send #readString
often enough to never let the buffer get full between any
two #readString messages. You CANNOT mix #readString with
#readNext and #readNextByte, unless you're very careful about
jumping through all the right logical hoops.
3. If you're really brave, you can dispense with the AsyncDevice
readBuffer altogether, and send #readQueue to simply return a
String containing whatever OS/2 has in its 5120 byte buffer.
This is really included only for simplifying testing, but it's
there if you think there's some advantage to it.
Writing to the Device:
Just send either #write:
or #writeCharacter:
To see if you've got it working, and to show a simple example,
edit, select, and DOIT the following after connecting a Hayes
compatible modem to your serial interface:
| ad |
ad := AsyncDevice open: 'COM1'.
ad bitRate: 19200.
ad write: ( 'at&v' , ( String with: (13 asCharacter) ) ).
DosLibrary sleep: 1000.
ad readQueue.
What's Missing:
1. Support for DMA/Enhanced Com Devices
2. Error/Status interpretation and monitoring
Thanks go to Gurujees Khalsa for the original!
Send comments and questions to Bob Gleason, CI$ ID 70473,77
December 24, 2017
Add comments