Zamiast próbować aktualizować TCNT0, lepiej byłoby śledzić liczbę cykli utraconych w wyniku konwersji ADC i w procedurze pośredniej - np. omillis () - skompensować te cykle. [Edytuj: zobacz lepszą alternatywę poniżej]

Bardziej szczegółowo:

• Przy każdej konwersji dodaj około 128 · 13 cykli (lub być może 128 · 13.5, aby uwzględnić średnie opóźnienie preskalera) do licznika cykli:
dawno utracone cykle; ...; lostcycles + = ADCcycles;

• W ramach każdego wywołania omillis () powiedz return millis () + lostcycles / 16000

• Albo powiedz return millis () + lostcycles>>14 , aby uniknąć marnowania czasu na podział. W przypadku korekty byłoby to o 2% mniejsze, ale zakładam, że korekta jest niewielka, powiedzmy 5% całkowitego czasu, co prowadzi do około 0,1% błędu z powodu użycia przesunięcia zamiast dzielenia.

Re: „Przegapiłbym zdarzenie przepełnienia (tego, którego Arduino używa wewnętrznie do śledzenia czasu) za każdym razem, gdy konwersja ADC jest rozpoczynana z TCNT0> 230”

To nieprawidłowe [jeśli używasz sugerowanego podejście]. Nawet jeśli przepełnienie timera 0 zostanie obsłużone sto mikrosekund z opóźnieniem, zostanie obsłużone poprawnie. [Jak zauważono w komentarzu Edgara Boneta, metoda, która po prostu dodaje do TCNT0 bez sprawdzania przepełnienia arytmetycznego, jak w oryginalnym podejściu, może przeoczyć takt timera.]

Uwaga, przykładowy kod wykorzystujący SLEEP_MODE_ADC w sekcji „Uśpij podczas czytania” w sekcji Konwersja ADC na Arduino na forum Gammon sugeruje, że należy sprawdzić przypadek, w którym występuje licznik czasu lub inne przerwanie podczas konwersji ADC. Podczas gdy SLEEP_MODE_ADC zatrzymuje clk _{I / O} , clk _CPU i clk _FLASH , opuszcza Timer 2, WDT, i kilka innych potencjalnych aktywnych źródeł przerwań.

Lepsza alternatywa:

