On 4/3/2014 1:40 AM, trifle menot wrote:
On 4/2/14, Mihai Popescu <mih...@gmail.com> wrote:
Dude, what the hell are you trying to do? Just explain in plain words here.
I am interested in working with rs232
and i wasted my time reading and wainting for your damn problem.
a) Set raw mode.
b) Set VMIN = 250 and VTIME = 1.
c) Set port speed to 115200.
d) Read data from the serial port.
e) Have a device (or program) send data to the serial port, at a
steady rate of 11 cps.
f) Notice a 20 second delay before read() returns. Your sending device
appears to have stalled, though it has not.
The problem is, VTIME is an interbyte timer. At 11 cps and VTIME = 1,
it never expires. You wait 20 seconds for VMIN to kick in, before
read() returns. Unfortunately, POSIX provided no option to make VTIME
an overall timer.
VMIN must not exceed MAX_INPUT (255 on my linux test box). So VMIN
must be <= 255 (even though an integer holds the value).
Now suppose VTIME was an overall timer, not an interbyte timer. In 0.1
seconds at 115200, you can transfer about 1100 bytes. At that speed,
VMIN will kick in before the timer expires, and read() will return
with approx. 250 bytes. If you get a block < 250 bytes, you will never
wait more than 0.1 seconds for it, even in the worst case, a steady 11
cps.
The POSIX writers erred by making VTIME an interbyte timer.
What real life problem are you trying to solve? Why do you need to have
< 250 bytes in the returned buffer? Is it important to have a "steady
11 cps" in the other situation? Have you considered non-blocking IO?
Using select or some other equivalent to determine if there is data
available on the port prior to the read?
Serial communications have been around since the dark ages & I was
writing code 20+ years ago to talk to RS-232 (a very un-standard
standard). There are many ways to solve the same problem...
Cheers,
Steve Williams
