On Mon, Apr 2, 2018 at 1:30 PM, Aaron Bufkin <[email protected]> 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 > [email protected] > http://lists.rtems.org/mailman/listinfo/users >
_______________________________________________ users mailing list [email protected] http://lists.rtems.org/mailman/listinfo/users
