On Fri, Mar 16, 2012 at 11:54:15AM -0600, Dwayne Reid wrote:
> At 06:21 AM 3/16/2012, Byron Jeff wrote:
>=20
> >Your example of wanting to disable the interrupt so that the main=20
> >loop can finish is a perfect counterexample to why one is needed.=20
> >The main loop is the priority over the ADC. So the ADC should not be=20
> >in an interrupt.
>=20
> Exactly right!
>=20
> Most of my code is written such that things like timer events are=20
> handled by polling flags in either my foreground or background tasks=20
> (depends on the project).  I keep interrupts for critical things like=20
> serial comms, over-current shutdown, PWM, etc.

We are definitely in agreement. I'll normally run a tick timer if I need to
keep track of time and run through the main loop once per tick. I set the
tick speed fast enough that any non time critical tasks are updated with
sufficient responsiveness.


> By my definition: an interrupt should start and finish in not more=20
> than a dozen or two cycles.  If an interrupt takes hundreds or=20
> thousands of cycles, it probably shouldn't be an interrupt.

And again always with the objective that interrupts should be for priority
items only. Usually I start coding with interrupts turned off and code
until I identify something that needs updating faster than the main loop
can get to it. It goes into an interrupt. Usually it's only enough code to
handle the immediate pressing need. If further processing needs to be done,
save the data if incoming and set a flag so that it can be processed in the
main loop. The ADC is one item I actually do this for when I just need to
have a current value in the main loop. Run the ADC continuously and grab
the new value and store it in the interrupt so that the main loop can
always read the updated value without having to wait for it.

BAJ

>=20
> As always, there are exceptions. (*)
>=20
> dwayne
>=20
> (*) Just for giggles and laughs - I once did a project where=20
> EVERYTHING was done in the interrupt service routines.  The=20
> foreground task was a forever loop with nothing inside.  As a result,=20
> I could dispense with saving and restoring context in the ISR's,=20
> which made them REALLY quick.
>=20
> Did it just to see if I could.  And - Yeah - it worked=20
> perfectly.  But it WAS a simple project.
>=20
> dwayne
>=20
> --=20
> Dwayne Reid   <dwayner@planet.eon.net>
> Trinity Electronics Systems Ltd    Edmonton, AB, CANADA
> (780) 489-3199 voice          (780) 487-6397 fax
> www.trinity-electronics.com
> Custom Electronics Design and Manufacturing
>=20
> --=20
> http://www.piclist.com PIC/SX FAQ & list archive
> View/change your membership options at
> http://mailman.mit.edu/mailman/listinfo/piclist

--=20
Byron A. Jeff
Department Chair: IT/CS/CNET
College of Information and Mathematical Sciences
Clayton State University
http://cims.clayton.edu/bjeff
--=20
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
.