業界人士由於長期深耕於專業領域，所以對於第三方社群生態（Arduino）所知有限。筆者也是過來人，自從脫離了業界，也才開始接觸，才真正認識瞭解了 Arduino。
當一句話概括 Arduino：開發者是全球數百個國家數以萬計的愛好者，無私奉獻軟硬體資源／open source，其所奠定之基礎之巨，不容小覷；其所應用之廣，同 Linux，只有您還沒想到的，沒有它尚未存在的；但質量呢？專業度呢？何不看看筆者個人所奉獻者，社群之中不乏此等比業餘的筆者還要專業的人士！

尚且總是不乏有人戲謔 Arduino 是玩具，學生，高中生玩的；
筆者受授於這些 open sources，得以更快速也更有能力地做開發，並感佩於那些無私的奉獻者，
回懟：對！是不是玩具，是看人用的！
這不也正看出了，它所適用之範圍能從小學生上到專業人士，
不正是它所展現的，已被眾人深耕演化進展了十幾年了的，取之不竭的開放性資源與眾所望塵莫及的開發能量嗎？

三句話，介紹完一顆 MCU，ESP8266（ESP8285）

• 筆者至今為止，所有的專案，都是用這顆 ESP8266／8285 實現的。（還未破關它，尚不敢用上 ESP32）
• 160MHz，2M-bytes Flash-in-Package Flash，近 100k BYTES SRAM，WiFi b/g/n 獨立模組 x 2，1 non-shared channel ADC，GPIOs 多達 11 pins，如下圖，是成板，極小尚而不侷促，只要上電就可以用了／開發了／産品化了！
• ESP8285 MCU chip，零售市場一顆台幣 20 元有找；硬體成本再多也安揑涼涼，龐大的資源後盾，尚缺軟體開發整合人力便俱足矣！

細說這三年來的專案

從建站至今，四年了，筆者已，為自己，寫了不計其數的程式了，shell scripts，C/C++，PHPs 之範例，測試，學習，研究，專案，等等。。。
故今目的性地，挑選出來一些屬於是進階的，更像是程式設計的，實務應用的，而非範例練習測試之類的。
所以當中，最早的第一篇算是 heap 的實現了。一句話論它，專業領域不可或缺的，但卻是往往不見實現於七成專案內的邏輯二元樹狀資料結構！
若您不熟 heap，一句話讓您認識：memory space 是一維線性空間，heap 是筆者所知唯一能在線性空間上成就二維二元樹狀結構之搜／增／刪／修，所帶來之效率（in-place operations／重點）；若線性查找一筆有序資料平均需時 1000 秒，使用 heap，僅需 11 秒。（阿不就二元搜尋？）是的，不同的是，資料元素的移除，插入，更新（可能是筆者新創，見該文）同樣都是 O(log₂(n)) 的時間複雜度，遠優於線性操作 O(n)。排序對比則是 nlog₂(n)：n²

相關文章之連結請見下方時間軸序

1. ESP8266 CodeBase

• 詳實地記錄了開發歴程。
  而細節／程式碼／數據／圖片／影片展示，請參見相對應的文章。
• 3 個月內寫了 4000 行程式，克服了相當多的難關
• 主要實現了裝置間同步：7 支 devices，首次同步後，devices 之間之最大差距小於 50us，通常在 20us 以下。經過 20 小時後，最大差距小於 40ms（時脈之累積偏差）。（註，過程中同步有用途地做了 4 次，第 4 次約在 11 小時後，故嚴格說是 9 小時的累積）。若無時脈修正，累積偏差／9hr 是 1418ms
• 全賴社群 open sources 之助，以 example 1 為例（6 支 devices），所有 devices 刷同一份扣毌需修改，自然能展示上述之實驗測試。
• 承上，如何區分 devices 之間彼此，如何給不同的 devices 有不同的 sub-domains，如何彼此協調，如何選出共主／同步用，即是運用了 mDns，mDns 從幾年前就很不就手的一直使用著，近期方才實作得可謂可忘了它的存在。
• 那麼，這份 codebase 還有什麼嗎？
  若您正使用 RTOS，請告知筆者是什麼原因選用它；也或許這份 9000 行也不做任何特別的事的 tmpc_esp8266.ino codebase，能讓您反棄用 RTOS 以用 tmpc_esp8266.ino，也或許第二代（後述），更會讓您選用 esp8266／若前面三行簡介還不足以吸引您。。。
