【正文】 e the hardware. For these integrated controllers, this means writing to memorymapped registers to configure the controllers to a known state. This is done in a function named TouchConfigureHardware() in each driver. In order to configure the hardware, we already have some decisions to make. Should the driver be interrupt driven? What type of conversion rate is required to get responsive and accurate touch position information? Let39。s walk through the thought process used to make these decisions. As for whether or not the touch driver should use interrupts, the example drivers do in fact use the interruptdriven approach. I did this mainly because, to be honest, it39。s fun to use interrupts. Don39。t infer from this implementation that it39。s always the best or correct design, and don39。t let anyone tell you that your touch driver is done wrong if it39。s not interruptdriven. I bring this up only because it seems polling has bee a dirty word to embedded systems programmers. I once asked a client if he was polling or using interrupts to service an input device. The response was this is an embedded system, we don39。t do any polling. I felt (temporarily) like an idiot for asking the question, but on further reflection polling is a very reasonable thing to consider. If you39。re using an RTOS and all of your tasks are often blocked waiting for an external event of some sort, the processor is sitting in an idletask loop, doing nothing constructive. Maybe a better design in this situation is to have your idle task poll for input from your touch screen. It39。s a reasonable design and is worth considering depending on your overall system requirements. How to go about configuring an interrupt varies from one operating system to another. You39。ll find sections of the code have been ifdef39。ed in for each of the many supported RTOSes. In all cases the drivers actually use two distinct interrupts: 1. An interrupt to wake up when the screen is initially touched, known as the PEN_DOWN interrupt and 2. A second interrupt to signal when the ADC a set of data conversions. I39。ll describe these interrupts and how they39。re generated in the following paragraphs. The next question is how fast do we want to receive sample input readings from the ADC. The rate will affect how we need to configure the clock that will drive the touch controller and ADC. We want the clock to be fast enough to provide responsive input and accurate tracking but not so fast that the conversion is inaccurate or the system is consuming more power than required. In my experience, a touch screen needs to provide position updates to the higherlevel software at a minimum 20Hz rate, or every 50ms. Faster is better, assuming the higherlevel software can keep up, and we aren39。t too concerned with power usage. If the touch input response is much slower than this, there will be a noticeable and annoying lag between touch input by the user and visual response on the display. The 20Hz update rate might not sound too challenging, but providing updates at 20Hz actually requires sampling at approximately 200Hz, depending on how many readings we are going to take before deciding we have a stable input. We need to oversample in order to debounce and average the touch input position values. Resistive touch screens, especially the inexpensive variety, are notoriously noisy and bouncy. The driver needs to sample the input for each axis several times before sending a position update to the higherlevel software. The provided drivers default to configuring ADC clocks on the respective processors for a minimum 200Hz (5ms) sampling rate. This allows the driver to sufficiently debounce and filter the ining raw data and still provide a 20Hz true position update rate to the highlevel user interface software. For the Freescale processor the touch controller module is named the Analog Signal Processor (ASP). The processor provides two peripheral clocks that are derived by dividing the core CPU clock. The course input to the ASP block is PERCLK2 (Peripheral Clock 2), which can again be divided to produce the final input clock to the ASP. Note that PERCLK2 drives other submodules in addition to the ASP block, including the internal LCD controller, and therefore the touch driver cannot program PERCLK2 just for a good fit for touch sampling. PERCLK2 is programmed to the highest rate required by all attached peripherals, which in most cases would be the LCD controller, and further divided as required for the slower peripherals. The MC9328MX1 reference manual includes a table that specifies the clock programming values needed to achieve a 200Hz output data rate. Hardware configuration for the Sharp LH79524 requires programming a few GPIO pins so that they are assigned to the ADC function, programming and enabling the ADC clock, and programming the ADC sequencer. The LH79524 ADC is a full programmable state machine and sequencer that is quite an amazing bit of circuitry all by itself. The ADC can be programmed to drive one touch plane。 delay。 take a measurement。 drive the opposite plane。 delay。 take a measurement, and so on all without any core CPU intervention whatsoever. Understanding how to program the LH79524 ADC Sequencer control banks could be a challenge but this is made much easier by an application note provided by Sharp (). The provided driver precisely follows the remendations of this application note regarding how to configure the Sharp ADC sequence controller. Is the screen touched?Once the basic hardware setup is plete, we need a reliable method to determine if the screen is touched. It makes no sense to run the ADC and get conversion readings if the user is not touching the screen. Both controllers provide a mechanism to detect if the screen is touched, and optionally to interrupt the main processor when a touch down event occurs. The driver function that determines if the screen is touched or not is named WaitForTouchState(). When the controller is in the touch detection mode the yaxis touch plane is tied high through a pullup resister. The xaxis touch plane is tied to ground. When the user touches anywhere on the screen, the planes are shorted together and the yaxis plane is pulled low. This can be connected internally to an interrupt generation mechanism known as the PEN_DOWN IRQ. During normal operation the drivers use the PEN_DOWN IRQ to wake up the touch driver task when a touchdown event occurs. This allows the driver task to block itself and not consume any CPU time when the screen is not touched and wake up and go into conversion mode once the user touches the screen. We can also save power by disa