Hi! I've been doing some more tests. For example, we lowered the
system clock down to 20 MHz and found the exact same behavior, so we
don't think this is purely an issue with the kernel missing bytes.
Nonetheless, we think we've found what's wrong with the
communication. The interfaced device's Tx line is kept LOW (i.e.,
serial break) during silent periods and raised to start communication
only 200 µS before the first byte is transmitted (something around 23
bits at 115200 bauds). It looks like the CPLD serial implementation
is not handling the break signal properly and so the first bytes are
garbage. Other bytes might be affected by this as well. Let me give
you an example of what is we're seeing with the osciloscope on the
serial line:
____Is00110011eTs00000000eTs10000000eTs10000000eTs01010101eTs00000000eE____
01234567 01234567 01234567 01234567 01234567 01234567
CC 00 01 01 AA 00
Meaning:
_ = line kept low (several seconds) between messages.
I = line kept high as a preamble before first byte (200µS total)
s = start bit (0)
0 = a 0 belonging to the transmitted byte
1 = a 1 belonging to the transmitted byte
e = stop bit (0)
T = an extra stop bit (1) found between bytes
E = line kept high as ending (200µS total)
The above is seen by the serial driver alternatively as:
[c0][cc][00][aa]
[fc][cc][00][aa]
[00][cc][00][aa]
As you can see, this particular message fails even when it is only
six bytes long!! And we're getting only four, one of which is not
actually part of the message.
We also tested with COM2 (using a voltage converter) and everything
works out fine, but we really need COM2 for other purposes.
My guess now is that the only possible fix, if any, must come from
Technology Systems, for this goes deep into the CPLD logic.
Guille
--- In "Guillermo
Prandi" <> wrote:
>
> Hi! Perhaps someone has faced this problem before:
>
> We bought one TS-7260 with the OP-2TTLCOM option. We've been doing
> some tests on COM3 (/dev/ttyTS0) at 115200 (our interfaced device
> ONLY works at 115200 bauds!). This device sends bursts from 8 to 18
> bytes. We're missing most of these bursts bytes. We thought we
would
> be able to catch all 18 bytes seamlessly with the 5 byte buffer,
but
> it looks like not even the first five are caught. We sometimes get
5
> and sometimes 4, although not the first 4 or 5 but interleaved
> samples (e.g., acdfh instead of abcdefgh). The manual warns about
> using a full 115200 baud rate, but we didn't know the situation was
> so bad :(. Things get worse if we think of lowering the system
clock
> down to 20MHz for power saving (our tests were performed with a
full
> 200 MHz clock). We can't afford connecting an RS-232 daughter board
> because our power budget is very tight (we're already using a $800
Li-
> ion battery!). We *really* would like to avoid using additional
> MAX3232 chips in order to use COM2 for this device. COM1 is needed
> for a device that uses full modem cabling, and COM2 is used for the
> console. COM4 is used for a GPS receiver (4800 bauds, we're not
> experiencing any problems here), and COM5 is used for a GPS modem
(we
> could lower down baud rate here up to 19200 with no problems).
>
> Any suggestions?
>
> Guille
>
------------------------ Yahoo! Groups Sponsor --------------------~-->
Great things are happening at Yahoo! Groups. See the new email design.
http://us.click.yahoo.com/SktRrD/hOaOAA/yQLSAA/CFFolB/TM
--------------------------------------------------------------------~->
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/ts-7000/
<*> To unsubscribe from this group, send an email to:
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
|