Almost the same firmware for different versions of device

Go To Last Post
15 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There will be two versions of the device I'm designing. One of them has a feature that's not included in the other one.

I'd like to use the same firmware for both, but use a configuration parameter stored in EEPROM to define whether the feature is enabled or not.

 

I know that there is an option to program EEPROM in the device programming tool of Atmel Studio 7. Therefore I need separate .hex files for both configurations. Then I could configure the the device by programming either one of the files to the EEPROM.

 

Would this be a good way to achieve this? How can I produce the .hex files needed?

Last Edited: Thu. Jul 12, 2018 - 08:35 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Why use EEprom for this?

If you want to make separate .hex files, then you might as well use a (few) #define macro(s) in your code for the differences between the versions and recompile.

 

Alternatively, instead of testing for a bit in EEprom, you could test for the availability of your (hardware?) feature, or use an exra pin with a pullup / pull down resistor on the PCB to distinguish between different versions.

You could also change EEprom contents with a few serial commands.

 

Paul van der Hoeven.
Bunch of old projects with AVR's:
http://www.hoevendesign.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kestis wrote:
Atmel Studio 7 ...  How can I produce the .hex files needed?

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.

 

Kestis wrote:
Would this be a good way to achieve this?

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?

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
Last Edited: Thu. Jul 12, 2018 - 06:20 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The difference in hardware between versions is some missing MOSFETS. It would be a good solution if the MCU could detect whether a GPIO pin is connected to gate of a MOSFET or not, but I don't know if it's possible.

 

Two configurations seems to be really good option. I'll have to look into it.

The reason I previously wanted to use EEPROM was to keep the the maintenance of the firmware easy. That way the software itself could have been exactly the same.

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

I just pointed out that it is possible to program the EEPROM with Atmel Studio. I don't care where I get the files from.

Last Edited: Thu. Jul 12, 2018 - 09:41 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kestis wrote:
The reason I previously wanted to use EEPROM was to keep the the maintenance of the firmware easy. That way the software itself could have been exactly the same.

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.

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

In AS7/avr-gcc if you add any EEMEM variables to the program then at build time both flash and eeprom Hex files will be created. Traditionally for "Project" the files would have been Project.hex (flash) and Project.eep (EEPROM) but I think I've seen that Studio now calls one Project.hex and the other Project_eeprom.hex

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kestis wrote:
if the MCU could detect whether a GPIO pin is connected to gate of a MOSFET or not, but I don't know if it's possible.

 

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

 

Click Link: Get Free Stock: Retire early!

share.robinhood.com/jamesc3274

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Paulvdh wrote:
Why use EEprom for this?

The implications of that are almost directly opposite to my AVR8 app building for nearly two decades.  Almost all apps have "many" configuration parameters, and very commonly used as OP outlined.  (Typically, those apps will also have a display and menu system and a few editing buttons.)

 

Re OP's actual request, in some cases yes we keep the same firmware, and then combine with different EEPROM images for ISP to the different part numbers.  If only one (as OP mentioned) or a few parameters, I might just use two project files and some type of conditional compilation and rebuild for both configurations.

 

Yes, Virginia, Paul, many of my apps have hundreds of configuration parameters in EEPROM.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:
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?

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.

 

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ki0bk wrote:
The OP is not looking for a way to manage two different versions of the program

Isn't he?

 

The way I read the OP, that is what he's asking.

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kestis wrote:

The difference in hardware between versions is some missing MOSFETS. It would be a good solution if the MCU could detect whether a GPIO pin is connected to gate of a MOSFET or not, but I don't know if it's possible.

 

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.

#1 This forum helps those that help themselves

#2 All grounds are not created equal

#3 How have you proved that your chip is running at xxMHz?

#4 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand." - Heater's ex-boss

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Brian Fairchild wrote:
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.

 

That would work if they are N-fet's, no so well for P-fet's where the gate is pulled low to turn on.

 

Jim

 

 

 

Click Link: Get Free Stock: Retire early!

share.robinhood.com/jamesc3274

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

I'm an old school luddite. Unless pins are extremely sparse I wouldn't bother with any of this sensing resistors on transistor gates or whatever. I'd just have a dedicated configuration pin that is held one way by a resistor but which has an optional solder bridge to the other rail. When you fit the transistors you make the solder bridge too (could be a DIP switch if you want to be real fancy). Then the code reads the state of that input pin at power on.

EDIT: clearly more caffeine needed here. Completely missed the fact that Jim already said this:

Maybe a pin that is ground in one version, not ground for the other.

Last Edited: Fri. Jul 13, 2018 - 10:13 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

and, of course, the technique is not limited to just 1 pin ...

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...