Arduino Forum

Using Arduino => Microcontrollers => Topic started by: falcon74 on May 08, 2013, 02:49 pm

Title: Mechanism for installation specific configurable parameter - EEPROM ?
Post by: falcon74 on May 08, 2013, 02:49 pm
My project involves multiple sensor nodes. The sensors need to behave somewhat differently based on certain parameters that are configured on a per sensor node, including calibration information. One easy way is to create different firmware for each instance.

I am wondering if it would be a good / recommended way, to use EEPROM, to store the configuration values, such that all the sensors are able to run the same firmware. That way, I only need to write the specific words in EEPROM, without touching firmware ?

However, with this approach, I'm running into a bit of problem that on my target uC (attiny85), I shall fall short of needed number of GPIO pins, if I reserve the ISP header pins, for it's subsequent programability (to write to EEPROM). Is this then something, that I should use jumper-pins to shunts to work around ? I.e. when I need to program uC, the jumper-settings are changed to connect uC pins to ISP pins (MISO, MOSI, SCK), and post programming jumpers are reset to allow them to function as GPIO ?

Keeping the sensor device circuit simple and low-cost is a key goal.
Title: Re: Mechanism for installation specific configurable parameter - EEPROM ?
Post by: fungus on May 08, 2013, 03:16 pm

I am wondering if it would be a good / recommended way, to use EEPROM, to store the configuration values, such that all the sensors are able to run the same firmware. That way, I only need to write the specific words in EEPROM, without touching firmware ?


Yes, that's exactly the sort of thing the EEPROM is for.
Title: Re: Mechanism for installation specific configurable parameter - EEPROM ?
Post by: dc42 on May 09, 2013, 01:15 pm

However, with this approach, I'm running into a bit of problem that on my target uC (attiny85), I shall fall short of needed number of GPIO pins, if I reserve the ISP header pins, for it's subsequent programability (to write to EEPROM). Is this then something, that I should use jumper-pins to shunts to work around ? I.e. when I need to program uC, the jumper-settings are changed to connect uC pins to ISP pins (MISO, MOSI, SCK), and post programming jumpers are reset to allow them to function as GPIO ?


You don't need to dedicate the ICSP pins, you can use them as general I/O as well. However:

- If you use them as output pins, then whatever is connected to them must not put more load on them than the programmer can drive, and must tolerate the signals that appear on them during programming.
- If you use them as input pins, then whatever device is attached to them must be able to handle the digital signals that appear on them during programming. For example, a push button connected to ground is OK as long as that button is not pressed during programming. For other devices driving those input pins, you may need to add a series resistor.
Title: Re: Mechanism for installation specific configurable parameter - EEPROM ?
Post by: hiduino on May 09, 2013, 11:45 pm
Here is an excellent guide for multiplexing pin usage.  http://www.kanda.com/avr-isp-circuits.html (http://www.kanda.com/avr-isp-circuits.html)

Title: Re: Mechanism for installation specific configurable parameter - EEPROM ?
Post by: oric_dan on May 10, 2013, 12:10 am
Quote
I am wondering if it would be a good / recommended way, to use EEPROM, to store the configuration values, such that all the sensors are able to run the same firmware. That way, I only need to write the specific words in EEPROM, without touching firmware ?

However, with this approach, I'm running into a bit of problem that on my target uC (attiny85), I shall fall short of needed number of GPIO pins, if I reserve the ISP header pins, for it's subsequent programability (to write to EEPROM).

I perceive [ie, am 2nd guessing] from this that you are thinking of connecting an external
EEPROM chip. However, Arduino chips have "internal" EEPROM for what you need, so
#of I/O pins is a separate matter.