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