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
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.
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
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.
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.
Yes but what about latency?
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
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
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
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
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
This can be helped by using µCLinux instead of full Linux (disabling the MMU).
-Michael
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
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.
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
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
"Michael Schnell" skrev i meddelandet news:fm674b$2he$02$ snipped-for-privacy@news.t-online.com...
You could use a serial port configured in loopback mode to transfer in one direction. Need two serial ports to transfer in both directions.
-- 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
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
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
Nice feature....to bad we use Xilinx :D Is the NIOS set up for linux with MMU ?
-- MMJ
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.
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
MMJ,
Of all the options posted, which one did you end up using?
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.