7.1.1 Low Fuse Bits

The interesting bits in the low fuse, at least of interest to Arduino users, are the SUT and CKSEL fuses and possibly CKDIV8. The latter simply divides the chosen clock source (see CKSEL) by 8 to obtain the final system clock speed.

7.1.2 Low Fuse Factory Default

Fuses CKOUT (bit 6), SUT1 (bit 5), and CKSEL1 (bit 1) remain unprogrammed by default; and this means that the system clock pulse does not appear on PORTB, pin zero (CKOUT). SUT1 affects the startup time, and CKSEL1 affects the default system clock.

7.1.3 Arduino Low Fuse Settings

The Arduino boards running with the ATmega328P microcontroller set the low fuse to FF_hex or 1111 1111_binary – at least on the Nano with an ATmega328P, the Duemilanove with an ATmega328P, the Diecimila, and the Uno.

7.1.4 High Fuse Bits

One word in the AVR is equivalent to 2 bytes, or is it 4 bytes? It depends on which memory you are discussing.

Given that the Uno has a 512-byte – that’s an 8-bit byte – bootloader, its fuse settings define 128 words. If a word was 2 bytes, this would be only 256 bytes for the bootloader. It wouldn’t fit. So it appears that here, a word must surely be 4 bytes.

There is much confusion all over the Internet about what exactly a word is in the data sheet. However, be aware that in Static RAM, addresses point to bytes. A word there would be 2 bytes or 16 bits. In the Flash RAM, an address points to a 16-bit-wide “byte,” so a word of Flash RAM is two of those "bytes" given, in reality, 4 bytes.

Confused? The bootloader lives in Flash RAM, so each address is 16 bits wide, not 8, and still confusion reigns.

In Static RAM, address 0 points at the very first 8 bits in memory and address 1 the next 8 bits. In Flash RAM, address 0 points at the first 16 bits of flash and address 1 at the next 16 bits.

The Arduino Uno sets the BOOTSZ1:0 fuses to 11_binary, while the Duemilanove, Diecimila, and Nano use 01_binary resulting in a bootloader of 128 words and 512 (8-bit) bytes, for the Uno, and 512 words and 2048 (8-bit) bytes for the others.

The Arduino therefore sets this fuse so that the RESET vector will start executing at the bootloader rather than the application code, which is a good thing as it means that you will be able to reprogram the Arduino as the bootloader watches for programming instructions before jumping into the application code if none are forthcoming.

7.1.5 High Fuse Factory Default

7.1.6 Arduino High Fuse Settings

As detailed earlier, the Uno is programmed with 128 words of bootloader space, while other boards based on the ATmega328P use 512 words. A reset causes execution to start from the bootloader address.

7.1.7 Extended Fuse Bits

All other values for the BODLEVEL2:0 fuse bits are reserved and must not be used.

7.1.8 Extended Fuse Factory Default

From the factory, this fuse is set to FF_hex or 1111 1111_binary – so the brown-out detection is disabled. Only fuse bits 2–0 are used (BODLEVEL2:0); the rest should remain as 1_binary.

7.1.9 Arduino Extended Fuse Settings

The Arduino sets this fuse to FD_hex or 1111 1101_binary which sets the brown-out detection threshold voltage to 2.7 V as only BODLEVEL1 is programmed. This is potentially a bad idea as the Arduino boards are running with an external 16 MHz crystal and the data sheet advises that this will only be reliable between 4.0 V and 5.5 V – so this fuse should really be set to FC_hex, 1111 1100_binary, to give a 4.1 V threshold.

7.3.1 Watchdog Timer Modes of Operation

It should be noted that the Arduino code might be making this check, but that depends on how the bootloader was compiled. It is therefore still possible that your code could lead to a constantly resetting AVR microcontroller under the circumstances mentioned in the data sheet.

7.3.2 Amended Sketch setup() Function

The Watchdog Timer can now be enabled to a known and desired state, if required, in setup() and a call to wdt_reset() executed each time through the loop() and any other long-running processes.

7.3.3 Watchdog Timer Reset

