Project Final Report Optical Hand Scanner

Transcription

1 Optical Hand Scanner B.V.B. Project Abstract The purpose of this project was to develop the embedded hardware and software to turn an optical mouse sensor into a hand scanner. Optical mice operate by rapidly taking pictures of the underlying surface, and feeding this stream of images into a digital signal processor to generate movement vectors, which are then used by the controller to determine how far the cursor has moved across the screen. This project involves extracting the optical sensor, and using it to create a hand scanner by stitching together the tiny images of the underlying surface. Status Unfortunately, the project did not turn out as expected. Although it did appear that communication was enabled from the zilog to the ADNS-2610 chip, communication in the opposite direction could not be enabled. This is due to one of a number of factors. 1. The optical sensor may not have provided adequate output voltage to register as a logical 1. This is unlikely since the input pin had pull-up enabled and the input register was reading that it had clocked in all ones. It appears the chip never pulled the SDIO line low in the first place. 2. The chip may have been damaged. For periods of time throughout the construction of the project, the sensor was searing-hot to the touch. Figuring that this was normal operation, I simply avoided touching it. After reconfiguring the wiring, the sensor was no longer hot to the touch. This could have implied that the earlier wiring configuration was short circuited and too much current was flowing through the optical sensor. 3. Unstable wiring due the the sensor's staggered pin configuration, the sensor would not fit onto a standard breadboard, requiring an adhoc solution that would frequently cut the power to the sensor. This could have reset the part without my knowledge. 4. The external 24 MHz oscillator may have been damaged and not provided a clean signal to the ADNS-2610's internal logic. The damage could have been inflicted in the process of desoldering the oscillator from the mouse board, and onto the pins of the optical sensor. Page 1 of 8

2 Specification The first figure reveals the pinout of the ADNS-2610 optical mouse sensor. When placed in a mouse, this chip is normally connected to a digital signal processor, which reads the image off of the sensor and provides a USB or PS/2 interface. In this project, the ADNS-2610 optical sensor is connected directly to the Z16 via GPIO pins, and will not interact with the sensor via a DSP. A significant challenge is that the optical sensor (ADNS-2610) uses a bi-directional, half-duplex control line for both inbound and outbound data. It is the job of the microcontroller to synchronize this transfer (by generating a clock line, SCK). The software components include the following: LED library for controlling the block LEDs SPI library to synchronize clocking in and out bits over the SDIO line ADNS-2610 driver. It stores all addresses and opcodes, controls high-level instructions to the optical sensor (e.g., fetch-pixel, control power, etc...) User application The mouse is interfaced in the following way: Page 2 of 8

3 The SCK line is generated by the microcontoller, specifically by the SPI library. The first 8 bits reference the address of the register the microcontrollers intends to write to, although specifically the first bit of the address byte indicates the direction for the following data byte. For write instructions there is no spacing between the address and instruction byte. The preceding figure indicates the format of a read instruction to the optical sensor. The jagged line indicates that the SCK line must be held high for a minimum period of time before clocking in the data byte, approximately 100 microseconds. If held too long the transaction will time out on the sensor and will desynchronize state with the microcontroller. Page 3 of 8

4 The preceding figure reveals the addresses of each of the relevant registers for programming and enabling communication with the optical mouse sensor. Hardware Configuration Page 4 of 8

5 This is an image of the optical mouse sensor precariously located above a breadboard. Note the LED (ripped off an optical mouse board) has been attached to the breadboard and is shining in the optical sensor. The LED is driven entirely by the optical sensor. A second view of the entire configuration. Note the blue 24.0MHz oscillator soldered onto the optical sensor on the left side of the image. The value in the LED panels indicates the opcode (0x00) and data value (0x40). This is a top-down view of the entire configuration. Page 5 of 8

6 The final image shows an up-close view of the modification to the optical sensor on the breadboard. Implementation & Construction The largest challenge of the project was the construction of the circuitry to interface with the optical sensor. The second major challenge was clocking in bits from the optical sensor, which in the end never worked out. Almost every combination of assigning open-drain and pull-up enabled modes to the SDIO input pin would not yield proper reading of bits from the optical sensor. I thought that if a small pull-up is enabled (setting PxPUE), then bits should register even if the logical high value is less than 3.3, and logical low values would pull the voltage to zero. However, trying different permutations of high and low PxOC and PxPUE did not yield any success. I don't think the issue of switching between data directions would have affected this. Another option would have been to use a separate input and output line on the zilog, and merging them on the breadboard. SPI Library Test In order to evaluate the SPI library to ensure proper synchronization between the SCK and SDIO bits, each line was attached to a separate LED. The clock speed was then significantly reduced to be on the order of half a second. I then visually confirmed (with several test vectors) that the proper sequence of bits has been clocked out correctly. This Page 6 of 8

7 was done by confirming that the SDIO LED was appropriately set on the rising edge of the SCK line. The block diagram illustrates the relationship of the various software and hardware modules. At the lowest level is the hardware, naturally, with communication being enabled to the optical sensor via GPIO pins on the zilog. The software modules are listed as follows: SPI Library. Interface includes write_byte() and read_byte(), as well as set a delay which keeps the SCK at a high level. Internally, it generates the SCK when it intends to clock in or out bits. Optical Sensor Driver. Sits atop the SPI library, contains the table of register addresses and relevant commands for the optical sensor. This includes primitives to set the state of the LED and sensor, as well as queries to for pixel values and camera state. User application. This would consist of an application based around the optical sensor driver. It would include options to query for an entire image frame, buffer it, and then transmit this image via the serial port to a host controller (a PC) which would implement the optical flow algorithms to stitch the images together into a larger mosaic. Could also correct for rotation of the image. LED Library. To drive the block LEDs on the Zilog board. Page 7 of 8

8 Retrospective Important Design Decisions I elected not to use the ESPI functionality of the Zilog. Primarily because the ESPI features assume a full-duplex communication over two unidirectional, half-duplex wires. Since the optical mouse has only one GPIO pin, this would involve rapidly switching the MOSI and MISO lines of the ESPI registers. Furthermore, due to the constraints of this one particular optical sensor, I would rather have fine grained control over the SCK than trust it to an external timer. The SCK for this project is not of a consistent frequency, and in fact if it is run as a consistent frequency it would definitely not work. I do not believe that my SPI library was in error, as I was able to issue write instructions to the chips, such as reset and power-down. This implies the error was entirely in the read phase, and likely that the chip was damaged. Lessons Learned and Reflections A common phenomena known as the 90/10 (or sometimes the 80/20) rule is observed across many different fields. This law is manifested in software development in the following way: 10% of the developer's time is spent designing, developing, and implementing a solution, the remaining 90% of time is spent debugging, and debugging, and debugging. With experience the programmer can pre-emptively debug code by avoiding common fallacies and careful oversight of the design process, but nevertheless the debug-verification cycle still consumes the overwhelming amount of time invested in a project. Unfortunately, the number of hours required to debug and investigate the problems that arose throughout the course of this project exceeded the hours that was allocated to it. Five years and two degrees in the CS department has begun to takes its toll. Though not directly related to this class, my personal point of burn-out has been passed the prospect of spending yet another weekend or late night debugging a programming assignment for school is demoralizing, especially after spending the work-week at a day-job programming and debugging another project; it has drained my former enthusiasm and energy toward these types of projects. However, I'm confident the concepts and lab experience from this class will bear fruit throughout my career. Attachments Attachments: Code, ADNS-2610 datasheet. Page 8 of 8