Jump to content

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


lanefu

Recommended Posts

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

 

 

Try building the appropriate python lib linked in the resources section at the top of this post.. then read the official pya20 dox and see if you win.  https://pypi.python.org/pypi/pyA20

 

I *think* they're just bitbanging spi on that lib but not sure.

Link to comment
Share on other sites

Hi, I'm a bit of a n00b, but I'm learning fast.

 

Running Armbian_5.25_Orangepizero_Debian_jessie_default_3.4.113.img

I'm using https://github.com/nvl1109/orangepi_PC_gpio_pyH3 and trying to port a project I have running on a RPi.

 

On the RPi I do :-

import RPi.GPIO as GPIO

GPIO.setwarnings(False)

GPIO.setmode(GPIO.BOARD)

GPIO.setup(12, GPIO.OUT)

Then the program does it's thang and then exits with :-

GPIO.cleanup()

 

I have ported this as :-

from pyA20.gpio import gpio
from pyA20.gpio import port

gpio.init()

gpio.setcfg(port.PA7, gpio.OUTPUT)

do the thang

and then I'm out of ideas for an equivalent to GPIO.cleanup(), do you just abandon ship and leave things hanging in the breeze or is there a way of cleaning up that I've missed?

 

You chaps are doing a marvellous job btw, keep up the good work.

 

 

 

Link to comment
Share on other sites

Hi,

I want to connect to the MCP 2515 chip via SPI on Orange Pi Zero so I downloaded pyA20 library (of course the program is written in python). The GPIOs look to work just fine but there is an issue with SPI. When I'm just writing to the SPI the program works bu reading causes the stack smash error. The code I'm using is very simple and it seems that only reading is an issue:

from pyA20 import spi

def ResetModule(self):
        spi.open("/dev/spidev1.0")
        spi.write([0xC0])
        spi.write([0x50])
        spi.read(8)

The error I get:

*** stack smashing detected ***: python terminated

So is there an issue with the library or am I doing something wrong?

Link to comment
Share on other sites

I've never seen such error ...

But your code seem to read in half-duplex mode.

You should try in full duplex mode by sending the same amount of dummy bytes you wish to read using spi.xfer()

rx_data = spi.xfer([0,0,0,0,0,0,0,0], 8)
print rx_data

 

Link to comment
Share on other sites

So I deleted /usr/local/lib/python2.7/dist-packages/pyA20, just to be sure that I'm using the right library downloaded the one You are using and ran python setup.py install on that one. After that installation I get Segmentation fault. I wonder if I should reinstall the hole system because I messed up something in the system or I'm installing the library improperly.

Link to comment
Share on other sites

Which board are you using ? OPiZero or OPiZeroPlus-H5 ?

In other words, is it an H3 or an H5 ?

Because on H5, there is an issue that all those branches are not supporting 64 bits pointers.

I've fixed it these past days, but I didn't submit PR yet, but the fix is pretty easy :

Change all references of "unsigned int SUNXI_PIO_BASE;" to "unsigned long SUNXI_PIO_BASE;"

 

Link to comment
Share on other sites

The chip has H2+ on it so the library for H3 should work ok on it. Tomorrow I'll try downloading the newest Armbian and running this code on a clean version of the system (just python-dev installed).

Link to comment
Share on other sites

OK so I installed the newest system, installed python-dev and the library and I still get the segmentation fault. Should I do anything else before starting my program? I couldn't find any step-by-step manual. I've checked my /boot/script.bin and the SPI section seems to be set properly and looks as follows:

[spi0]
spi_used = 1
spi_cs_bitmap = 1
spi_mosi = port:PC00<3><default><default><default>
spi_miso = port:PC01<3><default><default><default>
spi_sclk = port:PC02<3><default><default><default>
spi_cs0 = port:PC03<3><1><default><default>

[spi1]
spi_used = 1
spi_cs_bitmap = 1
spi_cs0 = port:PA13<2><1><default><default>
spi_sclk = port:PA14<2><default><default><default>
spi_mosi = port:PA15<2><default><default><default>
spi_miso = port:PA16<2><default><default><default>

[spi_devices]
spi_dev_num = 2

