0

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!

golo
  • 41
  • 7
  • The question is rather non specific and broad and likely to be closed. You should go ahead and ask specific questions about real issues you encounter. You will no-doubt only have uses a subset of the ThreadX API, so to give a general answer will be of little benefit to you. – Clifford Mar 27 '23 at 09:55
  • 2
    One way to solve this problem is to have used neither ThreadX or FreeRTOS API and implement an generic abstraction layer to which your application code is written. Too late for that now perhaps? CMSIS RTOS API is such an abstraction layer, albeit specific to ARM MCUs - although you could implement it on other architectures. – Clifford Mar 27 '23 at 09:56
  • Hey @Clifford, I did not find any convincing responses over google. Hence reaching out here. Porting types is what I found as: 1. different Os, same embedded device archi 2. same Os, different embedded device archi 3. different Os, different embedded device archi – golo Mar 27 '23 at 14:37
  • I understand that - and I did not vote to close it; it does not meet my very high threshold for killing a question. But if you were to follow the guidelines on SO questions you would see that this is not a good match. My point is that if you need to do teh port, you need to do the port, and you should ask questions about concrete issues rather then speculate on what problems you will encounter. The possible issues are legion, but largely depend on your platform, the extent and specific use use of the two APIs and your experience. – Clifford Mar 27 '23 at 16:32
  • 1
    In the absence of having the foresight to implement an abstraction in the first instance, you could implement a porting layer comprising the ThreadX APIs you are using using FreeRTOS so your application code need not change. That is use the ThreadX API as your abstraction layer. When your application does not work, you know you most likely have to fix the porting layer rather then the application, and it will be a matter of "fidelity" of the port - i.e. how closely it matches the semantics of ThreadX. – Clifford Mar 27 '23 at 16:36
  • https://stackoverflow.com/help/dont-ask this comes under "_an open-ended, hypothetical question_" IMO. – Clifford Mar 27 '23 at 16:40
  • @Clifford, I have one question for you. Like ThreadX is having TX module manager which is responsible for starting the module as well dispatching all module requests for ThreadX API services. Like wise what should be its equivalent in FreeRTOS? I am clueless in it though. – golo Apr 11 '23 at 06:54

1 Answers1

1

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".

Russ Schultz
  • 2,545
  • 20
  • 22
  • 1
    Re: FreeRTOS not having event flags, it does have: https://www.freertos.org/FreeRTOS-Event-Groups.html that are independent objects rather than part of the task, but you can achieve the same result (and an abstraction layer could hide those differences). I would say that just comes under the "semantic differences" you mentioned. – Clifford Mar 27 '23 at 16:25
  • @Russ Schultz , thank you for the approach mentioned. it really helped me. this might be an open ended question :) . But, IMO I feel most of the developers and researchers spend a lot of time in deriving the best approach possible. Now the tech is going fast, if we don't adopt a strategy then we will be like trying 99 times to light a bulb with no results and at the 100th trial, bulb is invented :) (just a saying) – golo Apr 03 '23 at 12:09