Re: xPC Serial Communication Problems

I'll start with the oscilloscope, since that's what we used to
discover this problem and because the only reason I mentioned the
receiving system was that that system can't handle the packets
becoming lopsided like this. I'll describe that system in more detail
later, just in case you think it might be useful.

We did hook an o'scope up to the transmit line coming out of the
target PC. This confirmed that when we saw strange behavior on the
console, the packets coming from the target PC are still 15 bytes
long, 115.2 kbps, etc. The only difference is that it was if we'd
rotated the packet structure so that we had 1, 2 or 3 data bytes at
the beginning of it, then the 6 synch bytes, then the remainder of
the data bytes. Everything about the packet looks just fine, other
than being "rotated" like this. That's why I put forth my guess that
somehow we either lose a byte or add a byte or something in the
serial routines on the target computer. The "beginning" of the packet
doesn't always look the same due to this packet rotation. The only
other thing I can think to add is that the CPU uses a 16550 (or some
reasonable facsimile) so the hardware buffer should be 16 bytes.

Packet should be:
BA BD BD BA BA BD 0 7 255 7 255 7 255 0 0

Packet ends up something like:
255 0 0 BA BD BD BA BA BD 0 7 255 7 255 7

(with very large gaps between packets so it's easy to see that we're
looking at a packet)

The console is an embedded microcontroller running homebrew C code.
The serial port doesn't have any hardware buffer so I have an
interrupt reading it after every byte and the interrupt's high enough
priority that it doesn't get interrupted itself. I drop the bytes
into a ring buffer and then "look backwards" to see if the synch
bytes are "in position" and if they are, then I know I've received
the whole packet and I pass it along to the main loop. The ring
buffer's currently 16 bytes and we've verified that it can't get a
false positive on the synch byte check. I could modify its code
slightly so as to double buffer the data and this *should* avoid the
console going crazy when this packet shifting takes place, but it
doesn't solve the source of the packet shifting. It would, however,
mean that we might be lagging by 50 ms as we wait for the tail end of
a packet to come in. In the current use, that 50 ms is probably
acceptable, but this may not always be the case. Hopefully this
answers all of your questions.

Walter

Gordon Weast wrote:


Walter,

I'll ask a few questions about your system before making a guess
about what's going on here.

Is the receiving machine executing at the 'same' 50 ms rate?
I quote the word 'same' since any such attempt will always result
in drift between the two machines unless something forces them
to stay synchronized.

Is the receiving machine using a read call to its system that can
return exactly 15, or merely up to 15 characters at a time? That
is,
does it wait until there are at least 15 characters in the receive
buffer, then return exactly the first 15, or does it return
whatever
is in it's buffer, up to 15 characters?

Does the receiver throw away characters until it sees the sync
characters,
then read the fixed message length? This will force
synchronization,
even when the reader executes when a partial message has been
received.
A partial message could be in the receive buffer if the two
machines
execute with the right phase shift (receiver looks at the buffer
when
a message is partially done).

I suspect you're seeing a timing drift problem, but I can't be
sure.

If you connect an oscilloscope to the transmit data wire and
measure
the data burst, is it 15 characters long at 115200 baud? With 8
data
bits, plus start and stop, there are 10 bits per character so this
data rate is 15*10/115200 = 1.302 ms. Is it always this length
with the
beginning always looking the same? If so, then you're seeing a
receive
synchronization problem.

Gordon Weast
xPC Target Development
The Mathworks

Walter Collins wrote:

I'm using RTW with the xPC target to send data from the target
computer to a control console. The data is 15 bytes long and
gets
sent every 50 ms (20Hz). The model on the target computer
currently
consists of 5 constant source blocks (split off into 15 lines)
going
into a pack block that's expecting 15 uint8's and this is fed
into a
binary serial send block. The serial send block's message width
is 15
with a sample time of 0.05. The rs232 set-up block sets the
port
up
to be 115.2 kbps with Tx and Rx buffer sizes of 1024, no
parity,
8
data, 1 stop, no protocol.

With that out of the way, the problem is this. The code works
just
fine for a while. The packet has 6 "synch" bytes at the
beginning,
followed by a combination of 0, 255 and 7. Monitoring the
serial
stream coming from the target computer, we can clearly see each
of
these where we expect them. After some random amount of time,
however, the serial stream changes. The bytes seem to be the
right
bytes, but now they're out of order. It's as if we lost some
bytes or
added some at some point. Now we'll have some of the data bytes
(the
0, 255, 7) at the beginning of the 15 byte packets, followed by
the
sync bytes, follewed by the rest of the data. This is causing
havoc
on the receiving end, which relies on there being a bit of
breathing
room at the end of a packet. Since the packets are now split
between
packet trasmissions, we don't have that breathing room.

Has anyone else seen this or have any recommendations on how to
fix
it? I've tried looking through the Simulink code for the serial
blocks, but they just refer to "functions imported from the
kernel"
so I can't see how they're actually handling the serial
communication
on a low level.

Thanks in advance for any help,
Walter

.

Relevant Pages

  • Re: Fundamentals question, is this how it works?
    ... Note the packet may be partially received when you get ... That is what i thought i was saying that it receives it all in a stream ... receving the buffer size each time. ... receiving that many bytes i then break and wait for the next set of data ...
    (microsoft.public.win32.programmer.networks)
  • Re: Fundamentals question, is this how it works?
    ... Microsoft MVP, MCSD ... Knowin when that second packet started is my problem. ... stream receving the buffer size each time. ... then the receiving side might ...
    (microsoft.public.win32.programmer.networks)
  • Re: Losing UDP packets with MFC Sockets
    ... Are you saying that in the input buffer I read from ReceiveFrom could exist ... "AliR" wrote: ... > receiving process is busy doing other things. ... >> class to indicate the packet arrival. ...
    (microsoft.public.vc.mfc)
  • Re: Fundamentals question, is this how it works?
    ... You maintain a buffer for the last incomplete packet. ... receiving that many bytes i then break and wait for the next set of data ... With a tcp stream socket what happens when it is reading say 4000bytes ...
    (microsoft.public.win32.programmer.networks)
  • Re: xPC Serial Communication Problems
    ... never seen bytes get wrapped like you're seeing with the new driver. ... Everything about the packet looks just fine, ... reasonable facsimile) so the hardware buffer should be 16 bytes. ... does it wait until there are at least 15 characters in the receive ...
    (comp.soft-sys.matlab)