大概在我上次說過的那個故事發生後一年左右,我們接下另一款收銀機開發案;當時我們原本使用的微控制器(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確實有一個小錯誤,但是很遺憾,得等到他們修正該款晶片的光罩組才能解決。這不會很快發生,我們卻有時間壓力,於是我們改變了韌體的行為,並接受在收銀機與其主機之間的資料交換速度比需要更慢,才能維持穩定。

這一次我們學到的教訓是:在推出速度更快、擁有更多新功能的產品之壓力下,有可能會搞砸整個產品。

編譯:Judith Cheng

(參考原文: Judge awards Broadcom double damages in Qualcomm patent case,by Andrzej Winczura;本文作者是來自波蘭的工程師,自稱在青少年時期就中了「電子桿菌」,在波蘭一家電子收銀機製造商ELZAB工作了20年,一開始是硬體與韌體設計師,過去六年則是為嵌入式系統開發應用程式)