天天看點

痞子衡嵌入式:超級下載下傳算法(RT-UFL)開發筆記(3) - 統一FlexSPI驅動通路

本篇是開發筆記第三篇,咱們就重點聊聊如何為超級下載下傳算法設計一套統一的FlexSPI驅動接口及其通路方式。

  大家好,我是痞子衡,是正經搞技術的痞子。今天痞子衡給大家介紹的是超級下載下傳算法開發筆記(3)之統一FlexSPI驅動通路。

  文接上篇 《超級下載下傳算法(RT-UFL)開發筆記(2) - 識别目前i.MXRT型号》,現在超級算法已經能夠識别到目前i.MXRT型号了,下一步就是找到一套統一的底層Flash驅動函數來實作外接串行NOR Flash的基本擦寫操作,這套統一的底層Flash驅動至少要在API層面做到與i.MXRT型号無關,并且調用方式統一,這樣就相當友善後續的上層算法層面的邏輯設計了。

  本篇是開發筆記第三篇,咱們就重點聊聊如何為超級下載下傳算法設計一套統一的FlexSPI驅動接口及其通路方式。

  我們知道i.MXRT系列内部用于連接配接NOR Flash的外設名字叫FlexSPI,這個外設在不同i.MXRT型号上差異很小,這對于設計通用Flash驅動函數來說友善了很多,這也是痞子衡做i.MXRT超級算法的最初動機。

  說到FlexSPI這個外設,其實就是Kinetis系列的QuadSPI外設的更新,在恩智浦MCUX SDK包裡提供了一套标準的FlexSPI驅動,這個驅動寫得還挺完善的,但是痞子衡并沒有選擇SDK标準驅動作為超級下載下傳算法的底層Flash驅動。

  我們知道i.MXRT系列都是包含BootROM的,BootROM都支援從外部串行NOR Flash啟動,這意味着BootROM中也是內建了FlexSPI驅動的(驅動源碼也開源在SDK裡了),BootROM裡這套驅動與MCUX SDK裡的驅動大體上差不多,但是細節上有差異,痞子衡最終選擇了BootROM裡的FlexSPI驅動作為超級算法的底層Flash驅動,原因下一節會講。

  現在我們雖然找到了一套看似統一的FlexSPI驅動,但事情遠不是這麼簡單。BootROM版本的FlexSPI驅動從API接口本身而言是幾乎一緻的,痞子衡之前也為此寫過文章 《利用i.MXRT系列ROM提供的FlexSPI driver API可輕松IAP》,但是在不同i.MXRT型号上調用方式不統一(在開放API的i.MXRT型号上API函數位址不一,在不開放API的i.MXRT型号上需要手動移植mcu-boot裡的源代碼),是以我們需要對所有i.MXRT型号下的BootROM FlexSPI驅動調用方式做一個統一。

  首先講開放ROM API的幾款i.MXRT型号(RT500/RT600/RT1060/RT1064/RT1170),這裡順便先解釋一下上一節的遺留問題,為何選擇BootROM版本FlexSPI驅動而不是SDK标準驅動?當然是因為有這個ROM API的存在,畢竟超級下載下傳算法最終可執行檔案越小越好,能調用ROM API可以極大地減小超級下載下傳算法的最終代碼長度。

  關于ROM API的細節,痞子衡不予贅述,我們按照如下格式準備好全部的g_bootloaderTree_imxrt宏待用(代碼僅示例了i.MXRT1060)

  對于沒有開放ROM API的幾款i.MXRT型号(RT1010/1015/1020/1024/1050),咱們就必須一一移植mcu-boot裡的FlexSPI相關代碼了,需移植的代碼包含兩部分:FlexSPI外設本身驅動,FlexSPI BSP驅動。前者移植起來倒是比較簡單(直接找一個最完善的版本即可),但是後者涉及到了clock和pinmux配置,因i.MXRT型号而異,這部分代碼差異較大,移植起來比較麻煩。

  FlexSPI外設本身驅動就是最終提供如下幾個通用的函數即可,這部分是共用的源代碼:

  在移植FlexSPI BSP驅動過程中遇到了一個最頭疼的事情,就是clock和pinmux代碼需使用SDK裡的基礎驅動,而SDK驅動依賴i.MXRT晶片頭檔案,但是最終超級下載下傳算法隻有一個工程,這個工程幾乎無法同時包含多個i.MXRT頭檔案。如果不用i.MXRT頭檔案,clock和pinmux代碼全部改為裸寫寄存器位址,工作量又太大,也不利于後期維護,最終想到的解決方案就是為每個i.MXRT型号的FlexSPI BSP驅動制作一個庫工程,在庫工程裡各自使用自己的頭檔案,然後生成一個庫檔案作為超級下載下傳算法工程的源檔案。

  下面是示例的i.MXRT1050庫檔案裡需提供的BSP函數清單,這也是綜合多個型号SDK包裡mcu-boot代碼後提煉出來的:

  現在無論是ROM API接口方式,還是源代碼(庫)接口方式,所有的i.MXRT型号下基礎FlexSPI驅動已經準備完畢了,到了最關鍵的統一階段了,我們首先可以定義一個如下ufl_target_desc_t結構體及其全局變量g_uflTargetDesc,這個結構體由FlexSPI擦寫API函數指針(flexspi_nor_flash_driver_t)以及BSP函數指針(flexspi_bsp_driver_t)組成:

  然後我們定義一個ufl_fill_flash_api()函數,該函數的功能就是根據識别出來的i.MXRT型号來具體填充ufl_target_desc_t型全局結構體變量裡的成員值。如果是源代碼接口方式,則填入對應函數名;如果是ROM API接口方式,則根據g_bootloaderTree_imxrt宏找到對應函數位址,最終我們在g_uflTargetDesc全局變量裡統一了FlexSPI驅動通路方式(下述代碼僅示例了RT1050和RT1060)。

  有了g_uflTargetDesc全局變量,此時再包一層API驅動給最終下載下傳算法上層邏輯調用就非常簡單了。

  至此,超級下載下傳算法開發筆記(3)之統一FlexSPI驅動通路痞子衡便介紹完畢了,掌聲在哪裡~~~

