Czy rejestry AVR i porty muszą być inicjowane do zera?

Podczas procedury inicjalizacji mojego kodu używam do takich rzeczy jak:

clr    r0  ; will always stay zero

out    PORTA, r0; initialize ports
out    DDRA, r0
out    PORTB, r0
...

Czy to jest rzeczywiście konieczne? Czy mogę być pewien, że nastąpi to automatycznie po zresetowaniu? W szczególności, czy mogę polegać na domyślnym ustawieniu wszystkich portów jako danych wejściowych, aby nie było problemu z głosowaniem zewnętrznym, gdy żaden kod nie jest wykonywany?

— Stefan Paul Noack
źródło

Odpowiedzi:

Porty we / wy AVR są ustawione na INPUT / Tri-State / Hi-Z (DDRx = 0x00) po zresetowaniu. Większość mikrokontrolerów (jeśli nie wszystkie?) Ma takie zachowanie. Jest to najbezpieczniejszy stan dla pinów. Więc tak, możesz polegać na portach ustawianych automatycznie jako wejścia.

Niektóre fragmenty ATmega16 pokazują dokładnie, że:

wprowadź opis zdjęcia tutaj

Styki portu C są trzykrotnie określane, gdy stan resetowania staje się aktywny, nawet jeśli zegar nie działa.

— m.Alin
źródło

Właśnie tego szukałem :)

— Stefan Paul Noack,

o ile pamiętam, jeśli pozostawisz wejście zmiennoprzecinkowe, dostaniesz na nim losowy szum, więc stan początkowy może wynosić zero, to dobrze, ale może stać się niezerowy po pierwszym cyklu zegara.

— miceuz

@miceuz Nie chodzi o to, aby dane wyjściowe były w nieznanym stanie . Mogą mieć niepożądany wpływ na obwód zewnętrzny podłączony do mikrokontrolera

— m.Alin

@miceuz masz na myśli rejestry portów wejściowych, prawda? mają one N / A jako stan początkowy (co ma sens, ponieważ odzwierciedlają tylko to, co jest zastosowane do pinu). Ale miałem na myśli rejestry kierunku danych. Chciałem się tylko upewnić, że przypadkowo nie ustawiłem portu jako wyjścia, być może powodującego konflikt z napięciami przyłożonymi do pinu.

— Stefan Paul Noack,

o tak, naprawdę przepraszam za hałas ..

— miceuz

Inicjalizacja portu ZAWSZE jest dobrym pomysłem, niezależnie od tego, co mówi karta danych.
Jeśli arkusz danych nic nie mówi, jest to absolutnie niezbędny pomysł.

Musisz tylko zdefiniować zawartość danych portu, jeśli zależy Ci na tym, co stanie się po uruchomieniu programu.

Jeśli nie zależy ci na wyniku, nie musisz ustawiać bitów danych portu :-).

Jeśli producenci wyraźnie stwierdzają w arkuszach danych, że bity danych portu są ustawione lub wyczyszczone, mogą być, ALE to i tak naprawdę naprawdę dobry pomysł, aby je zainicjować. „Warunki brzegowe” są tam, gdzie większość rzeczy idzie źle - np. Początek pętli, koniec pętli, okrągły punkt owinięcia bufora, ... Uruchamianie procesora jest równoważne sprzętowo. W prawdziwym świecie, w którym panuje hałas, usterki i ludzie, bycie odpowiedzialnym za losy swoich programów jest naprawdę dobrym pomysłem. Inicjalizacja portu jest łatwą częścią tego.

— Russell McMahon
źródło

W pełni uzgodnione. Właśnie pomyślałem, że zamiast resetu sprzętowego może nastąpić skok do startu programu lub - co ostatnio stało się ze mną, gdy pośrednie skoki się nie udały - Licznik Programów po prostu przepełnił się i ponownie osiągnął 0x0000. Kto wie, w jakim stanie będą porty po tym ...

— Stefan Paul Noack,

Ani rejestry, ani SRAM nie są inicjowane po resecie, tylko niektóre rejestry peryferyjne. Powinieneś zainicjować rzeczy, których używasz.

— avakar
źródło

Czy znasz lub masz link do utraconego rejestru rejestrów peryferyjnych, którego to dotyczy? Znalazłem „wartości początkowe” dla niektórych, takich jak UCSRCw arkuszu danych. A co z portami I / O, szczególnie w kierunku danych?

— Stefan Paul Noack,

Porty we / wy są ustawione na wejście. Wszystko jest w karcie danych.

— Leon Heller

@LeonHeller, dzięki, teraz to widzę. Właśnie w opisach rejestrów. Jakoś mi tego brakowało ...

— Stefan Paul Noack,

@ noah1989, Leon ma rację, początkowe wartości rejestrów peryferyjnych są zawsze określone poniżej wizualizacji rejestru (lub jakkolwiek nazywa się ten obraz z nazwami poszczególnych bitów :)).

— avakar