[Haskell-cafe] Atom Examples
limestrael at gmail.com
Sun Feb 14 04:29:38 EST 2010
Looks a bit complex to me at the moment, but I'll probably have a look at it
when I have the time.
Tom Hawkins-2 wrote:
> 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:
>> 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
> I hope this helps.
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
Live long and prosper
View this message in context: http://old.nabble.com/Atom-Examples-tp27580935p27581803.html
Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.
More information about the Haskell-Cafe