[Haskell-cafe] Atom Examples

[Tom Hawkins]

On Sun, Feb 14, 2010 at 1:30 AM, Yves Parès <limestrael at gmail.com> wrote:
>
> I've been interested in using Atom since I saw this:
> http://blog.sw17ch.com/wordpress/?p=84
> However those samples are very outdated, do you have newer ones?

Unfortunately, no.  I wish I had the time to write Atom examples and
tutorials, but I don't.

So in lieu of a tutorial, here's a few modules we use on our real
projects -- with limited documentation.

Arbiter.hs: A general purpose non-preemptive arbiter than implements
Lamport's bakery algorithm.  We use this to arbitrate multiple
software components that need to use the CAN protocol stacks for
sending multi-packet messages.  This is a good example that
illustrates some of the benefits of atomic state transitions rules.
What I find interesting is it works without any centralized arbiter
logic; notice there are no rule declarations in mkArbiter.

ECU.hs:  This is the hardware abstraction layer to our ECU.  Nothing
too interesting, but a good example of how to wire Atom up to external
C code.  Note the ECU record includes a bunch of expressions (E types)
and variables (V types).  The expressions form the inputs, like ADCs
and discrete inputs, and the mutable variables form the outputs, such
as PWMs and discrete outputs.  It also provides hooks to send and
receive CAN messages.

EVU.hs: The eVU is a little display mounted on the dash.  It presents
the driver with information such as charge pressure, mode settings,
and fault conditions.  The ECU talks to the eVU via the CAN bus.  This
is a good example because it illustrates a common object-oriented
pattern we tend to use all over the place:  the object contructor
(mkEVU) creates some state variables, defines rules for stuff to do,
and packages the state variables into an abstract type, or object
(EVU); then methods operate on this object.  In the case of EVU, the
object constructor defines variables for the things the eVU displays,
and it defines a rule to periodically send this information to the eVU
device via CAN.  And the methods set the various display elements such
as the active fault code (setCode), the accumulator pressure
(setCharge), and the active mode (setMode).

Sensors.hs:  Sensor processing, which takes data from the hardware
abstraction layer (ECU.hs).  One interesting feature is the oil
temperature sensor computation.  Based on a 1-D lookup table the
'lookup1D' function searches the table for the corresponding points
and performs interpolation.  In C, this probably would have been
written as a for-loop that would compute the lookup on every sample.
But because change in oil temperature is much slower than the sample
rate of the system, we only need to search one row of the table every
50 samples or so (i.e. with rules 'below', 'above', 'next', and
'found').  This effectively spreads out the computation over many
samples, thus lowering the processing latency of every sample.  Doing
this type of time-sharing in C would be tricky.  But in Atom, it's
trivial.  One of the many ways Atom benefits hard realtime
programming.

I hope this helps.

-Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: AtomExamples.tar.gz
Type: application/x-gzip
Size: 4542 bytes
Desc: not available
Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20100213/64c60b3b/AtomExamples.tar.gz