LEIF@SLACVM.SLAC.STANFORD.EDU (04/03/91)
No one replied to my earlier plea, but I refuse to beleive that everyone was
stumped by this one, so I'll ask again:
I nead to read data from the serial buffer on the HP48SX whenever a line-
feed or carriage return is received into the buffer from the 4-wire port.
I would like to know if there is a way of checking the buffer to see if it
received a lf/cr before I do an SRECV. Is there any way of checking this!?
I have tried just SRECV'ing in how ever many char's BUFFLE returns, but I
seem to loose some of the data when I do it this way. I feel that if I could
force my program to read **ONLY** after a cr/lf, I would no longer loose data.
If anyone has any suggestions PLEASE RESPOND. If I am not expressing myself
clearly enough, let me know and I will try to be more explicit. If I could
figure it out myself, I would! I'm just asking for suggestions, so please
help! Thanks alot in advance (since I know THIS time SOMEONE will answer :-).
Later... Leif Johnson
Leif@SLACVM.SLAC.STANFORD.EDUedp@jareth.enet.dec.com (Eric Postpischil (Always mount a scratch monkey.)) (04/03/91)
In article <91092.195502LEIF@SLACVM.SLAC.STANFORD.EDU>, LEIF@SLACVM.SLAC.STANFORD.EDU writes: >I would like to know if there is a way of checking the buffer to see if it >received a lf/cr before I do an SRECV. Is there any way of checking this!? There is no way to do this in the user language. It probably could be done in machine language. >I have tried just SRECV'ing in how ever many char's BUFFLE returns, but I >seem to loose some of the data when I do it this way. Something is wrong; you should not be losing data just because you SRECV. There must be something else going on. What makes you think you are losing data? If you: Set a variable, like S, to an empty string (""), Repeatedly wait a little bit and do BUFLEN SRECV and add the result to S, Check to see if there was a carriage return or line-feed in S, then you should get a line of data. If you are looking for a carriage-return followed by a line-feed, be sure you check to see if the carriage-return is received in one BUFLEN SRECV and the line-feed is received in the next. I seem to recall you stated in your original post that you could not get flow-control to work. This should be fairly simple, just a matter of setting the third number in IOPAR to 1. Are you having problems setting flow-control on the computer side? -- edp (Eric Postpischil) "Always mount a scratch monkey." edp@jareth.enet.dec.com
bgribble@jarthur.Claremont.EDU (Bill Gribble) (04/04/91)
A few notes from a person who's seen most of your problems: first, like a previous poster said, there's no way to receive only after a carriage return from user language, and if you can do it from machine language you're a better man than I am. Dealing with the serial buffer in machine language is very difficult, and there's really nothing you can't do with user language that you can in machine language. Second: as odd as it sounds, the 48 does drop characters when connected to a modem, flow control or no. While I was testing NRTS, I thought it was a bug in my code, so (being the clever guy I am) I did the following, which you can do as well to verify that the 48 doesn't handle buffer overflows well: log in to your favorite computer with your favorite hp term program. I suggest NRTS :-). Quit the program. Execute "ls -laR" XMIT. (or equivalent if you're not on a UNIX machine). Check the buffer. You would think it would be 255, the buffer having overflowed, right? I get an average of 45 to 70 characters in the buffer, usually the first line or so of the output, and nothing else. Even with flow control on, I get the same thing with no XOFF sent. A large number of characters just evaporate. This doesn't happen when connected directly to any sort of terminal line, so it doesn't bother me that much, but it is an anomaly, I think. ***************************************************************************** ** Bill Gribble Harvey Mudd College, Claremont, CA ** ** bgribble@jarthur.claremont.edu Never heard of it? You're stupid. ** *****************************************************************************
LEIF@SLACVM.SLAC.STANFORD.EDU (04/04/91)
In article <21685@shlump.nac.dec.com>, edp@jareth.enet.dec.com (Eric Postpischil (Always mount a scratch monkey.)) says: > >There must be something else going on. What makes you think you >are losing data? I am reading from a meter, which outputs a number of the form: xx.x<cr> every second. I see the annunciator in the upper left of the hp48 flash every second, but the characters I get from the buffer sometimes fail to be displayed by my program, and don't appear on the stack after program ends. Say I run for 1 minute, I should get 60 reads on the stack, well I usually get from 45-55 numbers (converted using STR\-> ), even though I do see the annunciator flash 60 times. (What is this annunciator supposed represent anyway? It looks like half an infinity symbol with an arrow sticking out of it's side :-) >I seem to recall you stated in your original post that you could not get >flow-control to work. This should be fairly simple, just a matter of >setting the third number in IOPAR to 1. Are you having problems setting >flow-control on the computer side? I haven't used flow-control, so I'll have to look into it. I am not; however, reading input to the 48 from a computer, rather from a digital meter, which thinks it is printing. Thanks for the suggestions, I'll try accumulating to a string, then splitting the string up and converting to numbers at the end of the program. As to the flow-control, I will have to look into what it is supposed to accomplish before I try to use it. Thanks again! P.S. Any and all other suggestions still welcome! :-) Later... Leif Johnson Leif@SLACVM.SLAC.STANFORD.EDU
edp@jareth.enet.dec.com (Eric Postpischil (Always mount a scratch monkey.)) (04/04/91)
In article <91093.182342LEIF@SLACVM.SLAC.STANFORD.EDU>, LEIF@SLACVM.SLAC.STANFORD.EDU writes: >I am reading from a meter, which outputs a number of the form: xx.x<cr> >every second. I see the annunciator in the upper left of the hp48 flash >every second, but the characters I get from the buffer sometimes fail >to be displayed by my program, and don't appear on the stack after program >ends. Unfortunately, the problem with this is that I can't tell from where I am whether it is your program or the 48 that is losing the data. The idea of just accumulating all of the characters in a string might help you determine if the data is being lost before or after you get them with SRECV. >I haven't used flow-control, so I'll have to look into it. I am not; however, >reading input to the 48 from a computer, rather from a digital meter, which >thinks it is printing. If the digital meter does not honor control-S and control-Q, flow control will not work. >Thanks for the suggestions, I'll try accumulating >to a string, then splitting the string up and converting to numbers at the >end of the program. Actually, if the meter sends out just numbers separated by carriage returns (or other kinds of space characters, like spaces or tabs), then all you need to do to convert the final string to a bunch of numbers is execute OBJ->. -- edp (Eric Postpischil) "Always mount a scratch monkey." edp@jareth.enet.dec.com