連續一天加乙個晚上，查資料，發現無解。
壓縮不可能在stm32上進行的。因為**中那個記憶體分配的結構體占記憶體太大了。解壓是可以實現的。
因此這個演算法在stm32上也是有一些作用：在某些場合可以在pc機進行壓縮存入arm中，然後arm解壓。比如某些**放到flash中。不過這些場合很少遇到。
lzma的**生成量並不很大，lzma920版本，要用這個版本，生成的可執行檔案很小。
linux 7z命令安裝使用及其交叉編譯移植到arm linux平台
how to compress data
--------------------
compile files: lzmaenc.h + lzmaenc.c + types.h +
lzfind.c + lzfind.h + lzfindmt.c + lzfindmt.h + lzhash.h
memory requirements:
- (dictsize * 11.5 + 6 mb) + state_size
文件寫的是要6m的記憶體。arm沒這麼大記憶體，除非外擴。
以上就是這大週末的研究成果。全是眼淚！
然後用單步除錯跟蹤，發現那個結構體超級大的結構體啊！
就是執行到lzmaenc.c裡面的lzmaenc_create的這句話：
p = alloc->alloc(alloc, sizeof(clzmaenc));
結構體如下：
typedef struct
clzmaenc;
如果剪裁一下有小可能搞定，但是代價估計很大，還不穩定。
然後就像咋辦呢？看看提供的文件吧！於是就發現了作者寫的：
memory requirements:
- (dictsize * 11.5 + 6 mb) + state_size
於是就徹底歇菜了！！！
看樣子以後要養成先看文件再看**的習慣！！
嗨！多好的**啊！可惜arm裡用不上了！！
stm32移植ucosII成功
osstarthang b osstarthang should never get here 現在做開發真的離不開internet啊 不然我也不可能2.5小時內搞定ucosii的移植。我的硬體版本是 stm32f103c8t6，ucos版本是ucosiiv2.86 另外給大家推薦一本學習ucosi...
STM32 uCOS III GCC移植說明
參考 第四節 參考 第五節 參考 第六節 ucos iii原始檔中的彙編 全部選擇gnu目錄下的檔案，主要包括 uc cpu arm cortex m3 gnu cpu a.s uc lib ports arm cortex m3 gnu lib mem a.s ucos iii ports arm...
STM32 iap移植筆記
對於大多數基於 flash 的系統而言，在最終產品中安裝之後，能夠對韌體進行更新，這一點非常重要。這一功能被稱為在應用中程式設計 iap stm32f4xx 微控制器能夠執行使用者指定的韌體，從而執行微處理器內建 flash 的 iap。借助這一特性，在重新程式設計過程中可以使用任意型別的通訊協議。...