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. 2. What should be the important task while porting for OSAL(Operating system abstraction layer) 3. 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!!! -Ramu
OS or RTOS Porting
Started by ●July 7, 2009
Reply by ●July 7, 20092009-07-07
On Jul 7, 10:21=A0am, "ramumadival" <ramu.madi...@gmail.com> wrote:> 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 b=ut> we wanted to completely replace to Nucleus RTOS on VIA chipset. > > Assumptions: =A0source 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 th=e> following concerns... > > 1. What are different types of porting? I think, people will say > parameter, API porting and all but I really didn=92t understand that...pl=s> explain me with an example.Have you bothered to look up what API stands for?> > 2. What should be the important task while porting for OSAL(Operating > system abstraction layer)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.)> > 3. 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 >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.> Thanks in advance, Plz help me!!! > > -RamuYou seem to have a big learning curve ahead of you. Good Luck! Ed
Reply by ●July 8, 20092009-07-08
>On Jul 7, 10:21=A0am, "ramumadival" <ramu.madi...@gmail.com> wrote: >> 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 RTOSb=>ut >> we wanted to completely replace to Nucleus RTOS on VIA chipset. >> >> Assumptions: =A0source 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 forth=>e >> following concerns... >> >> 1. What are different types of porting? I think, people will say >> parameter, API porting and all but I really didn=92t understandthat...pl=>s >> explain me with an example. > >Have you bothered to look up what API stands for? >Ramu: Yes! > >> >> 2. What should be the important task while porting for OSAL(Operating >> system abstraction layer) > >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.) > >> >> 3. EX: REX OS API takes input as 5 parameter but Nucleus OS takes only3>> or more than 5 parameter, so how to implement this case >> >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. >Ok. But systems API's can not changed I guess. my doubt is...Ex: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.>> Thanks in advance, Plz help me!!! >> >> -Ramu > >You seem to have a big learning curve ahead of you. >Good Luck! > Ed >Thanks for the consern...Pls let me know the REX RTOS's related documents or links...I could not able to google it. pls send me ...
Reply by ●July 8, 20092009-07-08
In message <vaqdnU8BAI7pqsnXnZ2dnUVZ_jCdnZ2d@giganews.com>, ramumadival <ramu.madival@gmail.com> writes>Pls let me know the REX RTOS's related documents or links...I could not >able to google it. pls send me ...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 /\/\/\/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Reply by ●July 8, 20092009-07-08
>In message <vaqdnU8BAI7pqsnXnZ2dnUVZ_jCdnZ2d@giganews.com>, ramumadival ><ramu.madival@gmail.com> writes >>Pls let me know the REX RTOS's related documents or links...I could not >>able to google it. pls send me ... > >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 /\/\/\/\/ >\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ > >Thanks for the concern... >Yes! you are right!! but project is under approval from end customer andit 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 by ●July 8, 20092009-07-08
On Jul 8, 5:40=A0am, "ramumadival" <ramu.madi...@gmail.com> wrote:> >In message <vaqdnU8BAI7pqsnXnZ2dnUVZ_jCdn...@giganews.com>, ramumadival > ><ramu.madi...@gmail.com> writes > >>Pls let me know the REX RTOS's related documents or links...I could not > >>able to google it. pls send me ... > > >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 =A0Staffs =A0England =A0 =A0 /\/\/\/\/ > >\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ > > >Thanks for the concern... > >Yes! you are right!! but project is under approval from end customer and > > 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. > > > > - Hide quoted text - > > - Show quoted text -- Hide quoted text - > > - Show quoted text -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 by ●July 12, 20092009-07-12
On Jul 8, 8:20=A0am, scott <swengineer...@gmail.com> wrote:> > 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*)try this one first: http://opensource.gsfc.nasa.gov/projects/osal/osal.php
Reply by ●August 17, 20092009-08-17
>On Jul 8, 8:20=A0am, scott <swengineer...@gmail.com> wrote: > >> >> 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*) > > try this one first: > >http://opensource.gsfc.nasa.gov/projects/osal/osal.php > > >Ah the beauty of POSIX.
Reply by ●August 18, 20092009-08-18
On Aug 17, 8:28=A0pm, "JeffR" <jeffreyram...@e2atechnology.com> wrote:> >On Jul 8, 8:20=3DA0am, scott <swengineer...@gmail.com> wrote: > > >> 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*) > > > =A0try =A0this one first: > > >http://opensource.gsfc.nasa.gov/projects/osal/osal.php > > Ah the beauty of POSIX.- Hide quoted text - > > - Show quoted text -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 by ●August 22, 20092009-08-22
>On Aug 17, 8:28=A0pm, "JeffR" <jeffreyram...@e2atechnology.com> wrote: >> >On Jul 8, 8:20=3DA0am, scott <swengineer...@gmail.com> wrote: >> >> >> For example I may always want to have a semaphore abstraction that >> >> allows for the following operations. Keep in mind I did not putmuch>> >> thought into these interfaces, you will have to do that. Your >> >> application would use these and the API documentation would definethe>> >> expected behavior of each and for each RTOS ou just have to writethe>> >> back end code to implement the advertised functionality. If youthink>> >> about this abstraction layer up front this tends to work out well. >> >> >> sem* semCreate() >> >> semGet(sem*) >> >> semGive(sem*) >> >> semDestroy(sem*) >> >> > =A0try =A0this one first: >> >> >http://opensource.gsfc.nasa.gov/projects/osal/osal.php >> >> Ah the beauty of POSIX.- Hide quoted text - >> >> - Show quoted text - > >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. >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.
