masters 2017 - lab manual for 21110...

MASTERs 2017 LAB Manual for 21110 LPD1 Using 8-bit Microcontrollers in Battery Powered Devices: Techniques for Optimizing Power Consumption, Pin Count, Performance, and Precision

Table of Contents Prerequisites 2 Introduction 3 Lab 1 Instructions 5 Task A 6 Task B 14 Task C 19 Task D 25 Task E 31 Lab 2 Instructions 32 Lab 3 Instructions 40 Lab 4 Instructions 41 Lab 5 Instructions 48 P4 Board Schematic 52

Lab Manual for 21110 LPD1

Prerequisites • Required knowledge

o Some embedded C knowledge • Required software

o Atmel Studio (version 7.0.1417 or later) • Required hardware

o AVR P4 demo board (ATAVRFEB-P4) o Power Debugger kit (ATPOWERDEBUGGER) o Four female-to-female strap wires (included with Power Debugger kit) o 10-pin debug ribbon cable (included with Power Debugger kit) o USB type A to micro B cable (included with Power Debugger kit)


Introduction This manual is intended to be used in the classroom as well as at home after MASTERs.

For the classrooms, it is assumed that everything you need is already installed on the computers. For home use, you will need to install Atmel Studio on your PC.

Also for the classrooms, due to time limitations, the hardware boards have been prewired. The wiring diagram and photo below show how the P4 and Power Debugger boards are interconnected with 4 female-to-female strap wires. The P4 board must NOT have a battery inserted in its battery holder!

VOUT 1.6V-5.5V 100mA on Power Debugger

GND on Power Debugger

->A (100mA ammeter input) on Power Debugger

A-> (100mA ammeter output) on Power Debugger


A 10-pin debug ribbon cable must also be connected from the Power Debugger to the P4 board as shown in the photo below.


LAB 1: Using the MCU oscillators and switching between them on-the-fly Objectives: Get familiar with the hardware and software tools that will be used for all labs. Set up the clock oscillators. Switch between the oscillators on-the-fly. Verify their behavior.

Because LAB1 covers a lot of material, it has been divided into the following tasks:

A. Using Power Debugger to provide power to the P4 board B. Opening a project and running it on the P4 board C. Using Data Visualizer for graphing and measuring current consumption D. Changing clock oscillators on-the-fly and measuring current consumption E. Using _delay_ms() for accurate delays in code


Task A: Using Power Debugger to provide power to the P4 board Procedure: To do: Connect to the Power Debugger using Atmel Studio. 1. On the P4 board, put the SET/RUN slide switch in the RUN position. This

disconnects the P4 board display from power since it will not be needed in this lab.

2. Connect the DEBUG port on Power Debugger to the PC using a USB cable. The red POWER LED on the Power Debugger will light up.

3. If the Power Debugger has not been used previously with the PC, some messages may appear that drivers are being installed, and a “You must restart your computer…” window may appear as shown in the figure below. If this happens, click on Restart Later to postpone the restart.

4. Locate the icon for the shortcut to Atmel Studio on the desktop as shown in the figure below.

5. Launch the Atmel Studio IDE by double-clicking on the icon.


6. After the Atmel Studio IDE has appeared, select ToolsDevice Programming. This will cause the Device Programming window to appear as shown in the figure below.

7. As shown in the figure below, use the dropdown lists to select Tool as Power Debugger, Device as ATtiny416, Interface as UPDI, and then click Apply.


8. If the Power Debugger firmware must be updated, a Firmware Upgrade window will appear as shown below. Click on Upgrade.

9. If a Power Debugger firmware update was necessary, the update will take several seconds and will complete with a “Power Debugger firmware successfully upgraded” message as shown in the figure below. Click on Close.


10. If a firmware upgrade was necessary, it will be necessary to click on Apply in the Device Programming window as shown below.

11. The Device Programming window will appear as shown below. Close the Device Programming window by clicking on Close.


Result: Atmel Studio recognizes the Power Debugger board.

To do: Provide power to the P4 board using Power Debugger.

12. In Atmel Studio select Tools Data Visualizer.

13. After the DGI (Data Graphic Interface) Control Panel appears as shown below, click on Connect, so as to connect to the Power Debugger Data Gateway.

14. Check the box beside Power and click on the gear symbol beside Power as shown below.


15. The Power Configuration interface will appear as shown below. Move the slider horizontally to the right to adjust the Voltage Output to approximately 2000 mV.

