@lburelli Thanks, I'll start to strip it down until I get to a working version.
Removing the FastLED.show() does indeed "fix it".
Or cutting down my code to only operate 2 arrays of LEDs, rather than 4, seems to make it not break too.
FastLED.addLeds<WS2812B, ARM_1_PIN, GRB>( leds[ 0 ], NUM_LEDS );
FastLED.addLeds<WS2812B, ARM_2_PIN, GRB>( leds[ 1 ], NUM_LEDS );
// FastLED.addLeds<WS2812B, ARM_3_PIN, GRB>( leds[ 2 ], NUM_LEDS );
// FastLED.addLeds<WS2812B, ARM_4_PIN, GRB>( leds[ 3 ], NUM_LEDS );
I do see this from the FastLED library when compiling, not sure if it has an effect, or is something I can "do" to make it go way?
In file included from /home/rob/Arduino/libraries/FastLED/src/FastLED.h:75,
from /home/rob/Arduino/2023-12-17-04-array-of-arrays-single-function/lamp/lamp.ino:2:
/home/rob/Arduino/libraries/FastLED/src/fastspi.h:157:23: note: #pragma message: No hardware SPI pins defined. All SPI access will default to bitbanged output
# pragma message "No hardware SPI pins defined. All SPI access will default to bitbanged output"
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
btw, after some more research into the bootloader and how the controller gets programmed, I have a couple of questions...
Am I correct in thinking that the bootloader is simply a sketch that waits for commands, to program the flash? That would make sense, when I actively put the Arduino into bootloader mode, it simplifies what the controller is doing when I try to program it - and why it works everytime that way.
If that's true, is the bootloader code also somehow injected into my sketch, so the controller regularly checks for incoming updates? Or does the upload process from the IDE quickly reset the device, (into bootloader mode?) then quickly provides the new flash/program?
It's this part of re-flashing the controller while MY code is running, that's got me stumped.
Apart from that I think I understand most of it.