Assembly Robot Lab 4 – Handling the Intersections with Delays and Interrupts

Introduction

This lab is designed to help you understand how timers, interrupts, and finite state machines can be used to implement a method for how the robot moves through the maze. In the previous labs, we have only been concerned with getting the robot to move in a straight line and correct itself if it veers off course. The problem with that line following is that there is no way to recognize when the rooms have changed as your path through the maze will require turning at certain locations. You will be using delays, interrupts, and finite state machines in order to perform line following when needed and to be able to do a different action when an intersection is found. By the end of this lab, we should have the basic structure that we will be building upon in the remaining labs.

What Is New

The following instructions and assembly directives are used in Lab 4. If you have any questions on any instructions or assembly directives a nice source of information, in addition to your textbook, are AVR Instruction Set Manual and the Atmel AVR Assembler User Guide.

AVR Assembly Instructions

Data Transfer

lds r24, variable      // Load value from variable(or location in SRAM) to register 24
sts variable, r16      // Store value from register 16 to variable (or location in SRAM)
push r17               // Save the value from register 17 to the stack temporarily
pop r19                // Copy the last value from the stack to register 19.

Arithmetic and Logic

cbr r24, 0b01101101     // Clear the bits in register 24 designated with a value of 1. Locations with a value of 0 are left the same.
tst r16                 // Check to see if the value in register 16 is equal to zero or negative (does the AND operation with itself).

Control Transfer

cpi r24, 0x3C         // Compares the value in register 24 to the constant 0x3C
reti                  // Return from Interrupt Service Routine (will re-enable global interrupts)
sei                   // Set the I bit in SREG (enable global interrupts)

AVR Studio Assembly

Directives

.DSEG                       // Indicates the start of the Data Segment (SRAM)

example: .BYTE X      // Defines an SRAM variable called example that is in terms of bytes and takes up X bytes. (IE X=3 means it takes up 3 bytes)

Breaking the Objective into Parts

At the end of Lab 3, you should have gotten your robot to continuously follow a line and be able to cross over intersections at a slower speed instead of stopping. This allows us to use some creative solutions for handling the detection of intersections and performing an action after that. As it is, the program from Lab 3 is suited for the parts of your path that are straight lines but is not capable of changing directions. We want to be able to separate that section of code from the main loop and execute it when the conditions are right. The end goal of Lab 4 is to have the robot follow a line to an intersection, cross it and move to the center of the room, and then spin in place. The spinning in place is a temporary output to show that the robot has switched from the line following algorithm to making a decision after it has entered a room in the maze. From this high level concept, we will go over how it can be broken down into the code that needs to be added.

In order to implement this, the first key change is that there are two situations that the robot should be running through depending on the position of the robot. The first one is that the robot should be executing the line following algorithm if an intersection has not been encountered. The second one is to perform the spinning action and stop the line following if an intersection was found. While there are many ways that this can be implemented, we will be using a finite state machine to handle the two situations as a part of the main loop. It provides a structure that separates the two sections of code and allows for expansion if more states are needed.

For the finite state machine to work,  there are four things that need to be discussed further.

  1. The structure of the main loop needs to be changed in order to execute the appropriate state at any given point in time.
  2. There needs to be something to keep track of which state should be executed. This can be done with a variable that represents the next state to go to.
  3. The next state variable needs to update when an intersection is detected.
  4. The updating of the variables should occur automatically without having the program wait for something to happen.

The first two issues will be handled by the finite state machine and the next state variable that we will be creating. The third issue will be dealt with during the line following state as that is when the transition should be occurring. The last issue is where the timer and the overflow interrupt will be used. As many of these parts are interconnected with each other, they will be covered in the order that is the easiest to follow.