16. Once the Voltage Output is adjusted to approximately 2.0V as shown below, check the Enable Voltage Output box and click on the OK button. This provides power at 2.0V to the P4 board, emulating a 3V battery near the end of its life.

17. Verify that the P4 board is truly powered by pressing any one of the 4 pushbuttons on the board (B1, B2, B3, or B4) and verifying that the red LED beside it lights up. The LED will appear rather weak because the 2.0V supply is just slightly more than the minimum 1.8V needed to light the LED. (If the LED does not light, verify that the wiring between the P4 board and the Power Debugger is correct.)


Result: The P4 board is powered with 2.0V from the Power Debugger. Tip: Whenever the Power Debugger is disconnected from its USB connection to the PC, the Output Voltage setting is lost. When the Power Debugger is reconnected to the PC via USB, the Output Voltage must be readjusted to the desired value and enabled. To do: Increase the supply voltage to the P4 board to 2.8V.

18. Click on the gear symbol beside Power as shown below to bring back the Power Configuration interface.


19. Move the slider horizontally to the right to adjust the Voltage Output to approximately 2800 mV as shown below.

20. Click on the OK button. This provides power at 2.8V to the P4 board, emulating a slightly discharged 3V battery.

21. Press any one of the 4 pushbuttons on the P4 board (B1, B2, B3, or B4) and verify that the red LED beside it lights up. The LED will appear brighter now because of the increased power supply voltage.

Result: The P4 board is powered with 2.8V from the Power Debugger. Task A of LAB1 is now complete.


Task B: Opening a project and running it on the P4 board Procedure: To Do: Open a project and run it on the P4 board. 1. In Atmel Studio, select File Open Project/Solution... to bring up the Open

Project window.

2. As shown below, find and select the C:\MASTERs\21110\devp4a1\devp4a1.atsln file and click on Open to open a pre-defined project that will be used as the basis for LABs 1, 2, 3, and 4.

Tip: The same project file will be used throughout LABs 1 through 4. Within the code in main.c, there are comments indicating where INIT (initialization) and APPLICATION code are to be placed for each of the labs. Keeping a clean separation between initialization and application code is recommended not just for these labs but for project coding in general.


3. In the Solution Explorer window, which appears on the right side of Atmel Studio as shown below, double click on main.c to view/edit the contents of the main.c file.

4. Scroll through the main.c file in the editor to get an overview of the code, and read the discussion that follows. Discussion: The main.c file includes a few header files, defines a few constants, and declares a few variables, but the most important part for the purposes of this lab is the content of the main() function. As shown in the excerpt below, the main()function contains a while(1) (forever) loop that interacts with several 8-bit wide PORT registers.


The I/O pins of the ATtiny416 device are controlled by three instances of the PORT register: PORTA, PORTB, and PORTC, where each bit of a register interacts with a specific I/O pin on the device. Additional names are defined near the top of the file, for example BLED3PORT, to make it more convenient to write code for a specific button or LED. A read of the PORTx.IN (Input Value) register obtains the value present on the pins of the port. The PORTx.DIRSET and PORTx.DIRCLR (Data Direction Set and Clear) registers allow an individual pin of the port to be configured as an output or input. Writing a one to bit n of the PORTx.DIRSET register will make the corresponding pin an output, and writing a one to bit n of the PORTx.DIRCLR register will make the pin an input. The PORTx.OUTSET and PORTx.OUTCLR (Output Value Set and Clear) registers allow the output value on the pins of the port to be controlled. Writing a one to bit n of the PORTx.OUTSET register will make the corresponding pin’s output level high, and writing a one to bit n of the PORTx.OUTCLR register will make the pin’s output level low. In the while(1) loop, the code first checks one bit of the BLED1PORT.IN (actually PORTA.IN) register to determine whether button B1 is pressed. If B1 is pressed, LED3 is turned on by first writing to the BLED3PORT.DIRSET (actually PORTB.DIRSET) register to set the direction of the pin as an output, then writing to the BLED3PORT.OUTCLR register to clear the output value of the pin. Next, a for() loop introduces a delay by counting to 10000. LED3 is then turned off by writing to the BLED3PORT.DIRCLR register to set the direction of the pin as an input, then another for() loop introduces a delay by counting to 10000, and so on. The intent of this code is to cause LED3 to flash whenever B1 is pressed. Because the delays are determined by how fast the CPU can count to 10000, the flash rate of LED3 will be proportional to the clock frequency of the CPU.

5. Click Debug Continue to build the project and run it in debug mode on the P4 board's MCU.


6. It may be the case that a “Please select a connected tool and interface…” window appears as shown in the figure below. If this happens click on Continue.

