Cześć,

...walczę o każdy uA, który zostanie wykorzystany przez moją ATMega88PA. Do komunikacji z innymi elementami systemu używam TWI oraz UART (baud = 19200 - wymuszona wartość). Zasilam układ 3V (bateria) i chcę użyć jak najniższej wartości kwarcu (np. 1MHz), tak aby pobierać jak najmniej energii z baterii.

Z noty katalogowej widzę, że dla 1MHz mam spory błąd transmisji (około 8,5% dla 19200bps) jednak już 1,8432MHz daje mi błąd na poziomie 0,0%. Od razu nasuwa się wniosek, że zewnętrzny kwarc o takiej częstotliwości będzie idealnym rozwiązaniem.
Jednak dodatkowo chcę wprowadzić MCU w stan "Power-Save" i zbudzić go co jakiś czas np. 30 minut poprzez asynchronicznie pracujący TC2. Do tego jednak potrzebuję kwarcu 32,768kHz. Tak więc użycie dwóch rezonatorów nie wchodzi w grę.

Tak więc zastanawiam się czy mógłbym zamiast kwarcu 1,8432MHz użyć oscylatora i podłączyć go (zgodnie z dokumentacją) do XTAL1 itym samym jednocześnie do XTAL1 i XTAL2 kwarc 32,768kHz? Oczywiście CKSEL3...0 ustawione w stan 0000, tak aby to oscylator był głównym źródłem zegara.

Nie mam pod ręką tych elementów i nie mogę tego sprawdzić... czy takie coś zadziała?

Schemat w dokumentacji wskazuje, że dla zewnętrznego źródła XTAL2 powinno być nie podłączone, a w moim przypadku będzie tam jedna nóżka z kwarcu zegarkowego...

nie bardzo kolego ...

możesz sobie dać wewn RC np 8Mhz i pod TOSC podłaczyc zegarkowy i pędzić timer asynchronicznie
jak chcesz 2 kwarcaki na raz .... to się da w większych atmegach np M32 ... ma osobne piny XTAL i TOSC

