Help, I am new to TX2 and have zero experience with python, can I please get an example code that works with the GPIOs. I am in a time crunch, any example would be very helpful
Here’s a nice tutorial showing how to use GPIO on the TX1
Here’s a reference which shows the pinout for J21 when using a TX2 (as opposed to TX1 above):
Here’s a link showing how to use gpio pins from the linux command line:
Python GPIO library:
Hello I am new with tx2 and linux OS
Could you tell us how can we use the repo in git hub to control a gpio with python?
For example how can I set gpio255 to turn on and turn off with this library?
Thanks for your help everybody
Hey there, Im guessing you figured this out by now but I thought I would add a little tutorial for those who might need help in the future. I don’t know why the readme from git hub doesn’t have the install instructions… here is what I did.
In the terminal:
$ cd $ git clone https://github.com/vitiral/gpio.git $ cd gpio/ $ sudo python3 setup.py build $ sudo python3 setup.py install
This installs the library to /sys/class/gpio (in case your are looking for it). I suppose this could be different for you. Check it by running python3 term: “import gpio; gpio.gpio_root”
After that run the gpio test script.
$ cd tests/ $ python3 test_gpio.py
Im not totally sure what the script actually does, seems like all it does is import some stuff. If the install is successful there will be no output.
The readme includes the commands you can run. Here is an example.
In a bash term enter: “sudo cat /sys/kernel/debug/gpio” to see the currently enabled sysfs GPIOs. The last section “… tegra-gpio:” is where the gpios we want will show up.
To run some of the commands you need to have root privileges, so start a terminal with “sudo python3”:
import gpio >>> gpio.setup(396,gpio.OUT) #this will setup J21 pin 7 as an output pin. If you rerun "sudo cat /sys/kernel/debug/gpio" you will now see gpio-396 listed as "out lo" >>> gpio.set(396,1) # rerun "sudo cat /sys/kernel/debug/gpio" you will now see gpio-396 listed as "out hi" and if you put a volt meter you will see hi on pin 7 of the j21 header >>> gpio.output(396,0) # this also works to drive pins >>> gpio.mode(396) # this shows the current pin mode 'out' right now >>> gpio.setup(396,gpio.IN) # set the pin to input mode >>> gpio.mode(396) # confirms this >>> gpio.read(396) # reads the pin value, I don't think this library does anything with pullup of pull down resistors... >>> gpio.input(396) # does the same thing >>> val = gpio.input(396) >>> type(val) # <class 'int'> so you need to use typecasting if you need something else. >>> gpio.cleanup(396) # closes and unexports the pin. Returning it to the system.
I noticed that if you use “gpio.output(396)” before gpio.setup(396) a you get a PermissionError, but if you use "gpio.input(396) before setup it will create the pin and get values from it, but the values are incorrect and no exception is thrown! Moreover, if you then try to do gpio.cleanup(396), or any other command excetp gpio.input(), you will again get the PermissionError. You need to setup the pin using gpio.setup in order to use it properly again. So watch out for this and make sure you use gpio.setup() first for every pin.
This library requires root privileges to use. This is because it is updating the values in system files. Scripts will need to be run with sudo python3 script.py. There is probably a way to embed root privileges in scripts but I havent used it before.
This is not the fastest way to set pins, but it is simple. I could drive a ~1 KHz square wave using a Jetson TX2.
I am having issues with using the GPIO pins in 3.3v mode. When driving pins from high to low or low to high they get stuck at 1.56 vdc and don’t respond any more. If I pull the pin on j24 and put it back, the value goes to what it should be set to (0v or 3.3v), but then if I drive another transission it agian gets stuck at 1.56v. By setting j24 to the 1.8v setting everything works properly, so I’ve been doing testing set like this.
There are also some other methods in the gpio library which I have not experimented with yet, look through the gpio.py file of type gpio. to see the others, but the above should get you going.
I pulled out a RaspberryPi Zero W that I had laying around to do some GPIO speed testing. I had previously overclocked the RPi to 1GHz (whow blazin!). I wanted to compare GPIO speed capability to JetsonTX2. On the jetson I was sure to run “sudo nvpmodel -m 0” and then “sudo jetson_clocks” before testing (for max clock speed).
Using a simple infinite while loop to drive a clock signal I got the following speed results for the two devices with various languages/libraries.
Device Language Library Frequency RPi Python3 GPIO 66.8 kHz RPi Python2 GPIO 100.3 kHz RPi C++ -O3 wiringPi 6.0 MHz RPi C++ wiringPi 6.3 MHz JetsonTX2 Python3 gpio 1.78 kHz JetsonTX2 Bash sysfs 4.9 kHz JetsonTX2 C++ -O3 fstream 10.9 kHz JetsonTX2 C++ fstream 10.7 kHz
I don’t think I’m alone when I assert that these results are disappointing. I’m guessing that the bottleneck comes from writing to system files, and then waiting for the kernel to do its thing. I’m pretty sure the python gpio library ultimately goes through sysfs in this way. I looked into the C++ library provided by jetsonhacks.com, but it looks like it just passes commands out to bash from C++, so I don’t think it would be any faster.
Is there a faster way to do this? Can we directly control the GPIO registers like on RPi?
Edit: added Jetson TX2 c++ fstream results.
Hello,Recently I need to use GPIO port to connect with Altera GPIO with 3.3V
and I need five port. I am wondering how to know which port I could use.
I need 3.3v pin.
If GPIO 388 398 389 298 is capable?
@joel.reindel thank you for your answer.
I found a library call periphery https://pypi.org/project/python-periphery/
and its very similar the way you use the one in your example.
@vegetableclean, the short answer is I’m not exactly sure. You should be able to do some experimentation with a volt meter to find out.
The long answer: Near as I can tell from the “quick start” type materials any of the GPIO on J21 should be capable of 3.3v operation. However, once I began to dig through the technical resource manual I found outlines of some gpio being 1.8v only and some being selectable. This was describing all gpio system wide, not just the ones which come out at J21. So, all GPIO are capable of 1.8v, some are capable of 3.3v, and maybe all the GPIO on J21 can do 3.3v.
The safest bet would be to use any pins, set to 1.8v, and then use an external level shiftier to convert the 1.8v to 3.3v and vice-versa. Here is one from sparkfun for example (https://www.sparkfun.com/products/12009) and adafruit (https://www.adafruit.com/product/757); the Ti SN74LVC245AN (https://cdn-shop.adafruit.com/datasheets/sn74lvc245a.pdf) looks like it could do the job as well.
I haven’t looked at the specific GPIO you are looking at (I’m not commenting on any particular GPIO), but the dev carrier board has a jumper selectable level translator between 1.8V and 3.3V on the GPIO which go to the header pins. J24 (the 3.3V/1.8V select) sits next to J21 right at the corner of the carrier board. Document labels for the module will always list 1.8V, but documents for the header pins might show 3.3V or selectable.
What is the python instruction to send data on gpio(serial uart) pin with specific baudrate.
How can I use this GPIO library without root privileges?
Were you ever able to find a solution to the voltage issue that you saw with the output of the J21 pins? I am having the exact problem and it is quite frustrating! When J24 is set to 3.3V, the voltages get stuck around 1.5V, and the only way for me to make them become what they should be is by removing and reconnecting my multimeter to the pin.
Im not sure there is a way to use GPIO without root privileges. The most “primitive” way is to edit the system files. The GPIO library I used edits the system files, and therefore requires system privileges.
I never did find a solution. It wasn’t really part of what I was working on. If I were to need the GPIO pins for something, I would have likely bought or built an external level shifter like I described above.
“The safest bet would be to use any pins, set to 1.8v, and then use an external level shiftier to convert the 1.8v to 3.3v and vice-versa. Here is one from sparkfun for example (https://www.sparkfun.com/products/12009) and adafruit (https://www.adafruit.com/product/757); the Ti SN74LVC245AN (https://cdn-shop.adafruit.com/datasheets/sn74lvc245a.pdf) looks like it could do the job as well.”
@electric27: See response to https://devtalk.nvidia.com/default/topic/1038616/jetson-tx2/tx2-gpio-is-not-working-/post/5373927/#5373927 (it can be hard to track multiple threads…that’s the one I saw first).
I need to configure and read gpio pins using java program…does anybody know.
The files you see in demos of changing GPIO through echo of text to somewhere in “/sys” are just ordinary file operations. Check out the various tutorials and examples using “echo”, and then just duplicate this with a Java println to that file. Other than needing root permission (sudo) these are just ordinary file i/o.
Is that means I can user pin E1 and E2 pin as GPIO?
Conn. Pin # | Carrier Board Symbol Pin Name | Carrier Board Net Name | Tegra X2 Pin Name
E1 | FORCE_RECOV# | FORCE_RECOVERY_L | GPIO_SW1
E2 | SLEEP# | SLEEP | GPIO_SW2
I couldn’t say if those pins are mapped to “/sys” (I do not know). However, if the pins are exported to “/sys”, then yes, you could use them (one other prerequisite is that nothing else already uses them). You would need root privilege if working through “/sys” to do so.
Yes. Both of these pins can be used as GPIOs. Since these pins are also used as recovery straps and have critical meaning at power on reset, it is best to use these as GPIO outputs and not inputs. If you wanted to use them as inputs, you would need to tri-state them externally at reset to ensure the proper state.
Here are the pin/gpio mappings:
E1 => FF.01 => GPIO #313
E2 => FF.02 => GPIO #314
If you are using the default Device Tree with the TX2 dev kit, you will need to make sure you remove them from the existing gpio-keys section (i.e., volume_up/down) in the dtsi before you can access them via /sys/class/gpio.