AVR-Chat

Your point is well taken.  In my test-platform on a Basic-x BX-24 I 
have minimized the amount of processing done in the Interrupt 
handler itself.  There are three interrupt-type of processes.

As I said, one increments a counter.

Another is fairly low frequency (on a timer tick interrupt)and sets 
a flag for screen updates.  Because that screen may be in use for 
other user input, the one user screen is serviced by the same main 
polled loop.

Unfortunately, it is not quite so simple.  There is another screen 
(LCD display) that does need to be updated every second.  It ONLY 
gets info from this 1Hz interrupt, so I do not need to worry about 
crashing into other task's screen updates.  If I had to deal with 
that issue, I would have the interrupt routine read the current 
cursor position and return it when it was done.  My display can not 
read the cursor position.

The third routine is relatively rare, and has fairly minimal 
calculations.

I _would_ disable interrupts while I read data that might get 
updated by an interrupt routine, but on a BX-24 (another reason to 
upgrade) the interrupts are not maskable as far as I can tell.  You 
can "LockTask", but interrupts have priority.  So, I read the 
frequently changed data "quickly" and hope it is not changed in the 
middle.  I could read it repetetively until the reading is the 
same.  I have not noticed this being a problem on the BX-24, but it 
is possible.  I will try it out.

=Tony

--- In AVR-Chat@yahoogroups.com, David Kelly <dkelly@h...> wrote:
> 
> On Apr 9, 2005, at 1:29 PM, arhodes19044 wrote:
> 
> > Really, my application is fairly linear.  About every second a
> > display needs updating with a few calculations.  Data entry 
happens
> > on another display/keypad.  Whenever certain external hardware
> > triggers (about 1Hz to 130hz), a counter is incremented, or(less
> > freqently) a few integer and float calculations are done based on
> > that counter and some vars are updated for display.
> 
> I suggest that you capture data in an IRQ service routine but 
postpone 
> any calculations until outside of user time. Especially don't try 
to 
> update the display. The display won't update that quickly, also 
you 
> will create a problem of knowing when your foreground process is 
> allowed to write to the display so as not to be clobbered by 
writes 
> from IRQ. Always do it in the foreground and not have any problems.
> 
> Sharing data between IRQ time and foreground time causes an issue. 
A 16 
> bit value may change if an IRQ occurs half way thru reading its 
hi/lo 
> bytes. Simplest solution is to disable IRQ, copy the values, 
enable 
> IRQ.
> 
> --
> David Kelly N4HHE, dkelly@H...
> 
=====================================================================
===
> Whom computers would destroy, they must first drive mad.