Re: guile-controlled house

[Steve Tell <tell@telltronics.org>]

On Tue, 2 Apr 2002, Thien-Thi Nguyen wrote:

>    From: Steve Tell <tell@telltronics.org>
>    Date: Tue, 19 Mar 2002 02:03:51 -0500 (EST)
> 
>    Anyone else interested in (or already using) guile for home
>    automation?
> 
>    Announcing "guilfred," guile's answer to Alfred the butler.  [...]
> 
> are these devices "real-time" in any sense?

Many device nodes have low-leveldealings with external hardware with
real-time constraints, such as the Dallas one-wire interface and
other serial protocols.  That's all handled in embedded 8051
assembly-language firmware.

I suppose the whole system of guile code, C support, and connected
device nodes could be considered soft real-time:

- events relates to the wall clock; if a cron entry says to call a
procedure at 17:05, it isn't the end of the world if it gets called at
17:05:01, but it is wrong if it happens at 17:06.  

- several user-interface inputs must trigger their guile procedures and
the results of those take effect soon enough that it appears
"instantaneous" to the user.  I've got a node called "keyled" which has 8
pushbuttons, each with an integral LED.  When the user pushes the button,
the embedded micro debounces the button, and stores the keycode in a
buffer.  Guilfred is continually polling all such keypad nodes, asking if
they have any buffered keycode.  When keycodes are found, the procedure
bound to that keycode is called.  Typicaly, at least two messages end up
being dispatched: one to turn on the LED in the button, and another to
turn on the associated lamp or other device.  I generally can't see any
noticable lag, but if I did, I'd set about redesigning and recoding so I
didn't.  But if one time in a hundred it took 250 milliseconds instead of
50, that would probably be OK.

But so far I'm not taking any particular measures to keep things
real-time.  I've been running guilfred as a user process on a linux box,
not even rtlinux nor even scheduling priority for the process.  
The same Pentium 166 cpu does other things too, serving web pages and
playing MP3 files.

When I started this a couple of years ago, I was worried about overhead of
using any scripting language, but subjectively guile has performed
admirably.  I have constrained it a bit: the C core is in charge and owns
the select loop.  It calls guile procedures or hooks on timer events and
external-input events.  Guile code isn't allowed to do anything that could
possibly block (although I'm not enforcing that by hiding "dangerous"
libguile procedures yet).


I've put some pictures some of the user interface devices at
http://www.telltronics.org/software/guilfred/hw-pictures/
Photos of nodes controlling some lights and the in-floor radiant heat will
have to wait until next time I climb into the attic.

Steve







--
Steve Tell  tell@telltronics.org 


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user