Jump to content

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

lanefu

By lanefu
in Advanced users - Development

 Share

Recommended Posts

martinayotte

martinayotte

Posted
Posted

I don't know about specific WS2812 protocol, but doing an SPI transfer is about as simple as :

from pyA20 import spi

spi.open("/dev/spidev0.0", mode=0, delay=0, bits_per_word=8, speed=5000000)
data = [0,1,2,3,4,5,6,7,8,9]
spi.xfer(data, len(data))
1
lanefu

lanefu

Posted
  • Author
Posted

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.

billybangleballs

billybangleballs

Posted
Posted

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.

 

 

 

admbrt

admbrt

Posted
Posted

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?

martinayotte

martinayotte

Posted
Posted

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

 

admbrt

admbrt

Posted
Posted

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.

martinayotte

martinayotte

Posted
Posted

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

 

admbrt

admbrt

Posted
Posted

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

admbrt

admbrt

Posted
Posted

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

 

Ivo Herzig

Ivo Herzig

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

martinayotte

martinayotte

Posted
Posted

Right ! This is true for all 64bits SoC, I've narrowed that on PineA64 too...

There is not so much "unsigned int" to "unsigned long" conversion required, if I remember : 2 in the gpio_lib.h and 2 in gpio_lib.c.

 

1
pmpp

pmpp

Posted
Posted

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 .

 

 

mykola_k

mykola_k

Posted
Posted

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.

nightseas

nightseas

Posted
Posted

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/

1
ajvuik

ajvuik

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

1
Guest
This topic is now closed to further replies.
 Share
Go to topic listing
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines

  I accept