• （手邊 7 顆還在跑，更新，25hr，偏差 66ms，當中 6 支偏差僅 24ms。。。當然是無線，沒興趣，若您有興趣試，看看空曠地距 30 米同步效果如何／要完成同步保險起見全上電後需等上 15 分鐘後即成；別忘了要有 router）
• 請略過（此處論述個人觀點）據自己的認知，早期的 ucOSII，基於埋控都不具 MMU，故模擬了 MMU 單元的目的進而實現 OS 才具有的特徵 context-switch。以進而實現 task-based 的使用者空間下之行程執行與管理的目的，其主要目的之一是為簡化 main-loop 內的架構並易於開發與管控不同行程，其次可能是易於除錯／於 user-space/process 下／但萬一崩呢／又若有因應不崩則代表什麼；而 embedded Linux 通常省不了 MMU 的硬體單元及 cpu 支援，且 SRAM 乃至於 ext-RAM 乃至於 ext-flash/sd/mmc 是必要配備且存在最小門檻，故埋控等級的與 embedded-linux 是倆平行世界，其主要目的則更有說服力：為了 made-ready 的例如 filesystem，USB，networks，SD/MMC，HDMI/LCD display，keyboard/mouse，系統管理及 x-window 等等的支援乃至於既存的系統程式與公用程式與應用程式等亦可直接使用或更容易移植，and，Open Sources！後者，適得其所。而前者，uc + RTOS，這帶出一個問題，運算資源將分割給 context-switch，及其行程管理等。當問，這付出與得到的權衡。
  另一方面，談，筆者 codebase 內已，不敢說獨創因或許只是自己孤陋寡聞亦或別人之商業機密當然不會聲張；請先查查此 9000 行用了多少 delay()；全時地且全可單次／週期／絕對時間(clock-time)小至 ms 地可 Timeout/alarm/Timeafter/RTrun（scheduling），尚未整合的 multi-timers 亦可設定任意時間中斷執行須實時的 events/functions（”RT”os），完全免除了可能不必要存在的 RTOS 的 overhead；並且這一份 codebase 還有著墨很深的同步。筆者有不小的認定若在 “RT”OS 框架下，其相較 standalone 將會“更難實現”裝置間同步。至於 standalone 之程式框架，若能完善地規劃分層與佐用巨集代換，應是可不小程度地簡化應用層上面的規劃因而可對等了 RTOS 俱有的軟體框架。
  若只以一句話論定，則，codebase 內之 Timeout／Clock-time／alarm／Timeafter／RtTaskRun（／MultiTimers），全是筆者不假／參他人而自創，且可稱得上顛覆傳統的埋控設計風格與運行效能（沒有丁點徒耗在 delay()）！（前題是要有不吝嗇的 SRAM／這是今日埋控該有的標配）
  對了，至於互斥鎖，筆者之前文章也自我探討過，忘了為何要探究它了。。。非 os-based 是沒有“時間上互斥”問題的；至於中斷的重進入問題也在相關文章中已釐清了。
  其他如，sleeping 的 processes 該不該喚醒，仍需去檢查與比對，並非只會巡訪 active processes；而 standalone 的，只需看一個 flag。
  簡言之，multi-core 用上 RTOS 應是會更有說服力（p.s., ESP32 Gen1 是 uc 等級的 2-core）；而 “RT”os，standalone 的應該會更稱得上 RT 吧。
  standalone 的，缺點之一便是在 programming 上會發散而不易系統化；當然這就仰賴先期完善的框架規劃以改善之。
  以上，我並非談論使用 standalone 有何好處／因無有無好處此問題；而是探討使用 RTOS 的必要性衡量。
  <<<天外飛來一筆／要定向校準可以很簡單解決；使用浮動的參考物（珠管或汞管）或仙蛇就在浮動物上>>>

