我不是那种热衷于摆弄各种工具的人。我认为工具仅仅只是工具，重点应该在解决问题上。我希望自己使用的工具不会过时，在这些工具上积累的经验也不会过时。 gcc 就是这样的工具，它从 1985 年诞生至今，在基本使用方法上没有太大的变化。它也继承了更为古老的 UNIX C 编译器的许多优秀基因，成为许许多多老程序员的至爱。 ARM 仿真器的选择也是这样的，它应该不会因为外部环境的改变而不能使用：它不能因为系统从 Windows 变成了 Ubuntu 就不能使用了；它也不能因为硬件接口的更新换代而影响继续使用（并口在越来越多的机器上都看不到了）。我希望它可以成为抽屉里的第二块 “ 万用表 ” ，也可以用上十年二十年而不会被淘汰。既然是第二块 “ 万用表 ” ，它一定不会造价高昂，让人望而却步；它也一定不会因为造价低廉而效率低下。我就是在这样的理念下设计我自己的 ARM 仿真器的， NetICE 应运而生。
常见的仿真器分为两种类型。其中的一种类型由两个基本部分组成：调试器硬件部分和主机上运行的代理程序。 J-Link 、 U-Link 、 H-JTAG 和 OpenOCD 都是这样的结构。例如： J-Link 的硬件部分只传输数据和生成 JTAG 时序，而包括 JTAG 数据编码和解码的大多数工作在代理程序 RDI.dll 中完成。但是， RDI.dll 只能在 Windows 上使用，它不能跨平台，一旦遇到 Windows 版本升级或着打补丁，其兼容性将倍受考验。
还有一种类型是把所有的功能都集成到了一起。如： BDI2000 、 EPI Jeeni 就是这样的结构。这一类型中，代理程序不是运行在主机上的，而是作为 firmware 的一部分运行。它在结构上比前一种类型更加的独立，再加上使用网口作为和外部世界的通信接口，它不会困扰在接口驱动程序这个环节上。得益于这些结构特点，它可以方便的跨平台，同时它受到外部升级活动的干扰也降到了最低。
这张是我用 NetICE 在 STM32 上调试自己写的嵌入式操作系统时的照片。 NetICE 后面的那根黑色的网线接在一个 8 口的 100M 网络交换机上，我的 Linux 主机也接在上面。
NetICE 属于和 BDI2000 一样的第二种类型。与其它仿真器不同的是：它是在单芯片 MCU 上实现的，同时它也没有使用包括 FPGA 等专用芯片在内的 JTAG 硬件时序生成装置，所以造价低廉。
这张照片是 NetICE 的内部，里面有 3 个芯片：以太网 PHY 、主控 MCU -- AT91SAM7X256 和用于电平转换的 Buffer
但是便宜并不意味着低效率， NetICE 使用 SPI_DMA+GPIO 的 JTAG 时序生成算法，数据传输速度远远超过 Wiggler 。在速度这个问题上我的看法是：任何东西都有一个效费比，更快的速度和更低的造价本来就是矛盾的两个方面。对于绝大多数嵌入式开发而言，花费 5 秒的下载时间和花费不到 1 秒的下载时间在使用体验上没有太大区别。
这些数据是在 Fedora 12 下用 tftpw 下载功能测得的，表格中的 Kbps 是 Kbit/s ，不是 KByte/s
在使用上， NetICE 也提供对 Windows 上常用开发环境的支持。它还提供了一个 telnet 控制终端，集成了许多方便实用的控制命令。所有的这些，我会在后面的博客中慢慢介绍。