Zegar dwunastodiodowy w oparciu o ATmega8 i DS1307

Wstęp

Główną przyczyną powstania tej konstrukcji była nuda oraz chęć zweryfikowania, jak poczciwa ATmega8 radzi sobie z software'ową realizacją PWM na wielu wyjściach jednocześnie. Żeby nie było nudno, postanowiłem, że urządzenie powinno mieć śladowe oznaki użyteczności - wybór padł więc na zegar pseudoanalogowy.


Opis konstrukcji

Urządzenie, jak już wspomniałem wcześniej, zostało oparte na mikrokontroler ATmega8. Dwanaście diod (osiem diod czerwonych i cztery zielone) służą do wyświetlania aktualnego czasu w następujący sposób:
- dioda, która świeci się stałym mocnym światłem, wskazuje aktualną godzinę,
- dioda, która miga z częstotliwością ok. 0,5 Hz, oznacza aktualną minutę (przeskok z jednej diody na drugą oznacza upływ pięciu minut),
- pozostałe diody lekko się jarzą, co ułatwia odczyt czasu w nocy.
Realizacja poziomu jasności realizowana jest za pomocą modulacji PWM.

Zielone diody wyróżniają godziny będące wielokrotnością liczby 3 (3, 6, 9 i 12). Na schemacie można zauważyć, że do podłączenia ich do mikrokontrolera zastosowałem rezystory o mniejszej wartości (4k7) niż do diod czerwonych (10k). Spowodowane jest to faktem, że oko ludzkie jest bardziej wrażliwe na światło czerwone, a więc żeby uzyskać wrażenie równomiernego świecenia wszystkich diod, diody zielone powinny świecić z większą mocą.

Warto też wspomnieć o miłym dodatku w postaci wyświetlania krótkich animacji w przypadku wystąpienia nowej godziny - to taki wizualny odpowiednik kukułki w zegarze z kukułką. W chwili obecnej zaimplementowanych jest pięć różnych animacji - wszystkie w mniejszym lub większym stopniu korzystają z dobrodziejstw PWM.

ATmega8 wykorzystuje wewnętrzny oscylator RC pracujący na częstotliwości ok. 8 MHz. Wiadomo, że oscylator RC nie nadaje się do bycia wzorcem czasu. W projekcie wzorcem jest kwarc 32 kHz podłączony do układu RTC DS1307. Układ ten zapewnia również ciągłe odmierzanie czasu w przypadku utraty głównego zasilania urządzenia. Zasilaniem zastępczym jest bateria litowa 3V.

Firmware został napisany w języku C. Starałem się stworzyć w miarę ogólne API, które pozwalałoby na zmianę rozstawu pinów na poziomie hardware'u bez znacznej ingerencji w software. Ucierpiała na tym jednak wydajność całego programu - w chwili obecnej program nie spełnia swoich zakładanych funkcji, o ile nie jest skompilowany z opcją -O3 (toolchain avr-gcc), co wymusza od kompilatora maksymalny poziom optymalizacji.

Zarówno schemat ideowy urządzenia, jak i kod źródłowy firmware'u, dostępne są w postaci załączników.



Podsumowanie

Koszt wykonania całego projektu nie powinien przekroczyć 50 zł:
- ATmega8 - ok. 10zł
- 12 LEDów - ok. 3zł
- uniwersalne PCB - ok. 15zł
- pudełko - ok. 10 zł
- DS1307 - ok. 7zł
- drobnica w postaci odrobiny termokleju do klejenia diod do obudowy, cyny, itp. jest trudna do oszacowania, ale raczej nie nadwyręży domowego budżetu

Z konstrukcji jestem raczej zadowolony, trochę mniej z firmware'u. Doszedłem do smutnego wniosku, że w przypadku embedded nie ma często miejsca na pisanie zgeneralizowanego i abstrakcyjnego kodu.