2. LD3320 語音識別模組

• 有影片 DEMO
• 此專案已在一年前完成結案，手上有 2 支成品，也一直都在我的車上，語音控制排氣管閥門之運作，順利地服役超過一年了！我是說，
• 時間過得太久了，此專案曾經克服什麼困難的關卡，或現陳述上有出入的地方，正確細節請逕參該文。
• 官方提供的範例，也只有語音辨識。
• 筆者不僅順利啟用了 chip 上的 MP3 播放，也無縫地整合了語音與 MP3 播放協同運作。
• 關卡：voice recognition，MP3 play，next MP3 play，個別都得需經過一次 chip reset（否則 chip 放飛了），不意便稍來可觀的延時。故最大的關卡，便是此三者順利地協作！
  並對於語音播放下了很大一番功夫，一個英文句子例如 thank you ken，就是 3 支 MP3 files，如何順接！並可輸入任意字串（須字音庫中有的單字／可自行追加），便可使其朗誦，或逐字母閱讀，等等諸功能；字音庫也是筆者反覆擠腦挑選出來常用的可以連貫起來的單字再一支一支下載下來，並首尾去空化。（當然，中文亦可／比照辦理／留意 16-bit）。
  前面提到的 2M flash ESP8285，能放幾支 MP3 files？ 恩，煞費一番苦心後，400 支 MP3 files／English words，只佔 1MBytes！
• 丢給他 LD3320；丢回來，官方範例太簡陋缺漏，且 IC 有問題，我不會！LD3320，不正是考驗程式經驗與設法突破關卡與發揮功力嗎！請谷歌看看，有無既存的 LD3320 像筆者醬的源碼專案！

3. Tables Lib

• data structure
• 將二維的 table 鏈結串列化（x 軸）成 tables，量身訂作於後一個劇本式的語音識別專案。自動化往返載入及搜尋對應，使得所載入者具時間區域性 temporal locality。
• 若有改版將擴增 y 軸及真正的 flash <–> memory 載入。

4. ESP8266 跟時間賽跑，中斷篇

• 只消一句話，曾經有人試著量測某顆 MCU 的中斷響應或延遲嗎？圖的是什麼？筆者到了這階段，才想到並想去做這件事。
  對了，要稱破關，則此番作為必不能少。。。

5. ESP8266 跟時間賽跑，GPIO 篇

• 75ns，150ns，自從知道這組神奇數字後，一直耿耿於懷。明白，將來有一天一定會用上它！

6. IIC timer-based soft stack

• 千萬別烤問我 IIC 相關的 spec，筆者可能會一直吱唔其詞，吐不出來XD！！！不過，我還是破關了它。。。有矛盾嗎？XD。。。
• Arduino（或絕大多數軟體實踐之實作品）是以 blocking 的方式將 iic 的資料，一次性地讀或寫完。
• 筆者以 non-blocking 的方式實作了，細到每個 bit，不限於 data 部份，例如 ack，皆能中斷之。並可以，以輸詢，也或是 timer triggered，的方式處理每個 bit。使相鄰 bit 間能穿插做其他事。
• 想當然爾，也實作了（通常 mcu 上都是 master 的角色），slave 角色，也就是說，當某 mcu 想面對怎麼樣的 slave 時，筆者手上這顆 mcu／此實作品，便能自訂其 address，依某設計好的行為／data，來模擬該 slave；一來可用於 mcu/master 的除錯，再來也，mcu 就是可當 slave，不多見吧！
• 當然不過，其效率是很大很大的問題。。。

7. ESP8266 主控台

