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

["Ian" <ian.bird@xxxxxxxxx>]

Hi

As Kevin mentioned I did some work on a serial/485 device. I started off on
a very small PIC but then found I had to increase the processor size
because
of both available RAM as well as program space. I also changed from
assembler to C for simplicity.

In the end I arrived with the Atmel range of products. Initially I went for
the Mega 16 device which has 16k of program space. I then moved onto the
Mega32 which is double the size and also has more RAM and EEPROM. It was
the
same footprint and almost the same price.

I built a device which had 16 inputs multiplexed onto 9 physical ports. It
also had 8 outputs which could control things like small relays through
some
transistors.

It had a wealth of configurability particularly on the inputs. Things like
sending a message on the rising edge, falling edge or both etc.

If any of this is any help I am happy to share it.

I did not implement CRC but if I had I would have used a lookup table for
speed. As with so many projects I never quite finished this one but it did
get to a fully working prototype stage. My needs then changes and I went
off
on the embedded Ethernet trail.

Ask away with any questions

Have fun

Ian



-----Original Message-----
From: xAP_developer@xxxxxxx
[mailto:xAP_developer@xxxxxxx]On
Behalf Of Kevin Hawkins
Sent: 20 July 2005 01:12
To: xAP_developer@xxxxxxx
Subject: Re: [xAP_developer] xAP Configuration, Serial RS485 Bridge and
PIC's


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
>
>
>
>