Borisbritwa Posted April 14, 2017 Posted April 14, 2017 STATUS_LED and POWER_LED defined in mapping.h . What's about EPHY-LINK-LED(A2) and EPHY-SPD-LED(F7) is it possible?
Borisbritwa Posted April 17, 2017 Posted April 17, 2017 #!/usr/bin/python import time from pyA20.gpio import gpio from pyA20.gpio import port from pyA20.gpio import connector gpio.init() gpio.setcfg(port.POWER_LED, gpio.OUTPUT) while True: gpio.output(port.POWER_LED, gpio.HIGH) time.sleep(0.25) gpio.output(port.POWER_LED, gpio.LOW) time.sleep(0.25) WHY THIS CODE DOES NOT WORK !!!???
martinayotte Posted April 17, 2017 Posted April 17, 2017 Because the POWER_LED is already in use by the kernel. It is the same if you try to use it with sysfs. echo 362 > /sys/class/gpio/export -bash: echo: write error: Device or resource busy The only way to free it is to edit DT and removing it from the r_pio section. But the STATUS_LED is already free and available.
maco1717 Posted May 4, 2017 Posted May 4, 2017 Hi, I was wondering if anyone knew if I could use this https://github.com/duxingkei33/orangepi_PC_gpio_pyH3 on the Orange Pi H2+ I've noticed the header is smaller than the H3 most of the pins that are in H2+ are in H3 but not all. Please see attached image. I'm assuming the GPIO ping that are in H3 I can use on H2+ looks like both use the same SoC could someone confirm this. Also how difficutl would it be to add the GPIOs that are in H2+ that are not in H3. Thanks. \Marco
martinayotte Posted May 4, 2017 Posted May 4, 2017 Someone has forked the above link and already ported it for OpiZero mapping : https://github.com/nvl1109/orangepi_PC_gpio_pyH3
maco1717 Posted May 5, 2017 Posted May 5, 2017 Oh Wow! that's excelent. I got one more question tho. Im looking for a similar method to use interrupt driven GPIO as in RPi.GPIO GPIO.add_event_detect(pin_number, GPIO.BOTH, callback=callback_function) Thanks.
martinayotte Posted May 5, 2017 Posted May 5, 2017 Unfortunately, the is no interrupts handling in the above libs.
maco1717 Posted May 6, 2017 Posted May 6, 2017 Quite. Thanks for getting back to me on this. I going to add it to my list of thing to do, I'm considering porting Rpi.GPIO to PI unless I find a solution before I get to it. xP
martinayotte Posted May 6, 2017 Posted May 6, 2017 Maybe you can take a look how it is done in Rpi.GPIO, and see if same method could be added in the other lib.
nedoskiv Posted May 7, 2017 Posted May 7, 2017 interrupts should be nice, I use fs access to gpio and my scripts are monitoring them every 0.1 sec, that make some cpu load, interrupts gonna be better
arhi Posted May 23, 2017 Posted May 23, 2017 On 12/19/2016 at 6:16 PM, martinayotte said: I've the I2C working, and for SPI I will probably need to tweak DT, since I'm working exclusively with Mainline. (So, I can't provide recipe for FEX, since I don't use Legacy) mainline kernel/armbian here, "Welcome to ARMBIAN 5.27 stable Debian GNU/Linux 8 (jessie) 4.10.11-sun8i" but I can't find a way to use i2c .. starting to feel frustrated .. (not with the system but with myself, feeling overly stupid with these oranges) so I'd really appreciate some help I tried few libs, examples.. etc.. but they all expect /dev/i2c* to exist.. but I don't have those root@orangepione:~/nekiliksaforuma/orangepi_PC_gpio_pyH3# modprobe i2c-dev root@orangepione:~/nekiliksaforuma/orangepi_PC_gpio_pyH3# modprobe --show-depends i2c-dev builtin i2c_dev root@orangepione:~/nekiliksaforuma/orangepi_PC_gpio_pyH3# ls -lad /dev/i2c* ls: cannot access /dev/i2c*: No such file or directory root@orangepione:~/nekiliksaforuma/orangepi_PC_gpio_pyH3# ls -lad /dev/i* lrwxrwxrwx 1 root root 25 Jan 1 1970 /dev/initctl -> /run/systemd/initctl/fifo drwxr-xr-x 3 root root 80 May 23 13:17 /dev/input root@orangepione:~/nekiliksaforuma/orangepi_PC_gpio_pyH3# I have the orangepi_PC_gpio_pyH3 you mentioned but don't see how to use it for i2c now, I see further down the thread that DTB thingy needs to be changed but I'm stuck with it ... attm I have wrt i2c pinctrl@01c20800 { compatible = "allwinner,sun8i-h3-pinctrl"; reg = <0x1c20800 0x400>; interrupts = <0x0 0xb 0x4 0x0 0x11 0x4>; clocks = <0x2 0x36 0x9 0xb>; clock-names = "apb", "hosc", "losc"; gpio-controller; #gpio-cells = <0x3>; interrupt-controller; #interrupt-cells = <0x3>; linux,phandle = <0x11>; phandle = <0x11>; i2c0 { allwinner,pins = "PA11", "PA12"; allwinner,function = "i2c0"; allwinner,drive = <0x0>; allwinner,pull = <0x0>; linux,phandle = <0x1d>; phandle = <0x1d>; }; i2c1 { allwinner,pins = "PA18", "PA19"; allwinner,function = "i2c1"; allwinner,drive = <0x0>; allwinner,pull = <0x0>; linux,phandle = <0x1e>; phandle = <0x1e>; }; i2c2 { allwinner,pins = "PE12", "PE13"; allwinner,function = "i2c2"; allwinner,drive = <0x0>; allwinner,pull = <0x0>; linux,phandle = <0x1f>; phandle = <0x1f>; }; ... i2c@01c2ac00 { compatible = "allwinner,sun6i-a31-i2c"; reg = <0x1c2ac00 0x400>; interrupts = <0x0 0x6 0x4>; clocks = <0x2 0x3b>; resets = <0x2 0x2e>; pinctrl-names = "default"; pinctrl-0 = <0x1d>; status = "disabled"; #address-cells = <0x1>; #size-cells = <0x0>; linux,phandle = <0x54>; phandle = <0x54>; }; i2c@01c2b000 { compatible = "allwinner,sun6i-a31-i2c"; reg = <0x1c2b000 0x400>; interrupts = <0x0 0x7 0x4>; clocks = <0x2 0x3c>; resets = <0x2 0x2f>; pinctrl-names = "default"; pinctrl-0 = <0x1e>; status = "disabled"; #address-cells = <0x1>; i2c@01c2b400 { compatible = "allwinner,sun6i-a31-i2c"; reg = <0x1c2b000 0x400>; interrupts = <0x0 0x8 0x4>; clocks = <0x2 0x3d>; resets = <0x2 0x30>; pinctrl-names = "default"; pinctrl-0 = <0x1f>; status = "disabled"; #address-cells = <0x1>; #size-cells = <0x0>; linux,phandle = <0x56>; phandle = <0x56>; }; ... i2c@01f02400 { compatible = "allwinner,sun6i-a31-i2c"; reg = <0x1f02400 0x400>; interrupts = <0x0 0x2c 0x4>; pinctrl-names = "default"; pinctrl-0 = <0x26>; clocks = <0x23 0x6>; clock-frequency = <0x186a0>; resets = <0x25 0x6>; status = "disabled"; #address-cells = <0x1>; #size-cells = <0x0>; linux,phandle = <0x5c>; phandle = <0x5c>; }; ... pinctrl@01f02c00 { compatible = "allwinner,sun8i-h3-r-pinctrl"; reg = <0x1f02c00 0x400>; interrupts = <0x0 0x2d 0x4>; clocks = <0x23 0x0 0x9 0xb>; clock-names = "apb", "hosc", "losc"; resets = <0x25 0x0>; gpio-controller; #gpio-cells = <0x3>; interrupt-controller; #interrupt-cells = <0x3>; linux,phandle = <0x29>; phandle = <0x29>; ir@0 { allwinner,pins = "PL11"; allwinner,function = "s_cir_rx"; allwinner,drive = <0x0>; allwinner,pull = <0x0>; linux,phandle = <0x5d>; phandle = <0x5d>; }; r_i2c@0 { allwinner,pins = "PL0", "PL1"; allwinner,function = "s_twi"; allwinner,drive = <0x0>; allwinner,pull = <0x0>; linux,phandle = <0x26>; phandle = <0x26>; }; ... and more .. no clue how to solve the problem
arhi Posted May 23, 2017 Posted May 23, 2017 figured it out adding "overlays=i2c0" to /boot/armbianEnv.txt solved the problem ..
Borisbritwa Posted June 10, 2017 Posted June 10, 2017 Has connected the display. What is the maximum SPI speed? The library can send parcels of 8 bits, how to change to 16 bits? I mean spi.write([0x00FF]) it's not possible ? Only spi.write([msb,lsb]) possibly.
Borisbritwa Posted June 11, 2017 Posted June 11, 2017 The maximum speed of spi for orange pi zero? My logical analyzer shows the maximum speed at SPI1_CLK/PA14 about 5 MHz It's not enough for me . This screen can work above 10 MHz. My settings in the program spi.open("/dev/spidev1.0", mode=0, delay=0, bits_per_word=8, speed=100000) this is 100 MHz , but I have in reality only 5 MHz CLK.
Borisbritwa Posted June 12, 2017 Posted June 12, 2017 Here's what I found out maximum speed for SPI 33 MHz this is defined in script.bin .The next command, I set the SPI for speed 5MHz spi.open("/dev/spidev1.0", mode=0, delay=0, bits_per_word=8, speed=500000) . Speed is set in Hz and not in kHz, as in the library wrote !!! When setting the speed above 6 megahertz, the screen starts to slow down .In reality, if the SPI speed is set to 10 Mhz, it starts to work worse than at 5 Mhz.
Francesco Spossati Posted August 21, 2017 Posted August 21, 2017 On 15/12/2016 at 8:49 PM, martinayotte said: For all my Oranges, I'm using https://github.com/duxingkei33/orangepi_PC_gpio_pyH3 Be aware that on PiZero, the STATUS_LED is not on PA15 but on PA17, therefore you will need to tweak mapping.h to change that. Thank for this, now i know why it does not work. But it still not clear. i change this: { "STATUS_LED", SUNXI_GPA(15), 2 }, to this { "STATUS_LED", SUNXI_GPA(17), 2 }, then i reinstall everything with python setup.py install but it seems to be too fast, i think it did't recompile my mod. Do i missing something? THANK YOU!
martinayotte Posted August 21, 2017 Posted August 21, 2017 In this library, dependencies check for header changes are not good. Delete the build folder with "rm -rf build" and re-install ...
PoV Posted August 22, 2017 Posted August 22, 2017 Hey! I just wanted to say thanks to martinayotte for patiently helping out. I was able to easily get the script here working on an Orange Pi One running a mainline Armbian: https://forum.armbian.com/index.php?/topic/3084-orange-pi-zero-python-gpio-library/&do=findComment&comment=28706 I used this version of the library. https://github.com/duxingkei33/orangepi_PC_gpio_pyH3 Installed it by following the instructions on that page. I already had GCC and `build-essentials` installed, but I did have to install the `python-dev` package before it would build though. I was then able to modify the sample script to toggle PA12 high and low (just like the LED) to make a Piezo buzzer do its thing. Used the pinout here as reference. http://linux-sunxi.org/Xunlong_Orange_Pi_One_%26_Lite I just wanted to collect my notes all in one place. Thanks again.
chocomega Posted August 23, 2017 Posted August 23, 2017 On 5/5/2017 at 0:23 PM, maco1717 said: Oh Wow! that's excelent. I got one more question tho. Im looking for a similar method to use interrupt driven GPIO as in RPi.GPIO GPIO.add_event_detect(pin_number, GPIO.BOTH, callback=callback_function) Thanks. On 5/23/2017 at 2:39 PM, pel.hu said: I'm also looking for a RPi.GPIO compatible solution so I can use my python codes wriiten for raspis. It's not only the lack of interrupts but all the setting commands are different. If someone finds or writes one please share it here. I found this library OPi.GPIO https://github.com/rm-hull/OPi.GPIO Quote A drop-in replacement library for RPi.GPIO for the Orange Pi Zero. Only the basic GPIO functions are replicated, using sysfs: this allows the GPIO pins to be accessed from user space. See the documentation for install instructions and detailed API usage. Not sure if it uses interrupts but edge detection and eventing is working so far. Pretty useful if you want to reuse code made with RPi.GPIO Please note: Support for pull up / pull down resistors and switch debounce are not yet complete.
jdugat Posted October 23, 2017 Posted October 23, 2017 I know most of the posts in this thread have to do with doing more complex things with the GPIO than what I want to do, but thought it would be a good place to ask (I hope) a simple question. I have a OPiZero (with usb expansion board) connected to a web cam using motion. I've got everything working just find, however, every now and again the /dev/video0 or /dev/video1 (probably the usb camera) will decide not to initialize and reboot will not correct the issue. I have an ESP8266 connected to the battery supplying the OPiZero, so I can monitor it to make sure the battery doesn't get to low. The ESP8266 can shut the power off to the OPiZero with a simple relay inline with the usb power cable. What I'd like to be able to do is set a pin to high on the OPiZero and read it on the ESP8266, so it can cycle the power. I think this is possible, but I'm still fairly green on GPIO usage. Can someone tell me which pin I could use to do something like this and would I be able to set the pin to a HIGH status with something as easy as a bash statement like echo out > gpio67/direction ? Any help would be greatly appreciated! Thanks.
martinayotte Posted October 23, 2017 Posted October 23, 2017 If your are talking about which GPIOs provided by ESP8266, I think GPIO15 is a good one, since it need to be pulled-down during ESP8266 powerup. The only thing is that you need to drive your relay with a MOSFET
jdugat Posted October 24, 2017 Posted October 24, 2017 From the picture below do I have the correct pin you are talking about (fourth down from the top on the right side of the double pinned row) ?
martinayotte Posted October 24, 2017 Posted October 24, 2017 No ! You were talking about ESP8266 driving a relay to cut power of the OPi, so, when I've said GPIO15, I was talking about GPIO15 of the ESP8266 itself ...
jdugat Posted October 24, 2017 Posted October 24, 2017 Sorry, then as per usual I confused everything. All I want to do set a pin high on the GPIO that I can read on the ESP8266 using something like the python code below. I just don't know which of the GPIO pins on the OPiZ I can use. Of course, I'll make sure that the GPIO pin is set to LOW when the OPiZ boots up. import os import sys if not os.getegid() == 0: sys.exit('Script must be run as root') from time import sleep from pyA20.gpio import gpio from pyA20.gpio import port from pyA20.gpio import connector __author__ = "Stefan Mavrodiev" __copyright__ = "Copyright 2014, Olimex LTD" __credits__ = ["Stefan Mavrodiev"] __license__ = "GPL" __version__ = "2.0" __maintainer__ = __author__ __email__ = "support@olimex.com" pin15 = connector.LEDp2 # This is the same as port.STATUS_LED gpio.init() gpio.setcfg(pin15, gpio.OUTPUT) sleep(2)
martinayotte Posted October 24, 2017 Posted October 24, 2017 Ok ! You means a GPIO from OPi as an output, then the ESP8266 will read it. I would say that almost any free GPIOs from OPi could be used, as long as they are not used for something else ...
jdugat Posted October 24, 2017 Posted October 24, 2017 Yes, sorry for the confusion. What would be a good one that's in the userspace already? Presently, I'm not using any of the pins that the arrow in the image below is pointing to.
martinayotte Posted October 24, 2017 Posted October 24, 2017 As I said, as long as you don't use alternate mode on some pins, for example, if you don't use TWI1, then PA18/PA19 are free. Depending of your kernel type, Legacy or Mainline, you need to make sure that TWI1 isn't enabled.
jdugat Posted October 25, 2017 Posted October 25, 2017 Please forgive my ignorance, but is there a way to test the availability of a of pin?
martinayotte Posted October 25, 2017 Posted October 25, 2017 For some usage, doing "cat /sys/kernel/debug/gpio" will reveal if pin is in use by kernel driver. But for some other usage such as I2C/SPI, you need to inspect Legacy FEX or Mainline DT. 1
Recommended Posts