请问eeprom语句在哪里发生

构造可维护的C或C++项目的基本规则之一是永远不要在头文件中分配存储。你可以把它放在一个自己的（.c源文件）的模块中，但是由于XC8AyEpProMyDATA（）宏是笨拙和笨拙的，你最好把一个.as汇编语言的源文件添加到你的项目中，用原始的ASPIC汇编程序初始化EEPROM，甚至写一个PC脚本或程序。m以eTelHEX格式生成EEPROM数据，并将其添加为MPLAB X可加载。



      以下为原文

    One of the fundamental rules of structuring a maintainable C or C++ project is never allocate storage in a header.   You could put it in a module of its own (.c source file), but as the XC8 __EEPROM_DATA() macro is so clumsy, you'd probably do better to add a .as assembly language source file to your project and initialise the EEPROM using raw ASPIC assembler, or even write a PC script or program to generate the EEPROM data in IntelHEX format and add it as a MPLAB X loadable.

嗨，根据XC8编译器手册，Y.EEPROM与PIC16一起工作，但不适用于PIC18设备：XC8 V1.45编译器指南的第33页。UALIGER对其他8位设备的工作是意料之中的。



      以下为原文

    Hi,
 

 
According to the XC8 compiler manual the __EEPROM works with PIC16 but does not work with PIC18 devices :
Page 33 of the XC8 v1.45 compiler guide
========================================================
2.5.9.4 CAVEATS
MPLAB XC8 does not implement the __eeprom qualifiers for any PIC18 devices; this
qualifier works as expected for other 8-bit devices.
========================================================
So I guess it should not be working for PIC18F26K40...
 
Regards

我已经使用了一个旧的8位PIC18F420代码，使用了.YEEPROMYORDATA语句。该文件意味着您不能使用γ-EEPROM限定符：γ-EEPROM int x＝0；或类似的东西，而不是



      以下为原文

    I've got some old 8bit pic18f4520 code using the __EEPROM_DATA statement.
 
#ifndef __EEPROM__
#define __EEPROM__
#include

__EEPROM_DATA('L','i','g','h','t',0,'O','n');
__EEPROM_DATA(0,'O','f','f',0,'R','e','m');
__EEPROM_DATA('o','t','e',0,'B','u','t','t');
__EEPROM_DATA('o','n','s',0,'C','l','o','c');
etc...
 
That document means that you cannot use the __EEPROM qualifier:
__EEPROM int x=0;  or something like that and not __attribute__

如果您尝试使用EEPROM语句，XC8 VI45和PIC18……“IT”告诉您使用MCC…最好自己写例行公事



      以下为原文

    If you try to use EEPROM statements , XC8 vi.45 and PIC18 ...'It' tells you to use MCC ... best write your own routine 

unsigned char readEEPROM(unsigned char ee_addr)
{
  EEADR = ee_addr; //Address to be read
  EECON1bits.EEPGD = 0;//Selecting EEPROM Data Memory
  EECON1bits.RD = 1; //Initialise read cycle
  return EEDATA; //Returning data
}
void writeEEPROM(unsigned char ee_addr, unsigned char nv_data)
{
  unsigned char INTCON_SAVE;//To save INTCON register value
  EEADR = ee_addr; //Address to write
  EEDATA = nv_data; //Data to write
  EECON1bits.EEPGD = 0; //Selecting EEPROM Data Memory
  EECON1bits.WREN = 1; //Enable writing of EEPROM
  INTCON_SAVE=INTCON;//Backup INCON interrupt register
  INTCON=0; //Disables the interrupts
  EECON2=0x55; //Required sequence for write to internal EEPROM
  EECON2=0xAA; //Required sequence for write to internal EEPROM
  EECON1bits.WR = 1; //Initialise write cycle
  INTCON = INTCON_SAVE;//Enables Interrupt from saved
  EECON1bits.WREN = 0; //To disable write
  while(PIR2bits.EEIF == 0)//Check for completion of write
  {
   Nop(); //do nothing
  }
  PIR2bits.EEIF = 0; //Clearing EEIF bit
}

在禁用写入之前，用这个替换您想要的写，并且用WR检查比EEIF占用更少的代码。



      以下为原文

   
Replace that with this
  EECON1bits.WR = 1; //Initialise write cycle
  while(EECON1bits.WR); //Wait for write to complete
  EECON1bits.WREN = 0; //To disable write
  INTCON = INTCON_SAVE;//Enables Interrupt from saved
}

as you'd want the write to complete before disabling writes, and checking with WR takes less code than EEIF.

