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

[Kevin Hawkins <lists@xxxxxxxxxxxxxxxxx>]

g8kmh wrote:

>I'm currently in the design stage of my xAP switch assembly. This
>would allow 4-8 switches(inputs) to provide either on/off, toggle or
>press/hold level. This would allow a wide range of applications, not
>least as a humble lightswitch! As an aside, it will be interesting to
>see what sort of ramp period and update frequency is required to
>allow the message with the level to be sent, mapped, passed across to
>the DMX controller and the light level changed - allowing the user to
>release at the desired level.
>
>
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.

>What I'd prefer not to have to do is define, in advance, which port
>input is which switch type. With non-PC applications this is going to
>come up again and again so what suggestions are there for a generic
>implementation?
>
>
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.

>Finally, as this is going to be a serial connected device (4 wire
>RS485) I've noted the xAP serial specification. Has anyone actually
>implemented it fully in a PIC? Clearly with limited RAM there are
>some restrictions on both tx and rx buffers and the need for the CRC-
>16. 'On the fly' parsing/message creation looks the only option.
>
>
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)

>As to the bridge, I'm going to be using a 4 port card at 38.4kbps so
>the general idea is that traffic is broadcast on all ports. The
>downside is that the device sending will see the sent message but
>this is inevitable since the bridge and the device cannot/shouldn't
>care what sort of devices are attached. Traffic buffering will be
>needed as well to mux all the messages. Potentially there may be a
>need to discard older messages if the ethernet side is flooding the
>serial network.
>
>Any comments?
>
>
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 .

Kevin

>Lehane
>
>
>
>