Read EEPROM to decide which library to include

Hi

I have two arduino boards doing the same thing, but use different pin.

I want to use same code (only the pin definition headers are different) in these projects

To distinguish these projects, I already wrote some data in eeprom.

So, is anyway to decide which header file need to include by reading eeprom data?
I want to finish this function in header file.

thanks a lot for the help

project.h:

/* to do
data = eeprom.read()
if(date == project1) #define PROJECT1
if(data == project2) #define PROJECT2
*/

#ifdef PROJECT1
#include<project1.h>
#endif


#ifdef PROJECT2
#include<project2.h>
#endif

project1.h:
**__ <strong>**#define LED_PIN 13**</strong> __**
project2.h:
**__</strong></strong> <strong><strong><strong>**#define LED_PIN 12**</strong></strong></strong> <strong><strong>__**
main function:
```
**void loop(){

digitalwrite(LED_PIN,1);

delay(300);

digitalwrite(LED_PIN,0);

delay(300);

}
__```**__

include, and all other preprocessor directives are done at compile time. EEPROM reads are done at run time. So what you're trying to do is impossible. You will either need to have both pin definitions known at run time or else write the entire pin definition to EEPROM.

If it is just the output pin ; why can’t you just store the value of the pin in Eeprom ( as above ) and read that in setup , or why not just power both output pins , so the version doesn’t matter. A third method is to use an input pin to tell the software which version you want .

I’m unsure the way you want to do it is possible ; I’m guessing it doesn’t work ...

Note to self : must type faster ..

Hi pert,

pert:

include, and all other preprocessor directives are done at compile time. EEPROM reads are done at run time. So what you're trying to do is impossible.

you totally solved my problem, I'll find another way to figure it out, thank you. I think my question might become "How to know my project version while or before compile-time " now

Hi hammy,

hammy: A third method is to use an input pin to tell the software which version you want .

this is a good way to solve my new problem, I appreciate your help unfortunately, there is no GPIO left in my case...

YHL: I think my question might become "How to know my project version while or before compile-time " now

I'm not sure what you mean by "project version". If I understand correctly, you're wanting to use the same sketch file for both boards, right? So, by "project version", do you only mean the board version? Do the two boards use the same type of microcontroller (e.g. ATmega328P)?

Hi pert thank you for replying me so fast I'm not good at English, but i'll try my best to describe my question specifically

pert: If I understand correctly, you're wanting to use the same sketch file for both boards, right? So, by "project version", do you only mean the board version? Do the two boards use the same type of microcontroller (e.g. ATmega328P)?

Yes, I want to use the same sketch file for both boards, two boards are use the same mcu either

the only different is the pin definition for example : A board use D13 to control LED B board use D12 to contorl LED but the LEDs are doing the same thing, maybe power display or counting etc.

So, my main purpose is when I'm compiling, I want to get correct pin definition

There is no simple way for the compiler to query the board at compile time. It's theoretically possible to use a pre-build hook to run some program that would communicate with the board but that will be quite complex.

The only easier solution I can think of is to make a custom hardware package which has a separate Tools > Board menu entry for each board. The build.board property in boards.txt will define a preprocessor macro which can be used to do conditional compilation. More info here: https://github.com/arduino/Arduino/wiki/Arduino-IDE-1.5-3rd-party-Hardware-specification#boardstxt However, this is not as automatic as you would probably hope for since it relies on you selecting the correct Tools > Board selection before compiling. This solution really doesn't have any advantage over simply making a small edit to your sketch, and is much more complex as well.

The best solution is to handle this at runtime by reading either an ID or pin configuration from EEPROM.

YHL: I'm not good at English

It seems excellent to me.

Perhaps this would satisfy. I worked up this little sketch using BWOD.

//#define A   // select version here
#ifdef A

char av[] ="version A loaded.  Output on pin  ";
#define ledPin 7
#else

char av[] ="version B loaded.  Output on pin ";
#define ledPin 9
#endif

 // BWOD declarations
// Variables will change :
int ledState = LOW;             // ledState used to set the LED

// Generally, you should use "unsigned long" for variables that hold time
// The value will quickly become too large for an int to store
unsigned long previousMillis = 0;        // will store last time LED was updated

// constants won't change :
const long interval = 1000;     

void setup(){
  Serial.begin(9600);
  Serial.print(av);
  Serial.print(ledPin); 
   // set the digital pin as output:
  pinMode(ledPin, OUTPUT); 
  }

void loop(){
  // here is where you'd put code that needs to be running all the time.

  // check to see if it's time to blink the LED; that is, if the
  // difference between the current time and last time you blinked
  // the LED is bigger than the interval at which you want to
  // blink the LED.
  unsigned long currentMillis = millis();

  if (currentMillis - previousMillis >= interval) {
    // save the last time you blinked the LED
    previousMillis = currentMillis;

    // if the LED is off turn it on and vice-versa:
    if (ledState == LOW) {
      ledState = HIGH;
    } else {
      ledState = LOW;
    }

    // set the LED with the ledState of the variable:
    digitalWrite(ledPin, ledState);
  }
  }

Commenting/uncommenting #define A changes which output pin blinks. I already have pins 7 & 9 wired up so that’s what I used.

pert, thank you very much for your information.

I'll study pre-build hook first, I really want to finish it in compile-time, because I don't want too much useless constant or variable in my program(maybe I'll have 3rd or 4th board in the future). therefore, reading EEPROM might be the last option.

your second suggest might not suitable for my implementation, like you said, it's not as automatic as I hope.

I think I'll try to study Atmega32u4(USB to UART bridge for Arduio Uno) to be my second option The board information (PID, VID, SN) seems store in it's EEPROM. maybe I can save my configuration in 32u4 instead of 328P, but I'm not sure

however, thanks for your help

YHL:
I really want to finish it in compile-time, because I don’t want too much useless constant or variable in my program

Keep in mind that will require you to have some code running on the boards that can send the identifying information back to the process run by the hook. That communication code will use up much more space than those useless constants.

YHL:
I think I’ll try to study Atmega32u4(USB to UART bridge for Arduio Uno) to be my second option
The board information (PID, VID, SN) seems store in it’s EEPROM.
maybe I can save my configuration in 32u4 instead of 328P, but I’m not sure

It’s typically the ATmega16U2 on the Uno, but it’s essentially the same as the ATmega32U4, only with less memory. The unique serial number certainly could be used by the pre-build hook process to determine which board is being compiled for. That would mean that you don’t need to have any special code running on the board to communicate with the hook.

You also need to figure out how the information from the hook process can be turned into a -D compiler flag, which will define a preprocessor macro you can use in your sketch.

Do you have access to both boards? Is there a pin common to both boards that is not being used?

IF so, program that pin as input, pullup, and read that pin in setup. On one board, jumper the pin to +5. On the other board jumper to ground.

You can read that pin to determine if the board is 1 or 0 and then your program will know which set of LED pins to use.

Paul

dougp: Perhaps this would satisfy. I worked up this little sketch using BWOD.

Hi doupg, Thanks for the reply and code. It’s clear. but this script can’t automatically determine the current board.

pert: You also need to figure out how the information from the hook process can be turned into a -D compiler flag, which will define a preprocessor macro you can use in your sketch.

OK, I’ll try Thank you.

Paul_KD7HB: Is there a pin common to both boards that is not being used?

Hi pual,

Thank you for help. But in my implementation, I used all of the GPIO pins