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 configNOBACKWARDCOMPATIBILITY” 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

Thanks for your feedback. My comments below.

1) It would be nice if the “backward compatibility” defines in FreeRTOS.h would have an “#ifndef configNOBACKWARDCOMPATIBILITY” 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 */

2) 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.

seems fine!

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

I just saw that FreeRTOS includes xSemaphoreCreateBinary to replace the old vSemaphoreCreateBinary function. Maybe the old function should also be disabled by configENABLEBACKWARDCOMPATIBILITY. 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!

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.

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!