PIC16F1704怎么将14位表常量写入ROM

1）MCU数据表第10节中的哪些信息（告诉你如何读/写/擦除闪存的部分）你不明白吗？2）我没有使用过这个芯片，但是我想在表3-1下的“注释1”和“高耐久性”ROM（特别是在第3.2节）的128个字节的引用会告诉我，有128个位置，你只能访问更低的字节3。你认为这是解决办法吗？（我必须承认，我不完全理解你所说的“双空间和双读”，但同样，这不是你的问题的描述。）苏珊



      以下为原文

    1) What information in Section 10 of the MCU's data sheet (the part that tells you how to read/write/erase the FLASH memory) do you not understand?
2) I've not used that chip but I would have thought that "Note 1" under Table 3-1 and the references to 128-byes of 'high endurance' ROM (especially in Section 3.2) would tell me that there are 128 locations and you can only access the lower byte
3) what is the underlying problem that you have that makes you think this is the solution? (I must admit I don't understand exactly what you are talking about with 'double space and double read' but, again, that is not the description of your problem.)
Susan

你必须使用内联汇编代码来完成它。你可以使用这样的东西来获取每一个WordDeDe:在一些图片的GETBITS（）函数中有一个小错误。见邮报第18号。



      以下为原文

    You have to use inline assembly code to do it.
 
extern const char bitmap[]; //required to access ASM data

#asm
PSECT strings,class=CODE,local,delta=2
GLOBAL _bitmap
_bitmap
    DW      0x3FFF  ; first entry
    DW      0x1234  ; second entry
#endasm



And you can use something like this to fetch each word
WORD getbits(BYTE chr)
{
    EEADR = (WORD)bitmap;   //get address of table, suppress warning
    EEADR += chr;   //add in offset. This way generates smallest code
    EECON1 = 0b00000000;    //clear CFGS bit
    EECON1bits.RD=1;    //start read
    EECON1bits.RD=0;    //dummy instruction (avoid NOP))
    EECON1bits.RD=0;    //dummy instruction (avoid NOP))
    return EEDAT;   //read data
}


 Edit: There's a small bug in the getbits() function for some PICs. See post#18.

C不会自动为你做这件事。你需要使用Flash API。如果你想把它放在你的代码中作为一个表，你可能需要一些ASM来做。



      以下为原文

    C will not do it for you automaticly.  You need to it using the Flash API.
If you want it in your code as a table, you may need some ASM to do it.

感谢苏珊的回答。我必须承认我的问题还没有完全解释，我希望现在能做到。ROM存储器是用14位字组织的，就像在1704的DS中所说的一样。o写入和读取每个ROM位置的全部14位。我的程序需要一个101个值的查找表，而不是我声明的“conch-char MyTab[] ]{ 0”。1，…“201, 202”，编译器在ROM中分配20214位的位置，类似于如果我在InUntu1616t中压缩了两个值，并声明“CONSTITC1616T MyTAB[]]{ 0”。1，…100, 101编译器：“编译器分配相同的202个14位的位置。我想现在已经清楚了。我在每对中使用的值有不同的准确度，第一个字符是8位长度，第二个字符只是5位长度，那么我可以使用16位字“UTI1616TI＝（（第一char & lt；6））（第二char & 0x3f））；“保存所有NE”。现在的问题是：如何用编译器保存一个14位字的方式来声明一个常量的单词表？也许可以使用μasm指令和asd构筑“DW”（？）这是可以做到的，但是正确的方法是什么呢？



      以下为原文

    Thank Susan for reply.
 
I have to admit that my problem could have not been explained fully, I will do now, I hope.
 
The ROM memory is organized in 14-bit words, like stated into the DS of 1704.
The FLASH_WriteWord and FLASH_ReadWord functions from MCC library do exactly that, then by that is possible to write and read the full 14 bits of every ROM location.
My program needs a lookup table with 101 couple of values than when I declare "const char MyTable [] = { 0. 1, ... 201, 202};" the compiler allocates 202 14-bit locations in ROM. Similar if I compact the couple values in one uint16_t and declare "const uint16_t MyTable [] = { 0. 1, ... 100, 101};" the compiler allocates the same 202 14-bit locations.
I suppose this is clear now.
The values I use in each couple have different accuracy, 1st-char is 8-bit length, 2nd-char just 5-bit length then I can use a 16-bit word "uint16_t i=((1st-char <<6) | (2nd-char & 0x3f));" to save all necessary bits into the 14-bit ROM word.
The question is now:
how can I declare a constant table of words like above in a way the compiler save only one 14-bit word?
Maybe using #asm directive and ASM instruction "DW" (?) it can be done, but what is the correct way to do it?

感谢Qub和NKurzman，我知道我必须使用汇编和DW，但是我还不知道如何正确地处理这个芯片中的ROM。RMCWord提供的MCC……微笑：那从一开始就不是问题…再次感谢



      以下为原文

    Thanks to both qɥb and NKurzman, I knew that I have to use assembly and DW, but I have not known how to address correctly the ROM in this chip.
 
To read and, possibly, to save the values during runtime, I use the FLASH_WriteWord (and .. ReadWord) supplied by the MCC ....Smile: , then that was not a problem from the beginning...
Thanks again
 

请详细说明一下。为什么要避免NOP？顺便说一下，OP PIC设备使用PMCONX、PMDATX和PMADRX。



      以下为原文

   
Please elaborate on this.  Why avoid NOP?
 
By the way, OP PIC device uses PMCONx, PMDATx, and PMADRx.
 

NOP（）会破坏优化器对当前银行的了解，所以即使在PRO模式下，即使选择了正确的银行，它也将始终进行银行选择操作。原来的代码是为PIC16F1518编写的，它也使用PMCONX等。我只是将代码转换为PIC16F1829上运行，它使用较老的EECOX风格NAMS.FYI，这里是在LST文件中的反汇编，在Pro模式下编译PIC16F1518的原始代码。



      以下为原文

   
NOP() destroys the optimiser's knowledge of the current bank, so even in PRO mode it will always put a bank select operation, even if the correct bank is already selected.
Replacing the NOPs with "do nothing" instructions in the correct bank avoids this. :)
 

