GPIOTE Tasks

[Timur Beganovic]

How many GPIOTE Tasks can I use at the same time. I want to drive six different pins with six different tasks which are connected to three events. Each event generates two tasks.  
Although I am using different channels for each task I can only assign four tasks
because of:  __O  uint32_t  TASKS_OUT[4];  

NRF_PPI->CH[0].TEP = (uint32_t)&NRF_GPIOTE->TASKS_OUT[0];

Is the task number really limited to four tasks?
 
best regards

[Timur Beganovic]

Any change on the PCB would imply a new PCB design because I am dealing with large amount of devices.

Besides that, I need to have two operational modes:

1. to drive two pins together (3 x 2 pins)

2. to drive all six pins separately

For the Mode 1, I use 3 GPIOTE channels which generate three different tasks (based on three different Timer events). These tasks call three different ISRs which set/clear two pins at once.  My goal is to avoid any ISR because they are blocking the CPU which is critical for my project.

For the Mode 2, I use three GPIOTE channels which generate three different tasks (based on three different Timer events). These tasks don't call any ISR but drive three different pins directly. For other three pins I have to use app_timers. CPU blocking in the Mode 2 is not critical for my project.

[ovrebekk]

Hi

I am racking my brain trying to think of some workaround, but I am coming up empty...

On the nRF51 I can't think of any way to control more than 4 GPIO's over PPI, so you will have to set the remaining 2 pins from interrupts. 

The question is if you could tolerate any latency on the pins, so that you don't have to give the GPIO interrupt the highest priority. At least then the CPU won't be blocked if you have important interrupt occurring at a higher priority. 

Best regards
Torbjørn

[Timur Beganovic]

HI Torbjørn,

I appreciate a lot your willingness to help me and your knowledge.

I also think that there is no way to drive more than 4 pins on 51822 using task-event module.

Regarding your question about interrupt priorities; the application receives RF packets continuosly in a poll manner.  Some of these packets contain an instruction which has to be performed  without any latency or CPU blocking from something else. The problem is that the application doesn't know when this particular packet arrived before it parses it. If I implement the whole packet reception using Radio interrupts, that wouldn't be tolerable for the pins because they control LEDs based on PWM.

best regards

Timur

[ovrebekk]

Hi

If the RF processing needs to have higher priority than the GPIO update I guess the question comes down to the worst case processing time of the RF packet processing, and if you can tolerate this latency on your GPIO update.

Since the radio uses DMA to store incoming data in RAM it's only the process of analyzing and acting upon the incoming data that will require CPU activity. 

Best regards
Torbjørn