• 有影片 DEMO
• 只靠一個 OLED display，還只是 32 x 128 像素，填幾個字就沒了！外加一支搖桿。。。那麼，能做什麼事？
• 角色是如題，主控台，是無線(WiFi)搖控器，可 multicast/多播。影片中，有兩支閥門，似同步地作動，便是此主控台所發的多播。故不論先來後到，加入此多播的 devices 都能跟著同步。主控台並可對個別 device 下 commands
• 路不轉車轉
• 在此有限的顯示平面上，設法突破克服之，如影片展示，有吧？！如此，您覺得能力有被此狹隘的平面侷限得無以伸展嗎？
• 它，還可以上網，將 http request 所收到的 html 原生內容（txt 格式），無論格式長寬，如實無障礙地全部顯示出來，單靠一支搖桿。
• 有看到編輯視窗嗎？是精華！完整的編輯能力，能夠輸入任何字串，作插入，取代，移除，儲存，歴史記錄／喚回，該有的都有，單靠一支搖桿。
  （初意是為了動態輸入網址來取得網頁內容，且可記入 history 供下次直接調用而不必再 key 一次）
• 註：用上的 open sources 有，U8g2 顯示驅動，little-fs 檔案系統，Arduino 內建（如 multicast 等）。應沒了，其他都是新扣。
• 具體而微的 GUI 界面，算流𣈱，故，
• 請告訴我，32×128+joystick 能做什麼事？。。。。。明知故問因為筆者有不同答案：單單只需，可行想法，付諸實現，努力與堅持（與適情妥協轉念），克服關卡；成長與經驗值的累積就是這麼來的，共勉之。

8. 直流馬達驅動板的軟體實作

• 有影片 DEMO
• 它使用上 MultiPWMs 函式庫，此函式庫會和 MultiTimers 函式庫合併起來一起講／後述。此二巨頭，乃筆者的代表作／精華之一，正是化腐朽為神奇之作。
• 此實作的對象是，電動閥門，是二線式直流有刷馬達+減速齒輪組，簡單講就是一般熟知的玩具馬達；過電就會轉；反向電流就可反轉。
• 使用的驅動板是具隔離的 H 橋正反向驅動。必須自行控制排除死區／dead-band。
• 要知道，閥門的開闔行程是有限的，當開度到最大（或關閉）後，機構上已讓閥門／馬達無處進展了，吾人如何得知已開到最大（到底了）並且適時斷電呢？若然而不斷電，馬達將會無處宣洩電功而致發高熱燒燬。
• 加 sensor feedback 或限位開關 吧！嗯，但，若，不允許呢？。。。。。。。。那麼就無解了。。。。。。。。？
• 此前題下，
• 我想要，
• 能夠適時斷電當已全開或已全關時，
• 能夠讓閥門，我想要它開多少度，它就開多少度；例如，分 7 階，0 全關，1～6，7 全開。
• 最直覺的作法，便是算時間再分割。若全開至滿關，全部就是 7 秒，那麼每 1 階就 1 秒。是的，這答案是對的！但請想想，會有什麼問題嗎？
• 若是物理數學世界，正確答案。但若是現實世界，這答案半對。閥門與馬達的老化，積垢等，將決定剩下半個答案。沒錯，我們唯一能運用的，也只剩時間了。
• 由於有點久遠前了／忘得差不多了，實作內容項目也頗多，故不再引導式地；
• 先說，當馬達遇阻，電流會有瞬態的變化／遽增或遽減／忘了。筆者實作 ADC 去 sensing 那瞬態特徵／斜率大於某值，以判別是否到底了，實際結果很理想符合預期；前題是，當須外加電阻，以放大此瞬態變化，是的，是電阻，ADC 是監測此電阻兩端的電位差以判別。
• 既然會老化卡頓，那麼，就來個全自動計算吧！即影片中所展示的，即所謂學習的部份。將來那天作動不如預期了，再來次學習吧，便能取得退化後的，使正常作動的數據參數。
• 再來便是優化，任何受阻，哪怕是一丁點，都會導致馬達或 H 橋或電阻瞬間發高熱；故，影片中反覆的開闔，便是要去抓那甜蜜點，盡量致，輕輕闔上，輕輕全開。
• 階數也是一絕！別忘了，是玩具馬達。。。故，也是在 ADC 的旁監下／同於上述，在開與闔之間，追求盡量明顯的劃階，即，我既知兩端碰壁的即時瞬態發生點，那麼我已跑了幾階，例如，現 25 階可行，那麼我會再試 26 階，假設取到了 30 階為最高了，表我成就了可行的最細解析度（純假設，馬達只被過電了 1us）；進而降化成 7 階，參數如此而得。此確保了在實際運作下極關鍵的一點；使作動 1 階，將是最大努力；而實測下，仍有機會發生，作動距離小於預期距離／但盡力了。（註：存在著所謂的啟動門檻）
• 是的還沒完，車載，電壓 11~15V 都有可能發生，意謂著馬達的驅動電壓不定。參數便必跟著變化。
• 別忘了筆者還有 file-db 函式庫／後述，它貫穿著筆者大部份專案。
• 各種不同電壓，上車前就全都先調試過一遍，儲存。上車後，實時地／週期性地比對當下電壓以載入對應參數。
• 結案
• no…看看，介紹就寫這麼多，那麼，程式呢它代表著？

