ECE 477 Digital Systems Senior Design Project Rev 8/09 s14

ECE 477 Digital Systems Senior Design Project Rev 8/09

Homework 9: Software Design Considerations

Team Code Name: __Blinkers++______Group No. __5____ Team Member Completing This Homework: ____Dennis Lee______E-mail Address of Team Member: ____leedj______@ purdue.edu

Evaluation:

SCORE DESCRIPTION Excellent – among the best papers submitted for this assignment. Very few 10 corrections needed for version submitted in Final Report. Very good – all requirements aptly met. Minor additions/corrections needed for 9 version submitted in Final Report. Good – all requirements considered and addressed. Several noteworthy 8 additions/corrections needed for version submitted in Final Report. Average – all requirements basically met, but some revisions in content should 7 be made for the version submitted in the Final Report. Marginal – all requirements met at a nominal level. Significant revisions in 6 content should be made for the version submitted in the Final Report. Below the passing threshold – major revisions required to meet report * requirements at a nominal level. Revise and resubmit. * Resubmissions are due within one week of the date of return, and will be awarded a score of “6” provided all report requirements have been met at a nominal level.

Comments: ECE 477 Digital Systems Senior Design Project Rev 8/09

1.0 Introduction Blinkers++ is an inter-car communication system that provides a more dynamic and intuitive method of communication. The user will interact with the device using a capacitive touch array that will be able to accept and interpret multiple touches. The output for the device will be displayed using coordinated LED patterns associated with the interpreted gesture. To achieve this output, this project will utilize three different microcontrollers: the PSoC, dsPIC, and PIC18. The PSoC reads in the user input on the touchpad. The dsPIC will interpret this input to determine the number and direction of the fingers. The PIC18 will coordinate the LED outputs. Challenges include designing an algorithm to interpret the user input and coordinating the scanning of the input touchpad. Therefore, success can be achieved if the input is read in and interpreted correctly.

2.0 Software Design Considerations To convey a touchpad input to LED output, our project uses three different types of microcontrollers: the Programmable System on a Chip (PSoC), dsPIC, and PIC18. The coding is modular such that each microcontroller performs a specific function. The PSoCs (9 total) read in the touchpad input. The dsPIC processes these touchpad inputs to detect the number of fingers and direction of fingers. The PIC18 determines the LED patterns and commands the LED drivers.

2.1 PSoC The PSoC interfaces with the capacitive touch buttons on the input touchpad. Table 1 below lists the external interfaces corresponding to each port. Each PSoC (9 total) can handle 30 sensor inputs. An I2C line is needed for programming and debugging, and another I2C line is needed to communicate input readings to the dsPIC.

-2- ECE 477 Digital Systems Senior Design Project Rev 8/09

Port name External Interface Port 1 [0] I2C SDA (programming) Port 1 [1] I2C SCL (programming) Port 1 [5] I2C SDA (communication with dsPIC) Port 1 [7] I2C SCL (communication with dsPIC) All other I/O pins Touch button input Table 1. PSoC external interfaces

An important consideration is the speed with which the buttons are scanned. Consider the worst case timing analysis for the PSoC. The slowest I2C speed is 100kHz, which corresponds to 10 us / clock cycle [1]. Five bytes can be used to transmit an array of 30 buttons read from 1 PSoC. Figure 1 below shows how each bit in bytes A – E can represent the array of 30 buttons. A total of 40 bits convey 30 buttons (8 bits / byte * 5 bytes). Assuming that I2C takes 2 x 40 bits = 80 clock cycles (accounting for I2C start, stop, etc), it takes 80 clock cycles * 10 us / clock cycle = 800 us to transmit 30 buttons. There are 9 PSoCs, for a total transmit time of 9 * 800 us = 7.2 ms. We would like the dsPIC to scan every 0.1 sec. The PSoC total transmit time is well under our desired scan rate of 0.1 s from the dsPIC.

A5 A4 A3 A2 A1 A0 B5 B4 B3 B2 B1 B0 C5 C4 C3 C2 C1 C0 D5 D4 D3 D2 D1 D0 E5 E4 E3 E2 E1 E0 Figure 1. Array of 30 buttons controlled by 1 PSoC

