AVR - przerwania zewnętrzne, usypianie i budzenie

Atlantis

unread,

Feb 9, 2013, 1:08:56 PM2/9/13

to

Po przeczytaniu odpowiedniego rozdziału podręcznika programowania AVR-ów
wciąż mam kilka wątpliwości, które chciałbym rozwiać:

1) Co tak właściwie dzieje się po wprowadzeniu mikrosterownika w stan
uśpienia? Jakie operacje będą wykonywane, a jakie nie? Załóżmy, że przy
pomocy rejestru MCUCR konfiguruję tryb ilde, w którym aktywna jest
większość modułów. Mam rozumieć, że wywołanie funkcji sleep_mode
spowoduje zatrzymanie wykonywania operacji w głównej funkcji programu,
ale wciąż będą wykonywane funkcje obsługi przerwań czynnych modułów, np.
USART, nawet jeśli nie zawierają one instrukcji wybudzenia mikrosterownika?
2) Co się stanie w przypadku wprowadzenia mikrosterownika w tryb
power-down, podczas gdy do portu USART podłączone jest aktywne
urządzenie? Do momentu wybudzenia mikrosterownika np. przez INT0
przesyłane dane będą po prostu przepadały, czy też taka sytuacja stwarza
jakieś zagrożenie dla uC albo podłączonego modułu?
3) Po wybudzeniu układu (np. przez przerwanie zewnętrzne) w którym
miejscu program wznawia swoją pracę? Dokładnie tam, gdzie znajdował się
przed uśpieniem, czy w jakimś innym punkcie?
4) Rozumiem, że w stanie uśpienia wszystkie wyłączone moduły (liczniki,
PWM) zachowują swoją konfigurację i po wybudzeniu automatycznie
rozpoczynają przerwaną pracę?

michal

unread,

Feb 9, 2013, 1:47:14 PM2/9/13

to

Użytkownik "Atlantis" <marekw19...@wp.pl> napisał w wiadomości
news:kf63bu$c0q$1...@portraits.wsisiz.edu.pl...

> Po przeczytaniu odpowiedniego rozdziału podręcznika programowania AVR-ów
> wciąż mam kilka wątpliwości, które chciałbym rozwiać:
>
> 1) Co tak właściwie dzieje się po wprowadzeniu mikrosterownika w stan
> uśpienia? Jakie operacje będą wykonywane, a jakie nie? Załóżmy, że przy
> pomocy rejestru MCUCR konfiguruję tryb ilde, w którym aktywna jest
> większość modułów. Mam rozumieć, że wywołanie funkcji sleep_mode spowoduje
> zatrzymanie wykonywania operacji w głównej funkcji programu, ale wciąż
> będą wykonywane funkcje obsługi przerwań czynnych modułów, np. USART,
> nawet jeśli nie zawierają one instrukcji wybudzenia mikrosterownika?

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.

> 2) Co się stanie w przypadku wprowadzenia mikrosterownika w tryb
> power-down, podczas gdy do portu USART podłączone jest aktywne urządzenie?
> Do momentu wybudzenia mikrosterownika np. przez INT0 przesyłane dane będą
> po prostu przepadały, czy też taka sytuacja stwarza jakieś zagrożenie dla
> uC albo podłączonego modułu?

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

> 3) Po wybudzeniu układu (np. przez przerwanie zewnętrzne) w którym miejscu
> program wznawia swoją pracę? Dokładnie tam, gdzie znajdował się przed
> uśpieniem, czy w jakimś innym punkcie?

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

> 4) Rozumiem, że w stanie uśpienia wszystkie wyłączone moduły (liczniki,
> PWM) zachowują swoją konfigurację i po wybudzeniu automatycznie
> rozpoczynają przerwaną pracę?

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

Atlantis

unread,

Feb 9, 2013, 2:27:38 PM2/9/13

to

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

