It's time to unify GPIO for the other PIs with WiringOtherPI and bundle it with Armbian!

 

Inspired from these discussions:

 

https://forum.armbian.com/index.php/topic/2808-orange-pi-zero-went-to-the-market/page-4#entry20302

http://tech.scargill.net/banana-pi-m2/#comment-27946

 

Goals

• WiringPI GPIO support for most AllWinner H2/H3 boards using legacy kernel
• WiringPI GPIO support for most AllWinner H2/H3 boards using mainline kernel
• Compatiblity with code using WiringPI dependencies
• Make my Orange Pi Zero blink my christmas lights
• Produce a distro-friendly package to be included with Armbian releases

Todos

• Compile todos from other discussions

 

Resources

• WiringOtherPi Repo
• Armbian Github issues for clerical purposes
• Jernej's read_fex tool 
• OrangePi Py20.GPIO Fork
• Another Py20.GPIO Fork that supports OrangePi Zero

And I'll just tag a few smart people here:

 

• @tkaiser
• @martinayotte
• @jernej

Small (NOOB) addendum: I don't know whether RPi.GPIO is something entirely different but IIRC there are also various adopted versions floating around. So in case code is already there and knowledge regarding the various board variants collected this lib might be addressed in the same or a second step.

 

At least 'hacks' like this should be able to be addressed in a similar way I would assume? Anyway, may the hardware guys share some wisdom

Yes, RPi.GPIO is coming from RaspberryPi community, I'm using the RPi.GPIO-PineA64 derivative since it is already as most pins there, I've submit a PR yesterday to add SPI/I2C borrowed from Olimex pyA20 to this pineA64 derivative, original Pi version still don't support those yet.

 

On H3, I prefer using the orangepi_PC_gpio_pyH3 since it is a derivative directly from Olimex pyA20 : https://github.com/duxingkei33/orangepi_PC_gpio_pyH3

I think RPi.GPIO is differently and strictly python.

 

WiringPI's roots come from emulating arduino stuff..  It seems to be the most comprehensive library as far as offering C libs, Shell Tools, python bindings, etc.

 

I'm game to target a different lib if needed tho..  I just did it for python

so should the end game be to just have a good python library and sysfs for shell- or are we interested in wiringPi for C and python?

Personally, I prefer python. But C libs can be usefull when speed is needed. Sysfs should be already handled by kernels.

I traced through the Pi Zero Schematics and mapped the 26 pins to their AllWinner ID/function
 

 

1 - 3.3v
3 - PA12 (TWI0_SDA/DI_RX/PA_EINT12)
5 - PA11 (TWI0_SCK/DI_TX/PA_EINT11)
7 - PA6 (SIM_PWREN/PWM1/PA_EINT6)
9 - GND
11 - PA1 (UART2_RX/JTAG_CK0/PA_EINT1) [IO-0]
13 - PA0 (UART2_TX/JTAG_MS0/PA_EINT0) [IO-2]
15 - PA3 (UART2_CTS/JTAG_DI0/PA_EINT3) [IO-3]
17 - 3.3v
19 - PA15 (SPI1_MOSI/UART3_RTS/PA_EINT15)
21 - PA16 (SPI1_MISO/UART3_CTS/PA_EINT16)
23 - PA14 (SPI1_CLK/UART3_RX/PA_EINT14)
25 - GND


2 - 5v
4 - 5v
6 - GND
8 - PG6 (UART1_TX/PG_EINT6)
10 - PG7 (UART1_RX/PG_EINT7)
12 - PA7 (SIM_CLK/PA_EINT7) [IO-1]
14 - GND
16 - PA19 (PCM0_CLK/TWI1_SDA/PA_EINT19) [IO-4]
18 - PA18 (PCM0_SYNC/TWI1_SCK/PA_EINT18) [IO-5]
20 - GND
22 - PA2 (UART2_RTS/JTAG_DO0/PA_EINT2) [IO-6]
24 - PA13 (SPI1_CS/UART3_TX/PA_EINT13)
26 - PA10 (SIM_DET/PA_EINT10)

 
So according to the FEX there's like 2 GPIO Pins enabled by default?  Pin12(PA7) and Pin26(PA10)?
 

[gpio_para]
gpio_used = 0
gpio_num = 2
gpio_pin_1 = port:PA07<1><default><default><0>
gpio_pin_2 = port:PA10<1><default><default><0>

I think we care too much for [gpio_para] section. It is used only by sunxi-gpio driver, which is not loaded by default (it is module). This driver is even dropped by later Allwinner BSP revisions.

Personally, I prefer python. But C libs can be usefull when speed is needed. Sysfs should be already handled by kernels.

 

Hmm I'm so torn now.... the python minimum viable solution is appealing for most mortals and I would figure C nerds are just going to do what they're going to do regardless--but these guys have interrupt support working now for the C stuff, so I guess there is a bit of polish going on

 

