Move to PlatformIO?

[henrygab]

This repository has many branches, and many of those are hardware-specific. At the same time, there is a substantial amount of common code.

It has been my experience that PlatformIO simplifies the following, both for the initial release and for anyone who wants to make changes:

1. Tracking and installing dependencies (libraries)
2. Tracking and installing board support files (e.g., ESP32 vs ESP8266 vs QtPy vs ...)
3. Enabling configurations that are arbitrary collections of settings

made-up example configurations

a. Fibonacci32 + QtPy/SAMD21
b. Fibonacci32 + ESP8266
c. Fibonacci32 + ESP32
d. Fibonacci64 + ESP32
e. Fibonacci64 + QtPy [w/Touch]
f. Fibonacci128 + QtPy
g. Fibonacci256 + QtPy
h. Fibonacci512 + QtPy
i. Fibonacci512 + ESP32 [w/Touch, I2C LCD, and JTAG]

4. Writing built binaries to the device
5. Viewing serial port output (e.g., after device boots with new build)
6. Building all supported configurations (avoiding build breaks)

While PlatformIO has some value for the creator (here's looking at you, Jason), it also has great value for purchasers. PlatformIO makes it REALLY easy to tinker, because all libraries and setup is handled by PlatformIO. No more wondering what library or version to get ... just pick a configuration and click "build".

It is my hope to combine at least the following branches, to allow building using PlatformIO for any of them via simple menu selection:

• fibonacci32mini
• fibonacci64
• fibonacci64-touch-demo
• fibonacci128
• fibonacci256
• fibonacci512mini

I would track which commit was the last one I merged into the PlatformIO branch.

@jasoncoon ... because this might be considered a "large" change, I wanted to check if this would be of interest. On the plus side, it'd be easier (single PR) to add effects to all these products at once vs current situation (either six PRs, or a PR + six merge / conflict resolutions).

If so, any thoughts before I start (such as other branches to include) would be most welcome.

[jasoncoon]

Sounds amazing! Also sounds like it will break compatibility with the Arduino IDE? I'd love to see what this looks like in a branch in your fork. As long as it's kept in a branch, and most changes are still made in main and then merged into the other branches it sounds fine to me.

[henrygab]

Somewhat surprisingly, it appears simultaneous support for both Ardiuno IDE and PlatformIO is possible. :)

Would you be open to moving the source files into subdirectory?

This will actually help for Arduino, and should be done first.

Arduino requires the parent directory name matches the sketch (.ino) name. With the current setup, because the sketch is in the root directory, it constrains where the user can clone the project.
For example, I cannot have two subdirectories in my projects folder, both cloning this depot, because one of them will need to have a name that does not match the sketch file. Arduino will simply break, and complain that the sketch name has to match the directory name.

