書接上文(點此查看前文)，我們橫向比較了在應用TFLm引擎進行模型文件導入時候，所使用的三種常用方式：

SD卡存儲結合文件系統，

xxd小工具進行文件的十六進制轉換

以及使用匯編指令.incbin直接進行模型導入。

可以說各有所長，但是，當我們需要頻繁地進行模型的替換、更新時，麻煩就出現了。xxd和.incbin的形式都需要重新編譯目標工程，并下載到板子中。 當我們的程序體量較大時，即便不需要對全部工程進行編譯（做到改啥編啥），但是，下載這一步，是無論如何不能跳過的，隨著最終鏡像大小的不同，所消耗的時間也會不同。而使用文件系統的方式，無形中增加了移植文件系統的工作量。

設計思路

為了克服這一問題，小編在上一篇的結尾提出了一個新的方案，直接把flash看作一大塊空白存儲區，并開辟一個固定區域存放模型文件。這樣一來，我們只需要在程序中將模型的讀取位置固定，無論模型是否更新，都能夠讀取最新的模型數據，進行后續處理。 而且小編也特意強調建議大家直接使用Nor Flash來實現這一操作。 以i.MX RT系列MCU為例說明這樣做的優勢。i.MX RT系列由于沒有片上Flash芯片，都通過外擴Flash芯片存儲代碼。當我們將啟動方式調整為XIP，即從flash啟動時，芯片內部的BootROM會幫我們配置初始化好這個片上的Flash芯片，而由于Nor Flash的特性，支持隨機的內存訪問，也就是說，我們在程序內部，可以直接通過指針的形式進行訪問，甚至可以直接調用memcpy函數進行數據的拷貝。 比起集成文件系統的方式，可以說方便至極。不過，也不是說Nand Flash就不適合，只是處理起來會稍稍麻煩一點，由于不支持隨機的讀操作，就要先拷貝到RAM區域再進行操作。

設計實現

言歸正傳，為了方便進行數據的管理，我們需要設計一套簡單的管理邏輯，說的專業一點就是為我們的數據添加一個幀頭，當然，既然大道至簡，數據打包格式大致就是如下格式（可能有些簡陋啊，大家見諒）：

當然為了能夠在程序中使用，我們再定義一個對應的C語言形式來表達，這里要用到C語言中0長度數組的概念：

struct {
uint32_t n, w, h , c;
uint8_t data[0];
}

這樣一來，我們就具象化了我們所設計的那個簡單的數據打包協議。

下一步是如何將數據打包成我們要的樣子，這里要借助于Python來編寫一個簡單的腳本處理，并假設最終會生成一個二進制文件，假設輸入一個多維數組results，首先構建其幀頭，默認維度不足4的數據，用1補齊，保證最終的幀頭包含4個維度信息：

def save_to_bin(bin_name, results):
    shape = list(results[0].shape)
    element_size = [1] * (3 - len(shape)) + shape
    element_len = len(results)
    # shape is [N, H, W, C]
    bin_values = np.asarray([element_len] + element_size, dtype=np.uint32).tobytes()
    bin_values += results.tobytes()
    with open(bin_name, "wb") as f:
        f.write(bin_values)
        f.close()

聊到這兒，可能有同學會問了，針對于tflite模型，我們往往只需要知道其首地址就好了，TFLm會處理那些長度信息，我還有必要構造幀頭嗎？這下給小編問的有點啞口無言。馬上著手設計了第二種數據結構：

是的，針對于模型數據這一特殊的存在，可以設計出更加精簡的表達格式，而且，我們知道tflite模型本身實際上已經是二進制文件的形式了，也就是說，可以直接拿過來使用，無需再做任何操作，直接燒寫到固定地址即可。

那我們上面所設計的數據結構就毫無用武之地了嗎？當然不是！小編做這些當然都是有理由的啊。

大家想一想，運行神經網絡模型的時候，光有模型就可以了嗎？當然不，我們還缺少輸入啊！如果你是攝像頭輸入，請跳過這節。而如果是離線測試呢？需要大量加載靜態圖到內存中，是不是和之前我們的分析就類似了。

每次更換測試數據，依舊需要重新下載鏈接，那么按照本文提供的方案，也為數據設置一塊固定的區域，然后借助于上述save_to_bin代碼，將數據打包成固定格式，是不是就可以在程序中利用那個結構體訪問了呢？沒錯！小編早就設計好了。