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

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

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

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

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

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

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

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

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

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

在命令與尋址層面，很多圓屏（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工業液晶屏項目里，建議把坐標分成四層來看：物理像素坐標、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]	表盤/環形進度/扇形等	需投影到(x,y)
觸控坐標（如有）	(tx, ty)（可能是0..4095或0..W/H）	由觸控IC定義	依觸控IC而定	點擊/滑動輸入	需標定映射到(x,y)

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

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 從窗口起點進行連續訪問。

這意味著：

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

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

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

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

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

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

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

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

這套語義在 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 旋轉/鏡像的本質：不是“坐標系變了”，是“計數器映射規則變了”

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

以 ST7789 數據手冊為例：它描述了窗口（XS/YS/XE/YE）與寫入地址遞增方式，并指出 CASET/RASET/MADCTL 的 MX/MY/MV 組合允許鏡像與交換尋址方向；同時區分 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

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

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

圓形 UI 的關鍵不是“地址怎么寫”，而是圓外區域怎么處理。最基礎判定：(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 很簡單、刷新區域很小	算法對了但幀率很差
掃描線段	每行求圓與該行交點 xL/xR，一次寫一段連續像素	中	低	高	中-高	環形背景、表盤底圖、填充扇形	交點取整不當會出現邊緣毛刺
預計算	Mask/LUT預先存每行 xL/xR 或 bitmask，運行時不再算平方	低	中按實現	高	中-高	MCU 性能緊張但需要穩定幀率	LUT 與實際圓心/偏移不一致會“越畫越歪”
分塊/Tile + DMA（架構級）	把屏劃分為 tile，局部 dirty-rect 刷新；配合 DMA 推送	低-中	中-高（tile buffer）	很高	高	動畫/指針頻繁更新、需要流暢	需要嚴格的窗口管理與臟區合并策略

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

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

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

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

校準方法（高命中率）

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

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

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

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

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

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

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

從工程可控性來看，最穩的認知框架是：

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

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

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

5.2 常見問題

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

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

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

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

3：為什么我用 dx²+dy²≤R² 畫出來圓邊很鋸齒，且幀率很低？

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

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

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