Display 驅(qū)動概述
隨著電子產(chǎn)業(yè)迅速發(fā)展,帶屏類的設(shè)備種類日益增多,各種各樣的顯示屏也隨之出現(xiàn)。
最常見的顯示屏有 LCD(Liquid Crystal Display)屏、LED(OrganicLight-Emitting Diode)點陣屏、OLED(Organic Light-EmittingDiode)屏等,根據(jù)其各自特點,用于不同的顯示場景。顯示屏的硬件接口主要有 MIPI、HDMI、SPI、I2C、RGB、MCU 等,現(xiàn)在用于手機的高分辨率顯示屏,主要用的是 MIPI 接口,HDMI 接口主要用于顯示器或 TV,RGB 和 MCU 接口為并口,主要用于功能機之上。
以 LCD 為例,其驅(qū)動主要完成三部分工作:
1、對 LCD Driver IC 及模組相關(guān)的硬件資源進行初始化,包括配置 MIPI 參數(shù),操作 GPIO 管腳,設(shè)置上下電時序,下發(fā)屏端初始化參數(shù)序列等;
2、器件驅(qū)動操作接口對注冊或者對接到標(biāo)準(zhǔn)的顯示框架上,例如 DRM 架構(gòu)或者 FB 顯示架構(gòu),保證在設(shè)備亮滅屏狀態(tài)切換時,顯示架構(gòu)可以通過 panel 驅(qū)動注冊的接口操控 LCD;
3、背光參數(shù)配置及等級設(shè)置等。
Display驅(qū)動模型介紹
驅(qū)動模型背景
當(dāng)前操作系統(tǒng)和 SOC 種類繁多,各廠商的顯示屏器件也各有不同,隨之針對器件的驅(qū)動代碼也不盡相同,往往是某一款器件驅(qū)動,只適用于某單一內(nèi)核系統(tǒng)或 SOC,如果要遷移到其他內(nèi)核或者 SOC,可能會有不小的移植工作量。而且,不同驅(qū)動 IC 的驅(qū)動代碼差異較大,產(chǎn)品更換驅(qū)動 IC,則又需要重新開發(fā)對應(yīng)的器件驅(qū)動,造成重復(fù)工作。因此,我們嘗試基于 HDF 驅(qū)動框架,編寫一套較通用的 Display 器件驅(qū)動模型,盡可能降低驅(qū)動開發(fā)者的開發(fā)或移植工作量,簡化器件驅(qū)動開發(fā),提升開發(fā)效率。
圖1 HDF Display驅(qū)動模型層次關(guān)系
以顯示模塊為例,上層為圖形服務(wù);中間層為 HDI 層(Hardware Display Interface),對圖形服務(wù)提供驅(qū)動能力接口,方便其操作具體的外設(shè)器件;顯示驅(qū)動模型當(dāng)前部署在內(nèi)核態(tài),向上對接到 Display HDI 的實現(xiàn),同時在內(nèi)核對接到標(biāo)準(zhǔn)的顯示框架上(如DRM、FB);向下對接不同的 panel 驅(qū)動,從而自上而下打通顯示通路,驅(qū)動屏幕點亮。
驅(qū)動模型通過逐步兼容不同的顯示框架(DRM、FB)及差異化的 SOC,開發(fā)者可基于其快速開發(fā)顯示屏器件驅(qū)動。
驅(qū)動模型解析
顯示驅(qū)動模型基于 HDF 驅(qū)動框架、Platform 接口及 OSAL 接口開發(fā),可以屏蔽不同內(nèi)核形態(tài)(LiteOS、Linux)差異,適用于不同芯片平臺(Hi35xx、Hi38xx、V3S等),為顯示屏器件提供統(tǒng)一的驅(qū)動平臺。
當(dāng)前驅(qū)動模型主要部署在內(nèi)核態(tài)中,向上對接到 Display 公共 hal 層,輔助 HDI 的實現(xiàn)。顯示驅(qū)動通過 Display-HDI 層對圖形服務(wù)暴露顯示屏驅(qū)動能力;向下對接顯示屏 panel 器件,驅(qū)動屏幕正常工作,自上而下打通顯示全流程通路。
模型各層設(shè)計說明
Display 驅(qū)動模型基于 HDF 驅(qū)動框架、Platform 接口及 OSAL 接口開發(fā),可以做到不區(qū)分OS(LiteOS、Linux)和芯片平臺(Hi35xx、Hi38xx、V3S等),為 LCD 器件提供統(tǒng)一的驅(qū)動模型。
如圖 2 所示,當(dāng)前 HDF Display 驅(qū)動模型主要分為四層:標(biāo)準(zhǔn)架構(gòu)適配層(DRM Panel Adapter Driver)、顯示公共驅(qū)動層(DisplayCommon Driver)、芯片平臺適配層(SoC Adapter Driver)、器件驅(qū)動層(Display Panel Driver)。
1、標(biāo)準(zhǔn)架構(gòu)適配層
圖3. 標(biāo)準(zhǔn)架構(gòu)適配層組件
如圖 3 所示,本層主要完成對接標(biāo)準(zhǔn)的顯示驅(qū)動架構(gòu),如 DRM(Direct Rending Manager)或 FB(Framebuffer),以 DRM 為例,將 panel 側(cè)驅(qū)動接口對接到標(biāo)準(zhǔn)框架中,保證在 DRM 框架中實現(xiàn)對 Panel 驅(qū)動的操作接口,當(dāng)前注冊的接口如下。
static struct drm_panel_funcs g_hdfDrmPanelFuncs = { .get_modes = HdfDrmPanelGetModes, .enable = HdfDrmPanelEnable, .disable = HdfDrmPanelDisable, .prepare = HdfDrmPanelPrepare, .unprepare = HdfDrmPanelUnprepare,};
2、顯示公共驅(qū)動層
圖4. 顯示公共驅(qū)動層組件
如圖 4 所示,此部分屬于整個驅(qū)動模型的中樞,所有的屏端接口注冊、Panel 信息管理、屏幕狀態(tài)控制、用戶態(tài) HDI 接口命令處理、以及通用的基礎(chǔ)顯示特性,目前都是通過這部分實現(xiàn)。
在本層通過結(jié)構(gòu)體 DispManager 管理所有的顯示信息,其成員 PanelManager 用于記錄與顯示屏相關(guān)的接口及參數(shù)信息。同時接收并處理 HDI 層直接對 panel 操作相關(guān)的指令(主要用于 L0-L1 等輕量級系統(tǒng)),如 Panel 器件信息的獲取、休眠喚醒、背光設(shè)置等指令。此外,本層還負(fù)責(zé)實現(xiàn)一些基礎(chǔ)顯示特性的業(yè)務(wù)框架,如 ESD 檢查機制,力求將顯示相關(guān)的共有邏輯集中到本層實現(xiàn),以簡化 Panel 器件驅(qū)動的實現(xiàn),避免 panel 驅(qū)動中相同功能的重復(fù)實現(xiàn),便于統(tǒng)一管理和維護。
3、芯片平臺適配層
圖5. 芯片平臺適配層組件
如圖 5 所示,借助此 SoC 適配層,實現(xiàn) Display 器件驅(qū)動和 SoC 側(cè)硬件資源的解耦,主要完成芯片平臺強相關(guān)的參數(shù)配置,如 mipi 速率計算及設(shè)置、管腳復(fù)用配置,以及其他和 SoC 強相關(guān)的差異化配置及初始化等。
4、器件驅(qū)動層
圖6. 器件驅(qū)動層組件
如圖 6 所示,器件驅(qū)動層主要實現(xiàn)和器件自身強相關(guān)的驅(qū)動適配接口,例如發(fā)送初始化序列、休眠喚醒流程、背光設(shè)置、ESD 檢測等,同時完成 panel 信息的解析,并將 panel 向上注冊到公共驅(qū)動層進行管理。
基于 Display 驅(qū)動模型開發(fā) LCD 器件驅(qū)動,可以借助平臺提供的各種能力及接口,較大程度的降低器件驅(qū)動的開發(fā)難度和周期,提升開發(fā)效率。
說明
以上驅(qū)動模型中的各層,需要根據(jù)產(chǎn)品自身情況來選擇,其中“顯示公共驅(qū)動層”和“器件驅(qū)動層”為必選項,“標(biāo)準(zhǔn)架構(gòu)適配層”和“芯片平臺適配層”則為可選項。對于L0-L1這種輕量級SoC,一般都會有與SoC強相關(guān)的硬件配置需要在“芯片平臺適配層”中完成,而對于L2及其以上的SoC,通常都會采用標(biāo)準(zhǔn)的顯示框架,此時“標(biāo)準(zhǔn)架構(gòu)適配層”則必不可少。
驅(qū)動加載及運行
HDF 的驅(qū)動的加載方式,在之前的 HDF 框架介紹章節(jié)中已經(jīng)做過說明,框架通過解析設(shè)備描述的 hcs 配置文件,獲取到各設(shè)備的配置信息,根據(jù) moduleName 來匹配對應(yīng)設(shè)備的驅(qū)動文件入口,按照配置的加載優(yōu)先級,依次加載驅(qū)動,詳細(xì)說明會在下一節(jié)的“具體開發(fā)步驟”中進行描述。
如圖 7 所示,簡要概括了驅(qū)動模型的加載及運行流程,對模型內(nèi)部組件及關(guān)聯(lián)組件之間的關(guān)系做了劃分,整體加載流程分為 9 步,分別說明如下:
“顯示公共驅(qū)動層”和“器件驅(qū)動層”為必選項,“標(biāo)準(zhǔn)架構(gòu)適配層”和“芯片平臺適配層”
1、HDF Device Manager 解析設(shè)備描述;
2、HDF 優(yōu)先加載器件驅(qū)動層,構(gòu)建 Panel 設(shè)備;
3、將 panel 信息及操作接口注冊到公共驅(qū)動層;
4、HDF 其次加載芯片平臺適配層,進行 SoC 相關(guān)硬件資源初始化;
5、HDF 再次加載公共驅(qū)動層,對共有特性進行初始化;
6、HDF 最后加載標(biāo)準(zhǔn)架構(gòu)適配層;
7、從公共驅(qū)動層中獲取到 PanelManager,;
8、將對應(yīng) panel 注冊到 DRM 框架中;
9、在系統(tǒng)運行起來后,DRM 會調(diào)用 panel ops 進行顯示屏控制。
對于采用像 LiteOS 這種輕量內(nèi)核的系統(tǒng),并不會像 Linux 內(nèi)核那樣提供標(biāo)準(zhǔn)的顯示框架,驅(qū)動模型也無法與其對接,因而上層圖形系統(tǒng)可以通過 HDI 接口,來直接操控顯示屏。
Display驅(qū)動開發(fā)指導(dǎo)
驅(qū)動開發(fā)說明
基于 HDF Display 驅(qū)動模型,開發(fā)一款器件驅(qū)動,開發(fā)者主要需要完成兩部分工作:HCS 配置文件、器件驅(qū)動層適配。
對于輕量級設(shè)備(L0-L1),以海思 Hi35xx 芯片為例,除了上述兩部分工作外,還需要在芯片平臺適配層中,完成 SoC 有關(guān)顯示屏的硬件資源配置。
對于標(biāo)準(zhǔn)設(shè)備(≥L2),還需要關(guān)注與 DRM 對接的標(biāo)準(zhǔn)架構(gòu)適配層,此部分在模型中已經(jīng)添加,開發(fā)者只需聚焦器件驅(qū)動層的實現(xiàn)即可。
具體開發(fā)步驟
此處我們以潤和開發(fā)板(Hi3516 SoC)為例,說明適配一款 LCD 屏需要完成的工作。
添加 Display 配置信息
(1)設(shè)備描述配置
配置文件目錄:
vendor/hisilicon/hispark_taurus/config/device_info/device_info.hcs
基礎(chǔ)的設(shè)備描述信息,在 HDF 的配置章節(jié)有作說明,此處不再重復(fù)描述。在配置文件中添加 LCD 設(shè)備描述信息如下:
device_lcd :: device { device0 :: deviceNode { policy = 0; // 設(shè)備發(fā)布策略為0,即只對內(nèi)核態(tài)發(fā)布服務(wù) priority = 100; // 設(shè)備對應(yīng)驅(qū)動加載優(yōu)先級,值越小越早加載 preload = 0; // 0代表正常加載,1代表不加載 permission = 0660; // 設(shè)備對應(yīng)節(jié)點的權(quán)限// 模塊名很關(guān)鍵,需和對應(yīng)驅(qū)動的中的moduleName保持一致 moduleName = “LCD_XXX”; serviceName = “hdf_lcdxxx_service”; // 當(dāng)前設(shè)備對應(yīng)的服務(wù) deviceMatchAttr = “ hdf_lcdxxx_driver”; // 設(shè)備對應(yīng)私有配置屬性名 }}
(2)器件私有配置
參考的配置文件目錄:
vendor/hisilicon/hispark_taurus/config/lcd/lcd_config.hcs
檢查配置宏
驅(qū)動模型的編譯入口:drivers/adapter/khdf/liteos/model/display/Makefile
根據(jù)編譯控制內(nèi)容可知,需增加 panel 對應(yīng)的編譯控制宏:
ifeq ($(LOSCFG_DRIVERS_HDF_LCD_XXX), y)LOCAL_SRCS += $(LITEOSTOPDIR)/。。/。。/drivers/framework/model/display/driver/panel/mipi_xxx.cendif
配置編譯宏的路徑:
kernel/liteos_a/tools/build/config/hispark_taurus_clang_release.config
LOSCFG_DRIVERS_HDF_DISP=yLOSCFG_DRIVERS_HDF_LCD_XXX=y
適配器件驅(qū)動
Display 驅(qū)動模型路徑:drivers/framework/model/display/driver
對應(yīng)的器件驅(qū)動路徑:drivers/framework/model/display/driver/panel
驅(qū)動入口模板如下:
struct HdfDriverEntry g_ xxxDevEntry = { .moduleVersion = 1, .moduleName = “LCD_XXX”, // 要求和device_info.hcs中配置的模塊名一致 .Init = xxxEntryInit, // 驅(qū)動入口};HDF_INIT(g_xxxDevEntry); // HDF驅(qū)動入口解析模板
LCD 器件驅(qū)動需要適配的基礎(chǔ)接口包括 init、on、off、setBacklight 等,并將器件信息掛接到 panle 的 info 成員上。
static void xxxPanelInit(struct PanelData *panel){ panel-》info = &g_panelInfo; panel-》status.powerStatus = POWER_STATUS_OFF; panel-》status.currLevel = MIN_LEVEL; panel-》esd = &g_panelEsd; panel-》init = xxxInit; panel-》on = xxxOn; panel-》off = xxxOff; panel-》setBacklight = xxxSetBacklight;}
Display開發(fā)實例
當(dāng)前潤和開源板(Hi3516 SoC)上搭載的是眾盛捷的 5.5 寸屏,對應(yīng)的 Driver IC 型號為集創(chuàng)北方 ICN9700,顯示屏的物理接口為 MIPI DSI,以此屏為例進行開發(fā)示例說明。
添加配置
配置路徑:
vendor/hisilicon/hispark_taurus/config/device_info/device_info.hcs
/* Display驅(qū)動相關(guān)的設(shè)備描述配置 */display :: host { hostName = “display_host”; /* Display平臺驅(qū)動設(shè)備描述 */ device_hdf_disp :: device { device0 :: deviceNode { policy = 2; priority = 200; permission = 0660; moduleName = “HDF_DISP”; serviceName = “hdf_disp”; } } /* SOC適配層驅(qū)動設(shè)備描述 */ device_hi35xx_disp :: device { device0 :: deviceNode { policy = 0; priority = 199; moduleName = “HI351XX_DISP”;
} } /* LCD器件驅(qū)動設(shè)備描述 */ device_lcd :: device { device0 :: deviceNode { policy = 0; priority = 100; preload = 0; moduleName = “LCD_ ICN9700”; } }}
通過如上配置中的器件驅(qū)動的 moduleName 為 “LCD_ICN9700”,HDF 遍歷對應(yīng)的驅(qū)動入口并加載匹配的驅(qū)動。
適配編譯
編譯入口:drivers/adapter/khdf/liteos/model/display/Makefile
ifeq ($(LOSCFG_DRIVERS_HDF_LCD_ICN9700), y)LOCAL_SRCS += $(LITEOSTOPDIR)/。。/。。/drivers/framework/model/display/driver/panel/mipi_icn9700.cendif
配置編譯宏的路徑:
kernel/liteos_a/tools/build/config/hispark_taurus_clang_release.config
LOSCFG_DRIVERS_HDF_LCD_ICN9700 =y
添加器件驅(qū)動
驅(qū)動路徑:drivers/framework/model/display/driver/panel/mipi_icn9700.c
器件驅(qū)動加載入口:
struct HdfDriverEntry g_icn9700DevEntry = { .moduleVersion = 1, .moduleName = “LCD_ICN9700”, .Init = Icn9700EntryInit,};
器件驅(qū)動初始化及 Panel 注冊:
int32_t Icn9700EntryInit(struct HdfDeviceObject *object){ struct Icn9700Dev *icn9700 = NULL; if (object == NULL) { HDF_LOGE(“%s: object is null”, __func__); return HDF_FAILURE; } icn9700 = (struct Icn9700Dev *)OsalMemCalloc(sizeof(struct Icn9700Dev)); if (icn9700 == NULL) { HDF_LOGE(“%s icn9700 malloc fail”, __func__); return HDF_FAILURE; } Icn9700PanelInit(&icn9700-》panel);
icn9700-》panel.object = object; icn9700-》reset_gpio = RESET_GPIO; icn9700-》reset_delay = 20; // delay 20ms object-》priv = (void *)icn9700; if (RegisterPanel(&icn9700-》panel) != HDF_SUCCESS) { HDF_LOGE(“%s: RegisterPanel failed”, __func__); return HDF_FAILURE; } HDF_LOGI(“%s: exit succ”, __func__); return HDF_SUCCESS;}
Panel Info 初始化:
static struct PanelInfo g_panelInfo = { .width = WIDTH, /* width */ .height = HEIGHT, /* height */ .hbp = HORIZONTAL_BACK_PORCH,
/* horizontal back porch */ .hfp = HORIZONTAL_FRONT_PORCH, /* horizontal front porch */ .hsw = HORIZONTAL_SYNC_WIDTH, /* horizontal sync width */ .vbp = VERTICAL_BACK_PORCH, /* vertical back porch */ .vfp = VERTICAL_FRONT_PORCH, /* vertical front porch */ .vsw = VERTICAL_SYNC_WIDTH, /* vertical sync width */ .frameRate = FRAME_RATE, /* frame rate */ .intfType = MIPI_DSI, /* panel interface type */ .intfSync = OUTPUT_USER,
/* output timing type */ /* mipi config info */ .mipi = { DSI_2_LANES, DSI_VIDEO_MODE, VIDEO_BURST_MODE, FORMAT_RGB_24_BIT }, /* backlight config info */ .blk = { BLK_PWM, MIN_LEVEL, MAX_LEVEL, DEFAULT_LEVEL }, .pwm = { BLK_PWM1, PWM_MAX_PERIOD },};
填充 Panel 信息并掛接回調(diào)接口:
static struct PanelEsd g_panelEsd = { .support = false, .checkFunc = Icn9700EsdCheckFunc,};static void Icn9700PanelInit(struct PanelData *panel){ panel-》info = &g_panelInfo; panel-》status.powerStatus = POWER_STATUS_OFF; panel-》status.currLevel = MIN_LEVEL; panel-》esd = &g_panelEsd; panel-》init = Icn9700Init; panel-》on = Icn9700On; panel-》off = Icn9700Off; panel-》setBacklight = Icn9700SetBacklight;}
Panel 亮屏接口實現(xiàn):
static int32_t Icn9700On(struct PanelData *panel){ int32_t ret; struct Icn9700Dev *icn9700 = NULL; icn9700 = PanelToIcn9700Dev(panel); if (icn9700 == NULL) { HDF_LOGE(“%s: icn9700 is null”, __func__); return HDF_FAILURE; } /* lcd reset power on */ ret = LcdResetOn(icn9700); if (ret != HDF_SUCCESS) { HDF_LOGE(“%s: LcdResetOn failed”, __func__);
return HDF_FAILURE; } if (icn9700-》mipiHandle == NULL) { HDF_LOGE(“%s: mipiHandle is null”, __func__); return HDF_FAILURE;
} /* send mipi init code */ int32_t count = sizeof(g_OnCmd) / sizeof(g_OnCmd[0]); int32_t i; for (i = 0; i 《 count; i++) { ret = MipiDsiTx(icn9700-》mipiHandle, &(g_OnCmd[i])); if (ret != HDF_SUCCESS) { HDF_LOGE(“%s: MipiDsiTx failed”, __func__); return HDF_FAILURE; } } panel-》status.powerStatus = POWER_STATUS_ON; /* set mipi to hs mode */ MipiDsiSetHsMode(icn9700-》mipiHandle);
添加芯片適配驅(qū)動
驅(qū)動路徑:
drivers/framework/model/display/driver/adapter_soc/hi35xx_disp.c
部分代碼示例如下,mipi 參數(shù)配置:
static int32_t MipiDsiInit(struct PanelInfo *info){ int32_t ret; struct DevHandle *mipiHandle = NULL; struct MipiCfg cfg; mipiHandle = MipiDsiOpen(0); if (mipiHandle == NULL) { HDF_LOGE(“%s: MipiDsiOpen failed”, __func__); return HDF_FAILURE; } cfg.lane = info-》mipi.lane; cfg.mode = info-》mipi.mode;
cfg.format = info-》mipi.format; cfg.burstMode = info-》mipi.burstMode; cfg.timing.xPixels = info-》width;cfg.timing.hsaPixels = info-》hsw; cfg.timing.hbpPixels = info-》hbp; cfg.timing.hlinePixels = info-》width + info-》hbp + info-》hfp + info-》hsw; cfg.timing.vsaLines = info-》vsw; cfg.timing.vbpLines = info-》vbp;cfg.timing.vfpLines = info-》vfp; cfg.timing.ylines = info-》height; cfg.timing.edpiCmdSize = 0;cfg.pixelClk = CalcPixelClk(info);
cfg.phyDataRate = CalcDataRate(info); /* config mipi device */ ret = MipiDsiSetCfg(mipiHandle, &cfg); if (ret != HDF_SUCCESS) { HDF_LOGE(“%s:MipiDsiSetCfg failed”, __func__); } MipiDsiClose(mipiHandle); return ret;}
總結(jié)
本文簡要說明了 HDF Display 驅(qū)動模型的整體架構(gòu)、加載及運行流程、以及開發(fā)者基于此模型開發(fā)一款 LCD 驅(qū)動需要完成的基礎(chǔ)適配工作。當(dāng)前模型更多的是聚焦對各顯示框架和差異化 SOC 的兼容適配,優(yōu)先滿足不同開發(fā)板的基本顯示功能需求,驅(qū)動模型還在不斷演進完善,歡迎持續(xù)關(guān)注。
責(zé)任編輯:haq
-
驅(qū)動
+關(guān)注
關(guān)注
12文章
1918瀏覽量
86940 -
模型
+關(guān)注
關(guān)注
1文章
3521瀏覽量
50427 -
HarmonyOS
+關(guān)注
關(guān)注
80文章
2126瀏覽量
33076
原文標(biāo)題:OpenHarmony HDF Display驅(qū)動模型解析及移植指導(dǎo)
文章出處:【微信號:gh_e4f28cfa3159,微信公眾號:OpenAtom OpenHarmony】歡迎添加關(guān)注!文章轉(zhuǎn)載請注明出處。
發(fā)布評論請先 登錄
知識分享 | 評估模型架構(gòu)——如何實現(xiàn)?

迅為RK3568開發(fā)板實操-HDF驅(qū)動配置UART-修改HCS配置
【北京迅為】iTOP-RK3568開發(fā)板鴻蒙OpenHarmony系統(tǒng)南向驅(qū)動開發(fā)實操-HDF驅(qū)動配置UART

北京迅為iTOP-RK3568開發(fā)板OpenHarmony系統(tǒng)南向驅(qū)動開發(fā)實操-HDF驅(qū)動配置LED

北京迅為RK3568開發(fā)板OpenHarmony系統(tǒng)南向驅(qū)動開發(fā)內(nèi)核HDF驅(qū)動框架架構(gòu)

迅為RK3568開發(fā)板篇Openharmony配置HDF控制UART-實操-HDF驅(qū)動配置UART-修改HCS配置
【「鴻蒙操作系統(tǒng)設(shè)計原理與架構(gòu)」閱讀體驗】- 第5章閱讀有感
迅為RK3568開發(fā)板篇OpenHarmony實操HDF驅(qū)動控制LED-添加內(nèi)核編譯
迅為RK3568開發(fā)板篇OpenHarmony實操HDF驅(qū)動控制LED-編寫內(nèi)核 LED HDF 驅(qū)動程序
迅為RK3568開發(fā)板篇OpenHarmony配置HDF驅(qū)動控制LED-新增 topeet子系統(tǒng)
迅為RK3568開發(fā)板篇OpenHarmony配置HDF驅(qū)動控制LED-配置創(chuàng)建私有配置文件
迅為RK3568開發(fā)板篇OpenHarmony配置HDF驅(qū)動控制LED-修改HCS硬件配置
車載以太網(wǎng)的整體架構(gòu)解析

評論