Hello I'm working on a homeautomation project that i'm developing for the attiny85 chip. When compiling, I get several red warning blocks in the verbose compile log.
In file included from C:\Program Files (x86)\Arduino\hardware\arduino\avr\cores\arduino\Stream.h:26:0,
from C:\Program Files (x86)\Arduino\hardware\arduino\avr\cores\arduino\HardwareSerial.h:29,
from C:\Program Files (x86)\Arduino\hardware\arduino\avr\cores\arduino\Arduino.h:224,
from C:\Program Files (x86)\Arduino\hardware\arduino\avr\cores\arduino\USBAPI.h:33,
from C:\Program Files (x86)\Arduino\hardware\arduino\avr\cores\arduino\CDC.cpp:19:
C:\Program Files (x86)\Arduino\hardware\arduino\avr\cores\arduino\Print.h:32:0: warning: "BIN" redefined [enabled by default]
#define BIN 2
^
In file included from c:\program files (x86)\arduino\hardware\tools\avr\avr\include\avr\iotn85.h:38:0,
from c:\program files (x86)\arduino\hardware\tools\avr\avr\include\avr\io.h:428,
from c:\program files (x86)\arduino\hardware\tools\avr\avr\include\avr\pgmspace.h:88,
from C:\Program Files (x86)\Arduino\hardware\arduino\avr\cores\arduino\USBAPI.h:24,
from C:\Program Files (x86)\Arduino\hardware\arduino\avr\cores\arduino\CDC.cpp:19:
c:\program files (x86)\arduino\hardware\tools\avr\avr\include\avr\iotnx5.h:55:0: note: this is the location of the previous definition
#define BIN 7
It seems to resolve and successfully compile however I don't like to see errors cause they usually comeback to haunt later down the road.
Is this something that can be fixed? Should/Could it be ignored or must it be fixed?
For Curiosity what exactly is going on here?
Also is there other more updated or feature rich board variants for the attiny?
Solution Determined:
CyberZoid:
The warning can be ignored and any programming relating to the ADC Control and status Register's Bipolar Differential Conversion bit should be explicitly defined separately in the user's program and not rely on definitions created in other files?
I've been following this thread and waiting for replies too. I'm about to start using ATtiny85s when they eventually arrive, so am keeping an eye on anything related.
They are only 'warnings' and not 'errors', so if everything compiles OK and works I wouldn't be too concerned if I were you. Chances are that the re-definition of 'BIN' is intentional.
I can't help regarding 'board' variants. I used the same tutorial as you, and also used the same board manager URL.
Now I'll sit back and keep watching to see what the experts say.
You can safely ignore that warning - it'll be a problem if you try to refer to the high bit of the ADCSRB with BIN (ie, ADCSRB |= 1<<BIN ), but not otherwise, and you could always do ADCSRB |=1<<7 - this is unlikely to cause code compatibility issues, as most chips (particularly the 328) don't have that functionality at all.
Ok am I correct to sum this up as thus:
The warning can be ignored and any programming relating to the ADC Control and status Register's Bipolar Differential Conversion bit should be explicitly defined separately in the user's program and not rely on definitions created in other files?
CyberZoid:
Ok am I correct to sum this up as thus:
The warning can be ignored and any programming relating to the ADC Control and status Register's Bipolar Differential Conversion bit should be explicitly defined separately in the user's program and not rely on definitions created in other files?
It looks that way. Since BIN is pre-defined in the datasheet foras bit 7 of the ADCSRB register, perhaps these other headers should have chosen their terms more carefully to avoid conflicts like this.
I'm curious. Would an enum also solve it? By restricting the type passed to print() to an enumerated type? Since the type of the print format parameter is defined in the function prototype?
An enumeration is a kind of named constant. By "namespaces / named constants" I meant...
An Arduino namespace which includes all things Arduino, a Libc namespace which includes all things Libc, each version of BIN defined in the appropriate namespace as either a simple constant (const uint8_t BIN) or an enumeration (enum{BIN}).
Just making the Arduino version a named constant would be a disaster. Because the Libc version is a macro, the Arduino "BIN" would be silently changed to "7". Now we at least have the warning letting us know there may be trouble. (For the record "BIN" is a truly terrible macro name.)
Making them both a named constant would cause a redefinition error.
Making them both a named constant then putting the Arduino version under the Print-class namespace would result in an unwieldy syntax for new users...
Serial.print( x, Print::BIN );
C++ does have the concept of a separate global namespace so it would probably work to put the Arduino version under an Arduino namespace with the Libc version outside a declared namespace (which puts it in the global namespace).
TL;DR: They either both have to be macros or both named constants. One or both have to be excluded from the global namespace.
Unfortunately, even namespaces would be a bit of a handful for new Arduino users. And very hard to implement, unless it was done inside a new release of the IDE. The stuff that needs to be wrapped in a namespace isn't even visible to a casual Arduino user without a bit of digging into the Arduino innards.
OldSteve:
Unfortunately, even namespaces would be a bit of a handful for new Arduino users.
using namespace Arduino;
...at the bottom of Arduino.h. Problem solved. Arduino users would have no idea anything changed.
Those wanting the Libc version of BIN ("advanced" users) can include the necessary qualifier / add a using.
The most difficult part, by far, is changing Libc. Libc has to continue supporting vanilla C which does not have namespaces. Essentially there would have to be two versions of every declaration: the current set of macros for C and a new set of named constants for C++.
