Moving from eCOS

[Joel Sherrill]

On Mon, Apr 2, 2018 at 1:30 PM, Aaron Bufkin <bufkin at marvell.com> wrote:

>
>
> Hi, I currently use eCOS, which has zero project activity and support. I
> am trying to find a suitable replacement. But I need some information
> before I get onboard with RTEMS.
>

OK. Hopefully others and I can help.


>
>
> From everything that I have read about RTEMS, it has support for SMP and
> POSIX but it does not support Aarch64.  Is this true?
>

The quick answer is yes. More detail.

RTEMS SMP supports ARM (tested to 4 cores), SPARC (tested to four cores),
and
PowerPC (tested to 24 cores). There are a lot of features in the SMP to
help build
applications that are designed to be analyzable and avoid resource
contention.
There is support for GCC's OpenMP out of the box.

The POSIX support is quite complete with over 1000 POSIX methods. We track
compliance against the POSIX standard and other standards like FACE and SCA
that profile POSIX for specific domains. The POSIX is complete enough where
it is usually straightforward to port over libraries you want. See
https://docs.rtems.org/branches/master/posix-compliance/index.html. If there
are specific methods you have questions about, just ask.

We do not have an aarch64 port yet. So far, using the 32-bit arm port on
the 64-bit aarch64 targets has met user needs. I suspect this is because the
main advantages would be 64-bit address space and faster 64-bit native
integer type
which are not a common need in applications needing single address space
OSes.
That said, we do want the port and have laid groundwork by having already
added aarch64-rtems to the GNU tools. You can build those now with the RSB.

There is a community of folks who provide services for RTEMS and any one
of us would be happy to help on a new port.


>
>
> How does the C runtime size of RTEMS compare to eCOS? Or FreeRTOS?
>

I don't have any hard numbers on this one. I will provide some background
and let users with direct experience comment.

Everything in RTEMS is library based and we use per-function and per-data
item linking. So you shouldn't see any dead methods. The C runtime of
RTEMS is newlib which is also used by Cygwin.

One point is that we focus on correctness and conformance. I recall long ago
being asked why RTEMS POSIX mutexes were slower than some other open
source OS. I looked at their implementation and immediately saw that they
didn't implement any attributes. When you don't implement everything, you
tend to be smaller and faster.

This is not to say we don't focus on size. In fact, one of the things I
think is neat is the recent and IMO very cool feature where something
like constructors are used to initialize RTEMS itself. If an OS feature is
not
used, then its initialization is automatically left out by the linker.

Between the per-function linking and the initialization technique we now
use,
if you find methods in your executable that surprise you, please report it.
We
haven't had any reported in a long time.

Someone with direct experience should comment.


>
>
> How configurable is RTEMS?
>

Aside from being library based with per-function linking, there are build
time
configuration and application link time configuration items.

+ build time - disable large features (e.g. SMP vs uniprocessor)
+ application configuration time - unlimited objects vs hard limits,
   filesystems (none or a set), static device drivers, etc.

My recommendation would be to build for some simulator ARM BSP and try
things. If you have questions, ask. I am sure the RTEMS Community will
be happy to help.

--joel



>
>
> Regards,
>
> Aaron
>
> _______________________________________________
> users mailing list
> users at rtems.org
> http://lists.rtems.org/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20180402/0ba0bf3d/attachment-0002.html>