Czyli chce kolega powiedzieć, że mierzymy czas z dokładnością +- 5 minut :d. Osobiście ten zegar nie podoba mi się, z racji dużej obudowy, brak jakiegokolwiek "wyrazu", jednak skoro poćwiczył kolega Timery i PWM to + dla autora.

Nawet prosty projekt przynosi dużo satysfakcji

Drobna uwaga:

linuxtorpeda napisał:

ATmega8 wykorzystuje wewnętrzny oscylator RC pracujący na częstotliwości ok. 8 MHz. Wiadomo, że oscylator RC nie nadaje się do bycia wzorcem czasu. W projekcie wzorcem jest kwarc 32 kHz podłączony do układu RTC DS1307. Układ ten zapewnia również ciągłe odmierzanie czasu w przypadku utraty głównego zasilania urządzenia. Zasilaniem zastępczym jest bateria litowa 3V.

Twój projekt można było rozwiązać znacznie prościej:
- zastosować ATmega8A lub ATmega8L (możliwość pracy od 2,7V),
- kwarc 32,768kHz podłączyć do Timer2 pracujący w trybie asynchronicznym,
- usypiać mikrokontroler do trybu Pover Save, w którym łącznie z włączonym Timer2 mikrokontroler pobiera zaledwie około 10µA.

W ten sposób zrealizujesz programowo to samo, co sprzętowo za pomocą DS1307.

@KKonradev2
Nie, nie mierzymy czasu z dokładnością 5 minut, 5 minut to dokładność, z jaką możemy czas odczytać. Czas jest mierzony na tyle dokładnie, na ile pozwala kwarc, czyli typowo +/- 15 sekund na miesiąc. Ja na co dzień posługuję się terminami typu "kwadrans po pierwszej" lub "za pięć dwunasta", więc nie przeszkadza mi to, że zegara nie mogę używać jako stopera.

@dondu
DS1307 przy odcięciu głównego zasilania pobiera z baterii typowo ok. 300nA, czyli jakieś 30 razy mniej niż 10uA.

linuxtorpeda napisał:

@dondu
DS1307 przy odcięciu głównego zasilania pobiera z baterii typowo ok. 300nA, czyli jakieś 30 razy mniej niż 10uA.

Zgadza się, ale Twój zegar w stanie zasilania z baterii nie przebywa prawie nigdy - zasilanie to jest tylko na wszelki wypadek:

linuxtorpeda napisał:

Zasilaniem zastępczym jest bateria litowa 3V.

Policzmy więc ile czasu ATmega w zaproponowanym przeze mnie przykładzie mogłaby pracować na baterii którą zastosowałaś, czyli CR2032?:

244mAh / 10µA = 24400h = 1016 dni = 2,78 roku

Należałoby oczywiście jeszcze odjąć ilość mocy traconej co 8 sekund (bo w trybie zasilnia z baterii nie trzeba odmierzać co sekundę) wzrost poboru prądu ułamek sekundy więc dla zaokrąglenia przyjmijmy, że były by to 2 lata.

@dondu
Jaki by nie był czas działania ATmegi na tej baterii, to z użyciem DS1307 urządzenie będzie funkcjonowało dłużej - w tym przypadku spokojnie ponad 60 lat. Przewiduję, że zegar może czasem znaleźć się na strychu przez dłuższy okres - dobrze by było, żeby w takim przypadku również funkcjonował. Można się czepiać tylko tego, że nie stosuję żadnej metody korekty czasu, co przy tak długim planowanym działaniu może być problemem.

linuxtorpeda napisał:

... w tym przypadku spokojnie ponad 60 lat.

Czy wiesz co to jest upływność lub samorozładowanie baterii?
Czy sprawdziłeś jaka jest wartość tego parametru i jak to wpłynie na 60 lat, które przytoczyłeś?
http://mikrokontrolery.blogspot.com/2011/01/bateria-zasila-mikrokontroler-czesc-3.html