See Appendix A for a flowchart of the main loop for the PSoC. When the dsPIC requests data over I2C, the PSoC begins scanning buttons. Once all buttons have been scanned, it will convey the user inputs to the dsPIC. Our code is flag driven, in the sense that it will respond when it receives a request from the dsPIC. This organization seemed logical, since the dsPIC acts as the control center and polls the PSoC slaves for data on the touchpad. 2.2 dsPIC Note that Appendix C has a memory map of the dsPIC [2]. The dsPIC will communicate with other devices through I2C, as shown in Table 2. For example, it needs to provide user feedback by lighting LEDs which will surround the touchpad, and it will communicate with the

LED drivers over I2C. It also needs to grab the user inputs from the PSoCs, which occurs over I2C. Wireless communication with the PIC18 will occur on a UART pin. The dsPIC will utilize the timer to scan the touchpad at our desired interrupt rate, 0.1 seconds. As described in the PSoC section, this interrupt rate should allow ample time for the PSoCs to read touchpad input. See Appendix A for a flowchart of the dsPIC’s main loop. The overall organization of the application code will be driven by the flag of the timer. Once a timer interrupt is triggered, the dsPIC will start requesting data from each of the 9 PSoCs on the I2C line. Another alternative organization is to use an interrupt driven approach. The code should work the same with either approach; we chose the flag driven approach to ensure that the calculations of the input are not interrupted. Port name External Interface Port G.3 I2C SDA (communication with LED driver) Port G.2 I2C SCL (communication with LED driver) Port A.2 I2C SCL (communication with PSoCs) Port A.3 I2C SDA (communication with PSoCs) Port A.3 UART Tx (communication with PIC18) Table 2. dsPIC external interfaces

2.3 PIC18 Note that Appendix C has a memory map of the PIC18 [3]. Table 3 below shows the external interfaces. The PIC18 will require an I2C bus with 14 slaves. It will also use a UART module to facilitate wireless transmission of data between the user module and LED output vehicle. The LED drivers will be updated individually, and no all-call or subaddress calls will be utilized. For constraint analysis purposes, if we updated the PWM channel for every LED at 100kHz(standard I2C speed), it will require 2.38ms to update all drivers (17 bytes per LED driver * 14 LED drivers). The plan is to update the LED drivers every 5ms. This is an appropriate tolerance for both human perception of light and leeway so that we don’t get behind in updating the LED drivers. Because we anticipate the LEDs not being on all the time, the PIC18 should go into a low power mode until it receives a command from the dsPIC. See Appendix A for a flowchart of the main loop for the PIC18. When the PIC18 receives a command from the dsPIC to output a pattern, the PIC18 will determine which LEDs to turn on and coordinate the LED drivers accordingly. Our code utilizes a flag driven approach, so

that the LEDs will flash patterns based on a timer flag. We could also have used an interrupt driven approach, but we wanted to ensure that the displaying of the LED patterns did not get interrupted.

Port name External Interface Port C.3 I2C SCL (communication with LED driver) Port G.2 I2C SDA (communication with LED driver) Port C.6 UART Tx (for debugging) Port C.7 UART Rx (communication with dsPIC) Table 3. PIC18 external interfaces

3.0 Software Design Narrative Appendix B shows a hierarchical organization of the software. The coding has three modules: the PSoCs, the dsPIC, and the PIC18. Each microcontroller has specific functions, and communication occurs mainly over I2C. Note that the dsPIC will communicate with the PIC18 wireless over a UART port.

3.1 PSoC Button scanning The PSoC’s job is to scan all the buttons into an input array and to transmit this input array to the dsPIC. When the dsPIC requests data from a PSoC over I2C, the PSoC begins scanning all buttons. We would like to scan every 0.1 seconds, so that the PSoC will respond to the dsPIC’s requests which are generated from a timer interrupt. As calculated in section 2.0, the PSoCs should scan fast enough to allow this update rate. Once the PSoC scan is complete, the PSoC will send its input button array to the dsPIC over I2C. Currently, we are testing basic I2C functionality.