7. To select a tool and interface, as shown in the figure below, use the dropdown lists to select Power Debugger as the debugger/programmer and UPDI as the Interface.

8. If it was necessary to select a tool and interface, click Debug Continue to build the project and run it in debug mode on the P4 board's MCU.

9. Once the code is running as indicated by a flashing green STATUS indicator on the Power Debugger, press button B1 on the P4 board for a few seconds. This will


cause LED3 to flash (or flicker) at a high rate, more than 10 times per second.

Result: Code for flashing LED3 is running on the P4 board. Task B of LAB1 is now complete.


Task C: Using Data Visualizer for graphing and measuring current consumption Procedure: To do: Graph and measure the current consumption of the P4 board. 1. Select Tools Data Visualizer.

2. Click on Start as shown below. A real-time graph of the current consumption of the

P4 board will be displayed.


3. The real-time graph of the current consumption vs. time will appear similar to that shown in the figure below, with ammeter channel A in blue and ammeter channel B in red. The horizontal axis of the graph is labeled with time in hours, minutes, and seconds, and the vertical axis is labeled with current. Below the graph, both instant and window average digital current values are provided for both channels. Since the P4 board is connected to ammeter channel A, and channel B is not connected to anything, only the channel A current values (blue) are relevant. To declutter the graph by removing channel B (red) and associated legends, first click on the Control Panel arrow as shown below.

4. As shown in the figure below, this will reveal the Control Panel. Click on the Channel B arrow as shown below.


5. This will reveal additional controls for Channel B as shown below. UNcheck the box beside Current, and click on the Channel B arrow as shown below to collapse the Channel B controls.

6. Press and hold button B1 on the P4 board for a few seconds. This will cause the LED to flash and the effect on current consumption will be similar to that shown in the figure below.


7. Click on the Stop button as shown in the figure below to stop the real-time current display.

8. As shown in the figure below, UNcheck the Auto-scroll box.

9. Click on the center of the current graph, then zoom out on the display by holding the left Shift key down on the keyboard and rotating the mouse-wheel down until the area of increased current consumption appears within the display. (If there is no wheel on the mouse, an alternative is to do a two-finger swipe down on the trackpad.)

10. Release the left Shift key and rotate the mouse-wheel so as to pan the display so that the area of increased current consumption is roughly centered in the graph.


11. Zoom in on the display by holding the left Shift key down on the keyboard and rotating the mouse-wheel up until the detailed square-wave structure of the current consumption is visible as in the figure below.

12. Observe that the current graph is a square wave with peak-to-peak amplitude of about 1 mA, since the toggling LED consumes about 1 mA of current when it is on. The period of the square wave can be determined by noting the time at the beginning of one period (1:29.40 in the example), noting the time at the end of the period (1:29.44 in the example) and subtracting the two values to obtain 0.04 seconds or 40 milliseconds (25 Hz). Because the C code has nothing in it that changes the main oscillator or prescaler division factor, the CPU is running with the default main oscillator and prescaler values. The default main oscillator frequency can be either 16 MHz or 20 MHz based on the settings of some non-volatile memory fuses (OSCCFG.FREQSEL[1:0]), and the default setting of these fuses is 20 MHz. The default prescaler division factor is 6, so the CPU is running at 20 MHz/6 = 3.33 MHz.

13. Click on Debug Stop Debugging. The STATUS LED on the Power Debugger will stop flashing. Note, however, that the code is still running on the P4 board because if B1 is pressed then LED3 flashes -- it's just that the debugger is no longer active.

14. Click Debug Continue to rebuild the project and run it using the debugger.


15. Click on Tools Data Visualizer, check the box beside Auto-scroll, and click on Start to begin measuring and visualizing real-time current again.

16. Hold the left Shift keyboard key down and rotate the mouse-wheel down to zoom out the graphical display to encompass approximately 10 seconds.

17. Measure the average current consumption by viewing the Ch A Window Average digital value in the display and record it here: ______ uA.

18. Click on Debug Stop Debugging to stop debugging (but, as noted earlier, the code will still be running on the P4 board).

19. Click on Tools Data Visualizer to bring back the Data Visualizer, and note that the current consumption has dropped. This is because the code is running on the MCU, but the debugger is no longer active. This demonstrates that the debugger consumes significant current. Measure the window average current consumption and record it here: ______ uA.

Result: The current consumption of the P4 board was graphed using Data Visualizer in Atmel Studio. Task C of LAB1 is now complete.


