Jump to content

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


lanefu

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
Link to comment
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 :)

Link to comment
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 comment
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 comment
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>
Link to comment
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.

Link to comment
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

Link to comment
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?

Link to comment
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.

Link to comment
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.

Link to comment
Share on other sites

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 ?

Link to comment
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 comment
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 comment
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

Link to comment
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. 

Link to comment
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 comment
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 comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines