OS or RTOS Porting

ut

ICE

e s

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

b=

open =

th=

that...pl=

3

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

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     /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

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.

>

on

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.

try this one first:

Ah the beauty of POSIX.

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.

much

the

the

think

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.

um

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.