您的位置:首页
在bootloader及IAP中使用zlib解压缩
2015-06-12 21:19
295 查看
原有的bootloader方案是在片内FLASH上面分成3块,bootloader区占一小块,然后剩下区域平分成两块,一块是运行区,一块是新固件临时存储区。
好在现在FLASH在系统成本中占的比例越来越低了,不然这样用肯定很奢侈浪费了。
在此方案基础上,我们还可以使用压缩功能,这样临时存储区可以更小一些,可以释放出更多空间给运行区。
压缩算法格式综合考虑后使用gzip,解压程序使用zlib。
因为gzip格式比较通用,方便压缩和调试。而解压所消耗的资源也尚可接受。
一般测试下来,gz所用的 deflate 压缩算法大概有75%的压缩率。
所以建议使用压缩后的运行区与临时存储区的大小比例为 4:3 比较合适。
不过压缩率跟原文特征有很大关系,
因此,生成固件时,除原文不能大于运行区的大小以外,还要限制压缩后的体积不能大于临时存储区的大小。
另外,如果系统传输有使用加密技术的话,一定要先压缩再加密。
因为加密后的数据压缩率很小,甚至会有压缩后的体积大于原文的情况。
最后看下zlib解压消耗资源情况:
实测在某cortex-M3/4的系统上面,zlib只启用解压功能,CRC32把table放在RAM中,在末进行其它特别优化的情况占用FLASH在15KB左右。
而解压文件时,消耗的RAM在32KB+9KB,不过一般bootloader或IAP时,其它功能处于禁用状态,所以RAM一般都是可以满足的。
所以,只要固件被压缩下来的体积大于20~30KB就可以考虑使用压缩算法了。
解压速度(120Mhz cortex-M3):
输入输出缓冲块均为16字节
初始化5us,解压1.8KB数据2.1ms,结束上下文7us.
初始化5us,解压150KB数据150ms,结束上下文7us.
输入输出缓冲块均为64字节
初始化5us,解压150KB数据100ms,结束上下文7us.
好在现在FLASH在系统成本中占的比例越来越低了,不然这样用肯定很奢侈浪费了。
在此方案基础上,我们还可以使用压缩功能,这样临时存储区可以更小一些,可以释放出更多空间给运行区。
压缩算法格式综合考虑后使用gzip,解压程序使用zlib。
因为gzip格式比较通用,方便压缩和调试。而解压所消耗的资源也尚可接受。
一般测试下来,gz所用的 deflate 压缩算法大概有75%的压缩率。
所以建议使用压缩后的运行区与临时存储区的大小比例为 4:3 比较合适。
不过压缩率跟原文特征有很大关系,
因此,生成固件时,除原文不能大于运行区的大小以外,还要限制压缩后的体积不能大于临时存储区的大小。
另外,如果系统传输有使用加密技术的话,一定要先压缩再加密。
因为加密后的数据压缩率很小,甚至会有压缩后的体积大于原文的情况。
最后看下zlib解压消耗资源情况:
实测在某cortex-M3/4的系统上面,zlib只启用解压功能,CRC32把table放在RAM中,在末进行其它特别优化的情况占用FLASH在15KB左右。
而解压文件时,消耗的RAM在32KB+9KB,不过一般bootloader或IAP时,其它功能处于禁用状态,所以RAM一般都是可以满足的。
所以,只要固件被压缩下来的体积大于20~30KB就可以考虑使用压缩算法了。
解压速度(120Mhz cortex-M3):
输入输出缓冲块均为16字节
初始化5us,解压1.8KB数据2.1ms,结束上下文7us.
初始化5us,解压150KB数据150ms,结束上下文7us.
输入输出缓冲块均为64字节
初始化5us,解压150KB数据100ms,结束上下文7us.
相关文章推荐
- CodedUI自动化测试及脱离VS独立运行
- VS 2013--工程的创建,scanf报错,常用快捷键,行号设置
- [apache]用shell分析网站的访问情况
- 纸牌问题
- Git的基本使用
- 记录一些有意思的证明
- [BZOJ 1031] [JSOI2007] 字符加密Cipher
- CSAPP缓冲区溢出攻击实验(下)
- CSAPP缓冲区溢出攻击实验(下)
- 兼容早期IE版本的 Ajax 实例
- 你的灯亮着吗读后感三
- 《返回一个二维整数数组中最大联通子数组的和》
- 学习Android的Camera
- notepad++自动补全括号
- 学习Android的Camera 2015-06-12 21:15 21人阅读 评论(0) 收藏
- Myeclipse安装Activiti
- 自己编写的.sh脚本文件运行完闪退解决方案
- LeetCode 75 Sort Colors
- 头像上传组件,后台安全控制
- 自己写着玩(二)