FullDuplex <-> linux (over FTDI) blues

pems

Messed with it all day to no avail, so came here for help

trying to use FullDuplex object to send data to a host PC with my app listening on the serial port that the FTDI chip (which is in the propplug) provides.

using 9600 8n1 and usual settings to initialize the serial port on linux.
The general problem that i am experiencing is the app getting too few / too many bits in some bytes it receives, which totally messes up the data flow.

i've tried to isolate the issue, so i did the following: sending from the prop either 0x0f or 0xf0 one by one. The result on the app end is 0x0f for 0x0f (ok) and 0x70 for 0xf0 (looks like it reads too many zeros - 5 instead of 4, i.e 00000111 instead of 00001111 , where LSB is on the left)

Am i missing anything?

Thank you

Ariba

Sounds like a Baudrate problem.
Have you set the CLK-settings in the Top Spin object?

for a Protoboard:
CON
_clkmode = xtal1 + pll16x
_xinfreq = 5_000_000


Andy

pems

Thanks Andy, i did (used the top object from some example)

very small progress on the above: managed to get receive my 0xf0's properly (receive 0xf0 instead of earlier incorrect 0x70)
Simply had to flag-out the following option:

options.c_iflag &= ~ISTRIP;

this option seems to allow the serial port to actually receive the extra bit(s) as opposed to cutting a byte short (hence 0x70 instead of the proper 0xf0)


but i am still experiencing loss of bytes occasionally

BradC

I usually use
stty -F /dev/ttyUSB0 raw -echo

If you are actually writing code, then
c_cflags = CLOCAL | CREAD | BAUD

zero all the other option registers..

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!

pems

Thanks a lot Brad, you gave me a very good hint: zero out all the options. I am guessing some flag left enabled in options was giving me problems

Here is a little serial setup recipe i am using - no dropped bytes yet

tcgetattr(fd, &options);

// clear all options
options.c_lflag &= 0;
options.c_iflag &= 0;
options.c_oflag &= 0;
options.c_cflag &= 0;

cfsetispeed(&options, BITRATE); // where BITRATE is defined as something like B115200
cfsetospeed(&options, BITRATE);
options.c_cflag |= (CLOCAL | CREAD);

options.c_cflag |= CS8; // i think this is needed to tell linux how many bits to use for data


// Set the new options for the port...
tcsetattr(fd, TCSANOW, &options);

fcntl(fd, F_SETFL, FNDELAY); //no blocking

BradC

Ahh, you must be on a BSD derivative.. yes.. that's the way to do it.

On Linux you need to OR the bitrate constants against options.c_cflag.

Also you probably don't need the FNDELAY as that is generally used on IP sockets.

You need Block/nonblock for serial hardware, but don't go setting nonblock unless you are doing select() on the FD properly or you _will_ lose data.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!

pems

Nope, ubuntu 8.04 here

the example i started with is some example off the web. I don't want it to block because i don't want my UI, that's in the same loop, to be sync'ed to these blocks. I want it to be fluid, so i'm fine with just polling the serial port.
So far so good, with no dropped bytes (i even tried 460800 baud successfully)