Camera32
Designed by Paul Miller
Camera32 is a 32-bit interface circuit for our current 8-bit camera, allowing the DSP to handle four times the information without additional I/O time.
Purpose: The current camera interface circuit is too slow, allowing a maximum frame rate of approximately 12.5 fps. This limitation is primarily due to I/O time. For each pixel, the DSP spends approximately 100 ns reading the data from the camera's 8-bit data bus. (Note, the 100 ns I/O time is imposed by the daughter card's chip limitations, and both boards are in the same memory space -- CE2.) Camera32 is designed to allow the camera to run at its maximum frame rate of 50 fps without increased I/O time.
Background: There are two major hardware factors that effect how fast the DSP can read the camera's data. One, the amount of time reading the data (i.e., 100 ns with the current design); and two, the amount of information read at a time. The latter is generally preferred as it reduces the number of reads required, thus running the bus at the same speed.
Design: Since our DSP (TI's C6711) has a 32-bit data expansion interface, it is capable of reading 32-bits of data every read cycle. This bus handles four times the information that the current implementation uses. Conveniently, 12.5 fps times 4 is our target of 50 fps. In order to convert our 8-bit read data interface to 32-bit, we must prepare four pixels of data before interrupting the DSP for a read cycle. This "preparation" is done using a combination of latches and a counter. The counter is incremented for each outgoing pixel and, through a decoder, signals one of the 8-bit latches to store the current pixel. For 32-bits or four pixels, it is only necessary to store the previous three pixels as long as the DSP reads the data while the fourth pixel is available on the camera's data bus. The counter will then need to interrupt the DSP on the fourth pixel for a read cycle. Thus, only three latches and one transceiver should be necessary.
Looking at the 4-bit 74*163 counter in the schematic, pin 1 is connected to VSYNC. When VSYNC pulses, the count is reset to zero. (Note that the number of pixels per frame is divisible by four and thus we will not lose any pixels.) This reset serves mostly as a sanity check. Pin 2 is connected to PCLK (pixel clock), which increments the count. This count is available on the A[0..3] binary output pins. For example, when bits A[0..3] are set to LLLL, the count is zero; LLLH is one; LLHL is two; LLHH is three, etc. These binary signals are cumbersome to work with when we're interested in using a separate signal to control the latching of our data. The 74*538 decoder chip handles this job for us. It is connected in such a way that the output count signals remain low except when active. When activated (high), the 74*573 latch latches the current data on the camera's data bus. On the fourth count (three), the DSP is interrupted. (Note that each latch and the transceiver are connected to separate data lines on the DSP's 32-bit data bus.) Upon the DSP's read cycle, the 74*245 transceiver is setup to transfer data from the camera's data bus to the DSP's 32-bit bus. Clearly, this data is only available for a short amount of time (approximately 180 ns at 50 fps). After this window closes, the first latch (zero count) will be updated with the next pixel. To be safe, the read cycle time was reduced to 50 ns from 100 ns. (Possible since we're now interfacing directly through the DSP's expansion header, and not the daughter card. This interface allows us to use a different memory space (CE3) that can be configured separately from the daughter card's CE2 memory space.) This process is repeated every four pixels.
Conclusion: Comparing to the current 8-bit design, Camera32 provides four pixels of data at 1.4 MHz (50 fps) opposed to one pixel at 1.4 MHz (12.5 fps). Of course even if our DSP can now handle 50 fps of data with the same amount of I/O time, processing four times the information will be another limitation. Reducing the frame rate will allow more processing time, since the data is read every forth pixel. Another significant benefit is the ability to use the camera's analog output signals; at 50 fps, the camera outputs an analog signal that can be connected to a standard video component input (i.e, connect the camera to a television). This feature is helpful for focusing and aiming the camera, as well as debugging.