Task D: Changing clock oscillators on-the-fly and measuring current consumption Procedure: To do: Modify code to change clock oscillators and measure current consumption. 1. Click on the main.c tab within Atmel Studio to go back to viewing/editing the code.

The next step in this lab will be to reduce the CPU clock frequency by changing the main clock prescaler value, and in order to do this it is necessary to write to the CLKCTRL.MCLKCTRLB register. Below is an excerpt from the ATtiny416 datasheet showing the detailed structure of the CLKCTRL.MCLKCTRLB register.


Discussion: One important thing to be aware of is that constants have been predefined in Atmel Studio to make it easier to write maintainable C code for accessing registers. Thus it is generally unnecessary to use hardcoded values. However, the naming of these constants cannot be determined just from looking at the device datasheet. For the ATtiny416 device, the definitions are contained in the iotn416.h header file.

To view the contents of the iotn416.h header file, in Solution Explorer, double click on Dependencies. Several filenames will appear below Dependencies. Double click on iotn416.h.

In iotn416.h, peripheral module structures are defined that group relevant registers together. Typically, a register is accessed as PERIPHERAL.REGISTER. Individual registers can also be accessed as PERIPHERAL_REGISTER.

Bit positions, bit masks, and group configuration constants are defined for easy setup of peripherals.

For example, the following code excerpt from iotn416.h shows how bit mask and bit position constants are already predefined for accessing the PEN bit in the CLKCTRL.MCLKCTRLB register.

For writing maintainable code, it is highly recommended that predefined constants such as CLKCTRL_PEN_bm or CLKCTRL_PEN_bp be used instead of hardcoded values like 0x01.

For fields that are more than one bit wide, such as PDIV in CLKCTRL.MCLKCTRLB, “group configuration” constants are defined for each legal value as shown below.


The availability of predefined constants makes it easier to write understandable, maintainable code.

There are a few registers that are especially critical to the operation of the system, and are therefore protected from accidental modification. The CLKCTRL.MCLKCTRLB register is one example of a protected register. A protected register is indicated in the datasheet by “Property: Configuration Change Protection”. A normal register write of the form register=new_value will not have any effect on the contents of a protected register. To change the value of a protected register, it is necessary to call the _PROTECTED_WRITE(register,new_value) function.

2. Just below the comment “// Put LAB1 INIT code below this line” in main.c, add a line of code that uses _PROTECTED_WRITE() to change the Main Clock prescaler division factor to 64. Using a prescaler division factor of 64 will cause the CPU to run at 20MHz/64 = 0.31 MHz, or about one-tenth of the original 3.33 MHz frequency. (Hint 1: Don’t forget that the prescaler must also be enabled using the PEN bit. Hint 2: Do not be concerned if a red squiggly line, indicating invalid code, appears below _PROTECTED_WRITE as shown below. This is a known issue in Atmel Studio, but it does not prevent the code from building and running successfully.)

3. Select Debug Start without Debugging to build and run the code without debugging.

4. Press B1 on the P4 board for several seconds, and observe that LED3 flashes

roughly twice a second as would be expected given that the CPU is running at (1/10) its original frequency.

5. Select Tools Data Visualizer to observe the current waveform. Measure the window average current consumption (without pressing any buttons on the P4 board) and record it here: ______ uA.


6. Click on the main.c tab within Atmel Studio to go back to editing/viewing the code. The next step in this lab will be to change to a different main clock oscillator, and in order to do this it is necessary to write to the CLKCTRL.MCLKCTRLA register. Below is an excerpt from the ATtiny416 datasheet showing the detailed structure of the CLKCTRL.MCLKCTRLA register.

Writing a new value to the CLKCTRL.MCLKCTRLA register allows a different oscillator to be selected for the main clock. However, when the new value is written, it takes some time to switch to the new oscillator, especially when the oscillator runs at a relatively slow frequency.


7. The CLKCTRL.MCLKSTATUS register, shown below, allows code to check on the status of the clock changing process so it can wait for the change to complete before continuing.

When a new value is written to the CLKCTRL.MCLKCTRLA register, the SOSC bit in the CLKCTRL.MCLKSTATUS register will change to one and stay there while the main clock change is in progress. After the main clock has been successfully switched to the new oscillator, the SOSC bit will return to zero. This allows code to


