ftdi-usb-sio-devel

[Ftdi-usb-sio-devel] Long delay between break signal and first data bytes

[Peter K. <pet...@we...>]

Hi,
I am using an FTDI device on a linux system (2.6.24-21) USB Data are:

FTDZIG54, TTL232R

I am having some trouble to get tcsendbreak() working. I am expecting a 
break level for some milliseconds on the TX line followed by the data.

The C code looks as follows:
//
int sync=0x55;

tcsendbreak(handle,0)
write(handle,&sync,1)
...
//
When I connect a scope to the tx line I can see something like:

~~~~.__,~~~~~~~~~~~~,_|||||
     A break signal
         some 500ms delay
                     the data beeing sent

I wonder how I would be able to send a break, immediately followed by my 
data. The problem is that other devices on the line do not expect such a 
long delay following the break signal.

Any help regarding breaks and general serial programming for ftdi 
devices under linux would be very much appreciated.
I have scaned the internet for some help but nothing apropriate was found

regards, Peter

Re: [Ftdi-usb-sio-devel] Long delay between break signal and first data bytes

[Bill R. <bil...@gm...>]

Did you try tcsendbreak with a set value rather than 0?

By default it may wait up to 500ms even though data isn't being sent for
500ms

You can check it with strace -T yourTestProgram  - you'll see the duration
of tcsendbreak in <>'s in the output.



On Sat, Oct 25, 2008 at 3:38 AM, Peter Künnemann <pet...@we...>wrote:

> Hi,
> I am using an FTDI device on a linux system (2.6.24-21) USB Data are:
>
> FTDZIG54, TTL232R
>
> I am having some trouble to get tcsendbreak() working. I am expecting a
> break level for some milliseconds on the TX line followed by the data.
>
> The C code looks as follows:
> //
> int sync=0x55;
>
> tcsendbreak(handle,0)
> write(handle,&sync,1)
> ...
> //
> When I connect a scope to the tx line I can see something like:
>
> ~~~~.__,~~~~~~~~~~~~,_|||||
>     A break signal
>         some 500ms delay
>                     the data beeing sent
>
> I wonder how I would be able to send a break, immediately followed by my
> data. The problem is that other devices on the line do not expect such a
> long delay following the break signal.
>
> Any help regarding breaks and general serial programming for ftdi
> devices under linux would be very much appreciated.
> I have scaned the internet for some help but nothing apropriate was found
>
> regards, Peter
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Ftdi-usb-sio-devel mailing list
> Ftd...@li...
> https://lists.sourceforge.net/lists/listinfo/ftdi-usb-sio-devel
>

Re: [Ftdi-usb-sio-devel] Long delay between break signal and first data bytes

[Peter K. <pet...@we...>]

Bill,

I tried tcsendbreak with a value of 1 (and other non zero) which 
resulted in no break beeing sent at all.
The problem here is, that the protocoll on the bus I am talking to does 
not allow a delay longer than a character after the break. Whatever I 
tried, it always caused a long break.
I even build a smal circuit that pulls the BUS Tx Signal to ground by 
using RTS. The interesting behaviour then is:

TX  ~~~,___,~~~~~~~||||
RTS ~~~,___,~~~~~~
            |<-.?.->|

Delay of about 50ms betwen raise of RTS and first data byte. The code 
does not implement any delays except for the RTS.

Not sure what this means? Is there anything in addition that I missed in 
programming the FTDI Driver?

Thanks for your patience.  Peter

Bill Ryder wrote:

 > Did you try tcsendbreak with a set value rather than 0?
 >
 > By default it may wait up to 500ms even though data isn't being sent 
for 500ms
 >
 > You can check it with strace -T yourTestProgram  - you'll see the 
duration of tcsendbreak in <>'s in the output.
 >