SERIN and timeout parameter
Archiver
Posts: 46,084
When using SERIN to receive data and using the timeout
parameter, when does the timeout stop? Does it stop on the
the first start bit? Can it "timeout" in the middle of receiving
the data so that only part of data is received and then go the
label specified? The SERIN is part of a program loop trying
to check things to see what to do so I have the timeout value
at 4 to keep from "hogging" the loop. The application is, a
PC is sending the time-of-day (TOD)every minute (displayed on the
LCD). If the TOD isn't received (stamp response back to PC
saying "no-go" send again) the TOD is resent. Using debug
there seems to be alot of 'junk' received before the TOD
comes thru correctly, hence my question, can the timeout occur
in the middle of data. I am running at 4800 baud. I have a
delay in the PC program after sending each character. I have
two SERIN commands, the first with the Timeout parameter to
receive a "command" byte to get the program out of the loop
and then to a SERIN with no timeout to get the hour byte and
the minute byte. The PC sends the 3 bytes with a slight delay
between each byte. The "junk" seems to be a clobbered command
byte (the SERIN with the timeout).
Thanks,
Bob Oldershaw
parameter, when does the timeout stop? Does it stop on the
the first start bit? Can it "timeout" in the middle of receiving
the data so that only part of data is received and then go the
label specified? The SERIN is part of a program loop trying
to check things to see what to do so I have the timeout value
at 4 to keep from "hogging" the loop. The application is, a
PC is sending the time-of-day (TOD)every minute (displayed on the
LCD). If the TOD isn't received (stamp response back to PC
saying "no-go" send again) the TOD is resent. Using debug
there seems to be alot of 'junk' received before the TOD
comes thru correctly, hence my question, can the timeout occur
in the middle of data. I am running at 4800 baud. I have a
delay in the PC program after sending each character. I have
two SERIN commands, the first with the Timeout parameter to
receive a "command" byte to get the program out of the loop
and then to a SERIN with no timeout to get the hour byte and
the minute byte. The PC sends the 3 bytes with a slight delay
between each byte. The "junk" seems to be a clobbered command
byte (the SERIN with the timeout).
Thanks,
Bob Oldershaw
Comments
>parameter, when does the timeout stop? Does it stop on the
>the first start bit
Yes. The start bit of each data byte received resets the timer. For example,
serin 16,3000,nodata,[noparse][[/noparse]wait ('FOX'), X,Y,Z]
times out after three seconds. But that is three seconds between
each byte that happens to come along the line (even line noise!). It
is _not_ three seconds cumulative for 'FOX' and the data.
On the other hand, once the start bit is detected, the serin will go
ahead and receive the whole byte--it will never time out in the
middle of a byte.
>I have
>two SERIN commands, the first with the Timeout parameter to
>receive a "command" byte to get the program out of the loop
>and then to a SERIN with no timeout to get the hour byte and
>the minute byte. The PC sends the 3 bytes with a slight delay
>between each byte. The "junk" seems to be a clobbered command
>byte (the SERIN with the timeout).
If your serin command on the stamp happens to start executing right
in the middle of a head to tail stream of data bytes, it looks like
garbage. You said you put a pacing delay in your transmitting
program. That helps. You also said you had a timeout delay of 4
milliseconds, something like this:
serin 16,4,nodata,[noparse][[/noparse]wait (command), X,Y,Z]
Your program is likely to hit the data that comes from the PC right
in the middle of the string, or even right in the middle of a byte.
That gives garbage. for the first character. It is hard to do this
kind of thing on a stamp due to the lack of an async serial buffer.
Can you time your program so that once it receives the PC data, it
does not come around to this serin instruction again until a little
less than a minute has elapsed, then increase the wait delay as
necessary?
-- regards,
Tracy Allen
electronically monitored ecosystems
mailto:tracy@e...
http://www.emesystems.com
could be coming active in the middle of data hence the garbage. The
time-of-day(TOD)routine does work but it usually takes the PC several
retranmissions to make a successful pass. I have a "checkpoint' in my
PC routines that is displayed to the monitor and I can see how many
tries it takes to get in. Sometimes on the first attempt but usually
anywhere from 2 to 15 attempts. The PC program resends the data until
it gets a valid response. The PC program is in a loop also so the
response may get clobbered for the same reason as the Stamp but
the TOD does get thru after the X number of retries. I have another
SERIN in the Stamp main loop which grabs the keycodes from my PCjr
infra-red keyboard. To make that work fairly reliable (with the PC
TOD in the loop)I had to change the timeout value in that SERIN to 40
so that probably affects the PC receives quite a bit but anyway it
works. True hit or miss async operation. I will play around with the
wait timeout values some more to see if that improves the retries and
doesn't affect the keyboard.The next step is to send a message from
the Stamp keyboard to the PC monitor. Thanks again for the very
informative response.
Bob Oldershaw