On Sun, Feb 14, 2010 at 1:30 AM, Yves Parès
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