Newbie question about RTEMS API

[Joel Sherrill]

gregory.menke at gsfc.nasa.gov wrote:
> 
> We've had good compliance from the POSIX api, which you might find
> more familiar than the RTEMS classic API.  Actually, we use both.  The
> Posix layer is not much more than a wrapper around the RTEMS classic
> functions.  Speed-wise there isn't much difference, as most all the
> POSIX calls don't involve a whole lot more than adapting POSIX
> parameters and values to those used in the RTEMS functions- which are
> somewhat "posixy" to begin with.

Technically all of the APIs are wrappers around the SuperCore.  Each
API wrapper promotes out its vision of semaphores, message queues, etc.
This is why there is virtually no performance difference between 
simialr services in the different APIs -- underneath it is the same
message queue, mutex, or semaphore operation.

Here is my take on the multiple API choice.  

Classic - Based on RTEID/ORKID which were close copies of pSOS+.  Since
  then it has been extended to include timers, rate monotonic periods,
  per task variables, priority ceiling, priority inheritance etc. 
Although
  not formally based upon any standards at this point, it provides 
  probably the richest set of "threading primitives" in the sense that
  almost every feature of the SuperCore is promoted out via the Classic
API.

POSIX - Very compatible with POSIX 1003.1b (full UNIX) with about 85%
  of the system calls supported.  If you want to port code, this is
  the API to use.  

uITRON - Still not complete and based upon v3.0 of the standard.  V4.0
  is out but I have not seen it in English yet (haven't looked recently
  either).  So I have trouble giving a recommendation to this one
  unless you are dealing with a Japanese consumer electronics device.

Mixed - Yes this works.  It has to work otherwise the TCP/IP stack
  and other infrastructure components would have problems.  So a POSIX 
  thread can make a BSD socket call that internally uses the Classic 
  API.  No big deal.  With GNU Ada, Ada tasks map to POSIX threads so
  the layering can get fun. :)

> We found the POSIX queue, semaphore, pthread and scheduling functions
> to be indistinguishable from the vxWorks versions with respect to
> overhead, so unless you're really pushing your board, I don't think
> theres much to worry about there.

And Greg has some benchmark results on this on their website.  They
were good and confirm everything anyone has ever seen with RTEMS.
Also RTEMS shares a great deal of code across all ports so the
performance
is very consistent.
 
> I've never messed with uitron, so I can't comment about that.  I
> suppose it could be argued the posix api might be more desirable
> because it makes your code more portable.  OTOH, additional amounts of
> RTEMS's coolness is available via the Classic API, so its definitely
> worth learning.

That is the very short version. :)
 
> Good luck,
> 
> Greg Menke
> 
>  > Hi all,
>  >
>  > I'm just getting started with RTEMS. After a couple head-scratching
>  > moments, I've got some simple hello world style programs up and
>  > running. I'm ready to get down to business, but I've got a quick
>  > question for you all.
>  >
>  > RTEMS has three APIs basically, the classic API, POSIX API and
>  > uITRON. I'm wondering which I should use. Here is the problem.... I
>  > don't have any legacy code or any code that will be ported over to
>  > my application. I'm using RTEMS to power a hobby robot. All I am
>  > interested in is ease of programming and the most speed I can drag
>  > out of it. I'm not overly familiar with any of the three APIs, so I
>  > don't have a preference.
>  >
>  > Are there any disadvantages to using any one particular API over
>  > the other? For instance, will using POSIX slow my system down a
>  > bit? Will using uITRON mean that I'll have to fight with the API
>  > changing from release to release?
>  >
>  > I guess I'm just looking for advantages/disadvantages of each when
>  > no legacy code is being thrown into the mix.
>  >
>  > Thanks!
>  > Aaron
>  >
>  >