完善资料让更多小伙伴认识你,还能领取20积分哦, 立即完善>
扫一扫,分享给好友
PIC16F1459,在内存顶部可用128B HEF。静态conchunrmi-gPIOCFG(5)@ 0x1F80= {0x00,0x00,0x00,0x00,0x00 };我相信上面的代码将保留第一行HEF,不需要修改XC8链接器选项;然后:ROMY-GPIOCFG(0)将读取0x00;执行之后:HeFlash写块(0,CFG,5);//CFG〔0〕=0xAA;只需使用来自AN16163的代码的函数,那么如果我读ROMPROGPIOCFFG〔0〕,它必须是0xAA?休息还是重新打开电源,读同样的0xAA?ROMIGPIOCFG〔0〕=0xAA??
以上来自于百度翻译 以下为原文 PIC16F1459,available 128B HEF on top of memory. static const unsigned char ROM_GPIOcfg[5] @ 0x1F80 = {0x00,0x00,0x00,0x00,0x00}; I believe above code will reserve the first row of HEF,no need to modify XC8 linker options; then: ROM_GPIOcfg[0] will read 0x00; after execute: HEFLASH_writeBlock(0, cfg, 5);//cfg[0]=0xaa; just use function from code of AN1673 then if i read ROM_GPIOcfg[0],it must be 0xaa??rest or re power on,will read same 0xaa? ROM_GPIOcfg[0] == 0xaa?? |
|
相关推荐
10个回答
|
|
将限定符改为“易失性”可能更好。例如,确保编译器不假设值不会改变。是的,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 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, 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. |
|
|
|
只有小组成员才能发言,加入小组>>
5243 浏览 9 评论
2035 浏览 8 评论
1955 浏览 10 评论
请问是否能把一个ADC值转换成两个字节用来设置PWM占空比?
3208 浏览 3 评论
请问电源和晶体值之间有什么关系吗?PIC在正常条件下运行4MHz需要多少电压?
2258 浏览 5 评论
779浏览 1评论
672浏览 1评论
有偿咨询,关于MPLAB X IPE烧录PIC32MX所遇到的问题
598浏览 1评论
PIC Kit3出现目标设备ID(00000000)与预期的设备ID(02c20000)不匹配。是什么原因
682浏览 0评论
579浏览 0评论
小黑屋| 手机版| Archiver| 电子发烧友 ( 湘ICP备2023018690号 )
GMT+8, 2024-12-24 22:12 , Processed in 1.574419 second(s), Total 95, Slave 79 queries .
Powered by 电子发烧友网
© 2015 bbs.elecfans.com
关注我们的微信
下载发烧友APP
电子发烧友观察
版权所有 © 湖南华秋数字科技有限公司
电子发烧友 (电路图) 湘公网安备 43011202000918 号 电信与信息服务业务经营许可证:合字B2-20210191 工商网监 湘ICP备2023018690号