The original code was written for a PIC16F1518, which also uses PMCONx etc.
I had only just converted the code to run on a PIC16F1829, which uses the older EECONx style names.
 
FYI, here is the disassembly in the LST file compiling the original code for a PIC16F1518 in PRO mode
  2588                           ;psect for function _getbits
  2589  02B2                     _getbits:    
  2590                           
  2591                           ;incstack = 0
  2592                           ; Regs used in _getbits: [wreg+status,2]
  2593                           ;getbits@chr stored from wreg
  2594  02B2  00F7                   movwf    getbits@chr
  2595                           
  2596                           ;stdisp.c: 238: PMADR = (unsigned int)bitmap;
  2597  02B3  3085                   movlw    high (_bitmap| (0+32768))
  2598  02B4  0023                   movlb    3    ; select bank3
  2599  02B5  0092                   movwf    18    ;volatile
  2600  02B6  30B0                   movlw    low (_bitmap| (0+32768))
  2601  02B7  0091                   movwf    17    ;volatile
  2602                           
  2603                           ;stdisp.c: 239: PMADR += chr;
  2604  02B8  0877                   movf    getbits@chr,w
  2605  02B9  0791                   addwf    17,f    ;volatile
  2606  02BA  1803                   skipnc
  2607  02BB  0A92                   incf    18,f    ;volatile
  2608                           
  2609                           ;stdisp.c: 240: PMCON1 = 0b00000000;
  2610  02BC  0195                   clrf    21    ;volatile
  2611                           
  2612                           ;stdisp.c: 241: PMCON1bits.RD=1;
  2613  02BD  1415                   bsf    21,0    ;volatile
  2614                           
  2615                           ;stdisp.c: 242: PMCON1bits.RD=0;
  2616  02BE  1015                   bcf    21,0    ;volatile
  2617                           
  2618                           ;stdisp.c: 243: PMCON1bits.RD=0;
  2619  02BF  1015                   bcf    21,0    ;volatile
  2620                           
  2621                           ;stdisp.c: 244: return PMDAT;
  Unnecessary "MOVLB 3" here if NOPs used
  2622  02C0  0814                   movf    20,w    ;volatile
  2623  02C1  00F5                   movwf    ?_getbits+1
  2624  02C2  0813                   movf    19,w    ;volatile
  2625  02C3  00F4                   movwf    ?_getbits
  2626  02C4  0008                   return

NOP（）会破坏优化器对当前银行的了解，所以即使在PRO模式下，即使选择了正确的银行，它也将始终进行银行选择操作。谢谢。这很有趣，所以程序集会破坏优化器。；）



      以下为原文

   
NOP() destroys the optimiser's knowledge of the current bank, so even in PRO mode it will always put a bank select operation, even if the correct bank is already selected.
Replacing the NOPs with "do nothing" instructions in the correct bank avoids this. :)

Thanks.  That's interesting; so assembly destroys the optimizer. ;)

假设NoP（）与内联程序集相同。用户指南指出：直接的后果是，即使选择了正确的银行，它也会迫使银行在联机汇编之后直接选择指令。它不对任何其他汇编代码处理NOP。



      以下为原文

    Presumably NOP() is treated the same as inline assembly.
The user guide states:

A direct consequence of that is that it will force a Banks Select instruction straight after the inline assembly, even if the correct bank is still selected. It doesn't treat NOP differently to any other assembly code.

我在某种程度上回忆了NOP（），但是在PIC.H文件中，它实际上是一个由编译器本质上内嵌的函数：也就是说，这个函数没有相应的源代码，并且在编译过程中被代码生成器扩展。



      以下为原文

    I somehow recall NOP() to be
#define NOP() asm("nop")
but in the pic.h file it actually is a function inlined intrinsically by the compiler:
// function version of nop
#pragma intrinsic(__nop)
extern void __nop(void);
#define NOP() __nop()

That is, this function has no corresponding source code and is expanded by the code generator during compilation.

我发现了同样的情况。然而，它仍然让乐观主义者忘记了银行的选择。



      以下为原文

    I found the same.
