FreeRTOS 8.0.0 RC2

Kernel
1

thomask wrote on Monday, January 06, 2014:

Hi!

Just two quick comments on 8.0.0rc2:

  1. It would be nice if the “backward compatibility” defines in FreeRTOS.h would have an “#ifndef configNO_BACKWARD_COMPATIBILITY” block. This would make it easier to spot old code.

  2. I’m using Tracealyzer 2.5.1 and noticed that
    ucQueueGetQueueNumber was changed to uxQueueGetQueueNumber
    Queue_t.ucQueueNumber was changed to uxQueueNumber.

I assume this will only get me into trouble if I’m using >255 queues, right?

best regards,
Thomas

2

rtel wrote on Monday, January 06, 2014:

Thanks for your feedback. My comments below.

  1. It would be nice if the “backward compatibility” defines in FreeRTOS.h would have an
    “#ifndef configNO_BACKWARD_COMPATIBILITY” block. This would make it easier to spot old
    code.


Like this? (I prefer the 'enable' rather than 'disable' otherwise its negative negative): 


/* Definitions to allow backward compatibility with FreeRTOS versions 
prior to V8 if desired. */
#ifndef configENABLE_BACKWARD_COMPATIBILITY
	#define configENABLE_BACKWARD_COMPATIBILITY 1
#endif

#if configENABLE_BACKWARD_COMPATIBILITY == 1
	#define eTaskStateGet eTaskGetState
	#define portTickType TickType_t
	#define xTaskHandle TaskHandle_t
	#define xQueueHandle QueueHandle_t
	#define xSemaphoreHandle SemaphoreHandle_t
	#define xQueueSetHandle QueueSetHandle_t
	#define xQueueSetMemberHandle QueueSetMemberHandle_t
	#define xTimeOutType TimeOut_t
	#define xMemoryRegion MemoryRegion_t
	#define xTaskParameters TaskParameters_t
	#define xTaskStatusType	TaskStatus_t
	#define xTimerHandle TimerHandle_t
	#define xCoRoutineHandle CoRoutineHandle_t
	#define pdTASK_HOOK_CODE TaskHookFunction_t
	#define portTICK_RATE_MS portTICK_PERIOD_MS

	/* Backward compatibility within the scheduler code only - these 
        definitions are not really required but are included for 
        completeness. */
	#define tmrTIMER_CALLBACK TimerCallbackFunction_t
	#define pdTASK_CODE TaskFunction_t
	#define xListItem ListItem_t
	#define xList List_t
#endif /* configENABLE_BACKWARD_COMPATIBILITY */


  1. I’m using Tracealyzer 2.5.1 and noticed that


Yes, the data type is changing to allow more objects. As mentioned on the 'upgrading to V8' page, the trace recorder code will be updated in the final release so everything uses the same data type, in the release candidate you currently get a type mismatch as it still contains the old recorder code, which is 8 bits for that variable.

[Quoting text and including code in this forum is really hard! It has taken me several edits just to get it this good]

Regards.

3

thomask wrote on Monday, January 06, 2014:

seems fine!

4

dragonflight1 wrote on Monday, January 06, 2014:

I’m glad I’m not the only one that thinks it sucks!
(the formatting that is)

5

thomask wrote on Tuesday, January 21, 2014:

I just saw that FreeRTOS includes xSemaphoreCreateBinary to replace the old vSemaphoreCreateBinary function.

Maybe the old function should also be disabled by configENABLE_BACKWARD_COMPATIBILITY. It was already deprecated in 7.6.0, and should therefore be disabled in 8.0.0 (IMHO).

And what about vTaskList, vTaskGetRunTimeStats?

best regards!

6

rtel wrote on Tuesday, January 21, 2014:

vSemaphoreCreateBinary() does not add any code because it is a macro, so I think it can stay to ensure the easiest possible upgrade for end users. However its actual use within demo code will be removed by replacing all calls with the function version.

Regards.

7

thomask wrote on Tuesday, January 21, 2014:

I would drop the old function anyways, because they differ in semantics (taken vs. not taken after initialization, parameters) but have a very similar name. v vs. x can be overlooked easily, and may be a great source of typo-bugs!