Embedded Linux Vs. Real time Linux - Embedded

This is a discussion on Embedded Linux Vs. Real time Linux - Embedded ; > What kind of hardware do you (intend to) have ? If you do this with an > FPGA, maybe the hardware can be done/changed appropriately. Anyway if > designing hardware that is to communicate with a processor, the > ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 38 of 38

Thread: Embedded Linux Vs. Real time Linux

  1. Re: Embedded Linux Vs. Real time Linux

    > What kind of hardware do you (intend to) have ? If you do this with an
    > FPGA, maybe the hardware can be done/changed appropriately. Anyway if
    > designing hardware that is to communicate with a processor, the
    > appropriate design rules should be followed.


    HW is beeing implmented first off in a FPGA and then moved to a structured
    ASIC later on! I think the buffers are rather small because of the memory
    amounts in the ASIC. But I'll for sure pass this on.

    --
    MMJ



  2. Re: Embedded Linux Vs. Real time Linux

    Michael Schnell wrote:
    > > But I guees the interrupt still will be
    > > pending when the interrupts are reenabled by the kernel ?

    >
    > Right.


    If you received multiple interrupts for a single IRQ during the time
    the interrupt was disabled this does not have to be true, it is
    possible that you only receive one of the interrupts.

    > > This causes a delay on the service time of the DMA and worst case is that
    > > the buffer overflows. Which parameter decides how long the kernel wil
    > > disable interrupts - CPU load? Is it posiible to make any estimation of this
    > > time?

    >
    > As Linux is not meant to be a realtime OS there are no specs on this.
    > But of course the time is rather short. But If you can live with that
    > delay I'm quite sure that doing a standard interrupt driven Linux device
    > driver will do the work, too.


    It depends on your definition of short. In some situations it can be
    100's of usec, or even msecs. If you need sub-msec responses this is
    not acceptable. For a general purpose OS this is pretty good.

    The PREEMPT-RT patch tries to get rid of the locks, and has been able
    to get a good RT version of Linux, but it is not available on all
    architectures. It is mainly developed for x86 platforms, but is
    available for some other platforms.

    Kind regards,
    Johan Borkhuis

  3. Re: Embedded Linux Vs. Real time Linux

    > I don't understand why you would need to do this.

    > You can however do whatever you like inside a Kernel device driver. At
    > least
    > on a single processor system it should still be possible to disable
    > Interrupts alltogether and running your code exclusively.


    Because we do have some hard real time demands (caused by our hardware
    arch - as it is now). We also would like to code our application code in a
    Linux enviroment. If we implment the service of the real time demanding
    hardware in a ISR compiled into the kernel space - we'll still suffer the
    latency that might cause buffer overflow in the hardware.

    >> - Some independant code outside the Linux enviroment to service the DMA
    >> ISR.

    >
    > Again, I don't see any reason why this code need to run outside the Linux
    > kernel enviroment.


    Having the the outside code meeting the real time demand of the hardware and
    the Linux to mange applications. But as I mentioned I seriously has my
    doubts to this soloution in terms of the communications between the to
    software entities.

    >> The DMA interrupt will happen without Linux knowing

    >
    > Again, I don't see a reason, why this should be necessary


    >> and Linux will be 100% interrupted and resceduled after ISR completion.

    >
    > This is possible to do with the standard Linux Kernel API.


    Yes but what about latency?

    >> - A Real Time Linux system having a real time extension in the kernel
    >> including a defined interface between the real time part and the kernel.

    >
    > Some Real Time Linux systems (e.g. RTAI) do it this way.
    >
    > An ordinary Linux Kernel with Realtime Preemption patches will however
    > provide ordinary Unix _Userland Applications_ with Realtime capabilities
    > (http://rt.wiki.kernel.org/).


    Yea this or the other patches mentioned might be the proper solution. What
    latencies might one expect when running a RT linux setup on e.g. a 75Mhz ARM
    platform?

    --
    MMJ



  4. Re: Embedded Linux Vs. Real time Linux

    Michael Schnell wrote:

    >> So what you are saying is that the Linux kernel WILL disable global
    >> interrupts from time to time.

    >
    > AFAIK, this is correct (maybe depending on the CPU architecture). You
    > need to inspect the Kernel sources to be sure.


    But this is the approach of the RT Preempt patch: To reduce the need of
    disabling the interrupt and replace this code by simple spin locks or
    mutexes. This means the word "preemption". Ensure every piece of code can
    be preempted if something with a higher priority is ready to work. So also
    the interrupt service routines are kernel threads now, and with a priority.

    On a DualCore-Pentium with RT Preempt we need more than 10000 hackbench jobs
    and a two ping floods to see latency violations on this box....

    JB

  5. Re: Embedded Linux Vs. Real time Linux

    MMJ wrote:
    > Yea this or the other patches mentioned might be the proper solution. What
    > latencies might one expect when running a RT linux setup on e.g. a 75Mhz
    > ARM platform?


    Hmmm, here are some numbers: PXA270 processor, running at 520MHz and RT
    Preempt Linux. About 19us...160us on a system with low load.
    With other load running this increases to 500us...750us. This is due to the
    fact ARM has its cache on the "wrong side" (=virtual addressbus), so task
    switching hurts your system (needs a cache flush every time).

    JB

  6. Re: Embedded Linux Vs. Real time Linux

    borkhuis@gmail.com wrote:
    > The PREEMPT-RT patch tries to get rid of the locks, and has been able
    > to get a good RT version of Linux, but it is not available on all
    > architectures. It is mainly developed for x86 platforms, but is
    > available for some other platforms.


    Is the PREEMPT-RT patch compatible with uCLinux? We're looking at using
    a Blackfin (no MMU) and we have hard realtime latency requirements (DMA
    completion interrupts) on the order of 1 to 10 mSec.

    Bob

  7. Re: Embedded Linux Vs. Real time Linux

    borkhuis@gmail.com wrote:
    > The PREEMPT-RT patch tries to get rid of the locks, and has been able
    > to get a good RT version of Linux, but it is not available on all
    > architectures. It is mainly developed for x86 platforms, but is
    > available for some other platforms.


    The main architectures are x86, powerpc (not ppc!!) and arm. As RT-Preempt
    fights against system management mode on x86 and other ugly broken x86
    hardware, its easier to use RT-Preempt on non x86 architectures.

    JB

  8. Re: Embedded Linux Vs. Real time Linux

    > This is due to the
    > fact ARM has its cache on the "wrong side" (=virtual addressbus), so task
    > switching hurts your system (needs a cache flush every time).


    This can be helped by using µCLinux instead of full Linux (disabling the
    MMU).

    -Michael

  9. Re: Embedded Linux Vs. Real time Linux

    > I think the buffers are rather small because of the memory
    > amounts in the ASIC. But I'll for sure pass this on.


    You mentioned DMA. If that is bus master DMA, no buffers in the hardware
    are needed, just two "channels" to do double buffering.

    If you want to use a DMA controller in the processor chip, maybe you can
    use two DMA channels that are activated alternating by the hardware. So
    the processor can program one of them while the other is running.

    With the project I'm up to start right now, I'll use a processor
    programmed in the FPGA, so the cost for the processor chip and PCB space
    etc can be used for the FPGA, which makes the solution very scalable.

    -Michael

  10. Re: Embedded Linux Vs. Real time Linux

    On Fri, 11 Jan 2008 22:35:22 +0100, Michael Schnell wrote:
    >> This is due to the
    >> fact ARM has its cache on the "wrong side" (=virtual addressbus), so task
    >> switching hurts your system (needs a cache flush every time).


    >This can be helped by using µCLinux instead of full Linux (disabling the
    >MMU).


    I can't ever imagine performance being worth running without memory
    management any any system more complex than a few thousand lines of code.
    Developing software where *any* process can overwrite the memory of any
    other process is just nasty. It gets real cute when a program had an error,
    but has exited, and the other clobbered program doesn't develop any problem
    until hours later.

  11. Re: Embedded Linux Vs. Real time Linux

    IMHO, this depends.

    For systems with user interaction I fully agree.

    For embedded systems that contain high security functions, Linux alone
    is not recommended anyway. Here a virtualizinfg system (like PikeOS)
    should be used that provides a simple (and thus reliable) system besides
    Linux that goes on working if Linux crashes. Thus memory protection in
    Linux does not help much (other than for debugging purpose).

    With a normal embedded system any part of the user software is as
    essential as the Kernel. If one of them crashes, the function of the
    embedded device is not provided any more Thus memory protection in Linux
    does not help much (other than for debugging purpose).

    -Michael


  12. Re: Embedded Linux Vs. Real time Linux

    BTW. The NIOS CPU (running in an Altera FPGA) comes with a "scatter" DMA
    unit. Same reads its commands from memory and thus can run
    uninterruptedly all the time, while the CPU just reads and writes the
    shared data and control memory.

    -Michael

  13. Re: Embedded Linux Vs. Real time Linux

    "Michael Schnell" skrev i meddelandet
    news:fm674b$2he$02$1@news.t-online.com...
    >
    >> But is the device driver not a part of the Linux envrioment with defined
    >> ways of communications and scheduling together with the Linux kernel?

    >
    > Of course. But that is more of a benefit than a restriction.
    >
    >> What I am talking about is some totally independant code that is able to
    >> interrupt all Linux processes and complete it's own task before
    >> re-enabling the Linux execution.

    >
    > The standard Linux Kernel will disable the interrupt now and then, so the
    > interrupt will not be recognized by the processor. If your hardware allows
    > multiple interrupt priorities, you could modify the Kernel to leave one
    > level enabled for your DMA system, but if you do so, there is no decent
    > possibility (other then a hardware FIFO or similar) to have your system
    > communicate with the Linux system (to pass the acquired data), as you
    > can't construct a non-spinning semaphore.


    You could use a serial port configured in loopback mode to transfer in one
    direction.
    Need two serial ports to transfer in both directions.

    > For any decently constructed hardware that creates or needs data bytes in
    > a speed that is slow enough for moving the stream via Ethernet, with a
    > decent processor a DMA enabled device driver should be by far appropriate
    > (otherwise the Ethernet driver would fail).
    >
    > If the hardware does not give the processor enough time to allow for some
    > decent latency between two consecutive DMA actions, the hardware is
    > erroneously constructed. It should contain some kind of FIFO, double
    > buffers or a similar construct. With that the processor can react on the
    > end of the previous DMA block while the next is running.
    >
    > -Michael





    --
    Best Regards,
    Ulf Samuelsson
    This is intended to be my personal opinion which may,
    or may not be shared by my employer Atmel Nordic AB




  14. Re: Embedded Linux Vs. Real time Linux



    Bob wrote:
    > borkhuis@gmail.com wrote:
    > > The PREEMPT-RT patch tries to get rid of the locks, and has been able
    > > to get a good RT version of Linux, but it is not available on all
    > > architectures. It is mainly developed for x86 platforms, but is
    > > available for some other platforms.

    >
    > Is the PREEMPT-RT patch compatible with uCLinux? We're looking at using
    > a Blackfin (no MMU) and we have hard realtime latency requirements (DMA
    > completion interrupts) on the order of 1 to 10 mSec.


    I don't know, I have no experience with Blackfin and/or uCLinux. You
    could try the related forum or mailing lists.

    Kind regards,
    Johan Borkhuis

  15. Re: Embedded Linux Vs. Real time Linux



    Michael Schnell wrote:
    > With a normal embedded system any part of the user software is as
    > essential as the Kernel. If one of them crashes, the function of the
    > embedded device is not provided any more Thus memory protection in Linux
    > does not help much (other than for debugging purpose).


    This is not related to memory protection: if your application crashes
    on whatever system, it cannot provide the required function anymore,
    unless you make your system fault tolerant, for example by restarting
    failing applications or rebooting your system (which, in a way, can
    also be seen as restarting your application.....).
    Memory protection does give your system some protection against
    applications going wild. At least you can have an application that can
    monitor all other applications, without the risk of being corrupted by
    another application.

    Kind regards,
    Johan Borkhuis

  16. Re: Embedded Linux Vs. Real time Linux

    > BTW. The NIOS CPU (running in an Altera FPGA) comes with a "scatter" DMA
    > unit. Same reads its commands from memory and thus can run uninterruptedly
    > all the time, while the CPU just reads and writes the shared data and
    > control memory.


    Nice feature....to bad we use Xilinx Is the NIOS set up for linux with
    MMU ?

    --
    MMJ



  17. Re: Embedded Linux Vs. Real time Linux

    >
    > Nice feature....to bad we use Xilinx


    I suppose the Xilinx Microblaze system provides very similar features to
    Altera NIOS. Moreover switching the brand is not too hard work until a
    PCB is done.

    > Is the NIOS set up for linux with
    > MMU ?
    >


    As of very recently NIOS does come with an MMU that can optionally
    enabled. Right now only MMU-less µCLinux exist for NIOS, but I'm very
    sure that full Linux will be available very soon (as already is with
    Xilinx Microblaze).

    -Michael

  18. Re: Embedded Linux Vs. Real time Linux

    MMJ,

    Of all the options posted, which one did you end up using?

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2