Pomijam już fakt, że gdyby Twój projekt mógł cudownym zrządzeniem praw fizyki działać na DS przy zasilaniu CR2032 przez 60 lat, to czas wskazywany nie miałby nic wspólnego z rzeczywistością, bo zastosowany kwarc ma dokładność rzędu 20-30ppm i w dodatku starzeje się ±5 ppm/rok:
http://mikrokontrolery.blogspot.com/2011/04/stopery-timery-itp.html

linuxtorpeda napisał:

Przewiduję, że zegar może czasem znaleźć się na strychu przez dłuższy okres - dobrze by było, żeby w takim przypadku również funkcjonował.

Dobieramy irracjonalny przykład by bronić swoją tezę?

linuxtorpeda napisał:

Można się czepiać ...

Oj kolego czytaj co napisałem w pierwszym poście - broniłem Ciebie przed częściowo negatywną oceną kol. KKonradev2

dondu napisał:

Nawet prosty projekt przynosi dużo satysfakcji

a następnie dopisałem:

dondu napisał:

Drobna uwaga: ...

Jeśli więc takie postępowanie uznajesz za czepianie się, to nie publikuj swoich projektów.

linuxtorpeda napisał:

... że nie stosuję żadnej metody korekty czasu, co przy tak długim planowanym działaniu może być problemem.

Nie jest to żadnym problemem w przypadku, gdy masz pełnię władzy nad programem.

Reasumując:
- nie dostrzegaj krytyki tam gdzie jej nie ma,
- zastanawiaj się nad tym co piszą nieco bardziej doświadczeni koledzy,
- czytaj dokumentacje stosowanych elementów,
- DS1307 itp. przydaje się w projektach, w których nie ma innej możliwości realizacji zegara asynchronicznego.

Nie przekonują mnie Twoje argumenty, ale dziękuję za opinię.

Za moich młodych lat musiałem być skromnym by fachowcy mnie czegokolwiek nauczyli, trzeba było stulić uszy po sobie i nauczyć się pokory.

A jak to się ma do zegara?

W jakim środowisku napisałeś ten program? I w jakim systemie operacyjnym? Chociaż to drugie pytanie jest chyba, sądząc po nicku, pytaniem retorycznym

Jeśli dobrze pamiętam, to moim środowiskiem developerskim było Eclipse + AVR-Plugin do Eclipse'a + avr-gcc + avrdude. No a system operacyjny - jedyny słuszny, czyli Linux, konkretniej mówiąc ArchLinux. Sam projekt powstał rok temu w wakacje z nudów, zajął mi około 15 godzin (projektowanie schematu + montaż + programowanie - łącznie trzy dni po kilka godzin dziennie). Wahałem się między ATmegami a PICami (bo mam sporo mikroklocków z obydwu rodzin), ale wybrałem ATmegi z kilku względów, o których nie chce mi się rozpisywać Polecam jednak obie rodziny.

Przyłączając się do tematu chciałbym zapytać o parę spraw:

1. Zakładając że chciałbym zrealizować asynchroniczne taktowanie timera T1 w trybie uśpienia Power Save to w jaki sposób podłączyć kwarc ?
Wiem narazie tylko tyle że w przypadku gdy chcemy uC taktować zewnętrznym sygnałem to można podczepić kwarc do pinów XTAL1 i XTAL2 równolegle dając do tych pinów kondensatorki których drugie końce podłączone są do masy. Ale tutaj są dwa wyprowadzenia, natomiast do taktowania zewnętrznego takich rzeczy jak T0 i T1 jest po jednym wyprowadzeniu , mam rację ? Jeśli tak, jak to się podpina ?

