圓形LCD液晶屏幕像素坐標如何劃分的？

1、為什么“圓形LCD像素坐標”會成為問題？

圓形LCD在消費類產品里看起來只是“外形不同”，但在工業(yè)HMI、儀表盤、醫(yī)療設備等場景里，它往往承擔刻度、指針、報警區(qū)域、觸控熱區(qū)等強語義信息。一旦坐標體系理解錯誤，常見后果不是“圖形歪一點”，而是更隱蔽、更難定位的系統(tǒng)性問題：

1·圓心不居中：同心圓/表盤刻度出現偏心，視覺上“像裝配歪了”，但根因可能是 X_OFFSET/Y_OFFSET 或掃描方向配置。
2·缺邊/裁切：圓周一側被切掉一條，通常是地址窗口（Address Window）邊界與有效區(qū)不匹配。
3·觸控與顯示不一致：顯示圓心正確但觸控熱區(qū)偏移，導致誤觸；在安全相關界面里尤其不可接受。
4·量產漂移：同一套軟件在不同批次模組上出現邊緣黑圈厚度不均，常與貼合公差、遮罩位置、驅動IC映射有關。

在安全相關系統(tǒng)中，界面與交互的“可預期性”會被納入更嚴格的工程約束。以功能安全通用標準 IEC 61508 的風險導向方法論為例，核心思想是用風險評估確定安全功能需要達到的完整性水平，這類框架會把“誤顯示/誤操作”視作潛在風險鏈條的一環(huán)。

而在環(huán)境適應性上，MIL-STD-810 強調通過環(huán)境應力的裁剪與試驗方法來驗證設備在全壽命周期條件下的可靠性，實際工程中溫度、濕度、振動會放大貼合/結構偏差，使坐標偏移在極端條件下更容易暴露。

所以：圓形LCD的坐標問題，本質是“顯示尋址、遮罩有效區(qū)、裝配偏移、觸控對齊”多因素耦合后的系統(tǒng)工程問題。

2、核心規(guī)范：圓形LCD為什么仍用矩形 (x,y) 尋址？

絕大多數圓形LCD在控制器層面仍以矩形像素矩陣定義分辨率，典型如 240×240。以常見圓屏驅動IC GC9A01A 為例，其數據手冊就以 240×RGB(H) × 240(V) 的方式定義顯示分辨率與輸出通道。

之所以“看起來是圓的”，通常是因為圓外區(qū)域被黑矩陣/遮光油墨或結構件遮擋，而不是像素尋址變成了“極坐標像素”。

在命令與尋址層面，很多圓屏（SPI/QSPI、部分并口）采用與 MIPI 顯示體系兼容的命令風格：

1·0x2A：Column Address Set（列地址范圍）
2·0x2B：Page/Row Address Set（行地址范圍）
3·0x2C：Memory Write（寫入像素數據流）
4·0x36：Address Mode（掃描方向/鏡像/旋轉相關配置）

這些命令在工程文檔與實現中經常被稱為 DCS（Display Command Set）/DCS layer 的通用命令語義。

關鍵點：控制器的顯存（GRAM）是矩形的，主控寫入時也是按矩形窗口推進；“圓形”是在更上層通過遮罩/裁剪實現。

3、需要同時理解的“四層坐標”

圓形LCD工業(yè)液晶屏項目里，建議把坐標分成四層來看：物理像素坐標、GRAM坐標、UI邏輯坐標、觸控坐標。它們經常被混用，導致“畫不準/點不準/旋轉亂套”。

坐標層	典型形式	原點/方向（常見約定）	范圍示例（240×240）	主要用途	與像素的關系
物理像素坐標	(x, y)	左上(0,0)，x→右，y→下（可被旋轉配置改變）	x∈[0,239], y∈[0,239]	描述“你想顯示在哪個像素點”	最終落點
GRAM/尋址坐標	列/行窗口 + 寫入順序	由 Address Mode/掃描方向決定	由 0x2A/0x2B 設置窗口	高效刷屏、局部刷新	定義寫入映射
UI邏輯坐標	(r, θ) 或歸一化坐標	以圓心為基準（cx,cy）	r∈[0,R]	表盤/環(huán)形進度/扇形等	需投影到(x,y)
觸控坐標（如有）	(tx, ty)（可能是0..4095或0..W/H）	由觸控IC定義	依觸控IC而定	點擊/滑動輸入	需標定映射到(x,y)

其中“圓形有效區(qū)”的最常用工程判定是：設圓心 (cx,cy)、半徑 R，像素 (x,y) 滿足(x−cx)2+(y−cy)2≤R2，則在圓內可繪制，否則屬于圓外區(qū)域（可選擇不繪制或填充背景）。這一步就是把“矩形尋址”裁剪成“圓形可視效果”的關鍵。

4、核心技術深挖對比

4.1 “圓形LCD坐標”的底層真相：GRAM永遠是矩形地址空間

