tag 标签: nand

相关帖子
相关博文
  • 热度 4
    2020-1-6 14:37
    1109 次阅读|
    2 个评论
    真「SSD」不怕火炼?长时间高温老化测试见真章
    百佳泰/Blake Chu 现今 SSD 主流已从当初的 2.5 吋 SATA SSD 进化到体积只有一半不到的 M.2 NVMe SSD 。当体积越小,代表了速度将有明显地提升,延迟也会降低,而体积小的 SSD 也更能应用在更广泛的地方,如车载系统、亦或是未来 5G 架构系统的应用。 NAND Flash 为 SSD 内部担任储存数据的组件,一般来说,影响 NAND Flash 数据保存,除了抹写次数( PE/Cycle ),温度也是另一个因素;如在极端的条件下使用,在长时间与不同的温度变化也会对 NAND Flash 数据保存( Data Retention )造成影响。为何这两点会影响到 SSD 数据保存呢?我们简单概述一下 NAND Flash 基本原理。 NAND Flash 基本操作的主要三动作: 写入 、 读取 、 抹除 。 写入 : 数据在 NAND Flash 中是以电子形式( electrical charge )储存。储存电子的高低电位,取决于 Control Gate 所被施加的电压(图 1 ),当一正电压加于 Control Gate 时,传送电子通过第一个绝缘体进入 Floating Gate 内,当 Floating Gate 被注入负电子时,在位中 1 就会变成 0 ,此时为写入。 读取 : 当读取数据时,同样会在 Control Gate 施加电压,吸住 Floating Gate 里的电子,利用电流来感应 Floating Gate 里的电子数量,靠感应到的电子数量转换为二进制的 0 与 1 ,最后输出成数据,此时为读取。 抹除 : 当 Control Gate 加进负电压时,会将电子传送到 Floating Gate 外,而当负电子从 Floating Gate 移除后,位也就从 0 变回 1 ,此时为抹除。 图 1 随着读取、抹写次数上升,电子多次穿越将造成漏电情况,也就是电子无法维持在 Floating Gate ,而导致数据错误。此类型情况也会随着芯片制程提升( TLC ),导致薄膜层越薄,使电子穿越所能承受的次数变的更少。另一方面,当 SSD 处于高温下,也会影响电子的行为导致无法正确保存数据。针对上述情况, JEDEC 固态技术协会已对一般客户及企业订出了温度规范(图 2 ),可见温度对于 SSD 数据存储的影响不可小觑。 图 2 SSD 高温老化测试案例分析 由于车用乃至于工业用的 SSD ,特别注重数据保存能力以及可在高温下维持功能与性能(如延迟时间( Latency ))。百佳泰针对温度是否会对 SSD 数据保存( Data Retention )造成影响,特别挑选四个市面上常见 M.2 NVMe SSD 来进行高温老化测试,利用长时间高温加速老化,观察这些 SSD 在接近寿命终点时的情况。 在进行测试实验前,我们已将这些 SSD 维持相同的条件:已经使用过一段时间、并写入了大量的数据(写入数据内容依据 JEDEC 协会规范制定)。在确认 SSD 状态以及 SMART ( Self-Monitoring Analysis and Reporting Technology )皆正常后,将 SSD 断电放进烤箱,设置 4 种不同时间与温度进行测试。当完成指定的长时间温度测试后,再将 SSD 从烤箱取出,最终在测试仪器上执行 SSD SMART 检查以及全碟读取检查。 ( 图 3) 图 3 Phase 0: 40°C/24HR 第一阶段测试我们先用正常温度 40°C 来检视这 4 个 SSD 状态,作用于基准值并跟后续高温测试进行比较。从图 4 来看,经过 40°C/24HR 后, 4 个 SSD 在执行全碟读取检查的运行时间相差不大;但 SSD A 所需的时间较其他三个长一些。 另从全碟读取检查的指令响应时间统计百分比来看(图 5 ), SSD A 的延迟时间在 Rank B 区间较其他三颗稍多了些。 图 4 图 5 (Rank A 低于 0.5mSec ,代表延迟低,性能好;而当 Rank 高于 10mSec ,则代表延迟高,性能差。故 Rank 能集中在 AB 是相对好的 ) Phase 1: 125°C/24HR 第二阶段测试我们进入高温状态( 125°C )并连续 24 小时烘烤 SSD ,来观察 125 度高温是否对 SSD 有影响。从图 6 来看,经过 125°C/24HR 后, 4 个 SSD 在执行全碟读取检查的运行时间都因为高温而变长;而 SSD A 在这阶段的测试里所需的时间也相较于其他 3 颗明显变得更长,从结果判断得知 SSD A 会因高温而影响效率。 从全碟读取检查的指令响应时间统计百分比来看, SSD A 开始在 Rank C/D 出现些许延迟的现象; SSD B 也表现出轻微的延迟, SSD C & D 则未有明显的影响。到目前为止 4 个 SSD 尚未出现状态错误( SMART error ),或 command error 的情况发生。 图 6 Phase 2: 125°C/120HR 从 Phase 1 结果来看, 4 个 SSD 的性能尚未分出胜负。这一阶段,我们一样维持 125 度,但将时间拉长 5 倍到 120HR 观察。从图 7 来看,经过 125°C/120HR 后, 4 个 SSD 都因为长时间高温让执行全碟读取检查的运行时间拉长,尤以 SSD A 来看,所需的时间竟拉到了近 5 小时之高。 从全碟读取检查的指令响应时间统计百分比来看, SSD A 因在长时间及高温的状态下,呈现高延迟现象;相较于 Phase 1 的 Rank D 数据,竟达 12 倍之多的差距( 18.8% )。此外, SSD B 也不遑多让,延迟时间相对提升;而 SSD D 也在此时开始出现延迟的情况( Rank B )。 在这一阶段测试环节中, SSD C 全身而退,尚未出现任何影响。到目前为止 4 颗 SSD 也还未出现状态错误( SMART error ),及 command error 情况发生。 图 7 Final Phase: 150°C/168HR 从先前 3 个测项结果来看, 4 个 SSD 尚未出现状态错误( SMART error ),但已有两个 SSD 出现明显延迟,导致性能显著下降。为了测试极端状况并加速老化速度,在最后一项测试环节我们将温度提升至 150 度,时间拉长 7 倍,总共 168HR ,从中观察这 4 个 SSD 在极端条件会出现什么样的情况。 从测试结果中(图 8 )我们发现 SSD A 在烤完拿到仪器上开始执行全碟读取检查时就出现问题,除无法正常读取外, SSD 固件回报也呈现状态错误( SMART error )。而 SSD C & SSD D 则是在全碟读取检查撑了一段时间后才出现 error 无法完成读取,随后也出现 SSD 固件回报状态错误( SMART error )。在最终测试环节中,只有 SSD B 脱颖而出,能完成全碟读取检查; SSD A 、 C 、 D 在全碟读取检查过程均发生 command error 情况,只有 SSD B 未出现状态错误( SMART error )及无 command error 的情况产生。 图 8 测试总结 纵观上述测试,我们可以发现随着长时间与温度的增加,部分 SSD 在执行全碟检查时效率下降;其中 3 个 SSD 也因时间不断的拉长以及温度的提升最终导致因数据保存出现问题而产生读取错误的情况。从低延迟时间级距 Rank A 来看,随着温度与时间不断增加,造成延迟时间的情况也随之加深,并导致控制器纠错时间增加,响应时间拉长。 值得一提的是, SSD B 表现优异,除顺利通过长时间高温测试外,在全碟读取检查延迟时间也都保持在高水平之上,相对其他 3 个 SSD 可靠不少。 图 9 结语 经过长时间高温的严峻测试,大部分 SSD 已无法负荷而出现数据保存问题,然而,还是有 SSD 能通过严苛的测试环境。虽现今 M.2 NVMe SSD 会因体积及散热等问题出现资料保存错误情况,但还是可以透过原料控制,以及控制器固件调校技术,让 SSD 能在严苛的条件中执行存取任务,完整保留数据,维持数据正确性。除了本次的测试案例外,百佳泰也可依照客户需求,针对温度 / 时间进行客制化、阶梯化设置,为您的产品迅速找出极限点;并从所提供的详细测试报告中协助您改善产品弱点,提升市场竞争力!
  • 热度 2
    2019-9-18 11:31
    1133 次阅读|
    1 个评论
    ​ 几十年来,闪存一直是嵌入式系统的一个重要课题。与其他存储技术相比,它允许大幅改进电子设备的大小和鲁棒性。闪存存储的其他优势包括缺少移动部件和降低功耗。然而,闪存的挑战并没有在消费类电子产品中广为宣传。其中包括有限的耐用性和更高的软件复杂性。 图 1 :从 U 盘驱动器和 SD 卡到 SSD 和集成电路,闪存是我们日常生活的一部分。 如图 1 所示,闪存在我们的日常生活中无处不在,从专门用于存储数据的设备(如 U 盘驱动器、 SD 卡和 SSD )到内部使用闪存的其他消费类电子产品(如智能手机、 Wi-Fi 调制解调器和智能灯灯泡。 一个标志性的反例是 2001 年发布的 iPod 的第一款产品。它使用旋转的硬盘来提供高存储容量(当时是 5 或 10 GB )。然而,一项研究发现,使用硬盘的产品的故障率大于 20% ,而配备闪存的型号的故障率则低于 10% 。由于它们包含敏感的移动部件,旋转的磁盘不能很好地处理机械冲击。这对配备磁性存储的便携式设备的故障率起着关键影响。 图 2 : 2001 年发布的原版 iPod 是具有磁性存储的移动设备的罕见例子。 当涉及到嵌入式系统时,闪存是非易失性存储器的首选。在嵌入式 Linux 系统中,在模块 ( SoM ) 和单板计算机 ( SBC ) 上使用集成电路 ( IC ) 是一种常见做法,因为它们通常比一些型号的 SD 卡更耐数据磨损。当环境振动是决定性因素时,它们也更加坚固。使用集成闪存的模块案例包括来自 Toradex 的 Apalis 和 Colibri 系列。在图 3 中,您可以看到 Colibri iMX8X 模块的放大视图,该模块配备了 Micron 的 eMMC : 图 3 : Colibri iMX8X 配备了来自 Micron 的 eMMC 闪存。 本文的目标是概述如何通过利用开源和专有软件来测量和估计 eMMC 磨损,从而设计更可靠的嵌入式系统。其动机是例如对 IoT 网关和数据记录器的需求不断增加,以及出于更高的可靠性或间歇性连接原因将冗余数据保留在本地的需求。为了介绍实际的实施细节,配备 Micron eMMC 的 Toradex 模块将被用于介绍如何实现磨损监控和寿命估计解决方案,即闪存分析工具。 本文还包括宽泛的技术概述和一些实现细节。您可能对该信息并不陌生,因此如果您已经具备必要的知识或您认为合适,请随时跳过部分。 技术概述 在进一步讨论之前,值得注意的是,闪存是一个如此广泛的话题,即使一篇专门讨论其工作原理的文章也无法提供足够全面的概述。以下段落仅作为背景,以更好地了解如何估计 eMMC 磨损。 虽然本文仅介绍了理解磨损估计的要点,但互联网上提供了有关闪存存储的丰富文献。例如, Toradex 在其开发者网站上拥有博客、网络研讨会录像和一系列文章。维基百科关于闪存的文章也有超过一百个对其他资源的引用。 NOR 和 NAND 闪存是一个宽泛的术语,有几种技术组合共同构成具有特定特性的最终闪存产品。闪存存储分可初步分为两种类型: NOR 和 NAND 。这些以该技术在晶体管级别如何运行来存储位而命名,类似于 NOR 和 NAND 逻辑门。 虽然 NOR 具有更简单的操作原理和更高的可靠性,但它通常需要更高的引脚数量,并且与 NAND 相比,其单位硅面积的存储密度较低,这会影响其尺寸和成本。由于这些原因, NOR 通常只用于特定应用,即使对于工业级、高度可靠的嵌入式系统也是如此。您可以在 Micron 的 NOR /NAND 闪存指南( PDF )了解更多此话题的信息。您可以在图 4 中看到 NOR 和 NAND 技术在存储密度和容量方面的摘要,该摘要取自本段中提到的指南: 图 4 :按密度和容量划分的 NOR 和 NAND 产品。(来源: Micron NOR/NAND 闪存指南) 如您所见, Micron eMMC 是 MLC 和 TLC 范围内的专用 NAND 设备,我们将对此进行更详细的讨论。由于 Toradex 模块使用 4GB 到 16GB 范围内的 eMMC ,我们可以推断它们使用 MLC 设备。本文稍后将对此进行介绍。 NAND 结构 原始的 NAND 闪存设备可以分为三个不同的部分。 单元格 Cell :最小的单位。该单元以位级别存储数据,并且不能由控制 NAND 存储的设备直接寻址。 页 Page :可用于读取和编程操作的最小单位组。编程操作由从值 1 到值 0 的 " 翻转 " 位构成。页面大小在几千字节范围内,例如, 4 KB 。 块 Block :可用于擦除操作的最小页组合。在定义中,如 Linux MTD 堆栈,块也称为擦除块。擦除操作包括恢复值为 0 的位到值 1 。块大小在几兆字节范围内,例如, 4 MB 。擦除操作比在页上执行的编程或读取操作慢得多。 从上面的要点中最重要的信息是,块磨损,因为它们会被擦除。因此,我们最感兴趣的是块擦除计数。也就是说,每个块被擦除的次数。 图 5 :原始 NAND 闪存的总体示意图。 NAND SLC 和 MLC 单元格作为最小单位,用于存储每一个位。每个单元实际存储的位数取决于它在读取操作期间可以保持和区分的电平阈值。闪存有多种设计,用于指示存储单元可以存储的位数。 SLC :单级单元,每个单元存储 1 位 Pslc : SLC 模式的 MLC 操作,每个单元存储 1 位 MLC :多级单元,每个单元存储 2 位 TLC :三级单元,每个单元存储 3 位 QLC :四级单元,每个单元存储 4 位 表 1 总结的密度和成本与可靠性和使用寿命之间存在权衡。 表 1 : NAND 单元技术比较 图 6 有助于展示 SLC 和 MLC 如何存储位: 图 6 : SLC 和 MLC 电压阈值 pSLC ( " 伪 SLC" )提高了 MLC 设备的操作速度和使用寿命,但代价是将其容量减少一半。寿命与真正的 SLC 无法相比拟,但它大大增加了。伪 SLC 不应与快速模式混淆,后者使 MLC 设备更快,但不会延长其使用寿命: 图 7 :伪 SLC 和快速模式 了解块是否配置为 MLC 或 pSLC 对于确定设备的使用寿命非常重要,因为我们会随着时间的推移统计坏块计数。 对于使用 MLC 技术的 eMMC ,根据硅的线宽,块一般可以承受 3000 到 10000 次擦除周期。与 MLC 相比, pSLC 的生存期提高操作 2 倍。因此, pSLC 比快速模式或提高配置(即使用容量翻倍的闪存使其使用寿命延长两倍)更可取。在制造商的公开文档中很难找到擦除周期计数和线宽值,因此对设备本身进行基准测试可能是一种解决方案。 ECC 我们简要地回顾了块磨损并变无法继续使用。这时当它们正常的时候,并不是一切都是完美的。位可能被随机翻转,损坏存储的数据。这是 ECC 或纠错代码算法介入以更正翻转的位。 随着时间的推移,块中有位翻转的概率会增加。当它变得太大时,块被标记为无法使用。可能在一开始就有坏块,存储设备会从工厂发货时就标记一些坏块。制造商通常包括备用模块来替换这些坏块,从而使它们不会立即影响可用的存储容量。 写入放大 简单地讲,写入放大就是将数据从一个块复制到另一个块,无论是为了更新数据、磨损均衡或任何其他原因。 磨损均衡和垃圾回收 如果始终使用相同的物理页和块,如更新文件,则这些块将过早磨损。在最坏的情况下,如果 NAND 控制器没有为坏块重新分配,则系统甚至可能在闪存寿命终止 ( EOL ) 之前停止工作。 为了防止这种情况发生,磨损均衡算法可确保块始终被均匀使用。为此,它会移动数据。有两种类型的磨损均衡算法。 动态:仅移动动态数据,即随时间更新的数据。静态数据保存在最初写入的块中。此算法更简单,但不使用存储设备的全部容量。当只有一小部分闪存保存静态数据时,最好使用它。 静态:此算法有目的地移动静态数据,均匀地磨损闪存的所有块。这是一种更复杂的算法,但它通过使用所有可用的闪存延长了存储设备的使用寿命。 垃圾回收是在出于任何原因复制数据时将块标记为 " 脏 " 的过程,而不是简单地直接清除它们。脏块仅在以后某个时间点擦除,例如系统空闲时,但早于当系统将再次需要这些块的的时间。请记住,擦除块是一种缓慢的操作,因此在某些情况下,适当的垃圾回收可以提高性能 图 8 展示了原始 NAND 管理算法如何被视为控制器将物理擦除块( PEB )映射到逻辑擦除块( LEB ),并将特定的 NAND 操作抽象为简单的读取和写入操作: 图 8 :原始 NAND 操作通过控制器抽象。 当原始 NAND 芯片连接到系统,试图实现 " 透明 " 控制器以简单地将 NAND 编程、读取和擦除操作转换到类似 HDD 的读写操作时,它严重影响了闪存的性能和使用寿命。这就是为什么 Linux MTD 子系统几乎总是被基于原始 NAND 特性的文件系统使用,并且可能在这之间还有一层,如 UBI 和 UBIFS 就是一个例子,而不是文件系统直接访问块设备。 如果您想了解有关磨损均衡的更多信息,请查看 Micron 的 TN-29-42 : NAND 闪存设备中的磨损均衡处理技术 ( PDF ) 和 维基百科 上的 " 磨损均衡 " 文章(以及其参考资料,包括一些 LWN.net 文章)。有关垃圾回收,请阅读 Micron 的 TN-2960 :单级单元 NAND 闪存中的垃圾回收 ( PDF )。 要详细了解原始 NAND 设备和应用程序之间抽象层的完整实现,请完整阅读 MTD 、 UBI 和 UBIFS 文档。当然,为了了解实现的细节,您也可以看看 Linux内核源代码 。 尽管原始 NAND 操作非常复杂,为了创建磨损估计模型,我们必须在一定程度上了解这些操作,抽象这种复杂性的简单方法是购买具有集成控制器的 NAND 设备,也称为托管型 NAND 。就集成电路而言,常用类型包括嵌入式 USB 、 eMMC 和 UFS 。在这里,我们将重点讨论 eMMC 。 eMMC 闪存分析 工业级嵌入式系统中最常用的大容量闪存技术之一是 eMMC ( 嵌入式多媒体卡 ),它由原始 NAND (通常是 MLC 或 TLC )及其附带的 NAND 控制器组成。它从底层操作系统中抽象了大部分管理软件堆栈。 eMMC 标准由 JEDEC 维护,在注册后可免费使用。本文撰写时发布的最新标准是 嵌入式多媒体卡电气特性标准 5.1 (注册后下载 PDF )。 由于控制器提供了高质量的抽象层(前提是它来自可靠的制造商)因此,只要采取一些预防措施,就可以安全地使用能够处理块设备操作的文件系统。在 Toradex 嵌入式 Linux BSP 中,对于具有 eMMC 闪存的计算机模块,我们默认使用 EXT4 文件系统。图 9 总结了原始 NAND 和托管型 NAND 在控制器方面的差异: 图 9 :原始 NAND 和 eMMC 控制器 在本文的示例中,我们分析了具有 1024 个块的 4GB MLC eMMC ,在实际情况中,它可以时 Micron 的 MTFC4GAJCN-1M-WT ,这在 Apalis iMX6Q 1GB 最新版本的模块上使用。我们还假设平均块寿命为 3000 次擦除周期,这只是一个根据我们实际经验的猜测。它不是从上述器件的数据表中得到的。 使用 eMMC 的挑战在于收集有关控制器实施和模块生命周期的详细信息,这些细节可能公开提供,也可能不公开。此外,人们可能更喜欢选择提供良好专有健康报告的制造商。 eMMC 标准为此保留一些寄存器,但是否使用它们则是可选的。为案例研究选择的 eMMC 具有详细的健康报告,有关该报告的详细信息可从 Micron 的 TN-FC-32 : e.MMC 设备运行状况报告获取,该报告可在 Micron 网站的 eMMC 软件部分 注册后获得。在 Micron 网站的这一部分中,您还可以找到本文稍后将使用的 emmcparm 工具,以及非常有帮助的 TN-FC-25 :了解 eMMC 的 Linux 驱动程序支持。 命令和寄存器 eMMC 标准通过包含电源、 CMD 、 DAT0-7 和 CLK 信号的总线定义了操作。 CMD 是一个串行通道,不同的 CMD 值表示不同的操作。将命令从主机发送到卡后,将通过同一串行行从卡向主机回复应答。相关数据可通过 DAT 信号线获取问。为了更好的说明,图 10 中提供了多块读取操作的图示。幸运的是,我们将使用的所有工具已经实现并抽象成为了 eMMC 通信。 图 10 :多块读取操作。(资料来源: JEDEC 标准号 84-B51 ,第 5.3.1 节,第 9 页) eMMC 标准还定义了具有不同信息集的寄存器,这些信息又可通过特定的 CMD 命令进行访问。表 2 显示了 eMMC 寄存器: 表 2 : e.MMC 寄存器(资料来源: JEDEC 标准号 84-B51 ,第 5.3 章,第 8 页) Extended Device Specific Data (以前称为 Extended Card Specific Data )是提供运行状况报告的位置。它包含: 供应商专有运行状况报告, 32 字节长 设备寿命估计类型 A ,以 10% 的增量提供运行状况 在我们的 eMMC 上指的是 SLC 块 设备寿命估计类型 B ,以 10% 的增量提供运行状况 在我们的 eMMC 上指的是 MLC 块 EOL 预警信息,按平均预留块来反映设备寿命 返回正常值、警告值(消耗的预留块的 80% )和紧急值(消耗的保留块的 90% ) 一个相关的问题:如果这些信息是现成的,为什么不只使用 JEDEC 标准的数据? 原因之一是健康报告仅从 JEDEC 标准第 5.0 版中引入。 另一个是值的低分辨率( 10% 增量),这对写入少量数据的测试应用程序不利。需要很长的运行时间才能获得任何有用的信息。 此外,提供独立于特定技术(如既能可以时 SD 卡,也可以是采用 MTD 的原始闪存)的闪存磨损估计工具更加灵活。 Micron 专有运行报告 对于本主题,我们(几乎)不在 JEDEC 标准的讨论范围之内。我们需要了解的唯一信息是如何访问此数据。我们只需要知道,我们必须使用一般的命令,即 GEN_CMD 或 CMD56 ,作为入口门,从器件中获取这些数据。 eMMC 规范中特定应用命令部分包含更多详细信息。 我们接下来需要的信息是供应商实现的运行状况报告。在我们的例子中,它包含在 Micron 的 TN-FC-32 : e.MMC 设备运行状况报告中,可在 e.MMC 软件区域中找到。 可获取下面的数据: 坏块计数器和信息 :工厂坏块计数、运行时坏块计数和剩余块计数。这还提供有关每个块上关于失效页地址和是否在擦除或者编程中失效。 块擦除计数器 :所有块的最小、最大和平均块擦除计数,以及每个块擦除计数。 块配置 :每个块的物理地址,以及它是 SLC 还是 MLC 。 要访问其中每个参数,必须由 CMD56 发出特定的参数。 关于在计算机模块在生命期内 eMMC 支持的说明 计算机模块制造商通常有长期供货策略,因为他们的客户可以从中受益,如工业和医疗用户。例如, Toradex 保证超过 10 年的供货。 通常,单个器件的生命周期比整个计算机模块的生命周期短。因此,新版本硬件会随着时间的推移发布,并与产品更改通知 ( PCN ) 进行说明。这是使用计算机模块的主要优势之一 ,它抽象了重新设计的复杂性。 另一方面,您可能会想出一个不符合最新标准的 eMMC 的硬件。这是另一种实际方案,您希望有一个磨损估计解决方案以某种方式脱离特定的技术或标准。 闪存运行状况 在任何给定时间点的闪存运行状况可以理解为已耗尽的容量百分比。为了简单起见,我们将假设在早期阶段没有块磨损,磨损水平是最佳和静态的,并且没有写入放大,即理想的场景。 总使用量可以从擦除总数或可写入设备的数据总量中获得: 或者 这里: E 表示总使用量,以擦除周期数(顶部)或字节数(底部)表示 B 表示块的数量 Lavg 表示块的平均块寿命,以块擦除计数表示 S 块的大小,以字节表示 根据定义,擦除周期的总数更准确,因为块磨损由块擦除引起。因此,前一种方法往往优于后者。 在上面的示例中,一旦将 1536000 次擦除均匀地分布的块上执行,或者将大约 6 TB 的数据写入设备,则其生存期已达到其生存期的 50% 。 在 Linux 上监视闪存运行状况 要 Linux 中监视前几节中讨论的闪存运行状况参数,需要从 eMMC 设备中提取有意义的信息的软件。可达到此目的的开源工具是 mmc-utils 。它实现了大量 eMMC 协议,包括从 Extended Card-Specific Data ( EXT_CSD ) 寄存器读取数据,并以人们可读格式显示数据。它包括 JEDEC eMMC 5.0 标准中定义的器件寿命。让我们通过运行不带任何参数的软件来简要了解一下它,其打印了帮助信息: root@colibri-imx6:~# mmc Usage: mmc extcsd read Print extcsd data from . mmc extcsd dump Print raw extcsd data from . 上面的输出侧重于 extcsd 操作。如果我们执行 extcsd 读取命令,我们可以获取一系列信息,包括 JEDEC 运行状况。让我们看看输出的开头或第一行: root@colibri-imx6-05097264:/app# mmc extcsd read /dev/mmcblk1 ============================================= Extended CSD rev 1.7 (MMC 5.0) ============================================= 这证实了我们有一个符合 JEDEC 5.0 标准的 eMMC 。然后,我们可以筛选输出以获取 JEDEC 定义的运行状况: root@colibri-imx6:~# mmc extcsd read /dev/mmcblk1 | grep LIFE Device life time estimation type B Device life time estimation type A eMMC Life Time Estimation A : 0x01 eMMC Life Time Estimation B : 0x01 root@colibri-imx6-05097264:~# mmc extcsd read /dev/mmcblk1 | grep EOL Pre EOL information eMMC Pre EOL information : 0x01 在上面的示例中,我们看到运行状况估计设备寿命在 0% 到 10% 之间,并且具有正常的 EOL 前的状态。因此,它是一个新的设备。如果我们尝试获取供应商的专有运行状况报告,我们发现它无法通过最新 mmc-utils 获得。甚至稍早的 ChroiumOS 也只显示零: root@colibri-imx6:~# mmc-cos extcsd read /dev/mmcblk1 | grep -i health Vendor proprietary health report: ]: 0x00 ]: 0x00 ]: 0x00 然而,人们总是可以编写一些补丁来尝试扩展该工具的功能。一个可用作测试的示例可能类似于如下代码所示。请注意,为了简洁起见,此代码未完整显示,例如省略验证功能: / Retrieve the erase count for each block // A two-step approach is needed (read number of tables and then read tables) int do_block_erase_info(int nargs, char **argv) { ret = CMD56_data_in(fd, cmd56_how_many_tables, data_in); printf("Block erase count\n"); printf("Block\tErase\n"); for(table_idx = 0; table_idx < how_many_tables; table_idx++){ ret = CMD56_data_in(fd, (table_idx * 256) + cmd56_retrieve_base, data_in); for(physical_block = 0; physical_block < 128; physical_block++){ printf("%d\t%d\n", (256*data_in ) + data_in , (256*data_in ) + data_in ); } } } 然后,我们可以用这个应用程序,从 Micron 的闪存中检索以下数据: int do_bad_block_count(int nargs, char **argv); int do_bad_block_info(int nargs, char **argv); int do_block_erase_count(int nargs, char **argv); int do_block_erase_info(int nargs, char **argv); int do_block_addr_type_info(int nargs, char **argv); 另一种选择是使用供应商的特定工具,如 Micron 的 emmcparm ,该工具不仅提供 JEDEC 的综合寿命报告,而且还提供上面列出的和在实际使用中举例说明的更详细的参数。 在撰写本文时( 2019 年 8 月), emmcparm 自 2016 年 5 月 27 日发布版本 2.6.0 以来到 2019 年 6 月 5 日发布的 4.4.0 版本期间有不定期的更新。该工具具有多种功能,其中运行状况为一个: root@colibri-imx6:~# emmcparm_arm --spare_block --bad_block --erase_count --sect_count I/O 跟踪 I/O 跟踪可以是一个有用的指示器,表明闪存在迅速耗尽,也可以是一个调试指示器,用于显示哪些应用程序正在写入过多的数据。 I/O 跟踪为不依赖于 JEDEC 标准或 eMMC 供应商运行状况报告的磨损估计模型提供输入数据。因此,它是实现一种灵活的工具的想法,可以扩展到所有各类使用原始 NAND 作为存储的技术。 实现可靠的 I/O 跟踪机制的第一步是掌握一些关于 Linux I/O 堆栈工作原理的基本知识。在非常高的层面上,通常在应用程序开发期间发生的情况是编写一些用户空间代码,并执行文件操作。 操作的完成方式可能因您使用的库和语言而异,但在某些时候,会从用户空间过渡到内核空间。此时库的函数会对内核进行系统调用。除了使用经过良好测试的成熟库(如 C 标准库),您也可以自行进行系统调用,但代价是需要实现抽象,并容易出错。 然后, Linux 内核通过通常称为 I/O 堆栈或存储堆栈来处理该 I/O 。作为最后一步,它通过低级设备驱动程序将数据发送到设备,在使用 eMMC 的情况下,该驱动程序必须符合 JEDEC 标准。图 11 在尽可能的最高层面上,标识了原始 NAND 和 eMMC 设备的堆栈 图 11 : eMMC 和原始 NAND 的 I/O 堆栈 我们可以从上到下浏览内核堆栈: 图 12 : Linux 内核结构的简化概述。(来源: 维基百科 ) virtual file system 是用户空间 API 的抽象层。 file system 本身实现特定结构来定义与文件相关的概念。 generic block layer ,通常包括文献中的 I/O scheduler ,是堆栈中处理所有块 I/O ( BIO ) 的地方,此抽象文件系统的块设备等。 I/O scheduler 获取 I/O 请求的队列,并根据特定算法将它们发送到块设备驱动程序。它尝试最大化块 I/O 性能, scheduler 的选择计可能会影响闪存的延迟、吞吐量和使用。 人们最初可能认为,观察随时间而写入闪存的次数,以获得写入速率,是能够可以从用户空间完成,并且这就足够了。然而,这种方法最大的问题是,它不能获得精确的测量。 如图 13 所示, Linux 内核是一个复杂的系统,它通过其堆栈实现缓存层,以防止不需要的磁盘访问。这是一个顾虑,因为磁盘操作总是很慢;即使闪存的出现,并且其有更快的操作速度,现在也需要延长存储设备的生命周期,这些缓存和队列对此有所帮助: 图 13 :缓存、缓冲区、队列和同步。 Linux 内核实现了一个称为页缓存的缓存,该缓存位于高层 VFS 和低层文件系统之间。它是内核最受欢迎的缓存系统。它使数据可供用户空间应用程序可靠使用,而无需通过文件系统。 进一步深入 I/O 堆栈,由于 I/O 合并,优化存储硬件,以及通常以吞吐量为目标的 I/O 队列的使用,可能会产生缓存副作用。作为合并 I/O 的示例,有一种回写机制,该机制将数据保留到必需写为止,从而防止碎片化以及使用零碎数页或块。这些机制也使得很难跟踪特定进程实际上写到闪存的数量。 作为数据同步的附带说明,对于嵌入式系统应用(尤其是没有备用电源)可能至关重要,并且可能会影响闪存寿命。因此,要注意只有在绝对必要才保存数据,即使在意外断电的情况下。用户按机器触摸屏面板上的 " 保存 " 按键就是此类应用的一个示例。 测量 I/O 写入 从我们对所有实际到达闪存的写入进行监视和核算的角度来看,问题变得更加明确: 在 Linux 堆栈的哪些位置,我们保证能够测量实际到达闪存的写入量 我们如何测量这一点?(我们可以使用哪些工具?) 不同于运行状况测量(可用于收集数据的工具数量有限),可用于 Linux 内核堆栈观察的工具是非常丰富的。图 14 显示了这方面的一个示例,取自 Brendan Gregg 的博客。 Brendan Gregg 是 Linux 性能监控领域知识最渊博的一个人。 图 14 : Linux 性能观察性工具。(来源: Brendan Greg ) 在我的研究过程中,我使用了 iotop 来跟踪用户空间操作,和 blktrace/blkparse 来准确跟踪块级 I/O 和实际到达闪存的内容。由于我不是内核黑客,这个主题仍有很大的研究空间,所以我不会以任何方式暗示这些是最适合或最优化的工具。例如, perf 跟踪和 eBPF 也在我的待办事项列表中。有一篇关于 Linux块I/O跟踪 的有趣文章,以及互联网上的许多其他资源,包括 Linux内核文档 本身。 在块级别跟踪 I/O 的重要意义在于准确性,因为这是确保写入操作实际到达闪存的唯一途径,而不是从缓存中刷新或由内核中的后续文件系统操作合并。这一点很重要,因为真正需要统计的是块写入的次数(实际上是擦除),而不仅仅是应用程序尝试写入的实际数据量。 让我们在实践中简要地了解一下如何使用 iotop 和 blktrace 。 iotop 有一些选项可以很方便地帮助完成此任务,并且很容易收集和分析时间戳、写入计数以及负责这些写入的进程: root@colibri-imx6:~# iotop –help Options: -o, --only only show processes or threads actually doing I/O -b, --batch non-interactive mode -a, --accumulated show accumulated I/O instead of bandwidth -k, --kilobytes use kilobytes instead of a human friendly unit -t, --time add a timestamp on each line (implies –batch) -q, --quiet suppress some lines of header (implies --batch) 你可以参考下面的示例: testfile root@colibri-imx6:~# iotop --only --batch --accumulated --kilobytes --time –quiet TIME TID PRIO USER DISK READ DISK WRITE SWAPIN IO COMMAND 2019-08-02 03:11:19 50 be/4 root 0.00 K 24.00 K -0.00 % -0.00 % pv -L 25k 2019-08-02 03:11:20 50 be/4 root 0.00 K 52.00 K -0.00 % -0.00 % pv -L 25k 2019-08-02 03:11:21 50 be/4 root 0.00 K 80.00 K -0.00 % -0.00 % pv -L 25k 2019-08-02 03:11:22 50 be/4 root 0.00 K 104.00 K -0.00 % -0.00 % pv -L 25k 2019-08-02 03:11:23 50 be/4 root 0.00 K 128.00 K -0.00 % -0.00 % pv -L 25k 当使用 blktrace 时,事情变得有点复杂。文档是开始查阅的好地方。在没有过滤的情况下,以实时模式下运行,它可以呈现大量的输出: root@colibri-imx6:~# blktrace -o - /dev/mmcblk1 | blkparse -i - 179,0 0 26 0.000114661 304 A WS 4509800 + 8 <- (179,2) 4468840 179,0 0 27 0.000117328 304 Q WS 4509800 + 8 179,0 0 28 0.000119661 304 M WS 4509800 + 8 179,0 0 29 0.000127328 304 U N 1 179,0 0 30 0.000131661 304 I WS 4509736 + 72 179,0 0 31 0.008860277 279 D WS 4509736 + 72 179,0 0 32 0.012586780 279 C WS 4509736 + 72 幸运的是,在 blktrace 和 blkparse 中实现了诸多筛选器来简化任务。表 3 列出了它们,并简要说明: 表 3 :过滤掩码(来源: blktrace 手册) 为了跟踪最后一刻用户空间 PID 信息和在闪存上发出的确认写入操作,我们将会使用 write 过滤器。在 blkparse 端,进一步筛选选择以下跟踪操作,这些跟踪操作从 blkparse 文档中引用: C - 完成:上一个发出的请求已完成。输出将详细说明该请求的扇区和大小,以及请求的成败。 I - 插入:请求正在被发送到 io 调度器,从而添加到内部列队并稍后由驱动完成。此时请求已完全形成。 寿命估算 通过记录 I/O 跟踪和闪存运行状况,可以确定两个相关性: 随时间推移的闪存运行状况 在写入率方面的闪存运行状况 请注意,这两种相关性都会随时间而发生,因此通过在单独的存储介质上实现本地 DB (或相同的介质,但考虑其对闪存磨损的影响)并运行系统足够长的时间,可以收集足够的数据估计上述相关性,然后计算寿命。 以擦除次数测量的总使用量: 以字节或者多个字节测量的总使用量: 这里: L 是秒为单位的寿命 E 是以擦除次数(顶部)或字节(底部)表示的总使用量 Cavg 是平均所有块擦除计数 ; 即块擦除总数除以每秒擦除的块 Wavg 是调整后的平均写入速率(以每秒字节为单位) 请注意,在第二个公式中,调整后的平均写入速率是运行闪存运行状态后的写入速率,包括相关的写入也统计在内。因此,在实践中,这考虑到诸如写入放大和系统写入等因素,这些在应用程序角度进行监视或估计理论值时不会被考虑的。 关于磨损估计的备注 温度会影响闪存寿命。您必须考虑使用 pSLC 模式(如果可用)、使用静态与动态磨损均衡、存在的坏块、设备接近 EOL 时会发生什么情况以及存在备用块等可能性。 记得通过文献来寻找与您的设计模型相关的注意事项和其他的方面。 闪存分析工具 Toradex 实验室目前正在开发闪存分析工具,旨在您的设备上抽象估算 eMMC 设备上磨损的所有复杂性。在本文中,我们一直在介绍此任务的原则、注意事项、案例和复杂性。现在,可能很清楚为什么这是一个复杂的任务,应用程序开发人员可能宁愿选择避免。 图 15 :闪存分析工具 如上图 15 所示,该工具旨在成为全面的辅助工具,而不仅仅是一个寿命估计工具。它被设计利用 Torizon 平台的 Docker 容器运行并作为模块化解决方案,您可以在核心模块的 BSP 上选择要使用的内容。 由于当前预测模型是使用线性回归方法实现的,因此,该工具的路线图包括对解决方案的深入研究,以创建具有更高准确性的新模型,支持更多用例。我们能够预见到基于 AI 和大数据的解决方案的可能性。 上面展示了 UI 的外观,我邀请您 率先测试下 ,并告诉我们您对此的看法。 总结 估计闪存寿命可以像从闪存运行状况中给出的块大小公式计算一样简单,也可以像开发工具并生成在数秒内估计设备寿命所需的模型一样复杂。您可以根据产品的使用场景来选择投入多少精力,或仅选择图 16 中概述的重要元素。无论如何,这是宝贵的信息。 图 16 :估计和预测原始 NAND 寿命。 与更简单的计算相比,复杂的方法提供了一些好处。除了更精确的结果外,您还可以将您工具某个版本部署到生产中,以获得更精确的生命周期数据。这还为您提供了监控功能和触发警报的能力,从而进行更具预测性的维护。最后,一系列底层和高层面的工具,包括 Micron 的 emmcparm 、 mmc-utils 和 Toradex 闪存分析工具,都可以让您轻松创建可靠的解决方案。我希望您在阅读这个博客文章时有一个愉快的经历。
  • 热度 7
    2013-11-29 13:59
    422 次阅读|
    0 个评论
    所谓多 CE 片选(Chip Enable 或 Chip Select), 亦即一颗芯片包装内, 集成了多颗 芯片的概念, 除了 CE与 Busy/Ready 以外的脚位都是共享的.   这样的设计, 因为类似一次用很多颗芯片, 使得总存储空间就可以变大, 脚位也不会增加太多. 大部分的情况下, 不同的 CE 间并不会同时被开启, 如同交通号志一样, 东西向绿灯时, 南北向就红灯. 这样十字路口这个共享区就不会发生撞车的情形.   少数情况, 所有 CE 会同时开启. 例如, 同一个时间要对所有的 CE 下复位(Reset), 或者同时写入一个完全相同的测试资料时, CE 就可以同时进开启, 反而这样的应用可以增进效率.   不管上述哪一种情况, 一个测量 NAND Flash 的人, 总是会需要看到芯片上每个 CE 开启之后的行为. 所以, NAND Flash 总线分析必须支持此类多 CE 的芯片. 否则无法完整检视这类的 NAND Flash.     深圳市千兆科科技有限公司 0755-23062736 www.giga-science.com
  • 热度 14
    2012-11-19 17:58
    1108 次阅读|
    4 个评论
           今天看了一个朋友的博客,他写的真的太好了,做销售这么久,第一次看到销售可以把芯片分析的那么的专业,真的是很佩服很佩服,为了增长自己的知识,我也顺藤摸瓜式的对我司代理的韩国ATO的nand flash做一个分析,分析不知道是对,但是,只是个人的理解,希望懂的多多提议,有意见交流可以联系Dora 15817241821  (QQ :2541344368),欢迎大家一起交流探讨。    Nand Flash,是FLASH的一种,另一种常见的就是NOR FLASH,NOR和NAND是现在市场上两种主要的非易失闪存技术,它相当于PC机的硬盘,用于保存系统运行所必需的操作系统、应用程序、用户数据、运行过程中产生的各类数据。NOR闪存更适合用来存储少量的代码并且需要多次擦写   ,而NAND则是高数据存储密度的理想解决方案 . Flash掉电后,数据仍可以永久保存。     一、NAND FLASH介绍     AND Flash 的数据是以bit的方式保存在memory cell,一般来说,一个cell 中只能存储一个bit。这些cell 以8个或者16个为单位,连成bit line,形成所谓的byte(x8)/word(x16),这就是NAND Device的位宽。这些Line会再组成Page,(NAND Flash 有多种结构,我司代理的是韩国ATO 公司的NAND Flash产品,因此以NAND FLASH 256Mb 3V的AFND5608U1,来做一解释,这款产品跟三星之前的同容量的一块是兼容的,因三星停产,所以,ATO才大量生产,希望可以满足市场需求。       且看NAND 256Mb的物理结构: 该芯片为      48引脚,有三种封装,其外围引脚较少,这样就方便和FLASH 硬件连接,即方便设计电路,又可以减少占用总线资源。具体的引脚见手册的第8页,在此我就不列出了。      下面是芯片的功能结构图: l  X-Buffers Latches  Decoders:用于产生行地址; l  Y-Buffers Latches  Decoders:用于产生列地址; l  Command Register:用于命令字的操作; l  Control Logic  High Voltage Generator:控制逻辑及产生Flash所需的高压; l  Nand Flash Array:存储部件; l  Page Register  S/A :页寄存器,当读、写页时,会将数据先读入或写入此寄存器,大小为528Bytes。 下图为NAND FLASH 256Mb的存储单元组织结构图:       容量为256Mb.     命令、地址、数据都通过8个I/O口输入/输出,这种形式减少了芯片的引脚个数,并使得系统很容易升级到更大的容量,写入命令、地址或数据时,都需要将WE#、CE#信号同时拉低。数据在WE#信号的上升沿被锁存,其中CLE为命令锁存信号、ALE为地址锁存信号。整个芯片为(256+8)Mb,因此,需要25根地址线来寻址,这样,如果我们以字节为单位发出寻址信号,总共需要3个周期,其中1周期列地址信号,1周期的行地址信号。见下图。   2、操作命令字介绍 操作NAND FLASH时,先传输命令,接着输出地址,最后读/写数据,期间还要检查FLASH的状态。具体的命令字见下表。       朋友们,今天先写到这,今后接着解析。 
  • 热度 8
    2012-10-30 16:19
    596 次阅读|
    0 个评论
    一、NAND Flash上半年整体行情低迷     (一)上半年整体处于去库存状态     在2010年强劲市场需求下,各NAND FLASH芯片生产厂商在2011年极大的扩大产能。据了解,2011年8月三星多条产线投入生产,将每月的产能提升至20万片以上,东芝、sandisk合资的12寸Fab5新厂产能也达到20万片;英特尔与美光合资IMFT厂产能10万片,海力士M11厂每月产能12万。大量的NAND Falsh芯片在2011年底涌现,导致市场供过于求,市场库存处于高位。因此,在2012年上半年原厂厂商、分销商、终端厂商库存持续走高,下游供应商只好调低价格冲销量,降低库存。     (二)上半年整体表现比较低迷     债危机影响不断扩大,宏观环境不景气,以及投资者信心不足导致以往应用产品需求成长缓慢,新起需求成长有限,使得2012年上半年NAND Flash市场需求增长力不足,市场淡季气氛浓烈。首先表现在:原产品需求成长缓慢,比如NAND FLASH产品大量运用于手机上,但从手机的实际出货量上看,全球手机出货量成负增长,低于市场普遍预期,重要的增长引擎智能手机出货量也不太理想,市场增速开始变得缓慢。其次新起需求成长有限。2012年各储存厂商看好平板电脑的市场需求,如微软、谷歌、亚马逊、宏基、华硕、惠普等纷纷加入平板电脑市场,市场销量也呈现大幅上涨。但从市场份额上看:ipad平板电脑一直处于市场垄断地位,2012年第一季度市场份额占65%,第二季度占68%,随后各分析机构又纷纷下调了IPAD的出货量,由此可知IPAD市场需求不如预期,带动整体平板电脑的需求减缓。另外,一直寄希望于win8能带动市场需求起来,可由于win8触摸功能支持成本及操作系统本身成本过高,使得新生买手受挫,需求减少。     (三)市场供过于求价格下降     由华强北价格指数数据显示:2011年第四季度至2012年第三季度指数收报点分别为90.81、89.54、90.57和90.46,较2010年及2011年上半年价格指数有明显的下滑,储存器价格整体处于低位徘徊。 储存器价格指数季度走势趋势,数据来源:华强北指数( www.hcsindex.org )       二、储存厂企业并购加大市场的集中度     2012年储存厂还出现了一系列的并购案以提高市场的竞争力,加大了储存器的市场集中度,对储存器的产能和市场价格具有更大的调节力度。其中美光收购尔必达最为关注,利用自己的主力产品NAND Flash与尔必达的Mobile DRAM联合,强化在智能手机领域的业务,海力士收购Ideaflash成立意大利研发中心,同时也撤资2.48亿收购美光数据储存控制芯片技术领导厂商LAMD来提高NAND flash市场控制芯片技术,希捷与DensBits达成战略合作关系,金士顿入股品安等。      三、第三季度NAND Flash市场价格有所回升     第三季度是电子元器件销售的传统旺季,市场需求客观上升以及心理预期上升的双重影响下,拉动市场价格上涨。由华强北价格指数数据显示:2012年9月,储存器的价格指数为91.28,较上一上升1.03点,是2012年单月上升幅度较大的一个月。   2012年储存器价格指数月走势趋势,数据来源:华强北指数( www.hcsindex.org )       其价格上升的主要原因有:①原厂厂商调整储存器产出,促使市场供求关系回归合理水平,如三星、东芝和美等纷纷减产和市场供应量,尤其是不买wafer给中国渠道商,担心其低价出售破坏市场价格空间,东芝坚守价格策略,旗下所有产品线涨价。据消息称:三星16产线暂缓投资,并把部分NAND Flash的产线转换成非储存器产线;东芝不仅减缓Fab5二期工程建设,同时宣布7月份建成三成;海力士将韩国的M12产线改为DRAM与NAND Flash混合产线,减少NAND Flash产出。②行业周期影响,市场需求的客观上升和心理预期上升双重影响,拉动市场价格上涨。如深圳市中意法电子科技有限公司总经理朱军山博士说:“从员工的接单情况上看,这两个月的接单数量有所增加”;深圳市创威科技有限公司采购人员lisa也提到她们公司这两个月采购量也在加大,但国外的需求没有明显上升。③***事件影响中日关系,日系产品清关延误。自日本宣布***“国有化”之时,中日关系影响了两国的经贸合作,进口日系品牌受阻。而日本又是中国电子元器件的进口大国,东芝是NAND Flash的第一厂商,因此很大程度上影响了市场的交易价格。      第四季度NAND Flash观察     从市场需求的角度上看:NAND Flash市场需求在第四季度看好。主要理由是①宏观经济趋于乐观,9月份中国制造业PMI指数为49.8%,环比上升0.6%;美国制造业采购经指数从8月份的49.6%上升至51.5%,欧元区制造业PMI为46.1%,环比上升1.0%。②行业周期和季节性因素作用下,第四季度是电子元器件的传统销售旺季;③伴随着智能手机、平板电脑、超级本等时尚消费类电子的发力,NAND Flash的市场需求增加;④国家政策扶持,9月18日,科技部同时发布“宽带网络科技”、“云科技”、“导航与位置服务科技”三大信息产业“十二五”专项发展规划,以促进电子信息产业的发展,从而带动NAND FLASH的需求。
相关资源
  • 所需E币: 5
    时间: 2021-4-14 23:02
    大小: 194.85KB
    上传者: stanleylo2001
    第六章NandFLash控制器s3c2440a_6NandFlash.pdf
  • 所需E币: 0
    时间: 2021-3-25 18:09
    大小: 171.89KB
    上传者: Argent
    全志方案在消费类电子占有很大的市场,随着产品的不断升级优化,全志方案不仅仅在安卓平板,视频监控、广告应用等领域崭露头角,本人收集些有关全志方案的开发资料,希望对正在使用全志方案的网友有所帮助。
  • 所需E币: 0
    时间: 2021-3-26 00:11
    大小: 474.21KB
    上传者: Argent
    全志方案在消费类电子占有很大的市场,随着产品的不断升级优化,全志方案不仅仅在安卓平板,视频监控、广告应用等领域崭露头角,本人收集些有关全志方案的开发资料,希望对正在使用全志方案的网友有所帮助。
  • 所需E币: 1
    时间: 2021-3-22 18:23
    大小: 424.96KB
    上传者: Goodluck2020
    Winbond_嵌入式系统开发商采用SerialNANDFlash做为AI系统储存内存的优势
  • 所需E币: 0
    时间: 2021-3-17 22:24
    大小: 1.03MB
    上传者: xgp416
    基于自主CPU的NAND启动的实现
  • 所需E币: 0
    时间: 2021-3-15 21:02
    大小: 43.3KB
    上传者: Goodluck2020
    S3C2410X的NANDflash启动.
  • 所需E币: 0
    时间: 2020-12-18 23:09
    大小: 13.81KB
    上传者: samewell
    NOR和NANDFlash存储器的区别
  • 所需E币: 0
    时间: 2020-12-18 23:14
    大小: 11.28KB
    上传者: samewell
    Nor与NandFlash区别
  • 所需E币: 0
    时间: 2020-12-10 22:39
    大小: 1.25MB
    上传者: LGWU1995
    基于自主CPU的NAND启动的实现
  • 所需E币: 4
    时间: 2020-11-17 22:12
    大小: 5.19MB
    上传者: xgp416
    深入研究NANDFlash控制器资源大小:5.19MB[摘要]移动电话的功能日益丰富,其对系统中数据存储容量的需求正在快速增长。NANDFlash具有速度快、密度大、成本低等特点,在各种数码产品中得到了广泛应用,在各种片上系统芯片中(SOC)集成NANDFlash控制器正成为一种趋势。本文讨论了FlashMemory的两种主流实现技术即NAN
  • 所需E币: 0
    时间: 2020-11-4 22:34
    大小: 385.46KB
    上传者: samewell
    Winbond_嵌入式系统开发商采用SerialNANDFlash做为AI系统储存内存的优势
  • 所需E币: 0
    时间: 2020-9-21 19:08
    大小: 385.46KB
    上传者: LGWU1995
    Winbond_嵌入式系统开发商采用SerialNANDFlash做为AI系统储存内存的优势
  • 所需E币: 0
    时间: 2020-9-9 23:38
    大小: 16.27KB
    上传者: samewell
    NOR和NANDFlash存储器的区别
  • 所需E币: 0
    时间: 2020-9-10 02:18
    大小: 13.77KB
    上传者: Goodluck2020
    Nor与NandFlash区别.docx
  • 所需E币: 0
    时间: 2020-8-26 16:50
    大小: 1.17MB
    上传者: 指的是在下
    MLC型NAND闪存中Polar码的优化设计
  • 所需E币: 3
    时间: 2019-12-26 01:43
    大小: 44.4KB
    上传者: 2iot
    NANDFLASH驱动在WINCE下的应用……
  • 所需E币: 5
    时间: 2019-12-25 17:28
    大小: 194.27KB
    上传者: rdg1993
    在便携式电子产品如U盘、MP3播放器、数码相机中,常常需要大容量、高密度的存储器,而在各种存储器中,NANDFLASH以价格低、密度高、效率高等优势成为最理想的器件。……
  • 所需E币: 5
    时间: 2019-12-25 16:36
    大小: 1.09MB
    上传者: 978461154_qq
    linux系统移植开发文档Linux系统移植目录第一部分前言....................................................................................................................................81硬件环境......................................................................................................................................81.1主机硬件环境.......................................................................................................................81.2目标板硬件环境...................................................................................................................81.3工具介绍...............................................................................................……
  • 所需E币: 3
    时间: 2019-12-25 15:37
    大小: 383.07KB
    上传者: rdg1993
    针对远程心电实时监护的特殊要求设计的监护仪软件系统,实现了心电实时监护、医嘱短信收发、监护状态显示、紧急求救报警等功能.基于GPRS的远程心电实时监护仪软件系统设计李继明,张跃,陈可(清华大学深圳研究生院,广东深圳518055)摘要:针对远程心电实时监护的特殊要求设计的监护仪软件系统,实现了心电实时监护、医嘱短信收发、监护状态显示、紧急求救报警等功能。关键词:心电监护NANDnash地址映射模型GPRS短消息当今社会,心脏疾病已严重影响了人们的生命安频率对患者心电信号采样,并把心电数据通过GSM/全,许多突发患者因得不到及时救治而使生命受到威GPRS网络发送给监护服务器,数据的实时性由监护服胁。传统的心电监护设备限制了患者的自由,动态心电务器和监护仪之间的控制信息控制。PDA接收来自监护记录仪(Holter)虽能便携地记录患者日常活动时的心电服务器的数据,并根据心电分析的结果通过数据服务数据,但是没有实时监护功能,对于危及生命的突发心(GPRS数据服务)和短消息(SMS)通知监护仪。监护服脏病变帮助不大。务器负责接收转存病人端全部心电数据,实时分析及回无线通信技术的日渐成熟使便携式心电实时监护成放分析;同时向PDA转发实时心电数据,利用控制信息为可能。利用GPRS无线数据通信技术,可将实时监护功来协调实时心电数据的收发。心电数据服务器存储所有能与Holter结合起来。患者可以配戴监护仪自由活动,同心电数据、患者信……
  • 所需E币: 4
    时间: 2019-12-25 15:09
    大小: 286.09KB
    上传者: rdg1993
    常规的嵌入式系统开发过程中,软件的开发和测试都是在目标硬件平台初步开发完成后进行的.RealviewMDK的出现,可以使嵌入式系统的软硬件协同开发、同步进行.为了使RealviewMDK的软件仿真器尽可能地接近真实的硬件环境,必须对其进行严格的测试.本文以S3C2410软件仿真器的PWM接口模块和NANDFlash接口模块为例,深入地探讨其测试技术.……
广告