Reading from /dev/ttyUSB0

Hi,

trying to read data from /dev/ttyUSB0 device
with command cat < /dev/ttyUSB0
according to strace i see that data flow comes in several parts,
althoung on i386 box data comes in one part

it looks like this

read(0, "G", 32768) = 1
write(1, "G", 1G) = 1
read(0, "LG,0462.15", 32768) = 10
write(1, "LG,0462.15", 10LG,0462.15) = 10
read(0, "00,NFM,", 32768) = 7
write(1, "00,NFM,", 700,NFM,) = 7
read(0, "0,0,WORK ROAD", 32768) = 13
write(1, "0,0,WORK ROAD", 130,0,WORK ROAD) = 13
read(0, ",ROAD P, M-8 ", 32768) = 13
write(1, ",ROAD P, M-8 ", 13,ROAD P, M-8 ) = 13
read(0, "ENT,1,0,77,", 32768) = 11
write(1, "ENT,1,0,77,", 11ENT,1,0,77,) = 11
read(0, "NONE,NONE\r", 32768) = 10
) = 10E\r", 10NONE,NONE

so the main question is aren't there any bugs in
kernel/driver/hardware anything else what is connected to BBxM that
enables flow segmentation?

using 3.0.17 kernel from Angstrom and pl2303 driver for usb-serial interaction

What do you mean by ‘flow segmentation’? Are you familiar with termios and programming for Linux serial ports?

Joshua

Sure i do,

when i am talking about flow segmentation i mean several lines coming
from serial port not one,
as it appears in i386 system. Moreover if i am polling serial
interface with 50 ms interval there are errors from the device.
When i do the same polling on i386 box there are no errors ever.

How to perform deep debug to see what happens with flow of commands
and answers?
It seems to me there must be cache issue or smth like that.

I’m sorry to be pedantic, but I think you need to provide much more details about what you are doing.

Sure i do,

Sure you do, what?

when i am talking about flow segmentation i mean several lines coming
from serial port not one,
as it appears in i386 system.

This sounds like you don’t have the correct termios settings if you want to receive reads of data separated by line endings. You could also try fgets.

Moreover if i am polling serial

interface with 50 ms interval there are errors from the device.
When i do the same polling on i386 box there are no errors ever.

What errors are you seeing? What do you mean by polling? Is this non blocking? What speed are you running the serial connection at?

How to perform deep debug to see what happens with flow of commands
and answers?

Deep, like within the kernel?

It seems to me there must be cache issue or smth like that.

Serial port programming in Linux is non-trivial and there are many, many annoying little behaviours with the various termios settings.

Are you sure this is a problem with the beagle[board/bone]? You said this was a USB serial dongle.

This might not be the best forum for this discussion.

Joshua

I am comparing the same programming environment on i386 and bbxm

as a read/write software i am using 'echo' and 'cat' utils

terminal is configured with stty

so taking the same config of terminal and doing echo in cycle and
reading with cat i am getting pretty different behaviour. Dongle is
not changed in this experiments.

So e.g.

stty -F /dev/ttyUSB0 115200
while (true); do echo -ne 'GLG\r' > /dev/ttyUSB0; sleep 0.05; done
cat < /dev/ttyUSB0 (other shell)

in i386 box i am getting
lines with correct information w/o any errors
line by line

when i am running the same code on bbxm
i am getting segmented lines
and device which i am polling (this i mean writing and reading in
cycle) reports me error code as it would get wrong command.

I don’t know if this helps you move forward Anton, but I just solved a console issue with kernel version 2.6.28 by changing the serial/USB dongle from one based on the Prolific PL2303 to one based upon the FTDI FT2232C. Symptoms were that I could send data TO the BB (albeit somewhat unreliably) but could not receive data FROM the BB. I tried two workstations, one Ubuntu and one Windows, both enumerated the serial/USB dongle successfully, but both had the same symptoms, so I believe the issue was on the BB side.