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 touch point. Depending on voltage drop it is possible to calculate the coordinates. There is a touch screen controller which takes most of the hard work – it has internal ADC that measures the voltage and sends a value to the microcontroller using one of the selected interfaces (I2C or SPI). In the board, there is a common ADS7843 controller used, 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 a bunch of 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 actual ADC value, PixOffX is offset value at axis point 0, and PixSizeX is ADC values 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; this means that when a different screen is used, you will need to measure new constants to be able 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 that are used 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 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. Also, it is noticed that first read after touch 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.
So next step would be to implement touchscreen data filtering, then perform calibration routine and of course clean up the code into nice lib. Here is a test code if you have a similar board and want to try touch screen [STM32Touch.zip].