Compiler warnings after switching from Arduino 1.6.4 to 1.6.6

I recently upgraded from Arduino 1.6.4 to 1.6.6, and am now getting the following warning:

WARNING: Category ‘’ in library OneWire is not valid. Setting to ‘Uncategorized’

I’m not even using the OneWire library (though I am using Adafruit’s NeoPixel library, which may be where the problem is). However, the code compiles fine and works on my device - a Gemma v2 - so I’m OK with ignoring the warning for now. I’d just like to know what’s causing the warning, to see if there’s anything I need to keep on my radar.

Another issue is that the compiler just increased my compiled code by some 300 bytes, pushing me well over the Gemma’s 5,310 byte code limit (I was at 5,308 bytes when compiled under 1.6.4, and that was AFTER a lot of code minimization).

Here’s the code:

// Gemma_NeoPixel_Tree
// Jeff Verive
// November 1, 2015
//
// The Gemma NeoPixel Tree is a Christmas tree made up of 6 columns of 8 NeoPixel RGB LEDs, with one additional
// NeoPixel RGB LED for the "star" on the top of the tree. All of these LEDs are connected in series to 
// create a daisy-chain of 49 LEDs, and are numbered as follows:
//   -  the star is LED#0
//   -  the bottom of the first column is LED #1, and the top of this column is LED #8
//   -  the bottom of the second column is LED #9, and the top of this column is LED #16
//   -  the bottom of the third column is LED #17, and the top of this column is LED #24
//   -  the bottom of the fourth column is LED #25, and the top of this column is LED #32
//   -  the bottom of the fifth column is LED #33, and the top of this column is LED #40
//   -  the bottom of the sixth column is LED #41, and the top of this column is LED #48

#include <Adafruit_NeoPixel.h>
//#include <avr/power.h>
#include <EEPROM.h>

// Which pin on the Arduino is connected to the NeoPixels?
#define PIN            1

// How many NeoPixels are attached to the Arduino?
#define NUMPIXELS      49
#define myDelay        50  //basic delay for some routines

// When we setup the NeoPixel library, we tell it how many pixels, and which pin to use to send signals.
// Note that for older NeoPixel strips you might need to change the third parameter--see the strandtest
// example for more information on possible values.
Adafruit_NeoPixel pixels = Adafruit_NeoPixel(NUMPIXELS, PIN, NEO_GRB + NEO_KHZ800);


int bright; // (0 = off, 255 = maximum brightness)
const int maxBright = 255;
byte previousBrightness;
void setup() {
  pixels.begin(); // This initializes the NeoPixel library.
  EEPROM.get(0, previousBrightness);
  bright = previousBrightness * 3;
  if(bright>255) bright = 28;
  EEPROM.put (0, bright);
}

