大概在我上次说过的那个故事发生后一年左右，我们接下另一款收款机开发案；当时我们原本使用的微控制器(MCU，以下称μC)是8051架构，但后来决定采用一个供货商经常鼓励我们使用的、某个知名厂商推出的最新版本μC，因为该新版组件有许多新添加的功能，包括较高速度的核心、次级数据指针缓存器(second DPTR)、内建SPI接口、全多任务UART、可程序化逻辑、内部闪存…等等。
我们想用这种新的μC以及其部份新功能来打造更先进版本的收款机，其中一个就是内建的全多任务UART，这能让我们的收款机与外部世界的通讯更快，而且相较于前一代机型可处理更大笔金额。利用该款μC的开发版，我们确定它可能达成我们的目标；在进行一些测试之后，我们开始设计主板以及韧体的开发。
当我们几乎完成新型收款机的硬件与韧体最终版本设计，在性能测试中，我们有时候会发现到奇偶校验错误(parity error)。一开始我们认为那是韧体的错误，该韧体完全是以汇编程序码撰写，而且问题只会偶尔发生，特别是当我们在某人操作收款机时传送大量数据。我们无法分辨那是PC主机传送了错误字节(内含错误奇偶校验位)，还是μC的UART就是无法收到错误的数据。
在经过几天的测试后，我们几乎可以确定问题来自于μC的UART。利用开发板，我们准备了一个专用程序从UART_A传送连续数据至UART_B，然后让UART_B将接收到的数据回传，结果是延迟递增。我们在示波器上观察到，若UART_B在接收到一个奇偶校验位(parity bit)的同时也在写入一个要传送的奇偶校验位，当所收到的奇偶校验位与要传送的奇偶校验位不同，μC的UART就会显示奇偶校验错误。
这清楚地告诉我们：该款μC的UART功能模块是问题所在。我们将观察结果告诉μC制造商，要求他们对我们观察到的现象提出解释，他们第一次的回答是不可能，问题一定出在我们的程序代码上；所以第二次我们自己先做了功课，将程序代码以及一些我们从示波器观察到的影像一并传送给μC制造商。
经过大约两个月，我们收到确认的讯息，μC制造商发现其组件的内建UART确实有一个小错误，但是很遗憾，得等到他们修正该款芯片的光罩组才能解决。这不会很快发生，我们却有时间压力，于是我们改变了韧体的行为，并接受在收款机与其主机之间的数据交换速度比需要更慢，才能维持稳定。
这一次我们学到的教训是：在推出速度更快、拥有更多新功能的产品之压力下，有可能会搞砸整个产品。
(参考原文： Judge awards Broadcom double damages in Qualcomm patent case，by Andrzej Winczura；本文作者是来自波兰的工程师，自称在青少年时期就中了「电子杆菌」，在波兰一家电子收款机制造商ELZAB工作了20年，一开始是硬件与韧体设计师，过去六年则是为嵌入式系统开发应用程序；编译：Judith Cheng)
最前沿的电子设计资讯
