Duplicate definition of "BIN"

[GoogleCodeExporter]

For a variety of ATtiny chips (x4, x5, x61 and ATmega161), the respective avr 
iot define files define BIN to 7 for Bipolar Input Mode in ADCSRB.

The core Print.h defines BIN to be 2.

This leads to spurious warnings and potential errors depending on which the 
compiler choses to use.

Since the BIN pin in the ADCSRB is probably the lesser, I'd suggest you change 
the #define BIN to #define BIPOLAR or BIPOLARIM in the files:

iotn167.h:#define BIN 7
iotnx4.h:#define BIN     7
iotnx5.h:#define BIN     7
iotnx61.h:#define BIN     7

There doesn't appear to be any way to avoid the potential confusion of the 
issue.

Original issue reported on code.google.com by pe...@stairways.com.au on 24 Feb 2012 at 8:22

[GoogleCodeExporter]

Actually, I've got no idea why the chip is labeled BIN and not BIM.

Original comment by pe...@stairways.com.au on 24 Feb 2012 at 8:59

[GoogleCodeExporter]

If Print.h did this before it defined BIN as 2, we'd still have a warning 
message but no ambiguity:

#ifdef BIN
#warning "ADCSRB BIN defined; re-defining as BIM"
#define BIM 7
#undef BIN
#endif

Original comment by n...@bike-nomad.com on 28 Jul 2013 at 5:34

[GoogleCodeExporter]

I contacted Atmel tech support and this was their response.  

"As per the latest ATtiny85 datasheet section 17.13.4 ADCSRB – ADC Control 
and Status Register B, page 137, bit 7 of ADCSRB register is BIN, which stands 
for bipolar input.  

http://www.atmel.com/devices/ATTINY85.aspx

Therefore #define BIN 7 in iotnx5.h is a valid statement and should throw 
redefinition warning when re defined some where else."

I tend to agree that it makes more sense to have BIN be 2, but they make the 
chips so they get to make the rules?  I am going to edit my copy of Print.h to 
change BIN to BINARY.  

Original comment by davidleh...@gmail.com on 17 Feb 2015 at 9:07