I am doing some embedded systems development work and I have an FTDI USB to Serial bridge chip on the board I am working on. It randomly drops received bytes. This only happens under Arch linux as I just recently switched from Ubuntu and I had no problems there. I have the same problem on another computer I use that also runs Arch, though the problem there is much worse. I'm assuming it's a kernel interrupt priority issue.

I don't really know where to start debugging this, so any input would be much appreciated. Unfortunately, it's quite random. Sometimes it's rock solid and sometimes it drops a byte every few hundred or so, causing some rather anoying issues. Cast in point: it seems to be working fine at the moment but earlier it was wreaking havoc while I was tring to carry out some calibration operations. The other computer I tried it with is consistently bad, though, getting out of sync almost immediately. The first computer (usually good performance) has a high end 2nd gen core i7 (sandy bridge) while the second (not so good performance) computer has an intel atom processor.

Last edited by alex.forencich (2011-09-01 07:07:02). I did some testing on my eee pc (same one as the previous post with an atom processor). In Ubuntu, the connection is rock solid. Didn't drop a single byte in 10 minutes of heavy data transfer. However, in Arch, it consistently drops at least one byte within 2 minutes and breaks the synchronization between the desktop application and the board. Now, I am going to add checks to reset the connection if it comes out of sync, but I really want to figure out what the underlying cause is here since it's definitely not a problem with the USB-serial chip or my firmware. Welcome To The Sandisk U3 Launchpad Installer.

The device on the other end is an Atmel xmega microcontroller. I did not use any flow control when I wrote the firmware as the communication routines in the firmware are very fast as the chip runs at 32 MHz and the USART is interrupt driven. Since only one byte at a time gets dropped, the chip is definitely receiving and responding to the bytes sent as most of the commands are 3 bytes and the responses are 3 bytes, so more than one byte would get lost if a byte got lost on the way there. As for stty, here are the outputs: Arch. Looks like the bytes sent were 13 04 06 so the 13 got eaten somewhere. As hex 13 is XOFF, I tried running stty -F /dev/ttyUSB0 -ixon.

Apr 30, 2012  php serial communication in linux. Arduino Forum >Using Arduino >Programming Questions >php serial communication in. I have installed xampp in fedora 13.I am trying to communicate with microcontroller through serial port using php serial class. My code is example.php(find the attachment).On opening example.php. Canon L11121e Driver For Windows 10.

This seems to have solved the issue. As I had no idea where to start when I wrote the serial interface originally, I looked at gtkterm for how to set up a serial port. It turns out that I forgot to initialize the c_iflag field of the termios struct for the port. After initializing that field to sensible defaults, the problem seems to be solved.

Although I suppose I now have a nice technique for simulating a lossy connection: just turn on software flow control with stty after the port is open and wait for it to blow up! I would have caught it much sooner (and I'm sure realized it was a my bad as opposed to a kernel issue or something) if the Ubuntu defaults were the same as Arch's in terms of flow control. The annoying thing about serial ports in linux, though, is if you don't know what you're looking for, you can't find good documentation for it. Case in point: I had no knowledge of the stty command until you mentioned it. Adrian Predrag Kezele Pdf Printer. Additionally, I had to basically borrow gtkterm's code instead of attempting to roll my own.

It's interesting the kinds of stuff that you run in to doing embedded systems. This was a deterministic problem that showed up randomly.

I had a metastability issue in my code quite a while ago that I didn't realize was a metastability issue because it was completely deterministic, always crashing after the same length of time after startup. It was caused by a complex interaction between a PWM module, a timer, and some buggy interrupt handlers.