One final issue that can make this lab seem too complicated to follow is where the robot starts to execute its spin. While it will not be a problem right now, it can greatly affect your rate of success with going through the entire maze. This is because as the robot is moving, there are several factors such as the battery power remaining, the friction on the wheels, and other things that affect how fast the motors move. This leads to the robot drifting off the line or completely missing the line after turning. Additionally, the position of the robot when it begins the turn plays a big role in this problem. In order to make sure this is not an issue, we will make sure that the robot is in the center of the intersection before it begins to spin. As you will see,  the robot will have to pass over the intersection in order to be in the right position, which conflicts with our goal of changing states when the intersection is detected.

The solution that we will be using here is to utilize a timer to trigger the transition between states. By turning a timer on when the intersection is detected, we can avoid adding several conditional checks or looping until the robot has crossed the line and is in the center of the room. It also allows the robot to continue executing the line following, which does not change any of the code as we will wait until the timer overflows. The timer overflow interrupt will then update the next state variable so that the spin action will be executed. This requires us to have determine the right amount of time before the overflow occurs as it can vary based on the motor speeds. However, that is easier to take care of than the alternatives.

Finite State Machine

The following figure shows the general process that the finite state machine will follow.

When the robot is turned on, it will automatically start with State 0. This is to make sure the robot can move forward and follow the line to the next room in the maze. As long as the intersection is not detected, it will keep running State 0. The moment an intersection is detected, it will trigger the change to State 1 but it will not be going there right away. We are using Timer 1 to delay the transition for a certain amount of time so that the robot is in the center of the room. It will still be executing State 0 until Timer 1 has overflowed. All of this can be represented with the following flow chart.

Once the transition has occurred, it will go to State 1 and then spin in place. In order to implement the finite state machine, the structure of our main program will be changed. The code that was in the main loop will need to be removed. As a starting point, you should have just the label and the rjmp loop instruction.

loop:

    // all other code has been removed

    rjmp loop

From here, the code can be broken into three parts. One section is used to determine the appropriate state to execute. Another section will produce the output needed for State 0 and the last section will handle the output needed for State 1. In later labs, modifications will be made to the sections as needed but the general structure will stay the same. This can be represented by the following diagram.

loop:
    // Code to determine which state to execute
    // Will branch or jump to appropriate labels


    // Code for State 0 output
    // Will branch or jump to endloop label when done

    // Code for State 1 output
    // Will branch or jump to endloop label when done

endloop:
    rjmp loop

For the first section, we will need to create a variable to keep track of the next state to execute and to check what value it is. Variables are different from registers in that the data is saved in SRAM and it cannot be accessed by the CPU directly. While this may seem like a downside, it does not take up one of the 32 registers and will persist as long as the program is running. It will help with the problem of running out of registers to hold data in and can be retrieved at any time. To define this SRAM variable, you will need to use the following format.

table: .BYTE 4

The first column is the label assigned to the SRAM address being reserved for the variable. You can use any name as long as it is valid. In this case, we want to call it next_state. The second column defines the data type. It can be in terms of bytes (8 bit values) or words (16 bit values). We will typically be dealing with bytes but be aware of the alternatives. The third column indicates the number of SRAM address to reserve. This is more or less the size of the variable. The example variable will reserve 4 bytes of space for the variable called table. Use this knowledge to define the next_state variable which needs only one byte of space. One final detail about defining SRAM variables is that it must be placed in a different section of our program as SRAM is part of the data segment while FLASH is part of the code segment. What this means is that you will need to insert the following lines above .CSEG

.INCLUDE 

.DSEG
next_state: .BYTE 1

.CSEG
.ORG 0x0000
RST_VECT:

One common misconception people have about defining SRAM variables is that everything is ready to go once it has been defined. However, the starting value of the variable has not been defined. It will default to whatever value is currently at that SRAM address, which could potentially be any value. This means every SRAM variable will also need to be initialized in order to prevent any errors with calculations or checking which state to execute. The initialization is done by saving the desired value from a register to the SRAM variable. For the finite state machine, we want to define a value to represent the states. We will be defining the binary value of 00 as state 0 and 01 as state 1 as shown below with equate statements. From there, you can save the appropriate value.

