Re: xPC Serial Communication Problems

Gordon,

I had looked into the possibility of upgrading to the newer blocks,
but I'm a bit lost. We're running version 2006a and all of the actual
serial communication blocks (that aren't marked "not for new models")
seem to be written for specific add-on serial port/communications
boards. I don't see a single one for using the serial ports that come
on a CPU card. We're using the serial ports that come on the CPU
board since we don't have room to add an extra PC-104 card to the
stack (and it has 2 ports on it, which is all we need). Did I miss
some documentation somewhere on how to upgrade from the older blocks
to the newer ones in the instance we're in? Looking over the FIFOs
with the advice you posted makes me think I can use those just fine
to implement what we're doing in the old code, but I'm stumped as to
what I should be doing as far as connecting those FIFOs to the
onboard serial ports.

Thanks for all the help you've given.
Walter

Gordon Weast wrote:


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: Accessing peripherals from a managed application
    ... You call the Win32 APIs for serial ports. ... beitman AT applieddata DOT net ... Maybe you open the driver with CreateFile, ... Call on the imported functions to access the hardware. ...
    (microsoft.public.windowsce.app.development)
  • Re: Inserting flow-control chars with an mpsafetty kernel
    ... ^Q characters cannot be inserted inserted anymore. ... TTY code, but it is not so directly involved in the handling of the ... When I implemented the ptsdriver, I thought the idea behind TIOCPKT ...
    (freebsd-current)
  • Re: Complete Pascal Reading from Serial Port?
    ... GS/OS generated driver. ... printer driver architecture. ... to send data to the serial ports, but they are no use for communication ... The nonexistent driver would be a native GS/OS character device driver ...
    (comp.sys.apple2.programmer)
  • Re: Bytes
    ... architecture, for the following reasons: ... to make Windows NT driver support easier. ... convert between wide characters and multibyte characters and this is ... be simply mapped to multibyte characters in C, ...
    (comp.lang.forth)
  • Re: Multiport Serial
    ... > I am writing a kernel mode driver for a PCI card with 16 serial ports. ... Serial" (GUID 50906cb8-ba12-11d1-bf5d-0000f805f530). ... > None of the 16 child devices seem to appear to the system as serial ports. ...
    (microsoft.public.development.device.drivers)