完善资料让更多小伙伴认识你,还能领取20积分哦, 立即完善>
[到] GeorgePauley,错误的模拟器指令循环,3月9日我打开了案例00282543,Mel回应了我的请求,似乎他没有足够的经验来帮助。请看看你能帮他什么忙。工具:MPLABX V4.05XC8 V1.45 WORDOWS7 X64目标设备:PIC18F2520在DM164130-3,28引脚LIN演示板。模拟指令循环计数与实际目标硬件中执行的指令周期数目不匹配。附上的项目可以用来查看差异。示例应用程序的描述:本应用程序的目的是在16位模式中使用time0来断言每隔2000个指令周期中断一次。Time1用于计算中断之间的指令周期。Time0通过中断服务程序重新加载。Time0再装入值被调整为写入Time0计数寄存器的结果所发生的未计数的指令周期,使得下一个Time0中断在当前中断之后完全不漂移地断言2000个指令周期。这意味着在任何数量的Time0中断下累积计数误差总是小于±2计数。不管该实现是否正确,模拟中的计数与实际硬件的计数不匹配。你能解释为什么模拟和真实硬件的计数不匹配吗?注意,MPLAB V892模拟器正确地计数指令周期。谢谢,CEA。
18F2520xSimulasBug x.Zip(83.81 KB)-下载51次 以上来自于百度翻译 以下为原文 [TO]GeorgePauley, Wrong simulator instruction cycle count On March 9 I opened case 00282543 and Mel has responded to my request it seems he may not have enough experience to help. Please see if there is any thing you could do to help him. Tools: MPLABX v4.05 XC8 v1.45 Windows7 x64 Target device: PIC18F2520 in the DM164130-3, 28 Pin LIN Demo Board. Simulated instruction cycle count does not match the number of instruction cycles executed in the real target hardware. Attached projects can be used to see the difference. Description of the sample application: The purpose of this application is to use TIMER0 in 16-bit mode to assert an interrupt every 2000 instruction cycles. TIMER1 is used to count the instruction cycles between interrupts. TIMER0 is reloaded by the interrupt service routine. The TIMER0 reload value is adjusted for the uncounted instruction cycles that occur as a result of writing the TIMER0 count register such that the next TIMER0 interrupt asserts exactly 2000 instruction cycles after the current interrupt without drifting. This means that the accumulated count error over any number of TIMER0 interrupts is always less than ±2 counts. Regardless of whether this implementation is correct or not the count from the simulation does not match the count from the real hardware. Can you explain why the counts from the simulation and real hardware do not match? Note that the MPLAB v8.92 simulator counts the instruction cycles correctly. Thanks, cea. Attachment(s) 18F2520_SimulatorBug.8.zip (94.09 KB) - downloaded 47 times 18F2520_SimulatorBug.X.zip (83.81 KB) - downloaded 51 times |
|
相关推荐
5个回答
|
|
埃加德!你在硬件中有什么价值,模拟器中有什么价值?如何在真实硬件上捕获TMR1值?当PIC设备在停机模式下转换时,任何调试停机都会对设备上的确切时间造成严重破坏。为什么在您的ISR加载TMR0H/L之前将TMR0打开?我原以为应该朝另一个方向去做。
以上来自于百度翻译 以下为原文 Egads! What value do you receive in hardware, and what value in the simulator? How are you capturing the TMR1 value when on real hardware? Any debug halt is going to play havoc with the exact timing on the device as the PIC device transitions in and out of halt mode. Why do you turn TMR0 on before loading TMR0H/L in your ISR? I would have thought it should be done in the other direction. |
|
|
|
在使用真正的硬件或模拟器时,电路内调试不会对样本代码中的断点造成任何破坏。然而,ICD处理冻结的外围时钟,这是我的工作。Time1捕获是通过设置Time1在16位读/写模式,与FoSC / 4作为时钟源和预计时器设置为1:1,然后Time1是在中断服务程序中读取。通过从Time1计数寄存器的当前读数中减去Time1计数寄存器值的先前读数来计算指令周期数。然后将其添加到32位计数变量中。所有这些都发生在Time0中断服务例程中。我选择了ToTimeSero 0打开的点,以便在任何写入之后,写入到Time0到特定地引起TimeR0计数寄存器的计数更新中的2个周期延迟。注意,Time0是在16位读/写模式下设置的。模拟器中的这个bug已经出现在PIC18F内核仿真模型中,因为MPLABX的发布。&编辑:我在断线处放置一个断点:nop-(;)/*在这里放置断点。在模拟和实际硬件中,可变时钟应该增加*/A断点。在实际硬件中,时钟变量在每次停止时平均增加2000,并且不漂移。仿真增加了时钟变量的2000或2002。
以上来自于百度翻译 以下为原文 The In-Circuit-Debug does not cause any havoc with breakpoints in the sample code when using real hardware or the simulator. However the ICD handles freezing the peripheral clocks it is working for me. The TIMER1 capture is done by setting TIMER1 in 16-bit read/write mode, with FOSC/4 as the clock source and the prescale set for 1:1, then TIMER1 is read in the interrupt service routine. The number of instruction cycles is calculated by subtracting the previous read of the TIMER1 count register value from the current read of the TIMER1 count register. This is then added to the 32-bit Counts variable. All of this occurs within the TIMER0 interrupt service routine. I selected the point where TIMER0 is turned on so that the write to TIMER0 to specifically provoke a 2-cycle delay in the count update of the TIMER0 count register after any write. Note that TIMER0 is setup in 16-bit read/write mode. This bug in the simulator has been present in the PIC18F core simulation model since the release of MPLABX. I place a breakpoint at line: Nop(); /* Put breakpoint here. Variable Clocks should increase by */ A break point here work in both the simulation and the real hardware. In the real hardware the Clocks variable increases by an average of 2000 on each halt and does not drift. The simulation adds 2000 or 2002 never less to the Clocks variable. |
|
|
|
这个问题会阻碍你在工作中前进吗?我运行了您的项目,并且看到了时钟变量中非常一致的2000—2002值。考虑到你的程序试图做的事情,以及数据表所说的,这些都是我所期待的值。我没有硬件可用(我们没有硬件和演示板树,我们可以去拔我们在Chandler需要的硬件!格林先生:但是我怀疑硬件的价值非常相似。事实上,在任何给定的迭代中,模拟器和硬件可以通过少量的循环彼此分离并不奇怪。模拟器和硬件有一些根本的区别。具体而言,硬件上的各种组件、外设等是独立和同时操作的离散实体。但是在模拟器上,这些实体的模型是必须以顺序方式操作的软件组件。这种差异往往导致模拟器事件发生较早或较晚的周期比硬件。这些小的差异可以增加很多周期。在这里讨论确切的问题可能需要一些时间。不幸的是,模拟器团队正在忙于其他任务。我将编写一个针对模拟器的bug报告,以便我们记录这个问题,这个对话,以及你的示例项目。我们会按照计划允许深入挖掘。(臭虫倾向于渗透到模拟器待办事项列表的顶部)。
以上来自于百度翻译 以下为原文 Is this issue keeping you from moving forward in your work? I ran your project and saw very consistent 2000-2002 values in the Clocks variable. Given what your program appears to be trying to do, and what the datasheet says, these are pretty much the values I would be expecting. I don't have hardware available, (We don't have hardware and demo board trees that we can just go pluck the hardware we need here at Chandler! mr green: ), but I suspect the hardware values to be pretty similar. The fact that on any given iteration the simulator and the hardware may be off from each other by a small number of cycles is not surprising. The simulator and the hardware have some fundamental differences. Specifically the various components, peripherals, etc. on the hardware are discrete entities that operate independently and simultaneously. But on the simulator, the models of these entities are software components that, necessarily, operate in a sequential fashion. This difference often leads to simulator events happening a cycle early or late compared to the hardware. These small differences can add up over lot's of cycles. Drilling down to the exact issue in play here is likely going to take some time. Unfortunately, the simulator team is busy with other tasks right now. I will write a bug report against the simulator so that we record this issue, this conversation, and your example projects. We'll dig in deeper as schedule allows. (Bugs have a tendency to percolate to the top of the simulator to-do list.) |
|
|
|
乔治,谢谢你抽出时间来看这件事。我的项目不再受到模拟器问题的影响。这段插图告诉我,即使当MPLABX显示模拟器支持该函数时,也不能相信它会像实际的硬件那样运行。这个“一致的2000—2002年”实际上是模拟的问题。真正的硬件不是这样的。这在我看来是如此短视。你如何验证硬件模拟而没有硬件作为参考?你的代码中有多少人有使用他们创建仿真模型的设备的实际经验?虽然这对于PIC18F2520中的许多外围函数是正确的,但对于Time0来说不是这样。数据表(DS963E页124)有一个框图,它显示了Time0输入时钟在所有操作模式下都与指令时钟同步。我建议在MPLABX仿真项目开始时,Time0仿真模型中存在一个bug。它从开发人员那里一直纠缠,让微芯片看这个,并不能很好地验证你的验证方法。
以上来自于百度翻译 以下为原文 George, Thank you for taking time to look in to this. My project is no longer impacted by simulator issues. This episode has shown me that even when MPLABX shows that function is supported by the simulator it cannot be trusted to behave like the actual hardware. This "consistent 2000-2002" is in fact THE problem with the simulation. The real hardware does not behave like this. This just seems to me to be so short sighted. How in the world do you validate a hardware simulation without the hardware as a reference? How many of your coders have any real experience of using the devices they create simulation models for? While this is true for many of the peripheral functions in the PIC18F2520 it not true for TIMER0. The data sheet (DS39631E-page 124) has a block diagram that shows the TIMER0 input clock is synchronized to the instruction clock in all modes of operation. I would suggest that there is a bug in the TIMER0 simulation model that has been there from the begining of the MPLABX simulation project. That it has taken persistent badgering from a developer to get Microchip to look into this does not speak well of your validation methods. |
|
|
|
乔治,我的案例(第00282543版),从3/9/2018开始还没有解决。现在芯片的支持已经超过60天了。在我看来,这个问题有两种可能的解决方案:在PIC18F家族测试代码HasBug的Time0仿真模型中有一个bug。对于案例1,我所要求的是行为被记录下来。对于2的情况,我会很高兴地发现我是哑巴。无论结果是什么,我都会很高兴。谢谢,CEA。
以上来自于百度翻译 以下为原文 George, My case (#00282543), started on 3/9/2018 has not been resolved. It's now more than 60 days that Microchip support has been working on this issues. The problem as I see it has one of two possible resolutions:
For case 2, I would be spectacularly elated to find that I am dumb. I would be pleased by either result. Thanks, cea. |
|
|
|
只有小组成员才能发言,加入小组>>
5195 浏览 9 评论
2013 浏览 8 评论
1937 浏览 10 评论
请问是否能把一个ADC值转换成两个字节用来设置PWM占空比?
3185 浏览 3 评论
请问电源和晶体值之间有什么关系吗?PIC在正常条件下运行4MHz需要多少电压?
2240 浏览 5 评论
751浏览 1评论
637浏览 1评论
有偿咨询,关于MPLAB X IPE烧录PIC32MX所遇到的问题
522浏览 1评论
PIC Kit3出现目标设备ID(00000000)与预期的设备ID(02c20000)不匹配。是什么原因
648浏览 0评论
549浏览 0评论
小黑屋| 手机版| Archiver| 电子发烧友 ( 湘ICP备2023018690号 )
GMT+8, 2024-12-2 22:45 , Processed in 1.473450 second(s), Total 87, Slave 70 queries .
Powered by 电子发烧友网
© 2015 bbs.elecfans.com
关注我们的微信
下载发烧友APP
电子发烧友观察
版权所有 © 湖南华秋数字科技有限公司
电子发烧友 (电路图) 湘公网安备 43011202000918 号 电信与信息服务业务经营许可证:合字B2-20210191 工商网监 湘ICP备2023018690号