zewnętrzne, usypianie i bud

Użytkownik "Atlantis" snipped-for-privacy@wp.pl napisał w wiadomości news:kf63bu$c0q$ snipped-for-privacy@portraits.wsisiz.edu.pl...

idle - cpu nie pracuje. liczniki liczą, uart pracuje, program nie jest wykonywany, pojawiajace sie przerwanie budzi mikrosterownik, wykonuje dane przerwanie i wznawia wykonywanie następnego kodu po instrukcji sleep.

prawdopodobnie tak jak piszesz dane sa tracone bo uart nie pracuje, dokladnie nie pamietam należało by przeczytać manual.

dokładnie następna instrukcja po sleep. (lub przerwanie trzeba popatrzeć do manuala aczkolwiek to zazwyczaj bez znaczenia)

tak. ale tez nalezy zobaczyć do manuala z szczególnym uwzglednieniem erraty. (tych trybów jest kilka i troche różnie na różnych prockach działają).

pozdrawiam mm

W dniu 2013-02-09 19:47, michal pisze:

Każde przerwanie, dobrze rozumiem? Czyli jeśli USART mi coś wyśle, to po wykonaniu funkcji obsługi przerwana odbioru znaku program rozpocznie normalne działanie, nawet jeśli funkcja sama w sobie nie będzie zawierała instrukcji wybudzenia?

Chcę po prostu upewnić się, czy moje rozumienie tematu jest poprawne, zanim zabiorę się za pisanie kodu. Generalnie program ma być uśpiony przez większość czasu. Budzić mają go dwa zdarzenia:

W funkcji main znajduje się nieskończona pętla. W niej dwie instrukcje warunkowe. Jedna sprawdza obecność stanu niskiego na RI, druga podniesienie słuchawki. Dopóki warunki te są spełnione, w pętlach wykonują się właściwe operacje.

Za instrukcjami warunkowymi, na końcu nieskończonej pętli znajduje się instrukcja wprowadzająca moduł w stan uśpienia, tak więc po następnym wybudzeniu sprawdzanie zacznie od następnej iteracji nieskończonej pętli.

Tak to powinno wyglądać czy coś pomieszałem?

Mi akurat chodzi o zwykłą Atmegę8. ;)

Nie.

1. Wszystkie takie podstawowe szczegóły masz opisane w datasheet. Naprawdę.
2. Zależne jest to mocno do konkretnego modelu procka AVR, są różne poziomy sleep.

Więc datasheet ad atmega8. Tam naprawdę wszystko jest. Rozdział "Power management and sleep modes", jest tam opisane które części uC działają w danym trybie uśpienia, i które przerwania wybudzą go z konkretnego poziomu snu. Jest nawet ładna tabelka.

W dniu 2013-02-10 13:43, DJ pisze:

Właśnie czytałem, ale wciąż nie mam całkowitej pewności jak interpretować ten fragment:

"Idle mode enables the MCU to wake up from external triggered interrupts as well as internal ones like the Timer Overflow and USART Transmit Complete interrupts."

Skłaniałbym się raczej ku interpretacji, w myśl której w obsłudze przerwania USART mogę umieścić instrukcję budzenia (wyzerowanie odpowiednich bitów w MCUCR). Ale czy samo wystąpienie przerwania spowoduje wyjście ze stanu uśpienia?

Czy uśpiony procek realizuje program? (tak rozumiem to co napisałeś) Powyższy fragment mówi że np USART w trybie uśpienia wysyła dane z bufora i po zakończeniu transmisji może obudzić program

przy INT0/1 jest notka, że budzenie poziomem.

Nie musisz. On już jest obudzony sprzętowo.

Tak, i tylko tak. Po obudzeniu wykonuje kod spod wektora przerwania który spowodował "pobudkę", a po jego zakończeniu wraca do miejsca gdzie usnął, wykonuje kolejne rozkazy.

Podchwytliwe pytanie, to i podchwytliwa odpowiedź: Realizuje program? Tak. Wykonuje rozkazy i zmienia ProgramCounter? Nie. MSPANC :)

W dniu 2013-02-10 18:26, DJ pisze:

Tylko poziomem? A jeśli przerwanie INT0/INT1 ustawię np. tak, żeby reagowało na opadające zbocze i w funkcji wyzeruję bity MCUCR - obudzi się?

Note that if a level triggered interrupt is used for wake-up from Power-down mode, the changed level must be held for some time to wake up the MCU. This makes the MCU less sensitive to noise. The changed level is sampled twice by the watchdog oscillator clock.

Więc pewnie z tego powodu do budzenia musi być poziom, nie zbocze.

A tabelkę oglądałeś? W idle można zboczem, reszta trybów snu - poziomem.

W dniu 2013-02-10 18:40, DJ pisze:

