ELM327 OBD-II 心得 (8)，驗屍報告2：延遲不是死掉的主因

Introduction

在學校念書時，課本都會把定理整理好，好似一切理所當然！我自己的經驗卻覺得過程應該是曲折的：比如我自信滿滿地寫了驗屍報告，現在也要自信滿滿的推翻。我想工程師日常就是這樣：信心滿滿的提出proposal，傷痕累累的被打槍（重複以上過程）

Anyway，真相只有一個，撐下去總是找得到答案！

這系列文章我也希望呈現真實的開發過程（或著我很弱的事實），在混亂中匍匐前進


買新的軍火

我在Mouser買了STM32 Nucleo F767ZI開發板，這是一顆90nm的高階MCU

• Cortex-M7 @ 216Mhz，512KB SRAM，2MB Flash
• 處理器很快，記憶體很大，程式記憶體很大，程式亂寫也跑得完
• 3x CAN，USB 2.0HS，Ethernet
• 有三個CAN，可以在MCU裡面進行轉發
• 那天想玩USB和Ethernet也有得用

FedEx效率很高，禮拜五訂貨，下周二版子就從美國送到；加上淘寶買的CAN收發晶片，經過一番努力我終於搞定CAN轉發！示波器上看到延遲從400us壓縮到20us，我都流淚了

HUD不是被延遲打死的

轉發完要立刻上去測嗎？我隱隱約約覺得不安。如果HUD是因為中間人延遲，那直接對接Pi-CAR和HUD不就沒有延遲？這時候Pi-CAR的反應速度又是多少？

下面這張圖黃色是HUD發出的詢問，藍色是Pi-CAR的回覆，兩個紅框是查詢和回覆，4ms = 4000us還是活的

把延遲弄得更誇張一點，Pi-CAR收到Query等0.1sec=100ms=100000us試試看，還是活著！！

從美國買了兩片板子（湊免運）1500，搞了很久的STM32開發，結果方向又錯了，臉腫腫的。Anyway，我還是很喜歡這片開發板，MCU環境受控，Linux複雜難駕馭。我可以用熟悉的工具（J-Link Debugger）進行分析，而且他轉發快，我還是會繼續用下去

我把這套設備弄上車做實驗，果然還是點不亮HUD，所以我還是不知道HUD怎麼死的

反省與改進

如果是上班，通常我有第一個想法，我會找同事討論。很爛的想法一邊講會找到錯誤；講不順會知道哪裡沒想清楚；同事會從沒想過的觀點切入，又有機會精煉想法

不過搞車子不是搞專案... 只能一邊寫文章自己和自己討論，起碼寫下文章能自圓其說，把事情想清楚