AVR Freaks

If we're talking specifically Atmel Studio, then this should be in the Atmel Studio section - not "General".

In Atmel Studio (inherited from Visual Studio) each project can have a number of Configurations - by default, you get 'Debug' and 'Release'.

You could make separate Configurations for your two "variants".

Or you could have 2 Projects within the Solution - which has the advantage  that Studio has a button to build all the Projects in a Solution.

Seems OK to me, but we have insufficient information about your situation & requirements to know if alternatives might be "better"; eg, if it might be "better" to program all devices the same, and then have a separate configuration operation to decide the "variant" ...

EDIT

Or, as Paulvdh  said while I was typing, why use EEPROM at all?

But, as Paulvdh asked,  why use EEPROM to do that?

EEPROM only really makes sense if there's the option to change the setting after the chip has been programmed - which doesn't seem to be the case here?

As Paulvdh said, the usual approach would just be to have some conditional compilation - with the control set in your Project configurations; eg,

// Stuff for both Variants
:
:

#if defined VARIANT_A
// Stuff for Variant 'A' only
:
:

#elif defined VARIANT_B
// Stuff for Variant 'B' only
:
:

#else
#error "Either VARIANT_A or VARIANT_B must be defined."
#endif

// More stuff for both Variants
:
:

Note the use of the final #else to catch the error case!

I just pointed out that it is possible to program the EEPROM with Atmel Studio

Ah - I see.

In general, most (all?) IDEs have something equivalent to this.

And you can do it straight from the command line, or in a makefile.

It would be difficult for the port pin to tell if the fet is missing or not, you will need to provide some means for the program to know which version of the board its running on.

One way is feedback, if the fet is operated, does some input to the micro change?  Can that be tested by the init function during power up?

The OP is not looking for a way to manage two different versions of the program, i.e. conditional compilation, but how to detect and run the same program on boards that are populated in two variants....

Can you post a schematic?

Jim

I tend to disagree here; see previous response.  I guess if going to rebuild and only a very small number of parameters then the flash could have the "hard" code.  But as you hinted at, there is often >>some<< mechanism to change the parameter -- not possible (at least impractical) if burnt into the flash image.

Summary:  Y'all are asking "why".  I ask "why not".  But perhaps I'm spoiled with CodeVision transparent EEPROM access.

Your FETs probably ought to have pull-down resistors on the gates to make sure they don't turn on during reset. Use lowish values pull-down resistors, around 4k7. Fit the resistors and FETs only on the enhanced version.

Set a pin as an input with the internal; pull-up turned on.

If the pin is high then the FET and pull-down resistor is not fitted and you have the basic version. If the pin is low then you have the enhanced version.

There are really two top level choices:

1) Compile time. To do this, you need to change  something, typically a #define whatever, that tells the compiler which features to use, based on #ifdef whatever ... #endif blocks. This results in the smallest code because the part of the code unique to the other device is never included. On the other hand, you have two build versions that you need to keep track of. And YOU need to load the correct one into the device.

2) Run time. You need to have some testable feature or detail. Maybe a peripheral that produces a distinctive signature. Maybe a pin that is ground in one version, not ground for the other. It just needs to be something that you can test in software. Upside: one compile for both units and no separate versions to keep track of. Downside: it is larger than the separate versions (though execution speed is only very slightly slower - just a couple of additional if() statements).

Jim