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: [Project] Kbd/LCD device


  • To: ukha_d@xxxxxxx
  • Subject: RE: Re: [Project] Kbd/LCD device
  • From: Ant Skelton <ant@xxxxxxx>
  • Date: Sun, 03 Jun 2001 15:05:17 +0100
  • Delivered-to: rich@xxxxxxx
  • Delivered-to: mailing list ukha_d@xxxxxxx
  • Mailing-list: list ukha_d@xxxxxxx; contact ukha_d-owner@xxxxxxx
  • References: <9fd2ba+l254@xxxxxxx>
  • Reply-to: ukha_d@xxxxxxx



Dr John Tankard wrote (albeit in an entirely different thread)
>
> Actualy I think the LCD is actualy more difficult because we dont
> know hat it will need to do, its actualy quite difficult to think of
> what it should do and it limits all the other devices that will
> follow.

Apologies in advance if I've got this all wrong or misused this [square
bracket] convention - I tend to skim read.

As I understood it, the LCD module comprises an LCD panel, some form of
user input, one of these rabbit jobbers running IP and an ethernet
connection to the house, in a 1 or 2 gang UK wall socket sized housing?

If that is the case, I'd envisioned the LCD module as nothing more than
a relatively dumb control surface - all it does is display information
and capture user input, communicating with a host on the network which
does all the legwork. Sort of like a severely limited X terminal or VNC
terminal.

I'm not suggesting we port X to it, but some of the same ideas could be
used, principally that of separating the user interface (LCD module)
from the application (remote host), and using device capabilities to
allow the use of LCD modules with different LCDs (eg text only, graphics
of varying resolutions and depths) and input devices (number of keys,
rockers, rollers, rotaries, touch digitizers et al).

The interaction between the LCD module and the central host would then
consist solely of 1) new UI 'frames' being sent from the central host to
the LCD module for display, and 2) new user-input being sent from the
LCD module to the central host, and pretty much nothing else bar the odd
control/status message.

A 'frame' in this context represents a set of text strings or a set of
bitmaps (depending on the LCD capabilities) which is sent the to the LCD
module and displayed. A 'frame' could represent the entire viewable area
of the LCD, or just a portion of it which needs to be updated: for
example, if the LCD is displaying a user interface frame which has a
clock on it, then only the region containing the clock needs to be
updated periodically, if the system is otherwise idle.

Since these concepts are already in use providing perfectly useable UIs
on things like X and VNC, if the protocol is carefully designed we can
reasonably expect them to be scaleable from LCD modules with 2x16 text
displays and 2 keys right up to 1280x1024x32bit displays with full
keyboard input: anybody fancy having a crack at one of those
aperture-view virtual monitors? ;)

Frames could be generated on the central host from whatever markup
language is currently flavour of the month, and rendered according to
the display/input capabilities of the intended recipient, which the
central host has previously received.

It would also be reasonably easy to then write a 'virtual LCD module' as
an app running on a PC, which would be useful for testing and
diagnostics use, and which would allow people to concentrate on the
UI/markup/rendering layers independantly of the physical hardware and
lower layer network software. I understand there are some strange people
out there who don't enjoy inhaling solder fumes and burning their
fingers and conversely, XML gives me the willies ;) Since much of the
discussion so far has centered around the user interface, virtual LCD
modules and the host end software would probably be the best first step:
it's zero-cost (yes, I know, other than the time involved) and would
allow us to thrash out what works and what doesn't for the UI before
commiting to hardware.

I imagine a typical conversation then to look like this:

LCD: hello! I'm an LCD module! my MAC address is aa:bb:cc:dd:ee:ff - I
need a home!
Host: hello aa:bb:cc:dd:ee:ff, your IP address is 10.1.1.1/16, you can
reach me on 10.1.1.254
LCD: thanks mate. My display capabilities are 2x16 text chars, single
colour. oh, and I have a buzzer
LCD: My input capabilities are two little buttons
LCD: Im not very clever, so don't use any kind of compression for my
frames
Host: roger that 10.1.1.1, I have a graphics context that matches your
capabilities
Host: I've rendered a screen for you - here's your first page to display
LCD: thanks
<time passes>
LCD: wild! somebody pressed button1!!
Host: ok, update line 1 characters 2 to 10 with this string
LCD: righto

etc etc

Additionally, should it ever prove necessary to develop a 'smarter' LCD
module for people who don't want to run a central host, then an
extremely dumb version of the central host software could be ported to
the embedded device and run as a separate app - the LCD still talks to
the network, it's just that the remote process it's talking to lives on
the same device. This embedded controller would discard the fancy markup
based approach for something much more primitive, and would only know
how to render for one target: the type of LCD module it's actually in.

Is that the sort of thing we're after doing here?

cheers

ant
--
/\/\
ant@xxxxxxx                   (`')                  www.ant.org
()
Megawatt Winged Avenger



Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/




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.