FullDuplex <-> linux (over FTDI) blues
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
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
Comments
Have you set the CLK-settings in the Top Spin object?
for a Protoboard:
CON
_clkmode = xtal1 + pll16x
_xinfreq = 5_000_000
Andy
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
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!
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
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!
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)