读取和写入HEF的简单想法

将限定符改为“易失性”可能更好。例如，确保编译器不假设值不会改变。是的，XC8愉快地接受“易失性const”。



      以下为原文

    It might be better to change the qualifier to "volatile". e.g.
volatile const unsigned char ROM_GPIOcfg[5] @ 0x1F80 = {0x00,0x00,0x00,0x00,0x00};
to make sure the compiler does not assume the value won't change.
Yes, XC8 happily accepts "volatile const".
 

只有当它们可以在编译器不知道的情况下更改时，它们才需要声明为易失性的。这是与中断共享的系统寄存器和变量。可能是你的情况，这取决于代码是如何编写的。静态和const并不奇怪。一个限制范围和存在，另一个确定是否可以改变（以及嵌入式系统内存位置）。



      以下为原文

    Thins only need to be declared volatile if they can change without the compiler knowing about it.
This is system registers and variables shared with interrupts.  Possibly you case, depending on how the code is written.
static and const are not strange together. one limits scope and existence the other determine if if can change (and for embedded systems memory location).

不，它保留了第一行HEF的前五个单词。链接器可以（或者，也许，不）决定将其他内容放入该行的剩余部分。无论如何，例如……XC8将0x34放入前六位，将初始化器列表中的字节放入五个程序内存单词中的每一个的下八位，从指定的地址开始。请记住，您只能在包含零的Flash位置位中写入除零以外的内容，您必须首先删除该位置。此外，对于'1459，一次只能擦除整行（32个字）。所以……如果你想擦除这些零字节并将其重新编程到其他字节，而不可能搞砸其他字节，你必须：要么……1。预留HEF的前32个单词（整个第一行），以确保链接器不会在该行上添加其他内容。然后你可以擦除行，只写你想要的五个单词。注意，在'1469 Flash中擦除一行之后，如果只写一行的五个字，那么该行上的其他字将保持擦除（全部擦除）。确保无论何时您想要将这些字节读入RAM，修改RAM中的前五个单词，并从RAM重写整个行。除非在你的程序中重写它们，否则电源循环或其他重置不会改变。（或者直到你重新对设备重新编程。）一旦你重写它们，它们就保持在它们的新值（不管电源周期或其他重置）直到并且除非你再次重写它们。（或直到你重新编程设备），问候，戴夫



      以下为原文

   


No.  It reserves the first five words of the first row of HEF.  The linker may (or, maybe, not) decide to put other stuff in the remainder of that row.
 
Anyhow, for your example...
 
XC8 puts 0x34 in the upper six bits and the byte from the initializer list in the lower eight bits of each of the five program memory words, starting at the indicated address.
 
Now, keep in mind that you can only write something other than zero into a Flash location bit that contains a zero, you must first erase that location.  Furthermore, for the '1459 you can only erase an entire row (32 words) at a time.
 
So...
 
If you want to be able to erase and re-program those zero bytes to something else, without possibly screwing up something else, you must:
 
Either...
 
1.  Reserve the first 32 words (the entire first row) of HEF to make sure the linker doesn't put other stuff on that row.  Then you can erase the row and write only the five words that you want.  Note that, after erasing a row in '1469 Flash, if you only write five words of a row, the other words on that row will remain erased (all ones).
 
Or...
 
2.  Make sure that whenever you want to change these bytes you read the entire row into RAM, modify the first five words in RAM, and rewrite the the entire row from RAM.
 
 
Once the device is programmed (with the initial values you specify in the array), the value of the words in Program Memory (HEF or anywhere else) will not change upon power cycle or other reset unless and until you have rewritten them in your program.  (Or until you reprogram the device all over again.)
 
 
Once you rewrite them, they stay at their new values (regardless of power cycle or other reset) until and unless you rewrite them again.  (Or until you reprogram the device all over again.)
 
Regards,
 
Dave

改变编译器认为是ROM的内存位置肯定属于“编译器不知道”的要求！：）



      以下为原文

   
Changing memory locations which the compiler thinks are ROM definitely comes under that "without the compiler knowing about it." requirement! :)
 

是的，我必须从5到32改变CopeRoMangGPIOFG，然后对整行：读修改写；虽然你只需要5或6字节的THE。HEF不易使用……和100K次。



      以下为原文

    yes,i have to change ROM_GPIOcfg from 5 to 32,then for the whole row:read-modify-write;although you only need 5 or 6 bytes of them.
HEF not easy to use...and 100K times

只有适用于标准中档或基线设备的另一个问题是，XC8在试图读取const变量或const数组元素时会出现故障，如果每个位置的高位都不包含ReLLW操作码，则调用它。最好是错误的值会返回，在最坏的情况下，它可能会随着执行失败而坠落，%Deal%知道它在哪里。然而，只有HEF内存范围中每个字的低字节实际上被实现为HEF，高比特被实现为正常闪存，只有10K的持久性，所以显而易见的解决方案是：简单地添加0x34到所有写入到HEF的字节数据，并立即写入每个行中的0x34 FF擦除行将通过在HEF字节（100K擦除/写入持久性）的预期寿命的ONE 10%中的持久性烧毁。因此，通常不希望将HEF作为C const变量/数组访问。所有的读数都应该使用AN1673库。



      以下为原文

    Only applicable to Standard Midrange or Baseline devices with HEF
 
The other issue is that XC8 will malfunction when it tries to read the const variable or const array element by calling it  if the high bits of each location don't contain a RETLW opcode.  At best, the wrong value will be returned, at worst it may crash with execution going %DEITY% knows where.
 
However only the low byte of each word in the HEF memory range is actually implemented as HEF, the high bits are implemented as normal FLASH, with only 10K endurance, so the obvious solution of simply adding 0x3400 to all byte data to be written to the HEF, and immediately writing erased rows with 0x34FF in each location will burn through that endurance in ony 10% of the expected life of the HEF bytes (100K erase/write endurance).   
 
Therefore it is generally undesirable to access the HEF as C const variables/arrays.  All reads should use the AN1673 library.
 
Edit: see below

知道这很好。因此，我反对用HEF部件增强中频是完全错误的。



      以下为原文

    That's good to know.  My objection is therefore totally incorrect for the Enhanced Midrange with HEF parts.

***



      以下为原文

    ***

无论如何，我只是想知道AN1673是否仍然在增强型中档HEF部分上工作；我的想法似乎并不简单，我完全遵循AN1673的写作和阅读。



      以下为原文

    anyway,i just wan to know if AN1673 still work on Enhanced Midrange with HEF parts;
my idea seems not simple,i would totally follow AN1673 fo both write and read.

还没有，我可以在硬件完成时尝试，在McCiFixDead上，MCU的前置时间大约是10周SADS:事实上，我已经熟悉C和C++多年了；我没有计划迁移到ASM，有时只是有点雅致。也许PIC16不是一个更好的C平台，与PIC18相比，但我想我的代码最终会起作用。



      以下为原文

    not yet,i could try when hardware complete,on microchipdirect,the leadtime of MCU is about 10weekssad: ;
in fact,i have been familiar with C and C++ for years;i have no plan to migrate to ASM,sometime just a little taste.
maybe PIC16 is not a better platform for C, comparing with PIC18,but i think my codes will be working finally.