Task Notifications related doubts

Kernel
1

Hi there,
In this example I am initializing 10 value into pulNotificationValue, when I am using eIncrement as eAction, Here pulNotificationValue should increment from 10 onwards right?
but it is always start incrementing from 0 onwards, Can you provide me any solution on this?
I am attaching the code below for your reference.

void task1_fun(void* pt)
{
	//TickType_t lastWakeUpTime;
	uint32_t pulNotificationValue = 10; //?
	//lastWakeUpTime = xTaskGetTickCount();
	while(1)
	{
		//vTaskDelayUntil(&lastWakeUpTime,pdMS_TO_TICKS(500));
		 if( pdTRUE == xTaskNotifyWait( 0,0,&pulNotificationValue,portMAX_DELAY ) )
		 {
			 HAL_GPIO_TogglePin(GPIOG,GREEN_Pin);
		 }
		 else
		 {
			 while(0);
		 }
	}
}
void task2_fun(void* pt)
{
	while(1)
	{
		HAL_GPIO_TogglePin(GPIOG,LD4_Pin);
		vTaskDelay(pdMS_TO_TICKS(500));
	}
}

void initPA0_as_input(void)
{
	//Micro Controller specific initialization
	//SYSCFG->EXTICR[0] = 0; //pa0 input to exti0
	//EXTI->RTSR = 1;//rising edge trigger
	//EXTI->FTSR = 0;
	EXTI->IMR = 1;//enable exti0 interrupt

	//Processor specific initialization
	NVIC_SetPriority(EXTI0_IRQn,5);
	NVIC_EnableIRQ(EXTI0_IRQn);
	//NVIC_SetPendingIRQ(EXTI0_IRQn);
}

void EXTI0_IRQHandler(void)
{
	EXTI->PR = 1;
//	vTaskNotifyGiveFromISR( tas1Handle,NULL );
	xTaskNotifyFromISR( tas1Handle, 0, eIncrement, NULL );
}
2

No. In this case, *pulNotificationValue receives the task’s notification value, after waiting for a notification event if necessary. The entry value of *pulNotificationValue is irrelevant.

What larger problem are you wanting to solve? We can make some recommendations for how task notifications can help.

1 Like
3

I am having multiple GPIO interrupts (6 inputs), these are user buttons,
I need to maintain system state machine according to the user input. For the user button differences I am using different bits of pulNotificationValue. It would be helpful if you suggest anything on this.

4

This will work. Each bit in the notificationValue could represent a button. When an ISR sets a bit (using eSetBits), that means there is an event for the button task to process. The button task could maintain state to determine when and how to debounce, when and how to identify debounced “button down” and “button up” events, etc. The task code would use xTaskNotifyWait() to clear all the notification bits, and it would use *pulNotificationValue to determine which buttons have events to process. It would process all of those events before calling xTaskNotifyWait() again.

5

Hi @jefftenney I have few questions.

  1. If multiple multiple ISRs are notifying the task, In this situation is there any chance it could miss any user input like what if two inputs pressed at same time?
  2. Once I processed the notification I need to clear only the processed notification bit from the pulNotificationValue how Can I do that?
  3. Will it capable of solving debouncing time?
6

See the use case of

as light weight event group.
Task notifications used this way (and using correct interrupt priorities) support getting signaled from multiple ISRs.
As @jefftenney explained you should fetch (and auto-clear) the complete notification value resp. bitmap and process all set bits by simply parsing them checking each bit and take the appropriate action. You could reserve 2 bits per button to signal button down/up events from the ISRs.
As part of the button handler task state machine you could use

to build a debouncing timer per button of e.g. 100 - 150 ms.
Invoking ulTaskNotifyTake with a certain reasonable timeout of e.g. 50 ms allows to poll-check the current button state (the logical state machine state and the physical state up or down) and their associated debounce timeouts.

1 Like