成功的嵌入式设计需要指令集之外的诸多因素

不管 OTG 是否真正有用，它使得PIC32 能在更多的传统领域中得到应用，无论是作为主设备或从设备。USB"嵌入式主设备"在使用中有一些限制，不像"标准主设备"如电脑，举例来说PIC32 不提供VBUS 电源（100-500 mA）,但是你可以在个人电脑的USB接口上找到这种电源--当然这完全可以理解。另外，速度限制也需要注意，，作为从设备时能够"全速"（12 Mbps），而作为主设备时只能提供"低速"（1.5 Mbps）。

这个套件包含了一些实用的演示。其中一个演示让该板子成为一个标准人机接口设备（HID）--比如鼠标。因为HID 驱动已经是标准，你可以把它直接插入PC 使用。另外，你可以把这个套件配置成USB 主设备,从而利用PIC32 不断完善的FAT 文件管理软件库，有一些演示展示了如何访问广泛使用的USB 存储器（见照片3）。

不过需要指出的是这个套件中没有包含CAN 演示。因为我不懂也没有实验条件进行有意义的CAN 测试，如果你需要该功能，你需要自己来评估和结论。

优化的迷宫

结构体系进化的重要标志之一，曾经是编译器的优化。您可能还记得有些人把"RISC"缩写调侃为"Relegate the Impossible Stuff to the Compiler"，即"把不可能完成的任务丢给编译器"。然而，在调试时,一个太过自我聪明的编译器其问题也是显而易见的。比如PIC32 的"C"编译手册有提到说，当调试经过优化的代码时"可能偶尔会碰到令人惊讶的结果。"

例如，有些变量和代码会消失，如果编译器认为你其实并不需要它们。举例说你声明了一个变量，然后给它赋值一个常数，接着在某个计算时调用了这个变量。不要为找不到那个变量和赋值语句而抓狂，编译器只是比你更聪明一点，它在计算中直接调用了常数。

当你在一个条件分支指令处点击了单步执行，然后看到光标移动到了下一条指令处，这是否意味该条件分支的条件未被满足呢？未必，请注意这是MIPS 架构的一个特性，即分支指令的下一条指令总是会被执行，当编译器找不到合适的指令时会填充一条NOP 指令。你必须再执行一次单步操作，才能确认分支条件是否被满足（在这种情况下，你会看到光标跳到分支目标处）或不满足（光标跳转到下一条顺序指令）。更先进的"代码移动"优化能够导致更多的优化干预。请记住，有时指令可以被挪动很远的距离，甚至超出你认为应在的循环之外。

不过，调试优化过的代码也是可能的，尤其是你喜欢头脑风暴的话（例如，在分支指令后跟一个分支指令会发生什么？）。通常缺省的编译器优化只生成简单的代码，会完整保留你的意图即使可能它效率底下。当调试时在断点触发处，，你可以放心地修改某个变量的值，而不用担心编译器会捣什么鬼(比如虽然你从源代码中看不到，但一些赋值语句已经被挪动并执行了)。

需要紧记的是，编译器优化设置（见照片4）能够产生很大影响。我试着跑过一个USB主机演示程序，采用了如表1 所示的不同编译器设置，你可以看到，不同设置下（速度/大小取向、循环展开，采取MIPS-16 的16 位代码优化选项）生成的代码大小相差能够高达2倍。


保持简洁

PIC32 在精简MIPS 架构使其服务于嵌入式应用方面做得很好。比如，全部的活动功耗只有1mA/MHz 水平，从它提供的性能来看这是非常难得的。它们的批量价格也比较合理，特别考虑到那些完整的外设和存储器配备。

然而竞争也非常激烈，像Cortex - M3、瑞萨SH（现在叫RX）、爱特梅尔的AVR32 以及飞思卡尔的ColdFire 等。这些竞争对手在行业里已经有很长的时间,它们的产品也具有很广的覆盖面，在高端产品上能提供跟PIC32类似的集成度和性能，同时还有许多入门级的简单产品。