// Equate statements
.EQU S0=0b00
.EQU S1=0b01

// Variable initialization
ldi r16, S0
sts next_state, r16

Now we can handle the code to determine what state to execute. As shown in the diagram at the beginning of the section, the main loop will begin by checking if next_state is equal to S0 or S1. As it is stored in an SRAM variable, you will need to load it into a register in order to perform a comparison as shown below.

loop:
    lds r17, next_state
    cpi r17, S0
    breq state0
    cpi r17, S1
    breq state1
    rjmp endloop

This will check what the value of next_state is for that iteration of the loop and branch to the appropriate state. If it does not match any of the valid states, it will not execute the code and go to the end of the loop. With that out of the way, we can focus on defining the code for State 0.

State 0 Output Code

The main output for State 0 is the line following code. This has already been completed from previous labs and will just be moved from the beginning of the main loop into this area. The only addition that needs to be made is to detect the intersection and to turn on Timer 1 in order to change the states. This will involve a slight change to the structure from Lab 3 that controlled the motor speeds.

To start, you will need to copy over the lines of code from Lab 3 that configure the motors to move forward, to get the values from the IR sensors, and to output it to the motors. The code should look something like this:

.INCLUDE m32u4def.inc

// These are arbitrary values. Make sure that you use your values from Lab 2
.EQU RightHIGH = 0xFF
.EQU LeftHIGH = 0xFF
.EQU RightLOW = 0xAF
.EQU LeftLOW = 0xAF

.EQU S0 = 0b00
.EQU S1 = 0b01

.DSEG 
next_state: .BYTE 1

.CSEG
.ORG 0x0000
RST_VECT:
    rjmp reset
.ORG 0x0100 
.INCLUDE "robot3DoT.inc"
reset:
    ldi R16, HIGH(RAMEND)
    out SPH, R16
    ldi R16, LOW(RAMEND)
    out SPL, R16
    call Init3DoT

    ldi R16, S0
    sts next_state, R16
loop:
    lds R17, next_state
    cpi R17, S0
    breq state_0
    cpi R17, S1
    breq state_1
    rjmp endloop

state_0:
    ldi R24, 0x51
    call ReadSensors
    call WriteToMotors

Next, we need to address the code to detect the intersection. The code from Lab 3 checks one motor at a time and does not handle both at once. It also only changes the speed of each motor separately and could be improved on. As covered in lecture, we can make use of comparisons to evaluate what situation is being detected by the IR sensors. There will need to be some processing involved to make sure that we are only looking at the desired bits and nothing else. Since the values from the IR sensors are placed into R24 to implement line following, we can use those bits to determine if the robot is hitting a line or an intersection. Specifically, that would be A_ON and B_ON which are bits 5 and 2. As the remaining 6 bits could be any combination of values, we want to remove them from the equation so that it makes it easier to handle the comparisons. This can be done with the cbr instruction, which clears the indicated bits in a register. With that taken care of, we can use the cpi instruction in order to determine which of the four possible situations the sensors could be seeing. Those situations are listed below along with the value we should be expecting to see in register 24.

Situation Motor Speeds Value in R24
Robot following the line (both on white) Right – Max speed

Left – Max speed

0b00100100
Robot veering to the left (Left on white, Right on black) Right – Min speed

Left – Max speed

0b00100000
Robot veering to the right (Left on black, Right on white) Right – Max speed

Left – Min speed

0b00000100
Robot on intersection (both on black) Right – Min speed

Left – Min speed

0b00000000

We will now replace the branching structure that was used in Lab 3. The code will look like this.

state_0: 
    ldi R24, 0x51 
    call ReadSensors 
    call WriteToMotors
    cbr R24, 0b11011011
    cpi R24, 0b00100100
    breq onLine
    cpi R24, 0b00100000
    breq rightOnLine
    cpi R24, 0b00000100
    breq leftOnLine
