Real Time Linux

Status
Not open for further replies.
X

Xenoamor

Well-known member
Hey guys, this maybe well out of the scope of this forum but I figured I'll ask it anyway.

I'm looking to output data, around 28 bits, from Linux in realtime. It is important the timing is accurate down to ~2MHz (500ns).
Does anyone have any solutions on how to do this, be it an external peripheral or a specific board

I've tried desperately to get the Raspberry Pi 3 to do it but there's very large jitter. I'm running a custom Preempt Rt Kernal with dedicated cores and CPU clock cycle counting. Still no such luck!

Now the Beaglebone Black enchanced has 2 real time processors in it which would do the job but they don't have enough GPIO pins mapped out to be used. I've been looking around and Ti do something called OMAP (Open Multimedia Applications Platform). Now these look good because they have a main A9 core with two Mx cores for the realtime stuff. Although I can't seem to find a board with enough GPIO routed to it

Any ideas on a solution would be greatly appreciated
 
Last edited:
You might take a look at QNX. This is a microkernal OS that has been used on factory floors for a long time. Many car Infotainment systems are built on this OS. Blackberry 10 also has QNX at the core.

I am aware of it, have seen it on the factory floor in PC class machines, and just saw an reference that claims 0.55 us response for a Pentium III. http://www.operating-system.org/betriebssystem/_english/bs-qnx.htm I have never used it however.

There seem to be some open source options as well as embedded options. http://www.qnx.com/legal/licensing/open_source.html

And there seems to be a raspberry PI version. http://community.qnx.com/sf/sfmain/...n.community.topc25902/post112752?id=atch15473

Let us know what you find.
 
It's going to be challenging on a general purpose CPU using DRAM. E.g. memory latency for ARM Cortex A9:
https://github.com/ucb-bar/ccbench/wiki/Kayla-(1.4-GHz-ARM-Cortex-A9)
4 cache misses and you are over your 500ns.

Where is your data coming from? Do you need to stay within the 500ns for latency or for output jitter?

Xenoamor said:
Now the Beaglebone Black enchanced has 2 real time processors in it which would do the job but they don't have enough GPIO pins mapped out to be used.
Click to expand...
The sad thing is, the PRU could do 32 bits. Have you considered using shift registers (that should be fast enough)?
 
> I'm looking to output data, around 28 bits, from Linux in realtime. It is important the timing is accurate down to ~2MHz (500ns).

Tell us more about this. Is this a bit stream that just needs accurate bit-to-bit time, 500 ns response to some event, etc.

In general, I'd use dedicated hardware peripherals if you possibly can and dedicated MCUs + SW only if that isn't possible. Use a serial link to Linux if you need some higher level functions.
 
If ever there was a project that screamed for an FPGA, this is it. A Xilinx Spartan-3 or Spartan-6 would easily do this.
 
pictographer said:
If ever there was a project that screamed for an FPGA, this is it. A Xilinx Spartan-3 or Spartan-6 would easily do this.
Click to expand...
Ditto! FPGA's are programmable hardware, massively parallel. Typical clock speeds (within a region) in the single-digit nanoseconds! Perfect!
 
jerwood said:
Maybe a job for an FPGA hat on your Pi, or look at the Parallela: https://www.parallella.org/board/
Click to expand...

Lots to choose from! If Linux is a requirement, I'd consider running Linux on a soft Microblaze processor within the FPGA and not bother with the Raspberry Pi or if a faster Linux processor is needed, I'd consider a Microzed with a Zynq device that combines dual A9s and FPGA programmable logic. The I/O could be broken out with a prototyping carrier card or a custom carrier card. The Parallela board uses a Zynq to manage the parallel CPUs. If something really small is needed, there are some amazing System on a Module boards.

Speaking of requirements, what are the requirements? ;-)
 
Okay so to give a bit more context to the situation what we have is 32x32 LED panels with K20s on them. They all share a 24bit bus with 2 control lines
What the Raspberry Pi currently does is resize a video, cut it up into panel size segments, rotates them as needed and transmits them with an address header onto the bus. Now this is clearly screaming realtime video processing but we have a small software team here (just me) and a relatively short time to get a resonable prototype running. We're aiming for 50 panels to start with which is a clock speed of 1.6MHz, 4.6MB/s. Now the Raspberry Pi can do the video processing (although it's proprietary GPU doesn't help) but it won't do the datarate.

Jake said:
You might take a look at QNX. This is a microkernal OS that has been used on factory floors for a long time. Many car Infotainment systems are built on this OS. Blackberry 10 also has QNX at the core
Click to expand...
I'll certainly be having a look at it. I'm currently compiling a Xenomai kernal so we'll see if this is the right direction soon. Although I must admit I'm certainly no Kernal wizard!


tni said:
Where is your data coming from? Do you need to stay within the 500ns for latency or for output jitter?
The sad thing is, the PRU could do 32 bits. Have you considered using shift registers (that should be fast enough)?
Click to expand...
The shared memory space of the PRU and Linux space would be perfect. 500ns latency is not an issue, the jitter is the killer. A small external circuit made of cheap 74HCT components will almost certainly do it. I'll write a small assembler program for the PRU and check it meets the timing constraints. Hopefully there's some decent library support for the GPU in this thing


jonr said:
Tell us more about this. Is this a bit stream that just needs accurate bit-to-bit time, 500 ns response to some event, etc.
In general, I'd use dedicated hardware peripherals if you possibly can and dedicated MCUs + SW only if that isn't possible. Use a serial link to Linux if you need some higher level functions.
Click to expand...
The issue is when I use the GPIO mmapped in the Raspberry Pi about 1 in 500 times it takes too long to propagate to the pins and the data misses the clock pulse. I have used a serial link in the past with a Teensy but the datarate is really starting to push the upper limits. I'd have to make a custom board to facilitate the large 24bit bus but this isn't out of the question. The K20 120MHz range do sport a High-speed USB interface. A larger processor and a compressed video format may also be a good solution



Now on the topic of an FPGA this would certainly be the dream solution and one that would almost certainly be used for the end product. I've worked with a range of these including the Spartan chips and know that with careful design these could do exactly what I need. Both the Parallela and the Microzed are very interesting boards. The issue is the development time to get these of the ground. The more I can do in a Linux OS the easier the task in my opinion. I'll look into a Raspberry Pi fpga shield, although I fear the dataspeeds between the two maybe low


And can I just say many thanks for all the input, this project has had me making a lot of difficult design decisions and this forum has always helped. It's always refreshing to have a shared knowledge with members both new and old!
 
You've looked at SmartMatrix, right? Or maybe you're already using that or something similar at each 32x32 panel?
 
Last edited:
We have custom LED panels and 'control boards' so we don't have the standard HUB75 interconnect.
I have seen the SmartMatrix project though yes, although the LED panel drive side is complete. The 3x5 font it has maybe of use though
IMG_20160630_085611_1.jpg
 
Last edited:
You can run Ubuntu, Petalinux or Free RTOS, etc. on the Microzed. Considerable open source support. Not as bit a community as Raspberry Pi, but more geared towards professionals.
 
Status
Not open for further replies.
Back
Top