> 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.

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?

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

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:
1) Pojawienie się sygnału dzwonka (linia RI współpracującego modułu GSM)
2) Podniesienie słuchawki telefonicznej.
Linie podpięte są odpowiednio do INT0 i INT1. Przerwania wyzwalane
pojawieniem się stanu niskiego (a może zbocze odpadające byłoby lepszym
pomysłem?). Wewnątrz obsługujących je funkcji znajduje się tylko
instrukcja wybudzenia.

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?

> (tych trybów jest kilka i trochę różnie na różnych prockach działają).

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

DJ

unread,

Feb 10, 2013, 7:43:56 AM2/10/13

to

On 2013-02-09 20:27:38 +0100, Atlantis <marekw19...@wp.pl> said:

> Każde przerwanie, dobrze rozumiem?

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.

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

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.

--
DJ

PS. przy odpisywaniu na priv usun antyspamowy wpis z adresu

Atlantis

unread,

Feb 10, 2013, 11:58:36 AM2/10/13

to

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

> Więc datasheet ad atmega8. Tam naprawdę wszystko jest.

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?

AlexY

unread,

Feb 10, 2013, 12:04:38 PM2/10/13

to

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

--
AlexY
http://nadzieja.pl/inne/spam.html
http://www.pg.gda.pl/~agatek/netq.html

DJ

unread,

Feb 10, 2013, 12:26:33 PM2/10/13

to

On 2013-02-10 17:58:36 +0100, Atlantis <marekw19...@wp.pl> said:

> W dniu 2013-02-10 13:43, DJ pisze:
>
>> Więc datasheet ad atmega8. Tam naprawdę wszystko jest.
>
> 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."

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

> 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).

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

> Ale czy samo wystąpienie przerwania spowoduje wyjście ze stanu uśpienia?

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.

Atlantis

unread,

Feb 10, 2013, 12:34:44 PM2/10/13

to

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

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

> (...)

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

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ę?

DJ

unread,

Feb 10, 2013, 12:33:06 PM2/10/13

to

On 2013-02-10 18:04:38 +0100, AlexY <al...@irc.pl> said:

> Atlantis wrote:
>> W dniu 2013-02-10 13:43, DJ pisze:
>>
>>> Więc datasheet ad atmega8. Tam naprawdę wszystko jest.
>>
>> 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ś)

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

DJ

unread,

Feb 10, 2013, 12:40:53 PM2/10/13

to

On 2013-02-10 18:34:44 +0100, Atlantis <marekw19...@wp.pl> said:

> W dniu 2013-02-10 18:26, DJ pisze:
>
>> przy INT0/1 jest notka, że budzenie poziomem.
> > (...)
>> Nie musisz. On już jest obudzony sprzętowo.
>
> Tylko poziomem?

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.

DJ

unread,

Feb 10, 2013, 12:54:27 PM2/10/13

to

On 2013-02-10 18:34:44 +0100, Atlantis <marekw19...@wp.pl> said:

> W dniu 2013-02-10 18:26, DJ pisze:
>
>> przy INT0/1 jest notka, że budzenie poziomem.
> > (...)
>> Nie musisz. On już jest obudzony sprzętowo.
>
> Tylko poziomem?

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

Atlantis

unread,

Feb 10, 2013, 1:21:43 PM2/10/13

to

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

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

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?

J.F.

unread,

Feb 10, 2013, 1:37:37 PM2/10/13

to

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

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

>> przy INT0/1 jest notka, ďż˝e budzenie poziomem.
>> (...)
>> Nie musisz. On juďż˝ jest obudzony sprzďż˝towo.
>
> 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ďż˝?

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.

Marek

unread,

Feb 10, 2013, 7:10:19 PM2/10/13

to

On Sun, 10 Feb 2013 19:37:37 +0100, "J.F."
<jfox_x...@poczta.onet.pl> wrote:
> Problem z przerwaniem na zbocze jest taki, ze ta funkcja jest czesto
> realizowana, jakby to okreslic ... mikroprogramowo ?

Wiesz jak jest konkretnie realizowana w Atmedze?

--
Marek

