UEXT PINs 3 and 4 MOD-LCD2.RTP

[striderheng]

Hi,
Am I correct in reading the CAD drawing that PIN 3 and 4 of the UEXT block is not connected to anything at the moment??
On the AR1021 chip, is pin 9(i2c IRQ) connected to anything or do I have to jumper SJ3 to have it connected to UEXT pin4(marked IRQ)

If I understand the AR1021 documentation correctly, I need to drive IRQ low to send commands to the controller???

I have been trying to send commands to the AR1021 via the i2C interface but am getting wrong header or command timeout responses.

[LubOlimex]

Yes, as I wrote in the other post it is I2C and I2C is pins 5 and 6 of the UEXT. These two pins are sufficient for touchscreen operation as demonstrated by our demo software.

By default Pin #9 is not used (it is connected to a disconnected jumper) - it is not needed for touchscreen operation.

[striderheng]

Yes, I understand UEXT 5,6 is for the i2C to the AR1021 controler. I have been trying to send commands to it but I keep getting errors. The touchscreen controller is continously sending 5 bytes touch report data packet on i2C which is the default behaviour for the MOD-LCD2.RTP.
But I want to to do more with the controller.
Going back to my original question about UEXT pin 4 which is marked TXD in the CAD drawing, which seems to lead to open? jumper3(SJ3) and to AR1021 pin9(marked i2c iRQ) on the other side of SJ3.
The AR1000 documentation seem to indicate I need to drive IRQ low(which I assume is AR1021 pin9) to send commands to AR1021. Am I correct in this?
Out of the box, UEXT pin 4 is not connected to anything, correct??? All the lines in the CAD draving for UEXT pin4 seems to go to open jumpers.
Would is be a problem to connect jumper SJ3 so that I can access AR1021 i2c IRQ(pin9) to be able to send commands to AR1021???


OK, after rereading more docs, AR1021 pin9 is a output pin so no help there.
Reading more on a different doc which mention this mode. Is this what is compiled and loaded into the AR1021 chip???

2.5.2Verifying controller bus data
To ensure the SPI or I2C bus has been enabled and configured correctly, it may be useful to know if we are reading data correctly. Within the AR1020/AR1021 driver, there is a mode such that the data is constantly clocked from the controller (ignoring the state of the IRQ).  To enable this mode, add the kernel parameter "ar1020-i2c.testI2Cdata=1" if using the AR1020/AR1021 I2C driver component or add the kernel parameter "ar1020-spi.testSPIdata=1" if using the AR1020/AR1021 SPI driver component. For an example of setting up a kernel parameter, please see section "2.4.1.1 Increase kernel log level using kernel parameters".Using this mode, it can quickly be determined by touching the touch screen if good touch data is being seen by the system.  A good packet will consist of a "0x80" or "0x81" value followed by four data bytes

[LubOlimex]

It is not a problem to solder the pads of a jumper together, if there is some issue you can always disconnect them back open.

But my advice is to study the part about the touschreen in our libraries that we have published, and more importantly in these two files:

https://github.com/OLIMEX/MOD-LCD2.8RTP/blob/master/SOFTWARE/Arduino/graphicstest_olimex/Adafruit_STMPE610.cpp

https://github.com/OLIMEX/MOD-LCD2.8RTP/blob/master/SOFTWARE/Arduino/graphicstest_olimex/Adafruit_STMPE610.h

Notice that these are modified libraries, not the same as the ones released by Adafruit!!!

[striderheng]

Yes , I have studied them and I have concluded that 90% of the code in there is not needed to run the demo plus its for a STMPE610 controller, not a AR1021 used by Olimex.

Pretty much the other functions in the library cannot be used as the command codes are wrong for AR1021, the coding is for reading or writing to STMPE610 which deosn't work for AR1021 and the outputs from AR1021 is obviously different from data coming STMPE610.
All you really need is the wire library and use i2C to read the data that is continuously pumped out. I stripped out the useful code in the demo code(the 5 bytes touch data packet read and bit movement parts to get the x,y data) and rewrote it as a function, and it seems to get data no problem from the i2c link.

But this is not the problem I am trying to overcome.
Reading the AR1000 documentation says I should be able to send commands to the AR1021 to get info or do some stuff(as described in their doc) but I keep getting error responses. That is my problem. I am trying to understand why it will not accept my commands. I followed the document instructions to send commands to AR1021 but all I get are error response, saying the header is wrong or command timeout.

9.0COMMANDS
9.1Sending Commands
9.1.1COMMAND SEND FORMAT

To ensure command communication is not interrupted by touch activity, it is recommended that the controllertouch is disabled, prior to other commands. This can be done as follows:
1.Send DISABLE_TOUCH command
2.Wait 50 ms
3.Send desired commands
4.Send ENABLE_TOUCH command

This is the document I am referring to

https://ww1.microchip.com/downloads/en/DeviceDoc/40001393C.pdf

Is the code compiled for the AR1021 kernel set to some mode where it will not accept commands over i2C and is only outputting data continuously???
 

[KeesZagers]

Hi,

Also I struggled with this chip to get it working with the Duinomite hardware. In the end I got it working at a lower speed I2C: 100 kbit/sec. Sending 0x55, 0x01, 0x13 for disabling and 0x55, 0x01, 0x12 for enabling. However the response was not always 0x55, 0x02, 0x00, 0x13 cq 0x55, 0x02, 0x00, 0x12 as expected. Sometimes an extra 0x55 was included so 0x55, 0x55, 0x02, 0x00, 0x13/0x12. Don't ask me why, but for me this was the only way to get it working. Maybe this information helps you. Good luck.

[striderheng]

HiKeeZagers,
Yeah, thats what I got too except I kept getting error responses. The responses is not consistent as you have mentioned, although in one of the other documents in the AR1021 product page(for usage with Linux), it is mentioned you should proceed the command with 0x00( like 0x00 0x55 0x01 0x13 otherwise you will get inconsistency in the i2c comms. I manage to get a proper response, although it was an error response, one late night which I have not been able to get again since then.
Looks like I need to tweak the speed a little or maybe use the AR1021 i2c IRQ output pin to check for pull to low before proceed with command sending. Thanks for your feedback. At least I know it is possible to send commands. I was worried about a mode mentioned in passing in one of the AR1021 product page documents that you can set the AR1021 to i2c test mode in the AR1021 compiled code where is it continuously only doing output so that you can test and tweak the i2c comms.
I was planning on hooking up other sensors to the same i2c bus as well but going to have to see how this is going to work in the end but first need to get consistent behaviour form the AR1021 otherwise this is not going to work for me.

[KeesZagers]

It has been about 2 years ago, I worked on this issue, but as far as I remember I got the error responses also as long as I worked on 400 kbit/sec. In my code now I use 100kbit/sec for the commands to the display and as soon as it is operating I switch to 400 kbit/sec.

[striderheng]

OK, I got it to work. There is still some errors which I think is due to making sure that the AR1021 is ready to receive commands before telling it to do something.
Its a mixture of
1)set i2c frequency to 10kHz.(have to check if higher freq works)
2)checking the IRQ pin to see if the AR1021 is not sending out data before attempting to send commands
3)sequence of hex bytes preceding the command,( e.g; 0x9a, 0x00, 0x55, 0x01, 0x13 to disable touch)
4)wait 50ms
5)send out the command on i2c
6)poll the IRQ for it to go high(showing that the AR1021 is ready with sending data) 7)read the response data.
I notice that when I send command to get version, it took like 15 poll cycles of the IRQ line before the data was ready to be read. This compare to like to no wait when you do a touch disable or touch enable.