Re: Re: New to the list- intro

["Ake Hedman" <akhe@xxxxxxxxxxxxx>]

> Parsing the messages isn't hard - the limitation is on the RAM space
> needed to hold complex configurations on very-low-powered devices. As
> Patrick says, the reference PIC xAP code fits in 200 bytes of ROM.
> Such a device is unlikely to have the capacity to hold a table of
> "things I'm watching out for", and will probably just hold a
"this is
> my addres - command me" configuration in 8 bytes.
>

Mark,

Fist. The "BSC Mapper". What is it? Any pointers?

For a simple "message" it is not but for more complex ones its a
different
thing and can consuming lot of resources on a low end controller.  Mostly
its an issue of RAM resources just as you say. The control would hopefully
also do something else than just read/write messages and need as much RAM
as possible for that.

"Simple" is of course as relative term. But even by most relative
terms

xap-header
{
v=12
hop=1
uid=FF123400
class=xap-temp.notification
source=ACME.thermostat.lounge
}

temp.current
{
temp=25
units=C
}

is harder to parse and use more uP resources then it is to parse

0x01 0x19

to get the same result.


I agree that on a PC or higher end device this difference does not matter.
On a low end device it is a different matter.


The perfect protocol for a low-end device should (IMHO):

- Just receive the messages it is interested in. If other messages is
present on the bus it should work with its "controlling" job. CAN
solves
this with filters/masks. Filtering is done in hardware.

- Have bus-arbitration in hardware. No processor resources used for that.

- Have priority handling. A "turn on lamp" is lower priority than
a "fire
alarm".

- Have some intelligent detection of the health of its bus.

- Should have no need for a master controler.




Regards
/Ake

On Wed, 26 May 2004 10:30:26 -0000, mark_harrison_uk2
<mph@xxxxxxx> wrote:

> --- In ukha_d@xxxxxxx, "Ian Lowe" <ian@w...> wrote:
>
>> The distributed decision making you describe is very much xAP's
>> philosophy (unless the BCS Mapper is a move to centralised
decision
>> making - Mark?) whilst smaller, more tightly regulated messages is
>> ours...
>
>
>
> Absolutely not.
>
> BSC Mapper is a slightly odd product. On one level, it CAN be used as
> a central control engine, albeit only for assigning connections in the
> BSC schema.
>
> On the other hand, it can be regarded as a central CONFIGURATION
> engine, that will push out the configuration to the end-point devices,
> and only send the necessary translation "live" if it has to.
>
> Example - you configure C-Bus.light.blue to connect to
> Homevision.input.1 in BSC Mapper
>
> BSC Mapper then sends a xAP message that interrogates whether the
> C-Bus controller supports distributed intelligence.
>
> - If it does, then well and good. From that point onwards, the C-Bus
> controller will change the blue light whenever a "Homevision
input
> port's changed" message is detected.
>
> - If it doesn't, then no problem. From that point onwards, the BSC
> Mapper controller will send a "C-Bus - change the blue
light" xAP
> message whenever a "Homevision input port's changed" message
is
> deteceted.
>
> This makes it possible for developers to choose to support distributed
> intelligence when they want to, but still be fully capable of xAP
> control if they can't (albeit at the expense of NEEDING a central
> controller at that point.)
>
> Parsing the messages isn't hard - the limitation is on the RAM space
> needed to hold complex configurations on very-low-powered devices. As
> Patrick says, the reference PIC xAP code fits in 200 bytes of ROM.
> Such a device is unlikely to have the capacity to hold a table of
> "things I'm watching out for", and will probably just hold a
"this is
> my addres - command me" configuration in 8 bytes.
>
> Mark
>
>
>
>
>
>
>
> Yahoo! Groups Sponsor
> ADVERTISEMENT
>
> Yahoo! Groups Links
>
> To visit your group on the web, go to:
> http://groups.yahoo.com/group/ukha_d/
>
> To unsubscribe from this group, send an email to:
> ukha_d-unsubscribe@xxxxxxx
>
> Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.



--
---
Ake Hedman (YAP - Yet Another Programmer)
eurosource, Brattbergavägen 17, 820 50 LOS, Sweden
Phone: 46 657 413430 Cellular: 46 730 533146
Company home: http://www.eurosource.se     
Kryddor/Te/Kaffe:
http://www.brattberg.com
Personal homepage: http://www.eurosource.se/akhe