The UK Home Automation Archive

Archive Home
Group Home
Search Archive


Advanced Search

The UKHA-ARCHIVE IS CEASING OPERATIONS 31 DEC 2024


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Re: xAP and embedded devices


  • To: "Ukha_d" <ukha_d@xxxxxxx>
  • Subject: RE: Re: xAP and embedded devices
  • From: "Ian B" <Ian@xxxxxxx>
  • Date: Thu, 15 Aug 2002 19:00:27 +0100
  • Mailing-list: list ukha_d@xxxxxxx; contact ukha_d-owner@xxxxxxx
  • Reply-to: ukha_d@xxxxxxx

I would see my PIC devices as being on an RS485 network hanging off a serial
port somewhere, be it PC or other device. Something to translate between the
two with more power would be fine. It would be good if xAP was stripped at
this point and something like SNAP added for low power devices. You would
not be able to say much with say 100 bytes including tags, addresses,
commands, text etc.

If we went to a better generation of embedded chips then power would
increase but who has the time and money to develop the devices. I think we
should keep it do-able. After all this whole project is greatly reduced
without the embedded devices.

Thoughts anyone - particularly those with the knowledge to program the more
powerful chips. Out of interest, how much are these more powerful chips vs.
the better features e.g. TCPIP stack etc.

Ian



> -----Original Message-----
> From: Mark Harrison [mailto:Mark.Harrison@xxxxxxx]
> Sent: 15 August 2002 16:27
> To: ukha_d@xxxxxxx > Subject: RE: [ukha_d] Re: xAP and embedded devices
>
>
> This is fine if the PIC device is on the ethernet.
>
> However, if the PIC device is going to be on a dedicated
> serial device, then I'd suggest that the xAP over ethernet
> stays as is, but with a byte-encoder for the serial port.
>
> M.
>
> -----Original Message-----
> From: PatrickLidstone [mailto:patrickl@xxxxxxx]
> Sent: 15 August 2002 16:24
> To: ukha_d@xxxxxxx > Subject: [ukha_d] Re: xAP and embedded devices
>
>
> --- In ukha_d@y..., ian.bird@c... wrote:
> > Hi guys
> >
> > I am getting a little concerned that you are all going PC centric
> again and
> > forgetting the rather meagre abilities of embedded devices.
> >
> > It has taken me at least a year to get where I am with my IR
> project.
> > However, I was starting from scratch and the program is currently
> running at
> > 1400 code lines (not comments) of assembler. I think it is time to
> review
> > the target devices again. I don't have the time (or funds) to learn
> how to
> > program another PIC micro let alone another breed like Rabbit, AVR
> etc.
> > Ideally I will be using PIC 16F628 chips with 2k program and about
> 150 bytes
> > of spare RAM. Using SNAP a packet has about 7 bytes of overhead
> including 16
> > bit CRC which I don't have to store as I can process them as they
> come in.
> > The message data I do have to store and rapidly fills my available
> RAM. My
> > RS485 network works at 19200 and I think these displays run at 9600
> max so
> > some storage is essential. Please bear this in mind. The cost of
> this chip
> > is around 2 to 3 quid, one of its good points.
>
> So should we go back to the original version of the protocol, which
> requires less overhead to process, then? Sensible use of separators
> (say xAP.source=ABC) could provide equivalent hierarchy to the curly
> brace notation. Use of sensible abbreviations could also reduce
> storage requirements (e.g. xAP.src). I'd be reluctant to adopt an op-
> code dictionary (e.g. Message key represented by byte sequence
> <0x00><0x01> is xAP.source) because of the problems of maintaining
> the dictionary in the long term.
>
> Another feature which can help with on-the-fly processing is
> insisting on tag order. Whilst certain name-value pairs may not be
> mandatory, specifying an order may help with state driven parsing?
>
> Patrick
>
>


Yahoo! Groups Sponsor
ADVERTISEMENT

For more information: http://www.automatedhome.co.uk
Post message: ukha_d@xxxxxxx
Subscribe:  ukha_d-subscribe@xxxxxxx
Unsubscribe:  ukha_d-unsubscribe@xxxxxxx
List owner:  ukha_d-owner@xxxxxxx

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

Home | Main Index | Thread Index

Comments to the Webmaster are always welcomed, please use this contact form . Note that as this site is a mailing list archive, the Webmaster has no control over the contents of the messages. Comments about message content should be directed to the relevant mailing list.