• AVR Freaks

Helpful ReplyLockedEEPROM Defaults

Author
jswanson
Super Member
  • Total Posts : 367
  • Reward points : 0
  • Joined: 2003/11/07 12:44:05
  • Status: offline
2016/05/03 08:39:09 (permalink)
5 (1)

EEPROM Defaults

Is there any way of setting the EEPROM defaults in a more friendly way?
In C18 I could write:

#pragma  romdata eedata_scnID=0xf00000+offset
const rom MYSTRUCTURE eedata_id[] = {
MYDEFAULT_LONG,
MYDEFAULT_INT,
MYDEFAULT_INT,
MYDEFAULT_CHAR,
};

(OK so the offset couldn't be a #define)
Is there any way of doing this in XC8 or do I have to work out the individual bytes each time and pad out the offsets?
 
Jeremy.
#1
JoshuaHartwig
Super Member
  • Total Posts : 357
  • Reward points : 0
  • Joined: 2014/02/10 10:58:13
  • Location: 0
  • Status: offline
Re: EEPROM Defaults 2016/05/03 13:24:42 (permalink)
+1 (1)
XC8 User Guide 5.5.5.2
 
You can use the macro __EEPROM_DATA() to initialize 8 bytes of EEPROM at a time (exactly 8 bytes, no more, no less).  Call it multiple times in succession to fill more memory.  You can fill it with #define'd macros if you want a separate header with all your default values/addresses.  No need to calculate ROM offset at all.
 
// main.c
#define EEPROM_DEFAULT_FOO 0x08
 
__EEPROM_DATA(0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07); // Fill first 8 bytes of EEPROM
__EEPROM_DATA(EEPROM_DEFAULT_FOO, 0x09, 0x0A, 0x0B, 0x0C, 0x0D, 0x0E, 0x0F); // Next 8 bytes of EEPROM
 
void main(void)
{
    while(1) {}
}


MPLab X red squiggles can lie.  What does the Compiler output say?
XC8 update missing PLIBs?  Now are a separate download.  Code Configurator recommended for new projects.
#2
DarioG
Allmächtig.
  • Total Posts : 54081
  • Reward points : 0
  • Joined: 2006/02/25 08:58:22
  • Location: Oesterreich
  • Status: offline
Re: EEPROM Defaults 2016/05/03 13:31:09 (permalink)
0
So it *is* there Smile
I was going to post something about that, but this thread mislead me
http://www.microchip.com/forums/m905056.aspx

GENOVA :D :D ! GODO
#3
Ian.M
Super Member
  • Total Posts : 13270
  • Reward points : 0
  • Joined: 2009/07/23 07:02:40
  • Location: UK
  • Status: offline
Re: EEPROM Defaults 2016/05/03 20:19:58 (permalink)
+3 (3)
The __EEPROM_DATA() kludge sucks and is barely fit for purpose.  You cannot initialise the EEPROM with arbitrary data at predefined addresses without either writing a program to parse an EEPROM image into __EEPROM_DATA() statements, or alternatively diving into ASPIC assembler. 
 
I cant understand why the eeprom qualifier hasn't been added to the XC8 PIC18 compiler - it makes no sense whatsoever to support it for PIC12/16 but not PIC18.   Also why doesn't the PIC12/16 compiler support the use of @ for absolute addressing with the eeprom qualifier?
 
Fixing these issues would allow easy EEPROM initialisation with complex data structures, while maintaining a fixed variable layout so that a new firmware version, possibly built with a newer compiler version could still be used for field upgrades, preserving existing calibration data and/or user settings.

--
NEW USERS: Posting images, links and code - workaround for restrictions.
I also support http://picforum.ric323.com because this forum is sometimes too broken to use!
#4
1and0
Access is Denied
  • Total Posts : 11000
  • Reward points : 0
  • Joined: 2007/05/06 12:03:20
  • Location: Harry's Gray Matter
  • Status: offline
Re: EEPROM Defaults 2016/05/03 22:59:02 (permalink)
+2 (2)
Ian.M
I cant understand why the eeprom qualifier hasn't been added to the XC8 PIC18 compiler - it makes no sense whatsoever to support it for PIC12/16 but not PIC18.   Also why doesn't the PIC12/16 compiler support the use of @ for absolute addressing with the eeprom qualifier?
 

I wonder the same thing too ... it's mind-boggling. pink
#5
jswanson
Super Member
  • Total Posts : 367
  • Reward points : 0
  • Joined: 2003/11/07 12:44:05
  • Status: offline
Re: EEPROM Defaults 2016/05/04 02:36:27 (permalink)
+1 (1)
Quite.  The __EEPROM_DATA macro is amazingly unfriendly. You cant even do:

#define BLOCK1 0x01,0x02,0x03,0x04,0x05,0x06,0x07,0x08
__EEPROM_DATA(BLOCK1);
 

#6
JoshuaHartwig
Super Member
  • Total Posts : 357
  • Reward points : 0
  • Joined: 2014/02/10 10:58:13
  • Location: 0
  • Status: offline
Re: EEPROM Defaults 2016/05/04 06:56:51 (permalink)
+1 (1)
Interesting... The preprocessor tears open the __EEPROM_DATA macro first and performs the error checking on the number of arguments before unpacking the BLOCK1 macro, resulting in it thinking there's only 1 argument.  This... probably should be brought up in a support ticket.
 
My applications have thus far have not had to store much calibration data so building a #define library of every address was pretty simple, but for larger projects...

MPLab X red squiggles can lie.  What does the Compiler output say?
XC8 update missing PLIBs?  Now are a separate download.  Code Configurator recommended for new projects.
#7
Ian.M
Super Member
  • Total Posts : 13270
  • Reward points : 0
  • Joined: 2009/07/23 07:02:40
  • Location: UK
  • Status: offline
Re: EEPROM Defaults 2016/05/04 09:15:40 (permalink)
+1 (1)
IIRC that's normal ANSI C preprocessor behaviour when the expansion of the inner macro contains an unshielded comma.  See https://gcc.gnu.org/onlinedocs/cpp/Argument-Prescan.html#Argument-Prescan
 

--
NEW USERS: Posting images, links and code - workaround for restrictions.
I also support http://picforum.ric323.com because this forum is sometimes too broken to use!
#8
mad_c
Super Member
  • Total Posts : 1249
  • Reward points : 0
  • Joined: 2010/12/12 17:48:27
  • Location: Brisbane, Australia
  • Status: offline
Re: EEPROM Defaults 2016/05/04 14:57:49 (permalink)
+2 (2)

I wonder the same thing too ... it's mind-boggling. pink

I can explain why, but not offer any hint as to how the future might pan out.
 
Adding support for the eeprom qualifier and to store such objects in EEPROM is relatively easy. The problem is that if the unthinkable should happen and the programmer actually write an expression that involved reading or writing those EEPROM objects. Such access requires routines to be called, and the problem with the PIC18 devices is that there are so many different routines that need to be present, maintained, and expanded with the release of new device families. Many devices did not have routines available, and since MCC would provide these routines in future for general access, the compiler's PIC18 EEPROM routines were dropped and the ability for the eeprom qualifier put on hold. The situation is less of an issue for mid-range devices, so the compiler currently maintains its own routines and the qualifier can still be used.
 
As I mentioned, I cannot confirm where the compilers are heading, and when, but hopefully you can put your mind to boggle other matters.
 
Jeff.
 
#9
Ian.M
Super Member
  • Total Posts : 13270
  • Reward points : 0
  • Joined: 2009/07/23 07:02:40
  • Location: UK
  • Status: offline
Re: EEPROM Defaults 2016/05/04 15:17:25 (permalink)
0
I can see the issues, and the wish to avoid burdening the compiler team with maintaining code that the MCC team are supposed to be duplicating, but as MCC is far from complete and it appears doubtful that it will ever support older devices, why not simply make the eeprom qualifier use user provided  functions for EEPROM access and user defined macros for initialisation?

--
NEW USERS: Posting images, links and code - workaround for restrictions.
I also support http://picforum.ric323.com because this forum is sometimes too broken to use!
#10
NKurzman
A Guy on the Net
  • Total Posts : 18860
  • Reward points : 0
  • Joined: 2008/01/16 19:33:48
  • Location: 0
  • Status: online
Re: EEPROM Defaults 2016/05/04 15:25:49 (permalink)
+3 (3)
This Also Assume All Programmers want to use MCC to generate code. While it maybe nice for beginners and knock it out quick projects.  It does not make code optimized to all needs.
 
Forcing Programmer to use MCC by transferring functionality from the compiler to MCC will end up crippling the compiler.
 
The you MUST use Harmony for the PIC32MZ mentality is a recipe to cripple the PIC ecosystem.  I hope it is not spreading to the smaller PICs.
#11
jswanson
Super Member
  • Total Posts : 367
  • Reward points : 0
  • Joined: 2003/11/07 12:44:05
  • Status: offline
Re: EEPROM Defaults 2016/05/16 01:33:40 (permalink)
+2 (2)
I totally agree with NKurzman. I preferred the C18 library approach. If you needed to change something in the library then you could copy the relevant source files to your project. It was also possible to step through the library functions if necessary. I worry that if I use the MCC that things will change next time I use it and I'll spend hours fixing the problem. Every time I upgrade XC8 something breaks. In their rush to attract new users and show how 'easy' it is to use on the demo stand, Microchip stand to alienate their existing user base.
Back on topic: Are there any plans to make the EEPROM defaults work in a more sane way like C18? (i.e using structures.)
Jeremy.
#12
jswanson
Super Member
  • Total Posts : 367
  • Reward points : 0
  • Joined: 2003/11/07 12:44:05
  • Status: offline
Re: EEPROM Defaults 2016/07/08 02:56:42 (permalink) ☄ Helpfulby jdunne525 2020/02/21 15:02:10
0
I found a way round this problem.  It works in v1.37.  I haven't tested previous versions.
 

 
#pragma warning push // save current warning state
#pragma warning disable 1262 // disable object outside of code space warning
#define EEPROMADR 0xF000 // this varies depending on the PIC
#define setEE(add,val) const uint8_t DEFAULT_##add@EEPROMADR+add={val}
#define setEE16(add,val) const uint16_t DEFAULT_##add@EEPROMADR+add={val}
#define setEEBLOCK(add,len) const uint8_t DEFAULT_##add[len]@EEPROMADR + add
 
 
 
setEE(8,2);
 
 
 
#define MYVALUE 170
 
#define MYADDRESS 10
 
setEE(MYADDRESS,MYVALUE);
 
 
 
setEEBLOCK(0x0C0, 6) = {1, 2, 3, 4, 5, 6};
setEE16(0x0C8, 0xAA55);
 
 
 
#pragma warning pop
 

 
Unlike the __EEPROM_DATA macro, you can use macros for the address and data.
Makes the EEPROM initialisation much more readable:) 
Hope this helps,
 
Jeremy.
post edited by jswanson - 2016/07/08 03:00:01
#13
Jump to:
© 2020 APG vNext Commercial Version 4.5