A little confused about data types in PROGMEM

Usually, when I program an array with binary notation I use the following format - B00001100. The compiler quite happily accepts the capital B for binary and I've not had any problems using that notation as opposed to 0b00001100 using the zero b prefix. However, recently I've been using PROGMEM as my arrays are getting a bit big, and also ( don't ask why, we'll be here all day ), I've needed to make an array that contains 9 bit elements. So I've declared the array as the word data type, entered my elements and carried on. But, when I compile, the sketch I get, for example, "B000011001 ( 9 bits ) was not declared in this scope". If I change the array elements to use the zero b prefix, such as 0b000011001 ( 9 bits ), everything compiles just fine and the program runs as expected.

I can't understand why the compiler will accept PROGMEM elements using the zero b prefix but not the capital B prefix for binary. This is the first time I've used PROGMEM with binary notation, so I may be missing something. Can anyone tell me where I'm screwing up, please!

Here's the absolute basic code I've been using showing the binary notation I use, but which will not compile:

#include <arduino.h>
#include <avr/pgmspace.h>

 const word frame [ ] PROGMEM =
                                  B100000000, B011111111, B001000000
                                }; // end of frame

 void setup()
 } // end of setup

 void loop()
 } // end of loop

All eight bit constants beginning with "B" are predefined macros for Arduino. The B prefix is not a C/C++ standard, so use 0b instead. Or any other convenient standard notation, since the data are always stored as binary.


That's because any leading bits that you don't provide are assumed to be zero

#include <PrintBin.h>

void setup()
  byte byteValue = 0b1;
  word wordValue = 0b1;

void loop()



Note that using the BIN format with Serial.println() does not print leading zeros where as my printBinln() function prints all the bits of a variable

Thanks to jremington for the reply, however I've been looking through other people's posted code and it seems that, in particular, a lot of people are using the B prefix for binary numbers within PROGMEM, especially some people that use arrays for their LED cubes.

I've looked through about 15 different codes that use the B suffix in PROGMEM and can't see what they are doing differently to me and getting their code to work. I copied one of the sketches to my sketch folder and pressed the Verify button, but I still get the " was not defined in this scope" error message. I've just spent 2 hours changing all my code to use the 0b suffix and will just have to accept that I can't use my usual binary notation in PROGMEM, but it's frustrating to see why it won't work for me.

Are they using 8 bits such as B10000000 or 9 bits such as B100000000 as you are trying to do ?

As has been pointed out

but there are no macros for the 9 bit versions, although you could add them, but why not stick to the standard 0b notation ?

0b…. notation has been added with c++14, before that I guess custom defines were used.

To the OP B…. is not c++ just because it works in this particular env is not the reason to use it

that notation has been around since the beginning of C

0x and octal were, not 0b, which was added later to C++ in 2014 or so.

See https://stackoverflow.com/questions/18244726/why-doesnt-c-have-binary-literals

gcc extensions are not C, they are extensions!

c++14 Integer literal - cppreference.com

0b... was available in "most" compilers LONG before it was added to the C/C++ STANDARD definitions (which I assume happened in C++14 as people have stated; I'm not sure about C.)

For example, avr-gcc-3.4.6 (from WinAVR - copyright 2006) supports 0b...
(hmm. A bit of searching says that the 0b syntax was added in gcc 4.3 (2008), and backported to gcc 4.2.1 and gcc 3.3.6)

"Original C" did not have binary constants. (You can find K&R first edition online. - The discussion of constants in on page 35.