Otóż mam taki problem, bawię się teraz pewna zabawką, gdzie do zmierzenia czasu impulsu wysokiego potrzebuje mieć timer który by zliczał co 1uS (czyli 1MHz). Układ jest taktowany z wewn. oscylatora 8MHz, więc ustawienia dla timera są takie:



Gdzie obsługa przerwania:


No i wszystko było by pięknie, gdyby mi po prostu przy tej szybkości nie zwieszało procka. Po prostu, gdy ustawie taką szybkość, procek zareaguje raz po kilku sekundach a potem zwis. Co ciekawe, gdy ustawiłem szybkość na 100kHz:


To wszystko pięknie śmiga. Problem w tym że jednak potrzebuję zliczać co 1uS bo cierpi na tym rozdzielczość.

Próbowałem już podciągać nieużywane piny do Vcc coby nie robiły za anteny, ale nic to nie dało. Wsadzenie zewn. oscylatora 12MHz (i oczywiście tym samym zmiana OCR0 i ustawień) też nic nie dało.

I tak siedzę nad tym dzisiaj, i już nie wiem co z tym fantem dalej czynić .

Do takich pomiarów wykorzystuje się tryb przechwytywania i wejście ICPx. Poczytaj w książce o dekodowaniu RC5.

_________________
Dragonus Cracovus: Biomagia

No OK. Napisałem coś takiego, ma to jakiś sens?

Niestety nie mogę sprawdzić sam bo straciłem programator i odzyskam go dopiero jutro rano.

uC taktowany 16MHz. Chce mierzyć czas stanu wysokiego na ICP (czas w uS).


I obsługa przerwania:


I rozumiem że zmienna PulseWidth to mój czas stanu wysokiego w uS...Teraz żeby maksymalnie odchudzić przerwanie, to rozumiem że gdybym zadeklarował ją globalnie, to mógłbym ją obrabiać w głównej pętli while(1)? .

Tylko tyle wystarczy:

Jeśli chodzi o preskaler to ustawić możesz tylko 1, 8, 64, 256 i 1024 i tylko wykorzystując TCCR1B. W nowszych procesorach mógłbyś ewentualnie jeszcze skorzystać z preskalera systemowego i przy kwarcu 16MHz ustawić taktowanie procesora na 8MHz i dalej podzielić to przez 8 wykorzystując preskaler timera.
Zmienna PulseWidth oczywiście musi być globalna (bo po wyjściu z przerwania w twoim przykładzie przestaje istnieć) i z modyfikatorem volatile.

_________________
Dragonus Cracovus: Biomagia

Zrobiłem układ z wejściem ICP, ale nadal coś mi nie chce działać. O co chodzi, generalnie wykorzystuje miernik odległości HC-SR04, który wyzwala się 10 mikro-sekundowym stanem wysokim na nóżkę TRIG. Po jakimś czasie przychodzi odpowiedź w postaci proporcjonalnego do odległości stanu wysokiego na wyprowadzenie ECHO.

Napisałem coś takiego:



Wykorzystałem wejście ICP, i wg. datasheet HC-SR04, wynik to czas stanu wysokiego w uS podzielony przez 58.

W moim przypadku jako że wykorzystuję kwarc 16MHz i preskaler 1, to wynik wynosi (czas_w_us/2/58).

No i na wyświetlaczu LCD zmienna PulseWidth dla różnych odległości przyjmuje praktycznie losowe wartości z całego zakresu int_16t.

Na początek połącz sobie wyjście TRIGER i wejście ICP i zmierz sobie czas stanu wysokiego który generujesz dla HC-SR04. Możesz sobie dla testów zmienić _delay_us(10) na inne wartości, aż do maksymalnej.

_________________
Dragonus Cracovus: Biomagia

Hmm dobry pomysł z tym podłączeniem wyjścia PA0 do ICP. No ale cóż, okazało się że w tym przypadku również na LCD pokazuje mi losowe liczby, bez względu na to czy sygnał trwa 10uS czy 1000uS.

W takim razie problem leży po stronie programu. Pobawiłem się z różnymi preskalerami oraz różnymi częstotliwościami ale wynik cały czas ten sam. Losowe liczny w zmiennej PulseWidth.

Witaj.
Ja na Twoim miejscu zainteresowałbym się jakimś analizatorem stanów logicznych. Niestety bez sprawdzenia "organoleptycznego" trudno Ci będzie sprawdzić, czy Twoje założenia co do działania programu są poprawne.
Piszę to z własnego doświadczenia. Na potrzeby konkursu kolego !NIEBO dotyczącego bezdotykowego włączania i wyłączania światełek próbowałem wygenerować na przerwaniu falę prostokątną o częstotliwości 36kHz. Niby wszystkie preskalery i inne wartości były poustawiane poprawnie ale ni w ząb nie chciało działać. Dopiero analiza przy pomocy analizatora stanów logicznych w piękny sposób pokazała mi gdzie robię błędy.
Mam za mało doświadczenia w praktycznym pisaniu programów na mikrokontrolery i uwierz mi, odpowiednie narzędzia po prostu pokazują całą radość z zabawy (w moim akurat przypadku) mikrokontrolerami.
Trzeba mieć doświadczenie Mirka i Suna aby pisać programy bez konieczności (częstego) sięgania po takie narzędzia jak analizator stanów logicznych, czy oscyloskop.
A po drugie szkoda nerwów i wątroby na szukanie błędów w programach

_________________
sig off ;(

No tak PulseWidth w takim przypadku zawiera czas trwania stanu wysokiego, a następnym razem stanu niskiego (który jest nieokreślony, bo zależy od momentu wyzwolenia impulsu). Oczywiście wtedy gdy masz:
bo zmiana na jest bez sensu.
Wprowadź taką poprawkę:

_________________
Dragonus Cracovus: Biomagia

O to to kolego Teraz się ładnie ustabilizowało. Wyniknął jeszcze jeden mały problem. Mianowicie taktuje 16MHz, preskaler ustawiony na 8 więc przerwanie mam co 0,5uS. Czyli zmienną PulseWidth dziele na 2 i wychodzi mi wynik w uS. No i było by ok gdyby ta zmienna miała wartość: (długość_sygnału)*2. Problem w tym że ma trochę więcej, poczyniłem taką tabelkę w której wypisane jest ile wynosił stan wysoki na pinie, a ile uC zmierzył.



Włączenie redukcji szumów ICNC1 w rejestrze TCCR1B nie daje zupełnie nic.

Jak rozumiem to T[us] to jest generowane przez ten sam procesor i nie sprawdzasz oscyloskopem co się wygenerowało. Twoja sekwencja generowania impulsu właściwie to wygląda tak:

Sporo tego. Weź teraz pod uwagę, że przy taktowaniu 16MHz jedna instrukcja asemblera (typowa, bo są i dłuższe) zajmuje 1 cykl zegara, czyli 1/16 us.
Jak masz drugi procesor to jednym generuj, a drugim zmierz. Oczywiście możesz pominąć ten eksperyment. Czujnik przecież sam generuje sygnał.

_________________
Dragonus Cracovus: Biomagia

No tak, racja. W takim razie moge najprościej w życiu po prostu odjąć tę siódemkę.

Natomiast pytałem o to, bo czujnik mierzy mi pięknie ładnie do 1652 (czyli 1652/2/58=14cm). Wyżej już licznik pokazywać nie chce, i myślałem że to wina samego czujnika.


EDIT: Ma ktoś może czujniczek HC-SR04? Bo nie wiem już czy to wina programu czy samego czujnika.