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 就可以了。

MacOS Catalina App 『已損毀，無法打開。你應該將其丟到「垃圾桶」』的錯誤訊息

MacOS 升級到 Catalina 後, 一定會被他嚴密的安全控管驚嚇, 比如說, 你從 Arduino 官網下載了 Arduino, 可以正常執行, 但如果你把這個 Arduino 上傳到 Google 雲端硬碟, 然後再從雲端硬碟下載回來, 一執行可能就會遇到這樣的畫面：

這是因為 Catalina 會自動幫不是從註冊網站下載回來的 App 加上註記, 執行時會根據註記的資料, 判斷是否可安全執行。你可以透過以下的指令觀察註記資料：

xattr -l Arduino.app/
com.apple.quarantine: 0181;5ddd072e;Firefox;BCD73B6E-DE9E-4821-93E6-C73238A5F5AF

xattr 是操作檔案延伸屬性的指令, 這裡可以看到 Arduino.app 有一項延伸屬性, 屬性名稱是 com.apple.quarantine, 而屬性內容是雖然是編碼過的資料, 但可以看到註記了此 App 是使用 Firefox 下載回來的, 只要將此註記資料刪除, Catalina 就不會檢查 App 是不是從註冊網站下載的, 也就可以正常執行了。刪除此註記資料的指令如下：

xattr -rd com.apple.quarantine Arduino.app

-d 選項是刪除後面指定的延伸屬性, 而 -r 選項是遞迴處理資料夾內的所有檔案與子資料夾。