Re: xAP Configuration, Serial RS485 Bridge and PIC's

["g8kmh" <g8kmh@xxxxxxxxxxx>]

<snip>
> I think that one will be a try it and see - will be interesting -
in a
> purely xAP Ethernet domain and using Netiom you can get very large
> throughputs of 60+ messages per second through BSC Mapper, hub etc
so
> should be pretty good. Are you using the xPL DMX app or a xAP
one ?
> There are known issues with high volume data via xPLHAL currently
which
> is on Tony's bug fix list.
>
xPL for now but an xAP implementation would be nice.

The intention was max messages at 10 per second with the initial ramp
at 2.55 seconds from level 0-255 (no surprise there!).

> Could you enlist a middleware layer that just takes
a 'press'/'release'
> message and handles the 'hold' by deduction (which is sort of how C-
Bus
> works)
>
> Press > threshold time causes start ramp command and release causes
> end.  If threshold time not exceeded then release causes toggle.
>
I could but I'd prefer not to. One reason for going down the xAP
route is the potential for autonomous operation (without a PC) in
some scenarios, although not currently in this iteration.

For now I'll probably just have the flags in the EEPROM and change
them as I blow the device. If there is then space I'll look at a very
specific config message and schema.

> Ian B is the one you want here as he has a xAP implementation on
> serial.  To an extent the CRC was there to protect and if not
required
> in a given application I suppose your could opt out of this
(although
> not to spec) - the embedded work I have done has adequate processor
> resources fortunately to work on packets rather than on the fly.
(Rabbit)
I wouldn't want to go without the CRC on a potentially long serial
network.  It isn't too much of an overhead in generation. The current
target is the PIC18F2320.

Yes Rabbit's. Z80's, Nascom 1, the memories - I can still remember
half the opcodes!... but as you say plenty of resource.  Pricing
isn't too bad either.

> If your devices have no interest in certain xAP traffic (ie no
ability
> to respond /action  in any way  particular messages) then I see
little
> pupose on bridging that data onto the slower RS485 - you may as
well
> filter & drop it - this of course is very application specific but
my
> approach would be to only pass data that has a 'purpose' to RS485
based
> on source address / target address and message type (class)
filtering.
> Your RS484 would then be only carrying pertinent data.   I am aware
of
> one approach that tokenises certain xAP keywords too.
>
> BTW one very different feature of xAP is the UID which uniquely
> identifies a source - receivers can detect originating nodes based
on
> this rather than the longform source address.  (ie 4 bytes) . This
saves
> a load of storage space.  The source must still be transmitted in
> broadcast xAP networks as wildcarding only functions on source (you
cant
> wildcard a UID). If you didn't transmit source then a listener
based on
> a wildcarded source address filter would fail. How you apply this
to a
> custom  RS484 bridged network with subset traffic I guess is your
choice .

Without some better xAP configuration mechanism source UID's are
useless IMHO. You'd have to blow the UID(s) into the PIC which maybe
OK for me but anyone picking up the code, maybe only a .hex file,
would have to change it for their source device(s) of interest and it
would make preprogrammed devices a nightmare. It would be better for
smaller devices that they always responded to a particular UID
(effectively a globally defined xAP broadcast UID) and there was an
optional configuration message to define further (maybe 4) UID's of
interest.

I'm specifically trying to make it as generic as possible, so as far
as I can it will follow the current xAP specs. If that isn't possible
then maybe some extensions/revisions are required (for example the
keyword tokenisation standardised, the crc in binary rather than
ASCII, broadcast UID, etc).

Lehane