Introduction
Our electronic drawing board integrates an easy human interface with a standard electronic display; specifically the a touchpad and an oscilloscope or TV screen.
The rationale behind the drawing board is to be able to create a free hand sketch using the touchpad and have a real time display on a screen which can later be sent to the computer once finalized.This idea came about after making countless reports that required drawings that take hours to perfect on a computer when in fact with a pencil it would only be a matter of minutes. In the market, tablets are gaining popularity but they are so expensive! Hence, we thought it’d be nice if we could simulate something similar under our $25 budget constraint.Thus we settled for using a touchpad to draw to an oscilloscope (and which EE doesn’t have an oscilloscope handy at home!). Better yet drawing to the TV!
High Level Design
The Rational
The original idea was to draw to a 5” TV screen using a pen input touchpad. We had originally ordered a Jam Studio tablet but unfortunately it was too complex and poorlydocumented. We couldn’t retrieve any signals from the pad. Thus, we decided to use a regular touchpad. This makes our design robust due to the inaccuracy of using a fingertouch as opposed to a pen point. However, the concept remains the same: to draw to a screen.
The microcontroller acts as a translator between the touchpad and the oscilloscope. Its job is to communicate with the touchpad using any of the 4 standard protocols: serial, ADB, PS/2, or USB and to send appropriate signals to represent the coordinates on the oscilloscope. Our touchpad uses the ADB protocol which is MAC compatible. Also, since the oscilloscope requires analog input signals, DACs are needed to translate the digital output from the MCU to a form that can be recognized by the oscilloscope.
Diagram
The following is the overall layout of our design.
Figure1 . High Level Design Layout
The Logic: How does a touchpad work?
ADB Protocol
The protocol requires a single ADB data signal line for the two-way communication between MCU and touchpad. This protocol is time sensitive. Essentially, the MCU needs to know precisely when to can send the commands and when to listen for responses.
Upon power on, the touchpad requires 200ms for calibration and self testing. After this, the MCU can begin sending its command packet and receive data packets. Most touch pads have 4 commands and 4 registers. (Appendix A) Our specific touchpad, Alps Glidepoint, has only 2 active registers: register0 and register3.
An ADB command is a 1-byte value that specifies the 4 bit ADB device address, the desired action the touchpad should perform and to what register. By default, the device address is 3 and the handler ID is $01. In order to ensure a two way communication, the “LISTEN” and “TALK” commands need to be implemented. Figure 2. shows the command format.
Figure2 . ADB commands.
The TALK command requests to read the data stored in the specified register. Register 0 is used to hold motion packet data. The MCU polls the touchpad by sending a Talk Register 0 command. The device responds to a Talk Register 0 command only if it has new data to send. (If more devices were used as inputs, the MCU would have to resolve device address conflicts, collisions and the device would need to issue a service request to signal it has new data to send.)
The LISTEN command instructs the touchpad to prepare to receive additional data. The device must overwrite the existing contents of the specified register with the new data.
The send command packet protocol follows the following flowchart:
(a)
(b)
Figure3 . Send Command Logic.
Once the MCU sends the stop bit, it releases the data line to wait for the touchpad to begin sending its data. If the time between the stop bit till the data start bit exceeds its maximum range, then the MCU resumes control and resends the TALK to Register0 command. If not, the device sends the motion data stored in its Register0 which by default consists of 2 bytes, 
and 
, in relative mode. (See figure 4)
and , in relative mode. (See figure 4)
Figure 4 ADB Register0.
Once, the motion packet is received by the MCU, is can store the data and send appropriate signals to the DAC to output the point onto the oscilloscope.
Initially, we had tried to overwrite register 2, in order to change the relative mode to absolute mode. This could have been done with the LISTEN register 2 command. Unfortunately, with this touchpad, Register 2 couldn’t even be read so a LISTEN command would have been pointless. Due to lack of documentation, we have made several assumptions based on the Sypnaptic touchpad documentation, an Apple book, and an article we found online implementing a sample ADB manager. Since, relative mode was the only output from this touchpad; we decided to use the oscilloscope as the display device as opposed to the TV since it relies on incremental values as its input.
Subsequently we also succeeded in using the TV as the display device. In order to use the TV with relative mode inputs, we store the current position for x and y (with a default starting point at the centre of the screen) and update x and y with thereceiveddeltas(up=-1,down=1,left=-1,right=1). Finally, the point is drawn using the video_pt subroutine. We are currently carrying out further tests to perfect the implementation.
Math Calculations
Timing sequence
Timer 0 is used to generate time. It is pre-scaled by 64 to generate a 4 
clock tick with a 16 MHz crystal. The timing ranges required by this program for ADB signals are shown in the table below. Note that each time reading is acquired by resetting TCNT0 and polling it until it exceeds the maximum range. The MCU sends each command bit for a specified duration with 
error. Note, that a logic 0 and logic 1 is determined by the pulse’s low time. A logic 0 is given by a low time approximately equaling to 65
clock tick with a 16 MHz crystal. The timing ranges required by this program for ADB signals are shown in the table below. Note that each time reading is acquired by resetting TCNT0 and polling it until it exceeds the maximum range. The MCU sends each command bit for a specified duration with error. Note, that a logic 0 and logic 1 is determined by the pulse’s low time. A logic 0 is given by a low time approximately equaling to 65 .Table1. ADB protocol timings.
Signals | Times | Times used |
Logic ‘0’ low time | 65us  5% | 64us |
Logic ‘1’ low time | 35us 5% | 36us |
Bit Cell time | 100us 3% | 100us |
Attention | 800us 3% | 800us |
Sync | 65us 3% | 64us |
Stop bit low time | 70us 3% | 72us |
Stop to start time | 200us 30% | 200us |
Storing and for the oscilloscope input
and for the oscilloscope inputThe two 7-bit deltas are mapped to a two bit incremental value and saved in two position arrays, bufferx and buffery. This is done by taking into consideration bit 6 of the relative motion packet bytes which represent the sign bits. For 
y, a set signed bit represents movement in the upward direction. Hence +1 is stored in buffery. For x, a set signed bit represents movement towards the right Hence +1 is stored in bufferx. The incremental values are represented as 2 bits in the following format:
y, a set signed bit represents movement in the upward direction. Hence +1 is stored in buffery. For x, a set signed bit represents movement towards the right Hence +1 is stored in bufferx. The incremental values are represented as 2 bits in the following format: { ‘-1’ = 11 , ‘1’ =01, ‘0’= 00 }.
This scheme allows us to store 2 points in one byte of memory. Thus in a 2k RAM, the maximum number of points we can store is 4000.
Figure 5. Oscilloscope Interpretration of incremental values.
Plotting x and y
First, we start at the center of the screen, meaning that the MCU outputs 0x40 to PORTA and PORTB to represent the analog Vx and Vy. Each 2 bits in the buffers (bufferX, bufferY) represent the change in coordinates.
The screen is refreshed in the main loop. Starting with the center point, the next point is calculated by retrieving the next 2 bits from each position buffer, interpreting with the appropriate incremental value and updating the X and Y register value containing the current coordinate. Finally, this register is sent to the ports connected to the appropriate DACs. Refresh( ) reads the buffers and displays the points onto scope. This is written is assembly code for speed optimization.
Program Code
The touchpad interface
Function: executecmd()
(Start)
Start by setting the ADB pin (C.0) on Port C as an input, and tri-stating it to an output. Float the data line to high, and clear registers to default values.
(Send command packet; calls sendcmd())
-(Attention Signal)
Set the line to low for about 800 usecs. If low time is greater than 824 usecs, then it’s a Reset Signal. The program starts over again, waiting for the line to be high.
-(Sync Signal)
The Sync Signal is sent by setting the line high for about 70 us between the rising edge of the Attention Signal and the falling edge of the first bit of the Command.
-(Command byte)
The MSB bit in the ADB command byte is sent first. This is achieved by calling a the putbyte routine, which sets the appropriate low time, and high time for a logic “0” or “1” bit. Each bit is 100 usecs. This is repeated until all 8-bits of the Command have been sent.
(Interpret the command)
All commands will be global and the default address will be 3 since we have only one relative position device. Determine whether it is a Talk, Listen, or Flush Command, and go to the specified Command routine. We implemented the talk and listen routine, but only use talk in the final version of the code.
(Receive data packet; calls getresp())
The talk command requires the MCU to wait for the line to go low. The time elapsed is the Stop-to-Start Time (Tlt). If this is a Talk Register 3 Command, the touchpad returns a random address as part of the two bytes sent to the Host. (In our results, bits 8-11 were random.) If this is a Talk Register 0 command, a response will occur only if there is data that needs to be sent. If so, the touchpad will send the data start bit (a ‘1’), two bytes of data from the indicated register, and a stop bit (a ‘0’ This signifies a successful transmission. If not, the program will revert back to the transmission of the Attention Signal.
(Send data; calls getarg() )
If the Command is a LISTEN Command, the MCU allots enough time to pass for the touchpad to interpret the command as such and then drives the line low after the appropriate Stop-to-Start Time. The MCU then starts sending the rest of the data packet with the start bit first, followed by the two data bytes, and then a stop bit. The touchpad should write this Data into the specified register.
Function: getresp()
(Interpreting the motion packet)
If the touchpad has been touched, two bytes of data are loaded into a buffer representing a relative motion. Now the data is interpreted by the MCU in order to interface to the appropriate display. The sign bit determines the direction of the motion; up or down, left,or right. Each direction is stored as two bits in bufferx and buffery.
Function: refresh()
(viewing the output)
We used the code we had written for the Etch-a-sketch lab to interface the oscilloscope.Thus, the routine refresh is called. This reads the contents of bufferx and buffery, makes the appropriate conversion and displays it on the screen. We implemented one slight modification. After the end of the buffers are reached, the routine traces back to remove the trailing end from the end point to the centre caused by reinitialization loop back of the buffers.
Hardware
We are using the STK500 board and the Atmega32 microcontroller with a 16 MHz crystal. We use all the on–chip I/O ports. PORTA drives the DAC for Vx and PORTB drives the DAC for Vy. We included a 1nF capacitor between the signal to the oscilloscope and ground in order to clean up the signal. PORTC is used for the touchpad inputs and a 470 
is needed as a pull-up resistor for the ADB signal. PORTD is used for the UART for debugging purposes. Connections are as follows:
is needed as a pull-up resistor for the ADB signal. PORTD is used for the UART for debugging purposes. Connections are as follows:
Figure 6. Touchpad connections.
Figure 7. DAC connections.
Things we tried that didn’t work
(1) Implementation of PS/2
We initially tried to implement the PS/2 protocol (which is used by mouse on standard PCs) on the touchpad. The PS/2 protocol has a four pin interface, Vcc, Gnd, Data and Clock. This is a bidirectional asynchronous protocol which is completely governed by clock signals generated by the touchpad. The touchpad pulses the clock line 11 times for every byte which is transmitted or received; Start bit, eight bits of Data, Parity bit and Stop bit. The touchpad starts clocking as soon as Power is applied to it.
For the PS/2 protocol, we initially relied on the code that was implemented in a previous 2000 Final Project (Zen touchpad). This code is in assembly and is meant for a 8535 MCU. The various codes that we tried were:
(a) ‘C’ code on Mega32
(b) Assembly code on Mega32
(c) Assembly code on 8535
We consistently failed to get any results. L We hooked up the touchpad to an oscilloscope to detect the clock pulses but the device seemed completely dead. We also opened up a touchpad to verify the signal lines. After a lot of time and energy spent on this implementation, we decided to check the touchpad on a Mac computer and to out relief got a response. J
All this would have been avoided if we had been able to obtain any sort of documentation on the touchpad. But the touchpad came with no documentation and it was impossible to reach any support staff either. The data sheet we used is meant for “Synaptic” touchpads but it is generic enough for most purposes. We also completely relied on the “Zen Touchpad” project’s claim that the touchpad used PS/2 protocol.
Lesson learned: Make certain you have a datasheet. Make no assumptions!!!
(2) Implementation of Absolute Mode
The touchpad works in two data reporting modes:
(a) Relative mode
(b) Absolute mode
The default mode is the relative mode. We had originally planned on working in the absolute mode thus requiring us to modify the ADB register 2 which contains device specific information like version number, capability bits, mode byte, etc. The steps involved are
(i) Read Register 3 to verify the default relative device address of 3.
(ii) Verify Handler ID to be ‘01’, ‘02’ or ‘04’.
(iii) Verify device response to Talk 1 (Eight bytes with first four being ‘Synt’)
We obtained these steps from the Synaptics datasheet and implemented the same on our touchpad. Unfortunately, it yielded no results. We were unable to even read registers 1 and 2, both of which are defined to be device specific. The only explanation we can provide for this is that the touchpad we have is not absolutely Synaptic compatible. Fortunately registers 0 and 3 are more generic and having identical structure and accessibility for all kinds of touchpads.
Lesson learned: Get a device specific Data sheet!!!
The test codes for writing to a register as well as the PS/2 implementation code (Mega32 in assembly) are included in Appendix B. We are certain that given the correct touchpad (Synaptic compatible), the codes will work perfectly. Following the breakdown of the code, anyone can use these functions to retrieve data packets from the touchpad and write an algorithm that displays the data. The trickiest part was implementing the touchpad functions.
Results/Conclusions
Analysis of design
Our original goal was to interface the touchpad as well as a keypad to the microcontroller as the input devices and have the display on the TV. With the touchpad – keypad combination we hoped to incorporate special drawing features, like drawing straight lines, rectangles, circles, text, etc. We had also planned on porting the final image onto a computer via the on-chip USART of the microcontroller.
We really regret to say that we could not meet all our proposed goals. This was essentially due to the initial set back with the confusion regarding the protocol used by the touchpad. Another point that slowed down our speedwas that we had to keep testing various approaches at every stage as we did not have a datasheet specific to our touchpad, nor was it possible to contact anyone with definite knowledge regarding the same.
We are still proud to say that we did finally get our project to perform its basic function. We modified the initial setup so as to have the display on an oscilloscope due to its incremental update algorithm as our touchpad seems to function only in relative mode. An additional point to be noted is that this modification also enables easy porting onto the computer. Finally we were also able to display on a TV screen. Though there are a few glitches that need to be debugged, the TV display algorithm is definitely a working model.
Intellectual property considerations
Initially we were under the impression that the touchpad we had worked with the PS/2 protocol. One of the previous Final Project’s already demonstrates the PS/2 implementation on an Atmel microcontroller. Thus we were hoping to use that as the base and expand further on it to include the display as well as some more drawing features. As such we ported that code to be compatible with the ATMega32, but we couldn’t really use it as our touchpad did not support the PS/2 protocol. We have included our version of the PS/2 implementation in the Appendix for quick reference for someone with a PS/2 touchpad as we are confident of its accuracy.
The final code that we used carries out the communication with the ADB protocol. We studied this protocol and built up the algorithm from ADB protocol information available in Apple documentation as well as on-line references.
Ethical considerations
We can honestly say that we upheld every point stated in the Code of Ethics throughout the duration of the project. Specifically we would like to note:
· Point 2. “to avoid real or perceived conflicts of interest whenever possible, and to disclose them to affected parties when they do exist” On several occasions, we were asked to kindly give up a workstation since our deadline was last. We had anticipated the restricted lab use but due to factors outside our control we were still working on a challenging schedule. On all occasions we were extremely accommodating and we returned during less crowded lab times.
· Point 6. “to maintain and improve our technical competence and to undertake technological tasks for others only if qualified by training or experience, or after full disclosure of pertinent limitations” During the course of this project we did extensive research on two communication protocols. Not only did we increase our knowledge base, but by making our code publicly available, we hope that in the future it’ll be of even more use.
· Point 7. “to seek, accept, and offer honest criticism of technical work, to acknowledge and correct errors, and to credit properly the contributions of others” We actively sought feedback from both Professor Land
· Point 8. “to treat fairly all persons regardless of such factors as race, religion, gender, disability, age, or national origin” By default, we always abide by this rule. We’re nice.
· Point 9. “to avoid injuring others, their property, reputation, or employment by false or malicious action” This was simply followed. It’s an extension of live and let live policy. We respected others and their belongings and were awarded with the same consideration.
TV Implementation
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 protocolremain 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.
TV Background
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.
Sync Generation
For the image to be properly displayed without any jitter, uniform pulses (63.5
long) 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.
long) 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. Image generation
We were supplied with a video generating code that contained the appropriate definitions. There were small/large character bitmaps, and video functions such asvideo_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.
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 seemsslugglish. 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.
*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 seemsslugglish. 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.
Conclusion
We completed all the tasks we set out to accomplish. We drew to the screen, yes!
0 comments:
Post a Comment