chwe Posted November 16, 2017 Posted November 16, 2017 (edited) The pyA20 gpio library is quite famous when people start to play with gpios , spi or i2c on sunxi boards but mapping needs often adjustments to work on your own board. This situation is not really friendly for 'beginners'. pyGPIO should help to make armbian a little bit more 'IoT friendly'. I didn't touch the 'backbone' of pyA20, so the syntax should be similar to its original (except pinname when using port instead of connector). How can I use this library: Cause all of this boards have (more or less) the same pinheader (sometimes other pins are deployed on the pinheader) pyGPIO tries to unify the mappings, so that code can be shared and deployed on all boards without touching the code. The mapping follows the pin naming of the RaspberryPi (it's not because I think their naming is perfect, but it should be the easiest way to port code from the 'RPi world' to Armbian. What is done: -Initial support for: OrangePi Zero/PcPlus/Lite/Plus2E NanoPi Duo(with and without Minishield)/Neo Olimex Lime/Lime2/Micro (pins are not renamed PG10,PG11 etc. instead of GPIO2, GPIO3 etc. cause those boards doesn't have a 'RPi Pinheader' Templates for 24,26 and 40 'RPi compatible' pin header -Board detection (when using Armbian) to check if your board is supported -Manual assignment when your board is not supported (yet) or automatic board detection fails What is not done: Testing testing testing! Documentation Meaningful examples (still the originals from olimex which wouldn't work anymore) What do you need to test the Library: You need python-dev and the Library which you'll find on my GitHub page. The installation should be easy, just follow the instructions... sudo apt-get install python-dev git clone https://github.com/chwe17/pyGPIO.git cd pyGPIO sudo python setup.py install Testing is the part where I need help. I don't have most of the boards which are supported (only OPi0 and OPi Pc Plus). I tested I2C and GPIO on the OPi0, for all the rest, I need you as testers, bug hunters, and feedback. Here are two short python snippets which should do the exact same thing (once with connector, you have to run them as root or with sudo otherwise it would not work!): import os, sys if not os.getegid() == 0: sys.exit('start script as root') from pyGPIO.gpio import gpio, connector from time import sleep gpio.init() gpio.setcfg(connector.GPIOp7, 1) #pin 7 as output n = 0 while n < 5: gpio.output(connector.GPIOp7, 1) sleep(1) gpio.output(connector.GPIOp7, 0) sleep(1) n +=1 sys.exit('finished ;-)') and once with port: import os, sys if not os.getegid() == 0: sys.exit('start script as root') from pyGPIO.gpio import gpio, port from time import sleep gpio.init() gpio.setcfg(port.GPIO4, 1) #gpio4 as output n = 0 while n < 5: gpio.output(port.GPIO4, 1) sleep(1) gpio.output(port.GPIO4, 0) sleep(1) n +=1 sys.exit('finished ;-)') Annotation: When using NanoPi Duo you've to possibilities with or without Minishield. Pin name is the same on both possibilities but when using port but pin numbering when using connector: Minishield: 3.3V |1·| 5V GPIO2 I2C0_SDA |3·| 5V GPIO3 I2C_SCL |5·| GND GPIO4 |··| GPIO14 UART1_TX GND |··| GPIO15 UART1_RX GPIO17 SPI1_MOSI |··| GPIO18 GPIO27 SPI1_MISO |··| GND GPIO22 SPI1_CLK |··| GPIO23 SPI1_CS 3.3V |··| NC (on mini shield) Without (e.g. connector.J1p7 or connector.J2p5) : J1 J2 (UART0_RX) |1| microUSB |1| 5V (UART0_TX) |2| |·| 5V GND |3| |·| 3.3V GPIO3 (TWI_SCL) |4| |·| GND GPIO2 (TWI_SDA) |5| |·| GPIO4 (IR_RX) GPIO23 (SPI1_CS) |6| |·| GPIO18 (IOG11) GPIO22 (SPI1_CLK) |7| |·| DM3 D- GPIO27 (SPI1_MISO) |·| |·| DM3 D+ GPIO17 (SPI1_MOSI) |·| |·| DM2 D- GPIO15(UART1_RX) |·| |·| DM2 D+ GPIO14 (UART1_TX) |·| |·| RDN (CVBS) |·| |·| RDP (LINEOUT_L) |·| |·| TXN (LINEOUT_R) |·| |·| TXP (MICP) |·| |·| LED-LINK (MICN) |·| microSD |·| LED-SPD Buttons (bigger orange pi boards) are mapped, but I didn't test if it works (mapping here, if somebody is interested in testing them, see mapping.h of your board): {"BUTTON", { { "BUTTON", SUNXI_GPL(4), 1 }, { { 0, 0, 0} }, } }, Edited November 29, 2017 by chwe add sudo/root 1 Quote
TonyMac32 Posted November 18, 2017 Posted November 18, 2017 Well, I had some trouble at first, since I'm bread boarding without shield and missed Without (e.g. connector.J1p7 or connector.J2p5) duh... I will come back after I spend some time playing. 0 Quote
chwe Posted November 18, 2017 Author Posted November 18, 2017 Needs also a bit more documentation. It needs a little bit more explanation. Olimex boards have a lot of gpio possibilities and you can address all of them (e.g gpio1, gpio2, lcd etc.). Since most others don't have more pinheaders I named it GPIO (do have a difference capital/small letters to the Olimex boards). Or when using the nanopi duo J1 and J2 (according to the datasheet) when you install the lib with minishield it's also called 'GPIO'. There's also a pin-header called LED (normally LEDp1 = POWER_LED, mostly the red one and LEDp2 = STATUS_LED) and a pin-header "BUTTON" (BUTTONp1 = BUTTON_1, but not tested yet). It should also be possible to use the GPIOs delivered by the CSI pin-header: This should give 14 GPIOs + I2C (TWI2) more.... I didn't implement them in the library now, cause it would need adjustments in the fex file for the legacy kernel, and I've no clue whats needed on mainline to use them as normal GPIOs. Maybe @Igor or @zador.blood.stained can comment this? If you're not sure about the naming for your board, just consult pyGPIO/pyGPIO/gpio/mapping/your_board_name.h to get some additional information (I hope I find time to write this stuff down in a small documentation). 0 Quote
martinayotte Posted November 18, 2017 Posted November 18, 2017 12 hours ago, chwe said: I've no clue whats needed on mainline to use them as normal GPIOs All unused GPIOs are defaulted as normal GPIO, no needs to tweak DT. And they can be tested easily using /sys/class/gpio ... 1 Quote
chwe Posted November 20, 2017 Author Posted November 20, 2017 On 18.11.2017 at 4:38 PM, martinayotte said: All unused GPIOs are defaulted as normal GPIO, no needs to tweak DT. And they can be tested easily using /sys/class/gpio ... I'll give it a try, but maybe next year. If someone wanna test it, I can adjust the mapping for a board with CSI connector. Thanks to @TonyMac32 , processor detection (Sun8i) should also work under mainline now. At the moment, I play with some i2c devices to test the library a little bit. I'll make this code snippets public on Github so that others can use it too. 0 Quote
Pol Isidor Posted November 23, 2017 Posted November 23, 2017 (edited) Can someone help me, why I can not compile pyGPIO? Im using Orange PI PC ans HDW with: Armbian_5.32_Orangepipc_Debian_jessie_default_3.4.113 Spoiler root@orangepipc:~/temp# git clone https://github.com/chwe17/pyGPIO.git cd pyGPIO Cloning into 'pyGPIO'... sudo python setup.py installremote: Counting objects: 241, done. remote: Compressing objects: 100% (148/148), done. remote: Total 241 (delta 169), reused 152 (delta 92), pack-reused 0 Receiving objects: 100% (241/241), 54.64 KiB | 0 bytes/s, done. Resolving deltas: 100% (169/169), done. Checking connectivity... done. root@orangepipc:~/temp# cd pyGPIO root@orangepipc:~/temp/pyGPIO# sudo python setup.py install running install running build running build_py creating build creating build/lib.linux-armv7l-2.7 creating build/lib.linux-armv7l-2.7/pyGPIO copying pyGPIO/__init__.py -> build/lib.linux-armv7l-2.7/pyGPIO creating build/lib.linux-armv7l-2.7/pyGPIO/gpio copying pyGPIO/gpio/__init__.py -> build/lib.linux-armv7l-2.7/pyGPIO/gpio running build_ext Detected processor: sun8i (Probably Allwinner H2+/H3) Unknown board Automatic board detection failed or your board is not supported (yet). You can use a pin mapping from one of our supported boards or abort the installation. This is only recommended for experienced users! Pin mapping might be false and the library does not work as expected! [1] OrangePi Zero [2] OrangePi Pc Plus [3] OrangePi Plus 2E [4] OrangePi Lite [5] A20-OLinuXino-MICRO [6] A20-OLinuXIno-LIME [7] A20-OLinuXIno-LIME2 [8] NanoPi Duo [9] NanoPi Neo [10] Abort 2 building 'pyGPIO.gpio.gpio' extension creating build/temp.linux-armv7l-2.7 creating build/temp.linux-armv7l-2.7/pyGPIO creating build/temp.linux-armv7l-2.7/pyGPIO/gpio arm-linux-gnueabihf-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fno-strict-aliasing -D_FORTIFY_SOURCE=2 -g -fstack-protector-strong -Wformat -Werror=format-security -fPIC -I/usr/include/python2.7 -c pyGPIO/gpio/gpio_lib.c -o build/temp.linux-armv7l-2.7/pyGPIO/gpio/gpio_lib.o arm-linux-gnueabihf-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fno-strict-aliasing -D_FORTIFY_SOURCE=2 -g -fstack-protector-strong -Wformat -Werror=format-security -fPIC -I/usr/include/python2.7 -c pyGPIO/gpio/gpio.c -o build/temp.linux-armv7l-2.7/pyGPIO/gpio/gpio.o arm-linux-gnueabihf-gcc -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions -Wl,-z,relro -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -D_FORTIFY_SOURCE=2 -g -fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro -D_FORTIFY_SOURCE=2 -g -fstack-protector-strong -Wformat -Werror=format-security build/temp.linux-armv7l-2.7/pyGPIO/gpio/gpio_lib.o build/temp.linux-armv7l-2.7/pyGPIO/gpio/gpio.o -o build/lib.linux-armv7l-2.7/pyGPIO/gpio/gpio.so building 'pyGPIO.i2c' extension creating build/temp.linux-armv7l-2.7/pyGPIO/i2c arm-linux-gnueabihf-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fno-strict-aliasing -D_FORTIFY_SOURCE=2 -g -fstack-protector-strong -Wformat -Werror=format-security -fPIC -I/usr/include/python2.7 -c pyGPIO/i2c/i2c_lib.c -o build/temp.linux-armv7l-2.7/pyGPIO/i2c/i2c_lib.o arm-linux-gnueabihf-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fno-strict-aliasing -D_FORTIFY_SOURCE=2 -g -fstack-protector-strong -Wformat -Werror=format-security -fPIC -I/usr/include/python2.7 -c pyGPIO/i2c/i2c.c -o build/temp.linux-armv7l-2.7/pyGPIO/i2c/i2c.o arm-linux-gnueabihf-gcc -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions -Wl,-z,relro -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -D_FORTIFY_SOURCE=2 -g -fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro -D_FORTIFY_SOURCE=2 -g -fstack-protector-strong -Wformat -Werror=format-security build/temp.linux-armv7l-2.7/pyGPIO/i2c/i2c_lib.o build/temp.linux-armv7l-2.7/pyGPIO/i2c/i2c.o -o build/lib.linux-armv7l-2.7/pyGPIO/i2c.so building 'pyGPIO.spi' extension creating build/temp.linux-armv7l-2.7/pyGPIO/spi arm-linux-gnueabihf-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fno-strict-aliasing -D_FORTIFY_SOURCE=2 -g -fstack-protector-strong -Wformat -Werror=format-security -fPIC -I/usr/include/python2.7 -c pyGPIO/spi/spi_lib.c -o build/temp.linux-armv7l-2.7/pyGPIO/spi/spi_lib.o arm-linux-gnueabihf-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fno-strict-aliasing -D_FORTIFY_SOURCE=2 -g -fstack-protector-strong -Wformat -Werror=format-security -fPIC -I/usr/include/python2.7 -c pyGPIO/spi/spi.c -o build/temp.linux-armv7l-2.7/pyGPIO/spi/spi.o arm-linux-gnueabihf-gcc -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions -Wl,-z,relro -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -D_FORTIFY_SOURCE=2 -g -fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro -D_FORTIFY_SOURCE=2 -g -fstack-protector-strong -Wformat -Werror=format-security build/temp.linux-armv7l-2.7/pyGPIO/spi/spi_lib.o build/temp.linux-armv7l-2.7/pyGPIO/spi/spi.o -o build/lib.linux-armv7l-2.7/pyGPIO/spi.so building 'pyGPIO.gpio.connector' extension creating build/temp.linux-armv7l-2.7/pyGPIO/gpio/connector arm-linux-gnueabihf-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fno-strict-aliasing -D_FORTIFY_SOURCE=2 -g -fstack-protector-strong -Wformat -Werror=format-security -fPIC -I/usr/include/python2.7 -c pyGPIO/gpio/connector/connector.c -o build/temp.linux-armv7l-2.7/pyGPIO/gpio/connector/connector.o In file included from pyGPIO/gpio/connector/connector.c:25:0: pyGPIO/gpio/connector/../mapping.h:27:0: error: unterminated #ifndef #ifndef __MAPPING_H ^ error: command 'arm-linux-gnueabihf-gcc' failed with exit status 1 Edited December 4, 2017 by Tido added spoiler 0 Quote
jscax Posted November 29, 2017 Posted November 29, 2017 from setup.py def check_board(): """ Detect board type (added by chwe17) """ boardinfo = open("/etc/armbian-image-release", 'r') I don't have /etc/armbian-image-release What I should search for instead? Do I need to install some utility tools? uname -r 4.13.16-sunxi cat /etc/debian_version stretch/sid cat /etc/os-release NAME="Ubuntu" VERSION="16.04.3 LTS (Xenial Xerus)" ID=ubuntu ID_LIKE=debian PRETTY_NAME="Ubuntu 16.04.3 LTS" VERSION_ID="16.04" HOME_URL="http://www.ubuntu.com/" SUPPORT_URL="http://help.ubuntu.com/" BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/" VERSION_CODENAME=xenial UBUNTU_CODENAME=xenial Orange Pi Zero Do you think it's possible to access GPIO from userspace? thank you 0 Quote
chwe Posted November 29, 2017 Author Posted November 29, 2017 Which image do you use? In case, board detection doesn't work, it should fall back to a manual board assignment whereas the OPi0 should be nr. 1. 11 minutes ago, jscax said: Do you think it's possible to access GPIO from userspace? Should be, but your problem would be the same... The lib needs sudo right at the moment. It's on my todo list to figure out what's exactly needed to run it without sudo (I've a lot of other todos so no guarantee that this is solved immediately ). 0 Quote
jscax Posted November 29, 2017 Posted November 29, 2017 I'm using the stable image ("Ubuntu server – legacy kernel") from here https://www.armbian.com/orange-pi-zero/ I changed the setup.py because otherwise it throws error trying to access non-existent file For userspace GPIO access I think I would try to reproduce the /dev/gpioSOMETHING approach, where you can manage broader user access permissions without issues. But I don't know where to start from. At very high level I think this is something I can obtain with a kernel module but I can't find anything. thank you 0 Quote
chwe Posted November 29, 2017 Author Posted November 29, 2017 4 minutes ago, jscax said: I'm using the stable image ("Ubuntu server – legacy kernel") from here https://www.armbian.com/orange-pi-zero/ I changed the setup.py because otherwise it throws error trying to access non-existent file Interesting, I'll have a look at it this when I'm back at home (tested it on 3.4.113 Kernel weeks ago). Would be nice to see a copy of the error but I'll try to reproduce your error (I've a OPi0). 8 minutes ago, jscax said: For userspace GPIO access I think I would try to reproduce the /dev/gpioSOMETHING approach, where you can manage broader user access permissions without issues. But I don't know where to start from. The whole project started cause I wanted a lib which works without changing code between my OPi0s and my OPi+PC. Setup.py will have a cleanup in the future. 1 Quote
jscax Posted November 29, 2017 Posted November 29, 2017 Just note I "forced" a kernel switch from 3.x to 4.13 (next) You're right I'm sorry, here the original error: python3 setup.py install running install running build running build_py running build_ext Detected processor: Allwinner sun8i Family (Probably Allwinner H2+/H3) error: [Errno 2] No such file or directory: '/etc/armbian-image-release' thank you 0 Quote
Igor Posted November 29, 2017 Posted November 29, 2017 11 minutes ago, jscax said: Just note I "forced" a kernel switch from 3.x to 4.13 (next) error: [Errno 2] No such file or directory: '/etc/armbian-image-release' There are only two options. We have a bug or you made some strange/from very old images upgrade. Can you start with a clean image from download? 0 Quote
jscax Posted November 29, 2017 Posted November 29, 2017 ___ ____ _ _____ / _ \ _ __ __ _ _ __ __ _ ___ | _ \(_) |__ /___ _ __ ___ | | | | '__/ _` | '_ \ / _` |/ _ \ | |_) | | / // _ \ '__/ _ \ | |_| | | | (_| | | | | (_| | __/ | __/| | / /| __/ | | (_) | \___/|_| \__,_|_| |_|\__, |\___| |_| |_| /____\___|_| \___/ |___/ Welcome to ARMBIAN 5.35 user-built Ubuntu 16.04.3 LTS 4.13.16-sunxi System load: 0.07 0.02 0.00 Up time: 3:15 hours Memory usage: 10 % of 493MB IP: xx.xx.xx.xx CPU temp: 40°C Usage of /: 3% of 233G [ 0 security updates available, 8 updates total: apt upgrade ] Last check: 2017-11-26 00:00 [ General system configuration (beta): armbian-config ] Last login: Wed Nov 29 09:38:35 2017 from x.x.x.x This is what I see at login. Omg.. someone switched the baby at birth maybe?? I have to wait a few days for the test as I'm waiting a shipment with an microSD card... 0 Quote
lagerschaden Posted November 29, 2017 Posted November 29, 2017 as the Orangepi One has the same connector as the Orangepi Lite https://linux-sunxi.org/Xunlong_Orange_Pi_One_%26_Lite I supposed it SHOULD run. BUT: there ist an error with from pyGPIO.gpio import gpio, connector, same problem with port instead of connector pi@pi-one:~/pyGPIO$ python Python 2.7.9 (default, Aug 13 2016, 17:56:53) [GCC 4.9.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import os, sys >>> from pyGPIO.gpio import gpio, connector Traceback (most recent call last): File "<stdin>", line 1, in <module> File "pyGPIO/gpio/connector/__init__.py", line 5 import < Something > ^ SyntaxError: invalid syntax >>> 0 Quote
lagerschaden Posted November 29, 2017 Posted November 29, 2017 next problem: runs only as root if not os.getegid() == 0: sys.exit('start script as root') 0 Quote
zador.blood.stained Posted November 29, 2017 Posted November 29, 2017 /etc/armbian-image-release and /etc/armbian-release are different files and have a different purpose. The former was added to track the source image version in case of upgrades, kernel switches, etc., it won't be present on many older images so it shouldn't be used for platform identification. 1 Quote
chwe Posted November 29, 2017 Author Posted November 29, 2017 (edited) 50 minutes ago, zador.blood.stained said: it won't be present on many older images so it shouldn't be used for platform identification. Thanks for pointing it out! I'll fix it today. --> fixed 1 hour ago, lagerschaden said: BUT: there ist an error with from pyGPIO.gpio import gpio, connector, same problem with port instead of connector pi@pi-one:~/pyGPIO$ python Python 2.7.9 (default, Aug 13 2016, 17:56:53) [GCC 4.9.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import os, sys >>> from pyGPIO.gpio import gpio, connector Traceback (most recent call last): File "<stdin>", line 1, in <module> File "pyGPIO/gpio/connector/__init__.py", line 5 import < Something > ^ SyntaxError: invalid syntax >>> 1 hour ago, lagerschaden said: next problem: runs only as root if not os.getegid() == 0: sys.exit('start script as root') See: 4 hours ago, chwe said: The lib needs sudo right at the moment. It's on my todo list to figure out what's exactly needed to run it without sudo (I've a lot of other todos so no guarantee that this is solved immediately ). 3 Edited November 29, 2017 by chwe 1 Quote
lagerschaden Posted November 29, 2017 Posted November 29, 2017 The problem seems to access /dev/mem, crw-r----- 1 root kmem 1, 1 Nov 28 22:17 /dev/mem If you change the group or add normal user to group kmem nothing changes -> you must be root to access. Also if you chmod /dev/mem to 0777 -> you must be root. Perhaps the makers of armbian can change something here. 0 Quote
lagerschaden Posted December 4, 2017 Posted December 4, 2017 I found a method to access gpio without root privileges, look here 0 Quote
jscax Posted December 4, 2017 Posted December 4, 2017 4 hours ago, lagerschaden said: I found a method to access gpio without root privileges, look here yep https://github.com/rm-hull/OPi.GPIO this library do that but in my experience need to be patched ( ) with the "sleep" hack to work. 0 Quote
chwe Posted December 17, 2017 Author Posted December 17, 2017 Initial support for pcDuino3 (not tested, cause I don't own the board): Pinmapping differs from other, cause no 'RPI compatible' pinheader: Edit: there was a mistake on some 40pinheader (e.g. OPiPC plus) boards which ended in an error during installation (forgot an }, ). --> fixed 0 Quote
lagerschaden Posted September 2, 2018 Posted September 2, 2018 On 12/4/2017 at 10:43 AM, lagerschaden said: I found a method to access gpio without root privileges, look here It also runs on Armbian 4.14.18 and 4.14.65 with no root privileges, but you must change the file # /etc/udev/rules.d/97-gpio.rules SUBSYSTEM=="gpio*", PROGRAM="/bin/sh -c '\ chown -R root:gpio /sys/class/gpio && chmod -R 0770 /sys/class/gpio &&\ chown -R root:gpio /sys/devices/platform/soc && chmod -R 0770 /sys/devices/platform/soc'" add a group gpio and make the user member of this group, then reboot 0 Quote
karl Posted September 16, 2018 Posted September 16, 2018 Hi, I am trying to do 4 bytes write / 4 bytes read to a pic. the first write/read goes ok, the second gets Error in 'usr/bin/python': double free or corruption (fasttop): 0xb4c00738. next try it gets 0xb4c00750. Third try gets Fatal Python error: GC object already tracked. I run ARMBIAN 5.38 stable DEBIAN GNU/Linux 9 (stretch) 4.14.18-sunxi on a orange pi zero h2+. Python is 2.7.13. any ideas how to fix this? thanks 0 Quote
David Hampson Posted September 30, 2018 Posted September 30, 2018 Just adding that I have got this working on a pcduino 3. I used the port option as I wasn't sure what the connector names are - see below. Is it possible to view the available ports and connectors? import os, sys if not os.getegid() == 0: sys.exit('start script as root') from pyGPIO.gpio import gpio, port from time import sleep gpio.init() gpio.setcfg(port.GPIO0, 1) gpio.output(port.GPIO0, 0) sys.exit('finished ;-)') On 12/18/2017 at 6:09 AM, chwe said: Initial support for pcDuino3 (not tested, cause I don't own the board): Pinmapping differs from other, cause no 'RPI compatible' pinheader: 0 Quote
chwe Posted September 30, 2018 Author Posted September 30, 2018 1 hour ago, David Hampson said: Is it possible to view the available ports and connectors? (J11) (J12) GPIO0 (UART2_RX) |·| |·| A0** GPIO1 (UART2_TX) |·| |·| A1** GPIO2 |·| |·| A2** GPIO3 |·| |·| A3** GPIO4 |·| |·| A4** GPIO5 |·| |·| A5** GPIO6 |·| (J9) GPIO7 |·| |·| 5V (J8) |·| GND GPIO8 |1| |·| GND GPIO9 |·| |·| 5V GPIO10 (SPI_CS) |·| |·| 3.3V GPIO11 (SPI0_MOSI) |·| |·| RESET GPIO12 (SPI0_MISO) |·| |·| IOREF GPIO13 (SPI0_CLK) |·| |·| NC GND |·| AREF |·| GPIO18* (TWI2_SDA) |·| GPIO19* (TWI2_SCL) |10| (P10) GPIO15 |·||1| GPIO14 GPIO17 |4||·| GPIO16 more or less all others have a 'RPi-a-like' pinheader.. so here connectors would be named J8,J9,J11,J12 &P10 (according to schematics) and numbering according to its place.. see there: https://github.com/chwe17/pyGPIO/blob/master/pyGPIO/gpio/mapping/pcduino3.h 0 Quote
TonyMac32 Posted December 9, 2018 Posted December 9, 2018 Bumped/Pinned like the others. If I'm going to be in the trenches on these boards, may as well make it count. I want to see this, circuitpython, Larry Bank's and sgjava's libraries all in a subforum (and any I'm missing, authors step forward and be counted. ;-) Also @chwe tossed you a PR for Tritium H2+/H3 and your own Blinky example. 1 Quote
chwe Posted December 10, 2018 Author Posted December 10, 2018 10 hours ago, TonyMac32 said: Also @chwe tossed you a PR for Tritium H2+/H3 and your own Blinky example. I may need a more maintainable mechanism to add new boards... It's currently a hacky solution.. 0 Quote
TonyMac32 Posted December 10, 2018 Posted December 10, 2018 1 hour ago, chwe said: I may need a more maintainable mechanism to add new boards... It's currently a hacky solution.. hmmm, I've seen worse. You could replace the manual override part with a "name your board file", is my first idea... 0 Quote
papahippo Posted August 5, 2019 Posted August 5, 2019 I am trying to use this on an OrangePiOne. I understand that this isn't supported but I had hoped that if I 'lied' and entered 1 (=Orange PiZero) I'd get a consitent module albeit with wrong pin numbers. But it leaves with an unusable 'connector' and 'gpio'. I'm prepared to do some development to support the OrangePiOne if you like.... It isn't immediately clear where to insert the necessary 'tweaks' but if I give it some effort I can find out. Larry Myerscough 0 Quote
Igor Posted August 5, 2019 Posted August 5, 2019 25 minutes ago, papahippo said: consitent module albeit with wrong pin numbers https://linux-sunxi.org/Xunlong_Orange_Pi_One#Orientation_of_the_GPIO_header 0 Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.