Re: xPC Serial Communication Problems

Walter,

The older serial block you're using uses the kernel resident driver
and I don't have much control of that.

The newer component version runs entirely in Simulink code. I've
never seen bytes get wrapped like you're seeing with the new driver.
The data you send needs to be formatted slightly different for the
new driver. Since you have data bytes that have the value 0, you
need to present the data as a vector of 16 bit values. Only the
bottom 8 bits are sent, just leave the upper 8 bits empty. The
first element is the number of values to follow. So, with the
old driver you would have the vector:

[0xBA 0xBD 0xBD 0xBA 0xBA 0xBD 0 7 255 7 255 7 255 0 0] as a uint8 vector,

with the new driver you would change this to:

[15 0xBA 0xBD 0xBD 0xBA 0xBA 0xBD 0 7 255 7 255 7 255 0 0] as a uint16
vector.

The new driver interprets a uint8 vector as a null terminated string,
so it would take the first vector and just send the 6 byte header and
stop before sending the 0. The uint8 vector format is therefore only
useful for true ascii strings that don't contain 0 data bytes.

You will get a lot more control with the new driver. I've never seen
it send bytes out of order or a message get rotated like you're seeing.

Gordon Weast
xPC Target Development
The Mathworks


Walter Collins wrote:

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: Direct Copying To Share Memory In NDIS ProtocolReceive
    ... Application allocates large structured buffer with room for seveveral packets. ... Driver fills buffer with multiple packets and eventually completes the read IRP. ... This, or variations on this, should work for you withoug having to have shared memory and events that are not part of the standard I/O scheme. ... I am wondering if I can obviate much of the NDIS packet allocation by ...
    (microsoft.public.development.device.drivers)
  • Re: Question about modifing the NDIS packet?
    ... packet FROM a miniport BACK of the net. ... If your driver is an intermediate ... you driver changes the length of the ndis packet buffer - here you ... your driver is not a registered ndis driver. ...
    (microsoft.public.windowsxp.device_driver.dev)
  • Re: xPC Serial Communication Problems
    ... Everything about the packet looks just fine, ... reasonable facsimile) so the hardware buffer should be 16 bytes. ... Is the receiving machine executing at the 'same' 50 ms rate? ... does it wait until there are at least 15 characters in the receive ...
    (comp.soft-sys.matlab)
  • Re: Packet alignment constraint in WinUSB
    ... a buffer of 1024 bytes is required. ... application code is not concerned with USB packet sizing. ... there is no inherent USB controller limitation. ... simply reading a partial packet directly from the driver. ...
    (microsoft.public.development.device.drivers)
  • Re: Interrupts disabled for too long in printk
    ... serial driver getting interrupts to be able to display the message? ... for 72 characters in 15 ms. So the console driver would be ... Why can't the serial console driver record the message in a buffer at ... the point where it is being called with interrupts off, ...
    (Linux-Kernel)
Loading