[Date Prev][Date
Next][Thread Prev][Thread Next][Date
Index][Thread Index]
Re: Your Opinions please
- To: ukha_d@xxxxxxx
- Subject: Re: Your Opinions please
- From: "mark_harrison_uk2" <mph@xxxxxxx>
- Date: Tue, 02 Sep 2003 08:49:40 -0000
- Mailing-list: list ukha_d@xxxxxxx; contact
ukha_d-owner@xxxxxxx
- Reply-to: ukha_d@xxxxxxx
John,
If you are going to comment on XPL, then please do so. This is a very
appropriate forum.
I would summarise the key difference between the two in that xAP is
gaining wide support from commercial developers, wheras XPL is
squarely aimed at the hobbyist market.
However, I would be grateful if you could NOT present mis-information
about xAP.
1: There are several developers developing xAP applications for PIC
processors (about the lowest powered out there) without problem.
In the PIC world, it does appear to be possible to write XPL code
using PIC-basic. xAP code for PICs realistically requires assembler.
(If anyone wants to prove me wrong and write xAP code using PIC-
basic, please feel free :-) ).
There are at least 6 hardware devices in the manufacturing pipeline
that use PICs that I know of. The commercial world tends to use
assembly code for these devices anyway.
2: xAP does support targetted messages. The TARGET command was
originally introduced in xAP 1.2, which is the version that both Ian
Lowe and Tony Tofts were most heavily involved with. Now, Ian and
Tony both have some concerns about the way 1.2 went, but to claim
that targetting isn't properly supported in xAP is simply bogus.
Regards,
Mark
--- In ukha_d@xxxxxxx, "John B" <home-automation@j...>
wrote:
> Hi Dave,
>
> > Excuse me for being a bit cynical, but 160 bytes just to switch
on a light
> > is a bit heavy going. Having not really looked at xAP in too much
detail,
> > mainly because I am working on my own CAN bus based system, I
find it hard
> > to believe it takes so many bytes. With my protocol I use a
single 29 bit
> > identifier for the sender, receiver and ID with 2 bytes in the
message to
> > indicate what to do with the output. Same for the reply.
>
> This is one of the main reasons why the xPL protocol was created.
xPL offers similar functionality to XAP (and a few things that XAP
doesn't support fully, such as targetted messages) and does so using
a much smaller message footprint.
>
> In your example of turning on an X10 device, an xPL message to do
this would require roughly 86 bytes.
> Whilst this is still far from being the most efficient protocol in
the world, it is approximately half the size of it's XAP counterpart.
>
> > My main reason for asking is how you accommodate such a large
telegram with
> > small microcontrollers? Some of the devices I use only have 2K
bytes of
> > programme space. Maybe Ian Bird could enlighten me to how he has
been
> > getting on with this?
>
> Ian Lowe has been doing some embedded xPL development, and many of
the features of the xPL spec were specifically aimed at making it
easier to write xPL-enabled embedded software.
>
> For example, if your device is only interested in command messages
(and is therefore not interested in status or trigger messages) it
only needs to read the first 5 bytes of the xPL message to determine
whether to discard it or continue processing it.
>
> In contrast, each XAP message begins with "xap-header",
which
doesn't tell you anything about the message, and IMO is a waste of 10
bytes which could have been put to a better use.
>
> > Maybe I should look at it again and see if I can come up with a
xAP to CAN
> > bus gateway as this would allow me to use some of the excellent
hardware you
> > guys have been building/creating. In fact I tried to find the xAP
website on
> > sourceforge just now but it was not there... Has this been moved
elsewhere?
>
> If you are interested in seeing what xPL has to offer, check out
the official project site at http://www.xplproject.org.uk/
> There is also the UKHA_XPL discussion group on Yahoo.
>
> Both XAP and xPL are excellent initiatives which have the potential
to vastly improve integration in the home automation world, and both
protocols have their strengths and weaknesses.
> The best advice is to look at both protocols and decide for
yourself which one best fits your needs.
>
> Regards,
>
> John
Home |
Main Index |
Thread Index
|