takashiki 发表于 2016-7-27 10:27
你的题目要求不是要搞个上位机命令行程序吗，那就用TCC写个脚本就完了，根本不用你去编译，MDK编译前先调 ...

我去看了下tcc介绍，这个tcc还真是牛啊，把c当脚本用，我赶紧去试试看再来汇报下

以前没发现有这样的好东西，都是用vc写命令行程序再用mdk调用的

myxiaonia 发表于 2016-7-27 10:30
是mdk里面有个大数组，我希望这个大数组是压缩后编译到最后的程序文件里，再里面解压恢复，

因为程序真 ...

说真的，就你这个需求，个人认为使用miniLZO、QuickLZ之类的，要比你的RLE压缩要好得多，压缩率会高不少，但解压时的时间和资源增加却并不多。
TCC当然牛X了，可以自己当解释器（其实是编译器），还可以通过源代码直接嵌入到宿主程序中。

takashiki 发表于 2016-7-27 10:37
说真的，就你这个需求，个人认为使用miniLZO、QuickLZ之类的，要比你的RLE压缩要好得多，压缩率会高不少 ...

之前也是找适合单片机的压缩算法，也看到了你所说的miniLZO，不过不清楚解压时候是否必须整个文件都解压完，rle比较简单，可以指定到任意偏移位置处获取解压数据，不知道你谈到的这两种算法是否也有这样的特征

而且我在看lzss的资料时有提到最少64k内存我就吐血了，我用的stm32型号最大就是64k，这可怎么整

aozima 发表于 2016-7-27 11:27
就1个数组，直接再写几行C，然后运行一下写成一个bin文件，前后5分钟搞定。

...

这个数组是部分初始化的，3维数组，用3层{}嵌套初始化，要初始化成0的地方，不是显式而是通过{}隐式的，c意义下的数组，里面还有注释

myxiaonia 发表于 2016-7-27 11:07
之前也是找适合单片机的压缩算法，也看到了你所说的miniLZO，不过不清楚解压时候是否必须整个文件都解压 ...

LZSS、LZARI、LZ77、LZW、LZ4等等解压都需要大内存
LZO、QuickLZ解压是不占用内存资源的（QuickLZ可选占用多大，我一般都选0），就函数内部几个临时变量的消耗，ROM是要占用一些，在1K级别的样子。
他们都无法指定任意位置开始解压，只能把你这80个二维数组单独压缩为80个单独的数组，然后完整的解压那1K内容。