9. buzzer 蜂鳴器

• 有影片 DEMO
• 前兩個，主控台，閥門控制，再加上這個，是中控台。另外再加上一個純 AP。所以車載上用了 4 個 ESP8266，合成一套系統。(及後來又追加了語音控制)
• 主控台供使用者手動控制用。閥門，當然可以被主控台操控，亦可被中控台自動控制。現在就來說說中控，做了哪些事。
• 蜂鳴器，用上了 MultiPWMs，調制過，讓它聲音不會那麼單調。汽車的轉速，每 1000 轉，便會鳴叫對應的次數。（因為是手排所以轉速多少是重要的）。
• 但，汽車轉速怎麼來的，這就是中控的責任了。這台，可是 30 年前的汽車，沒有 OBD/OBD2。
• 找到汽車的轉速訊號後，先示波器量測確認訊號的樣態。之後用 ADC or GPIO 忘了，來算出轉速。再由中控無線多播出來。所以車子一旦發動，多播資料是一直在發送的。
  影片中也展示了，ESP8266 的無線距離，被接受度是蠻高的。
• 轉速多少，決定了閥門的開度多少；因為轉速愈高，單位時間排氣量愈多，閥門愈開，致，或說愈省油，或說燃油效率愈高。
• 三十年前的冷氣。。。也是找到了它的相關訊號，從中截斷，以由中控取代，干嘛。。。試著實現恒溫控制；
• 開關訊號的取代，順利完成，不過，作動非預期，其後得知，其有回饋訊號。。。哈，人家可是 ESP8266 揑；經一連串取樣判別後，讓中控仿照回饋訊號頻幅去騙冷氣。
• 至此，整個冷氣的取代控制便告順利完成。不過XD，懶了，溫度的 sensing 就沒再繼續做下去了。。。

10. 使用 LittleFS 儲存與載入變數／資料（file-db）

• SPIFFS/LittleFS 檔案系統，既已被 Arduino 內建支援。
• 當然，檔案的一系列的開／關／讀／寫／搜，沒什麼問題。
• 不過就是嫌麻煩，若能，某個變數，呼叫某個函式便能將其存入 flash 是不是方便多了／載入亦然。
• 甚而，若某變數再賦予 id，那，是不是變成，類似資料庫了，id 將可是各種不同的定義屬性，例如，時間戳記，具大區間的－電壓值，等。後面／即 codebase，的 services 也利用上此 id；相同的變數名，不同的結果值，乃對應／索引於不同的同步對象之 service-port-id。當切換對象便循 id 載入對應專屬參數。輕而易舉且適得其所！

