I may have that problem as well. I'm using a 434MHZ RF transmitter and receiver. The rate of receiving data correctly is low, even though the waveform on the oscilloscope is perfect. 
And data shows on the screen in a burst, not continuously. 
I guess its because the Serial port has a buffer. My baud rate is 2400, and my RF module is simple and probably unreliable.
I tried 2 method (non-blocking, some change in setserial, I forgot..) and no change on the behavior.

Any suggestions?

On Wed, Feb 26, 2014 at 2:07 PM, Markus Svilans <msvilans@aeonyx.ca> wrote:
Dear gumstix-users,

I need some help troubleshooting an interesting serial communication
problem with the Gumstix Overo.

Recently I switched from a tried and tested kernel 2.6.34 to a newer
kernel 3.5 for a Gumstix Overo embedded project.

One of the OMAP serial ports is used to communicate with another device,
at 230400 baud 8-N-1. We are running the serial link at ~85% capacity.
This has been working very well with kernel 2.6.34 so far.

With kernel 3.5, we are having some serious problems. There is now a gap
of 200-300us between each group of 16 bytes in UART transmissions coming
out of the Gumstix.
Here are screenshots from my scope to illustrate:


The gaps should not be there. There should be a continuous burst of
RS-232 activity.

We are sending frames ~1300 bytes in size. The time gaps increase the
transmission time for each frame, preventing our system from functioning

Here are several of the things I've tried, none of which has made any
- Changed serial port from blocking to non-blocking, and back
- Changed kernel from preemptible, voluntary preemptible, non-preemptible
- Changed tick rate from 128 (default) to 1024 and back
- Disable tickless kernel, re-enabled tickless
- Played with thread priorities in software that transmits via serial
port -- made them all default priority, reduced priority, increased
some, not others -- various permutations
- Changed thread scheduler from SCHED_RR to SCHED_OTHER, and back

One main difference I am aware of between between kernels 2.6.34 and 3.5
is that in 3.5 the omap-serial driver is used, versus the classic 8250
driver that was used in 2.6.34.

Here are my best guesses at the moment:
- 16 bytes is the common Uart Tx FIFO size
- Suspect there is something happening in the omap-serial driver,
preventing a continuous stream of data. Instead there is a pause
inserted each time the Tx FIFO is emptied.

Has anyone seen something like this? Any solutions in later driver versions?

Any assistance at this point would be vastly appreciated.

Best regards,

Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis & security monitoring. All-in-one tool.
gumstix-users mailing list

Airie Zhou