I’m trying to use the Jetson GPIO library package from:
However, after following all the steps in README.md, I’m still unable to run the examples inside the samples folder or to import the Jetson.GPIO inside the python3 terminal. I even tried to reboot and reflash with JetPack 4.2 in order to try a fresh installation.
The same error always pops up in terminal:
No such file or directory: ‘/sys/devices/3160000.i2c/i2c-0/0-0074/gpio’
I dug a little deeper and saw that only the gpio file/directory is not there. Could not understand why it is not where it is supposed to be and how to solve the issue.
Appreciate some insights.
Jetson TX2 with Auvidea J120 board
JetPack 4.2
PS: I’ve followed the same steps in my Jetson Nano board and the library is working.
I can’t answer the specific question, but all files in “/sys” are pseudo files and exist only in RAM. The files are a result of specific kernel drivers. Either the driver is not loaded, or the configuration of the driver is such that the directory is never created.
Part of setting up an alternate carrier board is using a new device tree. Device tree is in effect a way to provide custom settings to the kernel. It is quite possible that a failure to correctly adjust device tree to that of the current carrier board (the Board Support Package for the carrier board would do this) is the cause. I know nothing about that carrier board, but I’d look closer at whatever BSP is provided by the manufacturer for use with JetPack4.2. I am guessing that your Nano is not using a custom carrier board.
You can use ordinary file i/o, e.g., print a text line to a file (“/sys” requires you to run as root, although a udev rule could be used to change those permissions). You’d have to figure out which files in “/sys” are the correct ones (many of the details have changed over various releases, but the methods remain the same).
Other than special i/o control calls (an “IOCTL”) everything in Linux is basically a file (you won’t need to worry about an IOCTL call with simple read or write operations). “stdin” is a file descriptor operation, “stdout” is a file descriptor operation, “stderr” is a file descriptor operation. Files in “/sys” are not real files, they are actually drivers, but in many cases you can read or write to those as if they are ordinary files (if you have permission…something sudo is good for…but a more advanced concept is to use “udev” to change permissions. Regular files can simply have permissions changed directly, but files which are not “real” files typically interact with a driver and need an alternative mechanism to change permissions (not needed if you can run as root, e.g., with “sudo”); “udev” is a rule based modifier for various devices.
“echo something > /some/file” is a file write. “cat /some/file” is a file read.
I probably can’t answer your question directly, but unless there is more information on the program, any error message, whether this is a custom carrier board, the L4T release (see “head -n 1 /etc/nv_tegra_release”), so on, nobody will be able to answer.
You would need to flash with the board support package (“BSP”) from the manufacturer of the Orbbity (one which matches the JetPack/L4T release). Mostly this is the device tree.
Basically, each file in “/sys” is not a real file, but is instead a reflection of some interface directly with the driver. The driver uses the device tree to accommodate different wiring schemes of different carrier boards, and so if the driver cannot find the hardware correctly, then the file will not exist.