loop and wait for SOSC to be zero, insuring that the main clock is actually running from the new oscillator for any code that follows. Modify the LAB1 INIT code so that the CPU is running from the 32kHz internal oscillator (OSCULP32K) with NO prescaling. This will require three steps: (1) writing a new oscillator selection to CLKCTRL.MCLKCTRLA, (2) waiting until the SOSC bit in CLKCTRL.MCLKSTATUS is zero, and then (3) making appropriate prescaler changes to the CLKCTRL.MCLKCTRLB register. (Hint 1: Both CLKCTRL.MCLKCTRLA and CLKCTRL.MCLKCTRLB are protected registers. Hint 2: Search for CLKCTRL_CLKSEL in iotn416.h to find the group configuration constant needed for writing to CLKCTRL.MCLKCTRLA.) This should cause the CPU to run at approximately 32 kHz, or about 1/100 of the original 3.33 MHz clock frequency.

8. Select Debug Start without Debugging to build and run the code. If the code is working, pressing button B1 should cause LED3 to flash with a period of roughly 4 seconds (frequency of 0.25 Hz) since the CPU is running at 1/100 the original frequency.

9. Select Tools Data Visualizer to observe the current waveform. Measure average current consumption (without pressing any buttons on the P4 board) and record it here: ______ uA.

10. While viewing current consumption, gently disconnect the 10-pin debug ribbon cable connector from the Power Debugger. Measure average current consumption and record here: ______ uA.

11. This demonstrates that to get the most accurate results when measuring supply current, especially in the uA range, it is necessary to run the code without debugging and to disconnect the debug cable. Now, reconnect the debug cable to the AVR port on Power Debugger.

12. Click on Stop to stop the real-time graph in Data Visualizer.

Result: The clock oscillator was changed and current consumption was measured in various scenarios. Task D of LAB1 is now complete.


Task E: Using _delay_ms() for accurate delays in code Procedure: To do: Use _delay_ms() to flash LED3 once per second. 1. Comment out the oscillator and prescaler change code that was added previously in

the LAB 1 INIT area of main.c so that the CPU will once again run at the default frequency of 20MHz/6 = 3.33 MHz.

2. So far in this lab, a for() loop counting to 10000 has been used to insert a delay in the C code. Although this has worked well for comparing relative main clock frequencies, it is not a good method of introducing a well-defined delay in C code. Atmel Studio provides the _delay_ms(delay_value) function for this purpose. The argument to the function specifies the desired delay in milliseconds – for example _delay_ms(123) causes a delay of 123 milliseconds. Before this function can be used, however, the F_CPU (frequency of CPU) constant must be defined so the function can calculate the correct number of cycles. Add the following line of code at the very top of main.c so as to define that the CPU frequency is 3.33 MHz: #define F_CPU 3330000UL

3. One other thing that must be added before _delay_ms() can be used is the appropriate header file. Just below the definition of F_CPU in main.c, add the following line of code: #include <util/delay.h>

4. In the LAB1 APPLICATION section of main.c, comment out the for() loops within

the while(1) loop and instead use calls to _delay_ms() so that LED3 will flash once per second.

5. Click Debug Start without Debugging, and verify that pressing and holding B1 causes LED3 to flash once per second.

Result: LED3 flashes once per second. LAB1 is now complete.


LAB 2: Using RTC to keep track of time while sleeping Objectives: Use the RTC (Real Time Counter) to keep track of time while minimizing power by sleeping. Verify the behavior.

Procedure: To do: Set up the RTC to generate an interrupt every 3 seconds. 1. In this lab the RTC will be set up to use the 32.768 kHz crystal oscillator as its clock

source. Before that can be done, however, the 32.768 kHz crystal oscillator must first be enabled using the CLKCTRL.XOSC32KCTRLA register. The detailed structure of the CLKCTRL.XOSC32KCTRLA register is shown in the datasheet excerpt on the next page.


Just below the comment “// Put LAB2 INIT code below this line” in main.c, add a line of code that uses the _PROTECTED_WRITE() function to change the ENABLE bit to 1 in CLKCTRL.XOSC32KCTRLA. (Hint: Remember that


iotn416.h can be viewed and searched to find the C constants needed to interact with the CLKCTRL.XOSC32KCTRLA register, and that copy/paste can be a useful method of adding the necessary constants to the code.)

2. The detailed structure of the RTC.CLKSEL register is shown in the datasheet excerpt below.

Add a line of LAB2 INIT code to setup the RTC with the 32.768 kHz crystal oscillator (XOSC32K) as clock source. (Hint 1: RTC.CLKSEL is NOT a protected register. Hint 2: Search for RTC_CLKSEL in iotn416.h to find the group configuration constants.)


3. The RTC.CTRLA, RTC.PER, and RTC.INTCTRL registers are defined as shown in the following datasheet excerpts.