Therefore, moving the sources to a subdirectory is a "good thing" for Arduino. (It's also a "good thing" for PlatformIO.)

Note: If you want minimal change, then I'd recommend the subdirectory be called esp8266-fastled-webserver. If you want to change the sketch name, such as to fibonacci, this would be the time to do so.

I am happy to make all the changes to move stuff. git mv will be used, to ensure history is retained. The PRs would then be provided for your review, and be limited to only the moving of the sources.

Presuming yes:

1. What subdirectory (and thus sketch name) would you like to use for the sources directory? (e.g., esp8266-fastled-webserver? fibonacci? other?)

2. What branches are "active" branches? (I would do the legwork for all these branches for the file move...)

[jasoncoon]

1. Yes, moving the source files would be fine with me. Let's keep esp8266-fastled-webserver.
2. Active branches:
   • 1628-rings
   • All of the fibonacci* branches
   • kraken64
   • parallel

[henrygab]

Jason, could you do me a favor?

1. enable verbose compilation in your Arduino IDE
   

2. build a binary for Fibonacci 256

3. Zip up the full build logs and attach to the reply

Why? I need to work through the list of dependencies ... the README.md doesn't list them all, and this is the lowest-overhead way I could think of to get the list that you use when building.

[jasoncoon]

Only these are user libraries:

• FastLED: https://github.com/fastled/fastled
• NTPClient: https://github.com/arduino-libraries/NTPClient
• WiFiManager: https://github.com/tzapu/WiFiManager

All of the other libraries are included with the ESP8266 core.

Using library FastLED at version 3.4.0 in folder: /Documents/Arduino/libraries/FastLED 
Using library NTPClient at version 3.2.0 in folder: /Documents/Arduino/libraries/NTPClient 
Using library ESP8266WiFi at version 1.0 in folder: /Library/Arduino15/packages/esp8266/hardware/esp8266/2.7.4/libraries/ESP8266WiFi 
Using library ESP8266mDNS at version 1.2 in folder: /Library/Arduino15/packages/esp8266/hardware/esp8266/2.7.4/libraries/ESP8266mDNS 
Using library ESP8266WebServer at version 1.0 in folder: /Library/Arduino15/packages/esp8266/hardware/esp8266/2.7.4/libraries/ESP8266WebServer 
Using library ESP8266HTTPUpdateServer at version 1.0 in folder: /Library/Arduino15/packages/esp8266/hardware/esp8266/2.7.4/libraries/ESP8266HTTPUpdateServer 
Using library ESP8266HTTPClient at version 1.2 in folder: /Library/Arduino15/packages/esp8266/hardware/esp8266/2.7.4/libraries/ESP8266HTTPClient 
Using library EEPROM at version 1.0 in folder: /Library/Arduino15/packages/esp8266/hardware/esp8266/2.7.4/libraries/EEPROM 
Using library WiFiManager at version 2.0.3-alpha in folder: /Documents/Arduino/libraries/WiFiManager 
Using library DNSServer at version 1.1.1 in folder: /Library/Arduino15/packages/esp8266/hardware/esp8266/2.7.4/libraries/DNSServer 

[henrygab]

9 out of 9 branches have been combined

Branches to be combined

• main
• fibonacci256
• fibonacci512mini
• fibonacci128
• fibonacci64
• fibonacci32mini
• kraken64
• parallel (aka ESP8266 Thing)
• 1628-rings

---

For early review / tracking completion

• Combined branch (pre-Platform IO integration, takes squashed commits from dev branches)
• First dev branch (got main and fib256 building)
• Second dev branch (added fib128, fib512, section headers for HTML to make it much more usable)
• Third dev branch (adding fib64, fib32)
• Fourth dev branch (to add kraken64)
• Fifth dev branch (to add parallel)
• Sixth dev branch (to add 1628-rings)
• Seventh dev branch -- for code cleanup, rename of .h files to .cpp where appropriate, header file generation, etc.

---

List of dependencies

With the following libraries, compiles in Arduino IDE:

Library	PlatformIO name	Version	Notes
FastLED	fastled/FastLED	3.4.0
NTPClient	arduino-libraries/NTPClient	3.1.0
WiFiManager	tzapu/WiFiManager	2.0.4-beta
IRremoteESP8266	crankyoldgit/IRremoteESP8266	2.7.20	(1)
CNL	SimpleHacks	1.1.7	(2)

(1) The IR library is not used by Fib256. However, some boards enable people to add an IR, so want to list the version of this library that would be used.

(2) NOT currently used, but a potential future library. The Compositional Numeric Library provides the ability to perform fixed-precision math. This may be helpful for boards that lack hardware floating point acceleration (e.g., ESP8266, AVR, QT Py). Even ESP32 only has hardware acceleration for floating point multiplication, so effects heavy on floating-point division also has potential improvements. CNL 1.x works with C++11. However, the normal distribution requires std::to_string. There are plans to have the SimpleHacks branch of v1.x support building in the Arduino environment directly.

---

[henrygab]

@jasoncoon -- Could you help me by answering a few questions? I'll try to make most of them simple yes/no or multiple-choice. :)

---

(expand) Seven simple + one additional question

1. For the Fibonacci64Nano, it appears that you left the LED_TYPE as WS2812B. Can you confirm that this is correct / intentional (and not set to SK6812)? I ask because FastLED uses different timings for the two controllers.

2. Can you confirm that, if it's "free" to enable, you'd want all the effects enabled for all sizes of the product? Specifically, Fibonacci versions of: swirl, fire, water, emitter, ... E.g., you just didn't have those functions written at the time a given board was released, and you added new effects only into the newer boards?

3. Can you confirm that, even though "free" to enable, you'd still want all the "swirl" analog clocks disabled when fewer than 128 pixels? E.g., Maybe you thought the swirl needed more pixels to look great, so disabled on Fib64/32 products?

4. Would you be OK with me changing the EEPROM layout? Most critically, I'd want to make the layout the same for all products. It'd also allow reducing EEPROM updates when values don't change, transaction-safe updates, etc.

5. Can you confirm my understanding that the different radii listed in drawAnalogClock() represent the maximum index into the fibonacciToPhysical[] mapping that would be have the clock hand overlay applied? Thus, these values must differ for the different board's pixel counts, because the largest value is NUM_PIXELS - 1.

6. For the Fibonacci512 board, you added an additional array, radii[], which simply stored the values from physicalToFibonacci[] shifted right by one (divided by two). Can you confirm this was done to provide slightly "larger" bands of color on the large 512-pixel canvas? This array is only used in radiusGradientPalette() and radiusPalette().

7. Can you confirm that this is a bug that will infinitely loop for Fibonacci512? Specifically, because the index is of type uint8_t and NUM_LEDS is defined as 512, the variable i will increment from 0...255, and then increment to 0 again ... thus never exiting the loop?
   

   esp8266-fastled-webserver/Noise.h

   Lines 90 to 92 in 94b7856

   	void drawNoise(CRGBPalette16 palette, uint8_t hueReduce = 0)
   	{
   	for (uint8_t i = 0; i < NUM_LEDS; i++) {

8. Finally, can you confirm that I am understanding (fairly closely) how the arrays in map.h are generated for the fibonacci boards? Specifically, the transformation of the X/Y coordinates to fit within range [0 .. 255], and conversion of angle to a unit where 256 of those units == 360 degrees?

---

(expand) Foundation: How the arrays in map.h are created

It appears that all the boards were generated using the standard vogel model.

That is, the first pixel is at the origin (pre-transform). One alternative is to offset the first pixel by a fixed amount, such as when desiring to enforce a minimum spacing requirement between pixels. However, this offsetting does not appear to have been done, as the first element of angles[] is always 0.)

Because the process transforms the positions, we can begin using unit values, simplifying the equations slightly.

1. Using radial coordinates, the Nth pixel's position is defined as:

r = sqrt(n)
theta = n * GOLDEN_ANGLE

2. Calculate all coordinates, giving Vogel's model centered at the origin
3. Store theta in angles[] (after converting to units where 256 units == 360 degrees)
4. Convert the radial coordinates to cartesian (x/y) coordinates
5. Transform the coordinates, such as via following psuedo-code:

// first, translate from origin == center so left side and bottom aligned with X/Y axis
double shiftX := min(originalCoordinatesX[]);
double shiftY := min(originalCoordinatesY[]);
double translatedX[] <== originalCoordinatesX[] - shiftX; // shifts right to align left side with X=0
double translatedY[] = originalCoordinatesY[] - shiftY; // shifts upward to align bottom with Y=0
// next, scale so that values lie entirely within the range [ 0.0 ... 256.0 ]
double maxXY = max(max(translatedX[]), max(translatedY[]);
double scaleFactor = 256.0 / maxXY;
double scaledX[] = translatedX[] * scaleFactor;
double scaledY[] = translatedY[] * scaleFactor;
// finally, convert to integer values in the range [ 0 ... 255 ]
uint8_t coordsX[] = (uint8_t)(scaledX[] - 0.5); // subtract 0.5 to avoid bias
uint8_t coordsY[] = (uint8_t)(scaledY[] - 0.5); // subtract 0.5 to avoid bias

---

Thanks!

[jasoncoon]

Thank you so much for all of the thought and effort you've put in to this effort so far! I really appreciate the yes/no format! 😆

1. It was not intentional, but seems to work fine? 😅
2. Absolutely. Most questions like that, with regard to this repository, can be answered by "I just didn't have or take the time to port it to all of the different branches".
3. If free to enable and it works, I'm fine with them being enabled. Honestly all of the clock functionality was experimental and just needs more time and testing.
4. Yes, as long as it can be handled in a backwards-compatible manner, like using a new version "magic number" to detect that settings should be reset to default, as opposed to accidentally loading the wrong settings.
5. Ah, you're right. I meant start and end radius to always be a one byte scale (0-255). The physicalToFibonacci map is exactly that, but only for F256. For other LED counts, I need to add or calculate a radius map (for F128, it would just be physicalToFibonacci[i] * 2, for F64 it would be physicalToFibonacci[i] * 4, etc. As I said, I haven't tested the clock functionality much, and even less on branches other than F256.
6. Same as 5 above.
7. Yes, nice catch. 😅
8. Yes, exactly.

Regarding mapping, all of that would be true, except: all LED positions/radii are actually shifted slightly. F256, for example, has LED0 at (83, 86.41) (XY, in mm) where the center would be (83, 83). The first LED is still always at angle 0.

Here are the mapping spreadsheets that I used for each board. For each of them, the x, y, and a columns are the same values used to lay out the PCBs. the x256, y256, etc columns are all mapped from those values to one byte.

• F512: https://docs.google.com/spreadsheets/d/1rawK-cG8d40yJjhzkQBb7IQ1f4qu8YlI_lmE8m3o-qM
• F256: https://docs.google.com/spreadsheets/d/1vrp3u4lPdo-fXrKE24U-yrlEvtgxa_5VCWYrCapL-9c
• F128: https://docs.google.com/spreadsheets/d/1eUB-qWStZ-ZuoXd7gk7oNchOEnAfDlQ0LZwNYpJi6H8
• F64: https://docs.google.com/spreadsheets/d/1I_DT5XyDIVshvRwymGS_oaJbiBXykuTK3auDDr3K0Mc
• F64 Micro & Nano: https://docs.google.com/spreadsheets/d/1xiduInotYQU7NunYOfD9yOA25d0omLINjD6YECnyJqI
• F32: https://docs.google.com/spreadsheets/d/1LiiiNbsjFFXiHoQbFzNFYi0ND9aY9GilJuEz5Y5EAXc

[henrygab]

I'm just doing some cleanup, and I need your help understanding what the right fixes are. This all relates to the data in map.h for the 1628 Rings. There is definitely some review, but I have tried to present the background and my understanding in a simple way, and if my understanding is sound, this will keep your answers to two of the three questions as simple "Yes/No" answers. 👍

---

IMPORTANT -- Review output as background to questions

I wrote some validation code, to help me validate my understanding of the existing 1628-rings code. The link goes to godbolt.org, which will compile and execute that validation code and show the console output ... all via the web (nothing local for you to do).

The validation code also pre-calculates the values for x and y from the polar noise function:

esp8266-fastled-webserver/PolarNoise.h

Lines 19 to 32 in e2103ea

	void drawPolarNoise(CRGBPalette16 palette, uint8_t hueReduce = 0)
	{
	for (uint8_t ringIndex = 0; ringIndex < ringCount; ringIndex++) { // y
	uint16_t ringStart = rings[ringIndex][0];
	uint16_t ringEnd = rings[ringIndex][1];
	for (uint16_t i = ringStart; i <= ringEnd; i++) { // x
	uint8_t x = (i - ringStart) * (256 / (ringEnd - ringStart));
	uint8_t y = ringIndex * (128 / ringCount);
	int xoffset = noisescale * x;
	int yoffset = noisescale * y;
	uint8_t data = inoise8(x + xoffset + noisex, y + yoffset + noisey, noisez);

Those pre-calculated values are stored in polar_x[] and polar_y[].

Output Sections

I've added three blank lines between sections of output.

The first section of output is from the validation of the ring structure. This validation ensures that the angle (in the angles[] array) for the first pixel of each ring is zero. If there's any mismatch, it dumps the rings[][] data, including the number of pixels calculated to be in each ring.

The second section of output is from validation that, for each ring, the radii[] values are constant. After all, this is mapping a series of concentric rings. Where there is a detected mismatch, I dump pixel information.

The third section of output notes that the values in angles[] does NOT match the values in polar_X[] (see above function). It then dumps the information for the first 3+ rings of pixels for easy visual review, to make it easier to review the behavior of what was previously dynamically-generated data.

---

Question 1 -- correct number of pixels per ring?

As you can see from the output (sections 1 & 2), it appears that there is a mismatch between the rings[][] data, and the other coordinates / angles / radii data.

QUESTION 1

Can you verify (on the actual physical board) how many pixels are supposed to be in ring indices 13..14?
(aka rings 14-15 if using one-based numbering)

• Answer A: 111, 117 ... rings[][] is correct, and the values for radii[] and angle[] need updates (and maybe also coordX[] and coordY[]
• Answer B: 110, 118 ... radii[] and angle[] are correct, just a simple typo in rings[][2] on number of pixels in these rings...
• Answer C: Neither of the above... the corrected data structures for map.h are in the following gist.... (insert gist here), giving coordX[], coordY[], angles[], radii[], and rings[][2].

I am presuming the answer is B ... and that just modifying the rings[][] structure accordingly will be the right fix.

---

Question 2 -- Intentionally non-smooth polar function?

Recall that the code snipped pre-calculates polar_x[] and polar_y[] based on the polar noise code:

esp8266-fastled-webserver/PolarNoise.h

Lines 19 to 32 in e2103ea

	void drawPolarNoise(CRGBPalette16 palette, uint8_t hueReduce = 0)
	{
	for (uint8_t ringIndex = 0; ringIndex < ringCount; ringIndex++) { // y
	uint16_t ringStart = rings[ringIndex][0];
	uint16_t ringEnd = rings[ringIndex][1];
	for (uint16_t i = ringStart; i <= ringEnd; i++) { // x
	uint8_t x = (i - ringStart) * (256 / (ringEnd - ringStart));
	uint8_t y = ringIndex * (128 / ringCount);
	int xoffset = noisescale * x;
	int yoffset = noisescale * y;
	uint8_t data = inoise8(x + xoffset + noisex, y + yoffset + noisey, noisez);

It appears that the value being computed for x (see polar_x[]) is intended to be a smooth value, essentially corresponding to the angle of the pixel. However, the actual values calculated do not actually correspond to the angles for each pixel. In addition, they result in values that do not provide smooth transition between the first and last pixels. (Could this be why there is the commented-out attempt to "smooth" the start & end of each ring?)

See the third section of the output from the godbolt.org snippet, specifically the angle and polarX columns. As you can see, the values start similar, but diverge more and more as the near the end of each ring.

Using the angles[] data directly should give the smooth result this appears to be expecting, and reduce computation per loop also.

QUESTION 2:

Can you confirm that, instead of calculating the x value in that polar noise function, the function should instead use the corresponding angles[] value for that pixel?

• Answer A: Yes! That will result in smoother color transitions (both within a ring, and across multiple rings), and is what I intended.
• Answer B: No! I intentionally want this different calculation used for concentric rings.

---

Question 3 -- Avoid calculating `y` in polar noise function?

Similar to the above, it's clear that the the calculations for the x and y values depend only upon the constant rings[] array. As hinted at in question 2, t he x value appears to be an attempt to calculate the angle (in unit256).

Similarly, the y value appears to be intended to store a value in the range [0 ... 127], with higher rings have correspondingly higher values. As a result, approximately half the palette will be visible at once, smoothly interpolated across the rings.

esp8266-fastled-webserver/PolarNoise.h

Line 27 in e2103ea

uint8_t y = ringIndex * (128 / ringCount);

However, the calculations for y end up providing a slightly reduced range of values:

y = ringIndex * (128 / ringCount);
y = ringIndex * (128 / 20);
y = ringIndex * 6;

Therefore, y is only in the range [0 .. 114], rather than the range [0 .. 127].

Note that map.h defines the array radii[], containing a scaled radius to fit in the range [0..255].

QUESTION 3:

Can the calculation of y be replaced with simply using radii[i] / 2u?

---

OK, that's as simple as I could make the questions. Looking forward to hearing from you.

[jasoncoon]

Thanks again for your help on this!

1. B. It should be 110 & 118, must have been a typo?
2. A.
3. Sounds good to me!

[henrygab]

Great, I think I already made those changes in my combined_dev7 branch. I'll be offline a few days, but I hope my next question will be about how to best test the changes (I have only Fib256 hardware...).

Currently, everything is still arduino based (so slow builds), but changing between products is a one-line change in config.h.

I expect stuff to either work perfectly, or crash for obvious reasons.

[henrygab]

Well, I'm essentially done with the changes to move all the code into a single branch.

Under Arduino, switching between "products" is a single-line change.

I've put up draft PR #211. I will move it away from draft status after I do some testing (primarily using print statements, since I can't really test the boards I don't have). Even without hardware, running each "product" without anything attached would at least catch any obvious crashes. The rest of the changes really center around which defaults are used for each board.

but ... it is a large set of changes, so I must ask:

---

@jasoncoon -- is PR #211 already beyond what you'd consider approving as a PR?

---

Admittedly, as with any PR, there are one-time costs for review and validation. At the same time, there are benefits, such as having a single branch for bug fixes, new effects, etc. Of course, the real benefits will flow from platformio support ... easier builds for any product, alternate MCU support including esp32, ability to use VSCode with proper code-completion and click-to-definition, etc. But, I want to ensure you have the Arduino-focused solution first, as you expressed concern about breaking compatibility with Arduino.

Of course, I am open to other changes that you'd want to see in the layout of the files, questions, change requests, etc.

[henrygab]

OK, most significant pre-requisite changes are now in main branch via PR #211.

Now to work on PlatformIO, when real life doesn't intrude...

[henrygab]

🎉 @jasoncoon ... It may have been easier than I thought, once all the prerequisite work was complete. 🎉

See PR #212, currently in draft status (generates and uploads both sketches and filesystem).

How to use in VSCode

1. Install Visual Studio Code (obviously)
2. Follow PlatformIO's short install instructions
   Note that some icons may differ slightly.
3. Close VS Code entirely

---

First build using PlatformIO in VSCode

1. In console window of your choice (e.g., cmd.exe),
   go to the root of where you cloned the git depot.
   Yes, there will be a "platformio.ini" there, if you
   are using the changes from the PR.
2. In the console, type code . to open the editor
3. Give it a little time to finish loading.
4. Click on the "alien head" icon in the left toolbar (#1 in image)
5. You should now see a list of tasks.
6. Expand the Default task and the fastled_webserver task (#3 in image)
7. The image should now look similar to the above
8. Under Default, choose Build All task (#2 in image)
9. Watch as all seven "products" are built
10. Under fastled_webserver, choose Build task (#3 in image)
11. Watch as compilation flies, due to cached build files! 👍
12. Optionally, choose Upload to push that build to the attached ESP8266
13. Optionally, choose Build Filesystem Image (#5 in image)
14. ... and then choose Upload Filesystem Image (#6 in image)

That's it! You've now compiled all seven "products", and then built / uploaded both the binary and the associated file system for the default (no product) build environment.

---

Other tips

By default, the bottom bar includes an indication of the current build environment. You can click this directly to change to a different build environment:

Note, however, that the prompt will appear at the top of the screen for which environment you want to switch to:

You can also access this entirely using the keyboard as follows:

1. CTRL-SHIFT-P to open the prompt shown above
2. Begin typing: platformio: env and hit enter (notice the completion mode)
3. Select the target environment (e.g., using up/down arrow keys, then enter)

---

Benefits include:

• Intellisense! Yes, the editing experience enters the 21st century. You can right-click on a variable or function, and get context-sensitive information, or jump to where a function is used, defined, etc. This alone is worth its weight in gold!
• Code Highlighting. Code sections are highlighted properly, based on the current #define results. For example, open map.cpp, and then switch between the different products (allowing Intellisense index to update in between). You will see that only one definition of angles[] remains color-coded, and it corresponds to the environment you chose.
• Fast builds. Thanks to PlatformIO's support for caching builds, it will only compile what changed.
• Dependency Management. No longer do you have to tell people to install a specific version of a library (e.g., because the newest version introduced a bug). Libraries are automatically downloaded, and any given environment (aka product) can add additional libraries, or override the version used of any library.
• Quick Sanity-Checking Builds. Just choose Build All from the Default task, and it will build all the environments. Allows for quickly checking if you broke the build with a change.

There's more, of course, but the above are some of the obvious benefits. Give it a try!

Let me know what you think?

[jasoncoon]

Thanks again! Sorry for the delay, I'll get this tested, approved, and merged tonight!

[henrygab]

All good. Life is more important, after all. Take your time. 🙂

Unrelated, but provides such high benefit, I must spread the knowledge

If you've had weird, and especially intermittent, networking problems (programs failing to start, DNS seemingly failing, whatever), check the following post of mine. While the user-facing symptoms are frustratingly hard to correlate to this root cause, the root cause itself is easily detectable and the fix is REALLY simple.

platformio/platformio-vscode-ide#2667 (comment)

Since it removes aggravation, and is so easy to detect and fix, please keep it in mind if you see someone hitting such odd problems....

[henrygab]

PlatformIO is now a supported option, although you can still build using Arduino.

Woo-hoo!

[jasoncoon]

I've been trying to spend a little spare time here and there trying to get ESP32 support working, but have not yet succeeded. Anyone else try?

In particular, I would love to be able to get wi-fi setup over BLE working: https://www.improv-wifi.com

Also spent a little time updating this project, and making sure it still works: https://github.com/jasoncoon/esp32-fastled-ble
It uses a web page that could be hosted anywhere, including locally, connects and allows control via web BLE. It's significantly easier to use initially than wi-fi.