_________________
Zbuduj swój system [url=https://helion.pl/ksiazki/w-labiryncie-iot-budowanie-urzadzen-z-wykorzystaniem-ukladow-esp8266-i-esp32-andrzej-gromczynski,wlablo.htm#format/d]IOT[/url]

Racja, to co napisałeś (wewnętrzny plus zegarkowy) mi działa i spełnia swoją funkcję...

Czyli tak, jak sądziłem - kwarc plus oscylator to raczej się nie uda w moim procku. Muszę wymyślić jakieś inne rozwiązanie, tak aby jak najbardziej oszczędzić baterię

Twoja sugestia Sun co do innego procesora wydaje mi się słuszna. Nie wiedziałem, że Atmel ma w niektórych 8-bitowych procesorach rozdzielone porty XTAL i TOSC. Już chyba nawet znalazłem to czego szukałem

1. Czas obudzenia procesora zakładam na "co 30 minut" z możliwością jego zmiany, no ale na początek 30 minut wystarczy
2. Urządzenie ma pracować w różnych temperaturach, a zasilanie to bateria (akumulator). Na początek założyłem jej wydajność na 200mAh więc za dużo to nie jest tak wiec to jest powód mojej walki o uA
3. Nie przewiduję używania "watchdog'a", no chyba że coś mi się odmieni
4. Tak, wyłączyłem wszystko co nie było potrzebne i tak jak piszesz wybrałem CPU z picoPower więc miejmy nadzieję, że ATMEL nie kłamie pisząc "pico" o poborze prądu.

Z tego co widzę ATMEGA324PA się nadaje jak najbardziej. Ma dwie part pinów do rezonatorów - główny (dla 1,8432MHz) i dla TC2 w trybie asynchronicznym oraz wspiera picoPower. No i wykresy dość obiecująco pokazują zużycie energii.

Dzięki mokrowski za "wejście" w temat. Moje urządzenia to właśnie takie czujki jak ta Twoja pogodowa.
Widzisz, ja chciałem jak najniżej zejść z poborem mocy, bo chcę zasilać małą baterią. Jak pisałem taką na 200mAh, więc aby działało to parę miesięcy, to fajnie było by mieć pobór prądu na poziomie pojedynczych 'uA'.
Jak pisałem na początku do MCU podłączony jest moduł radiowy, który może pobierać też kilka uA w trybie uśpienia więc jest o co walczyć
Wczoraj robiłem testy z ATMega324PA i jakoś te picoPower na tym procku nie działa... ogólnie wg. noty katalogowej w trybie Power-Sleep ten procesor powinien pobierać jakieś 5uA, a u mnie było aż 500uA! Konfiguracja to:
- czysty procesor, bez dodatkowych obwodów np. LED (DDRx = 0xFF, PORTx = 0x00)
- wyłączone zbędne rzeczy poprzez rejestr PRRx
- kwarc 1,8432MHz + 32kHz dla TC2 w trybie asynchronicznym
- BOD i WatchDog wyłączone (przynajmniej tak mi się wydaje patrząc na Fuse Bity)

Tak w ogóle mokrowski, piszesz o kalibracji kwarcu na podstawie czasu. Czy mógłbyś rozszerzyć tę myśl? Na czym miało by to polegać i po co?

Ja ze swojej strony mogę podpowiedzieć, że przecież ramka RS232 ma swoje dość ostre wymogi co do czasów poszczególnych bitów. Zatem próba dowolnego sposobu dostrajania się do tych czasów to już sposób na kalibrację wewn. oscylatora. Można to wręcz "w locie" robić. W dużym skrócie mówiąc, chodzi o to żeby w zależności od odbieranych danych (czy błędnie czy poprawnie) regulować wewn. oscylator bajtem OSCCAL. Poniekąd opisuję taką prostą kalibrację w Bluebooku ... ale jest na tyle prosta że wymaga terminala i obserwowania wyniku. Tymczasem można po cichu w procku to robić mierząc czas bitów nadsyłanego jakiegoś charakterystycznego znaku, i gdy w końcu się go odbierze to odpowiedzieć do nadajnika - OK ... już widzę znak X ... jestem dostronony! - czekam teraz na właściwe dane ... albo wręcz poprzedzać wysyłanie każdej ramki danych takim znakiem kalibrującym a procek zdąży się zawsze dostosować .... to naprawdę fajnie działa ... wręcz można się dostrajać do dowolnej wtedy prędkości RS232 - w granicach możliwości taktowania procka oczywiście.

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

No tak, racja Mirek, nawet to przerabiałem z Bluebook'a jednak nie używałem w ten sposób jak piszesz - sprawdzę to. Jednak jeśli np. używam wewnętrznego zegara 1MHz (w celu oszczędzenia mocy) i wg. dokumentacji mam błąd dla UART'a na poziomie 8% to raczej nie uda mi się dostroić kwarcu tak, aby był on mniejszy i transmisja się udała, tak?
Jak długo może trwać taka kalibracja? Czas jest liczony w pojedynczych ms czy w s?

wiesz co ? ja nie wiem czy np kolega mokrowski miał to samo na myśli co ja - może ma jeszcze inny i ciekawy sposób więc poczekajmy aż powie ze dwa zdania .... bo jak widać sporo fajnych rzeczy na forum podpowiada ...

ja w skrócie powiem, że dla mnie to trochę spory temat gdybym miał go omówić tu w szczegółach dlatego będzie on jednym z mniejszych ale mam nadzieję ciekawych tematów mojej trzeciej książki jeśli się ukaże - ale nie ma problemu abym spróbował cię chociaż naprowadzić

otóż trwa to tak szybko że kalibracja trwa tyle, że zmieścisz się czasowo pomiędzy jednym a drugim przesyłanym znakiem przez RS232. Ja do tego celu zaprzęgłem np zewnętrzne przerwanie INTx oraz jeden z Timerów 8-bitowych. Czyli wejście RX podłączyłem do wejścia INTx i w tym przerwaniu dokonuję pomiaru czasu jakiejś charakterystycznej ramki a następnie wyliczam potrzebne mi UBBR dopasowując się wręcz do nadlatującego baudrate - niezależnie od taktowania ... tzn tfuuu no niezupełnie niezależnie od taktowania bo rzeczywiście przy 1MHz to z prędkościami większymi sobie nie poszalejemy ale dla tych niższych jak 9600 czy nawet pewnie 19200 dałoby radę jak myślę - ale przyznam że nie testowałem sobie tego na 1MHz. Co ciekawe udało mi się to spokojnie zrealizować w czystym C, choć na początku myślałem że będę musiał sięgnąć po wstawkę asemblerową .... Z tym że moja koncepcja była taka że przed każdą przesyłaną ramką RS232 musiałem na jej początku dokładać ten jeden bajt/znak synchronizacyjny ..... uuuuf nawet w skrócie a musiałem się rozpisać ... ale mam nadzieję, że chociaż wstępnie drogę dostrzegasz

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

tak, tak widzę już tą idee. Poczekajmy jeszcze co napisze mokrowski
Małe pytanko... piszesz Mirek, że podłączasz RX do INTx. Rozumiem, że te samo RX jest podłączone do peryferyjnego układu... coś na wzór załączonego rysunku?

DOKŁADNIE tak pin Rx procka do INTx a na wejście RX procka .... podawany jest sygnał Tx z układu zewnętrznego ...

------------------------ [ Dodano po: 1 minucie ]

ale jeszcze będę testował sobie później wersję bez tego podprowadzania do INTx tylko sprawdzę na procku typu m88 czy uda się zaprząc do tego przerwanie PCINT istniejące na tym samym pinie procka alternatywnie

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

o! to było by niezłe, sam jestem ciekaw jak to jest z wykorzystaniem dwóch alternatywnych funkcji na jednym pinie.
Daj znać jak będą efekty, chociaż sam tez pokuszę się o sprawdzenie.

Dość ciekawa koncepcja morkowski i dzięki za dokumentację. Spróbuje to zastosować jeśli będzie taka potrzeba. W tym momencie wymyśliłem dość fajne wyjście z mojej sytuacji... będę zmieniał częstotliwość wewnętrznego oscylatora poprzez rejestr CLKPR. W moim przypadku mam ten problem, że mój układ radiowy, wyjęty z pudełka ma ustawioną prędkość na 19200bps. Tak więc, aby mój MCU działał z jak najniższą częstotliwością (pobierał jak najmniej prądu w stanie Active) muszę także obniżyć prędkość nadawania.
Czyli na początku będzie pracował na 8MHz i 19200bps, późnej zmniejszę obsługiwaną prędkość w module radiowym na 9600bps i tym samym częstotliwość mojego MPU do 1MHz... z ewentualną korekcją o której piszesz.
Czyli będę mógł zmienić dużego ATMega324 na jakiś mniejszy - byle by miał rejestr CLPR i inne potrzebne mi rzeczy... i chyba to będzie już działało

Sądzę, że poprawnie go uśpiłem, widzę przejście z 4mA na 0,4mA przy zaśnięciu. Tak więc też mnie to zdziwiło, gdyż na ATMega88PA było poprawnie - jak w dokumentacji, okolice 1uA.
Jeśli chodzi o radio to oczywiście, mam tam też usypianie. Na wszystkim mam zamiar oszczędzać, aby wyszło jak najwydajniej

Takie jeszcze małe pytanko...

Rozumiem, że jeśli mam zewnętrzny kwarc 32,768kHz to ustawienia rejestrów TCCR2B (preskaler) i OCR2A (licznik) w ATMega88PA robi się dla tej właśnie częstotliwości - 32kHz, tak? Nie ma wpływu na to częstotliwość wewnętrzna 8MHz czy np. 1MHz?

Pytam, bo widzę że coś mi powyższe zdanie nie jest prawdziwe i zastanawiam się dlaczego...

Oczywiście - tryb asynchroniczny włączony...



...i dalej wywołanie w main.c


Timer1 jest zliczany w klasycznym przerwaniu...


Tak więc ogólnie z tego co widzę, dla 1MHz wartość OCR2A = 32 powoduje zliczanie do 10s i w tym czasie MCU jest w stanie uśpienia. Ta sama wartość dla 8MHz skraca ten czas do jakichś 3s - 4s...?

Jak to widzisz?