Factory settings built into the code

[RckRllRfg]

Hi Everyone -

My next project does not give me the luxury of DIP switches to control various settings. Therefore, I will be using the EEPROM to capture this information since it is non-volatile and I only need to read it at the beginning of POR for variable information. These default settings are handled on the production floor. We only want one firmware code for the different varieties of options, so the options will need to be changeable when the PIC is interfaced with TeraTerm or RealTerm.

There seems to be different ways of approaching this; however, I would like to know what method would be best for handling this.

Method One - Use #defines for the memory address and the #rom to stuff data into the address; BUT, it think that the #rom only works for the flash memory, so this may not be a legitimate option

Method Two - knowing that the EEPROM of a fresh new PIC is FF, I could read for 0xFF and have default features be associated to this value. If a change is needed, a write to the EEPROM would be done through a function in the program.

Please let me know your thoughts or methods on this. I'm using a 16F1947 for this project.

Regards -

RckRllRfg

[PCM programmer]

[asmboy]

I had an 18f2423 project that used nearly all the eeprom in what had to be an alterable table for data correction.

The static constant and code to load the defaults -
was significant, a real PITA -
and i was running low on program rom.
-- sounds similar to your problem.

Here is what i did.

First - I use the Micro Engineering USB programmer

That does a nice read back of code space AND eeprom memory from a pic that has already been programmed or altered. Dumps it into a hex file.
Code space AND eeprom in one simple hex file.

So i split my program into ONE version that retained all the messy code to control building the table - writing the eeprom offset addresses -
making checksums and writing all defaults to eeprom -- but nothing executable.

I then programmed that code into a pic and ran it. (thus presetting all the eeprom as i wanted it).

Then i READ the pic and eeprom BACK into a hex file.

Then programmed the pic with only the main execute side - constants and routines used to calculate the initial data and simply -
merged by editing the CCS .hex output of the real executable
with the eeprom data area harvested from the default eeprom loader stub program -

voila - default setup data with no overhead to load the
eeprom.

BTW: it takes pretty little knowledge to edit the hex file ;-))

All my presets are done with NO overhead for default loading in
the main program at all.

The main program only needed to read eeprom to get the defaults
set by the "preset load generator" stub and on occasion write
updated data with a single utility eeprom "word" writer.

In my case - it was simpler to harvest the table generated by the
stub of a program and merge the hex with the main executable.

[RckRllRfg]

asmboy -

That's an interesting idea. I am familiar with performing "surgery" on hex files from my last project. That was due to the need to combine the bootloader code and the program code into a single file for use by the production team for the initial firmware build. If you search on the term "1947", you will see all of the fun I had with THAT effort!

Thanks -

RckRllRfg

[RckRllRfg]

PCM Programmer,

Thank you for the link. At this point in time I have only a handful of EEPROM variables that I need to store, so I will probably use the method in the links provided; however, there is a possiblity for the need for the table (as thoughts and issues develop) so I will keep asmboy's strategy in the back of my mind.

Regards -

RckRllRfg