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]

Thank you Torbjørn.

I just need to mirror the signal from the output pin A (which is timer event driven signal) to the output pin B? Is there any way to achieve this?

[ovrebekk]

Hi

Yes, you should be able to set up a GPIOTE input channel on output pin A and connect that to a GPIOTE output channel on bin B over the PPI. 

If you configure both GPIOTE channels in TOGGLE mode you get away with only two GPIOTE channels, but you have to take care to avoid output pin B being inverted compared to pin A. 

An alternative approach is to use two GPIOTE input channels, in HITOLO and LOTOHI mode respectively, and connect them to the CLEAR and SET tasks of the GPIOTE output channel. This will remove the risk of inverting the output, but will require one more GPIOTE channel and one more PPI channel. 

Best regards
Torbjørn

[Timur Beganovic]

Thank you for the explanation, Still, it doesn't solve my problem. I already used 3 GPIOTE channels to control 3 pins. The GPIOTEs generate tasks based on timer events (PWM). In order to mirror these 3 pins to another 3 pins I will need 3 additional GPIOTE channels, right? That would be 6 GPIOTE channels altogether.

best regards

[ovrebekk]

Hi 

You are correct. The nRF51 doesn't allow you to control more than 4 pins through the GPIOTE. 

If the pins are supposed to be the same couldn't you just interconnect them externally on your PCB?

Best regards
Torbjørn

[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