Dobrze, w takim razie jeszcze jedno pytanie. Jak właściwie wygląda próbkowanie tego poziomu? Powiedzmy, że ustawiam INT0 i INT1 na wykrywanie stanu niskiego. Na liniach pojawia się logiczne zero trwające kilka sekund, a nawet całe minuty. Kiedy i ile razy wykona się przerwanie?

Dnia Sun, 10 Feb 2013 18:34:44 +0100, Atlantis napisał(a):

Jak procek bedzie dobrze uspiony, to w "w funkcji przerwania" nie nastapi :-) A jesli nastepuje, to juz jest obudzony.

Problem z przerwaniem na zbocze jest taki, ze ta funkcja jest czesto realizowana, jakby to okreslic ... mikroprogramowo ? Pin jest probkowany w okreslonym momencie cyklu zegarowego, i wewnetrzna logika rozpoznaje zbocze jak stan ulegl zmianie od poprzedniej probki. Ale w tym celu zegar musi dzialac, przynajmniej w ukladzie przerwan.

No i czas impulsu musi byc odpowiednio dlugi ... i uwaga przy zegarze o zmiennej czestotliwosci. To samo zreszta przy "level"

J.

Wiesz jak jest konkretnie realizowana w Atmedze?

Wybudzanie za pomocą zbocza robi się w najprostszej postaci za pomocą 2 przerzutników D w szeregu. Jak D1 XOR D2 == 1 to masz zbocze. Filtrowanie to zazwyczaj długa linia opóźniająca i stan "połówki" jest obliczany według większości bitów (np bufor na 14 bitów wycina pojedyncze zakłócenie do 3 cykli).

Ze względu m.i. na pobór prądu we współczesnych procesorach prawie wszystko jest synchronizowane zegarem.

Musi być dlatego, że w power down główny zegar jest zatrzymany. W idle nie jest.

BTW jeszcze jedno pytanie przyszło mi do głowy: Jak zachowuje się watchdog w stanie idle? Z dokumentacji wynika, że jest włączony, jednak skoro program się nie wykonuje, to nie ma co go resetować. A jeśli tak, to uC powinien zostać zrestartowany natychmiast po wprowadzeniu w stan idle z aktywnym watchdogiem. A to nie miałoby najmniejszego sensu... Więc jak to wygląda w rzeczywistości?

Tak musisz program przemyśleć żeby miał okazję resetować watchdoga, jako objaw normalnej pracy. Np przerwaniami z timerów, czy czegokolwiek innego co występuje zawsze częściej niż okres watchdoga. Jeśli chcesz uśpić uC na amen na 30 minut, bo np po takim czasie przjdzie Ci INT0/1, to watchdoga w tym czasie użyć nie możesz.

A jeśli tak, to uC powinien zostać zrestartowany natychmiast po wprowadzeniu w stan idle z aktywnym watchdogiem.

czemu _natychmiast_? ustawiasz czas reakcji watchdoga na 0.00000000usec ;P

W dniu 2013-02-20 23:56, DJ pisze:

Czyli tak jak myślałem... Czy w takim razie duże jest zagrożenie zawieszeniem się uC w trybie uśpienia?

Oj, skrót myślowy. Miałem na myśli perspektywę człowieka, a nie maszyny. ;)

Jeżeli projekt jest poprawnie zaprojektowany to nie istnieje ryzyko "zawieszenia".

Przykład 1 - Czytasz dane z GPS po UART i zapisujesz na kartę.

- Procesor po starcie resetuje zewnętrzne urządzenia i przeprowadza inicjalizację.

- Procesor przechodzi w tryb IDLE.

- Przerwania UART powodują pakowanie bajtów do bufora i sparsowanie wiadomości po \n.

- Przerwanie zegarowe rozpoczyna zapis na kartę po SPI.

- Przerwania obsługują transmisję po SPI.

- Jeżeli nie będzie przez dłuższy czas komunikacji od GPS, albo zamrze komunikacja z kartą watchdog wywoła reset pozwalając.

Szablon wygląda +- tak: main(){ if(watch_dog_reset){ report_error(); GPS->force_reset(); CARD->force_reset(); } GPS->setup(); CARD->setup(); //... for(;;) sleep(); }

Przykład 2 - czekasz na naciśnięcie przycisku i otwierasz zamek jeżeli się zgadza karta.

- Procesor po starcie resetuje zewnętrzne urządzenia i przeprowadza inicjalizację.

- Procesor przechodzi w tryb STANDBY.

- Jedynym zdarzeniem na które czeka procesor jest przycisk, więc wd jest wyłączony.

- W czasie kiedy następuje komunikacja z kartą włączasz wd.

Szablon wygląda +- tak: main(){ if(watch_dog_reset){ report_error(); cleanup(); } BTN1->setup();

for(;;){ sleep(); wd_enable(); CARD->setup(); if(CARD->verify_access()){ DOOR->open(); busy_wait(); DOOR->close(); } wd_disable(); } }