Michoo

unread,

Feb 10, 2013, 9:02:56 PM2/10/13

to

On 10.02.2013 19:37, J.F. wrote:

> Dnia Sun, 10 Feb 2013 18:34:44 +0100, Atlantis napisał(a):
>> W dniu 2013-02-10 18:26, DJ pisze:

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

>>> Nie musisz. On już jest obudzony sprzętowo.
>>
>> 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ę?
>

> 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 ?

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).

> 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.

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

--
Pozdrawiam
Michoo

Adam Wysocki

unread,

Feb 11, 2013, 5:51:46 AM2/11/13

to

DJ <johnny12-...@poczta.onet.pl> wrote:

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

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

--
Gof
http://www.chmurka.net/

Atlantis

unread,

Feb 20, 2013, 5:15:52 PM2/20/13

to

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?

DJ

unread,

Feb 20, 2013, 5:56:41 PM2/20/13

to

On 2013-02-20 23:15:52 +0100, Atlantis <marekw19...@wp.pl> said:

> 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ć.

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

Atlantis

unread,

Feb 21, 2013, 12:46:31 PM2/21/13

to

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

> 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.

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

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

Oj, skrďż˝t myďż˝lowy. Miaďż˝em na myďż˝li perspektywďż˝ czďż˝owieka, a nie maszyny. ;)

Michoo

unread,

Feb 21, 2013, 6:26:44 PM2/21/13

to

On 21.02.2013 18:46, Atlantis wrote:
> W dniu 2013-02-20 23:56, DJ pisze:
>
>> 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.
>
> Czyli tak jak myďż˝laďż˝em... Czy w takim razie duďż˝e jest zagroďż˝enie
> zawieszeniem siďż˝ uC w trybie uďż˝pienia?

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();
}
}
--
Pozdrawiam
Michoo

Atlantis

unread,

Feb 22, 2013, 1:00:27 PM2/22/13

to

W dniu 2013-02-22 00:26, Michoo pisze:

> Przykďż˝ad 1 - Czytasz dane z GPS po UART i zapisujesz na kartďż˝.
> - Procesor po starcie resetuje zewnďż˝trzne urzďż˝dzenia i przeprowadza
> inicjalizacjďż˝.

No cďż˝... Mi chodziďż˝o o sytuacjďż˝ odwrotnďż˝ - UNIKNIďż˝CIE resetowania
zewnďż˝trznego urzďż˝dzenia (moduďż˝) GSM i napisanie kodu w taki sposďż˝b, ďż˝eby
ATmega po ewentualnym restarcie sama zorientowaďż˝a siďż˝ gdzie stoi.

Zaďż˝ďż˝my, ďż˝e sam uC (ale nie modem) wiesza siďż˝ w trakcie aktywnej rozmowy
telefonicznej. Watchdog go restartuje, ale moduďż˝ GSM dziaďż˝a dalej (co
najwyďż˝ej chwilowo tracďż˝c komunikacjďż˝ z Atmegďż˝).

Procedura inicjacji moduďż˝u jest tak napisana, ďż˝eby radziďż˝ sobie z
sytuacjďż˝, kiedy natknie siďż˝ na juďż˝ zainicjowany moduďż˝ - wtedy zostawia
go w spokoju spokoju.

W pďż˝tli znajduje siďż˝ instrukcja sprawdzajďż˝ca podniesienie sďż˝uchawki.
Jeďż˝li sďż˝uchawka zostanie podniesiona (lub program po wďż˝ďż˝czeniu natknie
siďż˝ na podniesionďż˝ sďż˝uchawkďż˝) wykonuje siďż˝ seria instrukcji (m.in.
wybudzenie moduďż˝u). Potem odwoďż˝ujďż˝ siďż˝ do funkcji, ktďż˝ra wysyďż˝a
"AT+CPAS\r\n" na potem czeka na ciďż˝g +:CPAS: 00". Gdy ciďż˝g siďż˝ pojawi
funkcja oczekuje jeszcze na ostatniďż˝ cyferkďż˝ i zwraca wartoďż˝ďż˝
odpowiadajďż˝cďż˝ znakowi ASCII.

