xTaskGetTickCount in tasks.c/h

Hello all I am using a at91sam7s arm7 chip, with IAR toolchain and 4.5.0 freeRTOS. I notice in definition of xTaskGetTickCount that the rturn of the count is surrouded by taskENTER_CRITICAL/taskEXIT_CRITICAL with the comment /* Critical section required if running on a 16 bit processor. */ Presumably since the ARM is 32 bits, I can replace this with a simple return xTickCount? Can I ‘automate’ this by using the #if (sizeof(portBASE_TYPE) >= 4) or is this likely to fail somewhere else? Hmm I find that IAR won’t accept sizeof as a preprocessor command! Keep looking! Many thanks in advance Mike Newsome Hitek Power Ltd, England

xTaskGetTickCount in tasks.c/h

If the definition of portTickType is the natural size of the processor word size (portTickType == portBASE_TYPE in effect), then the enter/exit critical is not required.  Removing the enter/exit critical also allows the function to be called from an ISR.  You could of coarse just set the tick count variable to be global, if you don’t mind doing that sort of thing. Regards.

xTaskGetTickCount in tasks.c/h

I prefer to keep other fingers out of this, by hiding it, but resent the time taked to post the critical flags if not necessary! Presumably the same applies to prvIsQueueEmpty, uxQueueMessagesWaiting and uxTaskGetNumberOfTasks, and also possibly prvIsQueueFull() as pxQueue->uxLength is set when the queue is set up, and cannot be dynamically changed. Many thanks for your time and help Mike

xTaskGetTickCount in tasks.c/h

Be careful with the queue functions.  prvIsQueueEmpty() and prvIsQueueFull() make a comparison, which is not atomic, so could require the critical section even though the comparison is with a constant – this depends on the code generated, it also depends on whether getting a result which for an instant is out of date really matters (which it probably doesn’t).  uxQueueMessagesWaiting(), uxTaskGetNumberOfTasks() should be ok. Regards.

xTaskGetTickCount in tasks.c/h

Hi Both prvIsQueueEmpty() and prvIsQueueFull() read the structure once then perform the compare on the values in registers and sort out the return value. So should be OK (until the compiler optimizer changes anyway!) Perhaps I’ll leave this one. Regards