Orange PI

[gioreva]

Hi, I want to use an OrangePI light With ARMbian-ubuntu I have compilation errors. With ARMbian-debioan, compile, but no GPIO moves If I put on raspbian light, the serial console does not even start.

Some advice ?

[hzeller]

The OrangePi is an entirely different computer, with an entirely different GPIO subystem and an entirely different GPIO mapping (don't believe their marketing that it is 'pin compatible'. It is of course not).

So you have to adapt the code to make GPIO running there. Please send a pull request when done so that other users of an OrangePi can use it.

[ukdepartureboards]

I also looked at a orange pi port as i would be interested to see how there all winner cpus perform! Be careful with there pwm pin though as its not in the same location!

[gioreva]

I do not have the ability to make this change. I bought an orange pi zero W, and 10 pcb drivers

[yawor]

I've started porting this library to NanoPi Neo, which uses Allwinnner (sunxi) H3 CPU. I think making new gpio.cc/gpio.h is all that's needed, but this requires some assumptions. The biggest difference between BCM and sunxi is that BCM has only one bank of GPIO pins and sunxi has the pins grouped into multiple ports (named from A to L). As the library focuses strongly on Raspberry Pi, the pin configuration and all the pin operations are based on uint32_t values which act as bit fields (one bit in the value denoted one pin). This is certainly not enough for sunxi, unless everything happens only on a single port. This highly depends on the board. For example the NanoPi Neo board exposes 14 pins from port A (not all of them are properly described in the documentation, but they are there) and pin A5 (normally UART0 RxT) can be used as a PWM0 output. This means that in my port I'm going to assume, that all the usable pins are on port A. There's also a problem with the GPIO performance. It's definitely slower than RPi. The biggest bottleneck is reading GPIO data registers: it takes 120 ns. Writing to the data register is faster, but still slower than on RPi (about 50 ns). Also there are no pin_set/pin_reset registers like in RPi. This means that when doing a standard "read, modify, write" (for example *PORTA_DAT |= (1 << 4);) operation takes a lot of time. A simple program, which only sets and resets a single GPIO pin is only able to achieve about 2.4 MHz square wave on the output. This can be fixed by not reading the register. By using a variable to cache previous port data value and only writing to the register, I've been able to achieve 12 MHz, but this means that it's not possible to use the port A for inputs at the same time, or for outputs outside of the library, as the ported GPIO class would overwrite all the port A pins all the time.

Anyway, I've been able to drive at least two chained 64x32 matrices (without the library yet) without PWM (so only 8 colors) but the refresh rate was quite good so I'm hopeful that after porting the library it'll work to some degree.

[mrcodetastic]

Hi @yawor, did you end up porting the library to the Allwinner H3? Or create a rought working prototype?

[mrcodetastic]

I created a very dirty port here: https://github.com/mrfaptastic/opi-allwinner-h3-rgb-led-matrix

[yawor]

Here's mine https://github.com/yawor/rpi-rgb-led-matrix Preconfigured for NanoPi Neo and NanoPi Neo Core (Neo2 and Core2 too). It works with H3 and H5 as there are no changes to the GPIO.

There's an issue with H3 (and H5) GPIO speed. Reading the registers takes few times longer than writing to them. I don't remember exactly now but it's something like 3 times longer. I'm also using port A, but my port doesn't read the value of the port, only write to it. I store the old port value in a variable. To change pin state, I update the variable and write it's value to the port register. The downside is that there can't be anything else using port A. NanoPi uses one pin from port A to control one of the LEDs. It's configured in device tree and controlled by the Linux kernel. So it's required to disable this LED either by changing the device tree or writing to specific sysfs and changing LED trigger from heartbeat to none. With oy writing to the port, I've been able to get about 12 MHz signal on the GPIO output. With reading and writing it drops to just 3 MHz. Also my port uses H3/H5 hardware timer for output enable pulses like the original one on RPi.

[mrcodetastic]

Hi @yawor. Great work with your port, much cleaner. Did you find the hardware timer improved the performance at all? I'm not sure there would be any benefit given there should be no change in overhead to manipulate 1 or 32 bits at once when bit-banging the GPIO PORTA register at once.

[yawor]

@mrfaptastic I don't think that the hardware timer has any influence on the performance. It's rather to make the colours more stable as the Output Enable is always active for the same amount of time specified for each bitplane - it's not affected by CPU usage.

[miklelv]

Hi, yawor. Is your library suitable for orange pi one with 40 pin gpio port with H3 CPU ?

[yawor]

@miklelv you'll probably need to do your own GPIO pin mapping. My mappings are based on what pins are available on Nano Pi Neo Core. What you need to take into account is that H3/H5 GPIO pins are grouped into ports. My implementation is able to work only with as single port. In case of Nano Pi Neo Core it's port A, as it had most pins exposed on headers and available for this use case. You'd need to check the Orange Pi documentation to check which ports and pins are exposed. Also take into account that I've had to make a decision not to read the port state back - it's always overwritten. This is because the read operation on GPIO registers on H3/H5 is 3 times longer than the write, which would make almost impossible to drive the RGB matrix with good results. This means you can't use the same GPIO port to drive something. You can use different port to do that if it's available. So if you'd like to use a different port than A, then you'd need to also change the code in GPIO::Init method in gpio_sunxi.cc. gpio_porta_base_ is the base address for the port A registers. I don't remember what the offsets for other ports are - you'd need to check H3/H5 datasheet (both CPUs use the same register addresses).

[miklelv]

I have this pinout

[miklelv]

Where should I connect RGB 1,2,a, b, c,d, store, oe, clock ? And what version of the operating system did you use on the Nano Pi Neo Core ?

[yawor]

I've used Armbian. From what I can see, you have a lot of pins available from port A (all the PA0, PA1 etc). But you NEED access to PA5 pin for OE, which I don't see on the above pinout. Only this pin can be configured to work as a hardware PWM. I've found on some forum, that PA5 is "serial boot connector middle pin", whatever that means (I don't have Orange Pi). This is the only pin that can't be changed. You can change other pins whatever you like, as long as they are all on port A. You can find pin mapping in lib/hardware-mapping.c. Pin numbers there correspond directly to port A pin numbers, so 0 means PA0, 1 means PA1 etc. I can't help you more than that. You'll need to figure out the rest for yourself.

