做视频类型的网站从哪个网站设置宽带主机

做视频类型的网站,从哪个网站设置宽带主机,横向拖动的网站,外管局网站怎么做报告1. 从HEX到BIN#xff1a;为什么我们需要这个转换#xff1f; 很多刚开始用KEIL做ARM开发的朋友#xff0c;可能都满足于默认生成的HEX文件。毕竟#xff0c;KEIL里勾选一下“Create HEX File”#xff0c;编译完就能直接找到#xff0c;用起来很方便。我刚开始做项目的时…1. 从HEX到BIN为什么我们需要这个转换很多刚开始用KEIL做ARM开发的朋友可能都满足于默认生成的HEX文件。毕竟KEIL里勾选一下“Create HEX File”编译完就能直接找到用起来很方便。我刚开始做项目的时候也是这么干的直到有一次我需要把固件交给生产线的同事去烧录他们直接问我“有没有BIN文件我们的烧录器只认BIN格式。” 我当时就懵了赶紧去查怎么生成。所以第一个要搞明白的就是为什么我们经常需要BIN文件而不是直接用KEIL默认的AXF或者生成的HEX简单来说AXF文件是带调试信息的可执行文件体积大包含了地址、符号表等主要是给调试器用的。HEX文件是一种十六进制格式它包含了地址信息所以烧录器知道该把数据放到芯片的哪个位置是一种“智能”的格式。而BIN文件是最“原始”的二进制镜像它就是纯纯的程序机器码从头到尾按顺序排列没有任何地址标签。你可以把它理解成一块完整的内存映像。那么BIN文件的优势在哪呢首先通用性极强。几乎所有的量产烧录工具、在线升级OTA工具、甚至一些简单的串口ISP下载方式都直接支持BIN格式。因为它简单没有解析负担。其次在一些特定场景下必不可少比如制作Bootloader时我们通常需要把应用程序的BIN文件放在外部Flash的指定位置Bootloader直接读取这个BIN文件并跳转执行。如果你用HEXBootloader还得先解析一遍HEX格式徒增复杂度。最后BIN文件体积相对更小去掉了地址描述等额外信息对于存储空间紧张或者需要通过网络传输的OTA场景能省一点是一点。所以虽然KEIL默认不直接生成BIN文件但掌握生成BIN的方法是从“学习者”迈向“实际项目开发者”的一个小台阶。接下来我们就深入KEIL内部看看如何搞定它。2. 初探fromelfKEIL自带的格式转换利器知道了BIN文件的好那怎么生成呢答案就在KEIL自带的一个命令行工具里——fromelf.exe。这个工具是ARM编译器工具链的一部分功能就是处理编译器生成的ELF格式文件比如我们的.axf文件把它转换成各种其他格式BIN只是其中之一。首先我们得找到它。根据你安装的ARM编译器版本不同它通常藏在两个地方对于较老的ARMCC编译器比如ARM Compiler 5C:\Keil_v5\ARM\ARMCC\bin\fromelf.exe对于新的ARMCLANG编译器ARM Compiler 6C:\Keil_v5\ARM\ARMCLANG\bin\fromelf.exe怎么知道自己的项目用的是哪个编译器很简单打开KEIL进入Options for Target-Target选项卡看ARM Compiler那一栏显示的是什么。找到正确的路径是第一步因为后续的命令行调用就靠它了。最直接、网上教程最多的方法就是在用户构建后步骤里直接调用它。具体操作打开Options for Target对话框切换到User选项卡。在After Build/Rebuild区域勾选Run #1然后在后面的文本框里输入完整的命令。比如如果你的工程输出名叫Demo命令可能长这样C:\Keil_v5\ARM\ARMCLANG\bin\fromelf.exe --bin -o ./Objects/Demo.bin ./Objects/Demo.axf我来拆解一下这个命令C:\...\fromelf.exe 指定fromelf工具的完整路径。--bin 告诉工具我要输出BIN格式。-o ./Objects/Demo.bin-o指定输出文件路径和名字。这里我们把Demo.bin输出到Objects文件夹下。./Objects/Demo.axf 最后这个参数是输入文件也就是链接器生成的.axf文件。点击编译如果一切顺利你就能在Objects文件夹或者你指定的输出目录里找到新鲜的Demo.bin文件了。这个方法立竿见影对于个人学习或者固定环境的单人项目完全够用。但是如果你和我一样经历过团队协作或者频繁新建工程就会立刻发现这个方法的问题。它太“硬编码”了路径是写死的工程名也是写死的。你的KEIL装在C盘同事装在D盘他直接复制你的工程配置编译就会报错因为找不到C:\Keil_v5...这个路径。你新建一个工程叫Project2又得手动把命令里的Demo全改成Project2麻烦且容易出错。这显然不是一种优雅和可移植的方案。3. 进阶技巧使用KEIL的“密钥序列”实现智能路径为了解决上面那个“硬编码”的痛点我们需要请出KEIL提供的一个非常强大的功能——密钥序列Key Sequences。这其实就是一些特殊的符号代号KEIL在构建时会自动将它们替换成当前工程的实际信息。用好它们你的构建命令就能智能适应不同的安装路径和工程名实现真正的“一次配置到处运行”。我们先来看一个可以直接替换上面那条“硬编码”命令的魔法字符串fromelf --bin -o $LL.bin #L或者另一种写法适用于明确指定工具链路径的场合$K\ARM\ARMCC\bin\fromelf.exe --bin --outputL.bin !L看起来有点像天书别急我们来逐个破解这些魔法符号#L 这是输入文件。#号代表“完整路径”L是“链接器输出文件”的文件代码。所以#L会在构建时被自动替换成你的.axf文件的绝对路径比如C:\YourProject\Objects\Demo.axf。!L 这也是输入文件的另一种表示。!号代表“相对于当前目录的路径”。!L通常会被替换成类似.\Objects\Demo.axf这样的相对路径。使用!L时要确保fromelf运行时的工作目录是工程文件所在目录。L 这个只取文件名不含路径和扩展名。L会被替换成Demo如果你的输出文件是Demo.axf。$L 这个只取路径。$L会被替换成C:\YourProject\Objects\注意末尾带反斜杠。$K这是关键K代表开发工具链的根目录。$K会被自动替换成你KEIL安装目录下ARM编译器工具链的根目录。对于ARMCC它可能是C:\Keil_v5\ARM\ARMCC\对于ARMCLANG则是C:\Keil_v5\ARM\ARMCLANG\。这样一来我们根本不用关心别人把KEIL装在哪$K会自动指向正确的位置。现在让我们重新解读那两条魔法命令fromelf --bin -o $LL.bin #L$LL.bin 输出文件。$L是路径L是工程名组合起来就是[axf文件路径][工程名].bin。例如输出到C:\YourProject\Objects\Demo.bin。#L 输入文件即axf的绝对路径。注意这里直接写fromelf而不是完整路径。这要求你的系统环境变量PATH中包含了ARM工具链的bin目录。如果没有更稳妥的做法是使用下面第二种。$K\ARM\ARMCC\bin\fromelf.exe --bin --outputL.bin !L$K\...\fromelf.exe 工具路径。通过$K自动定位完美解决不同安装路径问题。--outputL.bin 输出文件名为[工程名].bin它会生成在KEIL的当前工作目录通常是工程文件.uvprojx所在目录。!L 输入文件使用axf的相对路径。我个人的习惯是使用第二种并在After Build/Rebuild中配置。因为$K解决了工具路径问题L解决了输出文件名随工程变化的问题!L指定了输入文件。配置好后这个设置可以保存到工程模板里以后新建工程直接复用再也不用修改。提示在User选项卡输入这些带特殊符号的命令时最好用英文双引号把整个参数括起来尤其是路径或文件名中可能包含空格的情况下这样可以避免命令行解析错误。4. 深入fromelf不止于BIN的实用参数解析掌握了可移植的配置方法我们已经可以优雅地生成BIN文件了。但fromelf这个工具的能力远不止于此。了解它的一些其他参数能帮助我们在调试和发布时获取更多有用信息。我们可以通过命令行fromelf --help查看所有选项这里我挑几个实战中特别有用的来讲讲。文本信息输出超好用的调试辅助--text参数可以让fromelf输出可读的文本信息而不是二进制文件。结合下面的子选项它能变成强大的代码分析工具。-c反汇编。这个功能我经常用。当你手头只有一个.axf文件甚至是一个没有源代码的库文件时可以用fromelf --text -c yourfile.axf disasm.txt将反汇编代码输出到文本文件。对于分析崩溃地址、理解编译器优化行为非常有帮助。-s打印符号表。这会列出所有全局变量、函数的地址和大小。在排查链接错误比如某个函数找不到或者想了解内存布局时看一眼符号表就清楚了。-z打印代码与数据的大小信息。这是做内存优化的神器它会详细列出每个函数、每个数据段占用了多少字节。输出结果类似下面这样Code (inc. data) RO Data RW Data ZI Data Debug 12345 678 2345 1024 4096 123456 Object Totals你可以清晰地看到FlashCodeRO Data和RAMRW DataZI Data的占用情况快速定位是哪个文件或库吃掉了大量空间。-v详细信息模式。输出更全面的处理过程信息。其他输出格式--elf 输出为标准的ELF文件。有时可能需要与其他遵循ELF格式的工具链交互。--i32或--m32 输出为英特尔或摩托罗拉格式的32位Hex文件。这是HEX文件的另一种变体有些古老的编程器可能需要。--vhx 面向字节的Hex格式。实用组合拳示例假设我想在每次编译后不仅生成BIN文件还想快速知道这次构建的代码体积变化我可以这样配置两条命令$K\ARM\ARMCC\bin\fromelf.exe --bin --outputL.bin !L $K\ARM\ARMCC\bin\fromelf.exe --text -z !L .\Objects\size_info.txt第一条命令生成BIN文件。第二条命令将大小信息输出到size_info.txt。这样每次编译完我都能在Objects文件夹里同时拿到固件和一份体积报告非常方便跟踪代码大小的增长。5. 工程配置实战打造健壮的团队协作环境理论说了一大堆现在我们来点实际的。如何为一个团队项目配置一套健壮的、与路径无关的BIN文件生成流程我结合自己带项目的经验分享一套最佳实践。第一步统一工具链版本这是所有协作的基础。团队内所有成员必须使用相同版本的KEIL和ARM编译器。最好将使用的KEIL安装包或指定版本号写入项目的README或开发规范文档。因为不同版本的fromelf参数可能略有差异$K指向的目录结构也可能不同。第二步在工程选项中配置用户命令打开Options for Target-User选项卡。在After Build/Rebuild区域勾选Run #1。在命令输入框中填入我们推荐的魔法命令。对于使用ARM Compiler 5ARMCC的团队我强烈推荐这条$K\bin\fromelf.exe --bin --output.\Output\L.bin .\Output\L.axf这里做了几点优化$K\bin\fromelf.exe$K已经指向了ARMCC或ARMCLANG目录所以直接接\bin就能找到工具。--output.\Output\L.bin 我习惯在工程根目录创建一个Output文件夹专门放最终的可执行文件HEX、BIN。.\Output\使得输出路径清晰统一。L保证文件名与工程一致。.\Output\L.axf 同样明确指定axf文件来自Output目录。你需要先在Options for Target-Output选项卡中将输出目录改为.\Output并把可执行文件名设为L不带扩展名。第三步将配置纳入版本管理这是最关键的一步KEIL的工程配置保存在.uvprojx文件或旧版的.uvproj中。当你按照第二步配置好用户命令后这个配置就被写入了工程文件。必须将.uvprojx文件添加到Git、SVN等版本控制系统。团队成员拉取代码后打开工程这个配置就已经在了无需任何修改。无论他们的KEIL安装在C盘、D盘还是任何自定义路径$K都会自动生效BIN文件都会正确生成在项目的Output目录下。第四步创建项目模板如果你所在团队经常启动类似的技术栈的新项目可以创建一个“黄金模板”工程。在这个模板工程里提前配置好正确的芯片型号和调试器设置。优化等级、宏定义等常用编译选项。我们刚刚配置好的BIN文件生成命令。统一的文件夹结构如Drivers,Middlewares,Application,Output等。 以后新项目都从这个模板复制过去能节省大量重复配置时间也保证了团队规范的统一。踩过几次坑之后我发现严格按照这个流程来能避免至少80%关于“为什么我电脑上编译不出来BIN文件”的无效沟通。工程配置的健壮性是团队高效协作的一个隐形基石。6. 避坑指南常见问题与排查技巧即使配置看起来正确有时候还是会遇到BIN文件生成失败或者异常的情况。这里我总结几个自己踩过的坑和解决办法。问题一编译成功但BIN文件没有生成或者报错“无法找到fromelf”可能原因1$K路径解析错误。这通常发生在KEIL安装了多个工具链或者项目使用的编译器与$K默认指向的不一致。检查方法在KEIL的Options for Target-User选项卡点击右下角的Edit...按钮会弹出环境变量查看窗口。在这里你可以看到所有密钥序列的实际值。查看$K是否指向了你预期的ARMCC或ARMCLANG目录。可能原因2命令语法错误。特别注意空格和引号。如果路径或工程名包含空格必须用双引号将整个路径括起来。例如如果L是My Project那么--outputL.bin必须写成--outputL.bin。排查技巧在用户命令前加上cmd /c echo来调试。例如将命令改为cmd /c echo $K\bin\fromelf.exe --bin --output.\Output\L.bin .\Output\L.axf这样编译时KEIL不会真正执行fromelf而是会把替换后的完整命令打印到Build Output窗口。你可以直接复制这条命令粘贴到系统的命令行中执行看具体报什么错。问题二生成的BIN文件大小为0或者比预期小很多可能原因1输入文件路径错误。这是最常见的原因。!L或#L没有正确指向生成的.axf文件。请确认你的.axf文件确实生成在了你命令中指定的路径下。检查Options for Target-Output里的设置。可能原因2链接阶段有错误。有时链接器报错后仍然会生成一个无效的.axf文件。fromelf处理这个无效文件就会生成空的BIN。务必确保Build Output窗口里没有链接错误Linker Error。可能原因3.axf文件本身被占用或损坏。尝试执行一次Rebuild All而不是Build。问题三BIN文件烧录后程序不运行可能原因1忘记包含中断向量表等启动代码。BIN文件是纯二进制数据烧录工具不知道应该把它放到Flash的哪个地址。通常我们需要在烧录工具中指定BIN文件的起始地址。这个地址就是你的工程链接脚本中定义的Flash起始地址通常是0x08000000对于STM32。如果你烧录的起始地址错了程序自然无法运行。可能原因2生成BIN时丢失了部分数据段。--bin参数默认会生成整个加载区域Load Region的映像。但有些特殊的链接器配置可能会产生多个加载区域。对于绝大多数标准嵌入式应用一个加载区域就够了。如果不确定可以用fromelf --text -v !L查看axf文件的详细内存映射确认所有该在Flash里的段如.text,.constdata都在。一个实用的调试清单当BIN文件生成有问题时按顺序检查Build Output窗口 编译和链接是否有任何错误或警告输出目录 确认.axf文件是否已生成以及其大小是否正常不应为0。用户命令回显 用cmd /c echo打印出实际执行的命令检查路径和参数。手动执行命令 将回显的命令复制到Windows命令行中手动执行观察错误信息。检查fromelf版本 在命令行执行fromelf --vsn确认工具链版本。把这些排查思路变成习惯以后遇到任何构建相关的问题你都能快速定位而不是盲目地搜索和尝试。