DPRG List  

DPRG: Strategy

Subject: DPRG: Strategy
From: Kipton Moravec kmoravec at airmail.net
Date: Thu Jul 31 14:15:35 CDT 1997

Clay Timmons wrote:
> ---snip---
> > The 8051 has an external pin for one of the counters, which you could
> > hook up directly, without a counter chip.  Then it would generate an
> > interrupt when the internal 16-bit counter rolls over.  Does the HC11
> > have the same?
> Yes the HC11 has a similar pin called the pulse accumulator, see chapter
> 11 of the reference manual (pink book).  It has two modes of operation
> and can generate interrupts.  It is only 8 bit but the book explains
> how to extend this to 16 bits.
The nice difference on the 8051FX is that there is a second pin for
direction. So when hooked to an encoder, it counts up or down depending
on the direction the encoder is going.

BTW I went to the Motorola Literature center yesterday, and finally
picked up some books on the HC11, so I know what you MC11 fans are
talking about. Of course, unlike Intel and Phillips there is a separate
book for each type of HC11. And there were also multiple books on HC08
and HC05. (I did not bother with these.)  While I was there I picked up
some more data books on their other discrete devices. Ended up with a
box overflowing with books.  This morning, I got a discription of a
project, I am being asked to bid.  Of course it requires the MPC680
PowerQUICC and the LonWorks devices. So I was back today, picking up
another half-dozen books.

> ---snip---
> > > Another strategy I have imagined is using the RTI to
> > > cycle through my subroutines and poll the count on every RTI. This way I
> > > wouldn't have to worry about counter overflows, and so I could forego the
> > > binary counter scheme. Comments?
> > >
> > I do not know the HC11 so I am not familiar with the term RTI. So I can
> > not comment.
> RTI is return from interrrupt.
> Putting all your code in the interrupt handler might work. Generally
> you try and keep interrupt handlers as short as possible.  If your
> code is lengthy you must make sure that you will not get another
> interrupt before your handler has completed.
> -Clay Timmons   ctimmons at asic.sc.ti.com

No, it is not a good idea to put all of your code in an interrupt
handler. As Clay said, you want to keep your interrupts as short as
possible. Interrupts are also harder to debug.

It is better to keep the main part of your program in a loop, or go to a
wait (or sleep) command which wakes up when returning from an interrupt.
The interrupt should perform the minimum number of instructions, then
set a variable, which the main program checks, and performs the
necessary longer tasks.

A typical interrupt is a timer counter. The interrupt fires, a counter
is incremented, return from interrupt.  Or an interrupt fires, the
serial port read, the value put in a buffer, and a flag set that says
the buffer is not empty, and buffer count incremented. These are very
simple routines.  Usually less than 10 instructions.  You are a lot
safer that way.  

I am currently writing a psudo multi-tasking (I guess technically it is
multi-programming) routine for a project I am bidding on.  I have used
it successfully on four different projects.  In C it is only about 50
lines of code, and it is almost like and in many cases better than, real
multi-tasking, because you do not have as much overhead, and it is
simple! Maybe in the next couple of weeks, I will write it up for
everyone here.  I plan to use the technique in my robot.  It simplifies
the software control. 



More information about the DPRG mailing list