RE: Experimental TESTxx header usage.

[Ian B]

Hi Kevin

> I am not sure what you are doing currently to validate the xAP
>message - do you check on a character by character basis against the
rigid
>name/value order ?

I rely on the pairs arriving in the published order and I check against
values in flash and EEPROM. I skip pairs I don't care about and all this is
done one character at a time on the fly. I will have to rethink this so I
try to match against known pairs but in no particular order. The first pair
value should be enough to identify the line I looking at. I can then tick
them off so I don't check against them again and keep going till I run out
AND then hit the brackets.


>Overall in the message receive routine you should constantly check for
and
>cancel all processing of a message based on receiving <STX> or
<ETX>
>(except in the specific context <esc><STX> and
<esc><ETX>). This will avoid
>message lockups. If you are not using checksums then
"----<ETX>" is a key
>message terminator the "-" being '45'. Presumably there is
some timeout too
>- what would happen if the serial data stopped coming in mid
>message - would
>you hang ??

I do for <ETX> but not in the header ID routine. Instead I know how
long the
string I am looking at is and if it doesn't match or is too long I bail
out.
Of course I will need to rethink this :-(

I will be running a watchdog so longterm lockups are not a problem.

As I mentioned on the other list it is holiday time and the build-up so
progress will be slow for the next few weeks.

Ian



>-----Original Message-----
>From: Kevin Hawkins [mailto:<a
href="/group/xAP_developer/post?postID=sygENoqBVgEAF8ZDOYo6_j4Kvx_0xcr5oUI36toFRm5D9cpApmpmXMxc8KZDPEM9Pvr1F4X-238h8gZTBmwC">lists@u...</a>]
>Sent: 06 August 2003 14:32
>To: <a
href="/group/xAP_developer/post?postID=7rq4dc9UVhWKR1cIQznv-HHT2CEPqeFpFDSdxgPC3AJYs97c8t7PcspT4JD8bpjOh7qfYMLduf6fehLn4TnYtJ5pJg">xAP_developer@xxxxxxx</a>
>Subject: RE: [xAP_developer] Experimental TESTxx header usage.
>
>
>Hi Ian,
>
> > -----Original Message-----
> > From: Ian B [mailto:<a
href="/group/xAP_developer/post?postID=qi_uXKEd__KmsEKxoe42Hhb5eslxQlXEvzUw_5DEG-GoIo_1WNU-6iq-gVQJlRbXecG81kN7_mKhBg">Ian@M...</a>]
>
>
> > would probably have misunderstood it in its current context.
>I think it
> > should have had a section of its own rather than being tucked
away in
> > the
> > target section.
>
>I agree - it actually is very significant and deserves more
>emphasis - and
>I think has left footed more than just yourself ;-) P- perhaps we can
>address this in a spec document revision ?
>
>>Never mind though, it is there and I did miss it so
> > water
> > under the bridge.
> >
> > Now, how to fix it. Although I use C I am not a particularly
> > accomplished
>
>me neither unfortunately - and my C parsing routines have the luxury of
an
>incoming message buffer rather than 'on the fly'.
>
> > programmer and I honestly cannot think of a code space efficient
> > algorithm
> > which will allow me to match against strings in flash or EEPROM
> > (different
> > access methods) one character at a time and know the
>difference between
> > a
> > valid segment, an unexpected segment and rubbish because
something has
> > gone
> > wrong.
>
> I am not sure what you are doing currently to validate the xAP
>message - do you check on a character by character basis against the
rigid
>name/value order ? Perhaps you need to accept that the { and } brackets
are
>received OK in order to process the xAP packet. To an extent if
>they are not
>received then you are in a 'corrupted' situation anyway and should be
>discarding the packet anyway. Altering output state based on a known
>corrupted instruction doesn't seem sensible.
> There are only certain 'key' characters you can depend on to synch
>the message and the <LF>}<LF> and <LF>{<LF> in
the centre of the
>message are
>critical to delimiting the header/body sections. Currently if you were
to
>miss these you have the same issue don't you ?? I am not sure where you
are
>seeing the need for this string matching now coming in as an overhead
>because of unexpected header pairs. You don't have to recognise Testxx
as
>such - just ignore it as any other unexpected pair should be. Do you
>currently set a flag when you transition from header to body or perhaps
you
>just interpret all name value pairs after the 'expected' header
>ones as body
>name/pairs ?? If so I could see why this could be causing problems
now...
> You are one of the pioneer developers based on a serial xAP data
>stream. UDP data of course has a certain protection against
>corruption based
>on the Ethernet packet checksums. Specifically for this purpose we
included
>an (optional) checksum feature for transport layers that are prone to
>corruption, serial, radio etc. Do you use this checksum feature ?
>That would
>solve all your corruption issues here - (but would create another if
you
>haven't coded it of course). I think it boils down to a design decision
>based on how critical the operation of the devices attached to your
board
>may be - for an irrigation system there is probably some leeway but I
guess
>you don't know just what people may be controlling.
>
> > If for some reason I had corruption and missed the open and close
> > brackets in the middle of the message I would end up trying
>to evaluate
> > the
> > body as a header and ignore all the pairs. If I then missed the
<ETX>
> > this
> > would cause the unit to lock up as it would be continually trying
to
> > analyse
> > a message header. I know this is a worst case scenario but this
is the
> > way I
> > work - thorough (except when reading the spec it seems). Any
advice
> > here
> > would be very welcome.
>
>I would have thought you would have had to totally disregard all
corrupted
>packets and therefore should rely on critical synchs occurring mid
message
>based on the <LF>}<LF> and <LF>{<LF> characters
coupled with recognition of
>xap-header<LF>{<LF> and <LF>}<LF> at the end.
>
>Overall in the message receive routine you should constantly check for
and
>cancel all processing of a message based on receiving <STX> or
<ETX>
>(except in the specific context <esc><STX> and
<esc><ETX>). This will avoid
>message lockups. If you are not using checksums then
"----<ETX>" is a key
>message terminator the "-" being '45'. Presumably there is
some timeout too
>- what would happen if the serial data stopped coming in mid
>message - would
>you hang ??
>
> Patrick has some C code on his site (he says hoping it's up and
>running) although I suspect it is buffer based rather than on the fly.
>
> >
> > As for the bit where the version number changes, this is a valid
point
> > and
> > one I had not thought of. I think the answer here is simply to
ignore
> > the
> > bit after the 'V' and not fail on this at all. This will
effectively
> > give me
> > compatibility with all versions although it may fail elsewhere.
>
>Yep - storing a latest version compatibility number would stop your
product
>breaking though if such a change ever happened to the xAP spec -
>xAP v 6.66.
>Depends on how ...." I know this is a worst case scenario but this
is the
>way I work" .....critical that is.
>
> >
> > Ian (hoping for some wizzy C advice)
>
>Not from me - I am still only 3/4 way through the book !
>
> Kevin