完善资料让更多小伙伴认识你,还能领取20积分哦, 立即完善>
电子发烧友论坛|
你好,我有一个使用18F46K22的项目。我需要把它转到45 K22,小弟弟。据我所知(在检查数据表之后),我找不到任何重要的区别,但是闪存/eeprom/ram更少。Btw编译器是XC8 v1.38,使用最新的plib(是的,我知道)。我知道,但是我不能在这里选择。代码在46K中运行得很好。但是当编译为45 K时,它就停止工作了。经过一些调试,我发现一些字符在USART传输中消失了,它们很重要,因为它们是一些设备的命令。例如,一个基本命令是0xFF,后面跟着“reset”和d0xFF。所以发送的是FF重置FF(我这里是混合十六进制和ascii,所以稍微补了一点,但是序列是正确的)。复位“中间的字符串已经消失”。如下所示,两种情况下的代码完全相同。请注意,45K的项目不是从头开始的,是46k的清理、保险丝检查(以防万一)和其他参数的副本。有人知道为什么没有发送字符吗?我注意到在具有const参数的其他例程中也存在类似的问题,因此基本上对于45K项目,任何具有“const char*”的函数参数都被“忽略”,并且不发送任何内容(我检查了控制台输出的十六进制,以避免不可打印的字符等)。ine中,我可以看到输出按预期流动,但是附加设备的行为不是您应该期望的,因为它们从来没有得到正确的数据序列,您可以看到信息应该存在的间隙,它们都匹配“const”字符串。或者看起来是这样。这个问题与USAT无关,但与const参数有关。任何建议都会被欣赏。谢谢。
|
|
相关推荐
15个回答
|
|
|
这听起来很像NVMREG的勘误表,但我认为这仅限于K40芯片。奇怪的是,PIC18F45K22产品页面上根本没有列出勘误表。
|
|
|
|
|
|
您确信您的项目不使用与46K22硬链接的任何自定义链接器脚本吗?项目中是否有直接链接(如包括)到46K22?你有没有搜索过所有的文件“46K22”?
|
|
|
|
|
|
有时你听到胡夫的心跳是斑马。
|
|
|
|
|
|
我使用过18F25K22,它几乎肯定是相同的硅,其中函数采用const char*参数,并使用它们写到UART。所以芯片没有什么不寻常的。我建议升级编译器,看看它是否改变了行为。
|
|
|
|
|
|
这是因为你有一个PRO许可证,只适用于Rev 1.38,还是因为你想使用PLIB?您可以将PLIB安装到以后的编译器中(尽管有时需要修复一些小警告),或者更好的是,提取您正在使用的PLIB函数的源代码,并将其直接添加到项目中。
|
|
|
|
|
|
QHIT是由于PLIB…我不能替代它,因为它是一个老项目。事实上,我有我自己从PLIB衍生出来的问题,已经修复并适应于XC8,但它需要进一步测试。无论如何,我将用稍后的编译器版本和简单示例来检查“const”问题。NorthGuyThat关于链接器脚本的内容是今天要检查的未决问题。我没有直接参考46K。通常,我用一种非常通用的方式进行开发,以避免与特定实现相关的任何东西,除非没有其他方法,或者它是性能和抽象之间的折衷(我们正在与微控制器一起工作,所以,抽象东西并不容易)。NKurzmanI没有听说过NVMRG勘误表,所以我会检查一下。即使不是问题也很好知道未来的参考。显然我不知道哪个是问题。我会研究你的建议,看看结果。谢谢。
|
|
|
|
|
|
经过几次测试后,我发现问题是由配置位“EBTRB”(引导块表读取保护位000000 -007FFH)引起的。它导致在45 K22中,常数字符串文字被存储在PSCT中,称为“小CONSTST”(0-600),并且它被用以前的保险丝保护。据我所知(PSECTS和我仍然需要更多的方XD),所以当文字被访问时,它被读取为0,发送例程不会发送它,因为它被解释为字符串的结尾。我忘了提到,我在代码中使用保护,EEPROM等等。那是46K22?我刚刚检查了生成的地图文件。在这种情况下,存储文本的PSTECT小地址地址是01013H;在131360H中使用这个程序,这是相同的块区段,因此由于保险丝用于保护从其他块读取,所以根本没有问题。但是,在45 K22中,数据被存储在0613H -引导块中(UPP)。ER极限为7FF,程序为000960,结果为不同区块。保险丝阻止了阅读。我远不是psect的专家和编译器生成的东西,所以请随意纠正我。但我不明白为什么编译器把数据放在那里,为什么46k的数据没有放在那里……明天可以决定把数据放在那里,然后再把所有的数据都搞糟吗?调用函数时,它们不是纯文本变量,我可以将变量移到特定的块,但是文字?对我来说,问题是“解决”的,但我仍然觉得有些东西是隐藏的…如果你能给我指出正确的方向,我会很感激……我很感激你的建议,这些建议有助于减少问题(我尝试了所有这些建议,甚至把plib代码移植到新的编译器并更改了所需的内容)。
|
|
|
|
|
|
我怀疑这可能是EBTRX保护,因为它不是K40设备,但没有时间昨晚发布。我一直怀疑这样的事情可能会发生。因此,我的问题是:我们如何启用EBTRx并指示编译器避免将常量或文字放在无法读取的位置?那么,编译器是否应该比这更聪明呢?是的,下次更改代码或编译器版本时,分配可能会有所不同。
|
|
|
|
|
|
FII:有一个关于保护的WikoT文章,以及如何使用它。杰夫。
|
|
|
|
|
|
Jeff,当一个链接器类被定义并链接到一个区段或内存块时,这是否意味着没有用_u.()指定符指定的字符串文字和常量数据将不被分配给这个区段或内存块?也就是说,如果整个内存块受到保护,那么唯一可以向该块分配const数据的方法是使用this_.()指定符。
|
|
|
|
|
|
我的观点是,任何编译器都应该将用户从中隔离开来,并且要聪明,或者至少发出警告…什么也没发生。衡量任何编译器质量的一个重要标准不是生成的代码,而是它在编译时提供的信息,即错误、警告等。E容易发出简单警告。只是一个想法……同时我会阅读Wikot文章。谢谢你。
|
|
|
|
|
|
+ 1
|
|
|
|
|
|
链接器类只是一系列地址的定义而已。如果需要的话,可以链接到这个范围。你的开头句子暗示反过来。你的问题的答案基本上是,是的。默认情况下,编译器会将常量和字符串放在特定的psect(部分)中。这些编译器生成的部分在用户指南中列出。它们通常被链接到一个类中,要么通过可以在映射文件中看到的链接器选项显式地链接,要么通过它们的类的关联隐式地链接,该关联由PSECT指令(您应该在程序集列表文件中看到)定义。它们的输出重定向了您指定的部分;那些不使用节指定符的对象/代码继续转到默认部分。你创造的那些新的部分完全取决于你。您可以选择将它们链接到一个新的链接器类中,或者链接到一个特定的地址,或者让它们继续链接到他们的原始类中(哪种方式破坏了练习的目的,但是嘿!)如果希望所有对象最终都位于不受保护的内存中,但有两个对象需要保护,则会倾向于调整内存选项,以便保留受保护的块而不能使用,然后使用节指定符将需要保护的少数对象移入受保护空间在。但是,您可以扭转这种情况,在缺省情况下保护所有内容,并且只使用节指定符将它们放入不受保护的内存中。
|
|
|
|
|
|
代码生成器知道对象被放入的部分,但仅此而已。链接器知道所有链接之后对象的地址,在代码生成之后很久。当前编译器不知道这一点。必须有CHIPINFINI文件中指定的所有块地址范围。这些块中的一些是可变的长度,因此它们必须根据其他用户设置进行调整。目前,编译器所知道的是某个值必须被推送到特定的地址。没有与配置保险丝符号相关的含义。此外,还需要一些方法来指示是否允许将一个区段链接到受保护的空间中。要生成警告吗?对。容易的?没什么。嗯,他们是好想法——我会告诉你的。如果这个功能是可用的,那就太好了。
|
|
|
|
|
|
Jef,很久以前我编了编译器,很久以前。我可以说这是可能的和容易的,对公司来说实用吗?这是另一个问题:词法分析和代码生成/优化是编译器中最容易的部分,但是因为它们对于看起来最明显的人来说却是最重要的。真正的问题是大部分错误检测都来自于语义。问题是使用接近硬件设备的高级语言。有一个障碍,模糊的障碍,这些事情发生在哪里。这同样发生在PC机上,但是软件层层隐藏了它,并且由于它们有大量的ram/程序区域要处理,所以问题几乎是看不见的。用加农炮杀死苍蝇,编译器可以对其输出进行后处理,并简单地检查变量映射、加法器。边界,主动配置位,并报告任何潜在的问题。这只是文本文件处理,这是我所做的,但手动。没有创造性的搜索和匹配,完美的电脑任务。无论如何,XC编译器正在进化,最好的希望…:)
|
|
|
|
|
只有小组成员才能发言,加入小组>>
MPLAB X IDE V6.25版本怎么对bootloader和应用程序进行烧录
473 浏览 0 评论
5793 浏览 9 评论
2334 浏览 8 评论
2224 浏览 10 评论
请问是否能把一个ADC值转换成两个字节用来设置PWM占空比?
3530 浏览 3 评论
1124浏览 1评论
有偿咨询,关于MPLAB X IPE烧录PIC32MX所遇到的问题
1095浏览 1评论
我是Microchip 的代理商,有PIC16F1829T-I/SS 技术问题可以咨询我,微信:A-chip-Ti
873浏览 1评论
MPLAB X IDE V6.25版本怎么对bootloader和应用程序进行烧录
475浏览 0评论
/9
小黑屋| 手机版| Archiver| 电子发烧友 ( 湘ICP备2023018690号 )
GMT+8, 2025-12-2 05:55 , Processed in 1.073528 second(s), Total 102, Slave 85 queries .
Powered by 电子发烧友网
© 2015 bbs.elecfans.com
关注我们的微信
下载发烧友APP
电子发烧友观察
版权所有 © 湖南华秋数字科技有限公司
电子发烧友 (电路图) 湘公网安备 43011202000918 号 电信与信息服务业务经营许可证:合字B2-20210191

淘帖
17476