2. Czy można byłoby wykonać dokładny zegar w ten sposób że mikrokontroler taktowany byłby z wewnętrznego oscylatora RC , natomiast licznik T1 z wejścia asynchronicznego do którego podłączony byłby wspomniany kwarc ? Pytanie zadaję już w kontekście "synchronizacji" o której tylko słyszałem...
Czy ma to coś wspólnego z różną dokładnością oscylatorów (wewnętrznego RC i zew.kwarcu) lub też z ich różną częstotliwością ?
Jeśli ktoś nie rozumie tego pytania to niech odpowie zamiast tego na pytanie jakie trudności programistyczne mogą się pojawić dla średnio zaawansowanego delikwenta takiego jak ja jeśli podejmie się realizacji tego typu układu zaproponowanego m.in. przez Donda.

3. Każdy kwarc nastawiony jest na jakąś częstotliwość. Pytanie brzmi jaką częstotliwością maksymalną mogę taktować licznik T1 Atmega8 asynchronicznie ?
Czy częstotliwość kwarcu ma wpływ na jego dokładność, jeśli tak - dlaczego nie dać większego/mniejszego ?

Uprzejmie prosiłbym o wyrozumiałość jeśli chodzi o nieścisłość zadawanych przeze mnie pytań.

Ad 1 i 3:
Jeśli pytasz o ATmega8, to timerem asynchronicznym jest (jak napisałem powyżej) Timer2. Posiada on dedykowany temu kwarcowi (32,768kHz) oscylator. W przypadku tego mikrokontrolera niestety piny XTAL i TOSC są tymi samymi pinami. W innych przypadkach np. ATmega32 piny te są wydzielone więc można dwa kwarce podłączyć.

Szczegóły w tym zakresie: http://mikrokontrolery.blogspot.com/2011/03/A...AVR-Oscylatory-kwarcowe-kwarc-ceramiczne.html

Ad 2. Możesz oczywiście taktować mikrokontroler z wewnętrznego generatora RC, a Timer2 z kwarcu.

AdamZad napisał:

... jakie trudności programistyczne mogą się pojawić dla średnio zaawansowanego delikwenta takiego jak ja jeśli podejmie się realizacji tego typu układu zaproponowanego m.in. przez Donda.

Żadne, to banalnie proste rozwiązanie

PS.
Dondu, nie Donda

Uzupełniając to, co napisał dondu:

Ad. 1. i Ad. 3.
Na zewnętrzne wejścia T0/T1 możesz zapodać sygnał cyfrowy, który stanie się sygnałem zegara dla timerów 0/1. Sygnał musi być na tyle wolny, by dał się spróbkować przez mikrokontroler - szczegóły w dokumentacji.
Warto zauważyć różnicę pomiędzy zewnętrznym sygnałem zegarowym a zewnętrznym elementem (np. kwarcem), który skutkuje tym, że mikrokontroler działa z określoną częstotliwością - kwarc/rezonator ceramiczny i zewnętrzne kondensatory są jedynie elementami generatora częstotliwości, którego pozostała część jest zabudowana w mikrokontrolerze - de facto na żadnym z pinów XTAL1 i XTAL2 nie ma sygnału cyfrowego w czasie wykorzystywania kwarcu jako elementu regulującego częstotliwość pracy całego układu.
Częstotliwość kwarcu nie ma wpływu na dokładność zliczania impulsów na wejściu T1, dopóki trzymasz się zaleceń, tzn. żaden impuls nie zostanie pominięty przy zliczaniu (natomiast może być wykryty w różnym momencie od wystąpienia, co nie ma w zasadzie znaczenia).

Ad. 2.
Do T1 nie podepniesz kwarcu. Wyjaśnienie wyżej. Jeśli chcesz zrobić dokładny zegar, taktując jednocześnie procka z innego wzorca niż timer, musisz na pinie T1 zapewnić dokładny sygnał zegarowy, np. z jakiegoś generatora kwarcowego, zegara atomowego, itp. Problem z wewnętrznym generatorem RC polega na tym, że jego parametry różnią się dość znacznie w zależności od egzemplarza mikrokontrolera, temperatury i wieku układu oraz nie ma możliwości jego kalibracji o dokładności wystarczającej do zbudowania zegarka. Generator oparty o kwarc jest znacznie mniej zależny od ww. czynników, choć nadal można poprawić jego parametry przez np. zapewnienie mu stałej temperatury pracy - kwarce stabilizowane temperaturowo również są dostępne na rynku