Dalej jest instrukcja switch(), ktďż˝ra w zaleďż˝noďż˝ci od zwrďż˝conej wartoďż˝ci
podejmuje odpowiednie dziaďż˝anie:
- Jeďż˝li moduďż˝ zgďż˝osiďż˝ gotowoďż˝ďż˝ - uruchomienie procedury wybierania numeru.
- Jeďż˝li moduďż˝ zgďż˝osiďż˝ poďż˝ďż˝czenie przychodzďż˝ce - odebranie odebranie go i
uruchomienie procedury obsďż˝ugujďż˝cej rozmowďż˝
- Jeďż˝li moduďż˝ zgďż˝osiďż˝ juďż˝ aktywne poďż˝ďż˝czenie (poprzednia sesja,
przerwana przez reset) - uruchomienie procedury obsďż˝ugujďż˝cej poďż˝ďż˝czenie.

Michoo

unread,

Feb 22, 2013, 3:00:12 PM2/22/13

to

On 22.02.2013 19:00, Atlantis wrote:
> W dniu 2013-02-22 00:26, Michoo pisze:
>
>> Przykďż˝ad 1 - Czytasz dane z GPS po UART i zapisujesz na kartďż˝.
>> - Procesor po starcie resetuje zewnďż˝trzne urzďż˝dzenia i przeprowadza
>> inicjalizacjďż˝.
>
> No cďż˝... Mi chodziďż˝o o sytuacjďż˝ odwrotnďż˝ - UNIKNIďż˝CIE resetowania
> zewnďż˝trznego urzďż˝dzenia (moduďż˝) GSM i napisanie kodu w taki sposďż˝b, ďż˝eby
> ATmega po ewentualnym restarcie sama zorientowaďż˝a siďż˝ gdzie stoi.

Ale czemu atmega miaďż˝a siďż˝ zresetowaďż˝?

>
> Zaďż˝ďż˝my, ďż˝e sam uC (ale nie modem) wiesza siďż˝ w trakcie aktywnej rozmowy
> telefonicznej.

Oznacza to:
a) bďż˝ďż˝d w programie. naleďż˝y go wyeliminowaďż˝
b) bďż˝ďż˝d w module albo zakďż˝ďż˝cenie w komunikacji. stan systemu jest
prawdopodobnie niespďż˝jny. Twardy reset jest w takiej sytuacji
najbezpieczniejszym wyjďż˝ciem.

> Watchdog go restartuje, ale moduďż˝ GSM dziaďż˝a dalej (co
> najwyďż˝ej chwilowo tracďż˝c komunikacjďż˝ z Atmegďż˝).

>
> Procedura inicjacji moduďż˝u jest tak napisana, ďż˝eby radziďż˝ sobie z
> sytuacjďż˝, kiedy natknie siďż˝ na juďż˝ zainicjowany moduďż˝ - wtedy zostawia
> go w spokoju spokoju.

Ja bym w takim wypadku zrobiďż˝ sprawdziďż˝ na ile stan wyglďż˝da "dobrze" i w
rzie czego zrobiďż˝ power-cycle. Skoro byďż˝ reboot to znaczy, ze coďż˝ siďż˝
powaďż˝nie spieprzyďż˝o. Nic ci nie gwarantuje, ďż˝e moduďż˝ bďż˝dzie po czymďż˝
takim pracowaďż˝ poprawnie. (Ktďż˝reďż˝ telefony tak miaďż˝y, ďż˝e po padzie
komunikacji robiďż˝y soft reset podsystemu GSM, w efekcie wszystko
wyglďż˝daďż˝o ok (zasiďż˝g, sieďż˝, etc), tylko moduďż˝ nie sygnalizowaďż˝
przychodzďż˝cych poďż˝ďż˝czeďż˝.)

