Using strip effects in NightDriverStrip Platformio.ini #428
Replies: 9 comments 11 replies
-
|
Never mind. I think I figured it out. |
Beta Was this translation helpful? Give feedback.
-
|
Any chance you could say how you fixed it? I'm having a similar issue for a different board and I haven't been able to figure it out |
Beta Was this translation helpful? Give feedback.
-
|
Well...I didn't "fix it", I just figured out what I thought the way it worked isn't the way it works. I'm still trying to learn and figure out how davepl's code works, but learned a lot tonight just by more thoroughly reading main.cpp and globals.h, especially globals.h. I'm getting confused about the PlatformIO.ini file's reference to "dev_envs = ". Is is pointing to a "project configuration" as mentioned in the globals.h or something else??? What board are you using? |
Beta Was this translation helpful? Give feedback.
-
|
In platformio (I think this is actually an SCons thing that's leaked through....) an Environment is the project you're building. You pass this via the '-e' flag to the build. pio/scons then picks the env:THING line from platform.ini that matches that builds that thing. NightDriverLED then starts laying on additional terms of what you're building (mesmerizer or demo or spectrum or such) and what you're building it ON (heltecv2, heltecv2, a variety of dev boards, an m5stick, etc.) It gets tangly because most projects are the result of two distinct knobs and the use of 'boards' in this project doesn't really match the PIO concept of 'boards'. But here's what we have: envs are usually defined in terms of other envs (which makes sense - 'demo' is 95% the same for any of those boards) which you can read about in the 'extends' options in the [env:BLAH] stanzas in platform.ini. The kink is that some of THESE knobs turn the other knobs. So an env:FOO might set LEDSTRIP=1 (which means "we're programming strips of 281x's and not HUB75s") and some knobs (like USE_WIFI) inconsistently. Why does demo for a heltech turn on WiFi while m5 doesn't? Why does attaching a hexagon pad imply the presence of an LCD screen on specific pins? {shrug - I suspect the real answer is because the way inheritance in these files works makes copy-pasting so much easier than building a formal relationship between such things - see below for more on that} but importantly also sets exactly one other knob (which looks just like other knobs in -DTHIS and -DTHAT) but that is magical only to the READER of that knob: include/globals.h. [ pullout ] mesmerizer_all Platform buildfs Build Filesystem Image What order are the targets in? Why so slow? No Idea. Platformio seems to have taken the already slow scons and slowed it down by 5-10x. This scans platformio and gives you a list of *environments you can build in the first column and targets that can be built in the second column. Remember the 'e' and 't' and now you'll know why you can type: There isn't a tool that'll tell you [ /pullout ] include/globals.h looks for secret (not really secret, but not named in any way that would stand out at you) to look for specific #defines that were set via -Dwhatever in platformio.h that further controls the build. These knobs control what effects are used for that THING that you're building. It will thus look for DEMO, LANTERN, TREESET, LASERLINE, MESMERIZER, etc. to control the patterns of the shown effects as well as further configuration knobs like the IR and audio configuration, networking capabilities used, what pins things are on (wait, wasn't that done in platform.ini? Yep...sometimes. More shrugging.) So there's kind of a project/configuration fan out that starts at platform.io and gets "wider" in globals.h until about the #ifndef PROJECT_NAME. Then there are dozens of lines that kind of do a coalesce on configurations ("Oh, you wanted to do Audio? Well, here's how many bands we need." sorts of things. A big section that just generally takes all that above it and kind of makes the configuration complete, filling in missing definitions with defaults, etc. The next real point of divergence in the "what kind of blinkage" path is src/effects.cpp. This is where the pattern defines (DEMO, UMBRELLA, MESMERIZER, SPECTRUM, etc.) are examined and the appropriate ADD_EFFECTS are made to, well, add the effects. If you're at all off the beaten path (i.e. building your own or otherwise using hardware not present in Dave's Garage. :-) ) you should probably prepare to define your own env in platformio.ini that lays out what kind of hardware (board + blinkies) you're building, chooses the kind of blinkies (MESMERIZER, SPECTRUM, etc), You MAY have to tweak globals.h My personal preference is to -D as much as I can inside the single hunk of platform.ini (including things like pin numbers) just so I have only a single file that I have to keep out of 'git add's wrath to keep reverting every time I branch and merge. Managing more changes in more files is more problems over a life cycle of a long running branch for development. Now I'll concede that build systems are a total pain and are generally considered a distractions by developers[1] that just want blinkies. It's easier to copy-paste a few lines from something similar and end up submitting it to the project. I've questioned all this this before (#372) and finally reached a level of (thinking I) understand it all. We've since made some inroads since that thread to fixing some of the terminology issues in both code and doc like the top-level README. "Fixing" the defines that control the build is even explicitly discouraged in that very doc, so just embrace what's here. [1] Which is why every project if not every programmer has probably built their own at least once in their life, yet they all seem to stink in different ways... (and no, I'm not 'attosecond') @SeanMcKeen @airnocker , and anyone else struggling with entering orbit here, hopefully you'll find this educational. I'm back in town to help if questions remain. |
Beta Was this translation helpful? Give feedback.
-
|
@robertlipe, many thanks for taking the time to respond with your insights. You've given me a lot to comprehend and consider. |
Beta Was this translation helpful? Give feedback.
-
|
You're welcome. I wrote all that hoping to help you and others understand how all the pieces fit together because it took me some non-trivial effort to get my own head around it. Probably the two most interesting files for you to read - and they don't actually contain a lot of gnarly C++, so they're actually readable by a non-programmer that just has some commitment to digest them, are indeed globals.h and platformio.ini. There are indeed a large number of combinations in this project. It's not too far beneath the skin of my answer that I think there has indeed been too much copy and pasting. I called that out in #372, but didn't really get traction. Reading platformio.ini, there are at least three projects "beneath the eaves", which seems a bit crowded, for example. In a similarly detailed response last night in #427, I helped (hopefully) analyze a chain of failures caused by excessive copy/pasting. "Mesmerizer" talks about 2812's, when it's absolutely not a 2812 project at all. I called on those more familiar with those configurations to help fix it. We ultimately made some progress by partially untangling USE_HUB75 vs. USE_281x, but the individual project names are still messy. I've still not figured out what RING is even all about, but I'm pretty sure that MESMERIZER doesn't have 24 of them just because those code paths are mutually exclusive. IMO, we really need someone that has each project to really go in and clean up those configurations. There's so much duplications that it's just misleading people that are trying to learn from it. |
Beta Was this translation helpful? Give feedback.
-
|
@robertlipe, your comments have really help shed a "ring" of light around NightDriverStrip. Definitely, reading PlatformIO.ini and global.h is mandetory reading IMO in order just to gain a modicum of understanding. I understand the PlatformIO is designed for "team collaboration". Does this mean that what is up on GitHub for NightDriverStrip has code contributors other than @davepl ? If so, do these contributors identify their code pieces? I'm going to your #372 and #427 references, now. I'm guessing (and hoping) that RING refers to RGB strips that are in the shape of a annular RING, such as a WS2812B segments soldered into ring shapes and certainly those strips that are actually made as annular rings. If I can confirm this, I'll plant a flag! |
Beta Was this translation helpful? Give feedback.
-
|
On Sun, Sep 17, 2023, 2:28 PM airnocker ***@***.***> wrote:
@robertlipe <https://github.com/robertlipe>, your comments have really
help shed a "ring" of light around NightDriverStrip.
You're welcome.
Definitely, reading PlatformIO.ini and global.h is mandetory reading IMO
in order just to gain a modicum of understanding.
IMO, unless you're diving into the code with laser focus (e.g. to work on
network layer or lock contention or something where you can work with depth
over width) they're about mandatory.
I understand the PlatformIO is designed for "team collaboration". Does this
mean that what is up on GitHub for NightDriverStrip has code contributors
other than @davepl <https://github.com/davepl> ? If so, do these
contributors identify their code pieces?
Yes. You can see the git history clicking on the clock of the code tab
which will take you to
https://github.com/PlummersSoftwareLLC/NightDriverStrip/commits/main
The whole idea of open sourcing a project is to share it with others as
well as to collect and collaborate the efforts of others. At least in
recent months, this project has had very few actual contributors. Its
probably unwise to numerically quantify it, but this summer, at least, I
think it's probably 90% Either, 9% Dave, and .9% me. (I have about 150
commits sitting in the oven on a branch, awaiting the three of us land to
them, but it still won't really change the long-term realities.) I haven't
confirmed it in the project history, but I gather the bulk of code and
fundamentals were Dave's for a long time before he opened it to others.
Dave's been trying to get new blood on board. Rutger works a lot on
infrastructure. I've been playing ambassador, trying to welcome people and
get them started so the others can stay heads down. Tweaking a bit of
career guidance I once used:
"The most valuable thing a contributor can do is to make more
contributors."
We have had a couple coming online in the last few weeks, so hopefully we
can grow them into active contributors. You can see the. Growth in the
discussions area. Hopefully, they'll bloom soon. I think I saw a
meaningful PR come in last night, in fact.
I'm guessing (and hoping) that RING refers to RGB strips that are in the
shape of a annular RING, such as a WS2812B segments
Ah, I'd say that's a good answer. I was so hung up on the former name
(USE_STRIP) and thinking in lines that it didn't occur to me. All the
effects I've seen (in haven't finished reading it all...) use the entire
strip as a linear drawing canvas.
In that case, they make no sense in MESMERIZER.
So with that line of reasoning, we have configuration layers of:
The board we're on
The electrical traits (pins, LCD configuration)
The exclusive traits of 2812 vs HUB
The configuration of the blinkies of each of those (panel Configuration vs
length and shape of strips)
... and this is why globals.h and platformio.ini are hard.
Message ID:
… <PlummersSoftwareLLC/NightDriverStrip/repo-discussions/428/comments/7028176
@github.com>
|
Beta Was this translation helpful? Give feedback.
-
|
Does this mean changes I make to these files loaded into my VS/PlatformIO is also saved to the collaborative GitHub "Dave" folder? At this point, my interest and focus is music driven "strip(s)" code driven by one or more GPIOs, eventually with IR remote and WiFi interaction, but my personal project focuses on just one GPIO and project (code routine) selectable capability at present. I've no interest in "matrix" stuff (yet). Learning IR remote implementations will be all new to me. |
Beta Was this translation helpful? Give feedback.
-
|
On Sun, Sep 17, 2023 at 10:12 PM airnocker ***@***.***> wrote:
Does this mean changes I make to these files loaded into my VS/PlatformIO
is also saved to the collaborative GitHub "Dave" folder?
That's not how it works. All changes are yours alone until you invite
(request) someone else (github) to pull your changes into the upstream
tree. I received no email saying there was a new pull request and looking
in https://github.com/PlummersSoftwareLLC/NightDriverStrip/pulls , I don't
see a new one from you.
It's up to you whether that's good or bad.
Until you've submitted a PR (pull request), nobody else can see it. Until
that PR has been reviewed and accepted/integrated by someone with repo
superpowers (Rutger or Dave), it's not going to show up in everyone else's
build the next time they check out or update.
Thus far besides "laserline" I've tweaked "demo" to work with my M5StickC
Plus but I am having trouble actually finding the code for "demo", i.e.
there is no demo.h, so I making an educated guess it is covered by the .ini
defaults if they are not defined in other projects.
Please review
#428 (comment)
starting around the sentence with "wider".
globals.h has a bit of #if DEMO gibberish that sets up things, much like it
configure NUM_LEDS for your LASERLIGHT project. (You can use the Lipe Pro
Tip that I suggested a few minutes ago to find every place in the code that
uses the token 'DEMO"). But the path that makes it do 'DEMO stuff' is the
#if DEMO in effects.cpp. That triggers the ADD_EFFECT. The actual effect
for that one is 'RainbowFillEffect' . and using that LPT from above (that's
thrice in a few minute - my LPT's are awesome!) you can see that the body
for that is in include/effects/strip/misceffects.h
Got the beat from here?
At this point, my interest and focus is music driven "strip(s)" code
driven by one or more GPIOs, eventually with IR remote and WiFi
interaction, but my personal project focuses on just one GPIO and project
(code routine) selectable capability at present.
You're wise to not try it all at once. Debugging code (esp. if code isn't
really your bag) on a computer without a screen and a keyboard can be a
drag - especially since you're building part of the computer as you go by
adding more GPIO connections to do more stuff, etc.
I've no interest in "matrix" stuff (yet).
They're pretty fun, but really are a different world from the WS2812 stuff.
That was a real roadblock when I joined the project as I didn't get that
(what is now) USE_WS281X and USE_HUB75 are mutually exclusive.
Learning IR remote implementations will be all new to me.
If you're just using an existing remote and doing pretty normal things, you
shouldn't HAVE to know anything about the implementation. You may have to
flip a switch inside the code a bit inside remotecontrol.h to select the
remote type, but it's not like you'll need an IR protocol analyzer or
anything deep unless you're trying to integrate triggers from existing
external devices sending 'invisible' codes to trigger sequences or
something exotic.
Anyway, sounds like you're well on your way. Good luck and enjoy!
… Message ID:
<PlummersSoftwareLLC/NightDriverStrip/repo-discussions/428/comments/7029688
@github.com>
|
Beta Was this translation helpful? Give feedback.
-
|
Glad to have a better feel for the PR's, thanks. I'll have to review your 'LPT' tip. Sounds like what I need...desperately on having a better understanding on demo. I didn't know that one could buy generic IR controllers, so I've no 'existing remote'. Need to learn about them. |
Beta Was this translation helpful? Give feedback.
-
|
They're not quite literally a dime a dozen, but they're not far off. These
are the ones I can touch without getting out of my chair. The one on the
far left is SUPER common. There's a smaller 24 pin version of it, too.
Amazon and AliExpress both have them,. Of course, as well as the receiver
diode you'll need. My ky-044s are still on the slow boat. Just days ago
there was another dev that's about the same place as you in their journey
here that scrounged the receiver diode from a dead VCR or something. Search
should find it.
On Amazon, you can sometimes get the remote included with something else
(smart bulbs, strips, controllers) for about the same price as the remote
itself.
There's nothing magic about the remotes. None of the buttons ever make
sense so take an old TV remote, decide. That channel. Is brightness and
volume is effect or whatever and just add code to remote*cpp.
There will be a better way to handle remotes in this project in the future,
but that's how you can get going today.
…On Mon, Sep 18, 2023, 2:52 PM aldengaw ***@***.***> wrote:
Glad to have a better feel for the PR's, thanks.
I'll have to review your 'LPT' tip. Sounds like what I need...desperately
on having a better understanding on demo.
I didn't know that one could buy generic IR controllers, so I've no
'existing remote'. Need to learn about them.
—
Reply to this email directly, view it on GitHub
<#428 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACCSD34DEUMKWARTLAOC4QDX3CRBJANCNFSM6AAAAAA4XPARN4>
.
You are receiving this because you were mentioned.Message ID:
<PlummersSoftwareLLC/NightDriverStrip/repo-discussions/428/comments/7038692
@github.com>
|
Beta Was this translation helpful? Give feedback.
-
|
I see what you're saying, one way is to add an IR receiver diode to your MCU of choice. For now, I'm focusing on the built-in IR receiver in the M5StickCPlus. My TV IR remotes are already dedicated. I will look into some generics IR remote transmitters and read some of the remote*.cpp code. |
Beta Was this translation helpful? Give feedback.
-
|
Sounds like You're home free. Figure out which GPIO is connected to the IR
receiver already in your device. (I think it's GPIO9 if I found the right
schematic - it's not marked clearly.) #define IR_REMOTE_PIN to that pin in
config.h inside one of those #ifdef 5stickplus blocks Point your LED or
pretty much any TV, VCR, DVD, or other remote at it and see if you get
debug stuff that goes with the button pushes.
…On Mon, Sep 18, 2023 at 4:50 PM aldengaw ***@***.***> wrote:
I see what you're saying, one way is to add an IR receiver diode to your
MCU of choice. For now, I'm focusing on the built-in IR receiver in the
M5StickCPlus. My TV IR remotes are already dedicated. I will look into some
generics IR remote transmitters and read some of the remote*.cpp code.
—
Reply to this email directly, view it on GitHub
<#428 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACCSD33PJZRLF7LVMKPKDI3X3C63LANCNFSM6AAAAAA4XPARN4>
.
You are receiving this because you were mentioned.Message ID:
<PlummersSoftwareLLC/NightDriverStrip/repo-discussions/428/comments/7039528
@github.com>
|
Beta Was this translation helpful? Give feedback.
-
|
I think the M5StickC Plus only has an IR transmitter (as in, an IR sender), which is indeed connected to GPIO pin 9. The schematic depicting that part of the M5StickC Plus' electronics is this: It's in the same circuit as the (also outgoing) red LED, and depicts the actual IR device as a transmitting diode - the arrows are going out of the diode, not into it. That being the case, I think a separate IR receiver diode is required to add IR reception capability to the M5StickC Plus. Luckily, adding one is not that complicated. The female pin header side of the M5StickC Plus conveniently provides 3.3V (which is the "appropriate" voltage for most IR receiver modules), ground and a couple of GPIO connections (one being G25/G36, the other G26). One of the latter can be used for the data pin of the receiver module while still allowing the other to control the connected LEDS, if those aren't hooked up to the grove connector at the other side of the M5StickC Plus. If nothing else is connected to the female pin header, one could probably stick the IR receiver module pins directly into it, if only for initial testing. |
Beta Was this translation helpful? Give feedback.
-
|
@robertlipe you are absolutely correct, as I saw after your recent post and looked. I think I have some old IR receiver diodes from a mail sorting machine project from the turn of the millennium ;-). Newer ones are probably better suited no doubt. I just remembered there was an IR receiver in a Eleggo.com Uno starter kit I have and it had a generic 21 button IR remote. I'll have to see if the IR diode runs off 3.3v first. GPIO 32 and 33 are the two Grove connector I/O pins and 33 is available, but there are more IO pins on the 8-pin socket connector along with the 3.3v pin and Gnd.
You mean point any LED remote transmitter at the LED receiver? once a new compiled whatever is uploaded to the M5...and it is going to provide error feedback to PlatformIO? |
Beta Was this translation helpful? Give feedback.
-
|
Looks like Rutger has more experience with that exact combo (Since I have
never seen that stick device...) and that all sounds right to me. Somehow
you're coming up with different GPIO pin numbers. I wonder if this is the
difference in SOC PIN numbers and the board's DIP pins that they're routed
to on the edges. You may have to dig here a bit or see if you can reconcile
your pin numbers and his. (Different revisions?)
I wouldn't worry about the age. They don't go bad. IR remotes haven't
changed much (except in air conditioners, which seems to be a very European
thing....) since the 80's.
So if it prints 0x12345678 when you press UP and you want that to be
NextPallee, just hack up your local copy and change
else if (IR_STROBE == result)
effectManager.NextPalette
to
else if (IR_STROBE == 0x12345678)
effectManager.NextPalette
It'll be less painful than waiting for the endless recompiles and it's not
like you're going to submit changes for your personal remote. (Yet... until
we have a a better way of handling multiple remotes - which some chap was
working on.)
Totally worth a spin.
You may have been mislead into thinking you were going to have to deal with
this at the protocol level because of the awful/awesome way the platformio
stuff invisibly pulls in libraries and then tries to hide them from you.
Platform.ini pulls in IRremoteESP8266 and builds it and links it into every
build, whether you're building with IR or not. For example, I'm blessed
with 35 copies of it...
echo ./.pio/libdeps/*/IRremoteESP8266
./.pio/libdeps/atomlight/IRremoteESP8266
./.pio/libdeps/chieftain/IRremoteESP8266
./.pio/libdeps/cube/IRremoteESP8266 ./.pio/libdeps/demo/IRremoteESP8266
./.pio/libdeps/fanset/IRremoteESP8266
./.pio/libdeps/generic/IRremoteESP8266 ./.pio/li [ .... ]
For better and worse, platformio does a pretty good job of hiding this from
you.
…On Mon, Sep 18, 2023 at 8:23 PM aldengaw ***@***.***> wrote:
@robertlipe <https://github.com/robertlipe> you are absolutely correct,
as I saw after your recent post and looked. I think I have some old IR
receiver diodes from a mail sorting machine project from the turn of the
millennium ;-). Newer ones are probably better suited no doubt. I just
remembered there was an IR receiver in a Eleggo.com Uno starter kit I have
and it had a generic 21 button IR remote. I'll have to see if the IR diode
runs off 3.3v first.
GPIO 32 and 33 are the two Grove connector I/O pins and 33 is available,
but there are more IO pins on the 8-pin socket connector along with the
3.3v pin and Gnd.
Point your LED or
pretty much any TV, VCR, DVD, or other remote at it and see if you get
debug stuff that goes with the button pushes.
You mean point any LED remote transmitter at the LED receiver? once a new
compiled whatever is uploaded to the M5...and it is going to provide error
feedback to PlatformIO?
—
Reply to this email directly, view it on GitHub
<#428 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACCSD3ZNBFQX7AV4VFXCFW3X3DX2DANCNFSM6AAAAAA4XPARN4>
.
You are receiving this because you were mentioned.Message ID:
<PlummersSoftwareLLC/NightDriverStrip/repo-discussions/428/comments/7040516
@github.com>
|
Beta Was this translation helpful? Give feedback.
-
|
I wasn't clear enough. The 1838B 3-pin IR is recent. I have the datasheet on it, identified all the pins and there connections to their male pin header. I'm using 3.3v, Gnd and GPIO 26 on the stick's 8-pin header. During compiles I see the IR remote brand.cpp files whiz by, but don't see a way to pause the compile to read the list closely, nor is it easy for a newbie to VS/PIO to find these hidden include files that are not part of NightDriverStrip and for this hassle, and the not-so-obvious way to pause a compile process (as I'm used to being able to do with Assemblers) I'm very unimpressed with this coding platform. |
Beta Was this translation helpful? Give feedback.
-
|
Sorry. My mental health requires I exit this (and at least for a while, all other NDS) conversation for a while. You may or may not find https://docs.platformio.org/en/latest/core/userguide/cmd_run.html#cmdoption-pio-run-v useful to see what gets passed to the tokenizer on the command line. But since the platform may redefine what gets passed on the command line, it's just hard to tell. It's not you. |
Beta Was this translation helpful? Give feedback.
-
|
@robertlipe, thanks for your help and guidance. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
From watching Dave's Laser Cannon video I was under the impression that to use different strip effects (not matrix effects) all one had to do was redefine default_envs = (strip effect .h filename).
default_envs = laserline works great but that is about the only one I find that does. stareffect.h nope, snakeeffect.h nope, meteoreffect.h nope, all yield errors when attempting to compile/upload to my M5StickC Plus.
I'm totally new to PIO and my C programming days were many decades ago, so I'm a neophyte with C++.
What am I missing?
Beta Was this translation helpful? Give feedback.
All reactions