So, if you are using the Watchdog Timer, your code must include the file avr/wdt.h and call wdt_reset() at regular intervals. How regular? You must reset the Watchdog Timer within the configured timeout period.

The call to wdt_reset() is only necessary when the Watchdog Timer is configured to run in “WDT Reset” and “Reset and Interrupt” modes. It is not necessary to call wdt_reset() when running in “WDT Interrupt” (WDI) mode as that mode does not cause the microcontroller to be reset.

7.3.4 The Watchdog Timer Control Register

In this mode of operation, if the Watchdog Timer was initialized at time T with timeout period P, then the interrupt will fire at time T + P (assuming global interrupts are enabled of course).

If WDIE is again set to 1_binary after the first P timeout, but before the second P timeout, then the system reset will not occur at time T + P + P. The Watchdog interrupt ISR will fire again instead.

If, on the other hand, WDIE is not set to 1_binary prior to the end of the next timeout period, P, then the system will be reset. This will occur at T + P + P.

This sequence allows for such things as using the ISR to save any data that must be updated between restarts; shutting down any peripherals, motors, laser cutters, etc. to a safe state before the restart occurs; and so on. Until the system has restarted, and fully initialized, the state of various pins is potentially unknown; and a runaway laser cutter, for example, is not a good thing to have close by!

If the WDTON fuse has been programmed (i.e., has value 0_binary) then you are unable to ever change bits WDE and WDIE in WDTCSR. The Arduino default is that this fuse bit is not programmed, so the Watchdog Timer can be enabled or disabled as you might wish.

With this fuse programmed, WDE is always 1_binary, while WDIE is always 0_binary, so the Watchdog Timer is always running in Watchdog Timer Reset (WDR) mode, and you cannot use the Watchdog Timer interrupt.

When the system is reset by the Watchdog Timer, on restarting, the Watchdog Timer is still enabled; however, it is now enabled at the smallest possible timeout setting, 16 milliseconds, and not perhaps as you configured it prior to the reset. This could cause Watchdog Timer reset loops. The Arduino bootloader should be checking and disabling the Watchdog Timer, but this depends on how the bootloader was compiled and cannot be relied upon. See Listing 7-2 for details on how to possibly prevent this from occuring.

7.3.5 Enabling the Watchdog Timer

The AVRLib functions defined in avr/wdt.h take care of all this when you make calls to the function wdt_enable().

7.3.6 Setting the Watchdog Timer Timeout

All other WDP3:0 values from 10 (1010_binary) to 15 (1111_binary) are reserved and should not be used.

The loop() function does nothing at all. All the blinking takes place in the ISR for the Watchdog Timer interrupt. In code like this, where an ISR is doing all the work, the main loop should really put the AVR microcontroller to sleep. And this is something we will deal with in Section 7.3.8, “Putting the AVR to Sleep.”

7.3.7 Disabling the Watchdog Timer

The Watchdog Timer can be disabled by following the sequence of events as follows:

If the WDTON fuse has been programmed (i.e., has value 0_binary), then you will be unable to disable the Watchdog Timer. In this case, the Watchdog Timer is always running in Watchdog Reset (WDR) mode.

• Disable global interrupts. This will prevent any existing interrupt handlers from firing during the critical timed sequence, thus preventing a valid change to WDTCSR.

• Reset the Watchdog Timer. It may already be running, and it should not reset the AVR microcontroller while it is being reconfigured.

• Ensure that bit WDRF in MCUSR is cleared.

• To start changing WDTCSR, you must write a 1_binary to both WDCE and WDE in the same instruction. If WDE is already a 1_binary, you must still write a 1_binary to it. You are advised to preserve the existing state of bits WDP3:0 to prevent unintentional Watchdog Timer timeouts which will occur if the timeout period is being reduced, explicitly or implicitly, and the new timeout has already expired.

• Within four system clock cycles, write a 0_binary to bits WDCE and WDE. All bits must be set and/or cleared in the same instruction. The data sheet, surprisingly, advises clearing the entire register – which completely disagrees with its previous instruction to preserve the state of bits WDP3:0.

• Enable global interrupts.