Co do trudności przy realizacji projektu - prawdopodobnie przeszkodą może być znajomość angielskiego, czytanie dokumentacji to podstawa, materiały nt. AVRów po polskiej stronie internetu są niestety dość słabe (chociaż akurat do zbudowania zegarka powinny być wystarczające). Warto zainteresować się układami scalonymi z funkcją RTC, wyręczają programistę w żmudnym liczeniu czasu, nowsze układy tego typu potrafią po kalibracji kompensować błędy wykorzystanego kwarcu.

Uprzejmie dziękuję kolegom za odpowiedzi.
Przeanalizowałem temat, mam dodatkowe pytania:

1. W procku np. Tiny2313 nie ma nóg opisanych jako TOSC a zatem nie ma i możliwości asynchronicznego taktowania licznika (poprawcie mnie jeśli się mylę)
Czy można zatem (zakładając że ktoś na chama chce taki procek mieć jako zegarek) zbudować sobie samemu taki oscylator (z kwarcu zegarkowego, rezystora, dwóch kondensatorów i z dwóch inwerterów) i uzyskany sygnał zegarowy podłączyć do wyprowadzenia T0 tak aby timer zliczał te impulsy (zakładając że taktowany byłby z wewnętrznego oscylatora RC o częstotliwości rzędu MHz) ? Myślę, że mogłoby to stanowić wzorzec czasu....

2. Linuxtorpeda napisał że "Sygnał musi być na tyle wolny, by dał się spróbkować przez mikrokontroler" - dlaczego ? Nie miałem dziś czasu przejrzeć dokumentacji, obiecuję że przejrzę ale ciekawość mnie zżera już teraz! Pomocy!
Czy ma to coś wspólnego z pojęciem "synchronizacji" ?

3. Linuxtorpeda napisał że "Częstotliwość kwarcu nie ma wpływu na dokładność zliczania impulsów na wejściu T1, dopóki trzymasz się zaleceń, tzn. żaden impuls nie zostanie pominięty przy zliczaniu (natomiast może być wykryty w różnym momencie od wystąpienia, co nie ma w zasadzie znaczenia).". Czy będzie tak wówczas jeśli częstotliwość taktowania zegara będzie przynajmniej dwukrotnie wyższa niż częstotliwość sygnału na wejściu T1 ? (tw.Shannona Kotielnikowa?). I czy to ma związek z punktem nr 2 ? Poprawcie mnie jeśli się mylę.

4. Zakładając że chciałbym zrobić w miarę dokładny zegarek i zakładając że chciałbym mieć możliwość przełączania z zasilania sieciowego na baterię aby nie gubił godziny i zakładając że chciałbym wygaszać wszystkie segmenty jeśli brakło by sieciówki, to czy wówczas potrzebuję jedno dodatkowe wejście (pin) zagospodarować pod sygnał obecności zasilania sieciowego ? Czy można to jakoś inaczej rozwiązać ? Jakieś pomysły ?

5. Czy proponowana przez kolegę Dondu koncepcja usypiania do trybu power save wiąże się z tym że będziemy wybudzać go z tego trybu po zliczeniu przez timer odpowiedniej ilości impulsów ? Czy z tego trybu (power save) uśpienia wybudzić można sygnałem od timera (np.przepełnienie). Czy ten tryb podobny jest pod tym względem do Idle w innych prockach czy to jeszcze coś innego. Narazie znam tryby Power Down, Idle Mode i Active. I czy w trybie Power Save bufory wejściowe portów są aktywne czy nieaktywne ?

