Witam

Otóż bawiłem się dzisiaj conieco czujniczkiem ultradźwiękowym i napotkałem taki problem. Otóż: do zliczania czasu stanu wysokiego używam wejścia ICP (w HC-SR04 czas stanu wysokiego w us odpowiada odległości)



No i wsyzstko pieknie działa, ale chciałbym że wyświetlał mi wynik w konsoli (połączyłem się z PC przez max232) co np.20ms. Napisałem coś takiego:



I teraz tutaj mam problem bo nie za bardzo mam pomysł jak to sobie wykombinować. Zrobiłem taką pętlę for:



I zadziałało by to dobrze gdybym programował liniowo, czyli nie używał przerwania. Natomiast gdy używam przerwania to nie mam pomysłu gdzie to "opóźnienie" wrzucić. Do obsługi przerwania przecież nie wrzucę bo to jest wejście przechwytujące.

Dla pełnego obrazu sytuacji wrzucam pełny kod - opóźnieniem przy przycisku nie należy się przejmować bo w finalnej wersji będzie to zupełnie inaczej rozwiązane( sygnał START z aplikacji z PC).

A nie lepiej synchronizować sobie pracę pętli głównej licznikiem obsługiwanym przez Timer0 co np. 10ms. Chyba że szkoda to wtedy Timer1 i tak jest użyty i pracuje wystarczy wpisać odblokować przerwanie od przepełnienia i masz przerwanie co 32,768ms.

_________________
Dragonus Cracovus: Biomagia

No tak, ale spójrz.

Taktowanie mam 16MHz, i potrzebuje przerwanie co 10ms (czyli 100Hz). Wykorzystując 8-bitowy Timer0 i dzieląc preskalerem przez 1024, wartość OCR wyjdzie mi 156,25. Nie mogę wpisać do rejestru wartości z przecinkiem więc wpisując tam 156 otrzymam 100,16Hz - co nie za bardzo mnie urządza, ponieważ z czasem to odchylenie od pokazania wyniku co 10ms będzie coraz większe.

Ideałem byłby preskaler 256 no ale wtedy wyjdę poza dopuszczalną wartość OCR (czyli 625).

A to musi być w jednym przerwaniu to 10ms ? Przecież możesz dać preskaler=256, OCR0 = 125 i masz co 2ms, a przy OCR0 = 250 co 4ms. W przerwaniu możesz zwiększać drugi wewnętrzny licznik i zdarzenie w pętli głównej może być wyzwalane z wielokrotnością 2ms lub 4ms.

_________________
Dragonus Cracovus: Biomagia

Ehh, jak to mówią, najlepsze rozwiązania są zawsze najprostsze. Zawsze muszę kombinować na okrętkę


Na chwile obecną poczyniłem taki kod (Twojego pomysłu na razie nie wykorzystam, bo z nieznanych mi przyczyn padło mi zasilanie i muszę to jakoś ogarnąć) :



Wygląda na to że wszystko jest jak należy, ale martwi mnie jedna rzecz. Mianowicie czasami przerwanie wysyłające dane do PC uaktywnia się w czasie pomiaru ICR1. Czy do konsoli podeśle mi ostatnio "skończony pomiar", czy nieużyteczny śmieć z pomiaru "na gorąco" - czyli z jeszcze nie skończonego ?

Wynik to zawsze skończony pomiar: aktualny lub poprzedni. Jest tak dzięki tej linii:

Jakbyś chciał wiedzieć czy pomiar się zakończył należy badać bit ICES1.
PS.
Jesteś pewny odejmowania tych 7 impulsów. Przypomnę, że one nie wynikały z błędu pomiaru, a z wydłużonego generowania sygnału, gdy robił to ten sam procesor. Teraz gdy sygnał mierzony jest z zewnętrznego źródła moim zdaniem jest błędem odejmowanie tych 7 impulsów.

_________________
Dragonus Cracovus: Biomagia

Co do odejmowania 7 impulsów, to dzięki za celną uwagę. Tak trochę bezmyślnie wrzuciłem to odejmowanie, a przecież wcześniej sygnał nie pochodził z zewn. układu.

Natomiast dzisiaj tak nad tym siadłem i wpadłem na pewien pomysł, bo jeśli wynik ma być prezentowany co 10ms, to przecież mogę wrzucić _delay_ms(10). Sama funkcja nie zamraża mi procka, i przerwania będą nadal chodzić.