Den Mon, 9 Jul 2018 01:59:35 +0300 skrev Nejat Dilek <imruon@gmail.com>: > On Sun, Jul 8, 2018 at 6:50 PM, Mia Magnusson <mia@plea.se> wrote: > > > > Or require a longer _KERNAL pulse than this false pulse? > > > > How? I use this pulse to interrupt an attiny85. Even if I check for > the signal again in the interrupt it's all open to every kind of race > conditions since this false signal pops up quite randomly (unless > tamed) before and/or after intended access. Side note : I don't want > to code this in assembly, I prefer C if I can :) If the CPU is fast enough to reliable sample the input not longer than 500nS and not shorter than 41nS after an interrupt has been triggered, a software solution would work. If the input isn't active after 41nS but before 500nS, just ignore the interrupt and be sure to return to a state accepting interrupts fast enough so it can trigger on a real pulse. > Any other hardware means to filter out 41nsec pulses from 500nsec > pulses by the way? (Hmm, maybe using some logic gates with >41nsec > propagation delays) A simple low pass filter will do. 500nS is more than 10 times longer than 41nS so even a simple 6dB/octave RC filter should do the trick. Depending on the signal quality requirements on the interrupt input you might need a schmidt trigger (a 74xx14, 4093 or similar) between the low pass filter and the interrupt input. -- (\_/) Copy the bunny to your mails to help (O.o) him achieve world domination. (> <) Come join the dark side. /_|_\ We have cookies.Received on 2018-07-10 21:00:05
Archive generated by hypermail 2.2.0.