6. I ostatnia sprawa:
załóżmy że potrzebuję :
- zrobić zegarek dokładny z użyciem kwarcu zegarkowego około 32 kHz a zatem albo podłączam pod TOSC1 TOSC2 albo robię generator jak opisałem w pkt 1 a zatem albo używam 2 nóg procka albo 1.
- 1 pin do resetu
- minimum 2 piny do zasilania (czasem trzy bo masa jest podwójna)
- 2 piny do wejść (mode/set)
- 1 pin do rozpoznania czy idzie z baterii czy z sieciówki (zgodnie z pytaniem pkt 4)
- 12 pinów wyjściowych (7 segmentów 1 kropka i 4 na anody segmentów)
Razem : od 18 do 21 pinów (tzn nóg) procka - uzależnione od odpowiedzi na powyższe pytania i od poprawności moich domysłów...

Wiem że Atmega8 idealnie się by nadała do tego ale może jest coś optymalniejszego jeśli chodzi o pole wyboru mikrokontrolera AVR ?
Bo po co mi np. przetwornik ADC tutaj, po co mi aż 28 pinów tutaj, po co mi EEPROM, PWM (to się w sumie może przydać na ściemnianie wyświetlacza...) itd...
Coś tam już przeglądałem ale zwracam się z prośbą do speców o podpowiedzi...

Nie obraźcie się ale chciałbym w miarę szybko przyswoić wiedzę i dlatego nie doczytuję dokumentacji. Obiecuję że jak odpowiecie to doczytam!!! Zresztą sam tego chcę! Proszę Was o zrozumienie!!!! Jest 2:04 - siedzę nad tym już 14 godzinę dzisiaj - dlatego nie doczytałem.

Ad 1. Skaczesz po procesorach, ze trudno nadążyć
ATtiny2313 nie ma TOSC, bo nie ma Timera2 pracującego asynchronicznie,
Możesz oczywiście zrobić własny generator i podłączyć do T0, ale wtedy uśpisz ATtiny jedynie do trybu Idle przez co będzie zużywał sporo prądu. Ale jeśli to nie jest projekt zasilany z baterii, to nie ma znaczenia.

Ad 2. i 3. http://mikrokontrolery.blogspot.com/2011/04/jak-mikrokontroler-widzi-sygnal-cyfrowy.html


Ad 4. Jakoś musisz stwierdzić, że napięcie zasilające zostało odcięte. Dlatego jakiś pin + program muszą o to zbadać.

Ad 5. Tak Timer2 wybudzi mikrokontroler przerwaniem. Zobacz tabelkę trybów wybudzenia oraz opis trybu Pover Safe w rozdziale: Power Management and Sleep Modes
W przypadku Power Save dodatkowo zobacz wykresy w dziale: Electrical Characteristic


Ad 6. Jeśli to projekt zasilany z baterii, to nie ma sensu robić zewnętrznego generatora, bo będzie zapewne zużywał więcej energii niż wbudowany oscylator Timer2.

Jeżeli brakuje Ci jednego pinu, to w takiej sytuacji należy szukać oszczędności w pozostałej części projektu lub wybrać inny mikrokontroler. Atmega8 to tylko jeden z wielu AVR, i nie da się odpowiedzieć na Twoje pytanie nie znając dokładnie projektu.

Często bowiem bywa tak, że te projekt jest zrealizowany w sposób nieoptymalny i niewykorzystujący wielu sprzętowych możliwości danego mikrokontrolera. Czasami jest także tak, że zmiana procesora na inny pozwala rozwiązać projekt od strony sprzętowej znacznie prościej. Innymi słowy, w 99% przypadków dobieramy mikrokontroler do projektu a nie odwrotnie.

Nie obrażamy się, tylko w nocy czasami śpimy

Witam serdecznie,