[miklelv]

Thank you very much! PA05 was found on the debug connector, I will try it

.

[keep28]

Hi @mrfaptastic (and @hzeller) Thanks for an awesome effort, very nice! I just setup your code and compiled it on my allwinner H3 and it went through super smooth and worked great. I did notice it appears to be a branch from an earlier version of hzellers, code as the time delay switch -t isnt available in your port of demo code? Would it be hard to update the source to the latest zheller version?

[mrcodetastic]

Thanks for the kind words. Unfortunately I no longer have any Orange Pi devices and do not remember what to change anymore without breaking the code entirely.

[keep28]

@mrfaptastic Ah, Cool. Ok. no worries. Ill take a shot at it myself and see what I can do. Thanks for the response. Cheers. Steve

[keep28]

Hi @yawor Thanks for the smooth modern port to H3 of the led matrix code. Ive compiled and executed on my H3 and its gone through with no problems and all seems to work ok, except for no port A IO activity. I have installed libio and using gpioset gpiochip0 XX=0/1 I have tested all IO's and they are all working correctly. Would you know why the gpio isn't connecting through? Would you have an image available for download where it works ok for you that i could use to help debug. Any help or assistance would be very much appreciated. Thanks.

[miklelv]

Not found in project https://github.com/yawor/rpi-rgb-led-matrix were to define parameter RGB_LED_NANOPI_NEO ? Seems its no work. Any solutions ? were to define parameter RGB_LED_NANOPI_NEO or RGB_LED_NANOPI_NEOCORE ?

if defined(RGB_LED_NANOPI_NEO) || defined(RGB_LED_NANOPI_NEOCORE)

define RGB_LED_SUNXI

endif