文章總列表

ESP32做通用資料紀錄器

緣起

ESP32上架網站ESP32操作SD卡,再來要打造紀錄器,就是開檔把紀錄寫入SD卡

我想錄汽車CAN封包,樹梅派耗電略高,丟車上有疑慮,用MCU會比較省電;這個解完能錄腳踏曲柄的動態,到時候來學神經網路;一魚多吃,做個通用的工具,到處用


主畫面,可以點連結開始記錄


記錄檔管理頁面

錄下的LOG能當場看,下載,或是移除




文字LOG,可以直接顯示


通用資料紀錄器

WIFI晶片加上SD卡,能做各種應用;錄完直接透過WIFI取資料,不用讀卡機

  • 放車上,記錄汽車封包
  • 放單車曲柄上,紀錄加速度感應器,拿來學習神經網路
  • 放機車上,錄製電瓶的電壓
  • 放貓吉身上,看他每天睡多少
  • ...


不就只是fopen + fprintf()?

起初確實這麼想,然後越來越不單純

  1. 通用的格式存各種資料
  2. 紀錄櫃台(task)配備大緩衝區(16KB),資料可以丟了就跑
  3. 紀錄櫃台(task)從緩衝區讀出數據寫SD卡;資料不做任何轉換(花時間)直接寫;批次寫入(4KB),避免頻繁寫入掉效能
  4. 轉檔(task)把通用的格式轉成文字給人看;CAN封包會轉成Linux的candump的格式,串接別的工具
  5. 通用的格式日後可以轉成任何形式
  6. 必須簡單易用,網站醜也比破爛的按鈕好;比敲指令舒服


架構圖

AI畫了架構圖,軟體分了不少區塊,多種顏色。不是簡單的fopen() + fprintf()


也許正文現在才開始


AI輔助設計

刻意用Google GEMINI AI進行輔助設計,學習不熟的東西

  1. 不熟FreeRTOS
  2. 不熟ESP32,包括SDK,開發環境
  3. 不熟網站程式設計


有兩種策略做設計,以前我選(1),這次刻意選(2),深思而後行

  1. 只管先做出原型設計,欠下大量技術債,之後靠多次迭代整理軟體
  2. 假裝自己是架構師,我的決定會影響100人,框架得一次做對(較少的技術債)


開發環境挑選,AI的意見好壞參雜,親身測試他的意見,用過去踩坑的經驗判斷好壞

  1. 大量的和AI工具進行討論,評估各種開發工具,組合,研究能否維護
  2. 研究需要開發那些工具,讓RD能做,也能讓remote debug可行
  3. 挑選的工具,在Windows/ Mac/ Linux都要能運作
  4. 如果有100人,我會開發模擬器能在PC開發;現實我是1個人,就省著吧


架設網站,用AI學不熟的技術,因為基礎範例網路很多,品質不是問題(先評估可靠度)。AI當家教每個環節都能問到爽

  1. 連上WIFI的教學,基礎題都能答得很好。我不信任AI。就算他給我程式碼,我也是逐行看
  2. 靜態網頁當起點,給我基礎網站範例
  3. 用GET/POST的方式設定LED,照範例學
  4. 和AI討論GET方式控制LED語意很怪;幫我找HTTP協定文件,從本質搞清楚瀏覽器做什麼;用telnet做實驗,掌握每個細節


可擴展的資料紀錄器,有非常多細節要討論

  1. 資料發送端,當場用fopen() + fprintf()的效能一定很爛;資料必須發送給另一個人,統一在另外一個地方寫檔

  2. 發送的資料,可以是字串,也可以是binary,裝進通用的格式

  3. 通用的格式,檔頭包括類別,時間戳記,預留擴展欄位。每筆資料也有檔頭,紀錄時間和型別(比如CAN封包可能會同時記錄字串,封包,error frame)

  4. 錄製完畢立刻轉檔最舒服;只是一邊轉檔一邊紀錄效能會變差,讓使用者自己決定

  5. WEB-UI顯示檔案列表得讀SD卡,如果同時紀錄會影響效能,檔案列表不能放首頁

用AI反覆討論細節,排除不合用的選項再動手,幾乎每個模組一出手,就是自己理想的樣子;不過如果某個坑我沒意識到,用AI輔助照樣會踩坑

有個轉檔器,把通用的格式轉成人類閱讀的文字。他的介面非常明確,直接讓AI寫感受出一張嘴的爽度


和AI談Vibe Coding

聽說導入AI能大幅提高生產力

我自己用還是得大量討論,釐清細節,每次只能前進一點點。所以要具備什麼條件,用AI加速才可行?

  1. 嵌入式開發限制重重(綁硬體,資源受限),大量痛苦的細節
  2. 以上述轉檔器為例,有明確的介面,結果正確即可,效能不重要。最接近Vibe Coding
  3. 嵌入式開發得在電路板進行驗證,比較不容易像web開發,容易產生閉環(closed loop);或是嵌入式開發的社群,這些工具沒那麼成熟,比較不容易形成閉環
  4. AI認為,建構PC模擬器,可以測試大多數的code形成閉環;一個人是搞不起這個的;就算大一點的團隊,模擬器和真實軟體的差異也是吃足苦頭。所以嵌入式開發,難以測試也限制迭代速度

最後AI給的comment,我倒是同意的

  1. 嵌入式開發,不是追求打字的速度,而是追求『不走回頭路』的架構精準度

整套做下來,我倒是嚴重依賴工具code review,修理完所有意見才上板子做實驗


還沒測試的GEMINI CLI

The next move

整個專案丟在github,叫AI去網站看做得笨笨的;下一次要測試GEMINI CLI之類的工具,讓他在本機,直接泡在source code裡面,之後看看效果會不會更好

留言

這個網誌中的熱門文章

STM32 UART + DMA,使用HAL實作TX/RX,以及不定長度接收

小米掃地機器人S20+ review

玩CAN bus的傢伙們 (1) CandleLight-based USB-CAN