Ja, det var det jag avsåg. Dvs ett vanligt interrupt för första pulsen sätter upp "capture interrupt" och den andra pulsen "fångas" med ett dylikt och klockar in räknarvärdet i registret. uC:n har bara en sådan interrupt, men det räcker då. Osäkerheterna är inte i tiden det tar att sätta upp avbrottet i första delen (nolla register osv.), det tar iofs tid men den är deterministisk, utan tiden det tar att avbryta pågående instruktion. Både för första avbrottet och det andra. Om jag inte missminner mig så kan en insn på 328p ta mellan en och fyra klockcykler och eftersom avbrottet inte triggas förrän efter instruktionen är färdig så blir det en variabilitet.Fält skrev:Det räcker nog fint att bara lagra timer värdet från en timer interrupt så länge som processorn inte har för mycket att göra, men det normala sättet är att använda en input capture istället för en vanlig interrupt...
1us i upplösning räcker dock inte. Det blir ~3 m/s i de farter vi talar om. Nu fungerar det ändå med 1 i prescaler eftersom man kan räkna i > 4ms med 16MHz klocka och 16 bitars register. Och tiden mellan sensorerna här som mest ca 1ms vid 300 m/s. Så vi kan dra nytta av den fulla upplösningen.
Så, jag tror inte vi behöver något busy-waitande? (Jag förstod inte den delen i ditt resonemang.) Men tack för erbjudandet om samarbete. Jag har dock redan skrivit kod som fungerar när jag räknar pulspbredder från min funktionsgenerator som test, så det skall vara en smal sak att flytta över. Som vanligt lär det ta längre tid att bygga ihop grejjen fysiskt, än att programmera den.
(Fö kul att det här projektet har fått mig att lära mig hur jag laddar in en arbitrary waveform på min fkn-generator s.a. jag kan sitta vid lab-bänken och köra fullskaletester utan att behöva skjuta i källaren. Så jag kan både simulera kretsar i LTSpice med riktig vågform, för att sedan provköra den riktiga kretsen i bänk. Och naturligtvis fånga och vågformen med billigt (!) digitalt lagrings-oscilloskop Det är inte åttiotalet längre!
)
)
