MDK编译生成的BIN文件占用FLASH大小

最新推荐文章于 2024-12-31 17:05:06 发布
最新推荐文章于 2024-12-31 17:05:06 发布
阅读量1.3k 收藏 2
点赞数
CC 4.0 BY-SA版权
分类专栏： 调试 STM32
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/David_xtd/article/details/109457847
本文详细介绍了如何查看STM32在MDK编译后生成的BIN文件所占用的Flash大小，包括通过资源浏览器查看文件属性、使用TotalCommander以及分析MDK编译信息。最终得出结论，最便捷的方式是利用资源浏览器类工具直接获取。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

STM32烧写Flash时用到的BIN文件大小

在MDK中，通过fromelf.exe命令将hex文件转换成bin文件时，所占用的Flash空间是多大？
从哪里看呢？

1、资源浏览器中通过查看文件属性可以看到

在这里插入图片描述
上图中，大小一栏中的数字3716，即是BIN文件所占用Flash空间的大小。

2、相同功能的浏览器也可以看到

在TotalCommander中也同样可以通过文件的属性看到BIN文件的大小。
在这里插入图片描述
可以看到，BIN文件的大小同样是3716字节。

3、MDK编译后的信息中通过计算得到

在这里插入图片描述

compiling stm32f1xx_hal_cortex.c...
compiling system
最低0.47元/天 解锁文章

