Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 14 of 14

Thread: Real Time Linux

  1. #1
    Senior Member
    Join Date
    Nov 2015
    Location
    Wales
    Posts
    579

    Real Time Linux

    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 by Xenoamor; 06-28-2016 at 10:06 AM.

  2. #2
    Member
    Join Date
    Jul 2015
    Location
    Ontario, Canada
    Posts
    68
    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/betr...ish/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/d...2?id=atch15473

    Let us know what you find.

  3. #3
    Senior Member
    Join Date
    Jan 2013
    Posts
    843
    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/w...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?

    Quote Originally Posted by Xenoamor View Post
    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.
    The sad thing is, the PRU could do 32 bits. Have you considered using shift registers (that should be fast enough)?

  4. #4
    Senior Member
    Join Date
    May 2015
    Location
    USA
    Posts
    859
    > 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.

  5. #5
    Senior Member pictographer's Avatar
    Join Date
    May 2013
    Location
    San Jose, CA
    Posts
    701
    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.

  6. #6
    Junior Member
    Join Date
    May 2016
    Posts
    8
    Maybe a job for an FPGA hat on your Pi, or look at the Parallela: https://www.parallella.org/board/

  7. #7
    Quote Originally Posted by pictographer View Post
    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.
    Ditto! FPGA's are programmable hardware, massively parallel. Typical clock speeds (within a region) in the single-digit nanoseconds! Perfect!

  8. #8
    Senior Member pictographer's Avatar
    Join Date
    May 2013
    Location
    San Jose, CA
    Posts
    701
    Quote Originally Posted by jerwood View Post
    Maybe a job for an FPGA hat on your Pi, or look at the Parallela: https://www.parallella.org/board/
    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? ;-)

  9. #9
    Senior Member
    Join Date
    Nov 2015
    Location
    Wales
    Posts
    579
    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.

    Quote Originally Posted by Jake View Post
    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'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!


    Quote Originally Posted by tni View Post
    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)?
    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


    Quote Originally Posted by jonr View Post
    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.
    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!

  10. #10
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    24,094
    You've looked at SmartMatrix, right? Or maybe you're already using that or something similar at each 32x32 panel?
    Last edited by PaulStoffregen; 06-29-2016 at 12:40 PM.

  11. #11
    Senior Member
    Join Date
    Nov 2015
    Location
    Wales
    Posts
    579
    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
    Click image for larger version. 

Name:	IMG_20160630_085611_1.jpg 
Views:	110 
Size:	137.7 KB 
ID:	7502
    Last edited by Xenoamor; 06-30-2016 at 08:05 AM.

  12. #12
    Senior Member pictographer's Avatar
    Join Date
    May 2013
    Location
    San Jose, CA
    Posts
    701
    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.

  13. #13
    Senior Member pictographer's Avatar
    Join Date
    May 2013
    Location
    San Jose, CA
    Posts
    701
    One other thought. Can us use the Teensys to buffer just enough data to remove the jitter?

  14. #14
    Senior Member
    Join Date
    Jan 2013
    Location
    San Francisco Bay Area
    Posts
    645
    This list might be worth taking a look at:

    https://en.wikipedia.org/wiki/Compar...rating_systems

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •