[OpenTRV-dev] XAP

[Stuart Poulton]

Having been involved in the orignional conception of xAP, the intention 
has always been that it could be implemented on uC's.

I'm now starting to also look at LLAP from Ciseco, primarily as I'm 
looking at XRF / SRF modules. More info on LLAP can be found here

http://openmicros.org/index.php/articles/85-llap-lightweight-local-automation-protocol

Stuart

On 04/04/13 09:42, Kevin Wood wrote:
> Yes, even linking in string manipulation libraries takes a substantial
> chunk of memory on an AVR. Processing strings is also obviously much more
> CPU intensive than exchanging small binary packets, and that impacts
> battery life.
>
> Interworking with devices supporting these protocols is a good aim, but
> are we planning for this this to be maintained right down to the TRV
> itself or  to have a gateway device that provides a bridge between an
> efficient binary wireless protocol at the TRV and open protocols over
> other interfaces to the outside world? A gateway could, of course,
> implemented on a more capable platform, or, at least, on a microcontroller
> that has less tight power, memory and cost constraints than a TRV node.
>
> Kevin
>
>> Except that anything beyond a simple binary format will likely tax a uC
>> beyond endurance, especially for parsing.
>>
>> A trivial CLI on the PICAXE that I'm working on right now has taken 25% of
>> my available code space and makes MS-DOS 1.x look a little over-friendly!
>>
>> Rgds
>>
>> Damon
>>
>> On 3 Apr 2013, at 14:39, Bruno Girin wrote:
>>
>>> MQTT doesn't specify a message format so you could very well use the XAP
>>> message format over MQTT.
>>>
>>> Which reminds me, I need to add the PoC code I came up with to the
>>> source tree.
>>>
>>> Bruno
>>>
>>> On Tue, 2 Apr, 2013 at 4:26 PM, Thomas Hood <EMAIL ADDRESS HIDDEN> wrote:
>>>> On Tue, Apr 2, 2013 at 5:16 PM, Mike Stirling <EMAIL ADDRESS HIDDEN>
>>>> wrote:
>>>>
>>>>   I never really understand the logic behind projects that say they are
>>>>   targetting low-end embedded and then go on to develop a protocol in
>>>>   human-readable ASCII, or worse, XML!
>>>>
>>>>
>>>> At
>>>> http://www.xapautomation.org/index.php?title=Protocol_definition
>>>>   I
>>>> found some explanation for this. I quote with a little editing for
>>>> readability:
>>>>
>>>> Each name-value pair within the message block is defined by a keyword,
>>>> a delimiter, a value and a terminator. [...] The delimiter determines
>>>> the method of value encoding.
>>>>
>>>> '=' (equals sign, ASCII character 61 decimal) indicates that a value
>>>> is encoded as an ASCII string. This is the preferred encoding format.
>>>>
>>>> '!' (pling, ASCII character 33 decimal) determines that a value is
>>>> encoded as an ASCII hex representation. This allows the broadcast of
>>>> raw binary data. Whilst unavoidable under certain circumstances, its
>>>> use is discouraged because of the issues with portability (numeric
>>>> representations differ across processor types).
>>>>
>>>>
>>>> --
>>>>
>>>> Thomas
>>>> _______________________________________________
>>>> OpenTRV-dev mailing list
>>>> EMAIL ADDRESS HIDDEN
>>>>
>>>> http://lists.opentrv.org.uk/listinfo/opentrv-dev
>>> _______________________________________________
>>> OpenTRV-dev mailing list
>>> EMAIL ADDRESS HIDDEN
>>> http://lists.opentrv.org.uk/listinfo/opentrv-dev
>> _______________________________________________
>> OpenTRV-dev mailing list
>> EMAIL ADDRESS HIDDEN
>> http://lists.opentrv.org.uk/listinfo/opentrv-dev
>>
>
> _______________________________________________
> OpenTRV-dev mailing list
> EMAIL ADDRESS HIDDEN
> http://lists.opentrv.org.uk/listinfo/opentrv-dev