tinker2much
Posts: 127
Joined: Wed Jun 20, 2018 12:38 am

PiHut 3D RGB Xmas Tree questions

Thu Jan 02, 2020 8:58 pm

I was very happy to be given the new PiHut 3D RGB Xmas Tree for Christmas. https://thepihut.com/products/3d-rgb-xm ... spberry-pi It uses 25 RGB LEDs.

I had gotten the previous model (which uses 24 red LEDs and one white one for the star) two years ago. https://thepihut.com/products/3d-xmas-t ... spberry-pi. I had lots of fun programming that one to light up in all kinds of patterns. I had some questions and issues which I brought up on this forum at the time.

Initially, I wondered if the previous programs would work on this model, but they don't.
I read through the comments on the PiHut site, and read through the new code on GitHub https://github.com/ThePiHut/rgbxmastree, and fiddled with the new sample programs to vary things, and slowly but finally realized that the new tree is a very different beast.

The old one used up every GPIO pin, one per LED, making it impossible to attach anything else (I particularly wanted to hook up the typical shutdown switch to GPIO3 but couldn't).

The new LEDs (APA102s?) seem to be hooked up in a serial manner like an LED strip, so you need just power, ground, and clock and data pins to control them in an SPI manner. So of course the code would be different, but perhaps GPIO pins are free for other purposes? None of this seems to be documented, so I'm calling out to other tree enthusiasts with more hardware knowledge here...

I used a bright light and a magnifying glass to try to see which pins had traces connected to them, and seemed to find the following physical pins:
  • 2 == 5v
    6 == GROUND (maybe - not clear)
    22 == GPIO 25 (used for clock? )
    32 == GPIO 12 (used for data? )


In the GitHub code, there was mention of "mosi_pin=12" and "clock_pin=25", which seems to confirm I have those two right. I'm pretty sure about the power, but wasn't sure about the ground.

I've found references on Adafruit to "hardware SPI" using physical pins 19 and 23 versus using any other GPIO pins for "bit-bang" SPI, supposedly not as fast. https://learn.adafruit.com/adafruit-dot ... cuitpython, So, it would seem that the new sample code is "bit-banging"? I wonder why not use hardware SPI? If we connected the tree to different pins - and changed the code - would that be possible?

The new tree has the same 40-pin female header as the old tree, so it's physically taking up every pin even if its not using them. I tried (very carefully!) to set the tree apart from the pi and just connect the above four pins with MF jumpers, but I didn't get it to work (although I didn't ruin anything either, always a good thing.) If I could figure out which pins were really in use, I could somehow use others for shutdown switches or other purposes.

SO, this is an open invitation to anyone else who has this tree, or anyone else who knows about it, or who knows more about SPI or these LEDs, or the GitHub code, to comment here and enlighten us all.

tinker2much
Posts: 127
Joined: Wed Jun 20, 2018 12:38 am

Re: PiHut 3D RGB Xmas Tree questions

Fri Jan 03, 2020 12:41 am

Adding more questions...

The tree has through-holes labeled P, G, D and C - I guess power, ground, data and clock? Could these be connected to specific PI pins via jumpers, allowing the use of hardware SPI (physical pins 2, 6, 19 and 23 perhaps?) This would mean the whole tree's 40-pin header would NOT have to be plugged onto the pis header, freeing those up for other purposes?

I can't find any documentation about this at PiHut.

User avatar
DougieLawson
Posts: 37096
Joined: Sun Jun 16, 2013 11:19 pm
Location: Basingstoke, UK
Contact: Website Twitter

Re: PiHut 3D RGB Xmas Tree questions

Fri Jan 03, 2020 12:51 am

There's loads of documentation at: https://github.com/ThePiHut/rgbxmastree
Note: Having anything humorous in your signature is completely banned on this forum. Wear a tin-foil hat and you'll get a ban.

Any DMs sent on Twitter will be answered next month.

This is a doctor free zone.

User avatar
rpdom
Posts: 16110
Joined: Sun May 06, 2012 5:17 am
Location: Chelmsford, Essex, UK

Re: PiHut 3D RGB Xmas Tree questions

Fri Jan 03, 2020 6:37 am

tinker2much wrote:
Fri Jan 03, 2020 12:41 am
Adding more questions...

The tree has through-holes labeled P, G, D and C - I guess power, ground, data and clock? Could these be connected to specific PI pins via jumpers, allowing the use of hardware SPI (physical pins 2, 6, 19 and 23 perhaps?) This would mean the whole tree's 40-pin header would NOT have to be plugged onto the pis header, freeing those up for other purposes?

I can't find any documentation about this at PiHut.
I suspect those holes are for output for cascading to another tree or perhaps an LED strip. Not likely for input.

tinker2much
Posts: 127
Joined: Wed Jun 20, 2018 12:38 am

Re: PiHut 3D RGB Xmas Tree questions

Fri Jan 03, 2020 6:55 pm

DougieLawson wrote:
Fri Jan 03, 2020 12:51 am
There's loads of documentation at: https://github.com/ThePiHut/rgbxmastree
I mentioned that link in my first post. That's not the level of documentation I'm looking for. It does have tree.py which defines the Pixel and RGBXmasTree classes, a README that shows simple usages of those classes, and four sample programs covering the same ground. I've looked through all of those. (@bennuttall - for shame - not a comment in sight anywhere - ;-) )

I was looking for something more. Regarding the software - explaining what that code's really doing, how it's using the SPI interface (if it is), why such code isn't in gpiozero like the code for the previous Xmas tree. Regarding the hardware - how the tree connects to and uses the GPIO pins, the meaning of the P/G/C/D holes on the PCB, are there other capabilities of these LEDs besides what's demonstrated in the example code and exposed in those classes. How to do "hardware SPI".

Everything on the PiHut site refers to the github site or to their instructions for the previous non-RGB tree. Thanks to Rachel Raynes for designing the board, thanks to PiHut for selling yet another clever and fun and wonderful product, and to Ben for writing some quick code so those of us who got this as a Christmas gift would have something to start with, but how about some more meaty detail?

Here are some of the links I found which provide detail in the vicinity of what I want, but these aren't from the people who wrote the software or built the board. I would rather hear from them.

how to connect a strip of apa102's to a pi, and drive them using specific python code:
https://pimylifeup.com/raspberry-pi-led-strip-apa102/

APA102 spec sheet - maybe not the exact ones used here:
http://www.led-color.com/upload/201604/ ... %20LED.pdf

data and descriptions of this or a similar LED from adafruit:
https://www.adafruit.com/product/2343

blog and data sheet and more facts on the apa102:
https://cpldcpu.wordpress.com/2014/08/27/apa102/

FAST LED main - seems to be for arduino only
https://github.com/FastLED/FastLED

powering and connection adafruit dotstar apa102s
https://learn.adafruit.com/adafruit-dot ... onnections

CircuitPython on a raspberry pi
https://learn.adafruit.com/circuitpytho ... spberry-pi

python and CircuitPython, and connecting LEDs to a raspberry pi
https://learn.adafruit.com/adafruit-dot ... cuitpython

tinker2much
Posts: 127
Joined: Wed Jun 20, 2018 12:38 am

Re: PiHut 3D RGB Xmas Tree questions

Mon Jan 06, 2020 12:29 am

Maybe my last post made it look as if, because I had lots of links, I must therefore have a lot of answers.

Nope, I still have questions. Here are just a few...

1. Which GPIO pins is the new RGB tree really using, and could I just connect those instead of using the full 40-pin header?
2. If the sample code is not doing "hardware SPI", how would we do so?
3. What are the four holes on the PCB for, those labeled P/G/C/D ?
4. Is it possible to hook the new RGB tree to other trees, or to other strings of LEDs?

User avatar
DougieLawson
Posts: 37096
Joined: Sun Jun 16, 2013 11:19 pm
Location: Basingstoke, UK
Contact: Website Twitter

Re: PiHut 3D RGB Xmas Tree questions

Mon Jan 06, 2020 8:23 am

1. Read the code.

Code: Select all

class RGBXmasTree(SourceMixin, SPIDevice):
    def __init__(self, pixels=25, brightness=0.5, mosi_pin=12, clock_pin=25, *args, **kwargs):
        super(RGBXmasTree, self).__init__(mosi_pin=mosi_pin, clock_pin=clock_pin, *args, **kwargs)
        self._all = [Pixel(parent=self, index=i) for i in range(pixels)]
        self._value = [(0, 0, 0)] * pixels
        self.brightness = brightness
        self.off()
2. Read the code.
3. Ask PiHut (they're on twitter, so is Rachel Rayns who built this doohickey).
4. Ask PiHut or Rachel

You may even win a tenner. https://twitter.com/ThePiHut/status/1212677680191148032
Note: Having anything humorous in your signature is completely banned on this forum. Wear a tin-foil hat and you'll get a ban.

Any DMs sent on Twitter will be answered next month.

This is a doctor free zone.

tinker2much
Posts: 127
Joined: Wed Jun 20, 2018 12:38 am

Re: PiHut 3D RGB Xmas Tree questions

Mon Jan 06, 2020 3:19 pm

DougieLawson wrote:
Mon Jan 06, 2020 8:23 am
1. Read the code.

Code: Select all

class RGBXmasTree(SourceMixin, SPIDevice):
    def __init__(self, pixels=25, brightness=0.5, mosi_pin=12, clock_pin=25, *args, **kwargs):
        super(RGBXmasTree, self).__init__(mosi_pin=mosi_pin, clock_pin=clock_pin, *args, **kwargs)
        self._all = [Pixel(parent=self, index=i) for i in range(pixels)]
        self._value = [(0, 0, 0)] * pixels
        self.brightness = brightness
        self.off()
2. Read the code.
3. Ask PiHut (they're on twitter, so is Rachel Rayns who built this doohickey).
4. Ask PiHut or Rachel

You may even win a tenner. https://twitter.com/ThePiHut/status/1212677680191148032
1. I read that class but except for a few more obvious bits like the pins, it meant little to me
2. ditto, I'm not an experienced Python programmer, and what python I have done has been simple procedural stuff, not classes. And I'm certainly not a hardware guy.
3. I'm not on twitter and not going to be (that's another subject entirely, and one that I'm not going to explain here)
4. I had thought there might be a wider audience and a wider group of potential experienced helpers here. But it's a good idea to ask at PiHut. I will do so.

And now - sorry Dougie, you inadvertently bumped a hot button of mine - the steam's rising up for a rant:

As someone who's now retired after almost 30 years as a programmer, here's my opinion of "read the code": it's not the most effective way to teach people and it can waste programmer's time as much as it wastes user's time. I believe instead in written documentation - user documentation, system documentation, and well documented code. I've repeatedly been in the situation of having to fix or augment someone else's code (after they left the company), when all I had was "reading the code", and even though I was fluent in those languages, and had used those or similar applications, and I succeeded in the end, it was way too difficult. I would have given anything for some written explanation of what they were trying to do, how the product was supposed to be used, some background on the architectural decisions, and definitely some comments in the code explaining the particularly obscure (or clever) bits. I would have learned MORE that way, and I would certainly have learned it SOONER. If I could have had 5 minutes with the former person to ask a few quick questions, that would also have been way more productive. If you really want someone to learn, give them something more than just code.

Now here's the finale of the rant - and I'm NOT saying this was Dougie's attitude - there's sometimes an elitist or exclusive air to "read the code", like "this is all you ought to need, and if you need something more, maybe you're just not smart enough or tough enough". I think people who are told to read the code and fail will get discouraged and turn away from coding, which shouldn't be the goal of any of us here. End of rant. My apologies.

To turn this in a more positive direction, think of this as an application of the Golden Rule (treat others as you would be treated) - if you would like better (or any) documentation when trying to learn other people's code, then you ought to provide more of it it along with your own code.

User avatar
DougieLawson
Posts: 37096
Joined: Sun Jun 16, 2013 11:19 pm
Location: Basingstoke, UK
Contact: Website Twitter

Re: PiHut 3D RGB Xmas Tree questions

Mon Jan 06, 2020 5:42 pm

"Read the code" has worked for me in forty years of programming micros and mainframes including doing level 1 and level 2 technical support. The code reading is one step forward from reading the post-mortem system dump. Often what I was doing was reading someone else's code (and that could be the customer's code).

Python is one of the most readable languages of the lot. The only complexity is the object oriented paradigm, which can be a bit daunting for procedural COBOL programmers to get to grips with because it's way different to the normal monolithic structure of a procedural program. But you know what methods you're calling in your program that instantiates the object so it's realtively easy to trace what's going on. If not, litter the code with some print(...) statements (or logging) to see what's going on (what route a call takes). Or run it under an IDE like Thonny.

If you sign-up for GitHub you can post an issue at https://github.com/ThePiHut/rgbxmastree to get the developer to better explain what their code is doing.
Note: Having anything humorous in your signature is completely banned on this forum. Wear a tin-foil hat and you'll get a ban.

Any DMs sent on Twitter will be answered next month.

This is a doctor free zone.

tinker2much
Posts: 127
Joined: Wed Jun 20, 2018 12:38 am

Re: PiHut 3D RGB Xmas Tree questions

Mon Jan 06, 2020 9:02 pm

"COBOL programmer", heck no. The first half of my career was writing mainframe assembler; the second was doing the same applications over again for servers, using C and scripting languages. If there was any structure or modularity, it was there because you imposed it, without much help from the languages. The code was so cryptic, you HAD to document it in a human language.

Having written my first program in 1972, I've read a lot of code too. Printfs - been there done that. I'm not arguing that reading code doesn't work, or that it isn't necessary, just that it's not the most effective way to transfer knowledge about systems or programs. I was always grateful when anyone else provided rich documentation beyond the code, and I always tried to provide it for my systems whether anyone else did so or not.

I have always found the stuff that doesn't appear in the code to be as useful as the stuff that does - the history, the trade-offs, the compromises, the reasoning behind the architecture, the bits that still don't work as well as they should. The unvarnished truth, as if you got to interview the original author or team in confidence. And, I do mean something beyond git logs.

User avatar
DougieLawson
Posts: 37096
Joined: Sun Jun 16, 2013 11:19 pm
Location: Basingstoke, UK
Contact: Website Twitter

Re: PiHut 3D RGB Xmas Tree questions

Mon Jan 06, 2020 9:20 pm

Unfortunately, it's not the modern way.

It's a rare thing to find a comment in python code. In 370 assembler (now zSeries) you have to write comments because there's too many smart tricks you can do with funky instructions like execute (EX), move with offset (MVO) and translate (TR). With all the 64bit, high half of registers and grande instructions in zSeries it gets ever more complex.

The pythonic programmers assume their language is readable so often don't bother commenting even for the bits where they're using a tricky quirk.
Note: Having anything humorous in your signature is completely banned on this forum. Wear a tin-foil hat and you'll get a ban.

Any DMs sent on Twitter will be answered next month.

This is a doctor free zone.

tinker2much
Posts: 127
Joined: Wed Jun 20, 2018 12:38 am

Re: PiHut 3D RGB Xmas Tree questions

Mon Jan 06, 2020 9:27 pm

@DougieLawson - I have taken two of your suggestions:

1. I posted an issue on github, asking for further details about Ben's software
2. I posted a support request at The PiHut, requesting that Rachel provide answers to some hardware questions.

User avatar
rpdom
Posts: 16110
Joined: Sun May 06, 2012 5:17 am
Location: Chelmsford, Essex, UK

Re: PiHut 3D RGB Xmas Tree questions

Tue Jan 07, 2020 7:05 am

The first half of my programming career was writing code in COBOL and mainframe assembler. (I dabbled a lot in various BASICs and other assemblers as a hobby and as a job for a few years too).

Documentation was comments in the code. Sometimes there were none and I had to work out what the code was doing so I could fix it.

Sorting out bugs in COBOL could mean hours of analysing a system dump, disassembling it by hand and tracking down where in the program it had failed and what the data contents were. Usually it was someone exceeding the size of an array (OCCURS), or just plain bad data.

tinker2much
Posts: 127
Joined: Wed Jun 20, 2018 12:38 am

Re: PiHut 3D RGB Xmas Tree questions

Fri Jan 10, 2020 6:37 pm

tinker2much wrote:
Mon Jan 06, 2020 9:27 pm
@DougieLawson - I have taken two of your suggestions:

1. I posted an issue on github, asking for further details about Ben's software
2. I posted a support request at The PiHut, requesting that Rachel provide answers to some hardware questions.

1. Ben said the following on Github (spoiler alert!!) https://github.com/ThePiHut/rgbxmastree/issues/13
The pixels don't require precise timing or anything, so software SPI is fine. And if you are doing a Christmas project using two GPIO pins, why not use pins 12 and 25 to mark the date? A kind of Christmas Easter Egg.

2. I asked the following of PiHut support
A lovely and fun product, thanks! I am curious about some aspects of the hardware design of this item. Could Rachel Rayns please provide some additional detail? FIrst, which GPIO pins are actually being used (so I know which are free for me to use for other purposes, or perhaps so I could connect it to the pi via a handful of jumpers and not use the full 40-pin header). Secondly, what is the use of the 4 holes through the PCB, labeled D/C/P/G. Are these an alternate way to attach the tree to a pi or microcontroller, or perhaps a way to daisy chain other LEDs?
They answered:
Good morning.

I am afraid I do not have these details to hand :(

I can confirm though that the 4 holes you refer to allow you to daisy chain further LEDs :)

It's possible that the designer (Rachel - https://twitter.com/RachelRayns) can offer more insight that myself!
Since I don't do twitter, I can't follow their suggestion to contact her there. Perhaps someone else could ask these questions, if they were also interested.

tinker2much
Posts: 127
Joined: Wed Jun 20, 2018 12:38 am

Re: PiHut 3D RGB Xmas Tree questions

Thu Jan 16, 2020 9:58 pm

tinker2much wrote:
Mon Jan 06, 2020 9:27 pm
@DougieLawson - I have taken two of your suggestions:

1. I posted an issue on github, asking for further details about Ben's software
2. I posted a support request at The PiHut, requesting that Rachel provide answers to some hardware questions.
3. I also politely requested more information from Rachel Rayns, in my review of this product on the PiHut web site.

Return to “HATs and other add-ons”