RESOLVED - UNO vs. NANO exhibit different behavior FASTLed APA102

I have a functioning prototype that works on UNO (ATmega328P). When I switch over to NANO (ATMEGA328), the behavior is all wrong. The project uses the FASTLed library with APA102 LEDs

I was getting a upload issue with the Arduino IDE (1.8.13) , updated the drivers and that issue appears to have been resolved. I get good compilations and uploads now.

Code is as follows:

#include <FastLED.h>

// How many leds in your strip?
#define NUM_LEDS 60

// For led chips like Neopixels, which have a data line, ground, and power, you just
// need to define DATA_PIN.  For led chipsets that are SPI based (four wires - data, clock,
// ground, and power), like the LPD8806, define both DATA_PIN and CLOCK_PIN
#define LED_PIN 11 //GREEN
#define CLK_PIN 13 //BLUE
#define LED_TYPE APA102
#define COLOR_ORDER BGR
#define NUM_LEDS    58
#define BRIGHTNESS  150
#define FRAMES_PER_SECOND 10

// Define the array of leds
CRGB leds[NUM_LEDS];

const TProgmemRGBPalette16 MyLavaColors_p FL_PROGMEM =
{
    CRGB::DarkRed,
    CRGB::Maroon,
    CRGB::DarkRed,
    CRGB::Maroon,

    CRGB::DarkRed,
    CRGB::Maroon,
    CRGB::DarkRed,

    CRGB::DarkRed,
    CRGB::DarkRed,
    CRGB::Red,
    CRGB::Orange,

    CRGB::White,
    CRGB::Orange,
    CRGB::Red,
    CRGB::DarkRed
};

const TProgmemRGBPalette16 MyForestColors_p FL_PROGMEM =
{
    CRGB::DarkGreen,
    CRGB::DarkGreen,
    CRGB::DarkGreen, //DarkOliveGreen,
    CRGB::DarkGreen,

    CRGB::DarkGreen, //DarkOliveGreen,
    CRGB::DarkOliveGreen, //DarkGreen,
    CRGB::DarkGreen, //DarkOliveGreen,
    CRGB::DarkGreen,

    CRGB::Green,
    CRGB::Green, //ForestGreen,
    CRGB::Green,
    CRGB::Green,

    CRGB::DarkGreen, //LawnGreen, //LightGreen,
    CRGB::DarkGreen, //LawnGreen,
    CRGB::DarkGreen, //LawnGreen, //LightGreen, //MediumAquamarine,
    CRGB::DarkGreen, //LawnGreen //ForestGreen
};

CRGBPalette16 currentPalette(CRGB::Black); //initialize to BLACK for fade on affect
CRGBPalette16 targetPalette(MyLavaColors_p); //initialize target palette to LAVA colors
//CRGBPalette16 targetPalette(HeatColors_p);
//CRGBPalette16 targetPalette(ForestColors_p);
String palette = "Lava"; //used for debuging


const unsigned long lavaDur = 600000; //show lava for 600 seconds (10 minutes)
const unsigned long forestDur = 30000; //show forest for 30 seconds

unsigned long currentTime = 0; //initilize current timer
unsigned long previousTime = 0; //initialize previous timer
unsigned int x = 0; //used for debugging

void setup() {
  /* used for debugging 
  Serial.begin(9600);
  Serial.println("resetting");*/
  
  delay(3000);
  LEDS.addLeds<LED_TYPE, LED_PIN, CLK_PIN, COLOR_ORDER>(leds, NUM_LEDS);      // APA102, WS8201
  LEDS.setBrightness( BRIGHTNESS );
}

void loop() {
  currentTime = millis(); //start timer

  /* debugging, curious what is going on under the hood 
  EVERY_N_SECONDS(1) {
    x++;
    Serial.print(x);
    Serial.print(": ");
    Serial.print(" palette: ");
    Serial.println(palette);
  }*/

  /* After 10 minutes, set color palette to Forest */
  if (currentTime - previousTime >= lavaDur) {
    targetPalette = CRGBPalette16(MyForestColors_p);
    //palette = "Forest";
  }

  /* After 30 seconds, set color palette to Lava */
  if (currentTime - previousTime >= lavaDur + forestDur) {
    targetPalette = CRGBPalette16(MyLavaColors_p);
    //palette = "Lava";
    previousTime = currentTime;
  }

  /* Fill LEDS with noise colors */
  fillnoise8();

  /* fade colors from current palette to target palette */
  EVERY_N_MILLIS(10) {
    nblendPaletteTowardPalette(currentPalette, targetPalette, 48);          // Blend towards the target palette over 48 iterations.
  }

  /* show LEDs */
  LEDS.show();                                                              // Display the LED's at every loop cycle.
}


void fillnoise8() {

#define scale 30                                                          // Don't change this programmatically or everything shakes.

  for (int i = 0; i < NUM_LEDS; i++) {                                      // Just ONE loop to fill up the LED array as all of the pixels change.
    uint8_t index = inoise8(i * scale, millis() / 10 + i * scale);           // Get a value from the noise function. I'm using both x and y axis.
    leds[i] = ColorFromPalette(currentPalette, index, 255, LINEARBLEND);    // With that value, look up the 8 bit colour palette value and assign it to the current LED.
  }

} // fillnoise8()

I suspect it is something that is not quite compatible in the FASTLed.fillnoise8() method.

Any ideas what may be going on?

I have videos of the behavior but apparently mp4 or mpg-1 files are not allowed.

Is there a way to upload video's as attachments?

Hate to say this, but you might have to YouTube them! :astonished:

This is a link to a video of the UNO project, it works as designed: Good Behavior

This is a link to a video of the NANO project, it does NOT work as designed: Bad Behavior

I've spent a fair amount of time researching possible issues. I can't seem to find any good leads.

I don't get it. It's the same code (Arduino IDE 1.8.42.0, FastLED 3.003.003), same chip (sorda - ATmega328P vs ATmega328), no compile errors, good upload, same basic connections.

Thanks,
Mike

Mike, as you said, the Uno and nano are based on chip which are 99.9% similar so almost zero chance this is a software thing. Please post a schematic of the Nano circuit, with paticular attention to power supply. Hand drawn is fine.

100% the same die inside the package. Nano brings 2 more pins out for analog input use, and 2 more power/gnd pins.
Hence 32 pins vs 28 pins. The die itself is 100% the same.

328 vs 328P, there is a difference there, but it's very subtle, and one has to go thru the data sheet to find it.
And if I recall it's mostly in things like current draw, brown out level, but not in major functionality.

Real NANOs use 328P. Fakes/counterfeits/clones may use 328.

OK, I feel like an idiot. I found the problem.
Apparently it helps to have everything on a common ground. Who'd a thunk it.

I'll post up some chicken scratch schematics that will show the errors of my ways.

Thanks to @PaulRB who caused me to second guess my wiring. Definitely an ID-10-T error.