VIM 的眾多版本差異

在 Linux 上安裝 vim 如果沒有特別指名套件名稱, 例如：

sudo apt install vim

那麼安裝的會是 vim-common 套件, 這個套件只會安裝文字模式的 vim, 不會安裝圖形化版本的 gvim, 而沒有圖形化版本的套件, 邊一時是不會加上 +xterm_clipboard 模組的, 也就是無法讓 vim 複製資料到系統剪貼區 (clipboard), 也無法從剪貼區貼資料到 vim 中。

因此, 建議在安裝 vim 時, 可以選擇有圖形化版本的套件, 例如：

• vim-gui-common：通用行的圖形化版本, 如果沒有什麼特別需求, 或是面對以下版本不知道該選那一種, 就可以安裝這個版本。
• vim-athena：採用 X Athena 圖形元件程式庫的版本, 如果你執行這個套建中的 gvim, 會注意到他的圖形界面長的很不一樣, 那就是 X Athena 程式庫。這個版本體積小一點, 如果你不介意界面長的怪怪的, 或者根本就不會執行 gvim, 那安裝這個版本根本沒差。
• vim-gtk/vim-gtk3：搭配 gtk 同行界面程式庫的版本, gvim 的界面看起來會正常許多。如果你的環境本來就會用到許多使用 gtk 建制的軟體, 那就可以安裝這一個套件。

如果你根本不會執行 gvim, 也不在乎能不能與系統剪貼簿交換資料, 那麼也可以安裝 vim-tiny 套件, 這個套件是 vim-common 的精簡版, 最主要的差別是 vim-tiny 只能使用 vim 語法撰寫 vim 腳本, 無法使用 Python 或是其他程式語言撰寫 vim 腳本。

ESP8266 MicroPython 所有的 PWM 都是同一頻率

下午看了一下 ESP8266 MicroPython 的原始碼, 才發現原來所有的 PWM 都是共同頻率, 無法個別設計, 無論使用哪一個 PWM 物件叫用 freq(), 都會影響到所有的 PWM 物件。原始碼中實際設定頻率的程式如下：

void ICACHE_FLASH_ATTR
pwm_set_freq(uint16 freq, uint8 channel) {
    LOCK_PWM(critical);   // enter critical
    if (freq > PWM_FREQ_MAX) {
        pwm.freq = PWM_FREQ_MAX;
    } else if (freq < 1) {
        pwm.freq = 1;
    } else {
        pwm.freq = freq;
    }

    pwm.period = PWM_1S / pwm.freq;
    UNLOCK_PWM(critical);   // leave critical
}

你可以看到雖然函式有 channel 參數, 但在函式內根本不會用到這個參數, 而且頻率是記錄在 pwm.freq 中, 不會區分是那個 channel 的頻率。

改用 highlight.js 為文章中的程式碼加上語法顏色標示

原本使用的 SyntaxHighlighter 在 Blogger 上一整個炸壞掉, 現在改用 highlight.js, 快速簡單, 中間也考慮過 Google 的 code-prettify, 但是會有程式過長疊到右邊側欄內容的問題。

ESP8266 MicroPython PWM 的奇怪現象

同事在使用 ESP8266 的 MicroPython 時, 使用 PWM 製作呼吸燈, 但卻遇到了奇怪的狀況, 程式如下：

from machine import Pin, PWM
import utime

# R:D5 G:D6 B:D7
r = PWM(Pin(14, Pin.OUT), freq=500, duty=0)
# this line would make PWM work in a strange way
g = PWM(Pin(12, Pin.OUT), freq=500, duty=0)
b = PWM(Pin(13, Pin.OUT), freq=500, duty=0)

while True:
    for i in range(512):
        b.duty(i)
        #g.duty(i)
        r.duty(i)
        utime.sleep_ms(1)        
    for i in reversed(range(512)):
        b.duty(i)
        #g.duty(i)
        r.duty(i)
        utime.sleep_ms(1)

其實就是簡單的用 2 個腳位 PWM 從 0~512 再回到 0 製作陽春的呼吸燈效果, 不過執行後卻發現其中一個燈看起來一直亮著、另外一個燈卻偶而才閃一下,  根本沒有 PWM 漸次變化的效果。

經過實驗測試後發現, 程式一開始建立了 3 個 PWM 物件, 但是 g 這個 PWM 物件卻沒有用到, 如果不要建立這個多餘的 PWM 物件 g , 或是在實際上有使用到 g 物件, 例如把程式中 for 迴圈內的註解符號移除, 結果就正常了。目前還不知道實際發生問題的原因。

20200830 補充：這個問題我有貼到 MicroPython 論壇上, 經過善心人士回饋到 MicroPython github 上後, 已經把 bug 解掉了, 如果你改用 2020/3/27 之後的韌體版本, 就不會發生一樣的問題了。

20200909 補充：在 2020/09/02 發佈的 1.13 版韌體中, 已經將上述修正併入正式版本了。

macOS 的 APFS 與 HFS+ 檔案系統對磁碟影像檔的影響

如果要製作磁碟影像檔, 由於 macOS 在 High Sierra(也就是 10.13) 以後的預設檔案系統是 APFS, 因此若沒有更改設定, 指定使用 HFS+ 檔案系統, 製作出來的磁碟影像檔就無法在舊版的作業系統上開啟。製作影像檔時請務必小心：

MicroPython 文件上 framebuffer 的 framebuf.MONO_HLSB 與 framebuf.MONO_HMSB 說明反了

在 MicroPython 的文件中, framebuffer 的說明中對於 framebuf.MONO_HLSB 這樣一段：

Monochrome (1-bit) color format This defines a mapping where the bits in a byte are horizontally mapped. Each byte occupies 8 horizontal pixels with bit 0 being the leftmost.

因此, 如果有以下的 8X8 的圖：

就應該表示為這樣：

[0b10001001,
 0b00001001,
 0b00001001,
 0b00001001.
 0b00001001.
 0b00000001,
 0b00000001,
 0b00000001]

不過實際上顯示出來的圖左右會相反, 因此推測文件上 framebuf.MONO_HLSB 與 framebuf.MONO_HMSB 的說明應該是弄反了。在 MicroPython Forum 上也有人確認我的疑問。

Maixduino 編譯 selfie 範例出現 "cannot declare variable 'camera' to be of abstract type 'Sipeed_OV2640'" 錯誤

在編譯 Maixduino 板的 selfie 範例時, 竟然出現以下錯誤：

cannot declare variable 'camera' to be of abstract type 'Sipeed_OV2640'

經過查證, 在這一篇文章中提到在 0.3.11 版的原始碼中, Sipeed_OV2640 類別的內容把虛擬函式的名字 setRotation 打錯字變成 setRotaion, 導致繼承自 Camera 類別的 setRotation 虛擬函式沒有實作的內容, 讓 Sipeed_OV2640 類別仍舊是虛擬類別, 無法用來建立物件。解決的方法很簡單, 就是自己去 c:\users\你的使用者名稱\AppData\Local\Arduino15\packages\Maixduino\hardware\k210\0.3.11\libraries\Sipeed_OV2640\src 下, 把 Sipeed_OV2640.h 以及 Sipeed_OV2640.cpp 中的錯字 setRotaion 更正為 setRotation 就可以了。