On 4/7/12 10:08 AM, Javier Herrero wrote:
El 07/04/2012 16:02, Jim Lux escribió:
RTEMS wise... It's pretty well supported by the community, it's open
source, it does all the stuff you want a RTOS to do. it's NOT a
multitasking, dynamic loading OS like Linux. That is it doesn't
support an MMU and process space isolation (although that might be
possible in newer versions.. there's a lot of configurability). It's
basically a statically linked single task with threads. They've got
RAM (and disk) file systems, IP stacks, a shell, YAFFS, etc.
But there's also a core of users who are serious and rigorous and
contribute back, so the main stuff in the distribution from Joel
Sherrill at OAR (who make RTEMS) is pretty rock solid.
I will learn more about RTEMS. For the application I've (and this links
directly to the message from Javier Serrano), the hardware platform is
one of the CERN Open Hardware ones, the SPEC. For the purpose and
interface needs, really an operating system is not required (no
filesystem, no TCP/IP needed, no multitasking, no framebuffer...), and
certainly a Linux would have a very large footprint without providing
any real help.
RTEMS might be just what you need. Kernel, basic OS calls for
scheduling, queues, etc. It's nice when you decide you want threading to
not have to graft it into a "big loop no-OS" style program.
You can use native calls or POSIX style (I like POSIX, because I can
develop on Linux and just recompile for the RTEMS target).
There's all the usual GDB support as well.
And about the processor selection, the trade-off that
Javier exposes are the same I'm confronting. Both are open-sourced and
well supported, and in one side the LM32 is smaller, in the other the
LEON3 has more capabilities that can be implemented or not (like MMU or
FPU, and better multi-core support, although not currently needed in my
project). I probably will take the LEON3 road, but also because it is
more popular in my current field, but for now I usually do not need the
FT version since I'm more related with GSEs.
And that's good because the FT version costs money, but the regular old
LEON2 and LEON3 are free, and pretty bulletproof by now.
ESA has several rigorously verified flight qualified versions of RTEMS
(in Portugal and Austria, as I recall)
Yes, this is one of the reasons to gain experience in that road :) I
have some tendency to stay in Linux because I'm very familiarized with
it in the non-MMU implementations (for Blackfin) and also with MMU - and
I've found that for a small embedded system, to have the MMU is not so
important, even sometimes it is a drawback.
Device drivers are easy to write for RTEMS, and it has VERY fast ISRs.
That's probably one of the big advantages..
It's a small footprint, stripped down RTOS, but because you can work
with POSIX API calls, you can do most of your development in Linux
(particuarly things like calibration interfaces and computational stuff)
and then it ports very easily when you move it to RTEMS on the target.
_______________________________________________
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
