[Haskell-cafe] Atom Examples

[Yves Parès]

Thanks!

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:
>> 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
> 
>  
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
> 
> 


-----
Yves Parès

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.