intersection:

Feel free to use different names for the labels. The ones chosen here are selected to be the most descriptive of what is happening. For the code that goes into each of the new sections, we will go over just two of the four. You will be expected to complete the rest.

The code for the intersection section needs to turn Timer 1 on and is done with the following. Keep in mind that we have not determined the appropriate prescale value to use for the timer, so this is a preliminary number to use. Make sure to come back and update this value as needed.

intersection:
    // Set motors to appropriate speed
    ldi R24, RightLOW
    ldi R22, LeftLOW
    call AnalogWrite
    // Load value to turn timer 1 on
    ldi R16, 0x01
    sts TCCR1B, R16
    rjmp endloop

The code for the other three sections only needs to change the motor speeds. It will look like the following. Make sure to handle each situation appropriately. Each of these labels can be placed after the previous rjmp endloop.

onLine:
    ldi R24, RightHIGH
    ldi R22, LeftHIGH
    call AnalogWrite
    rjmp endloop

In the end, the code should look something like this.

State_0:
// Code for line following
    ldi R24, 0x51 
    call ReadSensors 
    call WriteToMotors
// Processing information from IR sensors
    cbr R24, 0b11011011 
    cpi R24, 0b00100100 
    breq onLine 
    cpi R24, 0b00100000 
    breq rightOnLine 
    cpi R24, 0b00000100 
    breq leftOnLine 
intersection:
// Code for intersetion
    rjmp endloop
onLine:
// Code for onLine
    rjmp endloop
rightOnLine:
// Code for rightOnLine
    rjmp endloop
leftOnLine:
// Code for leftOnLine
    rjmp endloop

With that, we are done with State 0 and can move onto State 1.

State 1 Output Code

For the State 1 code, the only thing that needs to be done is to configure the motors to spin in place. This can be done in either direction (clockwise or counter-clockwise) as long as the motors are moving in the appropriate manner. The code should look like this.

State1:
    // code to configure motors

    rjmp endloop

Setting up the Timer

As discussed in Prelab 4, there are several steps involved with setting up the timer to achieve a specified delay. We will review these steps and go over what is needed for Lab 4.

It is important to note that the timer registers are not part of the general purpose registers that are in the AVR CPU. They are located within the Extended I/O registers which are a part of the SRAM address space, not the I/O address space. We are only concerned with the normal mode which will increment by 1 until it reaches the maximum value 0xFFFF and then restarts at 0x0000 when it overflows. You may notice that there are terms for TOP, BOTTOM, and MAX. These can be changed depending on the operating mode but you should consider MAX to be 0xFFFF and BOTTOM to be 0x0000 for Timer 1 in our course.

Figure 1: ATmega32u4 Operating Modes

As we are only working in normal mode, you will not need to modify any of the configuration registers besides TCCR1B which stands for Timer/Counter 1 Control Register B. This is because the default setting for the other registers is to start in normal mode.

Figure 2: TCCR1B Description

The main bits that we are concerned about in TCCR1B are the clock select or CS bits. These bits allow us to define how quickly the timer will increment and ultimately how long it takes to overflow. The options for this are all based on the system clock signal coming from the microcontroller or an external clock source as indicated in Figure 3. You will need to select the appropriate combination for the bits in order to configure the timer for your desired delay. For example, if the pre-scale value of 256 is chosen with a system clock frequency of 16 MHz, the clock frequency for the timer will effectively be 62.5 KHz and result in a maximum delay of 1.0486 seconds.

Figure 3: Pre-scale Value Selection

The last of the registers that you will need to become familiar with are the timer counter registers (TCNT1H and TCNT1L) and the timer interrupt flag register (TIFR1). They are relatively self explanatory, with the timer counter registers holding the current value before the next increment while the timer interrupt flag register has the current value of the overflow flag (TOV1). We are mainly concerned with the TOV1 bit which indicates if the timer has overflowed (becomes 1) or not. One important thing to keep in mind is that the timer does not automatically tell the microcontroller that the overflow has occurred unless the corresponding interrupt was configured. If that has not been set, the microcontroller will only know that the timer is finished when it is programmed to check the value of the TOV1 bit.