文章會同時釋出到我的 部落格園首頁、CSDN首頁、知乎首頁、微信公衆号 平台上。

微信搜尋"痞子衡嵌入式"或者掃描下面二維碼,就可以在手機上第一時間看了哦。

痞子衡嵌入式:超級下載下傳算法(RT-UFL)開發筆記(3) - 統一FlexSPI驅動通路

  最後歡迎關注痞子衡個人微信公衆号【痞子衡嵌入式】,一個專注嵌入式技術的公衆号,跟着痞子衡一起玩轉嵌入式。

痞子衡嵌入式:超級下載下傳算法(RT-UFL)開發筆記(3) - 統一FlexSPI驅動通路
痞子衡嵌入式:超級下載下傳算法(RT-UFL)開發筆記(3) - 統一FlexSPI驅動通路
痞子衡嵌入式:超級下載下傳算法(RT-UFL)開發筆記(3) - 統一FlexSPI驅動通路

  衡傑(痞子衡),目前就職于恩智浦MCU系統部門,擔任嵌入式系統應用工程師。

  專欄内所有文章的轉載請注明出處:http://www.cnblogs.com/henjay724/

  與痞子衡進一步交流或咨詢業務合作請發郵件至 [email protected]

  可以關注痞子衡的Github首頁 https://github.com/JayHeng,有很多好玩的嵌入式項目。

  關于專欄文章有任何疑問請直接在部落格下面留言,痞子衡會及時回複免費(劃重點)答疑。

  痞子衡郵箱已被私信擠爆,技術問題不推薦私信,堅持私信請先掃碼付款(5元起步)再發。