milikich@iccgcc.decnet.ab.com (Mike Milikich, Allen-Bradley Company) (09/19/90)
I am writing an application which needs to communicate with an external device (a network bridge, actually) through the modem or printer ports. I have two questions : 0) Can anyone direct me to some sample code which uses the RAM serial driver to read and write bytes to/from either port? In fact, is the RAM serial driver the best way to do something like this (what are the options / pros / cons)? 1) Is it a safe or sanctioned operation to use nullEvent to read any received data from the serial port? What I need to do is allow event processing to continue while I am waiting for replies. Something that might simplify this is that there are no unsolicited responses, so I know when to look for received data : only after I've sent some out. But while I am waiting for a reply packet, I want to continue to respond to user input. -- -------------------------------------------------------------------------------- | milikich%iccgcc.decnet@consrt.rok.com |"...and the men who hold high places | | allen-bradley company | must be the ones to start..." | | 747 alpha drive |--------------------------------------| | highland heights, ohio 44143 | I don't speak for A-B, | | (216) 646-3494 FAX : (216) 646-4343 | and I know they don't speak for me. | --------------------------------------------------------------------------------
russotto@eng.umd.edu (Matthew T. Russotto) (09/20/90)
In article <1021.26f75aef@iccgcc.decnet.ab.com> milikich@iccgcc.decnet.ab.com (Mike Milikich, Allen-Bradley Company) writes: >I am writing an application which needs to communicate with an external device >(a network bridge, actually) through the modem or printer ports. I have two >questions : > >0) Can anyone direct me to some sample code which uses the RAM serial driver to >read and write bytes to/from either port? In fact, is the RAM serial driver the >best way to do something like this (what are the options / pros / cons)? The Ram Serial driver is old and obselete-- use the new ROM serial driver, which has more functionality. There are many tech notes on using it, though some are contradictory. (If anyone knows how to close the new ROM serial driver, please tell me-- CloseDriver is _bad_, right?) >1) Is it a safe or sanctioned operation to use nullEvent to read any received >data from the serial port? What I need to do is allow event processing to >continue while I am waiting for replies. Something that might simplify this is >that there are no unsolicited responses, so I know when to look for received >data : only after I've sent some out. But while I am waiting for a reply packet, >I want to continue to respond to user input. Seems reasonable. If your reply packet will fit within the buffer size, set with SerSetBuf, there will be no problem. If it won't, you will have to check the buffer every time to make sure it isn't full, and if it is getting close, process even if it ISN'T a null event. Watch out for MenuSelect, though. Your program can lose control for a long time that way. (Same with TrackControl) -- Matthew T. Russotto russotto@eng.umd.edu russotto@wam.umd.edu .sig under construction, like the rest of this campus.
han@Apple.COM (Byron Han, scapegoat) (09/20/90)
In article <1990Sep19.193147.15445@eng.umd.edu> russotto@eng.umd.edu (Matthew T. Russotto) writes: >In article <1021.26f75aef@iccgcc.decnet.ab.com> milikich@iccgcc.decnet.ab.com (Mike Milikich, Allen-Bradley Company) writes: >> >>0)Can anyone direct me to some sample code which uses the RAM serial driver to>>read and write bytes to/from either port? > >The Ram Serial driver is old and obselete-- use the new ROM serial driver, >which has more functionality. There are many tech notes on using it, though >some are contradictory. The ROM Serial Driver mentioned in IM-1 was the one in ROM for the earliest Macintoshes. The RAM Serial Driver mentioned in IM-1 is actually in ROM now... >(If anyone knows how to close the new ROM serial driver, please tell me-- >CloseDriver is _bad_, right?) > When you are done with the serial driver and are not using the ancient ROM driver (Mac 128 days), PLEASE close the driver when you are done. _CloseDriver or _PBClose are acceptable.
han@Apple.COM (Byron Han, scapegoat) (09/20/90)
In article <1021.26f75aef@iccgcc.decnet.ab.com> milikich@iccgcc.decnet.ab.com (Mike Milikich, Allen-Bradley Company) writes: >I am writing an application which needs to communicate with an external device >(a network bridge, actually) through the modem or printer ports. I have two >questions : > >0) Can anyone direct me to some sample code which uses the RAM serial driver to >read and write bytes to/from either port? In fact, is the RAM serial driver the >best way to do something like this (what are the options / pros / cons)? As a further note, when opening the serial driver, it is best to check to see if the driver is already open before opening - this prevents one application from "stealing" the serial driver from another under MultiFinder. Someday, serial port arbitration will be a reality, Until then...
jimc@isc-br.ISC-BR.COM (Jim Cathey) (09/20/90)
In article <1021.26f75aef@iccgcc.decnet.ab.com> milikich@iccgcc.decnet.ab.com (Mike Milikich, Allen-Bradley Company) writes: >1) Is it a safe or sanctioned operation to use nullEvent to read any >received data from the serial port? What I need to do is allow event >processing to continue while I am waiting for replies. Something that >might simplify this is that there are no unsolicited responses, so I >know when to look for received data : only after I've sent some out. >But while I am waiting for a reply packet, I want to continue to >respond to user input. Post an _asynchronous_ read to the serial driver, and have the completion routine do whatever it can to finish processing the packet. This could range all the way from just setting a flag (that you can check on nullEvent) to completely handling the packet and posting other reads/writes to the serial driver, assuming that this can all be done with the usual interrupt level code restrictions (no traps that move memory, etc). This has the advantages that there is no hokey polling, you don't have to patch anything, and you will never miss the packet even if you're in another application/DA or the menu system, etc. This is why the async calls are available (for nearly everything except SCSI disks, I think). +----------------+ ! II CCCCCC ! Jim Cathey ! II SSSSCC ! ISC-Bunker Ramo ! II CC ! TAF-C8; Spokane, WA 99220 ! IISSSS CC ! UUCP: uunet!isc-br!jimc (jimc@isc-br.isc-br.com) ! II CCCCCC ! (509) 927-5757 +----------------+ "With excitement like this, who is needing enemas?"
rfl@oddjob.uchicago.edu (Bob Loewenstein) (09/20/90)
> As a further note, when opening the serial driver, it is best to check to see > if the driver is already open before opening - this prevents one application > from "stealing" the serial driver from another under MultiFinder. How do you mean "steal"? If my application checks to see if the driver is already open, what happens if my application changes the baud rate? Or what happens if someone clicks to another application in MultiFinder that uses the port at another baudrate? How does an application handle things like this?
han@Apple.COM (Byron Han, scapegoat) (09/21/90)
In article <1990Sep20.143626.23475@midway.uchicago.edu> rfl@oddjob.UChicago.EDU () writes: > >> As a further note, when opening the serial driver, it is best to check to see >> if the driver is already open before opening - this prevents one application >> from "stealing" the serial driver from another under MultiFinder. > >How do you mean "steal"? Application A opens the serial driver. User switches to Finder and opens Application B which also opens the serial driver. Data is not shared in a totally nondeterministic manner between the two applications. >If my application checks to see if the driver is >already open, what happens if my application changes the baud rate? Or what >happens if someone clicks to another application in MultiFinder that uses >the port at another baudrate? How does an application handle things like this? Appications B (a A for that matter) should check to see if the serial driver to be opened is already opened or not. If it is already open, it should put up an alert saying that the serial port is already in use. If the driver is not open, _PBOpen should then be called. If _PBOpen returns portInUse, the application should also post an alert. This is what the Serial Connection Tool does. Oh also, do not assume that the only drivers available are .Ain, .Aout, .BIn, and .Bout. If the CommToolbox is installed, perform a lookup of the serial devices that are installed to get the names of all of the ports and the names of the associated input and output drivers (which should all support the same control calls that the existing .A/B In/Out drivers do. Hope this helps. Byron Han Occasional Wizard .
leonardr@svc.portal.com (09/24/90)
In article <10326@goofy.Apple.COM> han@Apple.COM (Byron Han, scapegoat) writes: >In article <1990Sep20.143626.23475@midway.uchicago.edu> rfl@oddjob.UChicago.EDU () writes: >> >>How do you mean "steal"? > >Application A opens the serial driver. User switches to Finder and opens >Application B which also opens the serial driver. Data is not shared in a >totally nondeterministic manner between the two applications. > Boy is that an understatement if I ever heard one ;-) >Appications B (a A for that matter) should check to see if the serial driver >to be opened is already opened or not. If it is already open, it should >put up an alert saying that the serial port is already in use. If the driver >is not open, _PBOpen should then be called. If _PBOpen returns portInUse, >the application should also post an alert. This is what the Serial Connection >Tool does. > How would you recommed that you check for 'already open'? I can't speak for PBOpen, but FSOpen DOES NOT (at least under 6.x) return portInUse it just goes ahead and opens up the driver AGAIN. Caused big problems when I updated my old code from the Ram driver since I no longer got portInUse errors... >Oh also, do not assume that the only drivers available are .Ain, .Aout, .BIn, >and .Bout. If the CommToolbox is installed, perform a lookup of the serial >devices that are installed to get the names of all of the ports and the >names of the associated input and output drivers (which should all support the >same control calls that the existing .A/B In/Out drivers do. > Correct! Even if you do not use any of the other CTB managers, you should AT LEAST do a lookup for all serial devices so that the user can use any serial device. There is even example code in the CTB docs for doing this and it is REAL simple to add to an already properly written application. >Byron Han >Occasional Wizard Only occasional!?!? Ah, being modest...I get it. Leonard Rosenthol Software Ventures
han@Apple.COM (Byron Han, scapegoat) (10/18/90)
In article <1990Sep24.000818.29952@svc.portal.com> leonardr@svc.portal.com writes: > How would you recommed that you check for 'already open'? I can't >speak for PBOpen, but FSOpen DOES NOT (at least under 6.x) return portInUse >it just goes ahead and opens up the driver AGAIN. Caused big problems when >I updated my old code from the Ram driver since I no longer got portInUse >errors... > Sorry about taking so long to respond, just got back from 3wk vacation... You might want to check the driver unit table and check the driver flags to see if the driver has already been opened... there is a routine in the 7.0 version of the Comm Rsrc Mgr called CRMIsDriverOpen() which does this...
newbery@rata.vuw.ac.nz (Michael Newbery) (10/19/90)
In article <10749@goofy.Apple.COM> han@Apple.COM (Byron Han, scapegoat) writes: >In article <1990Sep24.000818.29952@svc.portal.com> leonardr@svc.portal.com writes: >> How would you recommed that you check for 'already open'? I can't > >You might want to check the driver unit table and check the driver flags >to see if the driver has already been opened... there is a routine in the >7.0 version of the Comm Rsrc Mgr called CRMIsDriverOpen() which does this... And the following code (in Pascal) does the job now CONST { refNums of .AIn etc } rAIn = -6; rAOut = -7; rBIn = -8; rBOut = -9; IF BTst(BOr(GetDCtlEntry(rAIn)^^.dCtlFlags,GetDCtlEntry(rAOut)^^.dCtlFlags),5) THEN { The A driver(s) are open } Reference: IM II-190 "The Device Manager---The Structure of a Device Driver" -- Michael Newbery<newbery@rata.vuw.ac.nz> Nunc est bibendum Horace Od I xxxvii 1
leonardr@svc.portal.com (Leonard Rosenthol) (10/20/90)
In article <1990Oct19.043030.27980@comp.vuw.ac.nz>, newbery@rata.vuw.ac.nz (Michael Newbery) writes: > In article <10749@goofy.Apple.COM> han@Apple.COM (Byron Han, scapegoat) writes: > >In article <1990Sep24.000818.29952@svc.portal.com> leonardr@svc.portal.com writes: > >> How would you recommed that you check for 'already open'? I can't > > > >You might want to check the driver unit table and check the driver flags > >to see if the driver has already been opened... there is a routine in the > >7.0 version of the Comm Rsrc Mgr called CRMIsDriverOpen() which does this... > And the following code (in Pascal) does the job now > IF > BTst(BOr(GetDCtlEntry(rAIn)^^.dCtlFlags,GetDCtlEntry(rAOut)^^.dCtlFlags),5) > THEN > { The A driver(s) are open } > Which is just fine, if your application is old fashioned and only knows how to address the modem and printer ports...However, any current application should be smart enough to know how to find (either hard coded or dynamically) other serial devices and drivers to open and work with - therefore making your suggestions useless. Bottom line is that the current Apple serial driver does not return an error when being opened by another application (ie a second time). If Apple would improve the serial driver, at least to the level of some of the third party drivers, it would REALLY HELP THINGS! -- Leonard Rosenthol Software Ventures Corp. MicroPhone II Development Team