200万优质内容无限畅学
MDK如何在C代码中获取编译后的bin文件的大小
qq_27182175的博客
01-08 665
你会发现，实际的bin文件包含的 RW 数据大小并不是 372，而是 56，也就是说，有一部分数据并没有被包含进 bin 文件用于拷贝（可能和 RW 的数据有部分初始值为 0 有关而被压缩了）。而另外两个函数地址，原本鱼鹰并不知道这些值是干什么用的，还是通过分析 map 文件，才最终确认是两个函数的地址，至于到底干什么用的，鱼鹰就不是很清楚的，不过看名字也知道应该和变量初始化有关系。把代码里计算出来的Bin文件大小打印出来，和Map文件以及实际生成的Bin文件大小进行对比，发现大小是一样的。
KEIL编译生成bin文件，并输出内存使用情况
pikachu的博客
07-09 696
一、STM32CubeMX生成的代码输出bin文件 输出bin文件： Run#1框填入的是：fromelf.exe空格–bin空格-o空格"$L@L.bin"空格"#L"。“–bin”是两根英文短杆。 fromelf.exe --bin -o "$L@L.bin" "#L" 编译的时候，输出详细内存使用信息： Run#2框填入的是：fromelf.exe空格–info=totals空格"#L"。“–bin”是两根英文短杆。 fromelf.exe --info=totals "#L" ...
把bin填充0xFF到指定大小(含源码)
12-25
在mcu开发的时候， 特别是做升级文件的时候， 我们有时候需要把一个bin文件，填充指定大小，填充0xFF。 做了一个很简单的小工具，填充0xFF，到指定大小，例如16K。利用批处理就可以执行，支持相对路径。
MDK编译后生成bin文件占用FLASH大小说明
Solidif_Win的博客
08-17 669
linking… Program Size: Code=4972 RO-data=268 RW-data=52 ZI-data=1700 FromELF: creating hex file… After Build - User command #1: C:Keil_v5ARMARMCCbinfromelf.exe --bin -o …OBJUSART.bin …OBJUSART.axf “…OBJUSART.axf” - 0 Error(s), 0 Warning(s). Build Time El
初始化mcu程序选用32k_来，看看你的单片机程序有多大
weixin_39686192的博客
10-28 674
之前一直很奇怪一个问题，每次写好单片机程序之后，用烧录软件进行烧录时，能看到烧录文件也就是hex的文件大小：我用的单片机芯片是STM32F103C8T6，程序储存器（flash）只有64K。从上图可以看出，hex有128K。我有两点疑问，1. 只是一个很简单的平衡小车程序而已，有128K，这么大吗？2. 就算有128K，能下载到只有64K容量的单片机中去？这可能是一道送命题！下面开始我们的探索之旅...
mdk(keil)怎么查看整个工程占用FLASH及SRAM大小
shijizai的博客
12-18 1593
mdk(keil)怎么查看整个工程 占用FLASH及SRAM大小，共总结了两种方法
MDK编译过程及文件类型全解
2301_81790147的博客
12-31 804
编译器给出的 ZI-data 占用的空间值中包含了堆栈的大小 (经实际测试，若程序中完全没有使用 malloc 动态申请堆空间，编译器会优化，不把堆空间计算在内)uvoptx 文件记录了工程的配置选项，如下载器的类型(记录之前用的是STLINK还是JLINK等)、变量跟踪配置、断点位置以及当前已打开的文件等等。uvprojx 文件就是我们平时双击打开的工程文件，它记录了整个工程的结构，如芯片类型(记录之前用的是C8T6还是ZET6等)、工程包。了 python 脚本，也可以在这里输入用户指令执行该脚本。
mdk编译后的HTML,Keil编译过程及程序在Flash和SRAM的空间分配
weixin_35684578的博客
06-17 1083
1. keil编译介绍当使用keil进行单片机的开发时，运行一段程序后，在output输出框会看到如下图的结果。图1 keil 的output框其中，Compiler编译器，使用的版本是 V5.06，程序会先经过编译、后链接linking生成可执行的代码，如果要下载单片机的Flash上，还需要转换成二进制(bin)或者十六进制(hex)的文件。具体过程如下：图2 keil的编译过程值得注意的是，经...
STM32中flash大小-hex文件大小-bin文件大小之间的关系
shaynerain的博客
11-27 5534
之前一直以为STM32flash空间大小和hex文件相关，hex文件大小超过flash大小后程序就会出问题，最近因为做项目添加的新功能，fBootLoader生成的hex文件过大，以为分配的不够，但是不想去改flash空间分配的大小，于是就想到了bin文件，然后查了bin文件如何直接烧写进芯片，这样生产就不会太慢，找到了方法，觉得很麻烦，于是就在想为什么hex文件和bin文件...
如何在C代码中获取编译后的bin文件的大小
booksyhay的专栏
06-04 3832
开发环境：KEIL-MDK（RealView） 需求说明 要在C代码程序中获取编译器最终生成的bin文件大小。 思路 通过读取编译器中生成的链接符号变量来计算。 解决方案 比如，测试程序中生成的Code大小为1906个字节，RO-data的大小为486个字节。两者相加1906+486=2392. 项目配置： 分散加载脚本： ; ************************************************************* ...
Keil编译后生成bin文件占用内部Flash的大小，RAM，ROM，Code，RO-data，RW-data，ZI-data
小肥丸
04-02 3458
Keil编译后生成bin文件占用内部Flash的大小，RAM，ROM，Code，RO-data，RW-data，ZI-data 名词解释 RAM RAM又称随机存取存储器，存储的内容可通过指令随机读写访问。RAM中的存储的数据在掉电是会丢失，因而只能在开机运行时存储数据。其中RAM又可以分为两种，一种是Dynamic RAM(DRAM动态随机存储器),另一种是Static RAM(SRAM,静态随机存储器)。 ROM ROM又称只读存储器，只能从里面读出数据而不能任意写入数据。ROM与RAM相比
YModem协议理解
热门推荐
程序员日常记录
03-16 1万+
**YModem协议理解**Modem协议是使用更大数据块，以追求更高效率的调制解调器所使用的一种纠错协议。它类似于Modem协议。YModem协议使用循环冗余码校验作为检错的方法。YModem是一种比较高效的文件传输协议,每包数据1024bit或者128bit。 一、YModem协议传输的完整的握手过程 二、YModem协议解释
如何手动创建指定大小的bin文件
jxndsfss的专栏
10-26 5833
先创建一个txt文本文件，输入10个字符，文件的大小就是10字节。   同理，需要的bin文件多大，就输入多少字符，输入完毕后，修改文件后缀为.bin，然后使用J-Flash软件打开bin文件，再修改十六进制数值，可以按字节，双字节，四字节修改bin文件。   高字节存高位。  ...
bin文件分析发现的问题（1）
dreamexplorer_xlg的博客
06-07 966
KB、MB、GB和KiB、MiB、GiB区别
MDK Keil查看map文件及编译占用内存信息、函数入口地址
qq_38295600的博客
03-04 1万+
MDK Keil查看map文件及编译占用内存信息、函数入口地址
uboot下nand flash读写方法_鸿蒙HarmonyOS烧录方法总结
weixin_39547596的博客
12-07 1618
1.烧录工具理解HarmonyOS驱动框架，用户态APP和内核态驱动之间的通信机制。HarmonyOS烧录使用的海思自研的烧录工具Hitool，使用起来相对来说比较简单。整体界面如图所示：2.烧录内容烧录内容主要分为两部分，一部分是引导文件fastboot烧录，另一部分为项目文件烧录。这些文件分别是：OHOS_Image.bin可执行文件,rootfs.img和userfs.img镜像...
IAR查看程序占用的内存空间
m0_69752994的博客
09-04 1791
IAR查看程序占用的内存空间
(转载)在IAR及MDK里生成hex及bin文件的标准方法
weixin_30670151的博客
06-24 322
在IAR及MDK中生成bin及hex文件的设置方法： IAR里面---> 生成bin文件：（1）在options->linker ->output->other选中->output里选择raw-binary，module-local里选择Include all，其余默认；（2） options->linker ->Extra Outp...
KEIL5编译后会有一堆子文件
最新发布
07-28
<think>嗯，用户询问的是KEIL5编译后生成大量子文件的原因和解决方法。这个问题涉及到嵌入式开发中的编译过程管理，需要从编译机制和工程配置角度分析。 用户可能是一位嵌入式开发者，正在使用KEIL MDK进行项目开发，突然发现工程目录里冒出来很多不明文件。这些文件让工程看起来杂乱无章，用户既担心删除重要文件又希望保持工程整洁。从问题表述看，用户已经注意到编译后文件数量异常增多，但不太清楚哪些是必要的，哪些可以清理。 让我仔细梳理下KEIL编译流程中的文件生成机制。首先编译过程会分阶段产生中间文件，比如预处理阶段会生成.i文件，编译阶段生成.o和.d文件，链接阶段生成.map文件等。这些文件大部分是编译过程的副产品，但有些如.axf和.hex是最终需要的目标文件。 特别值得注意的是KEIL的build过程会生成临时文件，这些文件在增量编译时能加快速度，但确实会占用空间。如果用户开启浏览信息功能，还会额外产生.browse和.crf文件用于代码导航。另外工程配置中的输出选项也会影响生成文件类型，比如是否生成汇编列表文件.lst。 针对用户困扰，需要区分两类文件：一类是编译必需的过程文件，另一类是可选生成的辅助文件。解决方案可以从工程配置优化入手，比如关闭浏览信息功能，调整输出目录结构，设置自动清理规则等。同时要提醒用户注意备份，避免误删链接脚本或启动文件等重要输入文件。 用户可能还隐含了一个需求：如何判断哪些文件可以安全删除？这需要解释不同文件的后缀名含义，比如.o是目标文件不可删，.d是依赖关系文件可重建。建议用户使用版本控制工具忽略临时文件，这是保持工程整洁的最佳实践。</think>KEIL5（MDK-ARM）在编译项目后会生成多种文件，这些文件各有其用途。理解它们的作用有助于管理工程目录，并优化存储空间： ### 📁 一、KEIL5编译后常见文件类型及原因 1. **源文件相关中间文件** * `.o` / `.obj`：**目标文件** * **原因**：编译器将每个`.c`/`.cpp`/`.s`源文件编译后生成的二进制代码和符号表。链接器（Linker）将这些文件合并为最终的可执行文件。 * `.d`：**依赖关系文件** * **原因**：由编译器生成，记录源文件包含的头文件路径。用于`Makefile`判断是否需要重新编译（当头文件修改时）。 * `.crf`：**交叉引用文件** * **原因**：包含符号（变量、函数）的交叉引用信息，主要用于`Go To Definition`等代码导航功能（需开启`Browse Information`选项）。 * `.i`：**预处理后文件** * **原因**：当在编译器选项中启用`Preprocessor Output`时生成，展示宏展开和头文件包含后的完整代码。 2. **链接输出文件** * `.axf`：**ARM可执行文件** * **原因**：链接器生成，包含完整的可执行代码、调试信息（DWARF格式）、符号表。是调试器直接加载的文件。 * `.hex` / `.bin`：**烧录文件** * **原因**：通过`fromelf`工具从`.axf`转换而来，是烧录到单片机Flash中的最终二进制格式。`HEX`包含地址信息，`BIN`是纯二进制。 * `.map`：**内存映射文件** * **原因**：链接器生成，详细列出代码/数据在内存中的地址分布、各模块大小、符号地址、堆栈配置等，用于分析内存使用。 3. **调试/分析文件** * `.build_log.htm`：**编译日志** * **原因**：记录编译过程的详细输出（警告、错误、命令行）。 * `.browse`：**浏览信息数据库** * **原因**：包含工程中所有符号的定义和引用位置，用于`Go To Definition`、`Find References`（需开启`Browse Information`选项）。 4. **工程/配置相关** * `.uvprojx` / `.uvoptx`：**工程文件** * **原因**：存储工程结构、文件路径、编译选项、调试设置等。`uvprojx`是主工程文件，`uvoptx`保存用户个性化设置。 * `.dep`：**工程依赖文件** * **原因**：记录工程中源文件的依赖关系。 5. **临时文件** * `__history/`：**备份目录** * **原因**：保存工程文件的旧版本备份（可在`Edit -> Configuration -> Backup`中配置）。 * `*.tmp`：**临时文件** * **原因**：编译过程中的临时工作文件，通常可安全删除。 ### 🧹 二、管理/优化生成文件的方法 1. **集中输出目录** * **操作**：在项目选项`Options for Target -> Output -> Select Folder for Objects`中指定一个目录（如`.\Objects`），将所有`.o`、`.d`、`.axf`、`.crf`等文件集中输出到该目录，避免污染源码目录。 * **效果**：源码目录保持整洁，中间文件统一管理。 2. **按类型分类输出** * **操作**：在`Options for Target -> Output`和`Listing`标签页中： * `Output Directory`：设置`.axf`、`.hex`等最终输出文件的目录。 * `Listing Directory`：设置`.lst`、`.map`等列表文件的目录。 * **效果**：文件按功能分类存放，便于查找。 3. **禁用不必要功能** * **操作**： * 关闭浏览信息：`Options for Target -> Output -> Browse Information`（取消勾选）。这会避免生成`.crf`和`.browse`文件（代价是失去部分代码导航功能）。 * 关闭预处理输出：`Options for Target -> C/C++ -> Preprocessor`（不勾选`Generate Preprocessor Output`）。 * **效果**：减少非必要文件的生成。 4. **定期清理** * **手动清理**：删除`Objects`、`Listings`等输出目录下的所有内容（重新编译会自动生成）。 * **脚本自动化**：编写批处理（`.bat`）或Python脚本，在编译前自动清理旧文件。 * **KEIL内置功能**：`Project -> Clean Targets`（部分版本支持）可删除中间文件。 5. **版本控制忽略** * **操作**：在`.gitignore`或类似文件中添加忽略规则： ```gitignore # KEIL 忽略示例 Objects/ Listings/ *.axf *.hex *.bin *.map *.dep *.crf *.browse __history/ *.tmp ``` * **效果**：避免中间文件和输出文件进入版本库，节省空间并提高同步效率。 6. **优化链接器输出** * **操作**：在`Options for Target -> Linker`中： * 取消勾选`Generate Map File`（除非需要分析内存）。 * 在`Misc controls`中添加`--no_demangle`（精简符号名）。 * **效果**：减少`.map`文件大小（调试时可能需要重新启用）。 ### ⚠️ 三、重要注意事项 1. **勿删关键输入文件** * 链接脚本（`.sct`）、启动文件（`.s`）、库文件（`.lib`）是**编译输入文件**，删除会导致编译失败。 * 工程文件（`.uvprojx`, `.uvoptx`）是配置核心，必须保留。 2. **调试依赖** * `.axf`文件包含调试信息，删除后无法进行源码级调试。 * `.browse`和`.crf`文件影响代码导航功能，禁用前需权衡效率。 3. **增量编译** * 清理`.o`文件后首次编译会是**全量编译**，耗时较长，后续编译才是增量。 ### 💎 总结 KEIL5生成的多文件是编译流程各阶段的自然产物：`.o`是编译结果，`.axf`是链接结果，`.hex`是最终烧录文件，`.map`用于内存分析，`.crf/.browse`支持代码导航。通过**集中输出目录**、**禁用非必需功能**（如浏览信息）、**版本控制忽略**和**定期清理**，可有效管理工程目录。理解文件用途后，即可安全清理非必要文件，保持项目整洁[^1][^2]。 --- ### ❓相关问题 1. KEIL5中`.map`文件如何解读内存使用情况？ 2. 如何配置KEIL5以生成最小尺寸的HEX/BIN文件？ 3. KEIL5的增量编译机制如何提升开发效率？ 4. 为什么KEIL工程需要链接脚本（Scatter File）？如何配置？ 5. KEIL5与IAR在编译输出文件管理上有何差异？ [^1]: 编译过程本质是将高级语言逐层转换为机器可执行代码，中间产生多种过渡文件是必然的。 [^2]: 开发环境如KEIL、IAR会生成丰富的中间文件以支持编译、链接、调试等完整工作流。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值