Figure 4: Timer 1 Counter Registers


Figure 5: Timer 1 Interrupt Flag Register

The delay that you will need to implement will be dependent on your robot. As each robot has different maximum and minimum speeds, they will each get to the center of the room at different times after hitting the intersection. Since you will not know what is the right value at the start, we will begin with a delay of 500 milliseconds. This will be changed after the rest of the code has been completed as you will need to test the robot and make sure it does not go beyond the center of the room. If it crosses two or more intersections, you will need to lower the delay. Perform the calculations to get the start value and pre-scale for Timer 1 as done in Pre-lab 4.

Once those values have been determined, we can write the code needed. In order to configure the timer for the desired delay and deal with the timer overflow interrupt, you need to save the appropriate values to the TCCR1B, TIMSK1, TCNT1H, and TCNT1L registers. For example, if the values to save are 0x00 for TCCR1B, 0x01 for TIMSK1, 0x4D for TCNT1H, and 0x35 for TCNT1L, the code would look as follows. This code should go somewhere in the reset section.

clr r16
sts TCCR1B, r16
ldi r16, 0x01
sts TIMSK1, r16
ldi r16, 0x4D
sts TCNT1H, r16
ldi r16, 0x35
sts TCNT1L, r16

One key thing to keep in mind here is that we will have the timer turned off until the intersection is detected. What this means is that the clock select bits should be 000, which will prevent it from counting when the robot is turned on. We will write the value that you calculated earlier into TCCR1B in order to turn the timer on and allow it to trigger the timer overflow interrupt.

Understanding how the Timer 1 Overflow Interrupt works

We will briefly go over how the interrupt handling process works and walk you through the code needed to implement that. You can find additional details and examples in Lectures 10, 11, and 12.

Interrupts are used in order to allow the microcontroller to temporarily stop running the main program and handle any urgent situations that come up. It can then execute code that is specifically for that scenario before resuming normal operation. There are three key details that have to be present in order for this to occur.

1) Interrupts have to be globally enabled by setting the I bit to 1. They are disabled by default and all interrupt flags will be ignored.

2) The desired interrupt needs to be configured and enabled. Each subsystem has its own interrupt and configuration scheme. It is all off by default and will need to be set up by the programmer.

3) The interrupt flag will need to be set in order to initiate the process. The user does not need to handle this as each interrupt will trigger in a specific situation. For example, the timer overflow interrupt will set the timer overflow flag (TOV1) when the timer resets from its maximum value to 0.

If all of these conditions are met, it will go through the following process.

  1. Current instruction will be completed
  2. Jump to location in Interrupt Vector Table based on which interrupt flag was triggered.
  3. Execute Interrupt Service Routine while global interrupts are disabled
  4. Return from Interrupt Service Routine and re-enable global interrupts.
  5. Return to main program

One key detail that many people forget about when implementing the interrupts is that the Interrupt Vector Table (IVT) and Interrupt Service Routine (ISR) are not automatically defined. It is the programmer’s responsibility to add in what is needed. Therefore, for the implementation of interrupts, you will need to take care of four different tasks.

  • Enable global interrupts
  • Configure and enable the specific interrupt (local enable)
  • Fill in the IVT for the desired interrupt
  • Create the ISR for the desired interrupt.

As mentioned in lecture, the IVT is located at the very beginning of flash program memory. Each interrupt is allocated two flash program words, which is not enough in most cases. The reason for this is that you are expected have a jump instruction here that will go to the ISR for the interrupt. For this lab, it will look something like this.

.ORG 0x0028
jmp T1_OVF_ISR

It places the jump instruction to the ISR at the proper location within the IVT. We can also use the appropriate name for the interrupt if you happen to switch microprocessors (IE changing to Atmega 328p instead of Atmega 32u4) with .ORG OVF1addr

