Identyfikacja przyczyny resetu a AVR

Dnia 25.11.2006 JS_WP snipped-for-privacy@wp.pl napisał/a:

MCUCSR resjestr prawdę Ci powie... (przynajmniej w tych nowszych avr'ach).

Maciej Wywrocki napisał(a):

Bez sensu tak na piechotę. Po to jest MCUCSR aby z niego korzystać. Poza tym tak samo prawdopodobne jest pojawienie się w RAMie po włączeniu zasilania w sprawdzanym miejscu 32-bitowej losowej wartości 0x84936349, co każdej innej, w tym twojej "magicznej" flagi.

Co wiecej, ze wzgledu na budowe pamieci (a AVR jest SRAM, czy DRAM?) bardziej jest prawdopodobne, ze po powrocie zasilania pojawi sie owa magiczna sygnaturka niz dowolna inna wartosc.

Maciej Wywrocki napisał(a):

W przypadku tego procesora powód resetu jest dostępny w rejestrze MCUSR, patrz opis bitu WDRF.

A jeżeli nie AVRy to napisz, o czym mowa. Zdecydowana większość różnej produkcji mikrokontrolerów posiadających wewnętrzny watchdog pozwala na programowe stwierdzenie, czy reset był spowodowany zadziałaniem watchdoga.

Może nie trafić. I właśnie w takich przypadkach byłoby niemożliwe odróżnienie resetu watchdogiem (gdy zawiesi się program) od krótkiego padu zasilania. A w ATtiny26 możesz w MCUSR sprawdzić bity WDRF (reset od watchdoga), BORF (od spadku zasilania), EXTRF (naciśnięcie resetu zewnętrznego) i PORF (włączenie zasilania).

Może chcieli bardzo uniwersalnie go zrobić, aby pasował do każdej '51. Mimo to zawsze warto sprawdzić, jakie są możliwości konkretnego procesora, który chcesz zastosować.