zoukankan      html  css  js  c++  java
  • 记一次nor flash固件烧录速度优化

    背景

    某个方案使用的是spinor作为存储介质,每次烧录新固件都耗时数分钟,为了提高效率,需要对其进行优化。

    分析流程

    基本流程

    当前烧录流程,有一个可选步骤,全盘擦除,这个步骤耗时达数分钟。不过这是可选的。

    接下来必经的步骤,就是从PC端接收数据写入flash了。

    已有优化

    目前倒是已经有一个优化,在收到数据需要写入时,会先读出flash中的数据跟这笔要写入的数据进行比较,如果数据相同就直接跳过,数据不同,才进行擦除和写入。
    这个优化的依据是,相对于一次擦除和写入的耗时来说,读出和比较的耗时很少,一旦命中就可节省掉这次写的开销。在平时调试的时候,两次烧录的固件可能有些数据是完全一样的,这种场景下此处的优化就能发挥作用了。

    优化点

    初步分析,从流程上看没什么问题,最大的耗时在擦除上,但毕竟nor的物理特性就是需要先擦除再写入的。

    但仔细分析,其实还是有优化空间的,这个空间还就在于nor的擦除上。

    nor拥有多条擦除的命令,可以擦除4k,32k,64k或者整片擦除。这些命令的耗时是不同的。

    方案上由于分区规划设置了最小为4k的分区,所以nor就被配置为4k sector,则nor驱动使用的擦除命令就是对应的4k擦除的命令。而这是效率最低的一种擦除方式。

    当前方案在全盘擦除时,是使用循环调用4k擦除实现的,在后续写入数据时也都是以4k为单位进行擦除和写入,在擦除上耗费了大量时间。

    nor的几种擦除命令

    这几种擦除方式,差异到底有多大呢?

    找两款16M的norflash规格书看看。

    比较表格:

    擦除大小(Kbytes) 擦除时间(ms) 每4k擦除耗时(ms) 以4k为基准的耗时比例
    4 70 70 100%
    32 150 18.75 26%
    64 200 12.5 17%
    16 * 1024 3500 0.85 1.2%

    另一款:

    比较表格:

    擦除大小(Kbytes) 擦除时间(ms) 每4k擦除耗时(ms) 以4k为基准的耗时比例
    4 25 25 100%
    32 140 17.5 70%
    64 250 15.62 62%
    16 * 1024 2600 0.63 2.5%

    从以上统计结果看,一次擦除的空间越大,平均速度就越快。

    特别是chip擦除的速度高达到4k擦除的几十倍。

    优化方案

    找到了优化点,结合烧录流程就有了以下思路

    方案一

    设法将4k擦除改为32k,64k擦除。
    这种对于分区本身并非4k对齐来说,实现上会比较麻烦,需要代码中维护一个缓冲区进行数据的拼接,并处理一些边界情况。

    方案二

    在烧录的最开始进行一次chip擦除。并在后续的写入时,跳过擦除步骤,直接写入。
    这种方案对于烧录场景来说,非常合适,实现起来也简单。

    最终采用方案二,改动小,效果明显,烧录速度从数分钟降到了1分钟以内。
    但这个只适用于烧录场景。如果是要对系统运行时的写性能进行优化,就只能考虑尽量用64k擦除了。

    本文地址: https://www.cnblogs.com/zqb-all/p/12493500.html

    公众号: https://sourl.cn/rgbq6M

  • 相关阅读:
    Android学习笔记之-----讯飞语音识别实例化RecognizerDialog参数出现错误的解决方法
    java基本数据类型取值范围
    中国教育
    git push --help
    cherry Tree的严重漏洞
    程序的核心是什么
    BeanUtils.getProperty性能分析
    Java各种反射性能对比
    Spring AOP无法拦截Controller中的方法
    Mock单元测试
  • 原文地址:https://www.cnblogs.com/zqb-all/p/12493500.html
Copyright © 2011-2022 走看看