STM32103ZET6 prototyping board comes with LCD having touch screen capability. It is a great way to interact with device. Practically speaking Touch screen is a resistive film that can be read as regular potentiometer which value depends on touch point. Depending on voltage drop it is possible to calculate the coordinates. To make things easy normally there are touch screen controllers used that takes most of hard work – they have internal ADC that measure the voltage and sends value to microcontroller using a selected interface (I2C or SPI). In our board there is a popular ADS7843 controller used, which talks to 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 code reads a bunch of values, then averages to get rid of most garbage and then calculates screen matching coordinates. This is a trickiest part to do. You can do this empirically by getting min and max ADC values for each axis and then calculate coordinates using formula:
*x = ((TP_X-PixOffsX)/PixSizeX);
We recommend EasyEDA for circuit design and PCB prototype
*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. Biggest one is that code is hardware dependent, this means that when 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 adaptive technique called calibration. This is when you need to tell device to align touch screen with display by giving several points that are used to calculate coefficients. These coefficients are used in 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. Common solution is to use median filter to sort out scattered data. Also it is noticed that first read after touch gives messy data because screen needs some time to settle down. Probably it is best to throw away first data pair and use following ones. SPI read speed also can influence data quality.
So next step would be to implement touchscreen data filtering, then implement calibration routine and of course cleanup the code in to nice lib. Here is a test code it you have similar board and want to try touch screen [STM32Touch.zip].