11. Heap operations 再次登場

• 本文開頭就已介紹過，不再贅述。接下來介紹兩大巨頭；而 Heap，正是重中之重，它們的靈魂！！！

12. MultiTimers

• 此化腐朽為神奇之作，不需要多大篇幅。細節請見 MultiTimers 的各篇開發歴程。
• 眾所周知，ESP8266/8285，有兩隻 hardware timers；一支已被官方 SDK 專用；另一支 HwTimer1／後述簡稱 HT，則可讓使用者運用；不過，Arduino::esp8266 是有使用到此 HT，例如 pwm／我不確定；故，請留意衝突問題。
• hardware timers 不同於 Arduino 所內建者，其有何助益請自行谷歌。
• 什麼是 MultiTimers，它干了什麼？
  顧名思義，由 HT 派生出很多支 timers，並且也全都俱有 interrupt servicing／ISR 屬性，並且不限定它的週期，是謂也。（有啦，有限定下界）。
  簡單講例如，MultiTimers(HT) == HT(period=90us) + HT(period=133us) + HT(period=76us) + HT(period=321ms) + …
• 特徵，頻繁地於陣列上移除及插入元素；主要也是因此而需用上 heap。當然，是 min-heap。總是移除最快到期者，並插入新的它。
• 例如，18ms(2ms60us)，900us(889us)，7ms(888us) 三隻 timers 現況，那麼即將 7ms 的先到期並重新插入 7ms。
• MultiTimers 預設使用了陣列大小 15，恰為 4 層二元滿樹。原則上元素愈多，對比線性愈有效率；否則說實在的，效率說不定直接線性巡訪還比較好些。但筆者預估，大於一半，7，應 heap 就會出頭。當然，互補用，便是可以改善的空間／若改版會做。
• 既然，派生出的眾多 timers 徒子徒孫皆屈服在我的魔爪之下，自然，同步，是少不了的，即，可指定，timer2 offset timer1 若干。如此將有助於更廣泛的應用；即實現相位差。
• 結論，
• 一隻 hardware time 顯然不夠用。軟體 min-heap 解放了受限的硬體！
• 忌於 ISR 內停留過久這也是先天上的缺點。另一個缺點，就是最小公倍數後的擁擠問題，當然程式上也是盡量地排解。
• MultiPWMs 便使用了 MultiTimers 來實現。當然，用上它後，使用者還可自己派生出更多 timers。
• 從程式碼實現付梓至今也已兩年半了，認知上也有很大的長進，例如中斷延遲，GPIO 耗時，Timeout 的釐清等，相信下次改版必可更盡善盡美！
• 前面提到，ESP8266，於此，能夠多吸引您一些嗎？不行？兄弟！MultiPWMs 登場！

13. MultiPWMs

• 有影片 DEMO：（在 ESP8266 MultiPWMs Lib ver.0.7 文中）展示了同時跑了 13 隻 PWMs（實際掛上的 gpios 8 支），並且彼此之間有指定相位差。示波器展示其中 4 隻的 waveform，實時地調頻，調 DC，調相。（各自不同的哦）
• ESP8266 中斷延遲是可觀的，於此暫且稱 4us（大概。但已另有精測），這也是它最大的敗筆／但可以理解因有常存的 WiFi。
• 因此，（製作原理），MultiPWMs 技巧性地派生出了 4 隻 timers，每隻皆是 196us 週期，分別循序地 offset 了 49us，致成 50us 週期的可視為單一 TIMER，卻擁有 4 個依序相距 50us 的 ISRs。如此，以盡量避免 MultiTimers 的擁擠衝突缺陷。
  之後，所有的派生出的 pwms 將會平均分散在此 4 個 ISR-Time-Slot 中。