>
> W pďż˝tli znajduje siďż˝ instrukcja sprawdzajďż˝ca podniesienie sďż˝uchawki.
> Jeďż˝li sďż˝uchawka zostanie podniesiona (lub program po wďż˝ďż˝czeniu natknie
> siďż˝ na podniesionďż˝ sďż˝uchawkďż˝) wykonuje siďż˝ seria instrukcji (m.in.
> wybudzenie moduďż˝u). Potem odwoďż˝ujďż˝ siďż˝ do funkcji, ktďż˝ra wysyďż˝a
> "AT+CPAS\r\n" na potem czeka na ciďż˝g +:CPAS: 00". Gdy ciďż˝g siďż˝ pojawi
> funkcja oczekuje jeszcze na ostatniďż˝ cyferkďż˝ i zwraca wartoďż˝ďż˝
> odpowiadajďż˝cďż˝ znakowi ASCII.

foo:
Czekasz na
+:CPAS: 00
a dostajesz
+:CPAS: 01 (albo jeszcze lepiej 05, bo wybudzenie siďż˝ nie powiodďż˝o)
watchdag robi reset, goto foo.

>
> Dalej jest instrukcja switch(), ktďż˝ra w zaleďż˝noďż˝ci od zwrďż˝conej wartoďż˝ci
> podejmuje odpowiednie dziaďż˝anie:
> - Jeďż˝li moduďż˝ zgďż˝osiďż˝ gotowoďż˝ďż˝ - uruchomienie procedury wybierania numeru.
> - Jeďż˝li moduďż˝ zgďż˝osiďż˝ poďż˝ďż˝czenie przychodzďż˝ce - odebranie odebranie go i
> uruchomienie procedury obsďż˝ugujďż˝cej rozmowďż˝
> - Jeďż˝li moduďż˝ zgďż˝osiďż˝ juďż˝ aktywne poďż˝ďż˝czenie (poprzednia sesja,
> przerwana przez reset) - uruchomienie procedury obsďż˝ugujďż˝cej poďż˝ďż˝czenie.

A jeďż˝eli zgďż˝osiďż˝ 1,2,5?

--
Pozdrawiam
Michoo

Atlantis

unread,

Feb 23, 2013, 2:59:43 AM2/23/13

to

W dniu 2013-02-22 21:00, Michoo pisze:

> Ale czemu atmega miaďż˝a siďż˝ zresetowaďż˝?

W powodu watchdoga?
Moďż˝e inaczej. Czy przypadkiem mikrokontrolerowi nie zdarza siďż˝ czasem
(choďż˝by niezmiernie rzadko) zawiesiďż˝ siďż˝, tak po prostu zaprzestaďż˝
pracy? Jeďż˝li tak, to chodzi mi wďż˝aďż˝nie o ochronďż˝ przed takďż˝ sytuacjďż˝.

Bo rozumiem, ďż˝e czasem jakiďż˝ niuans w samym kodzie (np. pďż˝tla, ktďż˝ra w
okreďż˝lonych okolicznoďż˝ciach zacznie siďż˝ wykonywaďż˝ w nieskoďż˝czonoďż˝ďż˝) moďż˝e
spowodowaďż˝ zawias, ale to na razie pomijam.

> Oznacza to:
> a) bďż˝ďż˝d w programie. naleďż˝y go wyeliminowaďż˝
> b) bďż˝ďż˝d w module albo zakďż˝ďż˝cenie w komunikacji. stan systemu jest
> prawdopodobnie niespďż˝jny. Twardy reset jest w takiej sytuacji
> najbezpieczniejszym wyjďż˝ciem.

Dla jasnoďż˝ci: nigdy takiej sytuacji nie miaďż˝em. Nie zdarzyďż˝o mi siďż˝,
ďż˝eby moduďż˝ albo uC siďż˝ zawiesiďż˝. Wszystkie przypadki, kiedy coďż˝ dziaďż˝aďż˝o
nieprawidďż˝owo okazywaďż˝y siďż˝ efektem jakiegoďż˝ drobnego bďż˝ďż˝du w programie.

