Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[mallok05]

Hi all,

I searched quite a lot,  checked the datasheet and tried to analyze the code but can´t find a good starting point how to run my GUI interrupt-driven.

I want to reduced the system load and therefore only communicate with the gpu when there is a touch input by the user.

But I can´t get a grip of what to trigger by the interrupt handler of the mcu once a touch occurs. I guess it have to assign touch tags of my elements and then handle the ESD_Slot (idle, render, update) within the ISR?
I´m using an AtsamE70 with Ft810. The system works completely fine, I ported the necessary spi routines to the atmel mcu.

Maybe someone can give me a hint or point out where my view of the interrupt-driven approach is faulty.

Thanks + greetings

[Rudolph]

The interrupt is only the signal that a touch event occured.
So yes, you still need to assign touch tag values in order to get events
and at least read the current value when an interrupt occors.

But since reading the touch tags over SPI takes time as well (8 bytes) I would only set a flag
to indicate that touch should be looked at in my main loop (and only if that flag is not set already).
At 12MHz SPI it takes about 5,5µs to read REG_TOUCH_TAG.
This could be shortened by only reading the low byte to around 3,5µs.
That is like forever in IRQ for a 300MHz controller.

I am not using interrupts though because of how much time it takes to read the tag value and because
of the unpredictable nature of these interrupts.
I am just polling the tag value(s) once every 5ms as reading the values is necessary either way.

Hmm, I should update my sample-code: https://github.com/RudolphRiedel/FT800-FT813

Right now I am looking at 26µs idle for a two-point "multi-touch" function (BT815) that also includes making sure that EVE ist not currently otherwise busy.

If a touch event is registered only global vars are changed by my function.
Like which screen is to be displayed or how a toggle-switch or button is to be displayed.

Every 20ms my display gets refreshed, regardless if there are changes or not.
Tracking all possible changes and only updating on change only works with a static display.
But I am displaying for example measurements as well and use the timed refresh for animations.

My current GUI is processed in <250µs and then send over SPI using DMA.

The result is a 354µs load for the display within a 20ms intervall when idle, that is less than 2%.
I set myself a "limit" of 1ms for processing the GUI, that would be an allowable load of ~5%.
And the reaction to touch events feels instant.

Well, that is at least what works for me.

[mallok05]

Hi Rudolph,

thanks for your feedback and the good summary about interrupt handling and its pitfalls/design consideration.
I will check your library and see if I can gain more insight for my project.

I forgot to mention, that my system runs an OS and the Gui has the lower priority for the scheduling. Thats actually why I considered an interrupts approach first because I think it´s better to implement than adapting the entire timing for the scheduling. But I´m at the very beginning of the interrupt implementation.

I´ll keep this thread updated with my progress maybe some might be interested in it too and also leave some lessons learned to posterity

Cheers!