圓形LCD工控液晶模組（如常見 240×240）之所以仍能用 (x,y) 描述，是因為顯示控制器內部的 GRAM（顯示數據RAM）按“頁(Page)/列(Column)”組織，也就是典型的二維矩形地址空間。GC9A01 系列數據手冊明確描述：GRAM 中每個像素（18-bit）由 (Page, Column) 即 (Y, X) 地址定位，并可通過設置窗口（SC/EC、SP/EP）配合 RAMWR/RAMRD 從窗口起點進行連續(xù)訪問。

這意味著：

你寫入像素不是“寫一個圓”，而是在矩形顯存里寫一段連續(xù)數據流；

“圓形效果”來自上層對圓外區(qū)域的遮罩/裁剪，而不是像素尋址本身變成極坐標。

Adafruit 的圓形 1.28“ 模組介紹也直白點出：它看起來像”方屏把邊角削掉“，分辨率仍是 240×240，驅動 IC 為 GC9A01A，并且與 ST7789 的使用方式非常接近（SPI 寫入像素緩沖）。

4.2 Address Window 如何把“坐標”變成“像素流”

在 SPI/QSPI 圓屏里，最核心的編程模型是 Address Window（地址窗口）+ 連續(xù)像素寫入：

1·設定列地址范圍（x start / x end）

2·設定行地址范圍（y start / y end）

3·發(fā)送 Memory Write，后續(xù)數據按控制器內部計數器自動遞增寫入

這套語義在 MIPI DCS（Display Command Set）里是高度標準化的：

1·0x2A Column Address Set

2·0x2B Page Address Set

3·0x2C Memory Write

4·0x36 Address Mode / MADCTL（決定掃描方向、鏡像、交換XY等）

含義：你在 API 層看到的 drawPixel(x,y)，最終都會被“批量化”為 setWindow(x0,y0,x1,y1) + pushColor(stream)，否則 SPI 帶寬會被指令開銷吞掉。

4.3 旋轉/鏡像的本質：不是“坐標系變了”，是“計數器映射規(guī)則變了”

很多人畫圓不居中、畫圖像翻轉，第一反應是“坐標定義錯了”。更準確的說法是：MADCTL/Address Mode 改變了 GRAM 地址計數器到物理像素的映射。

以 ST7789 數據手冊為例：它描述了窗口（XS/YS/XE/YE）與寫入地址遞增方式，并指出 CASET/RASET/MADCTL 的 MX/MY/MV 組合允許鏡像與交換尋址方向；同時區(qū)分 horizontal/vertical addressing（MV=1 時 Y 地址先遞增等）。

GC9A01 的資料也給出了由 D5/D6/D7 控制的映射組合（例如“列指針映射到物理列/或映射到(239-物理列)”等），本質同樣是“尋址指針如何翻轉/交換”。

推薦在驅動層做一層“邏輯坐標→物理坐標”的顯式變換（而不是到處 if/else）：

設邏輯分辨率 W=240, H=240，邏輯坐標 (x,y)，偏移 (xo,yo)

以 0/90/180/270 四種 rotation 舉例（不含鏡像）：

rot=0: ? x‘ = x ? ? ? ? ? y’ = y

rot=90: ?x‘ = W-1-y ? ? ? y’ = x

rot=180: x‘ = W-1-x ? ? ? y’ = H-1-y

rot=270: x‘ = y ? ? ? ? ? y’ = H-1-x

再統(tǒng)一加上模組偏移：x_phy = x‘ + xo, y_phy = y’ + yo。

4.4 圓形裁剪：把“矩形尋址”變成“圓形有效區(qū)”

圓形 UI 的關鍵不是“地址怎么寫”，而是圓外區(qū)域怎么處理。最基礎判定：(x−cx)2+(y−cy)2≤R2

1·cx,cy 常取 (W-1)/2,(H-1)/2

2·R 不一定等于 W/2：很多模組圓外由黑矩陣/結構遮擋，實際可視半徑往往略小，留 1——3 像素黑邊反而更“干凈”。

但在 SPI 屏上，逐像素判定會吃 CPU；更要命的是：如果你對每個像素都 setWindow+寫1點，SPI 指令開銷會讓幀率崩盤。正確做法是：裁剪在算法層完成，寫入在窗口層批量完成。

4.5 深度對比：四種“圓形繪制/裁剪”策略怎么選

策略	核心思路	CPU開銷	RAM 開銷	SPI/總線效率	畫質可控性	適用場景	常見坑
逐點裁剪	每個像素算 dx²+dy²，圓內才畫	高	低	低（若逐點寫窗更糟）	中	UI 很簡單、刷新區(qū)域很小	算法對了但幀率很差
掃描線段	每行求圓與該行交點 xL/xR，一次寫一段連續(xù)像素	中	低	高	中-高	環(huán)形背景、表盤底圖、填充扇形	交點取整不當會出現邊緣毛刺
預計算	Mask/LUT預先存每行 xL/xR 或 bitmask，運行時不再算平方	低	中按實現	高	中-高	MCU 性能緊張但需要穩(wěn)定幀率	LUT 與實際圓心/偏移不一致會“越畫越歪”
分塊/Tile + DMA（架構級）	把屏劃分為 tile，局部 dirty-rect 刷新；配合 DMA 推送	低-中	中-高（tile buffer）	很高	高	動畫/指針頻繁更新、需要流暢	需要嚴格的窗口管理與臟區(qū)合并策略

