FreeRTOS: Improvements #55

New Issue

muellerr · 2020-04-22T20:00:51+02:00

muellerr commented

2020-04-22 20:00:51 +02:00

Issue for several freeRTOS improvements:

Semaphore class for FreeRTOS.
Has been implemented. It would make sense to create a Semaphore factory, interface, and implement it for the other OSes as well. There are binary and counting semaphores, for now I implemented the binary semaphore. Tied to the new TaskManagement helper functions (see 3.)
ISR calls for Message Queue
Simple version implemented. Requires switchting contex manually.
Tied to new TaskManagement functions (3.).
Also implemented a new cast for the xQueueSendToBack: Uses a cast to QueueHandle_t instead of void* , new FreeRTOS functions don't use a void* cast anymore but a special Queuedefinition struct pointer cast. The QueueHandle_t cast should be compatible to older FreeRTOS versions as long as as the respective downwards compatibility configuration define in the freeRTOS config file is set to one
Task Management Helper functions.

FreeRTOS has different functions calls depending on whether a function is to be called from an ISR or a task.
When using interrupts, a context switch has to be requested in some cases, but the right function call has to be used.
THere is no reliable way in FreeRTOS to get the current task context (ISR or Task) for every architecture and some of those function calls are also architecture dependant, so a general way to get this context is to ask it from the developer. This is how ISIS does it.
For that reason, I implemented a TaskManagement function, which requests a context switch and calls different FreeRTOS functions depending on the call context supplied. However, maybe it would be better to declare this function external and define it in the bsp. The function call is located in "portmacro.h", which depends on the architecture used.
Also see here:
https://stackoverflow.com/questions/58631246/freertos-why-to-call-taskyield-from-isr-method-within-the-isrhandler

UPDATE: The pull request does it like that now: function call is external and has to be implemented by developer when starting new freeRTOS project. This generally involves looking for the function call in the partmacro.h file. This is small hassle but keeps the osal separated from the architecture.

The TaskManagement helpers also are wrappers to ensure abstracton of certain OSAL features:

Requesting a context switch: explicit named function which calls vTaskDelay(0)
Function to request stack high watermark and get TaskHandle.

Issue for several freeRTOS improvements: 1. Semaphore class for FreeRTOS. Has been implemented. It would make sense to create a Semaphore factory, interface, and implement it for the other OSes as well. There are binary and counting semaphores, for now I implemented the binary semaphore. Tied to the new TaskManagement helper functions (see 3.) 2. ISR calls for Message Queue Simple version implemented. Requires switchting contex manually. Tied to new TaskManagement functions (3.). Also implemented a new cast for the xQueueSendToBack: Uses a cast to QueueHandle_t instead of void* , new FreeRTOS functions don't use a void* cast anymore but a special Queuedefinition struct pointer cast. The QueueHandle_t cast should be compatible to older FreeRTOS versions as long as as the respective downwards compatibility configuration define in the freeRTOS config file is set to one 3. Task Management Helper functions. - FreeRTOS has different functions calls depending on whether a function is to be called from an ISR or a task. <br> - When using interrupts, a context switch has to be requested in some cases, but the right function call has to be used. THere is no reliable way in FreeRTOS to get the current task context (ISR or Task) for every architecture and some of those function calls are also architecture dependant, so a general way to get this context is to ask it from the developer. This is how ISIS does it. <br> - For that reason, I implemented a TaskManagement function, which requests a context switch and calls different FreeRTOS functions depending on the call context supplied. However, maybe it would be better to declare this function external and define it in the bsp. The function call is located in "portmacro.h", which depends on the architecture used. Also see here: https://stackoverflow.com/questions/58631246/freertos-why-to-call-taskyield-from-isr-method-within-the-isrhandler **UPDATE**: The pull request does it like that now: function call is external and has to be implemented by developer when starting new freeRTOS project. This generally involves looking for the function call in the partmacro.h file. This is small hassle but keeps the osal separated from the architecture. The TaskManagement helpers also are wrappers to ensure abstracton of certain OSAL features: - Requesting a context switch: explicit named function which calls vTaskDelay(0) - Function to request stack high watermark and get TaskHandle.

muellerr referenced a pull request that will close this issue

2020-04-22 20:01:20 +02:00

binary semaphore init #54

muellerr added the

help wanted

feature

labels 2020-04-23 14:28:29 +02:00

muellerr added the

API Change

label 2020-04-24 17:13:06 +02:00

muellerr referenced a pull request that will close this issue

2020-05-18 17:41:58 +02:00