This should be placed before the include files but after the RST_VECT label.

Next, we need to enable the interrupt. This is done by turning on the timer 1 overflow interrupt by setting the timer 1 overflow interrupt enable bit (TOIE1) to 1 in the timer 1 mask register (TIMSK1). Then we will enable global interrupts by setting the I bit in SREG to 1.

ldi r16, 0x01
sts TIMSK1, r16    // local enable
sei               // global enable

This code should be placed at the end of the reset section and right before the loop label.

Finally, we need to define the ISR. As the ISR can be executed at any point in time, there are certain precautions that need to be taken to make sure that the program does not lose track of what it was doing. For example, if the code in the ISR will change SREG, we do not want to destroy what was in there in case it is needed when the program goes back to normal operation. This is where you will need to save and restore the value of registers used with the push and pop instructions. The ISR will have the following structure.

T1_OVF_ISR:
    push r15
    in r15, SREG
    // push any other temporary registers used

    // Code to execute

    // pop any temporary registers used
    out SREG, r15
    pop r15
    reti

Within that structure, we will be adding the code to implement what was discussed in the finite state machine. As mentioned before, the next_state variable needs to change to S1 when timer 1 has overflowed. The code to do that is as follows. We are also turning off the timer in order to prevent it from triggering the interrupt again accidentally.

ldi r16, S1
sts next_state, r16
clr r16
sts TCCR1B, r16

This should be placed outside of the main loop as it also functions as a subroutine. The next section will go over what it looks like with everything put together.

Putting it all Together

When everything is put together, it should look like this. Please note that certain parts of the lab are omitted to save space. You should be able to recognize where the major labels are and organize it accordingly.

/* Title block */

.INCLUDE 
// Equate statements
.EQU RightHigh=0xFF
.EQU LeftHigh=0xFF
// Other equate statements
.EQU S0 = 0b00
.EQU S1 = 0b01

// Define SRAM variables
.DSEG
next_state: .BYTE 1

.CSEG
.ORG 0x0000
RST_VECT:
    rjmp reset
.ORG OVF1addr
    rjmp T1_OVF_ISR
.ORG 0x0100
.INCLUDE "robot3DoT.inc"
reset:
      // Previous code in reset section

     // Initialize SRAM variables
     ldi r16, S0
     sts next_state, r16
     // Configure timer 1
     clr r16
     sts TCCR1B, r16
     ldi r16, 0x5F // Replace with your start value
     ldi r17, 0xFF
     sts TCNT1H, r16
     sts TCNT1L, r17
     // Configure interrupt
     ldi r16, 0x01
     sts TIMSK1, r16
     sei
loop:
     // All of the code for the finite state machine
     rjmp loop

     // All subroutines
ReadSensors:

     // Code for that subroutine

     ret

T1_OVF_ISR:
     push r15
     in r15, SREG
     // push other temporary registers
     push r16
     // code to execute
     ldi r16, S1
     sts next_state, r16
     clr r16
     sts TCCR1B, r16
     // pop temporary registers
     pop r16
     out SREG, r15
     pop r15
     reti

Design Challenge – Staying in a Square (5 Points)

Modify the code so that the robot will go back into line following after it has executed the action. You will also need to create subroutines that will handle turning right or left instead of spinning in place. The hint for this is to use another timer delay to take care of the amount of time spent turning. It is not recommended to use the same timer for two different delays as you will need to make the code more complicated to handle both situations. Also consider what will need to happen at the end of state 1 in order to get the robot to move in a square.

Lab 4 Deliverable(s)

All labs should represent your own work – DO NOT COPY.

Submit your list file as defined below. Make sure that the code compiles without any errors. Do not forget to comment your code.

Lab 4 Demonstration

At sign-off, your robot will start following the line when placed on the maze. It must cross the first intersection and perform the spinning action.