DPRG List  

[DPRG] Return of the AVR Mega-Geek

Subject: [DPRG] Return of the AVR Mega-Geek
From: Dick Swan dickswan at sbcglobal.net
Date: Thu Feb 18 23:37:10 CST 2010

> Jon Hylands wrote

> <<snip>>

> In the main loop, which gets run very often (assuming you don't slow

> it down much), you do this:


> heartbeat.update ();


What's a main loop? J. Just kidding.


Many applications work just fine with the "main loop" architecture where
essentially you have a loop that is continuously executed. And then within
this loop you make a series of function calls that must take a very small
time slice and then return.

.         Line following is a great example very amenable to the main loop
approach. Every cycle through the main loop you read the various values of
the line sensors and use them to appropriate adjust the settings of the
motor power levels.

.         Remote joystick control of a robot is another good fit.


But there are also many applications which don't fit "main loop" well. One
that really stands out is many of the autonomous robot competitions where
you want to perform as many different tasks as possible during a fixed time
duration. Typical pseudo code for this might be:

.         Drive straight for two feet

.         Turn right 90 degrees.

.         Grab balls from storage rack

.         Turn left 180 degrees.

.         Drive straight for four feet

.         Drop balls into scoring container

.         And so on for the next task/activity.

It's most natural to program this as a linear sequence of function calls.
You could also fit this into a "main loop" architecture but then you need to
have variables for managing the state (and various sub states) of each
activity and you have to program the activities so that instead of a single
function call they need to be designed to be repetitively called until they
return a "activity finished" return code whereupon you move to the next


The various programming environments for both the LEGO (i.e. ARM) and VEX
(i.e. Microchip 8-bit PIC) robots provide a basic "Operating System like"
environment that fully utilizes interrupt based handlers for all motors and
sensors so that they operate transparently in the background (or on
interrupt level) transparent to the end user program. What I haven't found
for the Arduino is a similar environment.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://list.dprg.org/pipermail/dprglist/attachments/20100218/8850e4ca/attachment.html

More information about the DPRG mailing list