Hi,
I would like to know if someone has experienced data sliced in two pieces ?
My case is simple, the UART in the beagleBone Black send the data in two piece …
The problem is that the device answer with an error crc …
so why the uart is doing that ?
Micka,
You’re missing a bunch of information needed to help troubleshoot/ For starters how fast ? Which distro ? Which kernel driver are you using ? etc etc etc.
Ok,
Well, the baudrate is at 38400, the distribution is the Ubuntu from Robert C Nelson ( 3.8.13 bone 30 ), the driver is the omap . I’ve modified a little bit the driver to add RS485 support ( see the patch attached ) , the only major modification that I’ve done is to add :
wait_for_xmitr(up);
if (up->rs485.flags & SER_RS485_ENABLED) {
if(up->rs485.delay_rts_after_send>0){
udelay(up->rs485.delay_rts_after_send);
}
/* Disable RS485 TX EN */
val = (up->rs485.flags & SER_RS485_RTS_AFTER_SEND) ? 1 : 0;
gpio_set_value(up->rs485.gpio_pin, val);
}
in the function serial_omap_stop_tx .
It works most of the time, but for an unknown reason there is this weird behavior …
Any tips ? lead to follow ?
rs485 (1).patch (8.41 KB)
Hi,
Hi,
Thanks for your answer,
Well, it’s just 16 octets or less … most of the time it works, but somehow the driver decide to interrupt the transfer …
yes it’s a single call to write …
Do you know if there is a configuration to solve this bug ? I’m also wondering if it’s because my linux ( 3.8 ) is not a real time kernel … maybe i should apply the kernel PREEMPT_RT ?
I’m really lost …
Micka,
Problem Solved !
By disabling the preempt mode in the kernel config … I have some fopen call in my program which is not a good idea in real time application …
Thx everyone for the help !
Good to her Micka,
I had an idea that this was the problem ( thread was getting interrupted, and state not save properly etc ), but I’m a complete Linux programming newb so . . .
Glad to hear you got it resolved.