The AVRLib functions defined in avr/wdt.h take care of all this when you make calls to the function wdt_disable().

You could, obviously, extract the preceding code to a function of your own and call that whenever the Watchdog Timer needed to be disabled.

7.3.8 Putting the AVR to Sleep

The ATmega328P comes with six different sleep modes built in. These can be used to vastly reduce power requirements of the AVR microcontroller when it doesn’t need to be polling for button presses and so on. When sleeping, interrupts must normally be used to wake the device and let it run the necessary processing as required.

In other words, if the code is written in such a way as to not require the processor to be constantly polling sensors and so on in the main loop, then it can be put to sleep which will save power and make batteries last much longer.

Chapter 9 of the data sheet, “Sleep Modes”, has the following points of note:

When entering a sleep mode, all port pins should be configured to use minimum power. The most important is then to ensure that no pins drive resistive loads. In sleep modes where both the I/O clock (clkI/O) and the ADC clock (clkADC) are stopped, the input buffers of the device will be disabled. This ensures that no power is consumed by the input logic when not needed. In some cases, the input logic is needed for detecting wake-up conditions, and it will then be enabled.

If the input buffer is enabled and the input signal is left floating or have an analog signal level close to VCC/2, the input buffer will use excessive power.

For analog input pins, the digital input buffer should be disabled at all times. An analog signal level close to VCC/2 on an input pin can cause significant current even in active mode. Digital input buffers can be disabled by writing to the Digital Input Disable Registers (DIDR1 and DIDR0).

The "analogue input pins" referred to are those of the ADC and the Analogue Comparator. Chapter 9, Section 9.1.3, “Digital Input,” and Section 9.2.1.6, “Disable Digital Input,” describe how to disable the digital input buffers when using the Analogue Comparator or the ADC.

The bits SM2:0 in the SMCR register are bits 3, 2, and 1, hence the use of the shift left instructions in the preceding definitions.

To put an AVR microcontroller to sleep in Idle mode, for example, you could execute code similar to that shown in Listings 7-8 to 7-10. You could, but I wouldn’t bother myself because it doesn’t work as expected with the code shown! Don’t worry as all will be made clear soon.

If, while the device is asleep, an interrupt occurs, the device will wake up but will then halt itself for four clock cycles before executing the interrupt routine. Those four clock cycles are in addition to any startup time requirements.

Once the interrupt routine has been executed, control returns to the instruction after the sleep instruction that put the device to sleep previously. The sleep instruction is built in to the ATmega328P. Our C++ code can call it as it has been defined elsewhere. Normally, it is easier to use the various sleep functions in AVRLib.

“So what’s wrong with the preceding sketch?” I hear you think. “Why is SLEEP_MODE_IDLE not the best sleep mode for this demonstration?” You will possibly have realized that while an Arduino is in this sleep mode, the Timer/counter 0, used to count millis() and so on, is running with its Overflow interrupt enabled. And an interrupt wakes the AVR microcontroller when it fires, so in SLEEP_MODE_IDLE the main loop just runs and runs – it does sleep, but only until the timer/counter overflows and that happens every 1024 microseconds.

If you were to recompile the preceding code, but use SLEEP_MODE_PWR_DOWN instead, once the LED flashes twice in setup(), you won’t see it again until a proper interrupt occurs – but because I haven’t enabled any particular interrupts, the Arduino will simply go to sleep and never wake up. There’s a much better example in Section 7.3.10.

7.3.9 Sleep Modes

In the following discussions, regarding each different sleep mode, I give the sleep modes numbers; SLEEP_MODE_IDLE, for example, is sleep mode 0. I indicate the value in binary as well, in 3 bits. These are the 3 bits that need to be written to the SM2:0 bits in the Sleep Mode Control Register (SMCR). These 3 bits control which sleep mode the AVR microcontroller will enter when the Sleep Enable (SE) bit is set and a sleep instruction executed.

While there are 3 bits available, giving eight different sleep modes (000_binary–111_binary), sleep modes 4 (100_binary) and 5 (101_binary) are reserved and should not be used, leaving only six modes. Of these, one cannot be used on the Arduino as it requires Timer/counter 2 to be running in asynchronous mode, which is not possible on an Arduino, and another is dubious. We therefore have three good modes and two dubious ones left on our Arduinos.

