Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Next revision		Previous revision
learn:microprocessor:tutorials:pic32-interrupts:start [2017/12/18 20:02] – created Marthalearn:microprocessor:tutorials:pic32-interrupts:start [2022/10/04 11:38] (current) – external edit 127.0.0.1
Line 13: Line 13:
  
 ==== Inventory ==== ==== Inventory ====
-  * 1 [[http://store.digilentinc.com/digilent-pro-mx7-pic32-based-embedded-systems-trainer-board/| Digilent Pro MX7]]+  * 1 [[https://digilent.com/shop/digilent-pro-mx7-pic32-based-embedded-systems-trainer-board/| Digilent Pro MX7]]
   * [[http://www.microchip.com/mplab/mplab-x-ide| MPLAB X IDE]]   * [[http://www.microchip.com/mplab/mplab-x-ide| MPLAB X IDE]]
-  * 1 [[http://store.digilentinc.com/pmod-step-stepper-motor-driver/| Pmod STEP]]+  * 1 [[https://digilent.com/shop/pmod-step-stepper-motor-driver/| Pmod STEP]]
   * 1 Stepper Motor (5V – 12V, 25 Ω, unipolar or bi-polar)   * 1 Stepper Motor (5V – 12V, 25 Ω, unipolar or bi-polar)
-  * 1 Logic analyzer or oscilloscope (Digilent [[http://store.digilentinc.com/analog-discovery-100msps-usb-oscilloscope-logic-analyzer-limited-time/| Analog Discovery]] or [[http://store.digilentinc.com/analog-discovery-2-100msps-usb-oscilloscope-logic-analyzer-and-variable-power-supply/| Analog Discovery 2]] recommended)+  * 1 Logic analyzer or oscilloscope (Digilent [[https://digilent.com/reference/test-and-measurement/analog-discovery/start| Analog Discovery]] or [[https://digilent.com/shop/analog-discovery-2-100ms-s-usb-oscilloscope-logic-analyzer-and-variable-power-supply/| Analog Discovery 2]] recommended)
  
 ---- ----
Line 26: Line 26:
 \\ \\
 <html> <html>
-<a href="https://reference.digilentinc.com/learn/microprocessor/tutorials/pmod-step-parts-layout/start" class="btn btn-success" role="button">Pmod STEP Parts Layout</a>+<a href="/learn/microprocessor/tutorials/pmodstep-parts-layout/start" class="btn btn-success" role="button">Pmod STEP Parts Layout</a>
 </html> </html>
 \\ \\
 \\ \\
 <html> <html>
-<a href="https://reference.digilentinc.com/learn/microprocessor/tutorials/pic32-interrupts/start" class="btn btn-success" role="button">PIC32 Interrupts</a>+<a href="/learn/microprocessor/tutorials/pic32-interrupts-appendices/start" class="btn btn-success" role="button">PIC32 Interrupts</a>
 </html> </html>
 \\ \\
 \\ \\
 +
 +==== Mechanics of Interrupts ====
 +Preemption by an interrupt causes the processor to stop the execution of the current code flow and begin execution of a special function called an “interrupt handler” or “interrupt service routine” (ISR). In previous projects, the order in which tasks were started and completed was strictly controlled by the order in which code was executed in the program. In this project, tasks are started and completed based on a programmed prioritization.
 +
 +An [[http://en.wikipedia.org/wiki/Interrupt| interrupt]] is a signal triggered by an event. The computer suspends what would normally be the next instruction of a task in one part of a program and begins executing code to complete an entirely different task. This occurrence of events can be periodic (deterministic) or aperiodic (sporadic). An example of a deterministic event is a timer flag being set. Sporadic interrupts are the result of an unpredictable event such as a divide by zero error, low power detection, serial data received flag or even pressing a button. These signals cause the microprocessor to implement a sequence of operations that results in an orderly way of suspending one task, executing an entirely different task, and resuming the original task.
 +
 +The three main types of interrupts are software, internal hardware, and external hardware. Interrupts that are initiated by some event inside the microprocessor are also commonly referred to as exceptions or traps. Software interrupts are explicitly internally triggered by some instruction within the current program and are commonly referred to as trap instructions. Exceptions are internally generated hardware interrupts triggered by errors detected during software execution, such as illegal math operations (overflow, divide-by-zero), debugging (single-stepping, breakpoints), and invalid machine instructions or operational codes (opcodes). Finally, external hardware interrupts are exceptions initiated by hardware other than the CPU. Both the software code and the processor architecture determine how exceptions are prioritized and processed.
 +
 +The [[https://en.wikipedia.org/wiki/Context_(computing)| context]] defines the state or operating conditions of the processor. In order to properly resume executing the task that was interrupted, the ISR is responsible for saving and restoring the context of the code that is interrupted. At the very least, the context consists of the processor register values, the flag register, and the program address of the next instruction to be executed when the ISR has completed. The C compiler is directed to generate code segments called a prologue and an epilogue. The prologue code saves the processor's context prior to executing the code that you have generated to service the interrupt. The epilogue code restores the context at the end of the ISR and redirects the execution of computer code back to the instruction that was preempted. For the PIC32 processor, the C compiler generates 33 assembly language instructions to save the processor context and an equal number of instructions to restore the context, thus requiring approximately 0.85 μs before and after executing the ISR code.
 +
 +Interrupt latency is defined as the time between the instant when an event generates the interrupt signal and the time when the first useful instruction in the ISR is executed. This latency is made up of two major components: the time required to save the processor context and the amount of time that an interrupt is disabled or deferred by higher priority interrupts.
 +
 +==== Managing Interrupts ====
 +Preemptive programs usually consist of two types of tasks: foreground and background. Foreground tasks are those preemptive tasks that the processor executes as soon as the need arises. Interrupts are assigned priority levels that dictate the order in which interrupts will be serviced. In the case of multiple foreground tasks both needing service at the same time, the higher the interrupt priority, the sooner the microprocessor executes the code to service that interrupt. Code executed immediately following a power-up reset runs at priority level zero and has no preemptive capability. This initial background task is responsible for setting up the resources for tasks that will eventually run as foreground tasks.
 +
 +Foreground tasks have preemptive capability by having higher priorities than background tasks. The foreground task ensures adequate response times, while the background task manages deferred processing of the foreground data. Background tasks are those that the processor executes whenever it has available time and is waiting for something more important to do. Background tasks generally run at the interrupt priority level zero within a while(1) { … } loop, where event detection by polling is common. Interrupt only systems that only have foreground processes respond quickly to both periodic and sporadic events but ignore potential work that can be allocated to a background process. The use of interrupts falls under the broad category of real-time task scheduling, and a thorough investigation of this topic is beyond the scope of this project.
 +
 +There are two types of preemptive operating schemes: nested and non-nested. Nested interrupt schemes allow higher priority level interrupts to preempt code that is servicing a lower priority interrupt. A non-nested interrupt scheme completes the execution of the code currently servicing an interrupt before it begins to service the code for any interrupt awaiting service regardless of interrupt priorities.
 +
 +Non-nested preemptive schemes are usually easier to manage, but they can result in priority inversion, where a low priority task blocks a higher priority task from running. This scheme is easier to manage, because the developer only has to focus on one ISR, and the operation that determines which interrupts to service resembles the process of polling that we did in Project 4. For non-nested interrupt schemes, we must individually check the flags set by the interrupting event to determine which event to service. All interrupts are assigned to priority level 1 and are vectored (sent) to the same ISR where the particular interrupt flag must be cleared. For multiple simultaneous interrupts, tasks are serviced in the order that the interrupt flags are polled. A non-nested priority scheme results whenever interrupts are enabled using the instruction INTEnableSystemSingleVectoredINT(); provided in the peripheral library.
 +
 +Nested priority schemes are generally more responsive, taking advantage of the fact that higher priority tasks can preempt (interrupt) lower priority tasks. The highest priority interrupt is guaranteed to have the lowest latency. However, nested priority schemes require more computer resources, such as time and memory, to accommodate context saving and restoring. Some low-end microcontrollers simply do not have sufficient memory and/or speed to support fully nested priority schemes. In reality, many embedded systems manage tasks using both nested and non-nested preemptive schemes as a result of either hardware and/or software limitations. Either interrupt management scheme can be used in combination with polling to detect events, as will be the case for Project 5.
 +
 +The PIC32MX family of processors can use polling, nested priority, and non-nested priority schemes simultaneously. The PIC32MX processors utilize two major software level priorities called the “Group Priority” and the “Subgroup Priority.” There are seven levels that can be assigned for the group priority (1-7), with one being the lowest priority and seven being the highest. An interrupt with a higher group priority will preempt an interrupt of a lower priority. There are four subgroup priority levels that can be assigned at each of the seven levels of group priority. Interrupts assigned to different group priority levels operate as nested interrupts.
 +
 +Multiple events can be assigned interrupt priorities at the same group level but at different subgroup levels. The sub-priority will not cause preemption of an interrupt in the same group priority level; rather, if two interrupts with the same group priority level are pending, the interrupt with the highest sub-priority will be handled first. The natural (hardware) priority scheme is asserted whenever multiple interrupts are generated simultaneously for events that are set for the same group and subgroup priority levels. (The notion of “simultaneous events” must be expanded to mean “if two interrupts are detected as waiting for service,” whether or not they occur at the same instant of time.) See Section 8 of the [[http://hades.mech.northwestern.edu/images/2/21/61132B_PIC32ReferenceManual.pdf| PIC32MX family reference manual]] for additional details of interrupt operations on the PIC32MX family of processors.
 +
 +In any case, for the PIC32MX family of processors, the interrupt flag bit must be cleared in software prior to completing the service of the interrupt, otherwise the same interrupt will be serviced again without an event to initiate its service.
  
 ---- ----
  
-===== Step 2: Building the Circuit ===== +===== PIC32 Interrupts ===== 
-Having chosen our resistor and capacitor values, we can begin putting the circuit together. We will be using the same circuit we first used in Debouncing via Software. In that project, the button bounce caused “noise” that occasionally made the LED glow dimly instead of blinking. The addition of our RC filter remedies this problem. Refer to Fig. 1, which illustrates the individual steps for modifying the circuit.+==== General Interrupt Requirements ==== 
 +There are four essential code elements required for a program to process interrupts using C—the declaration of the functions that will be used to service the interrupts, the code to initialize the resources that generate interrupts, the ISR code that will be executed in response to an interrupt and the instructions that enable interrupts in a global sense. There must be an ISR to handle any and all enable interrupts that includes an instruction to clear the specific interrupt flag. Failing to clear the interrupt will cause the processor to repeatedly execute the ISR, thus preventing the processor from executing any other application code.
  
-==== Modifying the Circuit ==== +Functions that have been declared as an ISR cannot be called by any other C function. There are two ways that the ISR code will be executed: either in response to the event that sets the interrupt flag through hardware or by setting the corresponding bit in the interrupt flag register using a software instruction. A function that is declared as an ISR cannot have any variables passed to it (no argument list) and must return a void data type.
-  - Connect the wire from pin 7 to the button's right side. +
-    * NOTE: The right side of the button corresponds here to the “top” of the button. This means that the two button legs that are always electrically connected are oriented vertically so that they span the valley between the columns. +
-  - Connect the 5V source to the button's current-limiting resistor.  +
-  - Connect a 10 µF capacitor and 10 kΩ resistor to the right side of the button. +
-  - Connect the ground pin (GND) to the right side of the capacitor and resistor+
  
-{{ :learn:microprocessor:tutorials:debouncing-via-rc-filter:rcfilter_bb.png |Figure 1. Circuit with trainable delay featuring an RC filter.}}+Normally, the code to initialize the resources that will generate the interrupt is executed only once for a given application. In this project, two different interrupts will be generated: Timer 1 interrupt and an I/O pin change notice interrupt. The programming requirements for each of these two interrupts are discussed below. The two statements in Listing 1 apply to all interrupts and should be executed only once after all interrupts have been initialized. In this instance, the program is using multi-vectored interrupts. Selected segments of the code used in an application can be protected from disruption by any and all interrupts by bracketing the code segment with the instructions INTEnalbeInterrupts(); and INTDisableInterrupts();.
  
 +**Listing 1.** Global Enabling of Global Interrupts.
 +
 +<code>
 +// Enable multi vectored interrupts
 +      INTConfigureSystem(INT_SYSTEM_CONFIG_MULT_VECTOR); //done only once
 +      INTEnableInterrupts();      //use as needed
 +</code>
  
 ---- ----
  
-===== Testing the Debouncing Properties of the RC Filter ===== +===== Timer Interrupts ===== 
-Now that we have built the circuit, you can test the debouncing properties of the RC filter. Plug the USB cable into your chipKIT board and program it with code from Debouncing via Software:+In Project 4, you configured Timer 1 to set the interrupt flag once each millisecond. However, no interrupt was ever generated. In order to set up a timer to generate interrupts, you must first initialize the timer to run as you did in Project 4. This is accomplished using the OpenTimer1 instruction shown in Listing 2. The next three macro functions enable Timer 1 interrupts. The first macro instruction sets the Timer 1 interrupt priority level to 2, the second sets the Timer 1 sub priority level to 0, and the third enables Timer 1 interrupts. 
 + 
 +**Listing 2.** Initializing Timer 1 Interrupts.
  
 <code> <code>
-const int btnPin = 7;                                     // Number of the pushbutton pin +#define T1_INTR_RATE 10000  // For 1 ms interrupt rate with T1 clock=10E6
-const int ledPin =  8;                                    // Number of the LED pin+
    
-int currentLedState;                                      // Current and previous states of output LED pin +void timer1_interrupt_initialize(void) 
-int previousLedState;                +{
-int currentBtnState;                                      // Current and previous states of input Button pin +
-int previousBtnState;               +
    
 +//configure Timer 1 using internal clock, 1:1 prescale, PR1 = T1_TICK-1
 +        OpenTimer1( (T1_ON | T1_SOURCE_INT | T1_PS_1_1), (T1_INTR_RATE - 1) );
    
-unsigned int count;                                       // Rising edge count of LED state +// set up the timer interrupt with a priority of 2, sub priority 0 
-unsigned int lastDebounceTime;       +mT1SetIntPriority(2);       // Group priority range: 1 to 7 
-unsigned int debounceDelay;                               // Delay time+mT1SetIntSubPriority(0);    // Subgroup priority range: 0 to 3 
 +mT1IntEnable(1);            // Enable T1 interrupts
    
-void setup() { +// Global interrupts must enabled to complete the initialization. – see 
-  +// Listing 1.
-pinMode(btnPin, INPUT); +
-pinMode(ledPin, OUTPUT); +
-  +
-currentLedState = LOW;   +
-previousLedState = LOW; +
-currentBtnState = LOW;             +
-previousBtnState = LOW; +
-  +
-count = 0; +
-lastDebounceTime = 0;   +
-debounceDelay = 50;    +
-  +
-Serial.begin(9600);+
    
 } }
 +</code>
 +
 +Timer 1 interrupts can be disabled at any point in the application software by using the instruction mT1IntEnable(0);. Other methods for initializing Timer 1 interrupts are shown in the orange tab on the top right.
 +
 +Listing 3's code shows how to both declare a function to be an ISR and the general format of an ISR function. For this example, the parameter ipl2 sets the Timer 1 interrupt level to 2. (Note: the MPLAB X editor uses Courier font, and the lower case “L” is difficult to distinguish from the number “1” in the aforementioned font. As an example, consider setting the interrupt level to 1 using the parameter ipl1.) This method of declaring an ISR eliminates the requirement of a function prototype. Additional methods are provided in the PIC32 Interrupts section (button below) because they may be used by other sources you may find.
 +
 +<html>
 +<a href="/learn/microprocessor/tutorials/pic32-interrupts-appendices/start" class="btn btn-success" role="button">PIC32 Interrupts</a>
 +</html>
 +\\
 +\\
 +
 +**Listing 3.** Timer 1 ISR at Interrupt Level 2.
 +
 +<code>
 +void __ISR(_TIMER_1_VECTOR, ipl2) Timer1Handler(void) 
 +{
    
-void loop() {+/* User generated code to service the interrupt is inserted here */
    
-currentBtnState = digitalRead(btnPin); +mT1ClearIntFlag();  // Macro function to clear the interrupt flag
-  +
-if (currentBtnState != previousBtnState) {             +
-  +
-lastDebounceTime = millis(); +
-// every time the button state changes, get the time of that change +
-}  +
-  +
-if ((millis() - lastDebounceTime) > debounceDelay) { +
-  +
-/* +
-*if the difference between the last time the button changed is greater +
-        *than the delay period, it is safe to say +
-        *the button is in the final steady state, so set the LED state to +
-        *button state. +
-*/ +
-currentLedState = currentBtnState;+
    
 } }
 +</code>
 +
 +----
 +
 +===== Change Notice Interrupts =====
 +Change notice (CN) interrupts are generated on selected enabled digital I/O pins whenever the voltage of the pin changes, causing the processor to read a logic value that is different from the previous reading of the PORT register. Pins designated as CN interrupt pins are shown in Table 1. Only BTN1 and BTN2 on the Digilent Pro MX7 processor board have the capability to generate CN interrupts. The I/O pin associated with BTN3 cannot generate a CN interrupt.
 +
 +^ CNx      |^ Port        ^
 +| CN0      || RC13        |
 +| CN1      || RC14        |
 +| CN2      || RB0         |
 +| CN3      || RB1         |
 +| CN4      || RB2         |
 +| CN5      || RB3         |
 +| CN6      || RB4         |
 +| CN7      || RB5         |
 +| CN8      || RG6 — BTN1  |
 +| CN9      || RG7 — BTN2  |
 +| CN10     || RG8         |
 +| CN11     || RG9         |
 +| CN12     || RB15        |
 +| CN13     || RD4         |
 +| CN14     || RD5         |
 +| CN15     || RD6         |
 +| CN16     || RD7         |
 +| CN17     || RF4         |
 +| CN18     || RF5         |
 +| CN19     || N/A         |
 +
 +**Table 1. I/O pins with CN interrupt capability.**
 +
 +CN interrupts can be disabled to protect segments of code using mCNIntEnable(0); to disable the interrupts and using mCNIntEnable(1); to enable them again . Listing 4 shows how to setup change notice interrupts using peripheral library code macros. In this code, CN interrupts are turned on for CN8 and CN9, which correspond to BTN1 (RG6) and BTN2 (RG7). The last parameter with value zero directs that internal pull-up resistors be disabled, because these pins have external pull-up resistors on the chipKIT Pro MX7 processor board. The code in Listing 4 enable CN interrupts at priority level 1 and sub priority level zero.
 +
 +**Listing 4.** Initializing CHANGE NOTICE interrupts.
 +<code>
 +/* Declaration of interrupt ISR for CN at interrupt level 1 */
 +void cn_interrupt_initialize(void) // This code is executed only once
 +{
    
 +// BTN1 and BTN2 pins are set as inputs by including the file 
 +// chipKit_Pro_MX7.h and calling chipKit_Pro_MX7_Setup();
 +// PORTSetPinsDigitalIn(BIT_6 | BIT7); 
    
 +// Enable CN for BTN1 and BTN2
 +mCNOpen(CN_ON,(CN8_ENABLE | CN9_ENABLE), 0);
    
-// ********************* start functional code ************************************** +// Set CN interrupts priority level 1 sub priority level 0 
-  +mCNSetIntPriority(1);   // Group priority range: 1 to 7 
- +mCNSetIntSubPriority(0);    // Subgroup priority range: 0 to 3 
 +mCNIntEnable(1);        // Enable T1 interrupts
    
-  +// Global interrupts must enabled to complete the initialization.
-  +
-// verification code, and a button press counter +
-  +
-if ((previousLedState == LOW) && (currentLedState == HIGH)) { +
-//count rising edges +
-count++;  +
-Serial.println(count);+
 } }
 +</code>
 +
 +A single interrupt vector is used for all CN interrupts. The interrupt does not tell you if the pin went high or low; only that the condition on one of the selected pins has changed. The ISR code must return a type void and have no parameters passed to it. The CN interrupt flag must be cleared prior to exiting the ISR using the instructions mCNClearIntFlag();.
 +
 +**Listing 5.** Change Notice interrupt service routine.
 +<code>
 +void __ISR(__CHANGE_NOTICE_VECTOR, ipl1) CNIntHandler(void) 
 +{
 +/* User ISR code inserted here */
    
-  +/* Required to clear the interrupt flag in the ISR */ 
-  +mCNClearIntFlag();      // Macro function
-  +
-// ********************* end functional code ************************************** +
-  +
-  +
-  +
-// set current states to previous states +
-digitalWrite(ledPin, currentLedState); +
-previousBtnState = currentBtnState; +
-previousLedState = currentLedState;+
 } }
 </code> </code>
  
-Once your board is programmed, the external LED should start blinking. +----
  
-Remove the capacitor from the circuit; it's okay to do this while the circuit has power. Since nothing can flow across this gap, more current will be diverted through the resistor that was in parallel with the capacitor. Similarly, once the capacitor has been charged in the circuit, it does not allow any current to flow through it. At this point, the capacitor will essentially act as a gap. After you have removed the capacitor, pressing the button enough times should eventually cause button bounce and make the LED glow dimly (instead of blinking). Tapping or flicking the button effectively accomplishes the same thing. Once you are able to reproduce the bounce consistently, try sticking the capacitor back in the circuit. Be sure you put the capacitor back exactly as shown in Fig. 1 (**with the white stripe terminal on the capacitor connected to ground**). If you reconnect the capacitor with the wrong polarity, it may damage your component. With the capacitor in place, you should not be able to get the button to bounce even if you flick it or tap it. +===== Project Tasks ===== 
 +This project implements a system that runs entirely using foreground processes. The Timer 1 interrupt is used to generate an interrupt once each millisecond. The PIC32 change notice interrupt generates an interrupt when a button is pressed or released. The project consists of writing a program that meets the specifications listed below:
  
-To see what the circuit is actually doing, check out Fig. 2. It shows what the button signal looks like with the capacitor absent from the RC filter. In Fig. 3, the same signal is shown magnified 100x, so that you can clearly see the noise caused by a button bounce. Finally, Fig. 4 depicts what the button signal looks like after the capacitor is replaced within the circuit. +<html> 
 +<ol type="1"> 
 +  <li>Functionality for main function.</li> 
 +  <ol type="a"> 
 +  <li>Calls system_init function (see step 2).</li> 
 +  <li>Continuously executes the while(1); statement.</li> 
 +  </ol> 
 +   
 +  <li>Create a system_init function that implements a fully nested interrupt scheme for Timer 1 and change notice interrupts using the following steps.</li> 
 +  <ol type="a"> 
 +  <li>Initialize the processor board using the function chipKit_Pro_MX7_Setup();. This function initializes the PIC32 processor for:</li> 
 +  <ol type="i"> 
 +  <li>Set the I/O PORT B pins for LEDA, LEDB, LEDC, and stepper motor as outputs.</lo> 
 +  <li>Set the I/O PORT G to read the button inputs for BTN1 and BTN2 as inputs.</li> 
 +  </ol> 
 +  <li>Initialize Timer 1 to generate an interrupt once each ms . Set the group priority for level 2 and the subgroup level for 0. (Refer to Listing 2.)</li> 
 +  <li>Initialize the PIC32MX7 system for change notice detection. Set change notice interrupts to detect activity on BTN1 and BTN2 only, the group priority level 1 and the subgroup level 0. (Refer to Listing 4.)</li> 
 +  <li>Set the system for multiple vectored interrupts. (Refer to Listing 1.)</li> 
 +  </ol> 
 +   
 +  <li>Functionality for change_notice_ISR (replaces read_buttons function in Project 4). (Refer to Listing 5.)</li> 
 +  <ol type="a"> 
 +  <li>Set LEDC on at the beginning of the ISR and off at the end of the ISR.</li> 
 +  <li>Call the sw_delay function for 20 ms delay to debounce button contacts.</li> 
 +  <li>Assign port data to the button_status variable.</li> 
 +  <li>Call decode_buttons function with arguments of button status.</li> 
 +  <li>Clear CNIntFLag.</li> 
 +  </ol> 
 +   
 +  <li>Functionality for Timer1_ISR . (Refer to Listing 3.)</li> 
 +  <ol type="a"> 
 +  <li>Set for a 1 ms interval (Refer to Project 4).</li> 
 +  <li>Toggle LEDA.</li> 
 +  <li>Decrement the step_delay variable.</li> 
 +  <li>When step delay is zero:</li> 
 +  <ol type="i"> 
 +  <li>Call stepper_state_machine function.</li> 
 +  <li>Reset step_delay variable to the value stored in the step_period global variable.</li> 
 +  </ol> 
 +  <li>Clear T1IntFlag.</li> 
 +  </ol> 
 +    
 +  <li>Functionality for decode_buttons (Refer to Project 4).</li> 
 +  <ol type="a"> 
 +  <li>Determine values for global variables step_dir, step_mode, and step_period.</li> 
 +  </ol> 
 +   
 +  <li>Functionality for stepper_state_machine (Refer to Project 4).</li> 
 +  <ol type="a"> 
 +  <li>Toggle LEDB.</li> 
 +  <li>Determine stepper motor output signals for step_code (local).</li> 
 +  <li>Call output_to_stepper_motor function with value of step_code.</li> 
 +  </ol> 
 +   
 +  <li>Functionality for output_to_stepper_motor (Refer to Project4).</li> 
 +  <ol type="a"> 
 +  <li>Output step_code to Port B using the read-modify-write sequence.</li> 
 +  </ol> 
 +   
 +  <li>Functionality for sw_delay (Refer to Project 2).</li> 
 +  <ol type="a"> 
 +  <li>Implement a hardware assisted software delay using the core timer that can be preempted.</li> 
 +  <ol> 
 +</ol> 
 +</html>
  
-{{ :learn:microprocessor:tutorials:debouncing-via-rc-filter:bsignocap.png |Figure 2. Button signal without a capacitor.}} 
  
-{{ :learn:microprocessor:tutorials:debouncing-via-rc-filter:bsignocap100x.png |Figure 3. Bounce noise present in button signal at 100x zoom.}}+----
  
-{{ :learn:microprocessor:tutorials:debouncing-via-rc-filter:bsigcap.png |Figure 4. Effect of capacitor on button signal.}}+===== Project Testing ===== 
 +There are significant timing requirements for this project: the Timer 1 interrupt rate, the stepper motor step rate, and the button debounce delay. Table 2 is provided below to assist you in determining where to place the instructions to control the instrumentation LEDs. The red tab above shows where to connect an oscilloscope or logic analyzer to the test points for LEDA through LEDC on the PmodSTEP to instrument this project. An example of a logic analyzer screen capture is shown below in Fig. 1.
  
-As you can see, the capacitor dramatically limits the rate at which voltage can change, especially compared to the size of the bounce noise. Considering the effect the RC filter has, our capacitor is definitely too big for handling button noise alone. This is not surprising. The RC values we chose were specifically meant to reduce bounce noise and any other noise caused by a tap/flick. The circuit was designed this way because it is easier to see the effects of the filter. A smaller capacitor could be used to target the bounce noise specifically.+| LED   ^ Operation      ^ When              ^ 
 +| LEDA  | Toggle         | Each millisecond  | 
 +| LEDB  | Toggle         | Each step         | 
 +| LEDC  | SET (on)       | Start of CN ISR   | 
 +| LEDC  | Cleared (off)  | End of CN ISR     | 
 + 
 +**Table 2. Instrumentation LED Operations.** 
 + 
 +{{ :learn:microprocessor:tutorials:pic32-interrupts:oscilloscope-screencap.png?nolink |Figure 1. Screen capture for the instrumentation of Project 5.}} 
 +Figure 1. Screen capture for the instrumentation of Project 5. Screenshot of Digilent WaveForms running on Microsoft Windows 7. 
 + 
 +---- 
 + 
 +===== Test Your Knowledge! ===== 
 +Now that you've completed this project, you should look at the following questions/problems: 
 + 
 +<html> 
 +<ol type="1"> 
 +<li>Develop a DFD and a CFD for this project.</li> 
 +</br> 
 +<font color="red">ANSWER: The data flow diagram shown in Fig. 2 is essentially the same as it was for Project 3. However, the control flow diagram shown in Fig. 3 now consists of three independent programs. The background code initializes the system. The two foreground processes run as independent programs and run to a termination.</font> 
 +</ol> 
 +</html> 
 +{{ :learn:microprocessor:tutorials:pic32-interrupts:interrupt-dfd.png?nolink&500 |Figure 2. Data flow diagram.}} 
 + 
 +{{ :learn:microprocessor:tutorials:pic32-interrupts:interrupt-cfd.png?nolink&500 |Figure 3. Control flow diagram.}} 
 + 
 +<html> 
 +<ol start="2"> 
 +<li>Explain how the oscilloscope capture required for step 4 demonstrates that your program implements a nested interrupt preemption scheme.</li> 
 +</br> 
 +<font color="red">ANSWER: The signal for LEDC is high during the period that the Change Notice interrupt is being served. The signal for LEDA continues to toggle due to servicing the Timer 1 interrupt. Hence, the timer interrupt is interrupting the Change Notice interrupt.</font> 
 +</br></br> 
 + 
 +<li>What are the requirements that dictate which sections of code must be protected from interrupts?</li> 
 +</br> 
 +<font color="red">Port B is changed in the Timer ISR (changing LEDA and SM1 through SM4) and LEDC is modified in the Change Notice ISR. If the instruction to modify the LEDC bit of Port B is not atomic (meaning that the order of execution cannot be changed), then it would be possible that a Timer 1 interrupt could change the contents of the LATB register in between instructions in the Change Notice ISR. Two of the three conditions needed for requiring protecting code are met: using a global variable (LATB) and modification in two ISR operating at different levels. If the modification of the global variable is not atomic, then the third condition is met and the code will need to be protected.</font> 
 +</br></br> 
 + 
 +<li>What constitutes the worst-case latency for systems that use polling to detect events?</li> 
 +</br> 
 +<font color="red">ANSWER: It is the main function loop time—all functions in the main function while(1) loop must be completed within the required time or some functions will be executed more slowly that the design requires.</font> 
 +</br></br> 
 + 
 +<li>Explain why the stepper motor is potentially running at a more accurate and consistent speed compared to the Project 4 implementation.</li> 
 +</br> 
 +<font color="red">ANSWER: The interrupt that causes the stepper motor to step is at the highest level. The latency is constant and predictable regardless of when the interrupt occurs. Hence the latency between the Timer 1 interrupt and the time when the stepper motor actually steps is always the same.</font> 
 +</br></br> 
 + 
 +<li>Discuss the advantages and disadvantages of polling versus interrupts in real-time control.</li> 
 +</br> 
 +<font color="red">ANSWER: The C code to implement polling is relatively simple to write and verify. The C code to setting up and ISR can be confusing to someone who is unfamiliar with the PIC32 processor. There are no memory requirements to store the processor context. Systems that do not use interrupts are deterministic albeit predictably slow.</font> 
 +</br></br> 
 + 
 +<li>Describe how you would change the Project 5 program to allow you to control the stepper motor at speeds other than those that are multiples of one millisecond.</li> 
 +</br> 
 +<font color="red">ANSWER: Increase the Timer 1 interrupt frequency.</font> 
 +</br></br> 
 + 
 +<li>Why are interrupt service routines restricted so that no variables can be passed to or returned from the function?</li> 
 +</br> 
 +<font color="red">ANSWER: Since one cannot predict when the ISR code will be executed, there is no way to prepare the processor registers to receive or return data. The only means of passing data to and from ISRs is by using global variables.</font> 
 +</br></br> 
 +</ol> 
 +</html>
  
-{{tag>learn microprocessors tutorial uno32 uc32 max32 debouncing rc-filter resistors capacitors mpide}}+{{tag>learn microprocessors tutorial pro-mx7 chipkit-pro pic32 interrupts }}