bmajkut Napisano Październik 28, 2013 Udostępnij Napisano Październik 28, 2013 Witam,napisałem kod do obsługi tego czujnika. Wysyłam wartość zmierzonego czasu przez usart do terminala. Jeżeli zbliżę przeszkodę na odległość 2 cm to otrzymuję w odpowiedzi wartość "40" co po podzieleniu przez 20 da mi 2 cm. Wyczytałem tutaj na forum w jakimś starym artykule, że to należy tak skalować. Chciałbym się jednak dowiedzieć dlaczego akurat dzielimy przez "20". W nocie katalogowej czujnika mamy wzór: odl = (czas stanu wysokiego * 340[m/s] ) / 2 Z tego wzoru nie wynika, że mamy stan wysoki dzielić przez "20" chyba że nie potrafię sobie tego przekształcić. Czas wysoki mierzę Timer2 w mikrosekundach, więc po przekształceniu wzoru powinienem czas stanu wysokiego mnożyć razy "0,017". Dodatkowo zauważyłem, że czujnik kiedy jest skierowany w stronę sufitu to maksymalnie daje mi wartość 1800, co po podzieleniu przez "20" daje "90", a do sufitu z blatu biurka mam zdecydowanie więcej. Kod programu: #define F_CPU 8000000ul #include <avr/io.h> #include <avr/interrupt.h> #include <util/delay.h> #include <stdio.h> #include "uart/uart.h" volatile int odl0 = 0; volatile int licznik = 0; char flaga = 0; char bufor[20]; void sonar_init() { DDRC = 0x02; MCUCR |=(1<<ISC00)|(1<<ISC01); GICR |= (1<<INT0); TCNT2 |= 0x00; TCCR2 |= (1<<WGM21)|(1<<CS20); OCR2 = 0x08; sei(); } ISR(TIMER2_COMP_vect) { licznik++; } ISR(INT0_vect) { if(flaga==0) { TIMSK = (1<<OCIE2); GICR &= ~(1<<INT0); MCUCR = 0x00; MCUCR = (1<<ISC01); GICR = (1<<INT0); flaga=1; } else if(flaga==1) { TIMSK &= ~(1<<OCIE2); GICR &= ~(1<<INT0); MCUCR = 0x00; MCUCR = (1<<ISC01)|(1<<ISC00); GICR = (1<<INT0); odl0=licznik; //odl0/=20; licznik=0; flaga=0; } } int l_pomiar(void) { //odl0=0; GICR |= (1<<INT0); PORTC |= (1<<PINC1); _delay_us(15); PORTC &= ~(1<<PINC1); _delay_ms(8); GICR &= ~(1<<INT0); return odl0; } int main(void) { sonar_init(); USART_Init(); uart_puts(" start "); while(1) { _delay_ms(1000); sprintf(bufor, "D: %d",l_pomiar()); uart_puts(bufor); } } Cytuj Link do komentarza Share on other sites More sharing options...
marek1707 Październik 28, 2013 Udostępnij Październik 28, 2013 Gdybyś jeszcze napisał jaki masz procesor i jak podłączyłeś czujnik to łatwiej byłoby zagłębić się w kod. Generalnie przedstawiony program to jakaś pomyłka. Timer 2 ustawiony jest na zgłaszanie przerwań co 1us. Żaden procesor z zegarem 8MHz nie jest w stanie obsłużyć tak częstych przerwań. Autor pewnie tego nie wiedział, licznik jakoś mu się inkrementował bo przerwania przecież były obsługiwane tylko wcale nie tak często jak chciał timer więc i wyniki były bzdurne. Wtedy zobaczył ile dostaje, dobrał sobie jakiś współczynnik i mniej więcej mu działało. Żałosne. Do zliczania interwałów 1us zaprogramuj po prostu któryś timer na liczenie z podzielnikiem 1/8. Puszczaj go od wartości 0 gdy wykryjesz stan wysoki na sygnale z sonaru a zatrzymuj po zakończeniu impulsu wyjściowego. Wynik będzie na pewno w mikrosekundach. Dla pewności możesz też obsługiwać przerwanie od przepełnienia tego timera w którym ustawisz flagę "overrange". Najbardziej elegancko byłoby oczywiście mierzyć długość impulsu przy pomocy wejścia InputCapture. Do tego właśnie zostało stworzone. Zamiast mnożyć przez 0.017 lub dzielić przez 58 możesz pomnożyć liczbę mikrosekund przez 1130 a z wyniku wziąć tylko 16 najstarszych bitów. Tak chyba będzie najszybciej. Cytuj Link do komentarza Share on other sites More sharing options...
bmajkut Październik 28, 2013 Autor tematu Udostępnij Październik 28, 2013 Kod napisany na Atmega8 z wewnętrznym oscylatorem 8Mhz. A jaka jest różnica pomiędzy tym czy mam Timer z preskalerem 1/8 i liczę do 8 i wtedy mam jedną mikrosekundę a tym co ty zasugerowałeś? Cytuj Link do komentarza Share on other sites More sharing options...
marek1707 Październik 28, 2013 Udostępnij Październik 28, 2013 Różnica jest następująca: W zaprezentowanym programie timer liczy z pełną częstotliwością zegara, co 1us zgłasza przerwanie i zeruje się (tryb CTC) zaczynając cykl od nowa. To program jest odpowiedzialny za to, by reagować na przerwania i co 1us inkrementować zmienną "licznik". To jest oczywiście niemożliwe, bo samo wejście i wyjście z obsługi przerwania zajmuje więcej niż 1us więc program zaczyna się spoźniać. Przerwania przychodzą co 1us a licznik jest inkrementowany rzadziej np. raz na dwa lub trzy przerwania. W rezultacie mimo iż procesor był zajęty na 100%, pod koniec masz w zmiennej "licznik" jakiś wynik, ale spokojnie możesz go wyrzucić do kosza. Nie ma wiele wspólnego z faktyczną liczbą mikrosekund jakie upłynęły w czasie liczenia czasu. Takie metody można stosować gdy masz liczyć np. z rozdzielczością 1ms ale nie 1us. Ktoś zupełnie nie rozumiał co robi, przykro mi. Gdy używasz timera jako licznika czasu, puszczasz go od zera z zegarem np. 1us i nic więcej nie robisz. Czas się liczy sam, timer niczego oprócz zegara nie potrzebuje, sam się inkrementuje a program może robić coś innego np. sprawdzać czy impuls już się zakończył. Wtedy zatrzymujesz timer przez wyłączenie mu zegara i spokojnie, już przy zatrzymanym zliczaniu odczytujesz odpowiedni rejestr TCNTx. Dostrzegasz? Tak jak napisałem istnieje jeszcze bardziej elegancka metoda pomiaru długości czasu trwania impulsu korzystająca ze specjalnej funkcji timera, tzw. Input Capture. Tam to już nawet timera nie trzeba zatrzymywać, a wystarczy tylko z odpowiedniego rejestru odczytać momenty początku, końca impulsu zapamiętane sprzętowo a potem je od siebie odjąć. Tak właśnie powinna być zrobiona obsługa sonaru. Cytuj Link do komentarza Share on other sites More sharing options...
Polecacz 101 Zarejestruj się lub zaloguj, aby ukryć tę reklamę. Zarejestruj się lub zaloguj, aby ukryć tę reklamę. Produkcja i montaż PCB - wybierz sprawdzone PCBWay! • Darmowe płytki dla studentów i projektów non-profit • Tylko 5$ za 10 prototypów PCB w 24 godziny • Usługa projektowania PCB na zlecenie • Montaż PCB od 30$ + bezpłatna dostawa i szablony • Darmowe narzędzie do podglądu plików Gerber Zobacz również » Film z fabryki PCBWay
bmajkut Październik 29, 2013 Autor tematu Udostępnij Październik 29, 2013 Czyli jeśli dobrze zrozumiałem: -skonfigurować Timer tak, by co 1us zwiększał zawartość rejestru TCNT1 -gdy na wyjściu echo pojawi się stan wysoki to zapisać aktualny stan rejestru TCNT1 -sprawdzać stan wyjścia echo i jeśli pojawi się niski to zapisać końcowy stan TCNT1 -różnica tych dwóch wartości to czas w mikrosekundach Od razu widać że muszę użyć licznika 16-bitowego. W funkcji wyzwalania powinienem zerować rejestr TCNT1, aby się licznik nie przekręcił w trakcie zliczania czasu trwania echa? Cytuj Link do komentarza Share on other sites More sharing options...
marek1707 Październik 29, 2013 Udostępnij Październik 29, 2013 To juz zależy od Ciebie. Jeśli licznik wyzerujesz a dopiero potem wystartujesz, to wynik masz na talerzu - po zatrzymaniu odczytujesz i już. Co więcej możesz wtedy programowo podglądać stan odpowiedniej flagi TOV i jeśli się ona ustawi to będzie znaczyło, że minęło ponad 65ms i na echo nie ma chyba już sensu czekać dłużej. Możesz też sprawdzać ja na końcu, już po zatrzymaniu licznika i odczytaniu jego zawartości w celu upewnienia się, że podczas liczenia TCNT nie przekręcił się ani razu przez 0xFFFF. Oczywiście używając TOV powinieneś ją zerować przed każdym startem zliczania. Za darmo masz sprzętowe wykrywanie przepełnień. Niezerowanie licznika kosztuje tylko jedno odejmowanie więcej. Niewielki koszt, ale tracisz możliwość korzystania z TOV - moim zdaniem cenną. EDIT: Metoda InputCapture jest jeszcze czymś innym. Tam korzystasz ze sprzętowej możliwości zatrzaskiwania stanu pracujacego licznika w specjalnym rejestrze. To blok timera - odpowiednio zaprogramowany na zbocze narastające - wykrywa pojawienie się tego zdarzenia na wejściu ICx, zapamiętuje stan licznika i zgłasza przerwanie. Ty na spokojnie odczytujesz ten rejestr, przeprogramowujesz na wykrywanie tym razem opadającego zbocza i dalej spokojnie czekasz. Gdy się ono pojawi, znowu dostaniesz przerwanie, odczytasz ten sam rejestr, odejmiesz obie wartości i już. Oczywiście nie musisz korzystać z przerwań - flagę gotowości nowych danych możesz sprawdzać programowo. Zauważ, że w tej metodzie nie ma żadnych opóźnień związanych z pracą programu. Jeśli chcesz łapać mikrosekundy to zaczyna być ważny czas jaki upływa od momentu wykrycia przez program odpowiedniego stanu na wejściu a wyzerowaniem i puszczeniem timera. To samo przy końcu: też trzeba wykryć stan niski i zatrzymać timer. Ten czas nie zawsze jest taki sam (program kręci się w pętli a zbocze może go "złapać" w przypadkowym momencie tej pętli) więc pomiar będzie zawsze obarczony pewnym błędem. Co gorsza, jeśli program w tym czasie obsługuje jakieś inne przerwania, ich czas obsługi musi się dodać do błędu zliczania czasu. ATmega8 ma mechanizm InputCapture wbudowany w Timer1, więc nic nie stoi na przeszkodzie by go wykorzystać. Jedynym wymaganiem jest to, by mierzony impuls doprowadzić do wejścia IC1. Cytuj Link do komentarza Share on other sites More sharing options...
bmajkut Październik 30, 2013 Autor tematu Udostępnij Październik 30, 2013 Należy zaznaczyć, że istnieją dwa sposoby obliczania odległości od przeszkody: 1. Długość stanu wysokiego na nóżce Echo jest proporcjonalna do odległości ze współczynnikiem proporcjonalności 58 dla centymetrów 2. Czas pomiędzy impulsem Trigger a stanem wysokim na nóżce Echo można obliczyć ze wzoru: d = t *340[m/s] / 2 Cytuj Link do komentarza Share on other sites More sharing options...
Pomocna odpowiedź
Dołącz do dyskusji, napisz odpowiedź!
Jeśli masz już konto to zaloguj się teraz, aby opublikować wiadomość jako Ty. Możesz też napisać teraz i zarejestrować się później.
Uwaga: wgrywanie zdjęć i załączników dostępne jest po zalogowaniu!