BOM/架構代價的量化：240×240×16bit 的全幀緩存約 2402402=115,200 bytes（≈112.5 KiB）。很多 MCU（無 PSRAM）放不下完整 Framebuffer，因此實際工程更偏向 Tile/局部緩沖 + Scanline/LUT 的組合：用少量 RAM 換取可接受幀率與更低指令開銷。

4.6 “X_OFFSET/Y_OFFSET”為什么幾乎繞不開：模組裝配與有效區(qū)不完全對齊

你在項目里看到的“畫面整體偏一截、邊緣黑圈厚度不均”，很大概率不是圓算法問題，而是 模組的可視圓心 ≠ GRAM 的幾何中心。原因包括：玻璃裁切、FPC貼合定位、黑矩陣印刷偏差、結構件壓邊等。工程上通常用 X_OFFSET/Y_OFFSET 把邏輯坐標系平移到“真實可視中心”。

這類“偏移參數”在不少通用顯示驅動框架里是顯式字段（rotation code + x offset + y offset），說明它并非個例，而是顯示模組工程的常態(tài)。

校準方法（高命中率）

1·畫“十字 + 同心圓 + 0/90/180/270刻度點”測試圖

2·觀察四象限黑邊厚度是否一致：

2.1左厚右薄 → xo 方向需要修正

2.2上厚下薄 → yo 方向需要修正

3·每次修正以 1 像素為步進，先把“圓心”對齊，再談抗鋸齒與美觀。

順序建議：先做 rotation/mirror 的坐標變換，再疊加 offset（更容易把參數“直覺化”，也便于量產配置表管理）。

圓形LCD液晶屏之所以容易在項目里引發(fā)“畫不準、點不準、旋轉亂、量產飄”，核心原因不是“坐標體系很玄”，而是很多團隊把不同層級的概念混在一起：把 UI 的極坐標表達當作像素尋址，把遮罩導致的可視圓當作真實分辨率邊界，把裝配帶來的偏移當作算法錯誤。

從工程可控性來看，最穩(wěn)的認知框架是：

1.像素尋址永遠是矩形 (x,y)：控制器的 GRAM 以行/列地址組織，通過地址窗口（CASET/RASET）+ 連續(xù)寫入（RAMWR）完成刷新，這是圓屏與方屏共用的底層模型。

2.圓形只是“有效區(qū)/可視區(qū)”：圓外區(qū)域要么被黑矩陣/結構遮擋，要么需要軟件裁剪/填充來保持視覺一致。

3.旋轉/鏡像/偏移是“映射規(guī)則”：Address Mode 改變尋址指針與物理像素的映射；X_OFFSET/Y_OFFSET 用來修正模組實際圓心與幾何中心的不一致，屬于量產常態(tài)，不是“寫錯了”。

5.2 常見問題

1：圓形LCD為什么不是“極坐標像素”？極坐標有什么用？

LCD圓形液晶屏的像素在控制器層面仍是矩形 GRAM 地址空間，寫屏也是按列/行窗口推進。極坐標更多用于 UI 表達（刻度、指針、環(huán)形進度），最終仍要通過三角函數把 (r,θ) 投影到 (x,y)，再結合圓形裁剪。也就是說：極坐標是上層幾何語言，不是硬件地址語言。

2：圓心 cx,cy 和半徑 R 怎么定？為什么我用 (W-1)/2 還是不準？

常規(guī)初值確實是 cx=(W-1)/2, cy=(H-1)/2，但“可視圓心”往往會因為黑矩陣印刷、玻璃裁切、貼合定位、結構壓邊產生 1——數像素偏移，所以你需要用 X_OFFSET/Y_OFFSET 去校準。建議用“十字+同心圓”測試圖，把四象限黑邊調到盡量均勻，再固化參數。R 也建議預留 1——3 像素黑邊以兼容遮罩公差（看起來更圓、更干凈）。

3：為什么我用 dx²+dy²≤R² 畫出來圓邊很鋸齒，且?guī)屎艿停?/h3>

鋸齒來自像素柵格離散化；幀率低通常來自兩點：

- 逐像素計算與逐像素寫窗導致 CPU 與 SPI 命令開銷爆炸；
- 保護性裁剪寫法把“面”拆成很多小窗口。

工程上推薦掃描線段（每行一段 span）或預計算每行 xL/xR 的 LUT，再用一次窗口寫入連續(xù)像素流，既能顯著提幀率，也更容易做抗鋸齒（例如對邊緣做亞像素/多采樣或漸變過渡）。