Cobra 2 touch very slow to resond

Archive
1

I have an application running on a Cobra 2 and I am finding that the touch screen is very poor response time. I often have to hit a button a number of times before it responds.

I have 5 threads in total running. 1 handles the display, 1 handles the GSM modem, 1 handles the HTTP request, 1 handles the sending of data over TCP/IP to a server and the last one handles the Xbee network.

The display is refreshed every second. Sleep is called at the end of the loop with a value 1,000ms

The GSM is checked for any SMS every 10 seconds. Sleep is 10,000ms

HTTP handler is simply waiting for a connection.

The server thread send the data every 2 seconds. Sleep is 2,000ms

The Xbee thread just does a few variable checks to see if we are to send any data. Most of the time is only sends about 1 per day. The sleep is 1,000ms

The Xbee received data is handled with a data received handler. I am using the MFToolkit for this. Data is transmitted by 3 sensors and each one sends every 2 seconds.

Now, if I disable the Xbee thread so that it does not start the data received handler, I get perfect response from the touch screen so I am therefore happy that the issue is not in the other threads. Same effect if I disable the sensors to stop sending and only have the thread started so there is no data being received.

I have looked through the MFtoolkit source and there are thread.sleep calls being made during the polling for data. The code does not use a datareceived handler. All data is polled.

There is no delay in my display code. I can see the clock being updated every second as expected.

I have even tried to set the Xbee thread to lowest priority and no change.

Has anyone else using the Cobra 2 run into issues with touch response?

On my ChipworkX based design, I use interrupt handling to read the touch and it has a similar system reading Xbee with 10 sensors and the response to touch is as fast as it can be.

How is the touch processed on the Cobra 2? I can see that it is via the ADC on the processor so wondering how often this is processed? I would assume that there is no interrupt with this and it is handled via polling?

2

Correct.

On the ChipworkX with interrupt driven touch, there is no issue using the same Xbee driver and that was with many more modules sending to it.

3

Yes. I have stopped the HTTP, GSM and Server threads. Still same result results.

4

Can you produce a minimal example that reliable reproduces the poor response? As little code as possible. Which Cobra II variant and which display are you using?

5

Hi John, I’ll see if I can do it but it may be related to the MFToolkits handling of Xbee data so may not be possible to cut it down.

If I can create a basic app with the MFToolkit that has the same issue, you won’t be able to test unless you have XBee modules to talk to it.

I am using the Cobra 2 WiFi with a TE35 display.

My other Cobra 2 with GSM and a fingerprint reader has no issues.

6

Just thought I would revisit this and update what I found.

I had updated the software to 4.2 R3 and at the same time added some new features. During this update I found that I could not calibrate the touch screen. There was no response to it. During calibration no other hardware has been initialised at this point.

I ended finding that is was the cable from the LCD for touch. After I unplugged and reconnected this it started working and now the application is also stable and touch works fine even with Xbee which I thought was the fault.

Just in case someone else spots this and has similar issues and come across this post during a search.

7

Hmm, I had a Cobra II system with a T35 which has no touch connection cable in use. And it seemed to be REALLY slow - but working. Button-presses was missed, and the char display was updating at a rate of 5 chars/second = 6 seconds to update 32 letters.

I connected the touch cable, and now it works as it should. I think this is a bug?

8

Hi Niels,

Did you enable the touch driver in the code?

I am pretty sure this will cause an issue as the ADC inputs will be LOW and the driver is likely to detect this as a touch and try to scan for the touch point. With it always being LOW, the driver is going to be quite busy.

9

That sounds like a reasonable cause of my problem. I dont see a feature in the current driver to do that. Do you have any pointers as to how it can be achieved?