Hello,
is it possible to have complete control about connected neopixels inside the loop of a custom prop without using the config definitions?
E.g. to display an image on a 8x8 neopixel display or create very custom neopixel behaviours.
I already tried to use the official fastled lib additional installed but it tells me, that it’s not implemented for this processor.
And there is already a neopixel port implementation in ProffieOS, so it would make sense to use this instead of running a second version in parallel.
Thank you and best regards
Daniel
Short answer is yes.
While you could use fastled to do it, it’s probably easier to just write a style for it.
All you need is something like this:
class MyAmazingStyle {
void run(Blade *blade) {
// here you can do once-per-frame computations.
}
// This function is called once for every led on the blade.
SimpleColor getColor(int led) {
return Color16(65535, 0, 0); // red
}
};
You can put the Style in the CONFIG_PRESETS, or in CONFIG_STYLES, and then use it like any other style, like: StylePtr<MyAmazingStyle>().
ProffieOS will update the blades as quickly as it can, and also dither the 16-bit colors to 8-bit colors.
If you literally just need an 8x8 image, you may also want to check out DisplayStyle:
There are lots of examples of styles in the styles directory you can look at.
It’s also possible to set up a “blade” with a style without using presets, meaning that it is entirely controlled by the prop, but it’s usually better to just have the preset system handle it.
Thank you for the fast answer. I tried to follow the way you’ve shown but struggeling at the part “you can put the Style in the CONFIG_PRESETS, or in CONFIG_STYLES, and then use it like any other style, like: StylePtr<MyAmazingStyle>().” because it says to me, “MyAmazingStyle was not declared in this scope”
I searched a lot but found no hits, how to start to create custom styles and announce them to the config. Is there a documentation about this topic?
Thanks and best regard Daniel
Technically, “the documentation” is a C++ book. 
All jokes aside, you can read about config files and their sections here:
In the example on that page, the snippet of code I showed above would go right after this line:
#ifdef CONFIG_PRESETS
Also, you’ll need to put public: before the run function, or all the methods will be private.
If this doesn’t help, post your config file here (between lines which have three ` on them) and I’ll take to get things going.
I don’t think we have a tutorial for writing styles unfortunately, but hopefully I can help you get started.
Thank you.
Do you have a hint what would be the best existing style to have a look at to get an idea how a style work (filename, name, folder, includes, base class etc.). I mean a minimal style implementation so that you can see where everything is registered?
There is no “registration”, just the name of the class.
Styles also don’t usually have base classes.
And if you write your style inside the config file, you don’t have to worry about #include statements since all of ProffieOS will have already been included. ProffieOS compiles as a single compilation unit currently.
Here the entire code for the Rainbow style: (click on the link, as the forum won’t show it all.)
For the most part, styles that aren’t part of ProffieOS should go in the config file though.
Great, thank you! I can work with that for now.
In the long term, I would prefer to be able to put the active code into classes and reuse it if necessary.
I’ll take a look at your example.
BTW: Many thanks and great respect! The project is very cool, albeit a bit powerful for beginners.
I appreciate the quick support and don’t think it can be taken for granted!
Since you mentioned C++, I have another question:
Is there a reason why the usual method of clean separation between classname.h and classname.cpp cannot be used in this project?
I have to put all my own C++ code in the H file, which is not very elegant…
To do that I recommend putting a .h file in your config/ directory with all the classes you want, then just include that file from your config file.
Most beginners do not write their own styles.
For basic lightsaber installs there are fairly simple tools and guides that people can use.
There are a few reasons why ProffieOS is written the way it is:
- At the time I started writing ProffieOS, Arduino was very bad at compiling multiple files.
- I don’t actually like writing code outside of the class. I prefer to write it in the class, no separation needed. [1]
- ProffieOS is relatively small. Traditionally, you need to separate things to avoid having to re-compile everything when you make a change. That is not particularly important for ProffieOS.
- Almost everything in ProffieOS is a template, which means it would go in the .h file anyways. Separating templates into .h and .cc doesn’t usually work out well.
- All of ProffieOS is meant to be compiled inline for speed.
Ultimately I will probably need to change some of this once ProffieOS grows big enough, we’ll see.
[1] No other programming language has a .h/.cc split. It’s an ugly thing that happened 40+ years ago because of how linkers work. Having to read two files to understand a class is not great IMHO.
Thank you - I understand your arguments. This makes sense to your project.
I agree with you about separating headers and C++, but that’s just the standard.
If you want to bring existing libraries or code into the project, you have to copy everything together again and end up with two code bases.
For example, I have existing classes and libraries that I want to use in the Proffie project because I’m switching from an ESP32 to Proffie ("working" Star Wars blaster - Daniel Springwalds Blog * Basteln mit Daniel). It would be nice if you didn’t have to completely rebuild everything.
But this is not an appeal – I just wanted to provide a broader overview of the topic.
I am fine with it as it is – I also understand that Proffie is not about writing lots of your own classes, but rather that everything should be configurable. So it is intended less for programmers and more for users.
Thank you again for your impressive work on this project
Very cool concept for that blaster. I will now look at my vape with the “what if you could be a blaster” look. 
Arduno libraries should be usable directly from ProffieOS, assuming that they work on the STM32L4 chips of course. However, there is one big caveat, which is a big part of why I have my own code for almost everything: All calls must be non-blocking. ProffieOS does not have threads, so anything which blocks will prevent everything else from happening.
A lot of arduino libraries simply busy-wait until something is finished. That is fine if your code only needs to do one thing, but when you’re driving a pile of neopixels, playing sound, animating a display and handling motion and button events all at the same time, blocking is simply unacceptable.
Bringing in classes written with .h and .cc files should also work I think. Arduino has gotten better at handling it. I just haven’t tried that, since I prefer it the ProffieOS way.
At the end of the day, ProffieOS is an environment which takes some work to integrate code into, just like any other OS I guess. It’s still Arduino, so anything that works in Arduino should more or less work in ProffieOS, it’s just a question of how well it will work.
Avoiding two code bases is usually done by abstraction. ProffieOS might have one way to do something, and ESP32 might have another. A helper class in your code which picks which call(s) to use using some #ifdefs will generally make that tidy enough… Sometimes having two implementations is unavoidable, but it’s not as bad as it sounds, because re-writing something takes almost no time compared to writing it the first time. (However, if maintaining multiple versions can be a problem long-term…)