Jak zauważa Gerben, nieco czystszym rozwiązaniem jest aktualizacja zmiennej count obsługiwanej przez millis () , zamiast używania procedury pośredniej. Więcej informacji znajdziesz w jego odpowiedzi na wcześniejsze pytanie. Oto adaptacja [nieprzetestowana] pomysłu do obecnego przypadku:

  unsigned int lostcycles = 0; ...; void accountForADC () {enum {ADCcycles = 13 * 128 + 64; ms_cycles = 16000}; // dostosuj odpowiednio zewnętrzny volatile unsigned long timer0_millis; zgubione motocykle + = ADCycles; while (lostcycles > = ms_cycles) {// Ta pętla zwykle wykonuje tylko jeden przebieg bajtów statusReg = SREG; // Zapisz stan przerwania cli (); // Wyłącz przerwania ++ timer0_millis; // Potrzebujesz przerwania dla atomowości SREG = statusReg; // Przywróć stary status lostcycles - = ms_cycles; }}  

Po uruchomieniu, przy dziesiątym wywołaniu funkcji accountForADC () ten kod doda 1 do timer0_millis , aby uwzględnić milisekundę przegrane z konwersjami ADC. lostcycles - = ms_cycles ustawi lostcycles na 1280. Po kolejnych 9 rozmowach ponownie dodajemy 1 do timer0_millis i zmniejszamy liczbę lostcycles ; i tak dalej.

Nie powiem ci, jak zrobić to, o co prosisz, ponieważ tak naprawdę nie wiem, jak to zrobić. Ale mam przeczucie, że da się zrobić. Tylko że byłoby to naprawdę, bardzo trudne , więc pojawia się pytanie: czy warto?

Aby uniknąć publikowania odpowiedzi opartych wyłącznie na opiniach, postaram się udzielić you someleads:

• Możesz ustawić timer 0 z rozdzielczością pojedynczego cyklu procesora, po prostu resetując jego prescaler za każdym razem, gdy ustawisz nową wartość.
• Możesz wprowadzać bardzo precyzyjne opóźnienia z funkcją _delay_us () . Argument powinien być stałą czasu kompilacji. _delay_us (0.125) robi dokładnie to, co mówi, że robi.
• Uważaj na preskaler zegara ADC: będzie on powodował pewne wahania czasu ADC, chyba że go zresetujesz. AFAIK, jedynym sposobem na zresetowanie tego preskalera jest rozpoczęcie konwersji ADC przy użyciu jakiegoś źródła wyzwalania w trybie automatycznego wyzwalania. Może to kosztować licznik czasu.
• Jeśli przegapisz zdarzenie przepełnienia, możesz po prostu ręcznie wywołać odpowiedni ISR ​​( TIMER0_OVF_vect () , który deklarujesz za pomocą ISR (TIMER0_OVF_vect ); ). Brzmi głupio, ale działa, pod warunkiem, że na siłę włącza przerwania po powrocie.

Aby dowiedzieć się, ile tików dokładnie tracisz, możesz wydać fewevenings uważnie przestudiuj czasy w arkuszu danych lub możesz spróbować skalibrować je na stabilnym źródle częstotliwości. Poleciłbym to drugie.

Myślę, że źle przeczytałeś arkusz danych. Konwersja trwa 13 cykli ADC (z wyjątkiem pierwszego), a nie 13,5.

Po drugie; Konwersja zaczyna się przy następnej narastającej krawędzi zegara ADC, a nie bezpośrednio. Tak więc, ponieważ preskaler ma wartość 128, może zająć dodatkowe 127 cykli zegara głównego przed narastającym zboczem kolejnego zegara ADC. Oznacza to, że konwersja ADC trwa od 13 do 13,9921875 cykli zegara ADC.

Nie jestem też pewien, ile czasu zajmie uC ponowne uruchomienie zegara procesora. Mogę więc „stracić” więcej czasu.

Chociaż musisz być świadomy, że oscylator kwarcowy nie jest tak dokładny na początku.

Czas rozpoczęcia konwersji nie jest ustalony. Na mojej stronie poświęconej licznikom czasu widzimy następujące informacje:

Porada:”

Jest dodatkowy czas przed rozpoczyna się konwersja. Konwersja rozpoczyna się na krawędzi czołowej zegara ADC, a nie w momencie, gdy prosi o to kod. W przypadku skalera 128, może być dodanych 127 dodatkowych cykli zegara (procesora), ponieważ sprzęt musi czekać na następny cykl zegara ADC. Może to dodać 7,938 µs do czasu konwersji.

Wygląda na to, że preskaler można zresetować, wpisując 0 do ADEN. Zgodnie z arkuszem danych:

Prescaler rozpoczyna odliczanie od momentu włączenia ADC poprzez ustawienie bitu ADEN w ADCSRA. Prescaler działa tak długo, jak ustawiony jest bit ADEN i jest stale resetowany, gdy ADEN jest niski.

Jeśli jednak to zrobisz, dodasz do czasu konwersji, tak jak będzie teraz weź 25 cykli zegara ADC zamiast 13.

• Jak sugerowali inni, jeśli dokładny czas jest tym, czego potrzebujesz, to zewnętrzny układ zegara może być dobrym rozwiązaniem. Chip i części prawdopodobnie osiągną cenę mniej więcej jednego dolara.

• Alternatywą byłoby uzyskanie zewnętrznego układu ADC, przenosząc w ten sposób problem redukcji szumów na chip który (miejmy nadzieję) został zaprojektowany, aby sobie z tym poradzić.

• Inną możliwością byłoby podłączenie wejścia zewnętrznego zegara do Timera 1 i uruchomienie go asynchronicznie. Jak czytałem arkusz danych, ten zegar będzie działał w trybie uśpienia ADC, więc możesz go użyć do pomiaru czasu. (To nie pomogłoby w przypadku millis () i micros (), ale można by napisać coś podobnego do Timera 1).

  Edytuj - jak wskazał Edgar Bonet się, źle odczytałem arkusz danych. To Timer 2 może to zrobić, a nie Timer 1. A szpilki do asynchronicznego uruchamiania timera nie znajdują się na chipie PDIP w Uno i nie są wyprowadzone do pinów płytki w Mega.