3 3
lanefu

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

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

 

  • @tkaiser
  • @martinayotte
  • @jernej

Share this post


Link to post
Share on other sites

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

Share this post


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

Share this post


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

Share this post


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

Share this post


Link to post
Share on other sites

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.

Share this post


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

 

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

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


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!

Share this post


Link to post
Share on other sites

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

Share this post


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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

 

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

Share this post


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. 

Share this post


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

Share this post


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?

Share this post


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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
3 3