A co do twardego resetu, to modem D15 nie ma nawet odpowiedniego pinu.
Jedynym rozwiďż˝zaniem z tego co widzďż˝ jest odciďż˝cie zasilania, a to mogďż˝
zrobiďż˝ rďż˝cznie.

> Ja bym w takim wypadku zrobiďż˝ sprawdziďż˝ na ile stan wyglďż˝da "dobrze" i w
> rzie czego zrobiďż˝ power-cycle. Skoro byďż˝ reboot to znaczy, ze coďż˝ siďż˝
> powaďż˝nie spieprzyďż˝o. Nic ci nie gwarantuje, ďż˝e moduďż˝ bďż˝dzie po czymďż˝
> takim pracowaďż˝ poprawnie.

Proces inicjacji moduďż˝u GSM oczywiďż˝cie przeprowadza elementarnďż˝
diagnostykďż˝, nawet jeďż˝li zastanie go w stanie wďż˝ďż˝czonym. Jeďż˝li coďż˝ jest
nie tak, zgďż˝asza kod bďż˝ďż˝du migajďż˝c diodďż˝. Trochďż˝ "diagnostyki" jest teďż˝
po podniesieniu sďż˝uchawki - pytanie o status, sprawdzenie poziomu
sygnaďż˝u itp. Sďż˝owem raczej moďż˝na siďż˝ poďż˝apaďż˝, gdy coďż˝ nie dziaďż˝a.

> foo:
> Czekasz na
> +:CPAS: 00
> a dostajesz
> +:CPAS: 01 (albo jeszcze lepiej 05, bo wybudzenie siďż˝ nie powiodďż˝o)
> watchdag robi reset, goto foo.

Tak swojďż˝ drogďż˝ co zwraca "+CPAS: 001" gdy modem jest niedostďż˝pny albo
"+CPAS: 005" gdy znajduje siďż˝ w stanie uďż˝pienia, skoro przecieďż˝ jest
niedostďż˝pny albo znajduje siďż˝ w stanie uďż˝pienia? ;)
Tutaj chyba chodzi o jakieďż˝ bardzo specyficzne sytuacje?
W funkcji sprawdzajďż˝cej o stan modemu umieďż˝ciďż˝em po prostu licznik.
Funkcja zwraca odpowiedniďż˝ wartoďż˝ďż˝, gdy program nie otrzyma odpowiedzi
przed upďż˝ywem 500 ms. Jeszcze tego nie zagospodarowaďż˝em, ale myďż˝laďż˝em o
zwykďż˝ym komunikacie bďż˝ďż˝du.

> A jeďż˝eli zgďż˝osiďż˝ 1,2,5?

Jeszcze niezagospodarowane, ale to kwestia dodania kolejnego "case"
wewnďż˝trz instrukcji switch(). Jak juďż˝ mďż˝wiďż˝em funkcja odpowiedzialna za
obsďż˝ugďż˝ CPAS czeka po prostu aďż˝ przyjdzie staďż˝a czďż˝ďż˝ komunikatu (+CPAS:
00) a potem czeka na pojawienie siďż˝ ostatniej cyferki, pobiera jďż˝,
konwertuje z ASCII na liczbďż˝ i zwraca programowi.

Michoo

unread,

Feb 23, 2013, 6:54:08 AM2/23/13

to

On 23.02.2013 08:59, Atlantis wrote:
> W dniu 2013-02-22 21:00, Michoo pisze:
>

>> Ale czemu atmega miała się zresetować?
>
> W powodu watchdoga?

To jest skutek równoważny z - "dlaczego watchdog zadziałał" - bo coś go
nie zresetowało, ale dlaczego?

> Może inaczej. Czy przypadkiem mikrokontrolerowi nie zdarza się czasem
> (choćby niezmiernie rzadko) zawiesić się, tak po prostu zaprzestać
> pracy?

