RE: Experimental TESTxx header usage.

[Kevin Hawkins]

Hi Ian,

> -----Original Message-----
> From: Ian B [mailto:<a
href="/group/xAP_developer/post?postID=ZsQHwL_9XFd3LD77g1nwU3DiA-HZWBfIEGdGzGgzvc1rVwvTDNoPbmZes8qjldzdpQOLCuZsc7Jr">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