[559] - GPIO Support for H2/H3 boards with a unified WiringPI library in a neat little package


Recommended Posts

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


Inspired from these discussions:
  • 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
  • Compile todos from other discussions



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


  • @tkaiser
  • @martinayotte
  • @jernej
Link to post
Share on other sites
Armbian is a community driven open source project. Do you like to contribute your code?

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 :)

Link to post
Share on other sites

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

Link to post
Share on other sites

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

Link to post
Share on other sites

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


1 - 3.3v
9 - GND
11 - PA1 (UART2_RX/JTAG_CK0/PA_EINT1) [IO-0]
13 - PA0 (UART2_TX/JTAG_MS0/PA_EINT0) [IO-2]
17 - 3.3v
25 - GND

2 - 5v
4 - 5v
6 - GND
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
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_used = 0
gpio_num = 2
gpio_pin_1 = port:PA07<1><default><default><0>
gpio_pin_2 = port:PA10<1><default><default><0>
Link to post
Share on other sites

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....



Link to post
Share on other sites

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!

Link to post
Share on other sites

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.

Link to post
Share on other sites

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

Link to post
Share on other sites

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.

Link to post
Share on other sites
This topic is now closed to further replies.