# Do AVR registers and ports need to be initialized to zero?

During the initialization routine of my code I use to do such things as:

clr    r0  ; will always stay zero


and:

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


Is this actually necessary? Or can I be sure this is automatically done upon reset? Especially, can I rely on all ports to be set as inputs by default so there is no problem with external votages when no code is executed?

-

The I/O ports of an AVR are set to INPUT / Tri-State / Hi-Z (DDRx = 0x00) upon reset. Most microcontrollers (if not all?) have this behavior. It's the safest state for a pin to be in. So yes, you can rely on the ports to be set automatically as inputs.

Some excerpts an the ATmega16 show exactly that:

The Port C pins are tri-stated when a reset condition becomes active, even if the clock is not running.

-
This is exactly what I've been looking for :) –  noah1989 Apr 10 '12 at 8:38
as far as i remember, if you leave an input floating, you get random noise on it, so initial state can be zero, that's ok, but it might become non zero after first clock cycle. –  miceuz Apr 10 '12 at 10:03
@miceuz The point is not to have outputs in an unknown state. They may have an undesirable effect on the external circuit that's connected to the microcontroller –  m.Alin Apr 10 '12 at 10:19
@miceuz you're refering to the port input registers, right? these have N/A as their initial state (which makes sense, since they just reflect whatever is applied to the pin). But I was refering to the data direction registers. I just wanted to be sure I don't accidently have the port set as output, possibly conflicting with voltages applied to the pin. –  noah1989 Apr 10 '12 at 10:57
oh yeah, really, sorry for the noise.. –  miceuz Apr 10 '12 at 20:17

Neither registers nor SRAM is initialized upon reset, only some of the peripheral registers. You should initialize things you use.

-
Do you know or have a link to a lost of which peripherial registers this applies to? I found 'initial values' for some such as UCSRC in the datasheet. What about the I/O ports, especially the data direction? –  noah1989 Apr 10 '12 at 8:11
I/O ports are set to input. It's all in the data sheet. –  Leon Heller Apr 10 '12 at 8:14
@LeonHeller oh thanks, now I see it. Right there in the register descriptions. I somehow missed that... –  noah1989 Apr 10 '12 at 8:19
@noah1989, Leon is correct, the initial values for peripheral registers are always specified below the register's visualization (or whatever that image with names of individual bits is called :) ). –  avakar Apr 10 '12 at 8:24
• Port initialisation is ALWAYS a good idea, regardless of what the data sheet says.

• If the datasheet says nothing then it is an utterly vital idea.

You only need to define the port data contents if you care about what will happen when your program runs.

If you don't care about the result you don't have to set the port data bits :-).

If manufacturers say explicitly in the data sheets that port data bits are set or cleared then they may be BUT it is STILL a really really good idea to initialise them yourself anyway. "Boundary conditions" are where most things go wrong - eg start of a loop, end of a loop, circular buffer wrap round point, ... . Processor startup is a hardware equivalent. In a real world with noise and glitches and people in it, being in charge of your programs destiny as much as you can is a really good idea. Port initialisation is an easy part of this.

-
Fully agreed. I just figured, that instead of a hardware reset, there could be a jump to the program start or - what recently happened to me when indirect jumps went wrong - the Program Counter just overflowing and reaching 0x0000 again. Who knows what state the ports will be in after that... –  noah1989 Apr 10 '12 at 8:48