Doczytałem ostatnio to czego nie doczytałem wcześniej, temat mi się znacznie bardziej rozjaśnił. Potrzebuję aby ktoś lepszy potwierdził co ustaliłem:

Do budowy zegara użyję:
Timer2 AtMega8 taktowany asynchronicznie z oscylatora wewnętrznego (low freq. osc.) stabilizowanego zewnętrznym kwarcem 32,768kHz podłączanym pod piny TOSC1 i TOSC2 bezpośrednio i to bez kondensatorów będzie poprzez odpowiednie wykorzystanie preskalera mógł być ustawiony na odmierzanie każdej jednej sekundy.
Przerwanie od przepełnienia (co 1 sek.) wybudzałoby mi ewentualnie uśpiony procek (uśpiony będzie tylko wówczas gdy będzie ciągnąć z baterii przy odłączonej sieciówce) z trybu Power Save, inkrementowałoby odpowiednie zmienne (sekund, minut, godzin) i w zależności od tego czy miałby zasilanie bateryjne czy sieciówkę byłby ponownie usypiany albo nie.

Mam jednak pytanie co do obsługi przerwania od przepełnienia T2.
Najchętniej chciałbym w procedurze przerwania (odpalanej automatycznie dokładnie co 1 sek.) inkrementować zmienne (godz., min i sek) ale również opcjonalnie (jeśli jest to konieczne - czyli gdy mamy sygnał o zaniku napięcia sieciowego) wprowadzać procek do trybu Power Save.
Pytanie brzmi : czy muszę się przejmować obowiązującymi zasadami opisywanymi na str.117 i 118 dok.Atmega8 bo wygląda na to że ja nie muszę zmieniać trybu pracy tego licznika ani rejestrów TCCR2, OCR2 i TCNT2 (ustawiam na samym początku programu tylko).

Dobrze myślę koledzy ?

Jeśli nie zmieniasz źródła zegara, to opisane zalecenia nie dotyczą Twojego problemu.

Zrób zegarek tak, jak umiesz. Jeśli będzie działał tak, jak sobie wymarzyłeś, to znaczy, że zrobiłeś go dobrze.

Zrobię, zrobię. Mam już gotowy schemat układu ale jeszcze nie będę wrzucał bo chciałbym zaprezentować naszą konstrukcję (robię go wspólnie z ojcem) w całości a nie we fragmentach. Jak zbuduję - wrzucę także linka na tego posta do wglądu.

Napiszcie mi narazie tylko jeszcze jedno.

Czy poza Atmegą8 i Atmegą32 jest jeszcze jakiś inny AVR mający taką fajną funkcję jak możliwość podpięcia kwarcu zegarkowego oraz to aby pracował na nim w trybie asynchronicznym ?

... nie będę przecież sprawdzał dokumentacji w kontekście każdego z procków Atmela... stąd ta prośba...

Ja też na pamięć nie znam możliwości konkretnych modeli, tak więc jednak proponuję skorzystanie z dokumentacji.

AdamZad napisał:

Przerwanie od przepełnienia (co 1 sek.)

Jeśli masz taką potrzebę możesz co 1 sekundę, ale jeśli nie musisz, to wykorzystaj timer do końca i wybudzaj co 8 sekund

AdamZad napisał:

Czy poza Atmegą8 i Atmegą32 jest jeszcze jakiś inny AVR mający taką fajną funkcję jak możliwość podpięcia kwarcu zegarkowego oraz to aby pracował na nim w trybie asynchronicznym ?

... nie będę przecież sprawdzał dokumentacji w kontekście każdego z procków Atmela... stąd ta prośba...

No pewnie, że nie będziesz
Wykorzystaj wyszukiwarkę: http://goo.gl/OBeZdo
Wybierasz rodzinę w kolumnie CPU oraz zaznaczasz tylko Yes w kolumnie 32kHz RTC i wsio.
Powyższy link prowadzi od razu do tak zawężonych wyników jak opisałem wyżej