Prev: ANN: Seed7 Release 2010-07-18
Next: Segmentation fault happening randomly
From: Mark on 19 Jul 2010 00:17
Hello

I'm developing a simple application for embedded system with RS-485
interface running a proprietary protocol, specifically doesn't use
start/stop bits. So, I should disable these bits in my application (because
now I can with oscilloscope that every byte is prefixed with start sequence.

So I came up with this code, but it appears I'm missing something:

int fd;
struct termios oldTermios, newTermios;

if ((fd = open(dev, O_RDWR | O_NOCTTY | O_NONBLOCK)) < 0) {
return -1;
}

if (tcgetattr(fd, &oldTermios) < 0) {
return -1;
}

memset(&newTermios, 0, sizeof(struct termios));

newTermios.c_cflag = CS8 | CLOCAL | CREAD | UART_DEFAULT_BAUD;
newTermios.c_iflag = IGNPAR;
newTermios.c_oflag = 0;
newTermios.c_lflag = 0;
newTermios.c_cc[VTIME] = 0;
newTermios.c_cc[VMIN] = 0;

if (tcsetattr(fd, TCSANOW, &newTermios) < 0) {
return -1;
}

if (tcflush(fd, TCIOFLUSH) < 0) {
return -1;
}

Would appreciate any suggestions or advices to fix it. Thanks.

--
Mark

From: Mark on 19 Jul 2010 00:25
Forgot to post the output of 'stty' after running my program:


~/tmp # stty -F /dev/ttyS1
speed 9600 baud;
intr = <undef>; quit = <undef>; erase = <undef>; kill = <undef>; eof =
<undef>;
start = <undef>; stop = <undef>; susp = <undef>; rprnt = <undef>;
werase = <undef>; lnext = <undef>; flush = <undef>; min = 0; time = 0;
-brkint -icrnl -imaxbel
-opost -onlcr
-isig -icanon -iexten -echo -echoe -echok -echoctl -echoke

--
Mark

From: Gordon Burditt on 19 Jul 2010 01:37
>I'm developing a simple application for embedded system with RS-485
>interface running a proprietary protocol, specifically doesn't use
>start/stop bits. So, I should disable these bits in my application (because
>now I can with oscilloscope that every byte is prefixed with start sequence.

CSTOPB is used to control 1 vs. 2 stop bits. You have CSTOPB turned
off (at least 1 is closer to 0 than 2).

I don't think termios was designed to deal with synchronous protocols.
(which I'm assuming it is since I don't see how you can have an
asynchronous setup with no start or stop bits.)

What driver are you using with this hardware? A driver that knows
it's talking to a synchronous port but trying to pretend to the
software that it's a regular asynchronous port may simply ignore
anything about start/stop bits and always turn them off. A driver
that knows it's talking to hardware that can do synchronous or
asynchronous may have a non-standard bit to switch modes between
synchronous and asynchronous. Or it may use a non-standard ioctl.

I think you have some documentation reading to do for your specific
platform.

When you display the resulting settings from your program, you
may want to use "stty -a" which shows more settings. That program
may still not know about any non-standard options your port has.

From: Mark on 19 Jul 2010 02:25
Gordon Burditt wrote:
> What driver are you using with this hardware? A driver that knows
> it's talking to a synchronous port but trying to pretend to the
> software that it's a regular asynchronous port may simply ignore
> anything about start/stop bits and always turn them off. A driver
> that knows it's talking to hardware that can do synchronous or
> asynchronous may have a non-standard bit to switch modes between
> synchronous and asynchronous. Or it may use a non-standard ioctl.

Our design is using FT2232D chip converting from USB to serial, its driver
is port of 2.6 kernel tree, ftdi_sio.c I don't think the driver knows
something about synchronous port, perhaps I should modify it.

> When you display the resulting settings from your program, you
> may want to use "stty -a" which shows more settings. That program
> may still not know about any non-standard options your port has.

--
Mark

From: Paul on 19 Jul 2010 04:11
Mark wrote:
> Gordon Burditt wrote:
>> What driver are you using with this hardware? A driver that knows
>> it's talking to a synchronous port but trying to pretend to the
>> software that it's a regular asynchronous port may simply ignore
>> anything about start/stop bits and always turn them off. A driver
>> that knows it's talking to hardware that can do synchronous or
>> asynchronous may have a non-standard bit to switch modes between
>> synchronous and asynchronous. Or it may use a non-standard ioctl.
>>
>> When you display the resulting settings from your program, you
>> may want to use "stty -a" which shows more settings. That program
>> may still not know about any non-standard options your port has.

> Our design is using FT2232D chip converting from USB to serial, its
> driver is port of 2.6 kernel tree, ftdi_sio.c I don't think the driver
> knows something about synchronous port, perhaps I should modify it.

When I look at the data sheet for that device, I get the impression
it supports async (start_bit, data, stop_bit) operation at speeds
up to 3 megabaud. The max internal clock is 48MHz, and using x16
style async clocking - that means it can handle up to 3 megabaud.

http://www.ftdichip.com/Documents/DataSheets/DS_FT2232D.pdf

The diagram on page 33 shows connections for RS-485, operating
at up to 3 megabaud async (subject to line length limitations -
you don't get that speed with 4000 feet of cable, only with
a short cable).

If you use the MPSSE hardware functions, the interfaces in the examples
provided, all use discrete clock signals. Perhaps you could set up a
pair of wires to carry clock, but that would be silly and probably
not the way your hardware design has things connected. Sending
clock on a separate cable, would have EMI implications. I don't know
in the case of this MPSSE function, whether the clock is steadily
running, or is more of a strobe as far as the design is concerned
(the clock may only be pulsed on an as-needed basis).

SPI I2C JTAG

MOSI SDA TDI
MISO SDA TDO
SCLK SCK TCK
CS --- TMS

http://www.ftdichip.com/Documents/AppNotes/AN_135_MPSSE_Basics.pdf

I think you're going to run this way --

http://en.wikipedia.org/wiki/Rs-485

http://en.wikipedia.org/wiki/File:RS-485_waveform.svg

RS-485 has three line states - driven_1, driven_0, float. By
including bias resistors on the bus (not shown in the FTDI diagram),
the float condition is converted to a logic 1 or a mark. The result
is the bus only has two visible conditions, mark or space. In that
picture in Wikipedia, the first space is used as a start bit, and
the x16 clock starts ticking to detect the middle of a bit cell.
And that is used for asynchronous serial communications.

If you'd selected some chip other than the FTDI device,
one with its own clock recovery PLL, it might have been
able to synchronize itself to bit transitions. You'd need
a transition rich encoding on the bus, to make that a reasonable
prospect. In addition, a synchronous protocol, needs a means
of framing bytes. The 0x7E flag byte, is an example
of a means of framing a synchronous link. Such a pattern would be
detected by a chip (not software, to reduce processor loading),
and whole messages might be delineated by flags. Escape codes
are used to compensate for the inability to send 7E as user data.
That is an example of a protocol that might have worked.

You can see some of the terminology in this advertisement.

http://www.quatech.com/catalog/rs422s_pcmcia.php

"the card's SCC provides advanced internal functions including
... digital phase-lock loop (DPLL) for recovering data clocking
from received data streams."

"supports asynchronous data formats as well as byte-oriented
synchronous protocols such as BiSync, and bit-oriented
synchronous protocols such as HDLC and SDLC."

You should talk to your hardware engineer, about the design
intent of the hardware you've got. The reason "ftdi_sio.c" might
not have any mention of synchronous operation, is because the
hardware does not support it.

Just a guess,
Paul
 | 
Pages: 1
Prev: ANN: Seed7 Release 2010-07-18
Next: Segmentation fault happening randomly