next topic »

[on:]

There needs to be a way to identify a board in a program.  For example the Leonardo and Teensy use the ATmega32U4 but having different pin mappings.

I am writing bit-bang libraries for SPI and I2C that require fast digital I/O so I can't use the standard digitalRead/digitalWrite.  I need to know the pin map at compile time to implement fast I/O but the processor type macro no longer is adequate.

Boards like the Teensy and Leonardo will have other special features that need to be distinguished so it would be helpful for a macro to identify the board, not just the processor.

[Reply #1 on:]

There are already some #defines for board type but IIRC only for Mega/non-Mega, maybe they should be extended.

______
Rob

[Reply #2 on:]

Ideally the IDE should define a symbol that tells you the target/core/variant which is selected from the Tools > Boards menu.  That's not a new idea... but it's never gone anywhere.  I'm pretty sure it's in the issue tracker, but I'm not going to go look up the issue number right now.

For an immediate solution, after you include Arduino.h or WProgram.h, you can check for CORE_TEENSY to determine if a Teensy board is in use.  For example:

Code:

#ifdef __AVR_ATmega32U4__
#ifdef CORE_TEENSY
  // it's Teensy 2.0
#else
  // it's probably Leonardo
#endif
#endif

Hopefully the IDE will someday provide more descriptive info about which board, or target/core/variant, or platform/target/core/variant, or whatever future schema combination, is in use.

[Reply #3 on:]

How are the signature bytes read? AVRdude does it, comes out with that "Yikes! Wrong signature" error message:

"All Atmel microcontrollers have a three-byte signature code which identifies the device. This
code can be read in both serial and parallel mode, also when the device is locked. The three
bytes reside in a separate address space."

[Reply #4 on:]

Thats doesn't tell you the board though, just the chip.

______
Rob

[Reply #5 on:]

"writing bit-bang libraries for SPI and I2C"

Why not require users to  be smarter about hardware connections and take advantage of the internal hardware?

[Reply #6 on:]

There are an amazing number of reasons bit-bang makes sense.  Tens of thousands of people use my libraries and I get a lot of e-mail.

Here are two common reasons, one from beginners and one from more advanced users.

There are few shields for the Mega and beginners want to use a shield like the Adafruit Data logging shield on a Mega so they have more flash and RAM.  They would like to use it without jumper wires.

Shields like this have the DS1307 RTC connected to analog pins 4, 5 and SPI connected to pins 10, 11, 12, 13.  The Mega uses pins 20, 21 for I2C and 50, 51, 52, 53 for SPI.  I provide bit-bang in SdFat and am writing a RTC library with bit-bang I2C to solve this.

A second case is when a user needs to log data at high rate from an SPI device in an ISR.  This requires a few bytes to be transferred over SPI each time the ISR is called.  Sharing the the SPI bus between the SD and sensor just doesn't work in this case.

A third example is I2C address conflicts since I2C has so few addresses.  For example Maxim RTC chips such as the DS1307 use the same address as the MicroChip MCP3422 ADC.

A note on the MCP3422.  It is a splendid part for high accuracy voltage measurement.  It is an 18 bit delta-sigma ADC with a built-in 0.05 % 2.048 V voltage reference, programmable gain amp, and is self calibrating.  At 8X gain the LSB resolution is 1.95 microvolts in 18-bit mode.  The part only costs $3.14 in quanity one.

[Reply #7 on:]

Didn't realize there were all those limitations. Thanks.

[Reply #8 on:]

There needs to be a way to identify a board in a program.

Absolutely.  Any multiple-hardware environment I've worked with has this.  There is a really easy solution to this, and you could submit it as a patch to github today. 

Add a "#define VARIANT_xxxx" to every pins_arduino.h file, with xxxx being the directory in which its found, e.g. "#define VARIANT_STANDARD" in variants/standard/pins_arduino.h, VARIANT_LEONARDO in variants/leonardo/pins_arduino.h.

This way the IDE doesn't need to do any special processing, and people who compile outside the IDE could take advantage of it also.