心中大罵f**k，溫度計自從摔地上之後就顯示 L。有可能是Low Battery，也有可能是Low Temperature… 但是量了電池電壓，是 1.5v，那就排除了電池問題。

於是拆開一看，傻眼了()

原來是熱電偶的線給我摔炸了啊xxx
那還不修起來，飛線飛線。 此時我還在發高燒 39 度，但爲了能量體溫，那也沒辦法了。

進行飛線修復

先把線飛出來，然後用三秒油固化防止短路。

然後焊接到斷掉線的焊盤上，這個步驟比較困難，因爲線很細，而且溫度計的 PCB 也很小。

修好了 繼續躺

(又省錢了 (不是
其實在意識到溫度計可能壞了之後，馬上就買了新的，但是新的還沒到… 當時氣得想去小料庫找 NTC 用 Arduino 自己先搓一個。

算了，總之繼續躺了。

半年前買了一台 surface pro 9 之後，直接 ntr 裝了 debian。
雖然半年使用體驗下來，個人覺得一致性體驗會比正統 windows 差點，但我仍然通過很多小技巧讓 linux 成爲了我的主力。 我就不買macbook 我就不買 就不買 氣死你們

這篇 blog 大概用作備忘，每次滾內核都要手動簽一下，挺煩的
就幾個命令的事情，所以還不想去手動去配 dkms，懶了懶了

關於安全啓動

安全啓動固然好，但是有些時候又想偷懶。畢竟我都有 root 了我還有什麼不能幹的x
主要問題是，在啓動 kernel 之後，內核似乎會同時啓用 kmod 的簽名檢查，讓一些原本沒有簽名的模塊無法正常加載。
比如設備驅動、虛擬機內核模塊 等(真的是很浪費時間耶

至於如何在 surface 啓用安全啓動，這邊就不再贅述了，如果你同樣有 surface 運行 linux 的需求，你可以跟隨 GitHub 上的 linux-surface 項目的 wiki 進行配置。

(大抵還是 mok 那一套

簽名流程

因爲我這邊需要簽名的東西是 vmware 的 vmmon 和 vmnet，所以我就以這兩個模塊爲例。
你問我都 linux 了爲什麼不用 kvm? 大概還是因爲習慣了 vmware，畢竟還需要管理一些 esxi 實例。二者都可以，只是對我來說 vmware 方便而已了。

簽名流程非常簡單。首先，你需要一個私鑰和一個公鑰。然後，你需要將公鑰加入到你的 MOK 中，這樣你的內核就會信任你的模塊了。
那麼上命令吧。

1
2
3
4
5

$ sudo /usr/src/linux-headers-$(uname -r)/scripts/sign-file \
  sha256       \
  <mok priv>   \
  <mok public> \
  $(modinfo -n <mod>)

其中，<mok priv> 是你的私鑰，<mok public> 是你的公鑰，<mod> 是你要簽名的模塊，如果你有正常跟隨 surface-linux 的 wiki 配置安全啓動的話，你應該會有一個密鑰對，直接用它們就行。

這樣，模塊就被簽名好了。直接用 modprobe 或者 insmod 加載上去就行。
或者更簡單一些，reboot。

這個方法同樣適用於 virtualbox，簽完加載即可。
順便說一句 virtualbox 的3D圖形加速有大約 300MB/s 內存泄漏，開機直接被 oom kill。xs

引用

• [1] I can’t execute command modprobe vboxdrv
  https://stackoverflow.com/questions/38437264/i-cant-execute-command-modprobe-vboxdrv
• [2] linux-surface/wiki/Secure-Boot
  https://github.com/linux-surface/linux-surface/wiki/Secure-Boot

DSC02735_origin.jpg

DSC02738_origin.jpg

拍照無時無刻不提醒著我該攢錢搞個好點的裝備了 (
我要長焦 我要長焦 我要長焦 我要長焦 我要長焦

應援棒, 顧名思義呈棒狀。當然也有一些特殊的形狀：比如棒上頂一個球 或者星星 之類,
但這種特殊棒不是這次改造的目標。

通常的應援棒大體由兩部分組成, 可以 擰下來的柔光罩 和 柄身。
柄身的 LED 發光, 照射在柔光罩上, 柔光罩上的柄圖會將光線散射開來, 形成柔和的光線。

此外柔光罩可以更換柄圖, 可以根據自己的喜好而定,
但大部分正常人的 DIY 也就到此爲止了。

至於比較激進的那些厄介大佬, 其性質會嚴重影響 live 觀看體驗, 原則上是不提倡的
所以本次改造基於 不影響他人體驗 為基礎

柔光罩結構

既然要改造, 那想必要如何去固定内部結構以達到最大的耐久性。

初步觀察, 柔光罩頂部有一個頂蓋, 它有兩個十分堅固的卡扣。
它看上去非常合理, 頂蓋卡扣扣死内部的小圓片,
裏應外合卡住頂蓋防止脫落。

那麽把它換成pcb, 在達到相同作用的同時, 還能為我們提供一個 pcb 的固定點,
以及作爲電池的觸點。不由得感嘆, 真是完美的設計!

頂蓋内側的秘密

讓我萬萬沒想到的是, 我嘗試了無數種方法去試圖戳頂蓋卡扣, 它竟紋絲不動。
柔光罩長度大約 20cm, 在拆解的時候力臂很短, 使不上勁。
外加卡扣的塑料質地意外的硬, 導致很難弄開。

然後我就放棄直接戳卡扣轉而去撬頂蓋, 結果大力出奇跡:

柔光罩蓋子被我幹碎了, 但導致我拆不下來的罪魁禍首也找到了: 原來是有膠。
好家夥, 還沒開始就結束了, 直接損 200 mmp)

可能在設計之初就考慮了拆卸, 但是量產之後發現公差太大卡扣不牢固,
所以破罐子破摔直接上硬膠粘接, 導致現在拆解困難。

這可怎麽辦…. 要不買一個別的棒子試試

柄身結構

柄身由 燈頭, 電路板, 按鈕, 電池倉 組成, 拆解時總體來說比較輕鬆。至少沒有膠
只需要拆下燈頭兩側的螺絲, 再把電池倉往内推, 此時燈頭會被推出來。然後用一個東西戳住背後的 hot buton (圓形的那個), 就全部拆出來了。

PCB

既然拆出來了那肯定要喵一眼 PCB 啦!

主板鑲嵌在塑料電池倉内, 透過一個摺彎過的的金屬絲與電池負極接觸, 另一邊則是電池的正極。二者的組裝方式都是透過焊接在 PCB 上進行的。

而且你這個回流焊是不是翻車了啊, 繞綫電感怎麽躺著貼上去了? 我要給0分

主板

强迫症受不了了, 把繞綫電感重新給他貼了一遍。

主板上有三個小按鈕, 看著質感非常不錯。是下了足夠的成本的 (欣賞

看看是什麽方案呢… 喔草, 你直接就是不打標是吧 (
而且越看越像STC..要不要讓姚老闆來認認貨 XD 。不過這個主控的秘密我們放到之後有時間了再研究

LED 燈珠

就這個燈珠而言, 給的還是很良心的。
至少這個燈珠除了基本的 RGB 三通道以外, 還增添了兩個額外的通道使其具備色溫調節功能。

這種燈珠一般叫 RGBWY LED, 兼具高亮和大功率以外的彩色 LED 方案。
W 嘛.. White, Y 嘛就是 Yellow 了。

另外絲印 KB1_R_LED_V5PD.. 這真的不是 kb 的板子麽?
我説的是 King Blade(無業配): 點擊購買! > KING BLADE ONE1 <

無論從外形到設計, 以及按鈕位置和形狀… 都是一模一樣的啊!
好啊, 你給我搞 OEM 是吧.wav

確認改造方向

首先, 柔光罩的頂蓋確認是拆不下來了, 似乎只能從拆解更方便的柄身入手。
其次 PCB 肯定是需要重新設計的, 只不過只改動柄身的情況下似乎並不需要高成本的 pogopin 之類的了。

(似乎也是一個好消息?

第一次將應援棒緊握在手中的喜悅和激動, 混合著周圍嘈雜的人群；
隨著音樂的律動大家整齊地開始揮舞應援棒, 會場内的天花板被晃動著的應援棒星星點點光芒映射出微微綠光；
小小的初音未來在透明的全息巨幕上翩翩起舞, 一旁的樂隊奮力演奏著樂器；
貝斯手近乎瘋狂的搖晃著腦袋, 會場内回蕩著跳躍的音符將演唱會慢慢推向高潮…

小時候的願望在今年終於實現了！

就這樣結束了嗎?

那當然不是! 我想成爲下次演唱會中最靚的崽崽 (當然不是厄介那種), 所以我想要一個更加炫酷的應援棒!
於是就有了這個系列 <-妳好多坑沒填完欸

off topic:
而且今年比較忙, 沒怎麽寫文章 )這次來寫個大的

改造的理論驗證

我想改造的部分是光源和控制電路部分。
將光源換成 WS2812, 在柔光罩的中間塞上兩顆 18650, 也許可以大大提高續航能力。

一些有趣的點子:

• 可以使用藍牙 BLE, 配對之後在持有多個應援棒的情況下, 可以同步顯示效果, 配合手機實現更多的功能
• 因爲光源位於柔光罩的中間, 需要靠柄身的 pogopin 來控制, 同時此設計也便於拆卸更換電池
• 不知道能不能做到配合角速度傳感器來實現揮舞顯示文字的功能 (因爲有柄圖會散光, 可能不好實現)

最近在忙著做 H3 的核心板, 朋友想幫個忙什麽的就寄過來了一個被他搞寄的 H3 開發板, 好讓我來參考參考。
所以我認爲 一個優秀的硬體工程師不僅要懂得怎麽去創造自己的作品, 還要懂得如何去檢測和維修。
咳咳.. 扯遠了2333。言歸正傳, 先來看看故障。

經朋友描述, 他把這個板子放進背包挂上充電寶, 然後綫不知道怎麽的被扭了一下, 就寄了。
他自己嘗試維修過, 拆了一個 dcdc 降壓晶片, 但是故障依舊。

既然知道了大概原因, 那麽我們就來順著這個方向看看。

對於大短路情況的檢修

維修廝常把「燒機」二字挂嘴邊。畢竟這是對於大短路故障的最快定位問題的辦法。
那麽我們也可以來。供電接入可調電源, 3V燒機, 限流1A。

焊接兩根燒機綫。

可以看到, 電壓被硬生生拉到了 2.6v, 對地大短路。

從熱成像的圖可以看出, CPU 核心對地大短路。 (這是真寄了)
根據 H3 的手冊, 我們可以參考芯片明顯發熱的區域, 對應位置正好是 VCC-3v3-IO 和 VCC-1v2-SYS。
所以可以先盲猜炸了兩路供電。

不管怎樣, 先把 CPU 拆下來再説。
熱風槍 350 度加熱, 用鑷子掀翻就行。

重新上電燒機, 大短路問題就處理好了, 看起來確實是 CPU 被擊穿導致。
那麽接下來就是挨個檢查供電了, 而且著重檢查上邊提到的那兩路供電。

參考著圖紙來維修

所幸的是, NanoPi-R1 是開源的, 所以我們能很輕易在網路上找到它的原理圖

上圖分別是 VCC-3v3-IO 和 VCC-1v2-SYS 的電路,
可以看到 VCC-3v3-IO 的輸出電感是 L4, VCC-1v2-SYS 的輸出電感是 L3。
那麽就去板子上找吧。

看起來被朋友自行維修並拆掉的 dcdc 晶片是它了, 它負責 VCC-3v3-IO 的供電。

上電看看 VCC-1v2-SYS, 輸出 5v! 這是直接把 1v2 擊穿了捅了 5v 到 H3… 不知道怎麽搞的

所以跟我一開始猜測的一致, 就是這兩路供電炸了。
那麽問題就都好解決了, 換掉對應的 dcdc 晶片, 問題就修好。

漏網之魚

當我滿心歡喜覺得快修好了之後, 重新上電測試發現, 它又恢復大短路狀態了。(草)
難道還有第三処炸管的地方?

經過熱成像排查, 忘記拍照了 )
這次出問題的地方是另一個 dcdc, 它負責 VCC-1v1-CPUX 的供電。

直接換新的晶片吧。

收尾工作

該修的都修的差不多了, 開可調電源打到 5v/2A 欄位, 不出現短路。
各路 dcdc 穩壓電路工作正常。那麽就是時候裝新的 H3 上去看看了。

接上串口綫, 打印了一些 kernel 啓動的日志。

發熱均匀, 沒有明顯的熱點, 工作完美 XD。

那麽剩下的事情就是洗洗刷刷乾净, 包好發回去了 順便到付兩塊紅磚。

總結

• 把電源修好通常能解決大部分故障
• 對地大短路問題一般是最好修的, 哪裡炸了換哪裡
• 可以根據 CPU 短路發熱的位置猜測是哪路供電炸了
• 跟著圖紙來, 善用萬用表

最後, 問題推測。這個板子沒有過壓保護電路的設計, 意味著如果電壓出現毛刺, 超過了 dcdc 的工作電壓就有概率擊穿。
所以扭了一下電源線, 還就真的可能炸機 (((

引用

• [1] FriendlyElec NanoPi R1
  https://www.friendlyelec.com/index.php?route=product/product&product_id=248
• [2] NanoPi R1 原理圖參考
  http://wiki.friendlyelec.com/wiki/images/a/ab/NanoPi_R1_V1.0_1809-Schematic.pdf

於是乎, 今天意外地把它從塵封的箱子中翻了出來。
順便最近一直想玩 Micro Python, 就看看能不能順便玩玩。
那就開始吧 XD

魔改 NodeMCU

RTL-00 模塊從設計上就和 ESP8266 模塊 P2P (Pin-To-Pin) 兼容,
所以可以直接代換, 不會出問題。

那我就直接用 NodeMCU 開刀了。 (以前買了不少這個板子
然後只需要按照下表接綫

然後再用 OpenOCD 試著連上板子。
如果一切工作, 將會看到 OpenOCD 識別到一個 Cortex-M3 核。

1

> openocd -f interface/cmsis-dap.cfg -f target/ameba1-mod.cfg

CMSIS-DAP 几乎是基操了。
所以如果你常玩 ARM 設備, 我會推薦你買一個 CMSIS-DAP。

附一個我改過的 target 配置。
來源 drasko/rtl8710-sdk-3.5a

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124

# Main file for Ameba1 series Cortex-M3 parts
#
# !!!!!!
#

set CHIPNAME rtl8195a
set CHIPSERIES ameba1

# Adapt based on what transport is active.
source [find target/swj-dp.tcl]

if { [info exists CHIPNAME] } {
  set _CHIPNAME $CHIPNAME
} else {
  error "CHIPNAME not set. Please do not include ameba1.cfg directly."
}

if { [info exists CHIPSERIES] } {
  # Validate chip series is supported
  if { $CHIPSERIES != "ameba1" } {
    error "Unsupported chip series specified."
  }
  set _CHIPSERIES $CHIPSERIES
} else {
  error "CHIPSERIES not set. Please do not include ameba1.cfg directly."
}

if { [info exists CPUTAPID] } {
  # Allow user override
  set _CPUTAPID $CPUTAPID
} else {
  # Ameba1 use a Cortex M3 core.
  if { $_CHIPSERIES == "ameba1" } {
    if { [using_jtag] } {
      set _CPUTAPID 0x4ba00477
    } {
      set _CPUTAPID 0x2ba01477
    }
  }
}

swj_newdap $_CHIPNAME cpu -irlen 4 -expected-id $_CPUTAPID

set _TARGETNAME $_CHIPNAME.cpu
dap create $_CHIPNAME.dap -chain-position $_TARGETNAME
target create $_TARGETNAME cortex_m -dap $_CHIPNAME.dap

# Run with *real slow* clock by default since the
# boot rom could have been playing with the PLL, so
# we have no idea what clock the target is running at.
adapter speed 10

# delays on reset lines
adapter srst delay 200
if {[using_jtag]} {
  jtag_ntrst_delay 200
}

# Ameba1 (Cortex M3 core) support SYSRESETREQ
if {![using_hla]} {
  # if srst is not fitted use SYSRESETREQ to
  # perform a soft reset
  cortex_m reset_config sysresetreq
}

$_TARGETNAME configure -event reset-init {ameba1_init}

# Ameba1 SDRAM enable
proc ameba1_init { } {
  # init System
  mww 0x40000014 0x00000021
  sleep 10
  mww  0x40000304 0x1fc00002
  sleep 10
  mww 0x40000250 0x00000400
  sleep 10
  mww 0x40000340 0x00000000
  sleep 10
  mww 0x40000230 0x0000dcc4
  sleep 10
  mww 0x40000210 0x00011117
  sleep 10
  mww 0x40000210 0x00011157
  sleep 10
  mww 0x400002c0 0x00110011
  sleep 10
  mww 0x40000320 0xffffffff
  sleep 10
  # init SDRAM
  mww 0x40000040 0x00fcc702
  sleep 10
  mdw 0x40000040
  mww 0x40005224 0x00000001
  sleep 10
  mww 0x40005004 0x00000208
  sleep 10
  mww 0x40005008 0xffffd000
  sleep 13
  mww 0x40005020 0x00000022
  sleep 13
  mww 0x40005010 0x09006201
  sleep 13
  mww 0x40005014 0x00002611
  sleep 13
  mww 0x40005018 0x00068413
  sleep 13
  mww 0x4000501c 0x00000042
  sleep 13
  mww 0x4000500c 0x700        ;# set Idle
  sleep 20
  mww 0x40005000 0x1          ;# start init
  sleep 100
  mdw 0x40005000
  mww 0x4000500c 0x600        ;# enter memory mode
  sleep 30

  mww 0x40005008 0x00000000   ;# 0xf00
  ;# mww 0x40005008 0x00000f00
  sleep 3
  mww 0x40000300 0x0006005e   ;# 0x5e
  ;# mww 0x40000300 0x0000005e
  sleep 3
}

隨手寫點固件

算了.. 不發了, 這個坑太大了。
我是一邊寫 Blog 一邊研究的。文章都寫了一半了, 沒曾想完美翻車。

説起來經歷了不少坎坷。

1. 移植了 Standard SDK 的 HAL 庫, 發現竟然全是從 lib 中 extern 來的符號,
   而對於寄存器結構是一點説明都沒有, 所以猜測應該是 nda 的。

2. 其次就是因爲沒有 flash 驅動, 要自己從頭寫。所以沒辦法在 OpenOCD 中下載固件,
   因爲上面 nda 的原因, 自己寫這條路幾乎也是堵死的。不過 GitHub 上倒是有一個參考, 但它不是很合我意。

3. 最後嘗試用 OpenOCD 寫 SRAM 試圖讓固件直接在 RAM 中跑,
   但不幸的是, 它崩了。

4. rust 有一個 sdk 庫。結果仔細一看它是 c binding, 實際上還是那個垃圾 Standard SDK。

算了算了, 翻車就翻車吧

最終鑒定: 沒救的電子垃圾。
以後有時間了再搞這個, 可以按第 3 步的方法繼續嘗試。

引用

• [1] rtl8710 倉庫
  https://bitbucket.org/rebane/rtl8710

• [2] rtl8710-openocd 倉庫
  https://github.com/sandeepmistry/rtl8710-openocd

• [3] RTL8710AF Datasheet 技術資料
  https://datasheetspdf.com/pdf-file/1304447/Realtek/RTL8710AF/1

以前的做法是刪掉目錄, 用一個沒有後綴名的檔案去頂替掉目錄, 這樣就會造成打開目錄失敗達到無法寫入的目的。
但是 QQ 更新了之後 (想必是有上傳 Log), 這個辦法不管用了。

所以這裡提出一個我的另一個想法。

利用 mklink 將 cache 目錄連接到回收站

這聽起來就很草, 來試試。

首先在 Folder Options 文件夾選項 找到並關閉 Hide protected operating system files.
然後進入盤符 C, 找到 C:\$Recycle.Bin\Recycle Bin, 點擊路徑編輯框, 將路徑記下來。

然後進入 QQ 的 cache 目錄, 敲入以下命令, 將目錄連接到回收站。

1
2
3

> mklink /J Audio F:\$RECYCLE.BIN\S-1-5-21-3915135931-3060788653-94912148-1001
> mklink /J Image F:\$RECYCLE.BIN\S-1-5-21-3915135931-3060788653-94912148-1001
> mklink /J Video F:\$RECYCLE.BIN\S-1-5-21-3915135931-3060788653-94912148-1001

實際測試

效果不太好, 文件可以寫入到回收站, 但是實際上桌面的回收站圖標進去還是空的,
有可能回收站自己也有 cache 一類的東西, 直接以文件系統的方式寫入不是很行。

那麽就連接到 \\.\NUL 吧

StackOverflow 搜索了一番, 發現 windows 上有類似 linux 中 /dev/null 的内核對象叫 \\.\NUL。
那麽就改掉上邊回收站的路徑, 重新 mklink 試試。

看一看文件夾被連接到哪去了—– 竟然在桌面

在 Windows 中, 你不能以 NUL 為名字創建一個檔案或者目錄, 想必這就是其中的原因。
在目錄連接到 NUL 之後, 應該不會再對硬碟有讀寫操作了。

• 利用 system tick 的中斷計數
• 保存上下文, 利用中斷進行上下文切換

這麽簡單概括肯定不方便理解, 一次講不完肯定要分兩次 (挖坑)。那這次就先來説説 system tick 的方式吧。

什麽是 system tick

這是一個 24 位的系統節拍定時器, 具有自動重載和溢出中斷功能,
所有基於 Cortex Profile M 的微控制器都可以由這個定时器獲得一定的時間間隔。

它每隔一段時間會產生一次中斷, 一般使用 1ms 為佳,
STM32 的 HAL 庫會使用 HAL_IncTick 來更新系統時間計數, 它就相當於整個單片機系統的心臟。

1
2
3
4
5
6

/**
  * @brief This function handles System tick timer.
  */
void SysTick_Handler(void) {
  HAL_IncTick();
}

HAL_Delay 它的内部就使用 system tick 來實現等待,
就連 HAL 庫中阻塞調用外設的接口也是使用它來進行超時檢測的。

基於 system tick 任務調度的實現

在知道它之後, 我們來開始講怎麽去用它實現任務調度。
我們需要擬定一下它整個運作的生命周期:

如上圖所示, 我們需要在中斷中遞增 tick_inc,
並在主循環中每次遍歷任務之前保存它並重置計數。 因爲中斷隨時會發生, 所以這一步要越快越好。
在遍歷中逐個減少任務的剩餘時間, 當有任務的剩餘時間為 0 或者小於 0 時, 執行該任務並重置它的剩餘時間。

這個模型的好處有

• 穩定可靠
• 編寫和使用簡單
• 平台相關程式碼少, 移植方便快捷
• 非搶占模型, 不會發生資源衝突

缺點如下

• 無法保證調度實時性
• 任務過多容易造成性能瓶頸

基於此模型的異步 Sleep 的實現

在理解整個模型如何運作之後, 那麽實現異步等待就非常簡單了。

因爲現在所有的任務都是在 Main Loop 中調度的(參見圖 1.), 所以如果我們在某個任務中
使用了 delay (比如 HAL_Delay), 那麽勢必會造成系統假死。 因爲它會阻塞主循環, 導致調度器無法正常調度任務。

爲了解決這個問題, 我們只需要把任務調取權交給需要 delay 的函數, 並同時根據 systick 計算超時。
就像這樣。 當然它並沒有考慮到 systick 的溢出情況。

1
2
3
4
5
6
7

void scheduler_sleep(uint32_t milliseconds) {
  // loop until time exceeds
  uint32_t start = tick_get_time();
  while(tick_get_time() - start < milliseconds)
    scheduler_handler();
}

需要説明的是, 如果這個 delay 時間太長且超過了任務本身的時間, 則會發生嵌套調用。
即: 這個任務因爲剩餘時間小於 0, 在 scheduler_sleep 中被執行, 並再次進入 scheduler_sleep, 最終導致炸棧。
這個問題就需要額外處理了, 本文假設不會遇到這種情況。

一些儸嗦

關於不能保證任務實時性

因爲執行任務的時候必定會消耗一定的時間, 如果此時單片機處理速度較慢且任務間隔時間小,
則會造成任務堆積導致卡頓或者響應速度變慢。

所以在使用時應提高間隔時間, 盡可能降低調度壓力。

與 RTOS 的不同

實際上它跟 RTOS 的任務調度方式不是一種東西, 它的任務並非「綫程」。
因爲不需要進行上下文切換, 且任務之間不是並行的關係, 因此也不存在資源競爭。

C 語言中的實現

我已經根據這個思路實現了一個跨平台的任務調度器，支持 async/await，支持 tls存儲。請參考 TheSnowfield/frost。

寫到最後

如果有任何意見或者問題或是錯誤或遺漏, 請在下方評論區留言。謝謝 (๑•̀ㅂ•́)و✧

引用

• [1] STM32知识：什么是SYSTICK 作用是什么
  http://news.eeworld.com.cn/mcu/ic487932.html

所以最後考慮給它擴容, 成本也不是很高, 18 HKD 能買到一個已經足夠用的 EMCP。
話不多説, 現在開始 ヾ(@^▽^@)ノ

EMCP 選型

可以參考這個 EMCP 表格
我選擇的是 KMK8X000VM-B412 (BGA162 LPDDR2 1G + 16G EMMC) (差不多得了)
畢竟已經有人測試過它能用了, 爲了保守起見還是沒必要多踩一個坑。

下單購買, 然後就是等快遞了 XD
記得買植球鋼網! 記得買植球鋼網! 記得買植球鋼網!

備份分區表和全盤鏡像

這一步我只展示在 Windows 上操作的步驟, 如果你用 Linux / BSD 可能比較麻煩吧…

OpenStick WiKi 的第一步pip3 安裝 edl有錯誤, 實際 pip 安裝上去的並不是我們刷機要用到的那個 edl 工具 (而是它),
錯誤示範我就不貼了, 免得引起誤會。在這給出正確的地址 bkerler/edl。

另外在 Windows 上非常不建議跟隨 OpenStick WiKi 的擴容步驟, 教程需要的 edl 工具在 Windows 環境難以安裝(雖然它是 python),
但所依賴的庫在 Windows 下運行會抛出諸如 “Unsupported operation or platform” 此類的錯誤。

總之, 我們只需要使用 miko 就行了。

備份分區表

9008 老操作, 不用我多説了吧 XD。(怎麽還要讓我教, 按住 RESET 按鈕, 插上 USB)

打開 miko, 選擇 Read -> Backup Xml Firmware
點擊左下角 Load Partition Structure 讀取分區表。

等待右側出現 Reading GPT partition table ..... Done之後,
點擊 Save path, 選擇保存到的目錄。最後點擊 Read Full Firmware就行了。
稍候片刻, 會 dump 出來很多文件。請注意確認備份目錄是否存在 rawprogram0.xml 文件, 它非常重要

備份全盤鏡像

然後切換到右側 Partition Backup / Erase 選項卡

點擊左下角 Load Partition Structure 讀取分區表,
等待分區表出現之後, 點擊右下角的 Read Full Image 製作全盤鏡像, 之後你會得到一個 bin 文件, 請妥善保存。

備份完成, 接下來就可以開始更換晶片了 o(*≧▽≦)ツ

更換新的晶片

首先把板子搬上手術桌

不用取掉屏蔽罩, 直接用熱風槍 320 攝氏度加熱,
半分鐘之後輕鬆取下。USB: aahhhhhrua我死了 (倒下)

那個 USB 遇到高溫擺爛了 233, 我們先不要理它,
用吸錫帶清理乾净焊盤, 用洗板水洗乾净並保持整潔, 方便接下來焊接。

最後, 放上新買的晶片, 用熱風槍 350 攝氏度加熱, 可以多放一些焊油。
直到它浮起來, 輕輕推動它會被拉回去的狀態。千萬別手殘用鑷子去壓它, 要從側面輕推 (爲了拍照, 放的有點歪)
特別注意, 它在加熱之後有几率自己跑掉, 因爲 BGA 球太小還沒化, 焊油受熱流動性強, 拉不住
所以建議先預熱板子, 再放入。之後用鑷子輕輕扶著一下

最後記得在焊錫凝固之前, 把之前擺爛的 USB 扶起來。
用洗板水洗乾净, 焊接就完成了 ヾ(≧ ▽ ≦)ゝ

恢復之前備份的分區

在做這個操作之前, 請確認你是否焊好,
如果能進入 9008, 説明應該沒問題, 如果沒有, 可能你換上的是不兼容的或者沒焊接好。

爲了確認晶片是否正常讀寫, 可以打開 miko,
選擇 Emmc 選項卡, 點擊 EMMC READ / WRITE TEST 來測試。

刷寫分區

依次點擊 Flash -> Xml Flasher,
點擊 Raw program, 選擇你備份文件中的 rawprogram0.xml,
點擊列表左上角的 CheckBox (複選框) 全選所有分區, 確認中間 Patch 的内容為 patch0.xml,

然後就可以點擊 FLASH! 刷入了。

刷寫鏡像

依次點擊 Flash -> emmc block0 flasher,
雙擊 Double Click To Open EMMC DATA 編輯框, 選擇你的全盤鏡像備份。
刷入即可。

如果沒有什麽問題, 你將會看到板子上熟悉的紅燈開始閃爍,
稍等一會兒電腦會識別到新的 USB 設備。

調整分區大小

開機之後, 連接上 WiFi 登錄到設備,

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

$ lsblk
NAME         MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
mmcblk0      179:0    0  14.6G  0 disk
|-mmcblk0p1  179:1    0     2K  0 part
|-mmcblk0p2  179:2    0   512K  0 part
|-mmcblk0p3  179:3    0   512K  0 part
|-mmcblk0p4  179:4    0     1M  0 part
|-mmcblk0p5  179:5    0   512K  0 part
|-mmcblk0p6  179:6    0    16K  0 part
|-mmcblk0p7  179:7    0     2M  0 part
|-mmcblk0p8  179:8    0     2M  0 part
|-mmcblk0p9  179:9    0     1K  0 part
|-mmcblk0p10 179:10   0     2M  0 part
|-mmcblk0p11 179:11   0     1M  0 part
|-mmcblk0p12 179:12   0    64M  0 part
|-mmcblk0p13 179:13   0     1M  0 part
`-mmcblk0p14 179:14   0   3.3G  0 part /
mmcblk0boot0 179:32   0     4M  1 disk
mmcblk0boot1 179:64   0     4M  1 disk
zram0        253:0    0 442.2M  0 disk [SWAP]

可以看到, 我們的新 EMCP 已經被識別, 更新到了 16G,
但是 mmcblk0p14 分區還是 3.3G, 所以我們接下來需要用到 parted 擴展一下分區。

進入 parted, 提示 GPT 備份表損壞, 敲入 OK。

1
2
3

(parted) print
Error: The backup GPT table is corrupt, but the primary appears OK, so that will be used.
OK/Cancel? OK

然後它會提示我們的空間沒有完全使用, 可能存在錯誤。
敲入 Fix 修復。

1
2
3

Warning: Not all of the space available to /dev/mmcblk0 appears to be used, you can fix the GPT to use all of the space (an
extra 22966272 blocks) or continue with the current setting?
Fix/Ignore? Fix

繼續, 敲入 resizepart, 調整分區。
選擇需要調整的分區, 選擇 rootfs 所在的分區號 (應該是 mmcblk0p14, 是第 14)
然後提示分區正在使用, 確認, 敲入 Yes, 最後敲入 100% 將分區調整至最大。

1
2
3
4
5

(parted) resizepart
Partition number? 14
Warning: Partition /dev/mmcblk0p14 is being used. Are you sure you want to continue?
Yes/No? Yes
End?  [3876MB]? 100%

檢查無問題, 敲入 quit 退出 parted。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

(parted) print
Model: MMC K8XVMB (sd/mmc)
Disk /dev/mmcblk0: 15.6GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:

Number  Start   End     Size    File system  Name      Flags
 1      67.1MB  67.1MB  2048B                cdt
 2      134MB   135MB   524kB                sbl1
 3      135MB   135MB   524kB                rpm
 4      135MB   136MB   1049kB               tz
 5      136MB   137MB   524kB                hyp
 6      137MB   137MB   16.4kB               sec
 7      137MB   139MB   2097kB               modemst1
 8      139MB   141MB   2097kB               modemst2
 9      141MB   141MB   1024B                fsc
10      201MB   203MB   2097kB               fsg
11      268MB   269MB   1049kB               aboot
12      269MB   337MB   67.1MB               boot
13      337MB   338MB   1049kB               devinfo
14      338MB   15.6GB  15.3GB  ext4         rootfs

最後調整文件分區大小

1
2
3
4
5

$ sudo resize2fs /dev/mmcblk0p14
resize2fs 1.46.2 (28-Feb-2021)
Filesystem at /dev/mmcblk0p14 is mounted on /; on-line resizing required
old_desc_blocks = 1, new_desc_blocks = 2
The filesystem on /dev/mmcblk0p14 is now 3734523 (4k) blocks long.

檢查

1
2
3
4
5
6
7
8

$ df -h
Filesystem       Size  Used Avail Use% Mounted on
udev             423M     0  423M   0% /dev
tmpfs             89M  1.2M   88M   2% /run
/dev/mmcblk0p14   14G  779M   13G   6% /
tmpfs            443M     0  443M   0% /dev/shm
tmpfs            5.0M     0  5.0M   0% /run/lock
tmpfs             89M     0   89M   0% /run/user/1001

可以看到, 我們的 RAM 也增加到 1G。

至此, EMCP 擴容成功,
非常感謝你能看到這兒, 米娜桑辛苦惹喵 ヾ(*≧∪≦)

所以我的目光來到了上次被我拆掉的那個 先機隨身4G上網卡
因爲我給它刷了 Debian, 所以可以做大部分普通派能做的事情, 乃至我現在腦洞大開想把它搞成 Voron 的控制端主機

第一個坑 - Type C 不輸出 5V

不得不説, 這個地方的問題我排查一個多小時

Monster 8 控制主機板的 Type-C 後邊有一個 USB-PWR 的跳綫

一開始以爲它是會輸出 5V 電的, 因爲我把跳綫撥到 ON 之後確實會輸出 5V 電壓,
但是隨便插了一個設備上去之後, 設備完全沒有反應, 像是完全沒上電的樣子
然後用萬用表一量, 好家夥插上設備之後只有 1V 了

遂開始找原理圖, 發現這個跳綫前端連著 VBUS, 但是貌似僅用作輸入
但是正好旁邊有一個 USB-A 母口, 它也有一個跳綫, 那我就不客氣地把電借過來用了, 一根飛綫!

因爲 USB-PWR 跳綫的左邊空接, 所以正好借過來的電也不會倒灌,
而是直接流向 Type-C 輸出 這簡直太合適了 (不

第二個坑 - USB 工作模式

這個問題處理起來比較簡單, 因爲直接就有現成的答案
因爲 OpenStick 的 Debian 固件默認啓動時會將 USB 配置爲從模式, 所以無法直接和 Monster 8 通訊

所以在參考 切換 USB 工作模式 之後,
使用以下指令就可以達到想要的效果了.

1

$ echo host > /sys/kernel/debug/usb/ci_hdrc.0/role

可以看到, 出現了一個 STMicroelectronics Virtual COM Port 的設備, 它就是 Voron 控制板啦 φ(゜▽゜*)♪

因爲 OpenStick 沒有 USB-ID 脚, 只能這樣手動切換 USB 模式來插入外部設備,
或者以後可以把這句指令寫入到啓動脚本或者 SystemCtl 服務來實現開機自動切換, 執行完指令之後所有從設備功能將失效

第三個坑 - 安裝 Klipper 需要過多空間

這個坑是我沒想到的, 竟然是因爲安裝 Klipper 的時候依賴了整個源代碼編譯環境,
不僅有 arm-gcc / python 2 和 3, 甚至還有完全用不到的 avr-gcc. 這可是 STM32 呀..

整個安裝過程需要至少 3GB 的空間, 當時我就傻眼了, 怎麽會事呢 (?
OpenStick 一般是被嚴重閹割過, 只有 4GB 的eNAND. 而且裝完系統之後還會少一些——

所以不出意外, 全給我吃光了

所以現在如果還想繼續用 OpenStick 做主機, 那幾乎就只有一條路了,
考慮換 EMCP 擴容. EMCP 我選擇的比較穩妥且經過測試的 KMK8X000VM-B412, 配置為 16G(eNAND) + 1G(RAM)
應該也許可能大概差不多夠用了 XD, 換新的 EMCP 成本為 18 HKD 左右, 還是承受得起的, 別忘了買植球鋼網

話説貌似.. 用網路把分區映射到 NAS 好像也是一個不錯的選擇…

08/25/2022 更新
擴容教程已經施工完畢 ╰(*°▽°*)╯
如果你想給你自己的 OpenStick 擴容, 可以參考 EMCP 擴容

第四個坑 - 依賴包炸裂

因爲 Moonraker 依賴的 libglib2.0-bin 會依賴比較舊的包,
而 OpenStick 預裝的比較新, 會引發一些依賴炸裂的問題, 導致裝不上。

千萬不要去嘗試卸載 libglib2.0-0(=2.68.1-2mobian1), 這樣會導致連帶差不多整個系統都給揚了。

所以我們只需要把 libglib2.0-0 降到 (=2.66.8-1)
然後等待降級完畢就行。具體可以參考 libglib2.0-0:amd64 install / remove broke whole ubuntu

1

$ sudo apt install -f libglib2.0-0=2.66.8-1

第五個坑 - Locale 不對勁

因爲 OpenStick 所使用的 debian 可能被精簡過, 在給 Monster 8 編譯固件之前需要 make menuconfig,
然後 python 會打印一行錯誤

1

warning: setlocale: LC_ALL: cannot change locale (en_US)

所以我們要自己重新配置一下 locale,
選擇 en_US.UTF-8, 等待自動安裝完畢即可

1
2

$ sudo apt install locales
$ sudo dpkg-reconfigure locales

第六個坑 - USB Modem (CDC ACM) 支援

這個坑目前來說可以説是最大的了, 解決這問題需要重新編譯内核。
因爲 OpenStick 的内核默認沒有啓用 USB Modem (CDC ACM) 功能, 所以在插入串口設備的時候沒有 /dev/ttyACM0,
會導致一系列問題, 比如 kiauh 等脚本無法識別設備進而導致上載固件失敗, klipper 沒辦法與 Monster 8 通訊。等等

編譯和準備工作

所以我們需要準備一個 Debian 9 / Debian 10 的系統 (Ubuntu 也行),
先把 OpenStick 的内核克隆下來。

1
2

$ git clone https://github.com/OpenStick/linux --depth 1
$ cd linux

然後配置内核編譯選項

1
2
3
4
5
6
7
8
9

# 安裝 gcc9
$ sudo apt install gcc-9-aarch64-linux-gnu

# 使用交叉編譯
$ export ARCH=arm64
$ export CROSS_COMPILE=aarch64-linux-gnu-

# 構建 menuconfig
$ make menuconfig

選擇右下角的 Load,
輸入 arch/arm64/configs/msm8916_defconfig, 載入預設 Ok 確認。

然後依次選擇

• Device Drivers
• USB support
• USB Modem (CDC ACM) support

按下 y 啓用功能 (標記變成 <*>), 然後按下若干次 esc 退出并保存到 .config。

最後開始編譯, 應該不會有問題發生。

1

$ make -j24

合成 boot.img

跳轉到 arch/arm64/boot 下, 確認存在編譯生成後的 Image.gz 檔案。

敲入以下命令, 將設備樹 dtb 檔案附加在内核尾部,
這兒我使用我的設備型號 ufi001c 的設備樹, 請根據實際情況自行調整。

1

$ cat Image.gz dts/qcom/msm8916-handsome-openstick-ufi001c.dtb > kernel-dtb

解包 OpenStick 官方發行的 debian 的 boot.img 並提取出 initrd.img。
我這就偷懶用 ApkDB 工具來解包了, Windows 上比較方便 XD

這個 ramdisk.gz 就是 initrd.img 了

進入到 OpenStick 終端, 使用 lsblk -f 指令找到 rootfs 所在分區的 UUID 並記下。

重命名為 initrd.img 丟到 debian 去, 使用 mkbootimg 合成 boot.img 檔案
需要注意的是在以下命令中 –cmdline 參數中的 root=UUID=xxxx, 需要將 xxxx 換成你自己的 rootfs 分區的 UUID。

1
2
3
4
5
6
7
8
9
10

$ mkbootimg                   \
  --base 0x80000000           \
  --kernel_offset 0x00080000  \
  --ramdisk_offset 0x02000000 \
  --tags_offset 0x01e00000    \
  --pagesize 2048             \
  --second_offset 0x00f00000  \
  --ramdisk initrd.img        \
  --cmdline "console=ttyMSM0,115200 root=UUID=xxxx rootwait rootfstype=ext4 consoleblank=0 loglevel=1 cgroup_enable=memory swapaccount=1 rw" \
  --kernel kernel-dtb -o boot.img

最後, 就能得到帶有 USB Modem (CDC ACM) 功能的内核了,
使用 fastboot flash boot boot.img 刷新分區, 重啓即可。

Klipper 識別到設備, 開始正常工作

未完待續

BOM 生成向導

連接在這 -> Voron Design
然後點擊首頁左邊的 Configurator 打開生成向導
依次選擇

• Direct Feed (近程擠出機)
• New build. Give me the full BOM. (創建新的實例)
• Blind Joints (框架接頭)
• IGUS cable chains (使用坦克鏈)
• 350mm Spec (構建大小, 這個自由發揮, 我選擇 350mm*350mm)

然後就會出來一個材料 BOM 單, 下載表格文件然後我們開始 (｡･∀･)ﾉﾞ

完整清單

請按清單(根據上邊的步驟生成好的清單), 依次購買齊所有配件
最右側的 CheckBox 可以幫助你記錄已經完成采購的項目 (打算使用 cookie 永久保存你的清單記錄, 不過現在還沒寫)

此清單大部分翻譯及踩坑由 47姐 提供, 感謝! (*≧︶≦))

終於列完了, 太多了…
這些東西買完差不多要 2k HKD 左右, 懶得自己配就買成品吧, 不過那就要6k了…

1
2
3
4
5
6

[2022-08-16 12:07:21.006]
RX：
[2022-08-16 12:07:25.566]
RX：
[2022-08-16 12:07:29.173]
RX：埥窖_K暸乧leared.

量過, 這個時候 I2C 總綫的 SCL 和 SDA 實際上是處於高電平, 也就是空閑狀態。
但 SR2->BUSY 位是 1, 有點靈異。

我也去網上搜羅過很多關於 STM32 I2C 問題的解決方案, 似乎有很多人遇到過。但各種 reset 代碼都加上了, 它們都不太適用我的情況。

事出有因

文章寫到這裡, 已經是第二天了。
我突然開始好奇, 這個問題竟然會如此穩定的復現, 肯定是有哪寫炸了什麽的。

於是就打開 keil 開始單步代碼, 同時打開邏輯分析儀查看波形。
結果真就給我找到了些許端倪 (

這個地方是我正在用 axp173 給 I2C 縂綫上從設備配電。
從設備在上電的時候也會初始化 I2C, 然後把 SCL 綫短暫地拉低了 36us。

再次點擊單步之後我就發現 SR2->BUSY 就被置了 1, STM32 隨即開始智障,
什麽數據都發不出去了, 因爲它覺得自己很忙, 各種返回 HAL_BUSY。

問題也好解決, 只要先給設備上電再初始化 I2C 就行了,
或者在初始化之後重載一下 I2C。對於我種比較懶的人, 肯定選是後者了 XD

對症下藥

然後就順手給它加上了這一句代碼,
本意是清除掉 BUSY 位, 讓它能夠回到正常工作的狀態。

結果重新一跑, 發現這寄存器是 RO (Read Only) 的, 沒辦法手動清掉。(駡駡咧咧
不得已, 換個辦法。

我就原地重新初始化一下, 應該沒問題吧
不過看起來是修好了 XD

這幾天閑得無事, 瞄了一眼去年就裝電腦上的 FL-Studio。
忽然又想起了一些心事。

回想起日常, 雖然自己對絕大多數音樂的類型非常包容, 也會懂得去欣賞,
但實際上在 FL 做起來是一點思緒都沒有。

不是卡在旋律, 而是感覺自己沒有勇氣去表達自己的旋律, 雖然這個時候都是自己戴著耳機, 也只有自己一個人有聼。
反而我覺得我對旋律比較擅長, 高興的時候時而會哼出來一些調調, 也有過想它們存起來的想法 (這是我想學 EDM 的原因之一)

問題主要出在我現在還完全不熟悉利用各種混音器插件搭配使用去做出來我想要的音色。
這對我來説太難了, 看著一整個窗口上密密麻麻的綫和旋鈕… 感覺寸步難行。
教程大抵是不管用的, 它只能教會你一些常用手段去做 SFX / 自動化參數控制 / 捏波形 等等,
但是對於自己想要的音色, 腦子裡確實能想出來它聽起來是什麽樣子的,
但它波形應該是什麽樣子, 怎麽去調出來, 這對我來説比單純的寫代碼, 向 cpu 表達自己想做什麽, 更加抽象。

昨天一口氣下了 100GB 的各種采樣包, 確實也有聽到了自己非常熟悉的 SFX,
並且非常希望把它們用在自己的曲子内。

報名學習的群沒了

順帶昨天還發生了一些事情。
在去年自己有報名一個電子音樂新手班, 在暑假開課。
我從中確實也學到很多。

昨天是這個班的最後一堂課, 同時也是宣佈大家畢業。
老師讓大家提交自己的作品參加評比, 但我對因爲這方面確實沒什麽經驗所以就沒有提交,
然後發現, 大家都沒交。

所以在昨天上課之前, 老師好像生氣了, 只抛下幾句非常涼心的話, 隨即解散了群,
大家就這麽不歡而散…
當時我看上課時間到了, 就去找群。但是並沒有找到, 直到我去翻了簡訊盒子才知道群被解散了…

我是非常敬仰他的, 作爲我的第一個 EDM 作曲老師, 他無私地向我們傳授作曲思路, 各種 tricks 和合成器的使用,
但現在也就只能是深感遺憾, 學生不才, 我沒能達到您的要求。

説到這裡, 心情逐漸變得沉重,
眼淚就控制不住地流下來了。

最近的一些打算

打算花一些時間來學習 EDM, 雖然變成了完全的自學, 但我相信我自學的能力不差。
另外就是朋友那邊的事情, 我決定做完了之後就推掉了。

年底之前, 先去一趟日本。

前天在群裡看到大佬們在討論一個 WiFi 上網卡, 據説是采用的高通 Snapdragon 410 的方案,
然後價格還特別香只要 19.9。

然後當我看到這則訊息的時候, 已經是一個周之後了, 價格已經被炒到了 38 元左右
領券購買也要 32 元(這實在是太虧了)。不過還是抱著試一試的心態, 買了一個。

馬上拆解

外觀看起來不錯, 整體構造十分簡潔, 並且還有散熱設計。

拆下 USB 頭部的兩顆螺絲,

然後用指甲劃開卡扣, 就能看到内部構造了。

電源管理方案是高通的 PM8916

處理器型號是 MSM8916, 果然是 410。

旁邊還有一顆 Skhynix 的 H9TP32A4GDBCPA-KGM,
是一顆集成了 4GB eNAND 和 4Gbit LPDDR2 的存儲器。

它的整體差不多就是這樣, 配置小總結:

• CPU Snapdragon 410
• RAM LPDDR2 4Gbit (512MB)
• NAND eNAND 4GB
• 全網通 (移動 / 聯通 / 電信)

一些疑惑

看了看説明書, 這個東西開機竟然有要 30 秒,
這麽長的時間, 冥冥之中感覺… 它上邊這是不是跑了一個安卓系統 (

那麽問題來了, 既然它性能看起來這麽不錯, 能不能拿來跑 bot 玩

最近在倒騰 USBKEY, 但在調試 CH1115 的時候發現, 一旦發送開屏指令,
在熒幕 IC 処會出現大約 90 攝氏度左右的發熱點。不是很清楚怎麽回事。

頂著這麽高的溫度竟然還 debug 了好幾個小時, 十分慶幸沒有把我房間燒起來 (不)
來看一看熱成像

溫度非常恐怖, 順帶著穩壓也開始微微發燙了。
但是看這溫度最少也是有午安大電牛的吧(5A大電流), 但是它只有 132ma 的電流, 有點意外。
同時也幾乎可以肯定不是短路造成的問題。

在發現這個問題之前, 我還在疑惑熒幕爲什麽亮了但是沒有完全亮,
當時是滿山遍野地在翻閲手冊找「亮度」 和 「對比度」相關的資料, 一心想在睡覺前調好, 完全沒有發覺溫度有異常。

現在一想, 看起來事情確實有點蹊蹺。

原理圖

儘管到目前爲止這種情況發生的原因尚不明確, 不過先把原理圖po出來吧。

這是公版的是用内置電荷泵的原理圖

大體上的改動是刪除了沒什麽用的 MOS 管, 考慮到設備采用 USB 供電,
只要漏電流不嚴重, 那還是能夠接受的。

其次就是 VBAT_in 処, 由於設備沒有電池, 故將其直接引到 VMCU, 也就是 3.3v。
(應該也沒什麽問題吧)

不過我總覺得事情沒這麽簡單。

接錯綫了

人剛剛起床。在跟賣家一番激情對綫之後, 才發現原來是綫接錯了。

需要注意的是, 熒幕的 VDD 是邏輯電壓, 一般和晶片電壓一致為 3.3v,
但它的 VCC 可不是 3.3v, 而會到是8v左右, 或更高。

因爲根據手冊, 在使用外置電荷泵時, 第 14 脚, 也就是 VCC 需要接入 8v 的電源, 這個脚是通往内部電荷泵輸出的。
注意看圖片底部注釋的 VCC_in。

所以想必, 在使用内部電荷泵的時候, 這個脚應該會至少輸出 8v 左右的電壓, 並且要串濾波電容接地。

然而, 我把它… 拉到了 3.3v。

滿身瘡痍, 哭死.wav
翻車, 絕對の大翻車。這就折騰修東西去了, 嗚嗚

成功點亮

好耶, 修好了。只需要把 VCC 懸空就可以了。
亮度問題也順帶解決。 (熒幕上的白點點可以無視掉, 那只是因爲沒有刷屏直接點亮的緣故。

説到白嫖, 那那那那那那我可就精神了啊 XD。
在給 LTC佬 安利了 AXP173 PMIC 的半個月之後, 他在私訊找到我說他板子翻車了。

えええ—– ? 怎麽回事。
我都用的好好的東西, 爲什麽到了你的手上就翻?
什麽?! 你第一版板子就跑去做 SMT ?

那請務必寄給我一個, 好讓我(白嫖一下)康康怎麽回事 。

經過兩天的焦灼等待, 板子終於到了

整體來講, 板子看起來美觀, 還是很不錯的。畢竟我 LTC 佬是什麽人呐, 對不對 XD
先給 8 分, 扣 2 分是因爲怕他飄了。開搞開搞! XD

裂開

貼好缺少的 AXP173之後, 上電發現 DCDC1 電感的輸出會突然衝到 4v 然後掉電。
以一般理性而言, 很明顯 Buck 衝飛了, 目測反饋電路有問題, 就找他要到了原理圖看。

然後人就裂開了

啊…這?
雖然不説畫的怎麽樣, 至少我看到的時候是 ? 的。

問題一 反饋電路沒有電氣連接

在仔細對照公版原理圖之後, 在47姐的提醒下 (47nb!) 找到了端倪

而在 PCB 上, 絕絕子
這麽不仔細, Buck 是肯定要完蛋的, 衝飛了不怕把後端負載炸了嘛。 (高壓の入侵)

飛綫之後, 爲了驗證電路是否還有問題, 於是斷開了後端負載的命脈。
這邊還是建議鋪銅走綫, DCDC1 後邊這麽多設備, 然而只拉了這麽一根細綫, 不是很合理。

修復完成, AXP173 空載輸出恢復至 3.6v
當然別忘了量完記得把命脈接回去x

問題二 ACIN 和 VBUS 混淆使用

對於 AXP173 有三個輸入方式, 分別是 ACIN, VBUS, VBAT.
先抛開 VBAT 不談, 先來説一説 ACIN 和 VBUS。

ACIN 指交流電來源, 是從 5v 電源適配器的輸出來的, 一般可以輸出 1A / 2A 或者更多。
VBUS 則指 PC 的 USB 總綫電源, 在 USB2.0的標準下, 最大輸出能力只有 500mA, 而 USB3.0 最大 900mA。

雖然對於 AXP173 來説二者都是可以作爲「充電」的電源來源,
但一般情況下只考慮充電的話, 還是推薦使用 ACIN, 可以避免許多麻煩。

然而眼前的板子, 它很奇怪。

可以明顯的看到, ACIN 接入了 VBUS。
但是 VBUS 接了一個 VBUS2, 這是什麽草玩意?

一番搜尋, 發現這個 VBUS2 除了接了一個 TP5 之後就什麽都沒接, 它是空的 (?

并且因爲他在原理圖上把 N_VBUSEN 拉到了 GND, 導致 AXP173 在使用 ACIN 初始化完畢之後,
自動切換到 VBUS, 但這個 VBUS 是假的什麽都沒接… 於是它自鯊了。

解決方法自然也很簡單, 只需要把 ACIN 和 VBUS 短接
這樣他們就合體了, 無視 N_VBUSEN。 (這裡用了比較高端的手法, 直接在封裝上短接)

問題三 電容接在了奇怪的地方

最後一個問題… 也是找了很久很久才發現。

這個就不多説了, 大概就是抄錯了。

解決方法, 把電容和電阻斷開, 並飛綫到 GND。

修到最後

至此, AXP173 的電路已經完成修復。
板子也成功上電, 好在他的後端電路沒有什麽問題, 不然又是一頓好找了。

連接到電腦, 出現了 RP2040 的 VFS 模擬分區。

由此可見, 白嫖還是需要付出一點代價的 (大霧)

破解僅作爲學習交流使用, 不用作任何商業目的。
以下所有描述和截圖均經過脫敏處理。

從朋友那收來了一批好玩的 IC (不方便透露 XD), 但是發現用它需要許可證, 好像還要簽保密協議之類的。
因爲自己是散戶人家肯定也不願意跟我簽的x, 所以沒辦法只能另尋他路了。

這個東西還比較小衆, 玩的人不多, 所以幾乎也沒辦法搜到太多資料。
於是抱著試一試的心態打開了 IDA, 想看看能不能找出來什麽東西。

大吃一斤

什麽? 我這麽菜的也能撿到漏? 不會吧不會吧不會吧?

來看一下它的啓動邏輯

邏輯很簡單。
啓動時會檢查一下授權, 如果授權不存在或者失效則彈出錯誤框, 並啓動一個授權配置程式並退出自己。
如果授權有效, 則加載主窗口。

不是… 就這?
在我對於破解的經驗中, 不應該是會讓我原地放棄的, 鋪天蓋地的混淆亂碼和一堆「Invalid Instructions」嗎?
怎麽今天讓我撿到漏了 (

順水推舟

既然它校驗的方法這麽簡單, 那乾脆直接爆破, 改掉 check_license 函數的返回值就可以了,
比如在這個函數頂部清棧並 ret 0 就可以實現。

但萬萬沒想到的是, 它竟然在很多地方(指各種負責次要功能的 exe) 都加了這種校驗。
那就非常棘手了, 不可能所有文件我都去打補丁嘛, 而且找起來也是非常麻煩。

而且順帶, 我發現它竟在 exe 内嵌入了一個 RSA Public Key。

並且驗證邏輯都是依賴於 OpenSSL 去算 RSA 簽名的。
那麽, 能不能把他的 Public 換成我們自己生成的呢? (好像是一個更優雅的辦法)

於是, 就手動生成了一個1024 位的 RSA Keypair, 再用 HXD 找到它原來 Public 的位置, 替換掉。
最後按照他驗證的方法去逆著生成一個假 License 喂給 IDE。
然後它真的能用。

於是乎, 矛頭就指向了無辜的 「OpenSSL」。 (怎麽又是你, 太慘了)

破解思路

反匯編上邊那個 load_key 函數,

畢竟破解要盡可能以保證原有功能正常為前提,
所以我的目光來到了 BIO_new_mem_buf 這個函數上。

使用它作爲破解點有幾個好處

• 可以插入判斷 Public 的代碼, 防止破壞了原有的功能
• 由於是動態庫上的公開 API 函數, 方便快速定位
• 工作量小, 多個程式都會使用此 API 來加載 Public, 一処破解全部破解

經過簡單修補之後, 換上了我們自己的 Public, 最終它變成了這樣

大概是先判斷一下調用方傳過來的 Public 是不是我們想要的,
如果是則直接換成我們自己的, 並調用原來的 BIO_new_mem_buf, 否則不干涉原始執行流程。

典型的 MITM 攻擊 (Man In The Middle)。

試一試

換上之前生成好的假 License,

至此, 手動破解結束。

個人覺得 OpenSCAD 入門還算很快的, 語法非常接近 C 語言。

相比常用的工業建模軟體 SolidWorks 而言,
它可以用程式碼去描述工件外觀和大小。具有參數化和可移植性的特點。 非常適合改來改去

話不多説, 立刻開始。

圓角正方體的平面構成

我們這裡説的不是通常意義上的 八個邊圓角 的那種, 一個立方體有8個邊嘛
而是 四個邊圓角 的類型, 即 與底面垂直的四個邊 是圓角。

而我們在矢量圖形中一般是使用 圓形 和 矩形 取並集去拼合圓角矩形。

當然你也可以直接透過繪製四個 1/4 Arc 來達到目的。

那麽在 OpenSCAD 中我們也有差不多的東西,
我們可以使用 hull() 來取得對象集合在空間上的極限邊距, 同時抛棄對象集合内部所有的頂點。
擺爛了, 隨便把樣子搞出來, 然後丟掉

嘗試畫一個

理解這些理論知識之後, 我們可以開始試著畫一個了

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

// for high definition curves
// so set factor to 0.1
$fs = 0.1;

translate ([0, 0, 0]) {
  // get bounding box
  hull() {
    // translate object to [0, 0, 0]
    // draw a cylinder with height 5, radius 0.5
    translate([0, 0, 0]) cylinder(5, 0.5, 0.5);
    translate([5, 0, 0]) cylinder(5, 0.5, 0.5);
    translate([0, 5, 0]) cylinder(5, 0.5, 0.5);
    translate([5, 5, 0]) cylinder(5, 0.5, 0.5);
  }
}

然後我們就能得到一個

然後可以包裝一下成爲一個模塊

1
2
3
4
5
6
7
8
9
10
11
12
13
14

module squircle (size = [1, 1, 1], r = 0.5, center = false) {
  $fs = 0.1;
  x = size[0] - r * 2;
  y = size[1] - r * 2;
  z = size[2];
  
  translate(center ? [-(x / 2), -(y / 2), 0] : [r, r, 0])
  hull() {
    translate([0, 0, 0]) cylinder(z, r = r);
    translate([x, 0, 0]) cylinder(z, r = r);
    translate([0, y, 0]) cylinder(z, r = r);
    translate([x, y, 0]) cylinder(z, r = r);
  }
}

僅僅幾行代碼就能生成一個圓角正方體,
以後只需要簡單地修改參數, 我們就能得到不同尺寸的圓角正方體了。
這可比 SolidWorks 改草稿的效率要高很多。

LiteVNA (Vector Network Analyzer) 是一個開源的矢量網路分析儀,
可以用來分析天綫性能 / 阻容抗匹配 / 史密斯圖 / 天綫增益 等。
因爲最近畫板子需要調試射頻, 所以就趁著價格香就買了。

它長得十分輕便小巧, 顯然沒有那些實驗室内的專業設備強, 但也夠用。

隨包裝附贈了一些配件,
有兩根饋綫, 三個測試頭, 一個連接器和一根 TypeC 綫。

不過這個中文説明書對我來説沒什麽用x 反正英文又不是不能看

需要特別説明的是, 中間三個金屬帽一樣的東西是用來校準設備用的,
我們下一章節中會講到如何校準設備。

校準設備

網分必須校準之後才能開始使用, 所以我們需要三個金屬帽

它們從左到右分別叫短路頭 / 開路頭 / 負載頭。
其中負載頭一般為 50Ω。

我們首先進入 CALIBRATE -> CALIBRATE 頁面,
能看到有 OPEN / SHORT / LOAD / ISOLN / THRU 這四個選項。

以下列步驟依次進行校準

• 把開路頭接到 PORT1, 點擊一下 OPEN, 等待校準完畢
• 把短路頭接到 PORT1, 點擊一下 SHORT, 等待校準完畢
• 把負載頭接到 PORT1, 點擊一下 LOAD, 等待校準完畢
• 把負載頭接到 PORT2, 開路頭接到 PORT1, 點擊一下 ISOLN, 等待校準完畢
• 用饋綫連接 PORT1 和 PORT2, 點擊一下 THRU, 等待校準完畢

當完成以上步驟之後, 別忘了點擊 DONE 保存校準數據。
當圖表左邊出現一些小字母的時候, 就説明校準完成了。

不過開始測試天綫之前, 我們需要回到主界面驗證一下。
依次接上開路頭, 短路頭, 負載頭, 饋綫, 觀察史密斯圖 就是那個綠色的玩意,

有一個小口訣:

短路在左邊, 負載在中間, 開路在右邊

用它進行對比驗證。

測試天綫和鑒別

最後我們來實測一下天綫~

先測一個 2.4Ghz 小辣椒天綫, 可以看到它的表現力也就凑合。

再來測一根, 經驗可得出它是一個 433Mhz 的天綫。

小插曲

最後突然想起我去年打 NOAA 的時候手作的一根天綫。

趕緊拿出來測了一測, 發現

哇什麽玩意, 簡直爛到不行。
立刻下樓, 把天綫扔進了垃圾桶。 怪不得總是失敗