In this final phase of our project, we show how once the touchpad communication protocol is established, you can interface the touchpad to even the TV screen.† This section explains the specifics to the TV design.† Details to the ADB protocol remain the same as in the oscilloscope implementation and are hence omitted.†
∑ Sync level = 0 V
∑ Black level = 0.3 V
∑ White level = 1.0 V
Figure 8. TV connections.
The TV is a (128x100) raster-scan device.† The image is produced by directing a beam horizontally from left to right onto the monitor and zigzagging back to the start of the next line.† For our small TV, the raster frame consists of 262 lines with a refresh rate of 60Hz (screen is repainted 60 times per second).† This task requires real time signal generation.†
For the image to be properly displayed without any jitter, uniform pulses (63.5long) are required in order for the beam to maintain horizontal sync.† By running timer1 at full speed (16 MHz), and interrupt on compare match after 1018 timer ticks (1018/16MHz= 63.625), we generate a line.† Thus, each frame (262 lines) takes exactly 1/60 of a second.† Most importantly this ISR must be entered from sleep mode to maintain a consistent start of a horizontal line (no variation in time to enter the ISR).† The lines are broken up as follows:† In lines 30 to 230, image is displayed.† The other lines are blank, but thatís where all the calculations are made. Each line has a horizontal sync pulse which is defined in the ISR code.† In the ISR, the following tasks are executed: (a) generate† 5duration sync pulse by setting PORTD to sync on and sync off ; (b) blast the data bits; (c) increment line count; (d) set a vertical sync executing line 248 to 251 ( this indicates the end of a frame); and (e) reset the line count if itís executing line 262.†
We were supplied with a video generating code that contained the appropriate definitions.† There were small/large character bitmaps, and video functions such as video_pt(),video_putchar(),video_smallchar();video_putsmalls(),video_line(), video_set(), and video_puts().† For our project we use the video_pt(), video_line() and video_set functions as well as the data blasting code to display the image on the screen.
MCU as the translator†††
The initial cursor location is at the center of the TV screen.† Thereafter, the MCU controls the movement of the cursor according to the motion packets received from the touchpad.† The MCU maintains a cumulative sum of the relative motion packets in registers currX and currY to convert to absolute mode.† Such a conversion was necessary as we were unable to change the touchpad mode of operation from relative to absolute.††
First task: draw points to the screen.† The touchpad is polled every 1/60 of a second at line 231 and proper mapping of the packet to a point on the screen is computed.† The mapping is done by using the sign bit of the †and †bytes (which were sent by the touchpad in response to the talk register 0 command).† The direction of the point is determined by interpreting the sign bit as follow:† If sign of is 1, then draw point to the right of current location.† If sign of† †is 1, then draw point in upward direction.†
Second task: add special features.† The MSB of Register0ís byte2, contains information about the button press.† It is cleared when button is pressed.† Thus, we manipulated this feature in order to implement three modes of operation.† By default, you enter mode1.† The switches for portA are used to select any other modes.† Switch0 selects mode 1, switch1 selects mode2, and switch3 clears the screen.†
Mode 1: relocate cursor
As you move your finger on the touchpad, points are drawn to the screen in real time.† However, if you want to show discontinuity you can move the cursor to a different area by hold down any button and moving your finger to the desired location.† Release the button to resume drawing.†
If the MCU interprets the button press bit as cleared, then it draws the point in that frame and erases that point in the next frame.††
Mode 2: draw a line
We had mentioned the fact that drawing with your finger is more inaccurate than with a pen.† Hence, drawing straight lines is facilitated with this mode.† Here we ran into a synchronization problem.† Between line 231 and line 30 we have a total of 60 lines to finish any computation before the next frame is drawn. This is approximately 3.881 ms (63.625*61).The problem is that the total execution time taken to send the Talk Register 0 command and to receive a response is 3.764† ms in the worst case scenario.† Drawing a line in the same frame was not possible.† Therefore, we split the execution into two frames.† On an even count frame, the touchpad is polled and current position calculations are carried out.† In the next frame, the new points are appended to the screen buffer.† The tradeoff is that due to updating at half the original rate (now 30Hz), the display seems slugglish.† We attempted to compensate this by mapping each packet to twice as many points, but this made the drawing more jagged.† We have less control of curvature.† Maybe with a bigger screen and better resolution, this would be a good modification.††††††††
Mode 3: Clearing the screen
Note that clearing the screen involves zeroing out the complete 1600 byte screen buffer.† Thus, this step was also performed in 2 frames in order to maintain proper synchronization.
We completed all the tasks we set out to accomplish.† We drew to the screen, yes!