Add some lines of LAB2 INIT code that write to these registers so as to generate an OVF (Overflow) interrupt every 3 seconds. The recommended writing sequence is RTC.PER to determine the overflow period, then RTC.INTCTRL to enable the overflow interrupt, then finally RTC.CTRLA to determine the prescaler value and enable the RTC. (Hint 1: There are many different combinations of PRESCALER


and PER that can be used, but one convenient choice for PRESCALER is DIV1024, which results in 32768/1024 = 32 counts per second. Hint 2: Search for RTC_PRESCALER in iotn416.h to find the group configuration constants for prescaler value).

4. In main.c, add some code to the RTC interrupt handler ISR(RTC_CNT_vect) that will flash an LED for 50 milliseconds so that it can be observed when an interrupt happens. (Hint: Copying and pasting some of the LAB1 application code for turning on and off an LED and using _delay_ms() is an efficient way to do this.)

5. Below the “// Put LAB2 APPLICATION code below this line” comment, add a call to the sei() function to enable global interrupts.

6. Just below the call to sei(), add a while(1){ } loop with nothing inside the loop.

7. Click on Debug Start without Debugging.

8. Verify that the LED flashes briefly every 3 seconds as it should from the interrupt handler. If it does not, inspect the code for errors.

Result: The RTC interrupt causes an LED to flash every 3 seconds. To do: Reduce current consumption by using sleep mode.

9. Select Tools Data Visualizer to open the current vs. time graph.

10. Click on Start to view the current consumption vs. time in Data Visualizer. Note that, even when the interrupt is not in progress, current consumption is nearly 1 mA.

11. Click on Stop to stop the real-time current graph.


12. Current consumption can be greatly reduced by using sleep mode when the interrupt is not active. Before sleep mode can be used, however, the sleep mode must be selected and enabled using the SLPCTRL.CTRLA register, shown in the datasheet excerpt below.

Add a line of code in the main.c LAB2 INIT section to write to SLPCTRL.CTRLA to select STANDBY sleep mode and enable sleep mode. (Hint: Search for SLPCTRL_SMODE in iotn416.h to find the group configuration constants for sleep mode.)

13. Inside the LAB2 APPLICATION while(1){ } loop , add a call to the sleep_cpu() function. This function call is what actually puts the device to sleep.

14. At the top of main.c, specify the correct header file by adding the following line of code: #include <avr/sleep.h>

15. Select Debug Start without Debugging to begin running the code.

16. Select Tools Data Visualizer and click on Start to view the current consumption in Data Visualizer. The current will be much lower, but there is no interrupt happening. This is because the RTC was not enabled to run in standby sleep mode. When the chip goes to sleep, the RTC stops running and an interrupt is never generated.


17. To fix this problem, modify the line of LAB2 INIT code that writes to RTC.CTRLA so that the RUNSTDBY bit is changed to 1, allowing the RTC to operate while the device is in STANDBY sleep mode.

18. Select Debug Start without Debugging to begin running the code. Now the interrupts will work and the LED will flash.

19. Select Tools Data Visualizer and click on Start to view the current consumption in Data Visualizer. The current consumption will be near 0 outside the interrupt because the device is in sleep mode.

20. Click on Stop to terminate the real-time graph.

21. In the interrupt service routine in main.c, comment out the code that turns on and turns off the LED, but leave in the 50 millisecond delay.

22. Add a line of code at the bottom of the interrupt handler that adds 3 to the second_count variable every interrupt.

23. Select Debug Start without Debugging to begin running the code.

24. Select Tools Data Visualizer and click on Start to view the current consumption in Data Visualizer. Now the desired behavior occurs: less than 100uA consumption, except when the interrupt handler is active.

25. Click on Stop to terminate the real-time current display.

Result: Current consumption was significantly reduced by using sleep mode. LAB2 is now complete.


LAB 3: Using 1 pin to drive an LED and detect a pushbutton Objectives: Use 1 pin to flash an LED and detect a pushbutton.

Procedure: To do: Write code that uses one pin to drive an LED and detect a pushbutton. 1. Click on the main.c tab in Atmel Studio to view/edit the code.

2. Under the “// Put LAB3 APPLICATION code below this line” comment in

main.c, add a while(1){ } (forever) loop that turns on LED1 for 50 milliseconds then turns it off for 50 milliseconds by changing the I/O to an input. (Hint: Copying and modifying code from LAB1 for flashing LED3 is an efficient way to do this.)