void loop() {
  // For a set of NeoPixels the first NeoPixel is 0, second is 1, all the way up to the count of pixels minus one.
 
  int Red = random(4);
  int Green = random(4);
  int Blue = random(4);
  int invRed = 1 - Red;
  int invGreen = 1 - Green;
  int invBlue = 1 - Blue;
  
  for(int i=0; i<200; i++){
    int k=random(NUMPIXELS);
    if(Red+Green+Blue == 0)
      pixels.setPixelColor(k, pixels.Color(maxBright, maxBright, maxBright));
    else
      pixels.setPixelColor(k, pixels.Color(Red*maxBright/3, Green*maxBright/3, Blue*maxBright/3)); // 
    pixels.show(); // This sends the updated pixel color to the hardware.
    delay(20);
    pixels.setPixelColor(k, pixels.Color(Red*bright/3, Green*bright/3, Blue*bright/3)); //
    pixels.show(); // This sends the updated pixel color to the hardware.
    delay(80);
  }

  
  for(int i=0; i<NUMPIXELS; i++){
    //int k=random(NUMPIXELS);
    //pixels.setPixelColor(k, pixels.Color(invRed*bright, invGreen*bright, invBlue*bright)); // 
    //pixels.show(); // This sends the updated pixel color to the hardware.
    //delay(20);
    if (Red+Green+Blue != 0){
    pixels.setPixelColor(i, pixels.Color(0,0,0)); //  off.
    pixels.show(); // This sends the updated pixel color to the hardware.
    delay(50);
    }
  }

  
  for(int i=0; i<3000; i++){
    int k = random(NUMPIXELS);
    Red = random(bright);
    Green = random(bright);
    Blue = random(bright);
    pixels.setPixelColor(k, pixels.Color(Red, Green, Blue));
    pixels.show(); // This sends the updated pixel color to the hardware.
    //delay(5);
  }


    spiralPaint(1, 0, 0); //Paint in a spiral pattern. Red is on; Green and Blue are off. Delay 50ms after lighting each pixel.
    spiralPaint(1, 1, 0);
    spiralPaint(0, 1, 0);
    spiralPaint(0, 1, 1);
    spiralPaint(0, 0, 1);
    spiralPaint(1, 0, 1);
    spiralPaint(1, 1, 1);
  
  int period = 36;  
  int cycles = 6;  
  for(int j=0; j<cycles*period; j++) {  
    for(int i=0; i<NUMPIXELS; i++) {
      pixels.setPixelColor(i, pixels.Color( TriWave(period, j+i), TriWave(period, j+i+period/3), TriWave(period, j+i+2*period/3)));
      pixels.show(); // This sends the updated pixel color to the hardware
    }
  }

}
int TriWave(int period, int x) {
  float halfPeriod = period/2;
  return bright * abs((float(x % period - halfPeriod))/halfPeriod);
}
void spiralPaint(int red, int green, int blue){
      for(int i=7;i>=0;i--){
        for(int j=5; j>=0; j--){
          pixels.setPixelColor(8*j+i+1, pixels.Color(red*bright, green*bright, blue*bright));
          pixels.show(); 
          delay(myDelay);
        }
      }
      pixels.setPixelColor(0, pixels.Color(red*bright, green*bright, blue*bright));
      pixels.show();
      delay(500);
}

Any ideas?

Jeff

:frowning:

The warning can be disregarded. 1.6.6 added a new entry that can be present in the keywords.txt file, called Category. But most existing libraries don't have that entry, so they made the IDE throw a warning so people will complain to library authors, or something.

Not sure what else changed that results in the increased compile size though...

It looks like the NeoPixel library - and perhaps a few more - have changed, resulting in increased code size. I have made changes to the code to get my code under the maximum code size, but just barely (by 4 bytes).

Your sketch size problem is a perfect example of how my SmallSetup lib can rescue those slightly too large sketches.

  • In 1.6.6, download my lib 'SmallSetup from the library manager. - Include it where you include EEPROM.h - then add 'inline' to the start of the setup() & loop() functions.

This will get you to just above 100% flash. So there is one other hint I can give.

  • Your variable 'bright' is an int, change this to a byte if its maximum range is really 255.

This should also fix your EEPROM values as you are reading a byte with 'previousBrightness', but 'put'ing an int with 'bright'.

With these changes I get 5,296 bytes, which is a saving of 244 bytes.

By the looks of your code, there are additional saving to find (what you mentioned in the post above).

Give this a test if you are interested and see if everything still works (and report back please, haven't tried this on a tiny 85).

Thanks, pYro_65!

I have rewritten the EEPROM reading/writing routines: writing an integer and reading back a byte did indeed cause a problem, so I changed all of the associated variables to integer (I could have used byte values, but integer values make the code more readable for my purposes).

The SmallSetup library did do a good job of reducing compiled code size, so together with that and some more code optimization/modifications, I have saved a little over 300 bytes. Now to find a way to use those bytes to add some more dazzle to my Christmas Tree!

Finally - the NeoPixel library did increase quite a bit (at least the pre-compiled size). While I haven't checked the size difference between compiled size for the current version and the previous version, I'm happy to believe in my heart of hearts that this is the reason for my code expansion.

Jeff

Well, the SmallSetup library DID reduce code size, but the code doesn't run regardless of whether setup() and/or loop() are

void setup()
void loop()

or

void inline setup()
void inline loop()

Am I doing something wrong?