handling multiple interrupt sources?
Started by ●March 27, 2005
Reply by ●April 5, 20052005-04-05
Mike, I just checked the diagram. I'm still going over your articles.
Great work and thanks!
- Tom
--- In basicx@basi..., Mike Perks <basicx@a...> wrote:
> Tom and Tony,
>
> You guys must have seen an early draft of part 6 of my articles :)
[snip]
Reply by ●April 5, 20052005-04-05
Tony, here is a link to Philip's 74HC/HCT family User Guide:
http://www.standardics.philips.com/products/hc/
- Tom
--- In basicx@basi..., "arhodes19044" <spamiam@c...> wrote:
>
> I am glad about the compatibility because I could not get the
74HCT123
> from Jameco, but got instead the 74HC123. I looked pretty hard at
the
> datasheets and I could not really find the operational difference
> between the HC and HCT models. I am sure there is some basic family-
> wide difference.
[snip]
Reply by ●April 8, 20052005-04-08
I got the parts and assembled the circuit, or at least one side of
it.
It must have some noise or something (I do not have the schmitt
trigger inverter in place yet). At first I thought the IC's were
not decoupled, but decoupling caps do not fix it.
Occasionally, rarely, it will have multiple triggers, some lasting a
brief time, other lasting a long time.
I only have on half of the circuit done (i.e. using only one trigger
for the interrupt, and the other side's inputs on the ICs are not
grounded or anything.) Maybe there is cross-talk.
I will assemble the other side and see if it still triggers
spontaneously. I have already tried various pull-up/down resistors
at various inputs without much effect.
Maybe I need to install some capsresistors (low pass filters) on the
various inputs/outputs to filter out high frequency noise.
Anyway, the multiple triggers tell me that the normally 1Hz
housekeeping interrupt routine can do its work quite quickly, and
should not interfere with its sister interrupt which will get
triggered at 5Hz to 120Hz
I also found out that debugging printing in the interrupt task
increases its stack requirements a hell of a lot. Boy, did I walk
all over other variables when I started debugging!
-Tony --- In basicx@basi..., "Don Kinzer" <dkinzer@e...> wrote:
>
> --- In basicx@basi..., "arhodes19044" <spamiam@c...> wrote:
> > I need to latch the signal, then reset the latch, and I may well
> > need to be able to reset while the original signal is still high.
> > I do not want it to retrigger until the signal goes back to the
> > "off" condition. I do not want continued presence of the signal
> > to inhibit my ability to the signal latch.
>
> An edge-triggered J-K or D flip-flop meets all the requirements
stated
> above. The schematic to which I posted a link a day or so ago
shows
> how to wire a 74HCT109. Wiring a D-flop would be similar - just
tie
> the D input high. Unfortunately, most of the D-flops ('174, '175)
> have a common clear which wouldn't work in your application.
>
> Here's the schematic link. Just delete the one-shots on the left
and
> clock the flip-flops with your pulse signal.
>
> http://www.kinzers.com/don/BX24/pulseCapture.jpg
>
> Again, depending on the characteristics of your signal you may
want to
> condition it by running it through a Schmitt input device like the
> 74HCT14. If the leading edge of your pulse is negative-going you
> would want the inversion anyway since the '109 is positive edge
triggered.
>
> Don >
> >
> > Originally I had considered two feeding-back latches, but it was
not
> > that simple.....
> >
> > -Tony
> >
> >
> >
> >
> > --- In basicx@basi..., "Tom Becker" <gtbecker@r...>
wrote:
> > > > ... the different ways the 4093 can be used...
> > > [Dang it! Yahoo insists on including the punctuation, now
gone, in
> > the
> > > links; these should work.]
> > >
> > > One can also implement very flexible logic in one physical
part,
> > using a
> > > PAL, GAL, PEEL or similar Programmable Logic Device. Common
PLDs
> > are
> > > cheap and easy to program, both logically and electrically.
GALS
> > and
> > > PEELs can be reprogrammed, too, so your hardware logic can
change
> > just
> > > as easily as your firmware can.
> > >
> > > I started with a 20V8 (20 inputs, 8 outputs, more or less)
with a
> > simple
> > > home-built parallel-port programmer, GALBLAST,
> > > http://www.geocities.com/ResearchTriangle/Forum/8070/algo.htm
but
> > > quickly graduated to an inexpensive USB ZIF-socket programmer,
> > then a
> > > full-blown and sadly expensive universal device programmer
> > > http://www.needhams.com that should last me awhile. Industry-
> > standard
> > > JEDEC files describe the logic that the programmer burns;
JEDEC
> > files
> > > can be produced by a number of compilers; a free one is
WinCUPL.
> > > http://www.atmel.com/dyn/products/tools_card.asp?tool_id'59
> > >
> > > I have grown to love these things and now often think in terms
of
> > > programmable logic rather than 74- or 4000- series parts.
> > Anything that
> > > can be built using AND/OR/NOT can be built with PLDs. I
> > implemented a
> > > quadrature frontend, including multiple BX-24 interrupt
handling
> > and
> > > other logic, in one GAL that sits very neatly against the left
> > edge of
> > > the BX-24; I used another for motor control along the right
edge
> > (see
> > > photo "GALs for glue logic" in the group Photos). These two
> > components
> > > do the equivalent work of about 20 74HC DIPs.
> > >
> > >
> > > Tom
> > >
> > >
> > >
> > > Tom Becker
> > > --... ...--
> > > GTBecker@R... www.RighTime.com
> > > The RighTime Clock Company, Inc., Cape Coral, Florida USA
> > > +1239 540 5700
Reply by ●April 8, 20052005-04-08
Tony,
>
> I also found out that debugging printing in the interrupt task
> increases its stack requirements a hell of a lot. Boy, did I walk
> all over other variables when I started debugging!
>
It is best to keep the interrupt task as small as possible. Find out
what caused the interrupt, set some flags or variables and return. You
can also sleep for a while before returning (100ms) to avoid potential
duplicate interrupts.
bxDism (http://home.austin.rr.com/perks/basicx/bxDism/ ) will help you
determine the minimum stack size for all your tasks. Unfortunately
Debug.Print and most of the CStr() functions are implemented in what I
term "external functions" so they add to both your program size and
significantly to your stack size partly because of the subroutine call
overhead. See part 4 of my articles on the internals of the BasicX
platform to learn more (see link below). Mike
http://home.austin.rr.com/perks/basicx/Articles/
>
> I also found out that debugging printing in the interrupt task
> increases its stack requirements a hell of a lot. Boy, did I walk
> all over other variables when I started debugging!
>
It is best to keep the interrupt task as small as possible. Find out
what caused the interrupt, set some flags or variables and return. You
can also sleep for a while before returning (100ms) to avoid potential
duplicate interrupts.
bxDism (http://home.austin.rr.com/perks/basicx/bxDism/ ) will help you
determine the minimum stack size for all your tasks. Unfortunately
Debug.Print and most of the CStr() functions are implemented in what I
term "external functions" so they add to both your program size and
significantly to your stack size partly because of the subroutine call
overhead. See part 4 of my articles on the internals of the BasicX
platform to learn more (see link below). Mike
http://home.austin.rr.com/perks/basicx/Articles/
Reply by ●April 8, 20052005-04-08
Yes, believe me, when one of the interrupt tasks might get triggered
at 100hz, I am really conscious of getting in and out.
When the interrupt is triggered the first thing it does is check the
higher frequency source first. Fortunately that is a simple
increment of a counter. Unfortunately it is a long integer
counter. Int size could not handle the worst case scenario.
Unfortunately since 100+ Hz is a possible situation, I _can't_ sleep
or delay 100ms. I did set the reset pin and then do the increment,
then release the reset pin. That will hold it in the reset state
for a little while.
I also did insert a couple of ticks of a sleep for testing purposes
to see if this would clear the multiple trigger issue, and it did
not. I still get multiple triggers
The less frequent interrupt source is not one in which I can ONLY
set some flags, but I do that too. The 1hz interrupt requires some
variable storage in a circular buffer so I can do some averaging
over time.
I was going to do a small amount of text I/O in the interrupt
routine, but I can set a different flag and then have another task
simply sleep for a second then do the few characters of text I/O
that way.
I had not gotten to the point of considering another task for the
mandatory I/O, but this is not a problem! Actually, since precise
timing of the mandatory text I/O is not critical (just needs to be
about once a second), it does not really need to be interrupt
driven. I am just worried about memory constraints for the stack
for the I/O. I had looked at the BXDisasm, and used it on my program.
Unfortunately it was not immediately obvious where I was going to
see the stack space requirements. And dynamic usage of the stack
may well be different from the disasm predictions
So, I took the expedient of filling the task stack with a certain
value, then I would let it run a while and eventually trigger the
printing of the stack's values. Where I see that the stack still
has the original values, then it is a fairly safe bet that this is
the limit of stack space requirements. I would then reduce the
stack size to slightly more than this size.
Thanks about making me seriously consider another task for the
mandatory I/O! I will try it!!!
-Tony
--- In basicx@basi..., Mike Perks <basicx@a...> wrote:
> Tony,
>
> >
> > I also found out that debugging printing in the interrupt task
> > increases its stack requirements a hell of a lot. Boy, did I
walk
> > all over other variables when I started debugging!
> >
> It is best to keep the interrupt task as small as possible. Find
out
> what caused the interrupt, set some flags or variables and return.
You
> can also sleep for a while before returning (100ms) to avoid
potential
> duplicate interrupts.
>
> bxDism (http://home.austin.rr.com/perks/basicx/bxDism/ ) will help
you
> determine the minimum stack size for all your tasks. Unfortunately
> Debug.Print and most of the CStr() functions are implemented in
what I
> term "external functions" so they add to both your program size
and
> significantly to your stack size partly because of the subroutine
call
> overhead. See part 4 of my articles on the internals of the BasicX
> platform to learn more (see link below). > Mike
> http://home.austin.rr.com/perks/basicx/Articles/
Reply by ●April 8, 20052005-04-08
Tony, connect any unused Inputs to Ground or VCC depending on the
logic family.
- Tom
--- In basicx@basi..., "arhodes19044" <spamiam@c...> wrote:
[snip]
> I only have on half of the circuit done (i.e. using only one
trigger
> for the interrupt, and the other side's inputs on the ICs are not
> grounded or anything.) Maybe there is cross-talk.
[snip]
Reply by ●April 8, 20052005-04-08
The logic family I am using is a bastardized (maybe part of the
problem) thing. A 4000 series inverter (pending a schmitt trigger
inverter), a 74HC dual retriggerable multivibrator, and 74HCT dual
latch feeding into a 4000 series OR gate.
Funny thing is that when I used 4000 series stuff exclusively I did
not get any retriggering. Even withoug decoupling and all that
stuff. I may go back to my old 4000 series stuff purely. I'd
rather see if I can get these things working even though my chip
count will not change one way or the other. Actually the 4000
series uses a couple fewer resistors/caps!
-Tony
--- In basicx@basi..., "tombhandley" <gr13tbs@c...> wrote:
>
> Tony, connect any unused Inputs to Ground or VCC depending on the
> logic family.
>
> - Tom
>
> --- In basicx@basi..., "arhodes19044" <spamiam@c...> wrote:
> [snip]
> > I only have on half of the circuit done (i.e. using only one
> trigger
> > for the interrupt, and the other side's inputs on the ICs are
not
> > grounded or anything.) Maybe there is cross-talk.
> [snip]
Reply by ●April 8, 20052005-04-08
Tony, the 4000 CMOS series logic have an Input threshold of 1/2
VDD/VCC. They are getting old and out of date but they do run off a
wider supply range and have good noise immunity as well as low power.
If this is just for your own use, I'd say stick with 4000. If this is
a product, I would strongly recommend looking at current logic
families and adjusting your design. Sorry if you mentioned that
before but I check into many forums and often forget...
In any case, always connect unused Inputs to Ground or VDD/VCC.
- Tom
--- In basicx@basi..., "arhodes19044" <spamiam@c...> wrote:
>
> The logic family I am using is a bastardized (maybe part of the
> problem) thing. A 4000 series inverter (pending a schmitt trigger
> inverter), a 74HC dual retriggerable multivibrator, and 74HCT dual
> latch feeding into a 4000 series OR gate.
>
> Funny thing is that when I used 4000 series stuff exclusively I did
> not get any retriggering. Even withoug decoupling and all that
> stuff. I may go back to my old 4000 series stuff purely. I'd
> rather see if I can get these things working even though my chip
> count will not change one way or the other. Actually the 4000
> series uses a couple fewer resistors/caps!
>
> -Tony >
> --- In basicx@basi..., "tombhandley" <gr13tbs@c...> wrote:
> >
> > Tony, connect any unused Inputs to Ground or VCC depending on the
> > logic family.
> >
> > - Tom
> >
> > --- In basicx@basi..., "arhodes19044" <spamiam@c...>
wrote:
> > [snip]
> > > I only have on half of the circuit done (i.e. using only one
> > trigger
> > > for the interrupt, and the other side's inputs on the ICs are
> not
> > > grounded or anything.) Maybe there is cross-talk.
> > [snip]
Reply by ●April 8, 20052005-04-08
--- In basicx@basi..., "tombhandley" <gr13tbs@c...> wrote:
> connect any unused Inputs to Ground or VCC depending on the
> logic family.
Some logic families should not have their inputs tied to Vcc. Rather,
they need to use a pullup resistor. I know that this caveat applies to
the original 74xxx series but not to some later families like 74LS.
Some engineers use a pullup even though the family doesn't require it.
You can share the same pullup among multiple inputs that are being tied
high.
Don
Reply by ●April 8, 20052005-04-08
OK, I will be either actually USING the other halves of the dual 109
and 123 IC's or tying them high or low. Probably easier to actualy
set up the real second circuit on the breadboard.
I hope this takes care of the multiple trigger issues.
Are there any of the inputs (on either of the IC's in your original
pulse detector circuit diagram that would seem to be particularly
noise sensitive? I am not sure what I can do to relieve the noise
except placement of a cap on those inputs.
The circuits are breadboarded right now. I do not find any wires that
seem to create/reduce the multiple triggers as I move/touch them. BUT
in some cases as I move closer or further to/from the breadboard, then
I can lessen/increase the triggering when it is happening. THe power
supply is heavily filtered, and I have big caps right on the
breadboard too.
Pressing on regrardless.... TOny --- In basicx@basi..., "Don Kinzer" <dkinzer@e...> wrote:
>
> --- In basicx@basi..., "tombhandley" <gr13tbs@c...> wrote:
> > connect any unused Inputs to Ground or VCC depending on the
> > logic family.
>
> Some logic families should not have their inputs tied to Vcc.
Rather,
> they need to use a pullup resistor. I know that this caveat applies
to
> the original 74xxx series but not to some later families like 74LS.
> Some engineers use a pullup even though the family doesn't require
it.
> You can share the same pullup among multiple inputs that are being
tied
> high.
>
> Don
