paulm@nikhefk.UUCP (Paul Molenaar) (06/14/89)
Does anyone know a plausible reason for charachters $91 and $93 not being
transmitted when doing a text-transmission over the serial port?
Those, and only those 'extended ascii' characters fail to show up at
the host. And character $91 happens to be a fairly wide-used character
used in the Dutch language area. Any clues are welcome. I'll post
the (Pascal) source code of the actual communications routine if
necessary.
--
Paul Molenaar
"Just checking the walls"
- Basil Fawlty -cruff@ncar.ucar.edu (Craig Ruff) (06/15/89)
In article <558@nikhefk.UUCP> paulm@nikhefk.UUCP (Paul Molenaar) writes: >Does anyone know a plausible reason for charachters $91 and $93 not being >transmitted when doing a text-transmission over the serial port? Probably because they are CONTROL-Q ($11) and CONTROL-S ($13) with the high bit set. Looks like you need a binary type transmission with flow control disabled or some sort of protocol to get around the input driver on the other machine. -- Craig Ruff NCAR cruff@ncar.ucar.edu (303) 497-1211 P.O. Box 3000 Boulder, CO 80307
paulm@nikhefk.UUCP (Paul Molenaar) (06/15/89)
In article <3441@ncar.ucar.edu> cruff@handies.UCAR.EDU (Craig Ruff) writes: #In article <558@nikhefk.UUCP> paulm@nikhefk.UUCP (Paul Molenaar) writes: #>Does anyone know a plausible reason for charachters $91 and $93 not being #>transmitted when doing a text-transmission over the serial port? # #Probably because they are CONTROL-Q ($11) and CONTROL-S ($13) with the #high bit set. Looks like you need a binary type transmission with #flow control disabled or some sort of protocol to get around the #input driver on the other machine. #-- #Craig Ruff NCAR cruff@ncar.ucar.edu Thanx! You're probably right on the dot! Now how do I produce a work-around for this hick-up? Should I have the serial driver ignore software-flow control? Doesn't sound like an elegant solution to me... But then again, my program isn't elegant either... ;) . . . ., . Paul Molenaar "Just checking the walls" - Basil Fawlty - -- Paul Molenaar "Just checking the walls" - Basil Fawlty -
tim@hoptoad.uucp (Tim Maroney) (06/15/89)
In article <558@nikhefk.UUCP> paulm@nikhefk.UUCP (Paul Molenaar) writes: >Does anyone know a plausible reason for charachters $91 and $93 not being >transmitted when doing a text-transmission over the serial port? In article <3441@ncar.ucar.edu> cruff@handies.UCAR.EDU (Craig Ruff) writes: >Probably because they are CONTROL-Q ($11) and CONTROL-S ($13) with the >high bit set. In article <559@nikhefk.UUCP> paulm@nikhefk.UUCP (Paul Molenaar) writes: >Thanx! You're probably right on the dot! Now how >do I produce a work-around for this hick-up? Should I have the >serial driver ignore software-flow control? Depends on what side the problem is on. If you're going to be sending and receiving these characters, then you ought to call SerHShake with the fXOn and fInX fields set to zero regardless. However, the problem may be on the host computer you are talking to over the serial port, in which case you will also have to set some flags known to the OS on that system. On UNIX, you do this with a "stty(1)" command. ("man stty" for information on how to use.) On VMS, you use a "SET TERM" command. ("HELP SET TERM" for information.) -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com Postal: 424 Tehama, SF CA 94103; Phone: (415) 495-2934 "Jesus died for somebody's sins, but not mine." -- Patti Smith
pak@tumuc.UUCP (Peter A. Krauss) (06/16/89)
In article <558@nikhefk.UUCP>, paulm@nikhefk.UUCP (Paul Molenaar) writes: > Does anyone know a plausible reason for charachters $91 and $93 not being > transmitted when doing a text-transmission over the serial port? Because... $91 - $80 = ctrl-Q == XON $93 - $80 = ctrl-S == XOFF I suppose you have to turn off the XON/XOFF software handshaking. -- +----------------------------------------------------------+ | Peter A Krauss (pak@tumuc.e-technik.tu-muenchen.dbp.de) | +----------------------------------------------------------+
rfl@oddjob.uchicago.edu (Bob Loewenstein) (10/10/89)
I have a program where I use the serial driver at 19200 baud. I set the size of the internal buffer to a large block so that I don't miss any transmissions while I'm not reading the port (64 bytes, the default, is too small). My problem is this: If someone using the program decides to open up some terminal emulator desk accessory, or switches via multifinder to another program that wants the port, when they switch back to my application, always my buffer is no longer used and the default is back; sometimes it screws things up altogether and causes a bomb. How can I manage the port for these user switches? If I knew when they returned to my program, I could reinitialize the port. Any comments would be appreciated.
enwall@Apple.COM (Tim Enwall) (10/10/89)
In article <5727@tank.uchicago.edu> rfl@oddjob.UChicago.EDU (Bob Loewenstein) writes: > >I have a program where I use the serial driver at 19200 baud. I >set the size of the internal buffer to a large block so that I don't >miss any transmissions while I'm not reading the port (64 bytes, the >default, is too small). My problem is this: If someone using the program >decides to open up some terminal emulator desk accessory, or switches >via multifinder to another program that wants the port, when they >switch back to my application, always my buffer is no longer used and >the default is back; sometimes it screws things up altogether and >causes a bomb. > You can use suspend/resume events to get notified when your your application is being put into the background/foreground and do whatever is necessary to save the state of your program. The "Programmer's Guide to MultiFinder" available from APDA explains suspend resume events, as do five of the current Tech Notes. Hope this helps. -- Tim Enwall Macintosh Developer Technical Support Apple Computer, Inc. "Opinion's but a fool, that makes us scan The outward habit by the inward man" -- Pericles, Act II. Sc.2
kent@sunfs3.camex.uucp (Kent Borg) (10/12/89)
In article <5727@tank.uchicago.edu> rfl@oddjob.UChicago.EDU (Bob Loewenstein) writes: > >I have a program where I use the serial driver at 19200 baud. I >set the size of the internal buffer to a large block so that I don't >miss any transmissions while I'm not reading the port (64 bytes, the >default, is too small). My problem is this: If someone using the program >decides to open up some terminal emulator desk accessory, or switches >via multifinder to another program that wants the port, when they >switch back to my application, always my buffer is no longer used and >the default is back; sometimes it screws things up altogether and >causes a bomb. > >How can I manage the port for these user switches? If I knew when they >returned to my program, I could reinitialize the port. > >Any comments would be appreciated. If your program is MultiFinder aware, you will get suspend and resume events whenever you are switched in or out. If you do not set your MultiFinder aware bit, MultiFinder will pretend a DA is being used as a way to force you to convert your private scrap to a desk scrap. Either way, it is possible to tell from within your event loop whether another program has been in the foreground. The bad news is I don't know how to tell whether a program in the background has been messing with the serial port. The details for sharing serial ports are not nice. Might check into the Communications Toolbox, it might offer some help. -- Kent Borg "Then again I could be foolish kent@lloyd.uucp not to quit while I'm ahead..." or -from Evita (sung by Juan Peron) ...!husc6!lloyd!kent
rfl@oddjob.uchicago.edu (Bob Loewenstein) (10/13/89)
Kent Borg points out: > The bad news is I don't know how to tell whether a program in the > background has been messing with the serial port. The details for > sharing serial ports are not nice. Might check into the > Communications Toolbox, it might offer some help. This is the essence of the problem now. My program is multifinder aware, and I can respond to resume/suspend events. However, I have no way to know if another program or da has messed with the serial port. If one has, I have lost any data that may have been coming in the background, and upon a resume event I can at least reset the port and its buffer. But if the port is still mine, I don't want to mess with it myself and then lose any current transmissions. Basically the question is now: How do you know if the port is still yours. I can find no call that tells me, for instance, the size of the internal buffer (I could compare to see if it's = to my buffer size), or the address of that buffer, or the configuration of the port for comparison.