Po odliczeniu błędów zasilania - nie. [1] To by oznaczało, że nie można
go bezpiecznie używać.

[1] W teorii możesz mieć przypadek w którym jakiś błąd jest zależny od
czasu i temperatury, ale prawdopodobieństwo jest minimalne. W praktyce
zdarza się czasami jakiś błąd w przerwaniach (na krzemie) i w określonym
przypadku procesor się nie budzi, ale to będzie raczej tylko missed
interrupt a nie zwis, w bardzo specyficznych warunkach (no i trafi do
erraty). Może też oberwać cząstką wysokoenergetyczną, ale to raczej na
orbicie.

> Jeśli tak, to chodzi mi właśnie o ochronę przed taką sytuacją.

Taka sytuacja byłaby nielogiczna - na co komu urządzenie, które się
losowo zawiesza?

Załóżmy, że masz szansę na zadziałanie w cyklu 6σ - to by oznaczało, że
procesor lecący na 20MHz zawiesza się średnio co 25 sekund...

> Bo rozumiem, że czasem jakiś niuans w samym kodzie (np. pętla, która w
> określonych okolicznościach zacznie się wykonywać w nieskończoność) może
> spowodować zawias, ale to na razie pomijam.

Błędnie - to jest jedyne z czym się będziesz musiał mierzyć w typowych
przypadkach.

>
>
>> Oznacza to:
>> a) błąd w programie. należy go wyeliminować
>> b) błąd w module albo zakłócenie w komunikacji. stan systemu jest
>> prawdopodobnie niespójny. Twardy reset jest w takiej sytuacji
>> najbezpieczniejszym wyjściem.
>
> Dla jasności: nigdy takiej sytuacji nie miałem. Nie zdarzyło mi się,
> żeby moduł albo uC się zawiesił. Wszystkie przypadki, kiedy coś działało
> nieprawidłowo okazywały się efektem jakiegoś drobnego błędu w programie.

Oczywiście. Weź tylko pod uwagę, że moduł to też jakiś uC z jakimś
oprogramowaniem.

>
> A co do twardego resetu, to modem D15 nie ma nawet odpowiedniego pinu.

PMOS na zasilaniu.

> Jedynym rozwiązaniem z tego co widzę jest odcięcie zasilania, a to mogę
> zrobić ręcznie.

W sprzęcie bateryjnym trochę z tym gorzej - dlatego robi się obwód
resetu na długim przytrzymaniu włącznika.

>
>
>> Ja bym w takim wypadku zrobił sprawdził na ile stan wygląda "dobrze" i w
>> rzie czego zrobił power-cycle. Skoro był reboot to znaczy, ze coś się
>> poważnie spieprzyło. Nic ci nie gwarantuje, że moduł będzie po czymś
>> takim pracował poprawnie.
>
> Proces inicjacji modułu GSM oczywiście przeprowadza elementarną
> diagnostykę, nawet jeśli zastanie go w stanie włączonym.

A co robi jeżeli uC zwisł w trakcie komunikacji? (Wysłał pół polecenia,
przyszło przerwanie, gdzieś nie było volatile i resetuje się w momencie
gdzie moduł dostał jakieś śmieci?)

> Jeśli coś jest
> nie tak, zgłasza kod błędu migając diodą.

Jest to jedno z podejść "skontaktuj się z serwisem". Drugim jest
"spróbujemy się zrestartować".

>
> Tak swoją drogą co zwraca "+CPAS: 001" gdy modem jest niedostępny albo
> "+CPAS: 005" gdy znajduje się w stanie uśpienia, skoro przecież jest
> niedostępny albo znajduje się w stanie uśpienia? ;)

Moduł. Moduł składa się z:
- radia
- modemu
- uC, który nim steruje
(czasami w jednym scalaku)

A spora część współczesnych SoC ma odrębne bloki funkcjonalne z
niezależnym wejściem zegara i asynchroniczne moduły komunikacyjne po to,
żeby cała reszta mogła spać.

