在產品開發的過程中,面對發佈壓力,往往會讓我們無法慢下來仔細閱讀元件的數據表、手冊以及應用說明。更糟糕的是,儘管我們可能已經翻遍了這些文件,卻發現什麼也沒記住,因為這些文件中的專業術語對我們來說就像外語一樣陌生。而當我們的程式無法運作時,便會忍不住抱怨硬體出了問題。
對於軟體工程師來說,可以將每個芯片視作一個單獨的軟體庫。例如,你需要花費多少時間來學習一個軟體庫(如 Qt、OpenCV、Zephyr、Unity 或 TensorFlow)?同樣的時間大約也是你熟悉處理器及其外設所需要的時間。處理器甚至有類似 API 的方法來與外設進行通信。和軟體庫一樣,你通常只需閱讀文檔的一部分便能開始工作,但最好的做法是先知道哪些部分最重要,避免無意中陷入不必要的細節中。
數據表就像是外設的 API 手冊。確保你擁有最新版本的數據表(可以檢查製造商的網站或進行在線搜尋)。接下來,我將告訴你該重點閱讀哪些部分,又有哪些部分可以等到需要時再看。
硬體元件由其數據表來描述,而數據表常常充滿了密集的信息,令人望而卻步。閱讀數據表是一門藝術,這需要經驗和耐心。首先要了解的是,數據表並不是為你而寫的,而是為電氣工程師寫的,更確切地說,是為那些已經熟悉這個元件或類似元件的電氣工程師準備的。
某種程度上,閱讀數據表就像進入了一場技術對話的中途。比方說,如果你已經熟悉了三到四個加速計或類似的元件,那麼當你面對下一個元件時,便可以只讀其概述部分,迅速了解這個元件和你以往的經驗有何不同。但如果你是個新手,數據表可能就顯得過於簡略了,並且往往假設讀者已經有一定的背景知識。
因此,在閱讀數據表時,概述部分可以跳過(或者至少稍後再看)。相較於概述,描述部分更值得關注。它通常占據數據表的前幾頁,密集而精煉,是理解這個元件的關鍵部分。你應該詳細閱讀這段描述,甚至可以大聲讀出來,畫出重要信息,或者試著向別人解釋這些內容。
閱讀數據表時,應注意哪些部分可以忽略,而哪些部分則是關鍵。以下幾個部分通常在第一遍閱讀時可以跳過,但當出現問題時,它們可能會提供解決方案:
NAME
或加有修飾符的引腳,可能表示低電平有效信號。例如,假設你在使用一個新型加速計,但發現它在某些情況下數據讀取不穩定。你可以查看數據表中的性能特徵部分,可能會發現該加速計的精度在一定電壓範圍之外會下降,這可能是問題的根源。同樣,當你遇到引腳信號異常時,查閱引腳分佈圖可以幫助你確認信號的高低電平是否符合預期,從而進一步進行排查。
總的來說,閱讀數據表並不是一件簡單的事情,它需要耐心和對細節的關注。但是,掌握這項技能對於解決硬件與軟件之間的問題是至關重要的,這將幫助你在開發過程中更快地找到解決方案並提升產品質量。
最終,在數據表的中途,你會遇到一些文本,標題可能是「應用資訊」或「操作原理」。或者,數據表可能會從表格和圖表轉換為文本和示意圖。這部分就是你需要開始詳細閱讀的地方。雖然可以先略讀以找出你所需要的資訊位置,但最後還是要從頭到尾細讀這部分。作為額外的好處,這裡的文本可能會連結到一些有價值的應用說明和用戶手冊。
閱讀這部分數據表時,應該思考如何在你的系統中實現這個元件的驅動。它如何通信?如何初始化?你的軟體需要做什麼才能有效使用該元件?是否有嚴格的時間要求?你的處理器能夠處理這些要求嗎?
在閱讀數據表的過程中,標記可能會影響程式碼的部分,這樣你可以稍後回到這些部分進行深入研究。時間圖是很好的停頓點,讓你可以喘口氣並消化信息。時間圖可以幫助你將文本與預期實現結合起來。例如,這些圖表會顯示信號的變化順序及其時間間隔,這對於處理和協調硬體與軟體之間的通信至關重要。
此外,確保你擁有該元件的最新數據表,並檢查製造商的網站是否有 errata(勘誤表),這會提供數據表中的錯誤更正。勘誤表可能針對數據表中的錯誤或元件本身的缺陷。大多數元件都會有某種類型的勘誤,這些錯誤有時候會直接影響你對驅動的實現。
當你完成數據表的閱讀並開始編寫驅動時,通常會發現需要反覆回顧數據表的某些部分。最常見的流程是先實現與芯片的接口,再進一步開發通信方法,最後實際使用芯片。在這個過程中,你可能需要重新閱讀數據表,以便更好地理解芯片的特性及其在不同情況下的行為。
這是一個需要耐心的過程,像烏龜和兔子賽跑一樣,耐心細讀才能更好地掌握這些資訊。一旦驅動程式完成並且運行正常,你可以再回到數據表的頂部閱讀功能摘要,因為此時你已經熟悉了該類型的元件,對摘要部分的理解也會更深。
即使如此,在處理類似的元件時,你仍然需要重新閱讀數據表的某些部分。不過,經驗的積累會讓你更快速地掌握關鍵資訊,並且你會發現數據表首頁的摘要提供了更多的幫助。
在處理外設時,還有其他資源可以幫助你更好地使用元件:
在深入研究之前,先環顧四周,答案可能就在你還未發現的地方。例如,你在使用某款晶片時遇到的問題,可能其他開發者也遇到過,他們的經驗與解決方案將大大減少你的探索時間。