On Aug 22, 11:23=A0am, "JeffR" <jeffreyram...@e2atechnology.com> wrote:
> >On Aug 17, 8:28=3DA0pm, "JeffR" <jeffreyram...@e2atechnology.com> wrote:
> >> >On Jul 8, 8:20=3D3DA0am, 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*)
>
> >> > =3DA0try =3DA0this 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? =A0Do you know how many kernels support at minim=
um
> POSIX.1? =A0Even 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. =A0- Hide quoted text -
>
> - Show quoted text -

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.

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

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.  

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.

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

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

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.

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

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

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

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!!!
>
> -Ramu

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