News:

LATEST RELEASE:  FPP 6.1 - Download from here - https://github.com/FalconChristmas/fpp/releases/tag/6.1

+-+-

+-User

Welcome, Guest.
Please login or register.
 
 
 
Forgot your password?

+-Site Stats

Members
Total Members: 15464
Latest: BroJam22
New This Month: 87
New This Week: 5
New Today: 5
Stats
Total Posts: 126798
Total Topics: 15538
Most Online Today: 107
Most Online Ever: 7634
(January 21, 2020, 02:14:03 AM)
Users Online
Members: 10
Guests: 69
Total: 79

Orange Pi's

Started by AAH, February 18, 2022, 03:48:02 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

AAH

Just wondering who has played around with getting FPP onto an Orange Pi and if so what version/s FPP, what variety of Orange Pi and was there any limits on using with pixel outputs, video output, audio output or anything else?
With Raspberry Pi's becoming next to impossible to source due to shortages due to covid I'm looking at something to use that is actually in stock and not expected in December 2022 like the Pi3B+ is.

dkulp

FPP should install on it fairly easily, but I'm not sure how useful it would be.   You wouldn't be able to drive any pixels from it directly.   We MAY be able to support using the SPI pins to drive some pixels, but those pins are different than the pwm pins so existing hat's wouldn't work.   The new DPI stuff wouldn't be usable as the Orange Pi doesn't have a mux for it on the pins.      Video would likely work, but be software decoded so likely limited in resolution.
Daniel Kulp - https://kulplights.com

k6ccc

Sounds like a candidate for a Master in a Master / Slave configuration - unless I'm missing something...
Using LOR (mostly SuperStar) for all sequencing - using FPP only to drive P5 and P10 panels.
My show website:  http://newburghlights.org

Jim

CaptainMurdoch

If you can run Debian 10 (Buster) on something, you have a good chance of FPP working via FPP_Install.sh as a Master or Remote with at least the ability to drive network based channel outputs.

I haven't used any of these recently, but over the years, I have run FPP on the following:

Orange Pi Zero
Pine64
ODROID-C1
NextThing C.H.I.P.
AtomicPi (x86 based)
PogoPlug (I ran FPP on this my first year after I decided to use my only Pi for Asterisk)

The problem I find with most of these is that they aren't supported anywhere near as well as the Pi and BeagleBone and they aren't as standard.  OS upgrades take longer to come out if they ever do, some hardware require vendor-specific patches or OS installs to get working, and some companies just fall by the way side like NextThing which went belly-up.  For kicks recently, I pulled out a C.H.I.P. and put Debian Jessie on it and then did an in-place upgrade to Buster, so it should be able to run FPP v5.x still, but with no direct pixel support and no wired Ethernet, it isn't of much use.  It does have a RGB666 DPI interface on the GPIO outputs, but I don't know if that would support the custom timing we'd need to drive pixels using the DPIPixels output.
-
Chris

djulien

Quote from: CaptainMurdoch on February 18, 2022, 03:17:44 PMIt does have a RGB666 DPI interface on the GPIO outputs, but I don't know if that would support the custom timing we'd need to drive pixels using the DPIPixels output.

The vga666 overlay is very similar to the dpi18 overlay.  They both control which pins are set for DPI, just some differences in which pins are used.  The timing is all handled by the GPU.

I read that the GPU chip is different, so the GPU firmware would also be different.  However, the processing load that DPI places on the RPi GPU is quite low (FPP only uses a 2.4MHz pixel clock for DPI), so the Orange Pi GPU firmware would need to be very inefficient in order not to be able to handle the timing.

CaptainMurdoch

Quote from: djulien on February 19, 2022, 08:44:09 PMI read that the GPU chip is different, so the GPU firmware would also be different.  However, the processing load that DPI places on the RPi GPU is quite low (FPP only uses a 2.4MHz pixel clock for DPI), so the Orange Pi GPU firmware would need to be very inefficient in order not to be able to handle the timing.

It's not really a question of whether it can handle the workload, it's a question of whether we can configure the proper WS281x timing on other SBC's DPI output.  Some don't have the configurability that the Pi's do or they may but documentation is lacking.  This is one of the reasons we have stuck with supporting just the Pi and BeagleBone, because of the level of community support and documentation other boards have.
-
Chris

Support FPP

+- Recent Topics

What is the second best way to get rid of pixel gap errors? by k6ccc
Today at 11:10:26 AM

1st attempt success by ctmal
Today at 10:13:02 AM

show locks me out of falcon player by breese
Today at 10:08:21 AM

MultiSync copying of Show Files not working in FPP 6.1.1 by dkulp
Today at 12:12:07 AM

running event date from within xlights sequence. by Poporacer
November 26, 2022, 11:26:24 PM

Wifi set up with no wired connection by Poporacer
November 26, 2022, 11:23:59 PM

p10 panel not working with xlight output by pennymoor
November 26, 2022, 11:07:29 PM

F16v3 Won't boot or power on by rjhodgefamily
November 26, 2022, 07:54:39 PM

Cannot Ping e1.31 Channel Data Target by mwolbert
November 26, 2022, 07:49:25 PM

Controller not keeping accurate time by JonD
November 26, 2022, 07:31:07 PM

Powered by EzPortal
Powered by SMFPacks Menu Editor Mod