This project builds a scripting language for W1209 thermostats. The scripting language is Forth based, but that doesn't mean that you need to know much Forth to get something done (the goal is that you don't need to know it's Forth).

To do achieve this, I'm experimenting with a simple "processing" pattern: chained steps.

\ background task with temperature control
: task ( -- )
  measure            \ measure temperature
  control            \ temperature control
  logger             \ data logging
  menu               \ menu and display code
;

The trick is that, like in jQuery, one can chain "filters" if the data type of "output" matches the "input". In the case of a thermostat that's easy: it's all about temperature.

The other part is that chainable filters are self-contained units. To do this I use basic modular programming techniques, and a chained init function:

\ chained init - starting point
: init ( -- )
;
#include measure.fs
#include control.fs
#include logger.fs
#include menu.fs

In a module, e.g. measure, the initialization looks like this:

\ chained init
: init ( -- ) init
  \ init LPF state with max. value
  dig2temp2 DUP @ 1- 2* 1+ + @ LPFDIG !
;

The word init first calls the init word of the previous module, and the complicated part, e.g. filter initialization, is nicely hidden.

The next thing is the file include hierarchy, a design feature of e4thcom. The file search path is: "cwd:cwd/mcu:cwd/target:cwd/lib" (cwd = current working directory). The standard filter words for an application are in the target folder. In an application, library words can be transparently replaced with a modified version without the need to change the library.