[spi_board0]
modalias = "spidev"
max_speed_hz = 33000000
bus_num = 0
chip_select = 0
mode = 0
full_duplex = 1
manual_cs = 0

[spi_board1]
modalias = "spidev"
max_speed_hz = 33000000
bus_num = 1
chip_select = 0
mode = 0
full_duplex = 1
manual_cs = 0

 

Link to comment
Share on other sites

On May 4, 2017 at 2:44 AM, martinayotte said:

Which board are you using ? OPiZero or OPiZeroPlus-H5 ?

In other words, is it an H3 or an H5 ?

Because on H5, there is an issue that all those branches are not supporting 64 bits pointers.

I've fixed it these past days, but I didn't submit PR yet, but the fix is pretty easy :

Change all references of "unsigned int SUNXI_PIO_BASE;" to "unsigned long SUNXI_PIO_BASE;"

 

 

I know this is old, but I found this topic using google and could not find a Version that has this fixed for H5. So for future googlers that have segfaults on GPIO.setcfg() this may be of interest.

I did what you suggested changing alle the SUNXI_PIO_BASE references and it works, adapted version here:

https://github.com/herzig/orangepi_PC_gpio_pyH5 

 

Thanks!

Link to comment
Share on other sites

Hi, whatever choice is made, it is very good initiative.

from my 3 points of view:

for learning:  the best gpio python2 AND 3 lib is imho  https://github.com/vsergeev/python-periphery, it is *clean*, pythonic and very portable.

and for lowmem boards do not underestimate micropython (python3 like) unix port which can use any C gpio lib easily with libffi.

 

for hacking:  wiring* code is not so clean :P   . But maybe give a chance to wiringX rewrite https://github.com/wiringX/wiringX/tree/rewrite

 

for time critical:  really *none* of the above .

 

 

Link to comment
Share on other sites

Hello, all,
I also have a problem with the spi function read() of the orangepi_PC_gpio_pyH3-master library.
I use the image Armbian_5.30_Nanopim1_Ubuntu_xenial_default_3.4.113_desktop.7z
with Nanopi M1.
GPIO works perfectly, but SPI works just function write(). function read() causes the stack smashing error.
And the function xfer() causes a segmentation fault.
I have a clean system with just installed image and pyH3 library.
These problems are with both Python 3 and 2. I tested this with OrangePi PC with the same result.
I2C functions also do not work (segmentation fault)

What do i do wrong ?
I would be grateful for help.

Link to comment
Share on other sites

What about an universal lib which is  totally decoupled from HW platform, and with functions (SPI, I2C, UART, GPIO) separated?

  - It should be not only able to run on Allwinner SoCs, but also other

  - No kernel driver hacking or physical register access, only based on Linux userspace interface

 

I did port the wiringPi last year. Both C and Python (Cython based) are supported.

The only customizing needed is to fill in the GPIO number map (standard Linux GPIO number) and device number (SPI1, ttyS2 etc.)

 

https://github.com/nightseas/nightWiring

https://github.com/nightseas/python-nightWiring/

Link to comment
Share on other sites

On 10/31/2017 at 10:24 AM, nightseas said:

What about an universal lib which is  totally decoupled from HW platform, and with functions (SPI, I2C, UART, GPIO) separated?

  - It should be not only able to run on Allwinner SoCs, but also other

  - No kernel driver hacking or physical register access, only based on Linux userspace interface

 

I did port the wiringPi last year. Both C and Python (Cython based) are supported.

The only customizing needed is to fill in the GPIO number map (standard Linux GPIO number) and device number (SPI1, ttyS2 etc.)

 

https://github.com/nightseas/nightWiring

https://github.com/nightseas/python-nightWiring/

 

May I put another dime in the pocket? :)

 

http://wiringx.org/

 

It is a very modular GPIO library, both C and Python.

I added versions for the Orange Pi one and the Olimex OLinuXino(not yet committed to the GitHub :P ) I didn't write the library though, but am using/contributing to it.

You can write one program and it is binary compatible with all boards. The Blink example works on all supported boards by giving the argument which board it should run on.

So, if I may say so, it has it's functions totally decoupled from the HW platform.

Adding a platform is about half an hour work, adding another SoC might take a little longer, but the H3 is already added, so adding more boards based on that SOC is pretty easy.

 

regards

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