STM32103ZET6 prototyping board comes with LCD having touch screen capability. It is a great way to interact with the device. Practically speaking Touch screen is a resistive film that can be accessed as a regular potentiometer which value depends on the touchpoint. Depending on voltage drop, it is possible to calculate the coordinates. There is a touch screen controller that takes most of the hard work – it has an internal ADC that measures the voltage and sends a value to the microcontroller using one of the selected interfaces (I2C or SPI). There is a typical ADS7843 controller used in the board, which talks to the microcontroller using SPI. After playing around, I’ve put a messy code that reads touch screen coordinates. It is a glued code from various sources, so it is only to fix some results.
Currently, the code reads many values, then averages to get rid of most garbage, and then calculates screen matching coordinates. This is the trickiest part to do. You can do this empirically by reading min and max ADC values for each axis and then calculate coordinates using formulas:
*x = ((TP_X-PixOffsX)/PixSizeX);
*y = ((TP_Y-PixOffsY)/PixSizeY);
Where TP_X is the actual ADC value, PixOffX is the offset value at axis point 0, and PixSizeX is the ADC value per pixel. I found that some touch screen libraries use this approach. But it has many disadvantages. The biggest one is that code is hardware dependent; when a separate screen is used, you will need to measure new constants to calculate coordinates. Right now, example code works using this method. It would be better to use an adaptive technique called calibration. This is when you need to tell the device to align the touch screen with the display by giving several points to calculate coefficients. These coefficients are used in the formula where actual coordinates are calculated from ADC values.
Also, there is a problem with messy data read. Sometimes touch screen controller gets data points that are scattered around the actual. Even hard averaging doesn’t help. So it needs more intelligent processing of data acquired. The typical solution is to use a median filter to sort out scattered data. It is also noticed that first read aftertouch gives messy data because the screen needs some time to settle down. Probably it is best to throw away the first data pair and use the following ones. SPI read speed also can influence data quality.
The next step would be to implement touchscreen data filtering, perform calibration routine, and clean up the code into nice lib. Here is a test code for a similar board and want to try touch screen [STM32Touch.zip].