3.2 dsPIC Finger counting algorithm Figure 1 below shows an example of a touchpad with inputs read in as 1’s and 0’s. The finger counting algorithm involves “coloring” groups of buttons. Colors are used to help visualize the problem. In the actual code, each block may be assigned a integer, rather than a color. The algorithm has the following general outline:

Loop through array of buttons If the button is “1” and the button is uncolored, then Check if the button’s neighbors (above, below, left, right, diagonals) are colored If the neighbors are colored, color the button the same color If the neighbors aren’t colored, color the button a new color The number of colors is equal to the number of fingers

0 0 0 0 0 0

0 1 1 0 1 0

0 0 0 0 0 0

0 0 1 1 0 0

0 0 0 0 0 0

Figure 2. Example of reading touchpad inputs

Algorithm to detect direction of fingers The direction of fingers needs to be detected to decide which LED portion of the car will light – front, back, left, or right. To determine direction, the averaged coordinates of the fingers can be calculated for each swipe. The x-y axis can be determined based on the corner of the touchpad. For example, if (0,0) in Figure 2 represents the upper left corner, the upper right corner would be (6,0). The algorithm might look like the following For each input frame capture Find averaged coordinates of the 1’s Store averaged coordinates in a buffer Compare the averaged coordinates from an early frame and a later frame Detect net change along x-y axis

Currently, our team has pseudocode written for the dsPIC algorithms.

3.3 PIC18

The PIC18 will be receiving data wirelessly from the dsPIC through a hardware based RF module. Communication between the PIC18 and the RF module is a UART connection. The PIC18 will be in a low power state until awoken by three successful transmissions of the same byte. One byte is required to communicate direction (4 bits with a max of 16 directions) and number of fingers (3 bits with a max of 5 fingers). The extra bit may be used for parity, or as a constant bit. After the PIC18 has verified that it received the same byte 3 times, it will initiate the timer0 module to interrupt every 5ms. After the PIC18 has completed the LED pattern, it will return to sleep mode until the next command is sent. The algorithm we will use will take advantage of our RAM space. We will be creating two tables in RAM that reflect the PWM registers in all the TLC drivers. Using arithmetic operations, we will have a “ready to deliver” buffer, filled with the updates the I2C bus is in the process of sending out, and a “currently under construction” buffer, where the PIC18 will be calculating the next batch of PWM updates. All together, these buffers will only occupy 1/8th of our total RAM space. Currently, the I2C interface to a TLC driver has been written and tested using a single TLC chip and PIC18F2525. The algorithms for calculating the next PWM values are in the pseudocode stage.

4.0 Summary In summary, Blinkers++ has a few design challenges. The dsPIC algorithm needs to correctly detect the number and direction of fingers. The PSoC needs to scan in the inputs correctly, which will require tuning of the sensitivity of the capacitive sensing buttons, and it needs to be able to convey the inputs to the dsPIC over I2C. The PIC18 will need to determine the LED patterns based on direction and number of fingers. Pseudocode has been written for most of the algorithms, and once I2C communication is established, the project will hopefully be well on its way to completion.

List of References

[1] Cypress Semiconductors. “CapSense Applications,” CY8C20x36/46/66/96 datasheet, Oct 2008 [Revised July 2009]

[2] Microchip Inc. “High Performance, 16-bit Digital Signal Controllers,” dsPIC33FJXXXMCX06/X08/X10 datasheet, Jul 2007 [Revised Mar. 2009]

[3] Microchip, Inc, “Enhanced Flash Microcontrollers with 10-Bit A/D and nanoWatt Technology,” PIC18F2525/2620/4525/4620 datasheet, 2004.

Appendix A: Flowchart/Pseudo-code for Main Program

PSoC Main Loop Start

CapSense Buttons Init

I2C Init

N dsPIC data requested?

Y Scan button

Add button status (on/off) to I2C buffer

N Scanned all buttons? Y Write I2C buffer

PIC18 Main Loop Start

UART Init

I2C Init

Timer Init

N New data received?

Y Enable TIM

Coordinate LED drivers over I2C

N Number of repetitions reached? Y

Appendix B: Hierarchical Block Diagram of Code Organization

Appendix C: Memory maps