These are chat archives for Makuna/NeoPixelBus

5th
Mar 2016
sticilface
@sticilface
Mar 05 2016 08:49

hi... so beginning to implement your new branch... eek... there is a lot of work there. well done. Also a lot of breaking changes.. so first question.... I'm using pointers to manage everything as i want the objects to be dynamic. previously i could use

 NeoPixelBus * strip;

to declare the pointer... now i need

 NeoPixelBus<NeoGrbFeature, NeoEsp8266Uart800KbpsMethod> * strip;

which is fine... the problem is that i've put everything into headers and separate cpp files.. and i declare

extern NeoPixelBus<NeoGrbFeature, NeoEsp8266Uart800KbpsMethod> * strip;

everywhere...

now i would like this to be 'defined' in the main sketch and have it propagated everywhere so that the user only has to change one line to change the pointer template.. does this make sense? what is the best way to do this... am i right in thinking it will have to be a #define and not typedef, as templates are preprocessor?

Michael Miller
@Makuna
Mar 05 2016 08:57
Create a header file and put a typedef in it. I just closed an issue showing how to do this.
sticilface
@sticilface
Mar 05 2016 08:58
oops :) sorry
Michael Miller
@Makuna
Mar 05 2016 08:58
Typedef NeoPixelBus<blah,blah> MyNeoPixelBus;
then you can just use MyNeoPixelBus, or whatever name you like 😃
The common header is needed so other Cpp and the main ino can include it.
Michael Miller
@Makuna
Mar 05 2016 09:03
P.s. templates are compiler feature
While uncommon, you sometimes see pointer typedef also
Typedef neopixelbus <blah,blah>* PMyPixels:
Michael Miller
@Makuna
Mar 05 2016 09:10
The other change will be the animator isn't tied to bus object anymore. The channels could be per pixel or only need one channel to do all your animations on. The loop example shows how to share channels and request channels when you need to start a new animation.
Due to this, the animator callback takes a param struct with all the interesting things included, including those new flags so you don't have check for 1.0 when finished.
sticilface
@sticilface
Mar 05 2016 09:23
i saw all those feature... and the easing stuff.. looks very cool.
sticilface
@sticilface
Mar 05 2016 09:37
ok. got it to work. is there any way to get that typedef inside the main user sketch?
seperate header works..
sticilface
@sticilface
Mar 05 2016 13:50
I like this new way of doing things... now.. one animator per object... = no heap usage.. and animator is handled by the effect, and not by my class stuff.. which is good..
thanks
Michael Miller
@Makuna
Mar 05 2016 19:00
There is no way to define it in the INO and have it available in cpp's.
Normal practice in C/C++ is to keep code in files "disconnected", otherwise just put it in one large file. Generally try to keep global variables (like strip) to a few as it is considered poor coding style; but this style is promoted my Arduino examples. NeoPixel strip is fine example to leave as global.
By following this guidelines, it makes it easier to move pieces from project to project or even put them into their own library. SticilFaceEffects library of cool NeoPixel animations ;-)
sticilface
@sticilface
Mar 05 2016 19:27
ok, cheers
i've not got that many effects yet... but i have ported adalight, dmx and dup handles.. and written a whole backend to handle saving and retrieving variables to spiffs, and serving them up to a webpage.. really easily... so adding a variable to an effect say.... bool magictouch1 only becomes a few lines of code. its working pretty well...
so far
thats occupied most of my time so far
sticilface
@sticilface
Mar 05 2016 19:48
based on what you've said.. would it be better for me to pass the strip and animator to each effect class so it is totally independent? although everything is pretty much intertwined...
can take a look if you fancy... and advice appreciated...
sticilface
@sticilface
Mar 05 2016 19:54
it depends on the jQuery files being uploaded, and unless you put the ESPmanager on there too they won't be in the right place... their location can be changed in the index.htm though. i have to make this bit of it easier..
Michael Miller
@Makuna
Mar 05 2016 21:32
Within the context of Arduino best practices, I think major objects that represent core concepts of your sketch (WiFi, NeoPixel, Storage) are fine being global.
It just means that as the sketch grows, you need to move them (definition, setup, etc) out of the sketch and into their own "setup.h" / "config.h" / "buildout.h" file for other pieces to include.
Just pick a good name that makes sense, I used those three as an example for one.
sticilface
@sticilface
Mar 05 2016 21:35
ok cool, cheers. that is what i've been doing.. and then the user just 'has to be aware' of their names.. but i guess that is the arduino way
Michael Miller
@Makuna
Mar 05 2016 21:37
Yeah, I had seen some libraries that expose an already created object you just have to know about. Early pre 1.0 Arduino libraries this was more common.