Re: xPC Binary Fifo Problem
- From: "Walter Collins" <walter.collins@xxxxxxxxxxxxxxxx>
- Date: Wed, 30 Jan 2008 20:14:02 +0000 (UTC)
I hadn't considered ignoring that. That would make most of
the headers a single byte long (the "command being
acknowledged" byte) with a few being 2 bytes long rather
than all of them being 2 bytes long. The concern now would
be whether data being returned as part of one command's
packet could trigger the code to think that it was the
header of a different command. I will experiment with this
to see if it works with the data streams we need to handle.
Thank you,
Walter
Gordon Weast <gweast@xxxxxxxxxxxxx> wrote in message
<fnqkfl$7ti$1@xxxxxxxxxxxxxxxxxx>...
Is the two character pattern 0xee, 0x11 sufficiently0xee.
unique? That is, just skip the null byte in the search
pattern. That would work as long as the null isn't in
the middle of the pattern.
The null will be skipped over and not returned out the
receive port of the fifo read if you do this.
Just remember to reduce the length you expect by one if
you do this.
The block uses the well tested strncmp() C library routine
to check for the pattern. This routine stops when it finds
a null in either string.
Gordon Weast
xPC Target Development
The MathWorks
Walter Collins wrote:
I'm trying to communicate with a device over the serial
port. The device returns acknowledge packets for every
command issued. The packets are a binary structure
consisting of:
<data length in bytes><byte representing the command being
acknowledged><data bytes if any><check sum byte>
For most commands, there is no data returned in the
acknowledge so it's simply returning 0x00 0xee 0x11 (if, for
example, the command it's acknowledging is command code
decimal.)
I'm running Matlab R2006a with the associated Simulink and
xPC versions that go along with it.
The problem I'm encountering is that the binary header FIFO
under the serial system has problems with headers that start
with 00. Firstly, they will latch onto any packet that
starts with 00, regardless of whether the remaining bytes of
the header are correctly. Secondly, any packet it does pass
always comes out the first port of the FIFO.
To test this, I modified the xpcserialbinarytest.mdl demo. I
set the FIFO settings as follows:
Header:
{char([40,66,190]), char([40,68,188])}
Message Lengths:
[3 3]
Output behavior: Zero output if no data
Enable input (unchecked)
Maximum read size:
40
Sample Time:
trun
This behaves as it should. If I send a packet of 0x28 0x42
0xbe, one output of the FIFO spits the packet out. If I send
a packet of 0x28 0x44 0xbc, the other output of the FIFO
spits the packet out. (My apologies for the hex and
Now if I change the headers in the FIFO block to:
{char([00,66,190]), char([00,68,188])}
Sending 0x00 0x42 0xbe sends the packet out on the first
output of the FIFO. Sending 0x00 0x44 0xbc sends this packet
out on the first output of the FIFO. Sending 0x00 0x01 0x02
will even send this packet out on the first output of the
FIFO, even though this packet is clearly neither of the
headers specified.
Is this a known bug that's been fixed in a more recent
release or is there a simple work-around?
Thanks,
Walter
.
- Follow-Ups:
- Re: xPC Binary Fifo Problem
- From: Gordon Weast
- Re: xPC Binary Fifo Problem
- References:
- xPC Binary Fifo Problem
- From: Walter Collins
- Re: xPC Binary Fifo Problem
- From: Gordon Weast
- xPC Binary Fifo Problem
- Prev by Date: Re: How to solve this infinite series...
- Next by Date: Re: gui greek alphabet symbols, help!
- Previous by thread: Re: xPC Binary Fifo Problem
- Next by thread: Re: xPC Binary Fifo Problem
- Index(es):
Relevant Pages
|
