- 博客(58)
- 收藏
- 关注
RSS订阅原创 ARM 链接文件.sct【Image$$＜Region_Name＞$$＜Base/Limit＞】
在嵌入式系统中，符号 和 是由链接器自动生成的关键地址标识符，用于精确访问和管理特定内存区域的起始与结束地址。以下是其详细解析和应用总结：命名规则： 表示内存区域 起始地址， 表示内存区域 结束地址的下一个字节。 其中 是链接脚本中定义的内存区域名称（如 ）。生成来源： 由 ARM 链接器（如 ）在链接过程中根据 分散加载文件（ 文件） 自动生成。GCC 链接器（ 文件）则使用类似 和 的符号。内存区域定位： 提供代码中直接访问特定内存区域的物理地址，无需硬编码地址值，增强可移植性和灵活
2025-03-22 11:33:56
916
原创 CmBacktrace的cmb_cfg.h
核心目标：通过合理配置，使 CmBacktrace 库适配目标硬件和操作系统，实现故障诊断功能。关键配置：打印输出适配硬件。CPU 和 OS 类型的正确声明。按需启用堆栈转储和语言支持。调试建议：结合 HardFault 异常处理，利用库输出的信息分析崩溃原因（如非法内存访问、栈溢出）。通过此配置文件，开发者可以灵活地将 CmBacktrace 集成到不同嵌入式平台中，显著提升系统调试效率。
2025-03-16 12:48:03
325
原创 FATFS学习（3.3）：ff.c（f_write）
函数，FATFS 实现了高效可靠的文件写入机制，兼顾性能与资源效率，满足嵌入式系统对存储操作的严苛要求。在部分写入场景下，若目标扇区不在缓存中，需先读取原扇区内容，避免覆盖未修改数据。对小数据或非对齐写入，先写入文件对象或全局缓存，延迟写回磁盘，减少碎片化操作。：动态扩展文件簇链（分配新簇），处理大文件和跨簇写入。：当剩余数据超过扇区大小时，直接写入连续扇区。：若为部分扇区写入，标记缓存为脏，延迟写回。：直接写入新簇的连续扇区，更新文件大小。：剩余数据写入新簇的扇区，更新。：写入部分数据至当前簇末尾。
2025-03-13 21:59:51
880
原创 FATFS学习（3.2）：ff.c（f_open）
例如，`DIR dj` 用于目录操作，`FATFS *fs` 指向文件系统对象，还有一些条件编译的宏（如 `FF_FS_READONLY`、`FF_FS_EXFAT` 等），这些宏会影响代码的编译路径，需要特别注意。在分析过程中，可能会遇到一些不熟悉的函数或宏，例如 `DEF_NAMBUF`、`INIT_NAMBUF`、`FREE_NAMBUF`，这些可能与长文件名支持相关，需要结合FATFS的文档或源码其他部分来理解其作用。这里会根据访问模式 `mode` 进行相应的挂载操作，可能涉及权限检查。
2025-03-13 09:53:11
846
原创 CmBacktrace的学习跟移植思路
CmBacktrace是针对ARM Cortex-M系列MCU的错误追踪库，支持自动诊断HardFault、Bus Fault等异常原因，并输出函数调用栈信息，帮助快速定位代码错误。核心功能包括：故障寄存器解析、堆栈回溯、多语言错误信息输出、支持裸机和RTOS（如FreeRTOS、RT-Thread）。熟悉IDE（如Keil、GCC）的调试配置和链接脚本（Linker Script）的修改方法。学习HardFault等异常的触发条件及寄存器（如SCB->CFSR、LR、PC）的作用。
2025-03-09 14:27:15
614
原创 FATFS学习（3.4）：ff.c（f_read）
在分析过程中，需要注意FATFS的条件编译选项，如FF_USE_FASTSEEK、FF_FS_READONLY、FF_FS_TINY等，这些宏定义会影响代码的执行路径。可能遇到的疑问点包括：簇和扇区的转换逻辑、快速查找（CLMT）的实现细节、缓存脏数据的处理流程，以及不同配置（如Tiny模式）对缓存管理的影响。然后，处理部分扇区数据的读取。通过这样的逐步分析，可以深入理解`f_read`函数的实现机制，掌握FATFS库在嵌入式系统中高效读取文件数据的方法，以及如何处理各种边界条件和错误情况。
2025-03-05 15:37:17
833
原创 FATFS学习（2.4）：ff.h
直接转发数据流 | 避免中间缓冲，适合内存受限系统 | 网络数据传输到文件 || 立即写入缓存数据 | 确保关键数据落盘（如断电前调用） | 实时数据保护 |: 分配模式（立即填充0或延迟分配） | 视频录制预分配大文件 || 预分配连续空间 |
2025-02-24 10:08:03
905
原创 FATFS学习（2.3）：ff.h
MKFS_PARM是一个高度面向文件系统底层细节的结构体，通过精确控制格式化参数，开发者可以适配不同硬件特性和应用需求。其设计体现了对 FAT 家族文件系统的历史兼容性和现代存储需求的平衡。在实际使用中，需结合具体文件系统规范和硬件特性选择参数。
2025-02-24 09:33:41
837
原创 FATFS学习（2.2）：ff.h
是 FatFs 库中用于管理文件或目录对象的元数据结构体，记录对象在文件系统中的存储位置、状态、属性及并发控制信息。其成员变量根据配置选项（如。
2025-02-18 20:57:03
980
原创 FATFS学习（1）：ffconf.h
FF_LBA64 用于控制是否支持 64 位 LBA，以访问大于 2 TB 的存储设备。启用 64 位 LBA 需同时启用 exFAT 文件系统（FF_FS_EXFAT == 1）。底层驱动需支持 64 位地址操作，确保功能正常。
2025-02-13 21:00:16
1046
原创 Service框架设计
背景随着 IOT 设备的快速发展，用户对于高效，安全，可扩展的服务框架需求越来越强烈，Service 技术框架应运而生，Service 技术框架是一种基于服务架构，它将应用程序划分为服务，这些服务可以用过设备环境网络通信并组合在一起形成应用程序，Service 技术框架可以提供多种服务，例如数据访问服务，安全服务，剥离数据显示交互，实现 MVC 或 MVVM 的技术基础。MVC是一种久经考验的经典架构模式，专为用户界面设计与构建而生，旨在实现各组件间的低耦合度。
2024-11-29 09:56:55
1082
原创 lvgl: 示例--样式（1）
注： /*Shift the gradient to the bottom*/开始渐变的位置在128，在192的位置结束渐变。
2024-11-13 13:40:00
575
原创 lvgl:简介（1）
LVGL(轻量级和通用图形库)是一个免费和开源的图形库，它提供了创建嵌入式GUI所需的一切，具有易于使用的图形元素，美丽的视觉效果和低内存占用。
2024-11-05 21:28:03
804
原创 lvgl 模拟器移植（V9）
github链接：GitHub - lvgl/lv_port_pc_visual_studio: Visual Studio projects for LVGL embedded graphics library. Recommended on Windows. Linux support with Wayland is work in progress.https://github.com/lvgl/lv_port_pc_visual_studio 一步到位下载主仓代码跟所有子模块：
2024-10-30 15:46:31
736
原创 代码整洁之道(第5章节)--格式
当有人查看底层代码实现时，我们希望他们为其整洁、一致及所感知到的对细节的关注而震惊。我们希望他们高高扬起眉毛，一路看下去。我们希望他们感受到那些为之劳作的专业人士们。但若他们看到的只是一堆像是由酒醉的水手写出的鬼画符，那他们多半会得出结论，认为项目其他任何部分也同样对细节漠不关心。你应该保持良好的代码格式。你应该选用一套管理代码格式的简单规则，然后贯彻这些规则。如果你在团队中工作，则团队应该一致同意采用一套简单的格式规则，所有成员都要遵从。使用能帮你应用这些格式规则的自动化工具会很有帮助。
2024-10-26 11:23:29
990
原创 代码整洁之道(第3章节)--注释
别给糟糕的代码加注释一重新写吧。什么也比不上放置良好的注释来得有用。什么也不会比乱七八糟的注释更有本事搞乱一个模块。什么也不会比陈旧、提供错误信息的注释更有破坏性。注释并不像辛德勒的名单。它们并不“纯然地好”。实际上，注释最多也就是一种必须的恶。若编程语言足够有表达力，或者我们长于用这些语言来表达意图，就不那么需要注释一也许根本不需要。
2024-10-22 09:32:34
935
原创 代码整洁之道(第3章节)--函数
函数的第一规则是要短小。第二条规则是还要更短小。我无法证明这个断言。我给不出任何证实了小函数更好的研究结果。我能说的是，近40年来，我写过各种不同大小的函数。我写过令人憎恶的长达3000行的厌物，也写过许多100行到300行的函数，我还写过20行到30行的。经过漫长的试错，经验告诉我，函数就该小。在20世纪80年代，我们常说函数不该长于一屏。当然，说这话的时候，VT100屏幕只有24行、80列，而编辑器就得先占去4行空间放菜单。
2024-09-05 20:08:51
665
原创 代码整洁之道(第2章节)--有意义的命名
软件中随处可见命名。我们给变量、函数、参数、类和封包命名。我们给源代码及源代码所在目录命名。我们给jar文件、war文件和ear文件命名。我们命名、命名，不断命名。既然有这么多命名要做，不妨做好它。下文列出了取个好名字的几条简单规则。取好名字最难的地方在于需要良好的描述技巧和共有文化背景。与其说这是一种技术、商业或管理问题，还不如说是一种教学问题。其结果是，这个领域内的许多人都没能学会做得很好。我们有时会怕其他开发者反对重命名。如果讨论一下就知道，如果名称改得更好，那大家真的会感激你。
2024-08-26 09:32:07
935
原创 代码整洁之道(第1章节)--整洁代码
优雅和高效的代码。代码逻辑应当直截了当，叫缺陷难以隐：尽量减少依赖关系，使之便于维护：依据某种分层战略完善错误处理代码；性能调至最优，省得引诱别人做没规矩的优化，搞出一堆混乱来。整洁的代码只做好一件事。整洁的代码简单直接。整洁的代码如同优美的散文。整洁的代码从不隐藏设计者的意图，充满了干净利落的抽象和直戴了当的控制语句。能通过所有测试；没有重复代码；体现系统中的全部设计理念；包括尽量少的实体，比如类、方法、函数等。
2024-08-22 09:14:16
821
原创 menuconfig+Kconfig的简单配置
在module_enable_config.h文件中定义宏，配置值为1或者0。#endif在main中进行代码宏控制。#else#endif优点：直白一目了然，打开module_enable_config.h文件修改重新编译即可缺点：每次需要使能或者关闭通知功能的时候都需要打开module_enable_config.h文件进行修改，修改完成然后再使用IDE（脚本）进行编译，这样比较麻烦。
2024-08-06 20:08:40
1187
原创 嵌入式：简单的UI框架
除了服务框架外，我们还需要对外显示UI，所以我们就需要一个UI的框架，跟服务框架一样，不用这个UI框架我们也是可以实现，但是这样每个人写的UI都会有差异，需要的事件，数据都是独立的，重复的代码也多。但是有UI框架之后就比较方便；例如每个界面都是识别到按键（以手表为例子）有框架直接 case:SINGLE_CLICK,即可，需要什么事件叫框架帮忙统一添加处理即可。除了负责事件的分发、还有就是UI界面的切换、动效等。
2024-08-03 16:21:40
2932
原创 敏捷开发笔记(第15章节)--FACADE模式和MEDIATOR模式
尊贵的符号外表下，隐藏着卑劣的梦想。本章中论述的两个模式有着共同的目的。它们都把某种策略(pocy)施加到另外一组对象上。FACADE模式从上面施加策略，而MEDIATOR模式则从下面施加策略。FACADE模式的使用是明显且受限的，而MEDIATOR模式的使用则是不明显且不受限制的。
2024-08-02 09:26:06
899
原创 敏捷开发笔记(第14章节)--TEMPLATE METHOD模式和STRATEGY模式：继承与委托
业精于勒”。一中国谚语早在20世纪90年代初期一也就是面向对象发展的初期一人们就非常看重继承这个概念。继承关系蕴涵的意义是非常深远的。使用继承我们可以基于差异编程(program by difference)!也就是说，对于某个满足了我们大部分需要的类，可以创建一Jerrilee M.Koheke个它的子类，并只改变其中我们不期望的部分。只是继承一个类，就可以重用该类的代码！通过继承，我们可以建立完整的软件结构分类，其中每一层都可以重用该层次以上的代码。这是一个美丽的新世界。
2024-08-01 09:36:55
660
原创 敏捷开发笔记(第13章节)--COMMAND模式和ACTIVE OBJECT模式
从严格的面向对象意义上来讲，这种做法是被强烈反对的一因为它具有功能分解的味道。然而，在这两个思维范式(paradigm)的碰撞处，有趣的事情发生了。这也许是真的，但是在实际的软件开发中，COM①MAND模式是非常有用的。该模式仅由一个具有惟一方法的接口组成，这似乎是荒谬的。有了这种结构，我们就可以在系统中传递Command对象并调用它们的do0方法，而无需明确地知道它们所代表的Command的种类。这会带来一些有趣的简化。在近几年记述过的所有设计模式中，我认为COMMAND模式是最简单、最优雅的模式之一。
2024-07-25 09:07:56
789
原创 敏捷开发笔记(第12章节)--接口隔离原则（ISP）
事实上，有一种特定的相关实践，可以使派生类无需实现这些方法，该实践的做法是把这些接口合并为一个基类，并在这个基类中提供接口中方法的退化实现。现在，考虑一个这样的实现，TimedDoor,.如果门开着的时间过长，它就会发出警报声。只有当DoorTimerAdapter对象所做的转换是必须的，或者不同的时候会需要不同的转换时，我才会选择图12.2中的方案而不是图12.3中的方案。该问题的答案基于这样的事实，就是一个对象的客户不是必须通过该对象的接口去访问它，也可以通过委托或者通过该对象的基类去访问它。
2024-07-20 11:07:05
1016
原创 敏捷开发笔记(第11章节)--依赖倒置原则（DIP）
所有结构良好的面向对象构架都具有清晰的层次定义，每个层次通过一个定义良好的、受控的接口向外提供了一组内聚的服务。这看起来似Policy Layer乎是正确的，然而它存在一个隐伏的错误特征，那Mechanism就是：Policy Layer对于其下一直到Utility Layer的改动Layer都是敏感的。每个较高层次都为它所需要的服务声明一个抽象接口，较低的层次实现了这些抽象接口，每个高层类都通过该抽象接口使用下一层，这样高层就不依赖于低层。请注意这里的倒置不仅仅是依赖关系的倒置，它也是接口所有权的倒置。
2024-07-17 09:14:00
874
原创 敏捷开发笔记(第10章节)--Liskov原则（LSP）
OCP背后的主要机制是抽象(abstraction)和多态(polymorphism)。在静态类型语言中，比如C++和Java,支持抽象和多态的关键机制之一是继承(inheritance)。正是使用了继承，我们才可以创建实现其基类(base class)中抽象方法的派生类。是什么设计规则在支配着这种特殊的继承用法呢？最佳的继承层次的特征又是什么呢？怎样的情况会使我们创建的类层次结构掉进不符合OCP的陷阱中去呢？这些正是Liskov替换原则(LSP)要解答的问题。
2024-07-08 09:13:06
781
原创 敏捷开发笔记(第9章节)--开放-封闭原则（OCP）
Ivar Jacobson曾说过，“任何系统在其生命周期中都会发生变化。如果我们期望开发出的系统不会再第一版后就被抛弃你就必须牢牢记住一点”。Bertrand Meyer在1988年提出著名的开发-封闭原则（The Open - closed Principle，简称OCP）为我们提供了指引。
2024-06-29 13:47:52
2296
1
原创 敏捷开发笔记(第8章节)--单一职责原则（SRP）
在SRP中，我们把职责定义为“变化的原因”，如果你能够想到多于一个的动机去改变一个了，那么这个类就具有多于一个的职责。有时，我们很难注意到这一点。我们习惯于以组的形式去考虑职责。图8.1.1.1。
2024-06-26 09:08:52
602
原创 敏捷开发笔记(第7章节)--什么是敏捷设计
在按照我的理解方式审查了软件开发的生命周期后，我得出一个结论：实际上满足工程设计标准的唯一软件文档，就是源代码清单。
2024-06-22 11:30:35
1974
1
原创 敏捷开发笔记(第5章节)--重构
本章讲述的是关于人的注意力的，阐述人民应该专注手边的工作并且确信自己正在尽全力，说明了使事物能够工作和使事物正确之间的区别，介绍了我们放入代码结构中的价值。重构的目的，是为了每天清洁你的代码。通过最小的努力就能够对我们的系统进行扩展和修改。要想具有这种能力，最重要的就是要保持代码的清洁。每一个软件模块都具有三项职责。第一个职责是它运行起来完成的功能。第二职责是它要应对变化。第三个职责是要和阅读它的人进行沟通。重构定义：在不改变代码外在的行为的前提下对代码做出修改，以改进代码的内部结构过程。
2024-06-11 08:46:53
331
原创 敏捷开发笔记(第4章节)--测试
测试套件运行起来越来越简单，就会越频繁的运行它们，测试运行得越多，就会越快的发现和那些测试的任务背离。如果有一天多次运行所有的测试，那么系统失效的时间就绝不会超过几分钟，这是一个合理的目标，我们决不允许系统倒退，一旦它工作在一个确定的级别上，就决不能让它倒退到一个稍低的级别。第一个也是最明显的一个影响，是程序中的每一项功能都有测试来验证它的操作的正确性。把程序设计为易于调用和可测试的，是非常重要的，为了易于调用和可测试，程序必须和周边环境解耦，这样首先编写测试迫使我们解除软件中的耦合。
2024-06-04 09:05:05
887
原创 敏捷开发笔记(第3章节)--计划
当你能够度量你所说的，并且能够用数字去表达它时，就表示你了解它；若你不能度量它，不能用数字去表达它，那么说明你的知识就是匮乏的、不能令人满意的。--凯尔文勋爵（英国物理学家）1883。
2024-05-28 09:01:24
763
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人