Especially now that I've realized Zhaolei's WiringOP is more maintained that I originally thought....

 

https://github.com/zhaolei/WiringOP/commits/h3

I think we care too much for [gpio_para] section. It is used only by sunxi-gpio driver, which is not loaded by default (it is module). This driver is even dropped by later Allwinner BSP revisions.

 

So what replaces the suxi-gpio module?  the generic gpio sysfs stuff?

the generic gpio sysfs stuff?

 

yes, it has same or better functionality and it must be present anyway (pinctrl) if you want to have useful kernel.

I think we care too much for [gpio_para] section. It is used only by sunxi-gpio driver, which is not loaded by default (it is module). This driver is even dropped by later Allwinner BSP revisions.

I think we should edit all fex files for H3 boards, remove all definitions from [gpio_para] section and add a comment that this section is obsolete.

I think we should edit all fex files for H3 boards, remove all definitions from [gpio_para] section and add a comment that this section is obsolete.

 

IMO that would be good. I must check if LED section is using this defines but AFAIK Armbian doesn't use them anyway.

Well for the sake of time i ended up doing a GPIO project on a Pi A+ with rpi.gpio....  it was pretty easy to use.

 

so uhm lets see what the thoughts are for scope.

 

try to get this to support h2 and h3 boards by using some autodection for 

 

https://github.com/duxingkei33/orangepi_PC_gpio_pyH3/tree/master/pyA20/gpio ?

So are you gonna do both now? The WiringOPI for OPI-0 or the Rpi.gpio?

 

Would be nice if both were available, but I know you do it in your free time and your free time is probably limited, so I'm happy in any case .

 

Since there are project online for the raspberry that use WiringPi and projects that use Rpi.GPIO.

 

Btw sincerly thanks for doing it!

try to get this to support h2 and h3 boards by using some autodection for 

 

https://github.com/duxingkei33/orangepi_PC_gpio_pyH3/tree/master/pyA20/gpio ?

 

What is your question exactly about this PyA20 ?

Any news on this? Are you waiting for other stuff (Wifi, ethernet) to be rock solid on the OPI Zero, before you start addding this support?

sorry I kinda fell off the face of the earth and dropped the ball.   

 

I'm still torn about what's more desirable..  a robust wiringpi port or just a healthy pyA20

My personal preference is that the wiring should follow the Arduino libraries.

My thinking is that it you do that then you get some compatibility with all the Arduino based peripherals to some degree out of the box.

Python should follow based on a solid C/C++ implementation of the drivers/ APIs.

 

But just a biased opinion.

Disclaimer lots of years in the C/C++, C#  world, not so much in the Python world.

I'd say go with WiringPi, so we could reuse existing projects for Rpi. If you'd go with pyA20, then fork it and make it compatible with Rpi.GPIO so we can reuse those projects for RPi .

I have fingers crossed that sometime this project is gonna come to fruition

okay so focus on WiringOP..... thanks....   

I have fingers crossed that sometime this project is gonna come to fruition

 

I'm gonna make you help me....Fork my repo and see if you can identify the Pin Mapping code and we'll try to get this going

Well I still don't have the hardware, so I can't help you with physical experiments, in addition I even can't find the pin mapping code , its probably in WiringPi.c but I dunno where i should look there. 

Well I still don't have the hardware, so I can't help you with physical experiments, in addition I even can't find the pin mapping code , its probably in WiringPi.c but I dunno where i should look there. 

 

 

Forreal...You don't have a zero yet?  What a bummer... So definitions n stuff are usually in .h files for the .c files to use.. so may wanna poke there

Holy cow.. I had no idea how ugly the wiringpi C library really is... it's really ugly.. not that I know what I'm doing--but It's ugly.  

So what is the principle of changing stuff? Can you give an example? I know that then I test it on the physical pin, but what do I need to change in the code?

So what is the principle of changing stuff? Can you give an example? I know that then I test it on the physical pin, but what do I need to change in the code?

ill have to dig through my notes to show you.... at this point im uninspired to persue wiringOP because it just has so much junk in it. I see why werecat threw a fit on the orangepi forums a while back.

 

so ill slowly start chasing the python route. someone forked pya20 specifally for the zero.... i updated the first post of this thread and added it as a resource. i did a quick test with onboard led and it seemed to work

 

anyway i think pursuing an autodetecting pya20.gpio fork is the most straightforward path.

 

Tapatalk thinks its important to tell you im using tapatalk from a phone.

Yeah pya20 seems way more straightforward, even I can see that, and it nice that someone has already done the pin-mapping for it. Still interested tho' in the "principle" of WiringOP, just in theory.

How would I load a python library to communicate over spi with ws2812 leds?