>
>> A jeżeli zgłosił 1,2,5?

>
> Jeszcze niezagospodarowane, ale to kwestia dodania kolejnego "case"

> wewnątrz instrukcji switch().

No tak, ale właśnie w ten sposób - przez zostawienie nieobsłużonych
przypadków - tworzy się zawieszające się urządzenia. Dobra praktyka -
zawsze dajesz default a jak nie wiesz co tam wstawić to wstawiasz
logowanie błędu + reset.

> Jak już mówiłem funkcja odpowiedzialna za
> obsługę CPAS czeka po prostu aż przyjdzie stała część komunikatu (+CPAS:
> 00) a potem czeka na pojawienie się ostatniej cyferki, pobiera ją,
> konwertuje z ASCII na liczbę i zwraca programowi.

A co w momencie gdy przyjdzie zakłócenie i zamiast cyferki przyjdzie coś
niezrozumiałego?

--
Pozdrawiam
Michoo

Atlantis

unread,

Feb 23, 2013, 11:50:41 AM2/23/13

to

W dniu 2013-02-23 12:54, Michoo pisze:

> Po odliczeniu błędów zasilania - nie. [1] To by oznaczało, że nie można
> go bezpiecznie używać.

> (...)

> Załóżmy, że masz szansę na zadziałanie w cyklu 6σ - to by oznaczało, że
> procesor lecący na 20MHz zawiesza się średnio co 25 sekund...

Chodziło mi raczej o znacznie, znacznie rzadsze przypadki. Kiedy uC
pracuje non stop. Założyłem, że w pewnym momencie może wystąpić jakaś
"sprzętowa" przyczyna zawieszenia i w związku z tym stosowanie watchdoga
ma sens.

> Błędnie - to jest jedyne z czym się będziesz musiał mierzyć w typowych
> przypadkach.

Rozumiałem przez to "pomijam w tych rozważaniach" a nie "pomijam w całym
projekcie udając, że zagadnienie nie istnieje". ;)

> W sprzęcie bateryjnym trochę z tym gorzej - dlatego robi się obwód
> resetu na długim przytrzymaniu włącznika.

Sprzętowy włącznik też przecież można zainstalować. ;)

> A spora część współczesnych SoC ma odrębne bloki funkcjonalne z
> niezależnym wejściem zegara i asynchroniczne moduły komunikacyjne po to,
> żeby cała reszta mogła spać.

Z tego co wyczytałem w dokumentacji, to w D15 działa to trochę inaczej.
Żeby wybudzić moduł ze stanu uśpienia trzeba wysłać jakikolwiek, krótki
ciąg znaków i odczekać 30ms. Wysłana wiadomość przepada. Dopiero potem
można nawiązać właściwą komunikację.

> No tak, ale właśnie w ten sposób - przez zostawienie nieobsłużonych
> przypadków - tworzy się zawieszające się urządzenia. Dobra praktyka -
> zawsze dajesz default a jak nie wiesz co tam wstawić to wstawiasz
> logowanie błędu + reset.

Nieobsłużony jest w tej chwili, bo jak na razie nie mam nawet wykonanych
połączeń, które umożliwiłyby mi przeprowadzenie resetu modułu z poziomu
mikrosterownika.

> A co w momencie gdy przyjdzie zakłócenie i zamiast cyferki przyjdzie coś
> niezrozumiałego?

Przedstawione rozwiązanie było tymczasowym. Teraz wyciągam liczbę za
pomocą sscanf(). Przy czym rzecz jasna przed zakłóceniem w komunikacji
przez USART mnie to nie obroni. Jak będzie miało dojść do przekłamania,
to do niego dojdzie. Jeśli zastosuję twoje rozwiązanie - całe urządzenie
się wtedy zrestartuje.
Jeśli zrobię to po mojemu - dioda zamiga informując mnie, że coś jest
nie tak. Odłożę słuchawkę i spróbuję podnieść ją ponownie.

Jak widać każda filozofia ma swoje złe i dobre strony. ;)