3. Select Debug Start without Debugging to run the code to verify that it works as expected by flashing LED1 about 10 times per second.

4. At the end of the 50 millisecond LED off interval, at the bottom of the while(1) loop, add some code that reads the B1 pushbutton value and uses it to control whether LED4 is lit. (Hint: Copy and modify some code from LAB1).

5. Select Debug Start without Debugging to begin running the code. Verify that LED4 follows the presses of button B1.

6. Now modify the while(1) loop with while(condition) so that when button B1 is pressed the MCU will get out of the loop and LED1 will stop flashing. This will cause LED1 to act as a flashing alarm indicator that is reset by pressing button B1.

7. Select Debug Start without Debugging to begin running the code. Verify that LED1 is flashing rapidly.

8. Press B1 briefly and verify that LED1 stops flashing. This demonstrates that one pin can be successfully used for both driving an LED and detecting the press of a pushbutton, as long as there are sufficient delays in the code.

Result: B1 was used to stop the flashing of LED1, on the same pin. LAB3 is complete.


LAB 4: Using ADC to monitor battery voltage Objectives: Set up the ADC. Set up the fixed voltage reference. Monitor battery voltage without using an extra pin. Warn when Vbat<2.5V and Vbat<2.0V on LEDs.

Procedure:

To do: Use the ADC to measure battery voltage and light LEDs when battery voltage is below 2.5V and 2.0V.

1. Before the ADC can be used, a voltage reference must be set up and enabled for the ADC. The VREF module is used to perform this function. The two VREF control registers, VREF.CTRLA and VREF.CTRLB, are shown in the datasheet excerpt that follows.


Under the “// Put LAB4 INIT code below this line” comment in main.c, set up the VREF module to generate 1.5V for the ADC using the VREF.CTRLA register, and enable the ADC reference using the VREF.CTRLB register. (Hint: Search for VREF_ADC0REFSEL in iotn416.h to find the group configuration constant for selecting the 1.5V reference.)

2. The ADC0.CTRLC and ADC0.MUXPOS registers are shown in the datasheet excerpt that follows.


As part of the LAB4 INIT code, use the ADC0.CTRLC register to set up the ADC with its reference voltage as VDD, and use the ADC0.MUXPOS register to set up the ADC with its input voltage as INTREF, the internal reference from the VREF peripheral. (Hint 1: Search for ADC_REFSEL in iotn416.h to find the constant for selecting VDD in ADC0.CTRLC. Hint 2: Search for ADC_MUXPOS in iotn416.h to find the constant for selecting INTREF in ADC0.MUXPOS.)


3. The detailed description of the ADC0.CTRLA register follows.

As part of the LAB4 INIT code, write to ADC0.CTRLA to enable the ADC.

4. Below the “// Put LAB4 APPLICATION code below this line” comment,

add an empty while(1){ } loop.


5. The ADC0.COMMAND register is used to start an ADC conversion and is also used to determine when the conversion is complete. The datasheet excerpt for this register is below.

Within the LAB4 APPLICATION while(1) loop, add some code that starts an ADC conversion and waits for it to complete.

6. Add a 16-bit adc_value variable declaration at the beginning of the main() function as follows: uint16_t adc_value;


7. After an ADC conversion is complete, the ADC result appears in the ADC0.RES register as shown in the datasheet excerpt below.

Because the input to the ADC is a constant 1.5 V from VREF, and the ADC reference is the supply voltage Vdd, the ADC result will be RES=(1.5/Vdd)*1024. After the conversion is complete, add a line of LAB4 APPLICATION code that saves the conversion result (ADC0.RES) in adc_value. Then add some code that uses adc_value to light LED1 as a low battery indicator when Vdd < 2.5V and LED2 as a very low battery indicator when Vdd < 2.0V.

8. Select Debug Start without Debugging to run the code.

9. Select Tools Data Visualizer and click on the gear symbol beside Power to access the Voltage Output adjustment control, then adjust the supply voltage to the P4 board from 2.8V down to 1.8V in approximately 0.2V steps (don’t forget to click OK to write the new value) and verify that the low battery indicators work as intended.

10. Adjust the voltage output back to 2.8V so it is ready for the next lab, and click on OK to close the Power Configuration interface.

Result: Low battery indicators for 2.5 and 2.0V were implemented. LAB4 is complete.


LAB 5: Using 3 pins to drive an I2C display Objectives: Set up and use the ATtiny416 to drive an OLED display via I2C. Use character expansion on-the-fly to minimize memory usage.

Procedure:

To do: Add your name to “MASTERS 2017” on the OLED display.

