I would like to know what things are being considered when you port a codebase from Threadx to FreeRtos on an embedded device provided that the embedded device architecture are different.
I am very novice to this porting activity in embedded devices.
Thank you for the suggestion in advance!
In general, an RTOS is an RTOS and most synchronization objects port pretty easily.
The problem lies when you use something other than mutex/recursive mutex/semaphore.
Events flags, for example, are a thing in ThreadX but don't exist in FreeRTOS. I think FreeRTOS has the idea of a task message/queue baked into the OS. ThreadX has all queues explicitly declared.
In addition, some semantics are different.
For example, FreeRTOS has separate API functions for calling from thread level vs. interrupt level. Its more explicit, but you can't easily write state agnostic code. (You can't move a user callback from thread time to IRQ time, for example, if the callback is used to poke a semaphore)
Also, FreeRTOS defaults to creating OS objects from a heap unless you specifically call the 'static' versions in which the application provides the memory for the object. ThreadX API assumes all memory is pre-allocated by the application and passed into the object creation APIs.
I think there's differences with what happens when a thread function exits. I know there's semantic differences with getting a thread to delete itself upon completion.
Really, you have to sit down and look at what you're using in the "source" and see how it maps to your destination.
I personally subscribe to the "write an generic abstraction layer and stay away from objects/types/patterns that are unique to one or the other RTOS".