返回信息流为什么要使用仿真器?
在与一些有经验的工程师交谈中，我们会发现有一部分非常有经验的工程师在开发中不使用或很少仿真器。向他们询问，原因得到的回答是"仿真器不可靠"，但是他们是如何解决程序开发中遇到的问题呢？他们通常是按照这样的方法来开发程序的：
(1) 根据自己的设计建立一个符合要求的硬件平台，如果该平台涉及的程序比较复杂。还要搭建一个人机交流的通道人机，交流通道可能是一个简单的发光二极管和蜂鸣器，也可能是串口输出和LCD输出。
(2) 写一个最简单的程序例，如只是将发光二极管连续的闪烁。程序编译后烧写到Flash芯片中，验证硬件平台是否工作正常。
(3) 硬件平台正常工作后编写系统最低层的驱动程序，每次程序更改后都重新烧写再验证。如果在程序验证中遇到问题，则可能在程序中加入一些调试手段。例如通过串口发送一些信息到PC 端的超级终端上，用于了解程序的运行情况。
(4) 系统低层驱动程序完成后再编写用户框架程序，由于这部分已经不涉及到硬件部分，所以程序中的问题用户一般能够发现。
请记住，您的系统程序中总有一段代码（就是最前面的一段，硬件初始化没有完成，不可能正确获取串口）对你来说是黑盒子，这段代码要么就凭你聪明的脑袋想，一定要想对，否则，它必须需要仿真器来调。
但是更多的调查表明，使用以上方法的工程师总的看来所设计的程序都是一次很小，很简单的程序代码。因为在做简单的项目时，我们可以通过一个发光二极管就可以表达出内部的信息：如果程序复杂，可能需要更多的信息来表示内部的状态，这样可能就需要串口协助调试：如果程序更复杂，硬件更多，实时性更强，那工程师就要更多的增强调试手段，串口可能就不能满足了，需要类似于断点的功能，因为我想知道在某一个时刻芯片的内部状态究竟是怎样？
如果用户程序的修改非常频繁，可能一次又一次地的烧写占用的时间就很多，这时用户就会想能下载程序并运行的装置。
随着用户要求的越来越高，调试装置已经越来越象一个通用的仿真器了。因此我们的建议是：不要回避使用仿真器，因为使用仿真器能提高您的开发速度。
ARM嵌入式实时仿真器工作原理：
通过内部硬件实现PC并口协议到串行JTAG协议的转换，利用高速JTAG串行扫描链，通过DCC(Debug Communications Channel)连接ARM核内的Embedded-ICE调试逻辑，调试逻辑实时监测ARM核心的寄存器、数据总线和地址总线。调试器设置Breakpoint及Watchpoint后，程序在ARM内核全速运行，调试逻辑实时监测地址与数据总线并与预设值比较，在吻合时产生异常中断通知内核并把控制权交给调试器。这样，在程序全速运行时，可以在断点处停止，可以设置条件断点、条件观测断点，而又不占用CPU时间及内存资源。
这是一条镜像帖。来源：北邮人论坛 / embedded-system / #533同步于 2008/6/4
Embedded_System机器人发帖
ARM仿真器
Winters101
2008/6/4镜像同步0 回复
订阅后，新回复会通过你的通知中心匿名送达。
0 条回复
暂无回复 · 你可以订阅本帖等待新回复。