Mam układ, w którym chcę jak najdokładniej zmierzyć częstotliwość przychodzących impulsów zewnętrznych. Teraz robię to tak: Uruchomiony mam Timer1 w którego przerwaniu zwiększam jakiś licznik (nazwijmy go CNT). Na narastającym zboczu impulsu wywoływane jest przerwanie, w którym obliczam częstotliwość dzieląc częstotliwość zegara Timer1 (czyli max ilość impulsów w czasie 1s) przez CNT (czyli ile razy zegar zdążył "tyknąć"). Teoretycznie powinno to dać dosyć dokładny odczyt, jednak w praktyce wcale tak nie jest. Nie mogę przeskoczyć jednej (raczej banalnej) sprawy
- przerwania są "blokujące", a procedura ich obsługi zabiera jakiś czas, przez co pomiar "tyknięć" zegara jest niedokładny. Jeśli zrobię "nieblokujące", to w ogóle wychodzą jaja i odczyt jest dobry jeden na kilka.
A nie możesz skorzystać z ICP? To chyba najlepiej się do tego nadaje. Licznik sobie leci na 16 bitach w kółko, każdy impuls zatrzaskuje stan licznika i tylko trzeba odjąć poprzednią wartość. Częstotliwość przychodzących impulsów zbyt mała?
Już zrobiłem, właśnie w taki sposób, a licznik rozszerzyłem na 32 bity przez dodanie 16. bitowej zmiennej inkrementowanej w przerwaniu zegara. Teraz wystarczy odjąć starą wartość licznika od nowej i użyć wyniku do podzielenia częstotliwości taktowania procka. Wystarczyło się ze 2 godziny przespać ;)
Powiedz jeszcze - czy potrzebujesz 32-bitowej dokładności?? 16-bitowa nie wystarczy?? Wówczas mógłbyś zrezygnować ze zmiennej w pamięci i operować tylko na wartości licznika... wiesz, ICP zatrzaskuje Ci stan licznika, ale nie zatrzaskuje wartości zmiennej... da się to obejść, ale sprawa się komplikuje - czy warto??
Nie doczytałem, że piszesz o ICP (wciąż trochę niedospany jestem). Nie korzystam z tego, bo mam dwa źródła sygnału, na INT1 i INT2.
16 bitowa rozdzielczość powinna wystarczyć, najmniejsza częstotliwość, którą chcę mierzyć to 1Hz, największa powiedzmy 7kHz kwarc mam
11.0592MHz więc przy podziale taktowania zegara przez 256 teoretycznie powinno być ok.
32 bitowy licznik rozwiązuje mi problem obliczania różnicy czasu pomiędzy impulsami - po prostu odejmuję 2 liczby, nie muszę się zastanawiać co z przepełnieniem.
Dokładność... hmm... dopuszczam rozbieżność kilku Hz co przy przy niższych częstotliwościach (kilkadziesiąt Hz) oznacza max 5% i mniej przy większych częstotliwościach (kilka kHz), ale ważniejsza jest dla mnie powtarzalność pomiarów, bo urządzenie jest kalibrowalne i częstotliwość jest przeliczana są np na obroty (czy co tam innego sobie user zażyczy).
BTW podłączę się pod ten temat, ponieważ w pewnym sensie jest związany. Mianowicie chciałbym trochę pobawić się programowaniem AVR i przyszedł mi do głowy pomysł zrobienia czegoś konstruktywnego. A mianowicie interfejsu do PDA, który umożliwiałby używanie go jako licznika rowerowego. :)
Założenie jest takie, że standardowo kontrakton mierzyłby czas obrotu koła o znanym obwodzie. To dawałoby informację o tym jaki dystans przejechał rower w tym odcinku czasu. Sprowadzenie tego do km/h to kilka linijek kodu. ;) Zastanawia mnie tylko czy przypadkiem nie będzie konieczne zastosowanie osobnego RTC do mierzenia tak krótkich odcinków czasu? Drugą rzeczą jest przesyłanie danych do urządzenia przenośnego. Chyba najprościej byłoby użyć rs232, jednak obecnie coraz mniej PDA posiada ten interfejs. Może lepiej byłoby to przesyłać przez podczerwień
- mają ją zarówno leciwe Palmy jak i większość nowoczesnych urządzeń. Czy BASCOM posiada jakieś proste procedury robiące to zgodnie z ogólnie przyjętymi standardami? Obawiam się, że samodzielna implementacja tego by mnie przerosła. ;)
Oczywiście potem musiałbym stworzyć odpowiedni program odbierający dane, wyświetlający je i ewentualnie wrzucający do pliku, co wymagałoby przypomnienia sobie podstaw C (lata bezczynności jeśli idzie o programowanie, a ten język to dosłownie tylko liznąłem), przejrzenia jakichś kursów i tutoriali itp...
realtime clock? nie będzie potrzebny... chyba że chcesz stampować pomiary datą, do celów archiwizacji?
krótkich? z szybkiego policzenia wychodzi że przy 26" kole 10Hz to
75km/h. pomykasz szybciej? ;)
10Hz dla uC to cała wieczność.
Zawsze można zrobić z FT232, tylko PDA (a raczej jego OS) musi umieć z nim gadać,
[...]
dla SIR TIOM4232 / TFDU4100
A ten PDA to chcesz mieć cały czas przypięty? nie szkoda go? wiesz - deszcz, wstrząsy, ewentualne "wywrotki" na rowerze - zależy po czym jeździsz. Chyba że jakiś stary B&W, który już na technologicznej "emeryturze".
plus kilkuset godzin spędzonych na debugowaniu prostych błędów zarówno dla AVR jak i dla PDA... Jeśli na tym etapie się nie zniechęcisz, to już połowa sukcesu.
Jak już się będziesz brał za C, to daruj sobie bascoma. Kompilatory C dla AVR też mają się całkiem dobrze.
Dobrze by było, choć może na początek można by sobie darować... :)
No tak, masz rację. ;)
Masz na myśli interfejs USB-RS232? Jeśli tak, to niestety nie wypali. Tylko nieliczne modele posiadają hosta USB...
Nie jest aż tak tragicznie. Można dostać specjalne obudowy rowerowe dla PDA, które chronią przez deszczem i w pewnym zakresie wstrząsami. Ludzie ponoć wykorzystują je z powodzeniem podczas jazdy po jakichś leśnych wertepach. Ja preferuję jazdę po utwardzonych drogach i jakichś polnych dróżkach, więc nie jest tragicznie. A wywrotki nie zaliczyłem od kilku lat (deszcz, śliska nawierzchnia i zbyt duża prędkość przy wchodzeniu w zakręt :P) - wtedy najważniejsze aby urządzenie zwyczajnie nie odpadło, a obudowa jest cała zabudowana. Niemniej spotykałem się z przypadkami ludzi korzystających z PDA i nawigacji przyczepionych za pomocą zwykłego uchwytu szczękowego. ;)
Oczywiście, spokojnie można by wykorzystać jakiegoś m100 za 15 zł na Allegro. ;) Z tym, że dla starych Palmów jest już odpowiednie, programowe rozwiązanie. Program zwyczajnie liczy zwarcia dwóch pinów na gniazdku synchronizacyjnych za pomocą kontraktoronu. Działa jedynie na kilku starych modelach Palma (IIIx, Vx i chyba m100, choć do ostatniego nie jestem pewien).
Powiem w ten sposób: Bascom jest bliższy temu co znam - swego czasu sporo czasu poświęciłem na naukę Basica i Turbo Pascala/Delphi. C i Asemblera x86 ruszyłem, ale wtedy mi się właśnie odechciało. :) Poza tym przeczytałem kurs programowania AVR w EDW, więc kiedy będę się brał za to w Bascomie będzie to już dla mnie znany teren, jedynie będę musiał zrobić powtórkę.
Od strony PDA trzeba by napisać coś przechwytującego dane, wyświetlającego je i ewentualnie wrzucającego do pliku. Nie ukrywam, że wolałbym to zrobić w jakimś języku basico lub turbopascalopodobnym. ;) Z tym, że pobieżne googlowanie wyrzuca mi jedynie linki do kursów pisania programów w C dla PalmOSa i WM. ;)
A jak współpracują z peryferiami typu cośtam-na-usb? np. GPS na usb? chyba wówczas pda musi mieć hosta.
Więc po co wyważać otwarte drzwi? ;) tylko dla treningu swoich umiejętności?
Bo to podstawa. Choć są interpretery basica, ale raz że powolne, dwa że duże. Co przy obecnych nowych pda nie ma znaczenia, ale jakbyś chciał wpakować na przykład w Vx, to nazbyt rześkie to nie będzie.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.