Newbie question about RTEMS API

[gregory.menke at gsfc.nasa.gov]

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.

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.

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.

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