我没有太多的贡献，关于原来的主题（在哪里放EEPROFIX数据报表），因为我很少发现有必要初始化EEPROM在加载时间。为了测试的目的，初始化EEPROM，我使用一个单独的.ASM文件，用DB或DW指令定义的内容。我的意思是，EEPROMYDATA（）在PIC18设备上工作，如OPO正在使用的PIC18F26K40，但是没有足够的灵活性来适应我的情感。我建议如果你使用EEPROMYDATA（）宏，把它们放在他们自己的单独的.C文件中。该文件将自动编译（不包含任何地方）。如果你在一个以上的.c文件中喷洒EEPROFIDEA数据语句，我不认为有什么方法可以保证不同字节序列存储在EEPROM数据空间中的位置。通过编写例程来读写EEPROM，我有一些评论。（对不起，有时我不能帮助）为PIC26K40（和其他’K40设备），它是NVMCon，不是eCon。对于26K40有1024字节的EEPROM，并且能够访问比前256个字节更多的地址参数，读取和写入EEPROM应该是16位的int，而不是字符。由于某些版本的K40设备臭名昭著的TBLRD错误，实现从PFM（程序闪存）设置改变NVMCON1的任何例程必须恢复该值是非常重要的。否则，用TBRD对PFM数据进行后续访问将失败。您将无法使用TBLRD访问const数组；您将无法使用PrtTf或某些其他标准库函数等。因为，一般来说，我不知道有任何方式来保证您购买或以其他方式获得的芯片不会受到TBLRD bug的影响，我认为您最好是。DAN当然，正确实现。最后，对于想要依赖MCC的人来说，DATAEEJORITEBYTER（）和DATAEEA读写（）函数不考虑点2和3。当然，TBLRD bug的解决办法并没有在MCC启动代码中实现，所以必须单独处理。（我使用+nvMeReLink选项。）作为EEPROM访问的一个例子，我的功能是将字节写入EEPROM，在数据表中的汇编代码之后进行图形化，看起来像：在各种芯片上进行测试，包括PIC18F27 K40 Rev 2，使用XC8版本1.45免费模式。



      以下为原文

    I didn't have much to contribute concerning the original topic (where to put EEPROM_DATA statements), since I rarely find it necessary initialize the EEPROM at load time.  For test purposes, to initialize EEPROM I use a separate .asm file with the contents defined with db or dw instructions.  I mean, EEPROM_DATA() works as advertised for PIC18 devices such as the PIC18F26K40 that the OP is using, but there simply is not enough flexibility to suit my sensibilities.
 
I suggest that if you do use EEPROM_DATA() macros, put them all together in their own separate .c file in the project. This file will be compiled automatically (don't #include it anywhere).  If you sprinkle EEPROM_DATA statements among more than one .c file, I don't think there is any way to guarantee where (i.e. in what order) the different byte sequences will be stored in the EEPROM data space.
 
With that out of the way, here's the thing:
 
Now that we have arrived at suggestions for implementing routines to read and write EEPROM, I have a few comments.  (Sorry; sometimes I just can't help myself)
 

• For the PIC26K40 (and other 'K40 devices), it's NVMCON, not EECON.
  
• For the '26K40 there are 1024 bytes of EEPROM, and to be able to access more than the first 256 bytes, the address parameter for reading and writing to EEPROM should be 16-bit ints, not chars.
  
• Due to the infamous TBLRD bug for certain versions of the 'K40 devices, it is very important to realize that any routines that change NVMCON1 from the PFM (Program Flash Memory) setting must restore that value.  Otherwise subsequent accesses to PFM data with TBLRD will fail.  You won't be able to access const arrays with TBLRD; you won't be able to use printf, or certain other standard library functions, etc. Since, in general, I am not aware of any way to guarantee that chips you buy or otherwise obtain will not be affected by the TBLRD bug, I think you had better, for dang sure, implement this correctly.
  
• Finally: For people who would like to rely on MCC, the DataEE_WriteByte() and DataEE_ReadByte() functions do not take into account points 2 and 3.  Also, of course the workaround for the TBLRD bug is not implemented in MCC startup code, so you have to take care of that separately. (I use the +NVMREG link option.)
  

As an example of EEPROM access, my function for writing a byte to EEPROM, patterned after the assembly code in the Data Sheet, looks like this:
void write_eeprom(uint16_t addr, uint8_t data)
{
    uint8_t nvmcon1_save = NVMCON1;
    uint8_t gie_save;
    NVMCON1bits.NVMREG = 0b00;
    NVMADRH = (addr >> 8) & 0x03;   // The '& 0x03' is not really necessary, but...
    NVMADRL = addr & 0xFF;          // The '& 0xFF' is not really necessary, but...
    NVMDAT = data;
    NVMCON1bits.WREN = 1;

    gie_save = INTCONbits.GIE;
    INTCONbits.GIE = 0;
    // Note that for all versions of XC8 that I have tested, the following
    // work just fine, even in Free mode.  Might be "safer" to use ASM
    // statements, but...
    NVMCON2 = 0x55;
    NVMCON2 = 0xAA;
    NVMCON1bits.WR = 1;
    while (NVMCON1bits.WR)
        ;

    NVMCON1 = nvmcon1_save;
    INTCONbits.GIE = gie_save;
    NVMCON1bits.WREN = 0;
} // End of write_eeprom()


 
Tested on various chips, including the PIC18F27K40 rev 2, using XC8 version 1.45 in Free mode.
 
Regards,

Dave