Posts: 317
Joined: Wed Jun 20, 2018 12:38 am

Pi Hut 3D Xmas Tree, and many GPIO questions

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:

star = PWMLED(2)
star.value = 0.0

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...

Posts: 500
Joined: Wed Sep 25, 2013 8:43 am
Location: Canterbury, Kent, UK

Re: Pi Hut 3D Xmas Tree, and many GPIO questions

Mon Dec 17, 2018 12:59 pm


I've just ordered one of these, it's arriving maybe tomorrow.

Having read the docs, on your daughters setup, you didn't set a program to run at boot did you ? That may explain the dual running symptoms you were seeing ? Only a guess as I'm not there yet.

Also did you see this page ? http://pkula.blogspot.com/2017/12/3d-xm ... ample.html

If you care to share any of your code I would be grateful, I'm planning on using this to teach myself a little python...


Posts: 317
Joined: Wed Jun 20, 2018 12:38 am

Re: Pi Hut 3D Xmas Tree, and many GPIO questions

Mon Dec 17, 2018 2:28 pm

SOLVED! I still have questions about what other processes are fiddling with the GPIO - and they definitely are, especially on boot - but I did figure out why my daughter's tree's LEDs were more variable than mine.

I started down the typical troubleshooting path - where you keep swapping things around until you identify the critical element. For example, I tried a different power supply (didn't help). I put my tree on her pi, and vice-versa (now, that was interesting - my tree got flashier and hers got normal!). Also, after booting many times, I realized that the extra flashiness settled down after a short while (a minute or two) and things seemed perfectly normal after that. Hmmmm.... At that point, I tried booting her pi and tree attached to a monitor (before I had been running headless and SSH'ing in), and that made it obvious - her pi was set up to boot automatically to the desktop, while mine are always set to go to the command line and ask for a password. And during the time that the system was 100% BUSY booting to the desktop, the LEDs on the tree were both more erratic and sometimes brighter, then they looked normal once the CPU had settled down to approximately 50%, which is where our own python programs would typically drive it. I clicked to shut the pi down, and there was another brief flashier/brighter time while the system was busy shutting down. Eureka!

In fact, any other process that keeps the CPU busy throws off the tree's flashing - "sudo apt-get update && sudo apt-get upgrade" for example. Our python code overall turns down the LEDs as well as dimming or flashing them in various patterns. From what I understand about PWM, you're not actually lowering the brightness, you're just turning them on full, less of the time? If some other process is keeping the CPU so busy that our code isn't executing as much, maybe the LEDs stay full on while we're swapped out? Just a guess...

Why didn't we notice this last year? Both pi's were set to go to the command line last year. We had saved off her python code, then re-burnt her card recently, so it had defaulted back to booting to the desktop.

Posts: 317
Joined: Wed Jun 20, 2018 12:38 am

Re: Pi Hut 3D Xmas Tree, and many GPIO questions

Thu Dec 27, 2018 2:23 am

I've figured out why the LEDs I was manipulating on the PiHut 3D Xmas Tree were extra variable under certain circumstances, so that part of my problem is "solved".

But I'm still interested in what OTHER process(es) are fiddling with the GPIO pins, so as to cause the LEDs to light up during boot up, for example, before my program is even started. Can some GPIO expert shed some light? OR point me to the facts somewhere on line?

Return to “HATs and other add-ons”