7.3.10 Analogue Comparator

The data sheet is not very clear on whether or not the Analogue Comparator interrupt can be used to wake the device from some of the sleep modes. Believe me I searched in vain for the detail! To this end, I configured the various sleep modes and set up a circuit identical to the one described in Chapter 9 on the Analogue Comparator. There’s a full description of the circuit and how it works in Chapter 9, Section 9.1, “The Analogue Comparator.”

In the code in Listings 7-11 to 7-14, I set the Arduino into various sleep modes in setup() and then tested to see if the comparator would wake the AVR microcontroller from its slumbers.

And the results? The Analogue Comparator does indeed wake up the Arduino when in SLEEP_MODE_IDLE but doesn’t wake it up in any other mode which is as I thought would be the case, but at least I now know.

7.4.1 Power Consumption

You should note that these figures are for a bare-bones AVR microcontroller and not for the whole Arduino board, complete with power-hungry devices like the voltage regulator, the always-on power LED, and so on.

You may be surprised to find out exactly how few components you actually need to run a device with an ATmega328P as the microcontroller and even fewer if your device can be run using an ATtiny85!

From Table 7-19, it can be seen that an active ATmega328P, running at 16 MHz with a VCC of 4 V, uses half the power of the same device running with a VCC of 5.5 V. Sadly, our Arduino boards are fixed at 5.0 V for VCC, so we are not able to do much in that area to reduce power consumption. However, for a bare-bones AVR microcontroller on a breadboard or circuit board of our own design, we do have the option.

While the Arduino boards themselves are excellent for prototyping, they are a tad expensive, and power hungry, to embed in the finished product. In the case where a device is deemed to be market-ready, the Arduino itself will normally be replaced by a minimal ATmega328P circuit, with far fewer resource requirements and a much lower cost.

7.4.2 Power Reduction Register

What these bits do is to stop the clock to the peripheral. Once the clock has been stopped, that peripheral is effectively suspended, and there is no ability to write to, or read from, the device’s registers.

The data sheet warns that Resources used by the peripheral when stopping the clock will remain occupied, hence the peripheral should in most cases be disabled before stopping the clock.

What this means is that whatever peripheral you wish to power off should be disabled before powering it down. In the case of the ADC, for example, this would entail writing a 0_binary to ADEN in the ADCSRA register to disable the ADC and then writing a 1_binary to PRADC in the PRR to power it off.

To power up a peripheral from its powered-down state, simply write a 0_binary to the appropriate bit in the PRR. The peripheral will wake up again and will resume the state that it was in when powered down. You have to write a zero because that disables the power reduction for that peripheral.

The Analogue Comparator doesn’t have a bit in the PRR. It does, however, have the ACD bit in the Analogue Comparator Control and Status Register – ACSR. Write a 1_binary to that bit to power off the Analogue Comparator.

7.4.3 Saving Arduino Power

Now you know what peripherals can be disabled and powered down, you are able to perhaps save a little of your device’s power by using the setup() function to power off all those bits of the ATmega328P that you don’t need for a sketch.

Taking the old favorite blink sketch, yet again, what does it actually need? Nothing more than the I/O pins and a timer/counter to work the delay() function. The delay() function and millis() and micros() all depend on Timer/counter 0. Listings 7-15 to 7-17 show an example blink sketch with unwanted peripherals turned off.

The AVRLib has some useful power maintenance functions, and these can be used to power off the peripherals we don’t need in our blink sketch. There is a trade-off of course: adding code to setup() to disable and power off these peripherals will increase the code size of the final sketch.

In the case of the blink sketch, it’s unlikely that this will be a problem, but for other sketches that might be pushing at the capacity of the AVR microcontroller, it could be a problem and you might have to revert to the direct manner of setting the registers in your code, rather than using the AVRLib functions.

The sketch uses 1006 bytes of Flash RAM now, which is obviously more than the standard blink sketch would use. In larger sketches, the overhead should be less.

