STMPE811 touch driver WIP

[resset]

WIP == work in progress

Hi Tectu, let's move to another topic with this driver.

I have seen that you uploaded some code for STMPE811. That's great news, and big thanks:)

But I must also say: arrrgh... It was this magic "| PAL_STM32_OTYPE_OPENDRAIN" that prevented me from running my demo:/

I made a few changes/bugfixes in my merge request. It's faaar from being finished but let's have initialization, readings etc. done at least.

I changed STMPE811_REG_ADC_CTRL1 value from 0x49 to 0x48 because its "0" bit is reserved.
Also, for STMPE811_REG_TSC_CFG having 0x9A value the comment is wrong; 0x9A gives: 4 samples averaging, 500 us touch detect delay and 500 us settling time. Value from comment should be 0xA3 - please make a decision (I think 0x9A should be fine, didn't compare to other drivers). I marked it with @TODO.

I made reading working:) But so-called interrupts are not working yet.

And rather esotheric question: how reading should really be done? It's just my rambling, I may be totally wrong:

Code: Select all

uint8_t interrupts;
interrupts = read_reg(STMPE811_REG_INT_STA, 1); // Find out what caused an interrupt
if (interrupts & 0x02) { // If it is FIFO threshold, clear it
   write_reg(STMPE811_REG_INT_STA, 1, 0x02);

   // Read XYZ values
}


[Tectu]

Hey resset,

I merged your pull request, thank you very much for your effort! The code I pushed to github wasn't tested yet so there were some nasty errors for sure
In fact, I took me three evenings to get the I²C working as well. However, exactly as you, I couldn't get any interrupt from the controller yet. If you find out why, please tell me, I did everything I knew

And you are right at the other two things. Not setting the reserved bit is as correct as the commented value isn't correct. To latter, I plan to introduce a new high level function call to GINPUT which allows it to change the filtering while run time. Together with that, I'd make something similar to give the user the ability to take advantage of the touchscreen controllers windowing functions. What do you think?

About your interrupt question: I think that's not the worst idea. We just must make sure that we also handle the temperature threshold values etc properly. This is farly quick when you use a switch statement and put the actual coordinate reading on top of it and the less important ones, as the temperature, at the bottom.


~ Tectu

[resset]

Thanks:)

I think we should get the most of this chip, so windowing and and filtering options would be great. But currently have no vision of its API in driver. I must look deeper into architecture of GFX in order to help with that.

Ups, I switched temperature readings off with my last commit regarding STMPE811

I go back to looking around in GINPUT and ADS driver.

One question: do you still have external 4k7 pullups in your setup?

Mateusz

[Tectu]

Yes, I had to solder two external 4k7 resistors on the board. I think the one on SCL is obsolete. On the schematics of embest, I can see that they only put a 10k pullup on the SCL line, but none on the SDA line. My scope told me that this isn't nice. I cannot confirm that it works but I'd suggest you to try.


~ Tectu

[resset]

I can confirm that it should work because their demo code works somehow;) There was this demo app, I have it here (in accompanying CD): code/STM32F4xx_Discovery_StdPeriph_Demo/Project/STM32F4xx_StdPeriph_Examples/03-LCD/LCD_Touch/

However, this is weird setup. On ATmegas I always used pullups on both lines.

[Tectu]

I completely agree with your, on ATmegas, I always used to pullups as well. I didn't try their demo code, but I guess it must work somehow. However, I cannot get the proper value yet as well. Try to find the error


~ Tectu

[resset]

Hi.

So I finally got it to work - I made one really simple change. I inserted 10 ms wait after software reset of STMPE811. And from my tests it turns out that (as opposed to what I wrote on IRC) no reset clear is needed. Also STMPE811_REG_SYS_CTRL2 was set up OK.

Strangely enough, it worked for me but I need somebody to confirm this. I made few additional cleanups. The reading routine needs some polishing of data it gets. Now it just divides 0 - 4096 (12-bit) ADC value by 13 for width and by 17 for height and that's how we get 320x240 touch area;) Also, just for tests i disabled calibration and lowered read cycles number in *_config.h file.

I run demo from here: http://chibios-gfx.com/documentation/ginput/touchscreen

Unfortunately you don't get the pixel changed where you point your finger, not yet:|

The code is waiting for merge and for fixing - what I'm still eager to do, but it takes me some time as you can see.

Mateusz

[Tectu]

Hey resset,

Thanks for the pull request, I've merged it. I didn't really had time to test it but ten minutes before I ran for the bus, I gave it a try. On my scope, I can confirm that there's an interrupt happening when you touch the screen. However, It's just a small spike instead of a low period as long as pen-down. I'm pretty surprised by this, I cannot understand why. There's this bit in the CTRL2 register where you can set the interrupt into level or edge mode. I changed it but then I don't get any results at all.
I wasn't able to read out any useful coordinates yet too. We first need to get that interrupt fixed, no?


~ Tectu

[resset]

Hi Tectu

Good to hear that it works for you.

This is what should happen with this code because I immediately clear interrupt when it comes (lines 118, 121, 122 in ginput_lld_mouse.c), so really I get only single point readout.
But this may be easily fixed and I think we should use FIFO and its interrupts.
Coordinates are wrong, I know. I just have to sniff in ginput to get it working correctly.

Mateusz

[Tectu]

Ah, when you clear the interrupts directly, it makes sense that I only get a small flag. The question is if this is a good idea. All the other touchscreen controller we're currently supporting keep the low level as long as the pen-down event is happening. The problem I see is that we don't get another flag when you move the point of touch. This means that the software never knows where you're currently pointing at and you cannot "draw lines".
We should definitely over think the interrupt handling. I'm not sure yet if using the internal FIFO is it worth, I didn't read about that much yet.

What do you think?


~ Tectu