On 7/10/2018 3:19 PM, silverdr@wfmh.org.pl wrote: > >> On 2018-07-10, at 20:43, Jim Brain <brain@jbrain.com> 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. >>> As long as the assumption is that valid pulse is always longer than the longest spurious one, you can use the "software debouncing" - similar to what is sometimes used to debounce relatively fast switches, without adding significant capacitance, Schmitt triggers, etc. I used it more than once with good results. >> I think it will require moving from an interrupt driven approach on the AVR (used now), to a polling approach: > Depends on the IRQ latency there but I am afraid in this situation this may be required. > >> while(PINC & _BV(PIN5)) {} // or whatever >> if(!(PINC & _BV(PIN5)) { >> // real signal. >> } >> >> An instruction on the 16MHz AVR takes at least 62.5nS, so the next comparison will push you beyond the 42nS issue. > Which further simplifies things greatly. What would be the longest for the above? > I'd say you'd need to do a test to see. I suspect it's 1 cycle to copy PINC to register START 1 cycle to copy the compare value 1 cycle to do the compare 1 cycle to copy PINC END 1 cycle to compare So, 187.5nS But, if the compiller optimizes and move the compare value load above the PINC load, it would be 125nS -- Jim Brain brain@jbrain.com www.jbrain.comReceived on 2018-07-11 02:00:04
Archive generated by hypermail 2.2.0.