7.4.4 The Power Functions

Not all devices have these functions; it’s another one of those configuration things. The iom328p.h header file sets up the appropriate functions which are available for peripheral devices on the ATmega328P.

You are required to manually turn off the Analogue Comparator if you do not need it. There doesn’t appear to be a utility function to do so in the AVRLib code.

7.5.1 Flash Memory

There are fuses, BOOTSZ1:0 and BOOTRST, to determine the size and address of the bootloader sections; and, in the case of the BOOTRST fuse, it determines whether the device starts executing the bootloader or the application code on startup and/or reset.

While it is possible and, indeed, permitted for the bootloader to write to the application section, the converse is not true. The application cannot access the bootloader section.

You should also note that the whole of Flash RAM can be used as the application section if no bootloader is required. This seems to be easily done simply by using an ICSP device to do the programming.

The sections are considered completely separate by the device, and they can have different protection levels. This protection is determined by special lock bits. Boot Loader Lock Bits 0 protect the application section, while Boot Loader Lock Bits 1 protect the bootloader section. There are two other lock bits that protect the entire ATmega328P from either being reprogrammed or having its Flash RAM read out.

7.5.2 Lock Bits

The lock bits can be set in software, in serial or parallel programming mode. To clear the bootloader lock bits, a full chip erase command must be given. It may not be possible, but I have not checked this on my own devices – for obvious reasons, to ever unlock the device for programming if the device lock bits have been set.

7.5.3 Installing the Uno (Optiboot) Bootloader

The Uno bootloader is around 500 bytes in size, so takes up less of your precious Flash RAM when installed. It is found, should you wish to examine it in detail, in $ARDINST/bootloaders/optiboot/optiboot.c.

Although it’s commonly referred as the Uno bootloader, it is, in fact, quite easily installable into other devices. The comments in the source code mention that it is compatible with both the Duemilanove and the Diecimila and other ATmega168- or AtMega328P-based devices.

You now have a smaller, faster bootloader and an additional 1.5 Kb of flash for your program – and all for free.

7.5.4 Optiboot Bootloader Operation

When the device is powered on, or reset, and if the BOOTRST fuse is set to enable the bootloader to be executed at startup, then the bootloader code for the device is executed.

One of the first tasks that the bootloader does is to check the MCUSR to determine if this was an External Reset or not. It does this by checking the EXTRF bit in the MCUSR. If that bit is set, then the device was reset by pulling pin 1, RST low, and not by a power-on, Watchdog, or BOD reset. This could have been done by the user pressing the reset button on the Arduino board or by the programming device using the DTR pin to pull the ATmega328P’s RST pin low. In any case, bit EXTRF will have been set.

In the case when this bit is not set, the bootloader assumes that the device is not about to be reprogrammed and jumps immediately to the application code, bypassing the rest of the bootloader itself. If the bit is set, then the bootloader continues executing.

The Watchdog Timer is set to fire after 1 second, the onboard LED is flashed once to indicate that it is waiting, and an infinite loop is entered to wait for characters coming in over the USART. If nothing is received after the 1 second timeout by the Watchdog, then the device will reset again but this time by the Watchdog. On restarting from a Watchdog-induced reset, the EXTRF bit in the MCUSR will no longer be set – the WDRF bit, on the other hand, will be set – so the application code is immediately executed.

The bootloader, if it continues executing, must have read at least 1 byte from the USART. These bytes are assumed to be commands from a subset of the STK500 communications protocol – the Optiboot bootloader currently only implements a subset of the STK500 instructions – and these commands are used to communicate with, usually, avrdude.

It is beyond the scope of this book to delve into the various bootloader commands as they really have little to do with application programming. Suffice it to say that the bootloader sits in a loop, reading characters from the USART and acting upon them, in addition to resetting the Watchdog Timer to prevent the device being reset by the Watchdog and messing up the programming.

Should you really wish to examine the Optiboot bootloader, there is a compilation listing for the ATmega328P, in the location $ARDINST/bootloaders/optiboot/optiboot_atmega328.lst – it does make interesting reading.