OS or RTOS Porting

Dear All,

I am going to work on RTOS porting (or even we call OSAL porting) from Qualcomm chipset to VIA chipset. Here Qualcomm chipset runs on REX RTOS but we wanted to completely replace to Nucleus RTOS on VIA chipset.

Assumptions: source code is in C, ARM7 processor, JTAG debugger, open ICE as IDE, Hardware is mobile phone

So, to do above...I am really requesting inputs with u all experts for the following concerns...

  1. What are different types of porting? I think, people will say parameter, API porting and all but I really didn?t understand that...pls explain me with an example.

  1. What should be the important task while porting for OSAL(Operating system abstraction layer)

  2. EX: REX OS API takes input as 5 parameter but Nucleus OS takes only 3 or more than 5 parameter, so how to implement this case

Thanks in advance, Plz help me!!!


Reply to
Loading thread data ...




Have you bothered to look up what API stands for?

different Operating Systems can have very different programming models. Extreme case is Preemptive compared to cooperative. There may be subtle differences in what looks like the same function. (e.g. a read from keyboard import in one OS might return EOF after a timeout when no key was pressed while another returns NUL and sets a status to indicate timeout.)

Change the code to match the programming model of the target OS. Again this goes well beyond the syntax of how many parameters are passed to OS routines. It includes the semantics of the operations.

You seem to have a big learning curve ahead of you. Good Luck! Ed

Reply to
Ed Prochak


open =




RES_tast_create(having 10 parametes) and in Nucleus_create_tast(taking only

5 parametes), so how can i handle rest of 5 parametes to achive the goal. i can not modify system API of nucleus. pls give me example and explain. if this not a case then pls ignore this doubt.

Pls let me know the REX RTOS's related documents or links...I could not able to google it. pls send me ...

Reply to

In message , ramumadival writes

If you are porting the REX RTOS you must have a license for it... therefore the documentation. If you have no documentation just ask the people who produce it.

\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
 Click to see the full signature
Reply to
Chris H

it may take 3 weeks to get it. By that time, we want to do some exersize on this, so I am rquesting u all if any.

Reply to


Are you saying that you are swiching the underlying RTOS from REX to Nucleus? If this is the case you are really talking about porting your application code to a new RTOS, correct? If this is the case you have a few choices. My approach would be to define an Abstraction Layer, i.e. think about what all the common functionalities are from one RTOS to the next that you are going to want to use in your application and define an interface that provides the functionalities you want. For each RTOS you will use you would need to implement these Abstraction Layer functionalities for that but as long as your application only uses these you would not have to modify the application.

For example I may always want to have a semaphore abstraction that allows for the following operations. Keep in mind I did not put much thought into these interfaces, you will have to do that. Your application would use these and the API documentation would define the expected behavior of each and for each RTOS ou just have to write the back end code to implement the advertised functionality. If you think about this abstraction layer up front this tends to work out well.

sem* semCreate() semGet(sem*) semGive(sem*) semDestroy(sem*)

As far as the documentation, good luck. Poor planning on your part does not constitute an emergency on my part. Next time plan a little better.

Reply to

try this one first:

formatting link

Reply to

Ah the beauty of POSIX.

Reply to

That assumes that whatever you port to or from implements the POSIX interface. Which of course brings up a lot of questions about what do you mean by implement POSIX. This can be problematic in my experience.

Reply to





Good luck finding an OS that supports an ARM7 derivative with an MMU

*enabled* that doesn't have POSIX.1c support, which includes Pthreads. What do I mean by POSIX? Do you know how many kernels support at minimum POSIX.1? Even Windows support POSIX.1c (this is the Pthreads version). One has way better luck at application portability if one writes to POSIX (threading, synchronization, queuing, signals, pipes etc) than some proprietary interface.
Reply to


That assumes that the POSIX implementation is correct and works as advertised. I have had problems in the past with a particular OS, which I was required to use, which claimed POSIX support. They certainly offered the required interfaces but when you enabled POSIX you would begin to see strange and hard to debug problems, mostly they had to do with timers. I am simply saying don't expect everything to work as advertised. We did end up abandoning POSIX and writing our own simple interface and all the problems went away and it really did not take much to do it. As far as luck with portabiliity, we had to port it and the effort was minimal. I am not saying POSIX can't be one solution for some but it is not the only way or even in some cases the best way to go.

Reply to

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.