For Visual Studio Code
Just use command code to open Visual Studio Code from Terminal
For example: code path/of/file
For Sublime Text editor
Just use command subl to open Sublime Text editor from Terminal
For example: subl path/of/file
為了加速 VM 的執行速度，VM App 以及 Virtual Disk 都是存放在 SSD，
最近 SSD 的空間開始吃緊了，所以想在 Ubuntu 18.04 上再掛接 (Mount)
顆實體硬碟。
Steps:
1: Power off your VM on VMware Workstation
2: Select your VM and edit virtual machine settings
3: on "Hardware" Tab, Select "Add..."
4: Select "Add -> Hard disk"
5. Select "Use a Physical Disk"
6. Select a Physical Disk ( a partition or entire disk, as required )
在這裡，我是掛接 EXT4 Partition， 在 Windows 10 的系統下是不會使用的，
若是你要掛接的 Partition 在原系統 (Host) 會使用到，
就請參考底下連接 ( VMWare 原始說明 )。
這篇文章就和大家來分享我對 MicroPython 的看法。
對於一直用 C 語言編寫程式的我，加上對 Python 的了解，知道 Python 需要直譯器(Interpreter) 以及 VM (Virtual Machine) 的轉換執行，所以在第一時間，我覺得 Python 是不適合在 Embedded Microprocessor 領域的，因為透過直譯器以及 VM BYTE 的轉換執行，程式碼的執行效率絕對不如 C 語言，在 Embedded 這樣寸土寸金的環境下，MicroPython 根本不適合；但是經過深入的研究後，現在覺得 MicroPython 在 Embedded 的領域，還是有他潛在的市場以及優勢，值得去學習；所以在這一篇文章裡，我將透過 MicroPython 和 Arduino 的比較，來告訴你哪種情境適合 MicroPython，以及哪些人需要 MicroPython。
MicroPython 最小需求 (minimum requirements ) 是 256KB 的 ROM 以及 16KB 的 RAM，也就是說，對於只有 32KB 的 ROM 以及 2KB 的 RAM Arduino UNO 而言，想跑 MicroPython 是想都不要想的，更廣義的說，在 Arduino Store 販賣的板子，大多數都不適合跑 MicroPython 。
另外，就 MicroPython 官方 Py-Board 的規格是 ARM-based Microprocessor 這點 ，也隱約的告知，想要 MicroPython 跑的順，就是需要 ARM-based Microprocessor ，以下是 Py-Board 的硬體的規格
STM32F722IEK microcontroller ( 32-bit ARM )
216 MHz Cortex M7 CPU with single-precision hardware floating point
512KB internal flash ROM and 256KB internal RAM
就連做為青少年程式教學的 micro:bit ，它的硬體規格也是 ARM Cortex M0 等級
ARM Cortex M0 32-bit microprocessor
256KB internal flash ROM and 16 internal RAM
所以，對於應用領域是 "小型系統" 的，MicroPython 就不適合了。
PE (Product Engineer), QA (Qualuty Assurance) 以及 FAE (Failure Analysis Engineer) 這些領域的工程師都長期使用 Script，而 MicroPython 就是以 Script 起家， 這樣一個特性的程式語言，非常適合像上圖這樣的工作情境。
另外，使用 MicroPython 做為你測試的基礎，基本上，你只需更改上載 main.py 就可以重新做測試，無需像 Arduino (C 語言)，即使只是改一行程式碼 ，還是需要重新編譯，重新上載整個程式碼，這樣麼費時費力的程序。在上圖這樣的工作情境上，MicroPython VM 慢的缺點，也立馬轉為優點，不是嗎？
所以，有 1) 自動測試 2) 元件測試或 3)控制測試設備，這樣需求工作領域的人，就非常適合利用 MicroPython Script 的特性來做到測試的工作。
今日 Python 會這麼火紅，除了易學外，Package 的完整度 (如 machine Learning) 更是把它推向近幾年來，程式語言第一名的寶座。
所以，想實踐你的創意，而你的創意又可以透過這些 Packages 的加持，達到快速完成 prototype 的話，那 MicroPyhon 絕對是你最佳的選擇。
或許你會問，那為何不是樹莓派 (Raspberry Pi) ，而是 MicroPython 呢 ?
在這裡，我給的答案是系統大小的選擇 ；這就好比你的 Prototype 是要架構在複雜Linux Embedded OS， 還是要像 Arduino 有或沒有 RTOS 的簡單系統架構之分別而已。畢竟要在樹莓派 4 核心的 Linux系統上實踐你的創意，開發時間以及成本都不低啊！
在 Real-Time Embedded System 的學習道路上，Arduino 與 MicroPyhon 的選擇，我個人建議是 Arduino；這就好比一台機器，Arduino 比較像是把機器組起來的那個角色，而操作那台機器的角色就是 MicroPyhon 。也就說，如果你是學生，還在學習寫驅動程式，那 Arduino 就較適合你，但若你是創客，或是喜歡 DIY 改造的人，MicroPyhon 就非常適合你，因為 MicroPyhon 已經把基礎架好了，你可以擁有更多的時間專注在你的創意上。
當然，用 MicroPyhon 來學習驅動程式的撰寫，也不是不可行，畢竟 MicroPyhon 的底層，也是以 C 語言完成的；但我偏向把它歸類為高階 Library 的撰寫，也就是說，比較不適合初學者。
[WSL] 實測 WSL Mount Command
透過不斷的升級，花費一上午的時間，迎來的 Mount Command，當然要實測一下喽！
首先是透過 wmic command 取得硬碟路徑
接著按照說明文件，省略 --partition 的指派 (說明文件說可以省略)，卻得到錯誤的訊息。
這是加上 --partition 的指派
EXT4 partition 就真的掛接上 Linux Subsystem 了 :-)
在 Linux Subsystem ，可以看到 EXT4 硬碟是被掛接在 //mnt/wsl 目錄下
接著，在掛接的 EXT4 硬碟上建立目錄，開檔案，也一切正常！
接下來就等 Mount Command 正式的 Release 了！
[WSL] WSL Mount Command
之前在研發大型專案， 如 Android 系統，都是在 Ubuntu OS Terminal 的環境下做開發，
但是平時常用的 Apps，卻又是在 Windows 系統下 ，如 Office, Outlook...；在只有一台
電腦的情況下，一般的解法不外乎就是 1) 裝 VM 或是 2) 安裝 Windows Ubuntu 雙系統，
不停地切換，工作效率真的很差！
知道有 WSL ( Windows Subsystem for Linux ) 後，就迫不及待的安裝來使用，使用後的
心得是 "很棒"！真的可以解決 1) VM 拖慢系統速度以及 2) 雙系統不停切換的問題了。
但是有一點就是它 ( Linux System ) 只能安裝在開機硬碟，佔用了 SSD 的空間；
Linux Subsystem 安裝在 SSD 是可以被接受的，但是 Development Code 佔用開機硬碟的
空間就真的無法接受了。
所幸，Windows 的開發人員也看到了這個問題，在 Window 10 Insider Preview 20221 build
就帶來了好消息！User 可以掛接 ext4 的硬碟供 Linux Subsystem 使用。
但因為是 Preview 版本，只有加入Windows 測試人員計畫才能正規取得。
畢竟是 Preview 的版本，還未通過穩定以及安全性的測試，所以我採用的方法是 “Dual Boot”，也就是不直接升級平時用的 Windows，而是將 Preview 的版本安裝在另一顆硬碟 ( PS : 試用 Preview 版本後的心得是 : 還好我有這樣做 😁😁😁 ，因為 "Dual Boot” 還一度失效，我平時用的 Windows 差點回不來 )。
這是 Window 10 Insider Preview 20221 build 安裝完成的畫面
透過不斷的升級，最終迎來我要的 WSL "Mount" Command， 20221 build 才有的喔！
將 Quest M3 與 Artisan 結合後，從烘培曲線發現， "風力" 的影響比我想像的來的大啊！
下圖是 "哥斯大黎加紅蜜處理豆"的兩次烘培曲線圖，這兩次烘培的火力都是一樣的，主要的差異就在進入梅納反應的風量調整，分別是風量 8 和 7，而最終呈獻出 “風量 7” 的烘培曲線，在烘培時間以及曲線上升幅度的表現，都比“風量 8” 的曲線，明顯來的短以及大，圖 3 就是兩曲線的比較圖。
另外，我標記的 A 點，可以明顯看到豆子的溫升曲線有一個急遽的溫降，那是我透過取樣棒觀察是否要下豆，這樣的"小"動作所造成的。
之前，只是透過書本得知風力對咖啡烘培的影響，但透過自己的實驗以及 Artisan 烘培曲線幫助，發現風力 (進風 & 抽風) 對咖啡烘培的影響可真是大啊 ！比我認知的還來的大啊！
For this error, please try below 3 possible solutions
# Possible Solution 1
You may not install Python yet, please follow below command to install it
sudo apt install python3.7
# Possible Solution 2
You have installed Python3, but "python" command is not equal to "python3"
Please follow below command to let them equal (Ubuntu 20.04)
sudo apt install python-is-python3
# Possible Solution 3
Symptom is same as "Possible Solution 2", but OS is Ubuntu 16.04.
Please follow below commands to create a symlink
whereis python3
run above command to get Python and Python3 installed directory\ies
sudo ln -s /usr/bin/python3 /usr/bin/python
run above command to create a symlink, the /usr/bin/python3 and /usr/bin/python are examples, please instead by the result of "whereis python3" command
HeliOS 的特點：
Open Source 的 Embedded OS (Operation System)，是 GPL-3.0 的License，也就說，對於專題製作而言就是免費的 。
採用協同式多工 ( Cooperative Multitasking ) 以及事件驅動式多工 (Even Driven Multitasking ) 的方式做Task 的切換。
Task 之間可以透過 Notification / Messaging 做資料訊息的傳遞。
一般的 Embedded OS 都有的功能，如計時器和記憶體的管理，它也有提供。
以上這幾項特點都是制式說法，不是我主要推薦給大家的原因， 而我推薦的理由有以下三點
小而美 :
以我改寫咖啡烘培程式的實作為例，HeliOS 佔用的記憶體空間，Program Memory (ROM) 則是約 1400 bytes, Variables (RAM) 則是 230 bytes，這絕對是 embedded OS 最小的；對比於 FreeRTOS 至少需要 5K ROM, 400 bytes RAM (以 2 Tasks 計算)，記憶體空間以及複雜度，HeliOS 是絕對小而美，但小歸小，五臟則俱全，Embedded OS 基本該有的 Notification / Messaging / Timer / Memory 的功能，他都有喔，對於專題製作的需求也是綽綽有餘的！
容易上手 :
再來則是容易上手，沒有負擔；只有 21 個 System Function Call，花 1~2 個小時研究一下，絕對就可以上手使用它。再加上是協同式多工(Cooperative Multitasking )，不是佔先式多工 (Preemptive Multitasking)，也就沒有 Mutex, Deadlock, Race Condition 這些擾人難解的疑難雜症了；也因為是協同式多工 ， Porting 到不同 CPU ，不須動用到組合語言就可以輕鬆移植到不同的單晶片上，CPU Porting 的困難度相對於 RTOS 就低很多了 !
程式發展不受限 :
最後一點則是程式發展不受限；這項優點是 Embedded OS 對比於 Super-loop 模式都有的特點；以Super-loop 模式發展的程式碼，到一定的複雜度後，例如專題製作的後期，Super-loop 的模式絕對會遇到瓶頸；通常是加了一堆 IF…，來做到類似 GoTo 境界；可能兩天沒碰程式碼，就不知道自己在寫甚麼了，不是嗎？
所以擁有
能把有工作事項以 Task 概念區隔開來的HeliOS 絕對是專題製作的首選。
加上小而美，容易上手，沒負擔，在專題製作初期就可以導入 了，當然也就不會發生後期才導入OS，騎虎難下，兩難的囧境了。
對於沒有寫過 Embedded OS 的專題新人而言，小而美，容易上手，也正是想學Embedded OS的最好入門首選。
I met this issue before. I use Putty, when I changed "Flow Control" from "XON/XOFF" to "None" under Connection -> Serial setting Category, this issue is gone.
After checked with ESP8266 data sheet, ESP32 / ESP8266 chips do not support the "Flow Control", that is why I changed "Flow Control" from "XON/XOFF" to "None", the issue is gone.
Hope this information can help someone.