1. In Atmel Studio, select File Open Project/Solution... to bring up the Open Project window.

2. Find and select the C:\MASTERs\21110\devp4a5\devp4a5.atsln file and click on Open to open a pre-defined project that will be used as the basis for LAB 5.

3. In the Solution Explorer which appears in Atmel Studio as shown below, double click on main.c to view/edit the contents of the main.c file.

4. Scroll through the main.c code to get an overview. The main.c file starts with

many constant definitions, including the bitmaps that are used to generate the


characters on the OLED display. Following the constants, there are several functions defined that handle the low-level details of initializing and sending data to the display such as twi_enable(), twi_send_packet_p(), and clear_oled(). The main() code, shown below, starts by holding the OLED reset line low and selecting the alternate TWI pins for the display. After 0.5 seconds, the reset line is released. The twi_enable() function is called to enable the TWI module, then the twi_send_packet_p() function is used to send a series of initialization commands to the OLED display. A clear_oled() function is called to insure that all bits of the display are cleared prior to writing any display data. The send_text_to_oled_p() function is then called twice to send “MASTERS” and “2017” to the display. The four arguments to the send_text_to_oled_p() function are: pointer to characters, number of characters to be sent, row index on the display where characters begin (starting with 0), and column index on the display where characters begin (starting with 0).

5. Put the slide switch on the P4 board in the SET position to insure that the OLED display is powered.

6. Select Debug Start Without Debugging to run the code. "MASTERS 2017" will appear on the OLED display. Note that, because each character is defined using 6 bytes, or 48 bits, the characters appear quite small on the 128x64 display – approximately 1 millimeter by 1 millimeter. One possible way of increasing the size is to define each character with more bits. For example, if each character was defined with 24 bytes (192 bits), then each character would occupy about 2mm by 2mm on the display. The problem with this approach is flash memory usage. In order to display 40 different characters, this would require 40*24=960 bytes, or about 1/4 of the ATtiny416 device’s 4Kbyte flash memory.


7. A better approach with respect to flash memory conservation is to expand each pixel

into 4 pixels on-the-fly just before it is sent to the display, so the flash memory utilization for character storage remains small. A function for sending expanded text, send_exp_text_to_oled_p(), is defined in main.c. This function has the same arguments as send_text_to_oled_p(), but each character is expanded on-the-fly to occupy 4 times the area on the display. In main(), replace the two calls to send_text_to_oled_p() with calls to send_exp_text_to_oled_p().

8. Select Debug Start Without Debugging to run the code. Verify that "MASTERS 2017" appears on the OLED display, twice as high and twice as wide as previously.

9. Just below the comment “// More text can be sent to the display below this line”, add some code that shows your name on the third line of the display. A character array, text_myname, already exists that you can use for this purpose, but it contains “MYNAME”. You will need to change its contents (by copy and paste from the all_char array that appears above it in the code).

10. Select Debug Start Without Debugging, and verify that your name appears on the third line of the display.

Result: Your name was added to the P4 OLED display.

Lab 5 Bonus To do: Add code for displaying power supply voltage on the P4 OLED display.

11. Below the code for displaying your name in main.c, there exists a while(1) loop for getting stuck followed by code from the LAB4 solution that initializes the VREF and ADC (see the code excerpt on the next page). This is followed by a second while(1) loop that performs several actions. Within the second while(1) loop, every 0.5 seconds, an ADC conversion is performed and then the ADC value is converted to Vdd in millivolts (vdd_mv). At the moment there is nothing to display Vdd. However, there is some code that shows how to display a single digit from 0 to 9. Comment out the first while(1) loop for getting stuck so that the ADC interaction code can execute.


12. Select Debug Start Without Debugging to run the code. Verify that the 4th row of

the P4 OLED display shows a digit that repeatedly counts from 0 to 9.

13. Comment out the call to send_exp_text_to_oled_p() that displays the single digit on the 4th row of the display.

14. Write some code that uses vdd_mv to display the voltage on the 4th row of the display in X.XX Volts format – for example, if vdd_mv is 2340 mV, then the display should show 2.34 V.

15. Select Debug Start Without Debugging to run the voltage display code.

16. Once the voltage display code is running and appears to be working, select Tools Data Visualizer, etc. to adjust the supply voltage to the board and verify that the display shows the correct supply voltage as the voltage is changed.

Result: Supply voltage is displayed on the OLED display on the P4 board. LAB5 is now complete.


P4 Board Schematic

masters 2017 - lab manual for 21110...

Documents