FreeRTOS config required flags not correctly treated

Hi,
many FreeRTOS config flags are required to be set to 1, but there isn't any check to throw errors when there aren't. some of these the flags are:

configUSE_MUTEXES
configUSE_RECURSIVE_MUTEXES
configUSE_TIMERS
configSUPPORT_STATIC_ALLOCATION

is it possible to add checks in the cmsis_os.h to throw "human friendly" errors when a required flag is not correctly set?

regards
Haithem.

Hi Haithem,

adding configuration checks sounds reasonable to me, we will look into that!

thanks!

what about adding the same checks in the cmsis_os2.c too? for example:

const char *osTimerGetName (osTimerId_t timer_id) {
#if (configUSE_TIMERS == 1)
  TimerHandle_t hTimer = (TimerHandle_t)timer_id;
  const char *p;

  if (IS_IRQ() || (hTimer == NULL)) {
    p = NULL;
  } else {
    p = pcTimerGetName (hTimer);
  }

  return (p);
#else
return NULL;
#endif
}

It is also an interesting proposal and we need to see the implications first. It is fine to exclude certain API or functionality if it is not used and thus reduce overall image size by excluding code from RTOS kernel.
If proposed exclusions can be made consistently then I don't see obstacles for adding them.

I see the same point in threads, for example. I found this when migrating from OS1 to OS2 ports.

For example, if static allocation is disabled, return error if no pointer to thread memory used.

CMSIS-FreeRTOS/CMSIS/RTOS2/FreeRTOS/Source/cmsis_os2.c

Line 460 in b4ccdfe

    
           hTask = xTaskCreateStatic ((TaskFunction_t)func, name, stack, argument, prio, (StackType_t  *)attr->stack_mem,

Hi,

Any updates regarding this request?

regards
Haithem.

Hi Haithem,
this request was partially address by 03eba7d where freertos_os2.h was added that contains some (but not all) configuration checks.

In the next step we need to address handing of defines (inside cmsis_os2.c):

configSUPPORT_STATIC_ALLOCATION
configSUPPORT_DYNAMIC_ALLOCATION
configUSE_MUTEXES
configUSE_RECURSIVE_MUTEXES

These options will be configurable and will not cause compile/link issues.

Unfortunately some defines like configUSE_TIMERS cannot be handled nicely because they effect other functionality - e.g. configUSE_TIMERS also effects EventGroups API and this obviously calls for some kind of compromise.

I will commit updated cmsis_os2.c within next days and add a reference to this case.

Hi Haithem,

please see the proposed solution. Configuration handling is divided to two types, defines that affect internal behavior (like support for static and dynamic allocation, recursive mutexes) and defines that exclude certain APIs (like mutexes, timers and task notifications).

Where possible, using certain define in FreeRTOSConfig.h is handled directly. For example, straightforward configuration is :

configSUPPORT_STATIC_ALLOCATION (static allocation of memory resources is not possible)
configSUPPORT_DYNAMIC_ALLOCATION (dynamic allocation of memory resources is not possible)
configUSE_MUTEXES (API for mutexes is excluded from code completely)
configUSE_RECURSIVE_MUTEXES (excluded handling for recursive mutexes)
configUSE_TIMERS (API for timer is excluded from code completely)
configUSE_TASK_NOTIFICATIONS (API for thread flags is excluded from code completely)

Where definition affects multiple APIs, its functionalities or is hard for compiler to optimize the code we have to make a compromise. By default, configuration check will throw a build error, but if developer knows what he is doing (description is provided in comments), there is an optional definition that overrides that build error and excludes certain functionality from the application code.

One example of this is the use of #define configUSE_TRACE_FACILITY 0 which prevents the implementation of RTOS2 function osThreadEnumerate. On first step, build error is thrown, which can be overridden by using #define configUSE_OS2_THREAD_ENUMERATE 0 that effectively excludes osThreadEnumerate from application code.

In most cases we can rely on compiler/linker optimization. For functions where tool chain optimization can do its work in a clean way, configuration check will only throw out error which will be gone when definition value is corrected. Tool chain optimization is then expected to be performed.

Vladimir

Hi Vladimir,

looks good to me, except the last point about the "Compiler/Linker optimization", as the MDK-ARM is often complaining about missing symbols even though they are not used.

regards
Haithem.

If there are any specific issues, just write them down, either here if relates to configuration check or open new issue.

Applications based on CMSIS-FreeRTOS should build flawlessly on all supported tools (Arm, GNU, IAR) regardless of used IDE. So, if there are obvious problems then they most likely relate to source code structure which is quite complex in certain cases and it would be good to solve them as soon as possible.

If you are happy with the proposed solution, please close this issue,
Vladimir