I am trying to digest all of the stuff like “mraa”, “gpiod”, and C++ routines in trying to understand how to make the Zero 3W’s gpio pins available to Python3. There is a lot of info but it seems like what I’ve tried doesn’t pertain to the Zero 3W, but to the other Rock based boards. It seems like everything else I’ve tried hangs the Zero, is invalid in Python, invalid in the terminal, or just plain doesn’t work. Is it me or is this a general problem? We newbies really need some help from the experienced Zero users in how to get to the gpio commands for Python or at least point us to the right direction. I don’t know of a book that clearly explains the gpio pins versus Python3. If there is, where can I buy it? I am really starting to miss my old RaspberryPi Zero.
Latest gpio handling from within Python3
Radxa Zero 3W is relatively a new board and a different board from Zero. Not everything has been ported to it.
I think if you read the forum you get some info about “mraa” on new boards and how to fix some problems.
Start describing in detail what you are doing first then you get some answers.
Thanks for your reply!
I am trying to accomplish 2 things on the Zero 3W:
1. using python3, just trying to learn how to drive a gpio pin high and/or low. I can now do it from the terminal using “gpioset --mode=time -s 1 3 5=0” (for setting board Pin40 to low or 5=1 for high). But I haven’t yet discovered how to do this within python3.
2. I want to be able to monitor internal chip temperatures (if possible) in order to use PWM to drive a case cooling fan from a GPIO pin using Python3 code.
3. actually there is a 3rd thing… I am just trying to keep my head above water in trying to learn how use Python3 vs Zero 3W. I have written some nice GUI stuff for the RaspberryPi and for use on my Microsoft Surface Pro in Windows, but struggling to get there with the Zero3W. It will happen after much late night keyboard stumbling and a lot of coffee.
Thanks again for your reply
That sounds good, if you can share the code somewhere, there are experts here who will help port it to 3W. Unfortunately, I can’t help with python.
-
Find some python examples of other Rockchip platforms, like Rock 3A, they are compatible to some extent.
-
Monitoring Chip temp.
Just read the value (using Python or any other language) from this location here:
Example:
64444 = 64444 / 1000 = 64 C (Celsius)
OK, after much studying and trying broken ideas, I was finally able to come up with this. It isn’t the best way, I’m sure, but at least it works and I’ve gotten this far.
I have a RGB LED hooked up to Zero 3W pins 37, 38 & 40 (using a 560 ohm resistor) and Gnd to Pin 39.
Using the “subprocess” import within Python, I can call out sudo commands from within Python to make thus work.
Here is the Python3 code:
#*******************************************************
program = “try_subprocess.py”
version = “240229 1611”
print(“program:”, program, “Version:”, version)
import time
import gpiod
import subprocess
Blu_ON = “gpioset --mode=time -s 1 3 6=1”
Blu_OFF = “gpioset --mode=time -s 1 3 6=0”
Grn_ON = “gpioset --mode=time -s 1 3 5=1”
Grn_OFF = “gpioset --mode=time -s 1 3 5=0”
Red_ON = “gpioset --mode=time -s 1 1 4=1”
Red_OFF = “gpioset --mode=time -s 1 1 4=0”
print (“starting program”)
print(“trying RED Pin37”)
time.sleep(1)
try:
print (Red_ON)
subprocess.run(Red_ON, shell = True, check = True)
time.sleep(3)
print(" RED ON ok?")
except subproccess.CalledProcessError as e:
print(“Red-ON error”)
time.sleep(3)
try:
print (Red_OFF)
subprocess.run(Red_OFF, shell = True, check = True)
time.sleep(1)
print(" RED OFF ok?")
except subproccess.CalledProcessError as e:
print(“Red-OFF error”)
time.sleep(3)
print(“trying GREEN Pin38”)
try:
print (Grn_ON)
subprocess.run(Grn_ON, shell = True, check = True)
time.sleep(3)
print(" Green ON ok?")
except subproccess.CalledProcessError as e:
print(“Grn_ON error”)
time.sleep(6)
try:
print (Grn_OFF)
subprocess.run(Grn_OFF, shell = True, check = True)
time.sleep(1)
print(" Grn OFF ok?")
except subproccess.CalledProcessError as e:
print(“Grn_OFF error”)
time.sleep(3)
print(“trying BLUE Pin40”)
try:
print (Blu_ON)
subprocess.run(Blu_ON, shell = True, check = True)
time.sleep(12)
print(" Blue ON ok?")
except subproccess.CalledProcessError as e:
print(“Blu_ON error”)
time.sleep(3)
try:
print (Blu_OFF)
subprocess.run(Blu_OFF, shell = True, check = True)
time.sleep(1)
print(" Blu OFF ok?")
except subproccess.CalledProcessError as e:
print(“Blu_OFF error”)
time.sleep(3)
print(“end of test”)
#****************************************************8
After Pin37 apparently stopped working, I switched to a 1Kohm resistor for the LEDs and Pin 36. Will research Pin 37 later.
Radxa Zero 3W is relatively a new board and a different board from Zero. Not everything has been ported to it.
That’s not completely true. It uses RK3566 SoC, which is well-known from the 3C and very similar to RK3568 from the 3A. And they’ve been around for a longer while.
Using the “subprocess” import within Python, I can call out sudo commands from within Python to make thus work.
Dear God. Please don’t do it that way…
I’ve done a lot of research and trial-and-error about using gpiod for my engineering thesis/project last month, because I needed external interrupts on my 3A. Things work very similarly on different boards.
Here. I wrote a basic “blink” example for you. It uses pin 40 which is chip 3 line 5.
import gpiod
from time import sleep
chip_number = 3
line_number = 5
with gpiod.Chip(f"/dev/gpiochip{chip_number}") as chip:
settings = gpiod.line_settings.LineSettings(
direction = gpiod.line.Direction.OUTPUT
)
config = {
line_number: settings
}
lines = chip.request_lines(config=config)
try:
while True:
lines.set_value(line_number, gpiod.line.Value.ACTIVE)
print("Pin state HIGH")
sleep(1)
lines.set_value(line_number, gpiod.line.Value.INACTIVE)
print("Pin state LOW")
sleep(1)
except KeyboardInterrupt:
lines.set_value(line_number, gpiod.line.Value.INACTIVE)
print("Done.")That’s not completely true. It is RK3566-T
and “and a different board from Zero.”
Zero uses Amlogic S905Y2 64bit processador quad core
Okay? What rock did you crawl out from under to be this picky about minor details?
Personally? Nothing makes me more furious than such behavior.
and “and a different board from Zero.”
Zero uses Amlogic S905Y2 64bit processador quad core
You’re literally countering the only part that I had never been even referring to in the first place. Yes, it’s true, but that is completely irrelevant when it comes to my response.
Did you really expect me to break the quote just to get rid of that part about the original Zero? I’m still right about everything else here.
Maybe try to keep your responses within the boundaries of a given topic?
But fine. Wanna have a precision war? I can play that game.
That’s not completely true. It is RK3566-T
That’s not completely true. The “-T” is nowhere to be found in the specs - not the product page, not the docs, not the Allnet China page, not the OKdo page. It also doesn’t show up on Google. But that doesn’t even matter. Wanna know why?
Because if it’s the same naming convention as RK3399 and RK3399-T then this hypothetical RK3566-T of yours at most has its frequencies lowered a bit.
Architecturally the RK356X family is basically all the same thing except for some additional features like communication buses. Even line numbering is mostly the same between Radxa boards in this case (yes, there are some minor differences, but ultimately that changes nothing).
And when it comes to the usage of GPIO everything is also almost the same thing.
Are you even aware of the fact that manufacturers re-use parts of their designs wherever and whenever they can?
Anyway… I’m sure you’re gonna read this whole thing the wrong way and wrongly believe that I’m saying that RK3566 and S905Y2 are the same thing. At that point I’m literally gonna delete my account from frustration.
Really? You threw the stone first, and when it bounced back and hit your forehead, it hurt, huh?
Yeah, we know you are right. I’m having some fun not a fight.
Really? You threw the stone first, and when it bounced back and hit your forehead, it hurt, huh?
Nothing bounced back and nothing hurt.
I literally provided the answer on the topic while you kept babbling about unrelated stuff.
Apparently SoC model numbers are more important to you than actual solutions.
Get your priorities straight or go back to the first grade to learn logic and reading comprehension because you apparently need to be re-educated in those areas. Have fun re-posting model numbers all over this forum. Cheers.
Shadow and Ninja, please don’t feud… I appreciate the help from both of you and don’t want to lose that.
On the import of gpiod, for some reason gpiod won’t import in my Python… "no module named ‘gpiod’
I tried using apt-get, apt, and pip but can’t get any loading of libgpiod. Don’t know yet what I am doing wrong.
I’ll gladly continue assisting you here. Did you install your packages properly?
First you need the library files from apt and then the bindings from pip.
If I remember correctly the bindings need to build themselves after being downloaded from pip.
Make sure you have the following packages installed:
sudo apt install python3-dev libgpiod-dev
And then install the Python module.
I don’t like using the pip command because it sometimes messes up which interpreter to install to.
So try this way:
python3 -m pip install gpiod
If you encounter any problems please post the output (e.g. from pip).
Worst case scenario I’ll make a clean install on one of my boards and check if there’s any steps missing.
AHH HAA!!
Thanks, Shadow…
I completely reloaded a new image of Debian ECF B6 and reloaded Python stuff per your instructions and ran your “gpiod” program of a few days ago and it runs perfectly and much, much faster than my “subprocess” program.
I appreciate your help. Now, I’ll have to digest each step of the program so that my brain understands how and why it all works. Plus, I’ll expand my efforts to include learning the GPIOD inputs and the communications using UARTS, I2C, and SPI works on the Zero3W. I plan on hooking it up to a Microchip PIC18LF67K40 microcontroller as it is my favorite Microchip to develop monitor and control systems.
I’ve already done this with the various RaspberryPi models except the Zero.
Next, I’ll study up on the inputs, communications, and reading Zero3W system internals to monitor temps, speeds, memory, and such.
One more thing… I am at a loss (apparently like everyone else) to load an image onto the eMMC for eMMC booting. But can I still read/write to the eMMC for things like creating accessible folders for python files, images (png, gif type), and documents. How can I tell which file folders are on the eMMC or on the SD card without the constant install/deinstall of SD cards to see what goes away.
Thanks again, you’ve helped me to partially unlock some of the secrets of that “combination lock” called the Zero3W. Any recommendation for a good reference book?
ran your “gpiod” program of a few days ago and it runs perfectly and much, much faster than my “subprocess” program
Yeah. Using subprocess was kind of a terrible idea, haha.
I’m glad that my solution works for you.
By the way, that “run” flag that I left in the code is completely unnecessary.
It’s just a remnant that was in my mind after doing a lot of threading-related coding.
I’ll edit the code later, but you can just ignore that part for now because it’s a pretty minor thing.
If I’m to be honest, understanding how gpiod is conceptualized took me a longer while.
But once you get used to the general ideas, it gets easier.
I’ll expand my efforts to include learning the GPIOD inputs and the communications using UARTS, I2C, and SPI
When it comes to the communication interfaces, I don’t think gpiod supports working with that.
You can use pyserial for UART and smbus2 for I2C… Probably…
I don’t know about SPI since I never use it.
reading Zero3W system internals to monitor temps, speeds, memory, and such.
I’m sure there was a Python module for that already that taps into what the OS already knows…
Can’t remember at the moment though.
I am at a loss (apparently like everyone else) to load an image onto the eMMC for eMMC booting
Yeah… Mine doesn’t want to enter maskrom mode for some reason. I don’t know how others have it.
How can I tell which file folders are on the eMMC
Not sure here. Need someone who’s better at Linux here. Most likely there’s a way print out what storage device is related to what mountpoint and then judge from that.
Any recommendation for a good reference book?
No, sorry. I wish there were good books about these things too, but most of the ones that are available where I live are platform-specific. And they probably aren’t available abroad anyway.
Thanks for your response. I think I’ll post a new topic on the forum to ask the eMMC questions about booting and storage.
Shadow,
I have leveraged the gpioset info you provided into learning more about gpiod and I can now do gpiogets (not yet mastered “as-is” option)… thanks again.
Also, I did post a new topic on the eMMC that might draw some interest and some answers.
regarding the eMMC files and directories… I loaded “Midnight Commander” and it turns out to be a great GUI tool for maneuvering the MMC as well a good learning experience since it gives a visual layout of the disk systems.
“sudo apt install mc”
Haha. It’s good that you’re discovering new tools that are of use to you.
I just look where the mountpoint is and ls.
I’m still struggling with trying to get to functioning GPIO pins. I can “set” them, I can “get” them (but the pin gets reset to 0 after each “get”, but I cannot get any real function out of them. I’ve set up GPIOD and failed at setting up MRAA (whiched caused dpkg errors that I cannot clear). The information available is a bit vague on working with the Zero3W and most of it is undated so I don’t know if I am trying to install deprecated software or not. Can someone verify to me that GPIOD is the newest means of accessing our pins and that MRAA is outdated. That’s the impression that I get from Google. Any help on getting to reliable and simple information on doing the normally familiar SPI, UART, I2C, PWM, etc., would be appreciated. Tried using “AS-IS” to keep the “get” command (GPIOD) from resetting my pin but to no avail.