Implementation of a custom Touch Screen Driver

Question

Dear all,

Platform Description:

• EW 9.10 Free, on FreeRTOS 10.1.1. + cmsis_os2 (wrapper).
• STM32F429 + External RAM on Custom Hardware
• 800x480 LCD display RGBA8888
• 4-Wire resistive touch screen interface.

Currently we've ported an old implementation of the TouchScreen implementation, which is based on  driving the 4 wires on specifics configuration and then reading back the values directlyl by the internal ADC of the STM32f429.
The literature we followerd can be found here (http://www.lysator.liu.se/~kjell-e/embedded/doc8091.pdf  and here for the calibration http://www.ti.com/lit/an/slyt277/slyt277.pdf).

 

The routines for touch measurement are executed on a separate thread on FreeRTOS, which does not belongs to the Gui Task. 

  ew_Task = osThreadNew( GuiThread, NULL, &ew_Task_Attrs);
  tsTask = osThreadNew( touchTask, NULL, &tsTaskAttrs);

Can this cause any issue? 

 

The logic of the reading of the adc are:
1. Config pins for touch event.
2. When event occured a osEvent is triggered and the thread from suspended become active.
3. Do the ADC measurement (adc compelted generate an event too)

4. Once there no more pressure on the display the task reconfigure the pin for touch event and so become suspended again, without draining any system resources.

5. At the end of the conversion & transformation in display coordinate the data are saved into a struct, protected by a semaphore(mutex one).

 

The EwBspGetTouchPosition call a function which retrive the converted data, Also this function is protected by a mutex with 0 timeout, so the EwBspGetTouchPosition will not be blocked.

 

bool isTouched(tsAdcValues *ptr)
{
  if ( osMutexAcquire(semTS, 0 ) == osOK )
  {
    memcpy(ptr, &tsEWCopy, sizeof(tsAdcValues));
    osMutexRelease(semTS);
    return tsEWCopy.isTouched;
  }
  return false;
}

We are experiencing sometimes that the task in charge of the touchScreen measurements is like suspended while the Garbage Colelctor is running (specifically in Core.c, around line 3413, the function is CoreRoot_Mark(CoreRoot _this) ).
Are we doing something wrong ? Is this a good way to integrate a custom touch screen controller?

 

Thanks in advance

Davide

 

Answer 1

Hi Davide,

 

I estimate that could be a FreeRTOS based problem. As first idea I would suggest to verify that the stack size is correct for each task.

Embedded Wizard 9.10 needs around 4-8 Kb stack size. To make sure that this is not the problem, please try a value at the upper range or higher (> 8Kb).

Could you please verfity this?

 

Some other ideas:

1. Does the tasks work properly if just one of them is active?

2. Unfortunately we are not experts in FreeRTOS, but normally the Embedded Wizard generated code works pretty well with FreeRTOS. So, could it also be that the semaphoring cause this problem?

3. Another reason could be the general FreeRTOS settings, for instance the minimum heap size or task priority?

 

Looking forward to your answer!

 

Kind regards,

Tim

 

Comments

Hi Tim,

 

I investgated today, we was running with  5K of stack. We increased to 8 now.

About your questions (really appreciated your point here):

 

1. Yes, the task, if run alone it was working quite good without getting stuck or delayed.
2. I think so at this point. I will try another approach by using queues or stream buffer. I rather prefer (for this case) a queue with 1 element only, where a new touch will be put on the head (removing the previous one). This is to prevent false detections.
3. Priority are ok, i've tried to lower EW and increase the TS task.

 

Generally speaking did you see any problem by keeping seprate the TS detection on a different task?

Keep you posted on the results in the next days on the results.

 

Thanks again

Davide

---

Hi Davide,

I am looking forward to get know whether it works.

Generally it isn't a problem to process the TS detection in a different task.

Kind regards,

Tim