• 限制：MultiTimers 有的，MultiPWMs 就有。而 MultiPWMs 時距是 50us，所以任一派生出的 pwm 之週期都必須是 50us 的倍數，並且最小不能低於時基 200us。。。。。是有點高，不過真的盡力了／不能再低了會崩XD
• 結論（不是我的結論），
  （諸位看出一點）極端苛求效率與成本將之納為本能，將是成長的原動力之一，即使像 ken 一樣是螞蟻腦，亦能有所長。
• 所以，MutltiPWMs 問道：裏雜摳A ESP8285/8266，用不用？

14. 自己真覺得有實用性才推的

• 事實上，筆者自覺得還有不少的其他內容也都有實用性。
  代表性地，再自薦一篇，SerF，其位於案例專題頁面內。現另以直接連結地，如下 GitHub，
• https://github.com/kenwoo777/SerF
• 阿有人會問，怎專案不放 github？。。。。。阿自己就有網站了。。。對吧。。。；不過是有考慮之後有空會再多放一些上去。。。
• SerF 是什麼？
• 這篇，若沒記錯，筆者也是沒日沒夜地，可能也搞了至少 2 個月有吧。。。
• （描述不精確因也忘得差不多了，用法請自行研究）
• 全自動地全文搜尋某指定字串（檔名亦可）於某個目錄底下的／含子目錄，所有純文字檔的內容，或壓縮檔其內容物的所有純文字檔的內容；當中，若壓縮檔中還有壓縮檔，則可持續無論套娃多深地深入找下去撈出來。
• 對了想起來了一滴，瑞士小刀。複合功能。所指定的某型式的檔案（名），無論藏得多深，無一幸免地會被複製到指定的地方存放（當初目的就是為了把所有 pdf 複製出來，但它們分散在壓縮檔內的壓縮檔內的。。。）
• 注意到，測果，5352 隻檔案共 277 GB，費時 18 小時，列舉完成總共 3,000,000 隻檔案，對三百萬。所 output 出來的檔案路徑及 sha1sum 所成的一份文字檔高達 2.4GBytes。
• 說得容易，為了實現這份程式／腳本也真的是在自我挑戰我的能力極限XXD。。。

DEMO

• 簡述一下 2 項 DEMO，皆是以前的 projects 再修改一下以更主題性地展示成果。其一是最近的一個 Sync-time 專案，另一個為語音識別控制 Voice-recog。所有程式碼附於後。
• Demo1：Sync-time
• A. 有一支 dongle，能做手勢辨識控制，首先秀 ntp time，中元標準時間，即，the light-weighted IP 具體而微地展現在 20 元的 ESP8266 上。
• B. 手勢控制四片 WeMos D1 mini 開發板的 LED on/off
• C. 四片開發板使用 espnow 協定廣播而同步，其同步效果差（因循序廣播）。偏差可高達幾百 ms。
• D. 隨後做 accurate time synchronization，四者間之時間偏差 < 30 us。且效果長達數天（<100ms/3days）。
• Demo2：Voice-recog
• 可前往此網站看一下 http://kenwoo.ddns.net/，但應是暫時性的，過一陣子應就會關掉。
• A. 網站 http://kenwoo.ddns.net/ 會秀一張圖片，若 15 分鐘內沒有任何人訪問，則會是“旭日東昇”圖片。若 3 天內沒有人訪問則會是“釋迦牟尼”圖片。
• B. 對 voice-recog dongle 講 4 種指令則將會讓網站更換成對應的 4 張圖片。
• C. 對 dongle 講 “文字模式”，則網站將亂數産生，秀出一串 10 個英數字元，刷新則重新産生，講“閱讀”，則 dongle 將會將此串朗誦出來。
• D. 此經典地而應景地 demo 了，Internet of Things，IoT，口頭下指令於手持裝置，傳達至遠端伺服器／存取資料庫，由網站的首頁展示出來並維持 15 分鐘後再回復原貌（往）。（返）手持裝置從網站／或資料庫取得資料並朗誦出來。