czei@quanta.eng.ohio-state.edu (Michael S. Czeiszperger) (06/15/89)
I recently purchased Apple's serial communications kit, and thought it would be useful to pass on my experience with the product. First, the overall design of the kit is very good. I previously tried some other public domain serial commands, and found that they weren't as flexible for doing complicated serial communications stacks. There are more than just the "send" and "receive" types of commands, with functions like CharsAvailable() to tell you how many chars are waiting in the input queue, and others to tell you the current status of input and output. Unfortunately, the kit does not work as per the documentation. (We all understand that I imply only that it doesn't work for me, not that it would not work for everyone. There may be something in my configuration which is causing some or all of these problems. I'm using finder 6.1, system 6.0.2, and hypercard 1.2.1) There are several bugs I've encountered which cripple the usefulness of the product: 1. Xon/Xoff still does not work on input or output. I tried an earlier version of the kit, and found that the Xon/Xoff did not work. After purchasing the latest version, 2.5b1, I've discovered that it still does not work. Because of this, I have to set my input buffer to be enormous to capture all incoming data without overflow. On output, I have to wait a second between lines so as to not overflow the other end of the data stream. CAVEAT: I have not put a line monitor on the output to conclusively prove that it is not working as per the Xon/Xoff protocol. My only test was with sending and receiving text from my stack, which did not work correctly regardless of the configuration of the ports. Input data continually overflowed on small buffers, which would not happen if the port was sending out Xoff's when the buffer was approaching overflow. Output data overflowed the target computer. I tried both sending large text fields to UNIX hosts, a C64, and a commercial network. 2. It does not strip linefeeds from the incoming data stream, regardless of whether that option is set or not. 3. It strips random characters from incoming data stream. By this I mean that it picks one character every time I boot the computer, and deletes every instance of that character from my data stream. Sometimes it is the letter "p". Other times it is the letter "n". And still others, the letter "g". This wreaks havoc on my stacks, making it impossible to make them work reliably. I wonder how to communicate these problems to the Apple hypercard people when I'm not a registered developer? -- Michael S. Czeiszperger | "...the average sea bass caught off the coast of Systems Analyst | Los Angeles contains three times your lifetime's Ohio State University | worth of toxins...", NBC News, 4/17/89 ARPA:czei@icarus.eng.ohio-state.edu 2015 Neil, Columbus, OH 43210 292-0161
paul@taniwha.UUCP (Paul Campbell) (06/16/89)
In article <2416@quanta.eng.ohio-state.edu> czei@quanta.eng.ohio-state.edu (Michael S. Czeiszperger) writes: > >1. Xon/Xoff still does not work on input or output. I tried an earlier >3. It strips random characters from incoming data stream. By this I >mean that it picks one character every time I boot the computer, and >deletes every instance of that character from my data stream. >Sometimes it is the letter "p". Other times it is the letter "n". >And still others, the letter "g". This wreaks havoc on my stacks, >making it impossible to make them work reliably. I wonder if the package (or you when you use the package) is setting the XON/XOFF characters (the MacOS serial driver lets you do this) to some random value (ie "p", "n" or "g")? Try using the command (whatever it is) to set these characters to the standard XON/XOFF. Paul -- Paul Campbell, Taniwha Systems Design UUCP: ..!mtxinu!taniwha!paul Oakland CA AppleLink: D3213 Q: How many men does it take to pilot the Exxon Valdez? A: One and a fifth.
czei@quanta.eng.ohio-state.edu (Michael S. Czeiszperger) (06/16/89)
In article <381@taniwha.UUCP> paul@taniwha.UUCP (Paul Campbell) writes: > >I wonder if the package (or you when you use the package) is setting the >XON/XOFF characters (the MacOS serial driver lets you do this) to some >random value (ie "p", "n" or "g")? Try using the command (whatever it is) >to set these characters to the standard XON/XOFF. Good guess. The only problem with this idea is that the user doesn't have the option of setting the characters used for XON/OFF. Perhaps there's something in the source code? I'm in the process of re-compiling the commands and doing a little debugging. Unfortunately, you need MPW to do this, which requires at least 2 megs of memory, and probably more. (My friends who have the latest MPW say that it is nearly unusable without *more* than 2 megs of memory) -- Michael S. Czeiszperger | "...the average sea bass caught off the coast of Systems Analyst | Los Angeles contains three times your lifetime's Ohio State University | worth of toxins...", NBC News, 4/17/89 ARPA:czei@icarus.eng.ohio-state.edu 2015 Neil, Columbus, OH 43210 292-0161
chesley@goofy.apple.com (Harry Chesley) (06/20/89)
I wrote the Serial Port Toolkit, but don't have current responsibility for maintaining it (I'm now in the Advanced Technology Group doing more researchy sorts of things). I'll try to answer some of the questions. For current plans/state/etc. you might try talking to Mike Holm, the Product Manager for HyperCard. Steve Maller was maintaining all of the Toolkits, but I'm not sure if that's still true now. In article <2416@quanta.eng.ohio-state.edu> czei@quanta.eng.ohio-state.edu (Michael S. Czeiszperger) writes: > First, the overall design of the kit is very good. Thanks. In article <2416@quanta.eng.ohio-state.edu> czei@quanta.eng.ohio-state.edu (Michael S. Czeiszperger) writes: > Xon/Xoff still does not work on input or output. It does not, and is not spec'd to work on incoming data (yes, it probably should), only on outgoing data. But it should definitely work on outgoing. I just tried it out and looked in the source code and you're absolutely right, it isn't working correctly. My apologies. I'm not sure how that sneaked out, since we definitely tested the flow control portion. What's actually happening is that when x-on/x-off flow control is turned on, it will use random characters for flow control, hence the other problem you reported, the eating of characters. This is because the code is not setting the right pair of flow control characters before calling the driver to enable flow control. I will report this internally to be fixed in the next release. In the meantime, if you have MPW, you can fix the source code. In the file SPortUtil.inc, in the routine SetUpSPortGlobals, there is some code that sets up the handshaking configuration record; it's preceeded by "with shakes do". There's several things set to initial values. Add "xOn := 17; xOff := 19;". That should do it (note: I haven't tried this yet, so if there's any problem, let me know). If it's a viable solution for you, you can still use signal flow control without making any changes to the XCMDs. For incoming data, I just set the buffer size to a large number (like 10K, which is lots to a serial port, but not really much to HyperCard). In article <2416@quanta.eng.ohio-state.edu> czei@quanta.eng.ohio-state.edu (Michael S. Czeiszperger) writes: > It does not strip linefeeds from the incoming data stream, > regardless of whether that option is set or not. There is no option to strip linefeeds from the incoming data stream. There is an option to append linefeeds to carriage returns, and one which strips all control characters except carriage return and backspace, including linefeed. This is the stripControlsOn option. I just tried this, and it works just fine. A note about setting options in general: the option have must be typed in exactly right ("stripControlsOn" for control character striping and "XOnOutOn" for X-on/X-off) or it won't work (i.e., it doesn't recognize just the first few characters but rather the whole word). Note: I posted this reply to the newgroup as a whole in case other people had similar problems/questions/etc., but it's probably better to take any follow-up discussion off-line. I'm reachable as chesley@apple.com. Hope that helps.
czei@quanta.eng.ohio-state.edu (Michael S. Czeiszperger) (06/20/89)
In article <2417@internal.Apple.COM> chesley@goofy.apple.com (Harry Chesley) writes: >I wrote the Serial Port Toolkit, but don't have current responsibility for >maintaining it (I'm now in the Advanced Technology Group doing more >researchy sorts of things). I'll try to answer some of the questions. For >current plans/state/etc. you might try talking to Mike Holm, the Product >Manager for HyperCard. Steve Maller was maintaining all of the Toolkits, >but I'm not sure if that's still true now. I can't tell you how happy I am to hear from someone at Apple about this. These particular problems have caused some loss of good will between myself and the people who have contracted for the stack design. You see, I never had the problems I described until very recently. What would happen would be I would send out the stack for testing, and the person who paid for the stack would discover that it didn't work. They'd have random wierd things happen, and all I could say was "it worked when I tested it". The smart thing to do would be to purchase MPW and debug it myself, but that would eat up most of my profits considering you need more than 2 megs to run MPW comfortably. I've arranged with a friend to get access to his machine, so I will be able to re-compile the serial kit. (Assuming I can figure out how to use MPW. Just looking at the size of those manuals gives me the shivers) Thanks, -- Michael S. Czeiszperger | "...the average sea bass caught off the coast of Systems Analyst | Los Angeles contains three times your lifetime's Ohio State University | worth of toxins...", NBC News, 4/17/89 ARPA:czei@icarus.eng.ohio-state.edu 2015 Neil, Columbus, OH 43210 292-0161
czei@quanta.eng.ohio-state.edu (Michael S. Czeiszperger) (06/21/89)
In article <2417@internal.Apple.COM> chesley@goofy.apple.com (Harry Chesley) writes: >There is no option to strip linefeeds from the incoming data stream. There >is an option to append linefeeds to carriage returns, and one which strips >all control characters except carriage return and backspace, including >linefeed. This is the stripControlsOn option. I just tried this, and it >works just fine. I checked the source code, and only recvUpTo actually strips control characters. Since I could never get this routine to do anything but spit loads of random characters out the serial port, I'm exclusively using recvChars() to input data from the serial ports. In the source code for recvChars(), there is no attempt to strip control characters, although it does zero out the MSB if that option is set. If anyone is interested, a friend of mine with MPW (Mark Welch) fixed the Xon/Xoff problem, and also added the feature of stripping control characters to the routine recvChars(). If you've purchased the serial kit and would like the diffs drop me a line. -- Michael S. Czeiszperger | "...the average sea bass caught off the coast of Systems Analyst | Los Angeles contains three times your lifetime's Ohio State University | worth of toxins...", NBC News, 4/17/89 ARPA:czei@icarus.eng.ohio-state.edu 2015 Neil, Columbus, OH 43210 292-0161
chesley@goofy.apple.com (Harry Chesley) (06/22/89)
In article <2447@quanta.eng.ohio-state.edu> czei@quanta.eng.ohio-state.edu (Michael S. Czeiszperger) writes: > I checked the source code, and only recvUpTo actually strips control > characters. Oops. You're right and I meant to mention that in my previous reply and forgot: most of the configuration options work only with recvUpTo, not with recvChars. recvChars was intended to be a very low level, simple interface to the port, while recvUpTo is the primary high level, fancy interface. Among very many other features, recvUpTo lets you set a time-out so you don't get hung up waiting for input.