Nevertheless, it still makes the optimiser forget what bank is selected.

“健忘”；“无为”的陈述。



      以下为原文

    Amnesia ;)  Nice workaround with the "do nothing" statement.
 

所有的程序Flash（下8B）都可以通过像RAM一样的间接寻址来读取。访问14B字的繁琐代码可能会增加比保存的代码和时间更多的代码。这似乎毫无意义。



      以下为原文

    All program flash (lower 8b) is readable through indirect addressing just like RAM. Cumbersome code to access 14b words may add more code and time than is being saved. This seems pointless

没有比从内部EEPROM读取更繁琐。我认为重点是节省闪存，50%。



      以下为原文

    No more cumbersome than reading from the internal EEPROM.  I think the point is to save flash memory, by 50%.

你已经错过了我的问题的要点：“3”你有什么潜在的问题让你认为这是解决问题的方法？正如其他人向你展示的，这是一件非常困难的事情，为什么你还要尝试呢？我怀疑你是想使用一些大于1字节的常量，但由于某种原因，你不喜欢简单地把它们声明为“const”，让编译器为你做所有的工作。基本上，这似乎是一个“X-Y”问题（HTTP://XObjul.IfFo/），而我正在尝试T。o找出你真正想要做的事情，因为我怀疑有一个更简单的方法。



      以下为原文

   
You have missed the point of my question: "3) what is the underlying problem that you have that makes you think this is the solution?".
As others have shown you above, this is a very difficult thing to do so why are you even trying!
I suspect that you are wanting to use some constants that are larger than 1 byte but, for some reason, you are not happy with simply declaring them as "const" and letting the compiler do all the work for you.
Basically this seems to be to be an "X-Y" problem (http://xyproblem.info/) and I'm trying to find out what you are really trying to do as I suspect there is a much easier way.
Susna

夫人和绅士。这是怎么一个“非常困难的事情”？因为它是装配？Qub已经发布了在POST后3中完成这项任务所需的所有代码。Qub的代码执行与下面C代码相同的任务：并且通常通过调用QubNow给出的函数来读取这个数组，这有多困难？坦率地说，我认为通过FSR/MOVIW读取闪存中的16位数据需要相同的时间和代码。但是OP只需要14位宽的数据，它可以适应闪存的一个字，而const int数组为每个数据需要两个闪存字。作为LUT，与汇编DW方法相比，这增加了大量的闪存。



      以下为原文

    Com'on lady and gent. How is this "a very difficult thing"? Because it's assembly? Qub has already posted all the code that is necessary to accomplish this task in Post #3.
 
Qub's code performs the same task as the following C code:
const uint16_t bitmap[] = { 0x3FFF, 0x1234 };
and reading this array normally like this
uint16_t foo = bitmap;
is by calling the function given also by Qub
uint16_t foo = getbits(i);
 
Now, how difficult is that? Frankly, I think it takes about the same amount of time and code to read an array of 16-bit data from flash memory via FSR/MOVIW. But OP needs only 14-bit wide data, which can fit in one word of flash memory; whereas the const int array takes two flash memory words for each data. For large array, such as LUT, that adds up to a lot of flash memory comparing to the assembly DW method.

在我从PMCON1转换到ECON1中有一个bug。在PMCON1中没有7位实现，我将它设置为零。EECO1的7位是“EEPGD”，它必须是“1”来选择Flash，否则它会在具有它的PICS中访问EEPROM。因此，在PMCON1中设置该位也不害处。



      以下为原文

    There's a bug in my conversion from PMCON1 to EECON1.
There's no bit 7 implemented in PMCON1, and I set it to zero.
Bit 7 of EECON1 is "EEPGD", which must be "1" to select FLASH, otherwise it accesses EEPROM in PICs that have it.
So:
WORD getbits(BYTE chr)
{
    EEADR = (WORD)bitmap;   //get address of table, suppress warning
    EEADR += chr;   //add in offset. This way generates smallest code
    EECON1 = 0b10000000;    //clear CFGS bit, set EEPGD bit to access FLASH
    EECON1bits.RD=1;    //start read
    EECON1bits.RD=0;    //dummy instruction (avoid NOP))
    EECON1bits.RD=0;    //dummy instruction (avoid NOP))
    return EEDAT;   //read data
}
It doesn't hurt to set that bit in PMCON1 too.

关于EEPGD：CFGS位，00访问数据EEPROM存储器01访问？？？？10访问Flash存储器11访问配置文件、用户ID和DevIDbut 01访问什么？或者它的访问量和11一样吗？



      以下为原文

    Regarding the EEPGD:CFGS bits,
 
00 accesses the data EEPROM memory
01 accesses ???
10 accesses the Flash memory
11 accesses the Config, User ID, and DevID
 
but what does 01 access? or is it accessed the same as 11?

我怀疑CFGs是1，那么EEPGD不在乎。LWLO和免费比特的评论似乎支持这一点。（我正在看PIC1F1829数据表）



      以下为原文

    I suspect if CFGS is 1 then EEPGD is don't care.
The comments on the LWLO and FREE bits seems to support this.
(I'm looking at the PIC1F1829 datasheet.)