Pi Hut 3D Xmas Tree, and many GPIO questions
Posted: Wed Dec 12, 2018 2:05 am
Background: I got two of those great PiHut 3D Xmas trees last year, and used one each to teach my daughter and re-teach myself how to solder. We wrote a lot of different python programs to flash the lights in different patterns, using LED, LEDBoard, or PwMLED as imported from gpiozero, and had loads of fun.
This is a multi-part question, relating to how GPIO pins work, as suggested by the behavior of our separate PiHut trees this year.
First, this year, mine's working fine, and she's just trying to run the same programs as last year, but her PiHut tree seems to be flashing erratically, i.e, whatever program she's running, the pattern seems to have extra flashes or variability in it - flashier even than it ought to be, if that makes any sense. I've previously goofed and run two programs simultaneously, and I've seen some combination of the patterns result, but I don't think we're doing that now.
Before we get too far down a rabbit hole, is anyone acquainted with such behavior on the part of this item - caused by anything at all - a part in the tree gone bad , flaky software somewhere, an incompatible python update, a missing gpiozero update, a bad run of pi zeros, a flaky soldered-on header, an insufficient power supply? If so, please let me know before I start reaching even farther for an explanation... If not, let's leap ahead!
The behavior when two programs are running does suggest the possibility that the GPIO pins can march to multiple drummers at the same time, or put another way, aren't locked or held or waited for by one process at a time, so one cause of the variation might be that someone else's process or program is simultaneously messing with the same GPIO pins that our program is intended to play with. But which one?
Second, I've been playing more with automating the starting and stopping of my own Xmas tree and programs via crontab, i.e, starting the program when the pi is booted or at some specific hour, and similarly stopping the program or shutting down the whole pi later, when I've had enough flashing and want to go to sleep.
I interrupt the program with a simple - or brutal - bit of scripting in crontab like:
0 21 * * * ps -ef | grep python | grep -v grep | awk '{system("kill " $2)}'
But this sometimes leaves some lights on, in mid-program or mid-flash as it were, and that annoys me. Especially the LED forming the tree's "star", GPIO number 2 or pin number 3.
This leads to another thought in my mind - that GPIO pins are sort of robotic - or Newtonian - going on doing whatever they were doing when some entity stops telling them to do anything different. So, I thought I had to run some other "clean-up" program like this:
from gpiozero import LEDBoard
from gpiozero import PWMLED
from gpiozero import LED
tree = LEDBoard(*range(4,28),pwm=True)
for led in tree:
led.value=0.0
tree.close()
star = PWMLED(2)
star.value = 0.0
star.close()
But, no matter how I tweak this code, is still seems like some LEDs either fail to turn off or actually go back on later, and I can't sleep both because the light's on and I can't figure out why the light's on, if that's clear...
Another of my ideas is to attach some kind of on-off switch that would either gracefully shut down or reset the pi, but can I really do that when the Xmas tree seems to be using all of the pins (the articles I've skimmed seem to say that you need specific pins to preform the graceful on and off with the same switch, so here's another slant on the question - can my shutdown switch and my tree share pins? But even when I've gracefully shutdown the pi now using "sudo shutdown -h now", that damn star is still shining, so I would have to actually cut the power to get the thing off...
I've also noticed that the "star", GPIO2, pin3 often comes on when I boot the board, as does tree LED19, GPIO14, pin8. This must mean that some operating system program or process is turning them on, unless the pi hardware itself does that? By the way, this is a Raspberry Pi Zero, V1.3, revision 900093.
SO, someone with some actual knowledge here - who all is using those GPIO pins? Specifically, could it be someone simultaneously using the pins that's disrupting my daughter's tree's flashes, what is it that's keeping my star on, or turning it on during boot and keeping it on even after shutdown? And can I re-use pins myself, for a shutdown program triggered by a switch while my tree flashing program is still running?
Whew, next time, I promise, separate questions...
This is a multi-part question, relating to how GPIO pins work, as suggested by the behavior of our separate PiHut trees this year.
First, this year, mine's working fine, and she's just trying to run the same programs as last year, but her PiHut tree seems to be flashing erratically, i.e, whatever program she's running, the pattern seems to have extra flashes or variability in it - flashier even than it ought to be, if that makes any sense. I've previously goofed and run two programs simultaneously, and I've seen some combination of the patterns result, but I don't think we're doing that now.
Before we get too far down a rabbit hole, is anyone acquainted with such behavior on the part of this item - caused by anything at all - a part in the tree gone bad , flaky software somewhere, an incompatible python update, a missing gpiozero update, a bad run of pi zeros, a flaky soldered-on header, an insufficient power supply? If so, please let me know before I start reaching even farther for an explanation... If not, let's leap ahead!
The behavior when two programs are running does suggest the possibility that the GPIO pins can march to multiple drummers at the same time, or put another way, aren't locked or held or waited for by one process at a time, so one cause of the variation might be that someone else's process or program is simultaneously messing with the same GPIO pins that our program is intended to play with. But which one?
Second, I've been playing more with automating the starting and stopping of my own Xmas tree and programs via crontab, i.e, starting the program when the pi is booted or at some specific hour, and similarly stopping the program or shutting down the whole pi later, when I've had enough flashing and want to go to sleep.
I interrupt the program with a simple - or brutal - bit of scripting in crontab like:
0 21 * * * ps -ef | grep python | grep -v grep | awk '{system("kill " $2)}'
But this sometimes leaves some lights on, in mid-program or mid-flash as it were, and that annoys me. Especially the LED forming the tree's "star", GPIO number 2 or pin number 3.
This leads to another thought in my mind - that GPIO pins are sort of robotic - or Newtonian - going on doing whatever they were doing when some entity stops telling them to do anything different. So, I thought I had to run some other "clean-up" program like this:
from gpiozero import LEDBoard
from gpiozero import PWMLED
from gpiozero import LED
tree = LEDBoard(*range(4,28),pwm=True)
for led in tree:
led.value=0.0
tree.close()
star = PWMLED(2)
star.value = 0.0
star.close()
But, no matter how I tweak this code, is still seems like some LEDs either fail to turn off or actually go back on later, and I can't sleep both because the light's on and I can't figure out why the light's on, if that's clear...
Another of my ideas is to attach some kind of on-off switch that would either gracefully shut down or reset the pi, but can I really do that when the Xmas tree seems to be using all of the pins (the articles I've skimmed seem to say that you need specific pins to preform the graceful on and off with the same switch, so here's another slant on the question - can my shutdown switch and my tree share pins? But even when I've gracefully shutdown the pi now using "sudo shutdown -h now", that damn star is still shining, so I would have to actually cut the power to get the thing off...
I've also noticed that the "star", GPIO2, pin3 often comes on when I boot the board, as does tree LED19, GPIO14, pin8. This must mean that some operating system program or process is turning them on, unless the pi hardware itself does that? By the way, this is a Raspberry Pi Zero, V1.3, revision 900093.
SO, someone with some actual knowledge here - who all is using those GPIO pins? Specifically, could it be someone simultaneously using the pins that's disrupting my daughter's tree's flashes, what is it that's keeping my star on, or turning it on during boot and keeping it on even after shutdown? And can I re-use pins myself, for a shutdown program triggered by a switch while my tree flashing program is still running?
Whew, next time, I promise, separate questions...