
I'm working with Atom to program an ATtiny25. I am curious about how consistent the timings actually are. Consider John Van Enk' example of blinking a LED on an Arduino: http://code.sw17ch.com/blog/atom/blink_atom.c We see that sometimes `setLED' is executed and sometimes not. When `__clock' is incremented, it will be incremented sometimes sooner, sometimes later. Also, I am a little puzzled by the `__coverage` variable. What does it do? As for my project/motivation -- I'm just trying to blink a little LED on much less robust/rich kit -- the Trippy RGB Waves kit from Lady Ada. I am (gratuitously) exploring ways to program it with Haskell. -- Jason Dusek

On Fri, Jan 1, 2010 at 4:43 AM, Jason Dusek
I'm working with Atom to program an ATtiny25. I am curious about how consistent the timings actually are.
The function returned by Atom is intended to be called periodically, preferably using some hardware timer, like this: while (1) { waitForNextSample(); atomGeneratedFunction(); } This provides consistent cycle-to-cycle timing. However, the events that occur within the Atom function will most likely vary in time from call to call, due to rules being scheduled at different periods.
Also, I am a little puzzled by the `__coverage` variable. What does it do?
__coverage keeps track of which rules have fired during the execution of a program to provide some measure of code coverage. The compiler returns RuleCoverage[1], which is a list of rule names with associated indices bit positions to the __coverage array. Inside an Atom program, you can access this array with nextCoverage[2], which provides the current index and value of __coverage[index]. Repeated calls to nextCoverage would loop through the __coverage array. This feature was added before Atom had support for arrays, so it should probably be rewritten as some point in the future. [1] type RuleCoverage = [(Name, Int, Int)] [2] nextCoverage :: Atom (E Word32, E Word32)
As for my project/motivation -- I'm just trying to blink a little LED on much less robust/rich kit -- the Trippy RGB Waves kit from Lady Ada. I am (gratuitously) exploring ways to program it with Haskell.
-- Jason Dusek _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

2010/1/1 Tom Hawkins
...the events that occur within the Atom function will most likely vary in time from call to call, due to rules being scheduled at different periods.
So the purpose of the "period" is really not so much to set a consistent execution time as it is to ensure non-interleaved execution for safe multi-threading? -- Jason Dusek

Wait, no -- I missed something. As long as the outermost Atom routine is run every `n' µs by a hardware clock, the counter (`__global_clock') will contain an accurate count of how many `n' µs intervals have passed in our application. -- Jason Dusek

Yes, exactly.
On Fri, Jan 1, 2010 at 3:02 PM, Jason Dusek
Wait, no -- I missed something. As long as the outermost Atom routine is run every `n' µs by a hardware clock, the counter (`__global_clock') will contain an accurate count of how many `n' µs intervals have passed in our application.
-- Jason Dusek _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Hi Jason,
Regarding timing, the version of blink_atom.c below does not contain this,
but my later versions used the hardware timers to control the blink rate.
One can setup the interrupt vector for a hardware timer to call your
outermost atom function at whatever resolution you want. As long as the
timer allows enough time between expirations for any of the task groups to
finish, it will run in hard real time.
Hope this helps.
John Van Enk
On Thu, Dec 31, 2009 at 10:43 PM, Jason Dusek
I'm working with Atom to program an ATtiny25. I am curious about how consistent the timings actually are.
Consider John Van Enk' example of blinking a LED on an Arduino:
http://code.sw17ch.com/blog/atom/blink_atom.c
We see that sometimes `setLED' is executed and sometimes not. When `__clock' is incremented, it will be incremented sometimes sooner, sometimes later.
Also, I am a little puzzled by the `__coverage` variable. What does it do?
As for my project/motivation -- I'm just trying to blink a little LED on much less robust/rich kit -- the Trippy RGB Waves kit from Lady Ada. I am (gratuitously) exploring ways to program it with Haskell.
-- Jason Dusek _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

I remembered that I have some of this stuff on github. Here's the example C
file that sets up the timers on an Ardunio board.
http://github.com/sw17ch/atom-arduino-experiments/blob/master/Blink/blink.c
Notice that the main function does nothing. All the work is done by
blink_atom() which is called out of the ISR (Interrupt Service Routine).
On Fri, Jan 1, 2010 at 10:48 AM, John Van Enk
Hi Jason,
Regarding timing, the version of blink_atom.c below does not contain this, but my later versions used the hardware timers to control the blink rate.
One can setup the interrupt vector for a hardware timer to call your outermost atom function at whatever resolution you want. As long as the timer allows enough time between expirations for any of the task groups to finish, it will run in hard real time.
Hope this helps.
John Van Enk
On Thu, Dec 31, 2009 at 10:43 PM, Jason Dusek
wrote: I'm working with Atom to program an ATtiny25. I am curious about how consistent the timings actually are.
Consider John Van Enk' example of blinking a LED on an Arduino:
http://code.sw17ch.com/blog/atom/blink_atom.c
We see that sometimes `setLED' is executed and sometimes not. When `__clock' is incremented, it will be incremented sometimes sooner, sometimes later.
Also, I am a little puzzled by the `__coverage` variable. What does it do?
As for my project/motivation -- I'm just trying to blink a little LED on much less robust/rich kit -- the Trippy RGB Waves kit from Lady Ada. I am (gratuitously) exploring ways to program it with Haskell.
-- Jason Dusek _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

2010/1/1 John Van Enk
I remembered that I have some of this stuff on github. Here's the example C file that sets up the timers on an Ardunio board.
http://github.com/sw17ch/atom-arduino-experiments/blob/master/Blink/blink.c
Notice that the main function does nothing. All the work is done by blink_atom() which is called out of the ISR (Interrupt Service Routine).
Thanks for the example. -- Jason Dusek
participants (3)
-
Jason Dusek
-
John Van Enk
-
Tom Hawkins