[time-nuts] FPGA GPSDO (Was: Re: NTP jitter with Linux)

[Jim Lux]

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.