完善资料让更多小伙伴认识你,还能领取20积分哦, 立即完善>
首先,我使用的是XC16V1.31和MPLAB X V3.65的PIC24FV32 KA302。我有一个奇怪的优化行为,其中只有15个成员的结构只在优化级别设置为1时才使前5个成员消失。这个结构是字符串(char *),后面是一些无符号整数。这是一个刚刚开始出现的新行为,我不确定我能做些什么。我曾试图声明结构不稳定,但似乎没有效果。该变量在结构中的数据甚至未被访问的点上被篡改。我输入一个不相关的函数,中间的结构成员被抹去0。每一次运行时,它的精确点似乎不同,尽管这可能是因为我用优化的代码用ICD3进行调试。除了构建没有优化,还有什么可以尝试的吗?我希望至少有一些大小的优化,因为CODISACACE与应用程序的大小相当小。
以上来自于百度翻译 以下为原文 Hi all, First things first, I'm using a PIC24FV32KA302 with XC16 v1.31 and MPLAB X v3.65. I'm having a weird optimization behavior where a structure with 15 members is getting the first 5 members wiped out only when Optimization Level is set to 1. The structure is as string (char*) followed by a number of unsigned integers. This is a new behavior that just started to crop up, and I'm not sure what I can really do about it. I've attempted to declare the structure volatile but it seems to have no effect. The variable is getting clobbered at a point where the data in the structure isn't even being accessed. I enter an unrelated function, and midway through it the structure members in question get wiped out to 0. The exact point seems to differ each time I run through it, although this could be since I'm debugging with an ICD3 with optimized code. Is there anything else I can try other than just building without optimization? I'd prefer to have at least some size optimization, as codespace is rather slim with the size of this application. Any advice would be appreciated, Thanks! |
|
相关推荐
14个回答
|
|
请张贴相关代码!试图分析一些“不知何故”的情况几乎是不可能的。
以上来自于百度翻译 以下为原文 Please post the relevant code! Trying to analyze some situation described "somehow" is next to impossible. |
|
|
|
该变量在结构中的数据甚至未被访问的点上被阻塞,这听起来是在其他地方的指针错误,或者是一个缓冲区溢出错误。
以上来自于百度翻译 以下为原文 The variable is getting clobbered at a point where the data in the structure isn't even being accessed. That sounds line a pointer error somewhere else, or a Buffer over run error. |
|
|
|
嗨,在大多数情况下,调试一个优化的项目是不可能的……对于你的结构,你是否试图使你的结构中的每个成员都具有易失性?你对结构中成员的顺序有什么假设吗?当做
以上来自于百度翻译 以下为原文 Hi, In most cases debugging an optimized project is impossible... Regarding your structure, did you try to qualify as volatile each member of your structure ? Did you make any assumption about the order of the members in the structure ? Regards |
|
|
|
…或尝试访问变量时,它不再在范围内?…或者仅仅取决于监视窗口中显示的变量,而这些变量在代码中从未使用过。代码中的bug只在优化启用时才出现,但它们仍然是错误。
以上来自于百度翻译 以下为原文 ... or try to access the variable when it is no longer in scope? ... or just depending upon what is shown in the WATCH window for a variable that is never used in your code. Bugs like that in your code sometimes only show up when optimisation is enabled, but they are still bugs. |
|
|
|
如果这个结构在一个固定的地址上,在地址上设置一个数据写断点,运行优化的版本,您将更接近找到罪犯。如果需要,您可以向结构体中添加一个哑成员,而不应该在没有bug的情况下写入该成员。P.S.我总是运行和调试优化-这是可能的:
以上来自于百度翻译 以下为原文 If this struct is at a fixed address, setup a data write breakpoint on the address and run the optimized version and you will be closer to finding the offender. You can always add a dummy member to the struct, if required, that should not be written to without a bug! p.s. I always run and debug optimised - it is possible :-) |
|
|
|
当然,只要你不做一个不安全的假设,看看你的代码将通过什么步骤,以及未读变量将包含什么。
以上来自于百度翻译 以下为原文 Of course, so long as you don't make unsafe assumptions about what single-stepping through your code will do, and what unread variables will contain. |
|
|
|
我不打算发动战争:调试优化代码是可能的!虽然不太容易,但当有疑问时,混合模式调试会有所帮助。最坏的情况是当变量只存在于未命名的位置(例如寄存器或一些堆栈)。
以上来自于百度翻译 以下为原文 I did not intend to start the war: debugging optimized code is possible! Although not exactly easy. When in doubt, mixed-mode debugging helps. The most nasty case is when variables exist only in unnamed locations (e.g. registers or on some stack). |
|
|
|
感谢目前的想法,至少我有一个想法,看看这个结构。问题是“KIPPADNFION”是用来在一个连接的键盘上存储信息。它包含一个名称(Char *)以及一个14位的“IO掩码”和“PIN号”,我可以用来屏蔽包含当前状态的信息的数据。我不能发布确切的代码,但我确实找到了一些结构成员可以在我附近读取的地方。M看到数据被抹去:首先是在一个IF的参数中:另一个是这个结构的一部分成员被用来掩盖一些数据:另外一点值得注意的是,KeypadInfo的数据是在运行时从预定义的键盘信息中填充的,而不是在编译时定义的。YAPAD信息宣布const。我把它们放在一个大数组中,我可以在运行时把信息从KeypadInfo拉进来。在KEPADADFIN中的数据被清除之前,这些都做得很好。我愿意相信这可能与我如何从这些结构中移动数据有关。有什么可能指向它不应该的地方吗?这里有一些我不知道的坏习惯吗?再次感谢,如果有什么我能提供的帮助,请告诉我。
以上来自于百度翻译 以下为原文 Thanks for the ideas so far, at least I have some idea where to look. The structure is question "KeypadInfo" is for storing information on a connected keypad. It contains a name (char *) as well as a 14-bit "io mask" and "Pin Numbers" that I can use to mask data off the word containing information on the current state of the keys. typedef struct{ char* kpd_name; uint16_t io_mask; uint8_t btn1_pin; uint8_t btn2_pin; /*Snip more buttons*/ uint8_t btn_15; }KpdInfo; volatile KpdInfo KeypadInfo; I can't post the exact code, but I did find a couple places where members of the structure could be getting read near where I'm seeing data get wiped out: First is in the arguments of an if: if(KeypadInfo.btn1_pin >=9 || KeypadInfo.btn2_pin >=9){ /*snip*/ } The other is a bunch of members of the structure are used to mask some data: DataStruct.btn1 = (i2c_data & btn1mask) >> ( KEYPAD_MAX_KEYS - KeypadInfo.btn1_pin); /*Snip, repeat this for each button*/ Datastruct.btn15 = (i2c_data & btn15mask) >> ( KEYPAD_MAX_KEYS - KeypadInfo.btn15_pin); Something else of note, this data in KeypadInfo is filled in at runtime from predefined keypad information, and is not defined at compile time. I have all the keypad information declared const. I place them all in a big array that I can pull the information from at runtime and put into KeypadInfo. This is all done well before the data in KeypadInfo gets wiped out. KpdInfo KeypadList[16]; const KpdInfo Kpd_0 = {"Kpd0" , 0b0011111111001111, 11 , 12 , 2 , 1 , 9 , 7 , 10, 8 , 3 , 6 , 4 , 5 , 16 , 16 , 16 , 16}; /*Snip, more keypad definitions*/ const KpdInfo Kpd_15 = {"Kpd15", 0b1111110111000111, 11 , 13 , 12 , 7 , 14 , 10 , 9 , 8 , 6 , 5 , 4 , 3 , 2 , 1 , 16 , 16}; void Init_KeypadList(void){ KeypadList[0] = Kpd0; /*Snip, populate the array*/ KeypadList[15] = Kpd15; } bool Init_Keypad(char* keypad_num){ uint16_t index; bool kpd_ok = false; for (index = 0; index < NUM_DEFINED_KEYPADS;index++){ if (strcmp(KeypadList[index].kpd_num,keypad_num) == 0 ){ /*Matching Keypad Number, set keypad*/ KeypadInfo = KeypadList[index]; kpd_ok = true; break; } } return kpd_ok; } I'm willing to believe that this could have something to do with how I'm moving the data from these structures around? Is something maybe pointing where it shouldn't be? Is there some bad practice going on here that I'm just not aware of? Thanks again, let me know if there's anything else I could provide that could be of help |
|
|
|
此外,在最后一个代码块中,KEPADADNUM应该是KIPPADNY名称。论坛软件似乎不想让我编辑我的帖子。
以上来自于百度翻译 以下为原文 Also, in that last block of code, keypad_num should be keypad_name. The forum software doesn't seem to want to let me edit my post. |
|
|
|
这就是我所追踪到的:在这第一次循环的过程中,当我到达PrimeStRS23()时,前5个成员(char *,ut1616t和三个ut88t成员)被篡改并设置为0。此时发生的唯一事情是检查输入GRIGHOILIN要高,50ms延迟,以及超时计数器的检查。是不是我没有意识到的副作用?
以上来自于百度翻译 以下为原文 So here's what I've tracked it down to: #define GREEN_IN PORTBbits.RB15 while(GREEN_IN == 0){ __delay_ms(50); if (timeout >= 200){ /*Maximum 10 second wait time for GREEN*/ break; } Process_RS232(); Svc_Keypad(); timeout++; } Inside this while loop on the first time through, by the time I get to Process_RS232() the first 5 members (A char *, a uint16_t, and three uint8_t members) are getting clobbered and set to 0. The only thing that occurs in this time is the check for an input GREEN_IN to go high, a 50mS delay, and a check of the timeout counter. Does __delay_ms() have side effects I'm not aware of? |
|
|
|
我认为你可能会因为缓冲区溢出而获奖,在SurryRS23 2()中有一个串行缓冲区通过MeSET被清除,这可能在擦除这个结构的范围内。事实证明长度参数是错误的(太大了)。自从我确保它匹配实际的缓冲区大小以来,我就没有见过这种情况。我在调试优化代码时,我在进行WAGRIN,PATIORYRS22~()在没有我的知识的情况下被调用(我的断点设置在一条在先行上,但是我想这可能不是代码真正流向W的准确)。优化启用。
以上来自于百度翻译 以下为原文 I think you might win the prize with Buffer Overrun, There's a serial buffer being cleared in Process_RS232() via memset that's potentially within range of wiping this structure out. Turns out the length argument was wrong (and too large). I haven't seen this crop up since I ensured it matches the actual buffer size. I'm wagering since I'm debugging on optimized code, Process_RS232() was being called without my knowledge (I had the break point set on a prior line, but I suppose that may not be accurate to how the code actually flows with optimization enabled). |
|
|
|
CHAR*KPDYNEX;在您的结构中,是否设置了这个名称?或改变tokar kPDyNoD〔10〕;
以上来自于百度翻译 以下为原文 char* kpd_name; In your struct, did you set this to point to a name? or change to char kpd_name[10]; |
|
|
|
我不是100%确定你的意思吗?在这个上下文中,KPDLNEY更适合作为固定大小的数组吗?我有一个数组的键盘信息结构,我做了一个STRCMP找到列表中的一个,应该被分配给KEYPADIONFIONS结构并执行一个任务:
以上来自于百度翻译 以下为原文 I'm not 100% sure what you mean? Would kpd_name be better suited to being a fixed size array in this context? I've got an array full of keypad information structures, I do a strcmp to find the one in the list that should be assigned to the KeypadInfo struct and do an assignment: KpdInfo KeypadList[16]; const KpdInfo Kpd_0 = {"Kpd0" , 0b0011111111001111, 11 , 12 , 2 , 1 , 9 , 7 , 10, 8 , 3 , 6 , 4 , 5 , 16 , 16 , 16 , 16}; /*Snip, more keypad definitions*/ const KpdInfo Kpd_15 = {"Kpd15", 0b1111110111000111, 11 , 13 , 12 , 7 , 14 , 10 , 9 , 8 , 6 , 5 , 4 , 3 , 2 , 1 , 16 , 16}; /*populate array of keypads*/ void Init_KeypadList(void){ KeypadList[0] = Kpd0; /*Snip, populate the array*/ KeypadList[15] = Kpd15; } /*After we have the name of the desired keypad, call to load the correct information*/ bool Init_Keypad(char* keypad_name){ uint16_t index; bool kpd_ok = false; for (index = 0; index < NUM_DEFINED_KEYPADS;index++){ if (strcmp(KeypadList[index].kpd_name,keypad_name) == 0 ){ /*Matching Keypad Name, set keypad info*/ KeypadInfo = KeypadList[index]; kpd_ok = true; break; } } return kpd_ok; } |
|
|
|
没关系,我没有注意到你的init。大小是不重要的,因为它是一个常数。
以上来自于百度翻译 以下为原文 It's ok, I didn't notice your init. Doesn't matter about the size since it is a const pointer. change to this: const char* kpd_name; |
|
|
|
只有小组成员才能发言,加入小组>>
5248 浏览 9 评论
2036 浏览 8 评论
1956 浏览 10 评论
请问是否能把一个ADC值转换成两个字节用来设置PWM占空比?
3217 浏览 3 评论
请问电源和晶体值之间有什么关系吗?PIC在正常条件下运行4MHz需要多少电压?
2264 浏览 5 评论
786浏览 1评论
677浏览 1评论
有偿咨询,关于MPLAB X IPE烧录PIC32MX所遇到的问题
603浏览 1评论
PIC Kit3出现目标设备ID(00000000)与预期的设备ID(02c20000)不匹配。是什么原因
684浏览 0评论
581浏览 0评论
小黑屋| 手机版| Archiver| 电子发烧友 ( 湘ICP备2023018690号 )
GMT+8, 2024-12-27 08:41 , Processed in 1.543561 second(s), Total 104, Slave 88 queries .
Powered by 电子发烧友网
© 2015 bbs.elecfans.com
关注我们的微信
下载发烧友APP
电子发烧友观察
版权所有 © 湖南华秋数字科技有限公司
电子发烧友 (电路图) 湘公网安备 43011202000918 号 电信与信息服务业务经营许可证:合字B2-20210191 工商网监 湘ICP备2023018690号