Jump to content

Recommended Posts

Posted

What is the process to get python3 talking to the GPIO pins?  I have installed the ASUS-GPIO package but it is not working.  Under the tinker debian release, this h/w was working correctly, so I know this is some kind of s/w issue.

 

Thanks!

Posted

Linux durango 4.11.6-rockchip #9 SMP PREEMPT Fri Jun 23 20:37:25 CEST 2017 armv7l armv7l armv7l GNU/Linux

 

I'm not getting any errors, it is just not working.  I will get out the scope tomorrow and conduct some debugging and update you.

 

I downloaded the ASUS_GPIO instructions on the tinker board website for a python install.  Was this correct?

 

Posted

Here is a code snippet of the program I am using:

 

#!/usr/bin/python3
import ASUS.GPIO as GPIO
import time
relay_gpio_pin = [7,8,10,11,12,13,15,16,18,19,21,22,23,24,26,27]

GPIO.setwarnings(False)
GPIO.setmode(GPIO.BOARD)
for pin in relay_gpio_pin:
   GPIO.setup(pin,GPIO.OUT)
   GPIO.output(pin,GPIO.HIGH)       # Turn relay off

for pin in relay_gpio_pin:
   time.sleep(0.025)
   GPIO.output(pin,GPIO.HIGH)
   time.sleep(0.025)
   GPIO.output(pin,GPIO.LOW)

 

The above code worked correctly running on the same Tinker Board with the Tinker OS 1.8 and 1.9.  Now under the armbian it no longer works.   Thinking it might be the relay board, I put some led's on the GPIO pins and manually turned in pins 7 and 11, I could never turn them off with the Python statement: GPIO.output(11,GPIO.LOW). 

 

I followed the following steps to install the python ASUS.GPIO code (as root):

apt-get install python3-dev

wget http://dlcdnet.asus.com/pub/ASUS/mb/Linux/Tinker_Board_2GB/GPIO_API_for_Python.zip

unzip GPIO_API_for_Python.zip
cd GPIO_API_for_Python/

python3 setup.py install 

Posted

I have not tried the 4.4 of the 4.12 Kernels, would you like for me to?  What is the repo for the nightly 4.12 kernel?

Posted

There's your legacy armbian:P Why not burn it to a SD-Card and try it by yourself? @TonyMac32 nor armbian gets money for the work & support which they give for the tinker board (in case of armbian you can change it by donate to the project). IMHO working with you instead of working for you is how it should work. 

lecacy.thumb.jpg.6f15a1274e09ee303597e324d013af7d.jpg

Posted

It's just compatibility with 3rd party libraries that can't be guaranteed since it's the userspace library problem to ensure compatibility with different kernels.

I presume that GPIO via the sysfs interface works the same on all kernels.

Posted

Right, I was just making sure everyone was on the same page, especially since the 4.11 kernel is eol and the hardware support on Tinker was less than complete.  (Partially the kernel's fault, partially the speed I've been able to roll out changes)

 

I also need to take a look and make sure I didn't have https://github.com/rockchip-linux/kernel/issues/15

 

Going on, I never specifically looked at it, it could be the issue.  Checking tonight.

Posted

I just noticed that the 3.3 GPIO pin is at 4.98 volts when running under the 4.11 and 4.12 kernels.  When I booted under Debian 1.9 I saw 3.25 volts on the 3.3 GPIO pin.  The 16 post relay board I am using wants 3.3 volts to signal the logic board as 12 volts to power the relays.  

 

Could this be the issue as to why my relays are now working correctly?

Posted

Now that is interesting.  Let me take a look. which physical pin in particular?  The 3.3 volt supply?

 

I'm getting 3.3 on all pins...

Posted

Strange, I've got a solid 3.3 on that pin.  Is there anything else plugged in, and can you check the voltage on any of the other GPIO pins?  They all feed from VCC33IO. 

 

[edit] Checked 4.12 and 4.13 kernels, 3.3 Volts on both.

Posted

The relay board was pulling the 3.3 volt line to 4.98.  Disconnected the relay board and re-confirmed pin 1 is now 3.25. 

Posted

For industrial purposes I would recommend opto-isolating quite literally everything, and having the opto-isolators in DIP sockets for easy replacement in case of fire. For power, "Ideal Diode" circuits using a FET are useful as well to prevent back-feeding. This is a general rule of thumb for me at work, it also allows level shifting without much difficulty.  I have an application where I need to switch from 9 to 24 volts as part of a communication protocol to a special sensor, and the opto-isolators made it a breeze.

Posted

Thanks a great idea, thanks!  Could you share some of the chips you are using to give me a starting point?

Posted

http://www.vishay.com/docs/83725/4n25.pdf

 

This series is the "garden variety", basically made by everyone.  Pay attention to speeds, if you're doing high-speed communications stuff these will have a detrimental effect.

 

Ideal diode circuits are something you can do yourself, or buy prepackaged:  http://www.linear.com/product/LTC4358

 

They aren't the cheapest, but can keep everything happy (say you power your Tinker from the GPIO then plug in the OTG connector.  The two supplies can "fight" if they aren't at the same level.)

Posted

Hello,

I am trying to use GPIO in c and with wiringPi. I use GPIO_API_for_c. I can't pilot pins from my current user count.

I need to be root to use it. And even this is not evident when I try to use

Whatever I find on the web and test, nothing seems to work.

Otherwise if I do this sequence I obtain weird result:

 

nafa@tinkerboard:~$ sudo su
root@tinkerboard:/home/nafa# echo 167 > /sys/class/gpio/export
root@tinkerboard:/home/nafa# echo in > /sys/class/gpio/gpio167/direction
root@tinkerboard:/home/nafa# gpio readall | grep 167
 | 167 |   3 | GPIO5B7 |   IN | 0 | 15 || 16 | 0 | IN   | GPIO5B2 | 4   | 162 |
root@tinkerboard:/home/nafa# echo out > /sys/class/gpio/gpio167/direction
root@tinkerboard:/home/nafa# gpio readall | grep 167
 | 167 |   3 | GPIO5B7 |   IN | 0 | 15 || 16 | 0 | IN   | GPIO5B2 | 4   | 162 |
root@tinkerboard:/home/nafa#

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

Important Information

Terms of Use - Privacy Policy - Guidelines