|
Home > Archive > Unix Programming > June 2006 > Not reading, or sending, fast enough on my serial application
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Not reading, or sending, fast enough on my serial application
|
|
| af300wsm@gmail.com 2006-06-23, 1:22 pm |
| Hello,
Thanks to those who responded earlier this week to my posting about
needing help with my serial programming. I'm past that hurdle (the
hurdle I was trying to clear ended up being one of my own "genius"),
but now I'm seeing that my application drops packets.
Now, I'm trying isolate where I'm having difficulty. The code places
the serial driver in raw, non-canonical, mode for all the read and
write calls. So I have two questions.
Pertinent information: packet size is 255 bytes.
1) on the send, or write, side of the app. I simply open the serial
line and write the 2500 packets to it. This part of the application
takes, approx., 5 seconds to complete. I'm wondering, since the serial
line is set to 115200 BAUD, am I'm writing the data to the device
faster than the kernel can send it and therefore bits are being dropped
in the buffer before being sent?
2) on the receive, read, side; I again place the serial line in raw
mode and then set the c_cc[VMIN] member to the packet size and then set
the c_cc[VTIME] member to 0. I also call fcntl to set the FNDELAY flag
on the descriptor and then use select() with a timeout of 30 seconds on
the file descriptor (the extremely long timeout is only to allow the
user to start the sender on another computer before the timeout). What
I'm wondering is, am I incorrectly using these facilities? Since I'm
setting VMIN to 255, is select extraneous? Also, since I'm setting
VMIN to 255 AND I'm setting the flags to FNDELAY, is the read still
being blocked until the 255 characters are present?
Andy
| |
| Karl Malbrain 2006-06-23, 7:23 pm |
|
af300wsm@gmail.com wrote:
> but now I'm seeing that my application drops packets.
>
> Now, I'm trying isolate where I'm having difficulty. The code places
> the serial driver in raw, non-canonical, mode for all the read and
> write calls. So I have two questions.
>
> Pertinent information: packet size is 255 bytes.
>
> 1) on the send, or write, side of the app. I simply open the serial
> line and write the 2500 packets to it. This part of the application
> takes, approx., 5 seconds to complete. I'm wondering, since the serial
> line is set to 115200 BAUD, am I'm writing the data to the device
> faster than the kernel can send it and therefore bits are being dropped
> in the buffer before being sent?
This is always true -- your write sends data instantaneously. The port
buffers the data and sends it to the uart. So, the answer to this
question is NO.
> 2) on the receive, read, side; I again place the serial line in raw
> mode and then set the c_cc[VMIN] member to the packet size and then set
> the c_cc[VTIME] member to 0. I also call fcntl to set the FNDELAY flag
> on the descriptor and then use select() with a timeout of 30 seconds on
> the file descriptor (the extremely long timeout is only to allow the
> user to start the sender on another computer before the timeout). What
> I'm wondering is, am I incorrectly using these facilities? Since I'm
> setting VMIN to 255, is select extraneous? Also, since I'm setting
> VMIN to 255 AND I'm setting the flags to FNDELAY, is the read still
> being blocked until the 255 characters are present?
Can't answer this one -- I never use select on a serial port. Why you
use the FNDELAY open flag and set VMIN to 255??? Do you want to wait
for 255 characters, or not?
karl m
| |
| af300wsm@gmail.com 2006-06-23, 7:23 pm |
|
Karl Malbrain wrote:
> af300wsm@gmail.com wrote:
>
> This is always true -- your write sends data instantaneously. The port
> buffers the data and sends it to the uart. So, the answer to this
> question is NO.
Ok, thanks.
>
>
> Can't answer this one -- I never use select on a serial port. Why you
> use the FNDELAY open flag and set VMIN to 255??? Do you want to wait
> for 255 characters, or not?
As I was reading through the manual pages for termios and such, I was
thinking this. If it's true that I can't write the data to the device
faster than the kernel/driver can write on the device, then the packets
must be dropping on the receiving end.
What methods might one employ to get data quicker? Since I'm cutting
out select and simply waiting for 255 characters to become available,
how would I read it fast enough?
Andy
| |
| Karl Malbrain 2006-06-23, 7:23 pm |
|
af300wsm@gmail.com wrote:
> As I was reading through the manual pages for termios and such, I was
> thinking this. If it's true that I can't write the data to the device
> faster than the kernel/driver can write on the device, then the packets
> must be dropping on the receiving end.
Right.
> What methods might one employ to get data quicker? Since I'm cutting
> out select and simply waiting for 255 characters to become available,
> how would I read it fast enough?
Your information exchange protocol is going to have to deal with
dropped packets.
karl m
| |
| davids@webmaster.com 2006-06-23, 7:23 pm |
|
af300wsm@gmail.com wrote:
> What methods might one employ to get data quicker? Since I'm cutting
> out select and simply waiting for 255 characters to become available,
> how would I read it fast enough?
Is one side purely sending and the other side purely receiving? You
might try testing with purely unidirectional traffic. The problem might
be that the sending side is losing time it really needs to be sending
because it's in a blocking receive or failing to receive data the other
side is sending because it's in a blocking send.
If you can ever get in a state where both sides say "I'm not going to
call receive right now, I'm waiting to be able to send this data
first", then you can deadlock horribly. The simplest solution is to
make sure that no matter how long it takes you to send data, you
continue receiving while you're doing that (just stick it in a buffer
and process it later if you're lazy).
DS
| |
| af300wsm@gmail.com 2006-06-26, 1:22 pm |
|
davids@webmaster.com wrote:
> af300wsm@gmail.com wrote:
>
>
> Is one side purely sending and the other side purely receiving? You
> might try testing with purely unidirectional traffic. The problem might
> be that the sending side is losing time it really needs to be sending
> because it's in a blocking receive or failing to receive data the other
> side is sending because it's in a blocking send.
This is the current model employed, one side only sends and the other
only receives.
>
> If you can ever get in a state where both sides say "I'm not going to
> call receive right now, I'm waiting to be able to send this data
> first", then you can deadlock horribly. The simplest solution is to
> make sure that no matter how long it takes you to send data, you
> continue receiving while you're doing that (just stick it in a buffer
> and process it later if you're lazy).
Sounds like this is what I'll have to do. Unfortunately, I think I'll
probably have to work something out like the other post suggests
(sorry, I forget the name now) and that is to have the application deal
with dropped packets.
I'll start experimenting.
thanks,
Andy
|
|
|
|
|