RE: Re: xAP and embedded devices

["Ian B" <Ian@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.