Count Button Cycle

This assignment focuses around basic task synchronizing techniques leveraging interrupts and semaphores. This assignment will also exercise the technique of proving code correctness in the time domain by using discrete (digital) signals and an oscilloscope.

Download the modified example14 code from Hw5 on Evaltools. This is the code we “hacked” to use some of the hardware features of the Micro Controller (uC, pic32mx795f512l) and learned how to use an oscilloscope to display and measure digital states from the uC.

This assignment is broken into two parts. Part 1: using counting semaphores to capture button cycles. Part 2: focuses on measuring kernel/task code execution performance and analyzing performance challenges with other debugging techniques and kernel performance.

Part 1: Count Button Cycle

 Introduction:

A momentary switch/button is an electro-mechanical device which changes an electrical circuit by providing contact (closing the circuit) or opening a contact (opening the circuit), the button/circuit returns to the normal state once the button is released (momentary). The button used with our uC development board, when depressed closes the circuit to a specific pin (digital input) to our uC. The “hacked code” enables the CN (Change Notification) register to be mapped to Switch 1 (PORTD bit 6, RD6) this will generate an interrupt to the Micro Processor (uP, MIPS), which has our ISR mapped. This means that each change of state of RD6 will generate an interrupt, two interrupts per button push.

The reason why polling technique is not used (looping software checking the value of RD6), is elimination of race conditions (aperiodic button pushing) between the button and software execution and poor software design.

Requirements:

Modify the sample code to use the counting semaphore technique and synchronizing solution to count how many times the button was pushed. This means a button handle task is blocked by a semaphore (counting) and becomes unblocked after the button (RD6) ISR has been pressed and released (button cycle). This means the counting or logic for the semaphores is not managed in the ISR but by the handler. Your button handler will maintain the accumulated button cycles (accButCycles).

The periodic task in the example must be modified by changing the current “print” statements. They will be replaced to display the accButCycles (“Current Total Button Pushes are: “).

Verification:

Once the code is executing the initial test plan is to depress SW1, hold 1 sec, and then release SW1. The code should maintain the count correctly.

Validation:

Test performance. Depress and release the button faster than the 1 sec rate. Increase your rate. Keep count the number of times you cycled the button.

Q1: Does the output of the measured counts (printed) match your counts? IF not offer an explanation/analysis why the kernel and tasks did not provide the correct answer. <Put the question and answer in the header comment of your code >

Part 2: Kernel Analysis

Introduction:

Earlier lectures and examples kind of proved the temporal issues using character outputs for software development and maintenance. This section of the assignment is to prove the pervious statement and to gather kernel metrics to better estimate task execution performance.

This is going to be measured by leveraging the digital outputs to LED 1-3 in the hacked example14. The idea of instrumenting code to be measured (UUT) can be “bracketed” by a digital (1=start of code and 0=end of code). Capture the digital pulse on the scope and measure the pulse width will yield the execution time of the UUT. The key understanding or take-away, is to know is the time it takes to force a digital high (5vdc) and the measured effect, a paradigm of the Heisenberg effect. For the uC we are using, the commands are a two to three clock cycles (12.5ns/cycle) overhead or less than 40ns/write. Negligible impact.

Requirements:

The section is to introduce performance metrics and one of many measuring techniques. This will help the student analyze the task management of the kernel. Record the answers to each requirement in the header comment.

  1. Measure the time it takes to output the print statement in the periodic task.
  2. Measure the periodic rate of the periodic task.
  3. Comment out the print statement in the periodic task, does the task maintain the 200ms rate? Could this be a real-time task, meaning the kernel meets the time constraint of the task to start every 200ms.

Extra 5 points (each) on next exam

  1. How long does it take for the kernel to perform a “context switch”?
  2. How long does it take for the kernel take to “take” or “give” a semaphore?

Order from us and get better grades. We are the service you have been looking for.