在刚开始接触STM32的时候，使用的keil作为IDE，由于在这之前，使用过VS， 使用过eclipse，因而在使用keil之后，实在难以忍受keil编辑器简陋的功能，可以说是极其糟糕的写代码体验。 之后，尝试过各种IDE，使用eclipse+keil，结果发现eclipse对C语言的支持也是鸡肋，使用emBits+gcc，需要和其他人协同的话就比较麻烦，之后发现了platformIO，也是使用gcc作为编译器，不过只支持HAL库，而且还有一个重要的原因，同事都是用的keil，如果我使用gcc，就不能协同工作了。 最后，通过使用VS Code + keil的方式，完美解决了写代码的体验问题，以及工程协作问题，其实网上使用VS Code作为编辑器，keil作为编译器的教程很多，不过基本都是需要在VS Code中编辑，然后在keil中编译，下载，调试，本文就要实现编辑，编译，下载，调试，全部使用VS Code。 Part1环境 （1）VS Code； （2）keil；python； （3）GNU Arm Embedded Toolchain（arm gcc工具链）； （4）C/C++(VS Code 插件)； （5）Cortex-Debug(VS Code 插件)； （6）其他VS Code插件(提升体验)。 Part2前提 正式写代码之前，首先需要建立好一个工程，这个需要使用keil完成，包括工程配置，文件添加… Part3编辑 在安装好VS Code插件之后，VS Code编写C代码本身体验就已经很好了， 但是，因为我们使用的是keil环境，所以需要配置头文件包含，宏定义等，在工程路径的.vscode文件夹下打开c_cpp_properties.json文件，没有自己新建一个，内容配置如下： { "configurations": [ { "name": "STM32", "includePath": [ "D:/Program Files/MDK5/ARM/ARMCC/**", "${workspaceFolder}/**", "" ], "browse": { "limitSymbolsToIncludedHeaders": true, "databaseFilename": "${workspaceRoot}/.vscode/.browse.c_cpp.db", "path": [ "D:/Program Files/MDK5/ARM/ARMCC/**", "${workspaceFolder}/**", "" ] }, "defines": [ "_DEBUG", "UNICODE", "_UNICODE", "__CC_ARM", "USE_STDPERIPH_DRIVER", "STM32F10X_MD" ], "intelliSenseMode": "msvc-x64" } ], "version": 4 } 其中，需要在includePath和path中添加头文件路径，${workspaceFolder}/**是工程路径，不用改动，额外需要添加的是keil的头文件路径， 然后在defines中添加宏，也就是在keil的Options for Target的C++选项卡中配置的宏，然后就可以体验VS Code强大的代码提示，函数跳转等功能了（甩keil的编辑器一整个时代）。 Part4编译、烧录 编译和烧录通过VS Code的Task功能实现，通过Task，使用命令行的方式调用keil进行编译和烧录。 keil本身就支持命令行调用，具体可以参考keil的手册，这里就不多说了，但是问题在于，使用命令行调用keil，不管是什么操作，他的输出都不会输出到控制台上！！！(要你这命令行支持有何用) 不过好在，keil支持输出到文件中，那我们就只能利用这个做点骚操作了。一边执行命令，一边读取文件内容并打印到控制台，从而就实现了输出在控制台上，我们就能直接在VS Code中看到编译过程了 为此，我编写了一个Python脚本，实现keil的命令行调用并同时读取文件输出到控制台。 #!/usr/bin/python # -*- coding:UTF-8 -*- import os import threading import sys runing = True def readfile(logfile): with open(logfile, 'w') as f: pass with open(logfile, 'r') as f: while runing: line = f.readline(1000) if line != '': line = line.replace('\\', '/') print(line, end = '') if __name__ == '__main__': modulePath = os.path.abspath(os.curdir) logfile = modulePath + '/build.log' cmd = '\"D:/Program Files/MDK5/UV4/UV4.exe\" ' for i in range(1, len(sys.argv)): cmd += sys.argv[i] + ' ' cmd += '-j0 -o ' + logfile thread = threading.Thread(target=readfile, args=(logfile,)) thread.start() code = os.system(cmd) runing = False thread.join() sys.exit(code) 此脚本需要结合VS Code的Task运行，通过配置Task，我们还需要匹配输出中的错误信息(编译错误)，实现在keil中，点击错误直接跳转到错误代码处，具体如何配置请参考VS Code的文档，这里给出我的Task。 { // See https://go.microsoft.com/fwlink/?LinkId=733558 // for the documentation about the tasks.json format "version": "2.0.0", "tasks": [ { "label": "build", "type": "shell", "command": "py", "args": [ "-3", "${workspaceFolder}/scripts/build.py", "-b", "${config:uvprojxPath}" ], "group": { "kind": "build", "isDefault": true }, "problemMatcher": [ { "owner": "c", "fileLocation": [ "relative", "${workspaceFolder}/Project" ], "pattern": { "regexp": "^(.*)\\((\\d+)\\):\\s+(warning|error):\\s+(.*):\\s+(.*)$", "file": 1, "line": 2, "severity": 3, "code": 4, "message": 5 } } ] }, { "label": "rebuild", "type": "shell", "command": "py", "args": [ "-3", "${workspaceFolder}/scripts/build.py", "-r", "${config:uvprojxPath}" ], "group": "build", "problemMatcher": [ { "owner": "c", "fileLocation": [ "relative", "${workspaceFolder}/Project" ], "pattern": { "regexp": "^(.*)\\((\\d+)\\):\\s+(warning|error):\\s+(.*):\\s+(.*)$", "file": 1, "line": 2, "severity": 3, "code": 4, "message": 5 } } ] }, { "label": "download", "type": "shell", "command": "py", "args": [ "-3", "E:\\Work\\Store\\MyWork\\STM32F1\\FreeModbus_M3\\scripts\\build.py", "-f", "${config:uvprojxPath}" ], "group": "test" }, { "label": "open in keil", "type": "process", "command": "${config:uvPath}", "args": [ "${config:uvprojxPath}" ], "group": "test" } ] } 对于使用ARM Compiler 6编译的工程，build和rebuild中的problemMatcher应该配置为： "problemMatcher": [ { "owner": "c", "fileLocation": ["relative", "${workspaceFolder}/MDK-ARM"], "pattern": { "regexp": "^(.*)\\((\\d+)\\):\\s+(warning|error):\\s+(.*)$", "file": 1, "line": 2, "severity": 3, "message": 4, } } ] 文件中的config:uvPath和config:uvprojxPath分别为keil的UV4.exe文件路径和工程路径(.uvprojx)，可以直接修改为具体路径，或者在VS Code的setting.json中增加对应的项，至此，我们已经完美实现了在VS Code中编辑，编译，下载了。 编译输出： 有错误时输出： 错误匹配： Part5调试 调试需要使用到Cortex-Debug插件，以及arm gcc工具链，这部分可以参考Cortex-Debug的文档，说的比较详细； 首先安装Cortex-Debug插件和arm gcc工具链，然后配置好环境路径，如果使用Jlink调试，需要下载Jlink套件，安转好之后，找到JLinkGDBServerCL.exe这个程序，在VS Code的设置中添加"cortex-debug.JLinkGDBServerPath": "C:/Program Files (x86)/SEGGER/JLink/JLinkGDBServerCL.exe"，后面的路径是你自己的路径。 这里补充一下arm gcc工具链的配置："cortex-debug.armToolchainPath": "D:\\Program Files (x86)\\GNU Arm Embedded Toolchain\\9 2020-q2-update\\bin",后面的路径是你自己的路径。如果使用STLink调试，需要下载stutil工具，在GitHub上搜索即可找到，同样配置好路径即可。 以上步骤弄好之后，可以直接点击VS Code的调试按钮，此时会新建luanch.json文件，这个文件就是VS Code的调试配置文件，可参考我的文件进行配置。 { // 使用 IntelliSense 了解相关属性。 // 悬停以查看现有属性的描述。 // 欲了解更多信息，请访问: https://go.microsoft.com/fwlink/?linkid=830387 "version": "0.2.0", "configurations": [ { "name": "Cortex Debug(JLINK)", "cwd": "${workspaceRoot}", "executable": "${workspaceRoot}/Project/Objects/Demo.axf", "request": "attach", "type": "cortex-debug", "servertype": "jlink", "device": "STM32F103C8", "svdFile": "D:\\Program Files\\ARM\\Packs\\Keil\\STM32F1xx_DFP\\2.3.0\\SVD\\STM32F103xx.svd", "interface": "swd", "ipAddress": null, "serialNumber": null }, { "name": "Cortex Debug(ST-LINK)", "cwd": "${workspaceRoot}", "executable": "${workspaceRoot}/Project/Objects/Demo.axf", "request": "attach", "type": "cortex-debug", "servertype": "stutil", "svdFile": "D:\\Program Files\\ARM\\Packs\\Keil\\STM32F1xx_DFP\\2.3.0\\SVD\\STM32F103xx.svd", "device": "STM32F103C8", "v1": false } ] } 注意其中几个需要修改的地方，executable修改为你的工程生成的目标文件，也就是工程的.axf文件，svdFile用于对MCU外设的监控，该文件可以在keil的安装路径中找到，可以参考我的路径去找，配置完成后，再次点击调试按钮即可进行调试。 相比keil自己的调试功能，VS Code还支持条件断点，可以设置命中条件，次数等，可以极大的方便调试。 总结 通过以上的配置，我们基本上，除了建立工程和往工程中添加文件，其他完全不需要打开keil，所以也无妨说一句，再见，智障keil！
你是否曾经遇到过在linux系统中出现的各种内存问题？比如内存泄漏、内存碎片等等。这些问题都可以通过深入理解linux内存模型得到解决。 一、前言 在linux内核中支持3中内存模型，分别是flat memory model，Discontiguous memory model和sparse memory model。所谓memory model，其实就是从cpu的角度看，其物理内存的分布情况，在linux kernel中，使用什么的方式来管理这些物理内存。另外，需要说明的是：本文主要focus在share memory的系统，也就是说所有的CPUs共享一片物理地址空间的。 本文的内容安排如下：为了能够清楚的解析内存模型，我们对一些基本的术语进行了描述，这在第二章。第三章则对三种内存模型的工作原理进行阐述，最后一章是代码解析，代码来自4.4.6内核，对于体系结构相关的代码，我们采用ARM64进行分析。 二、和内存模型相关的术语 1、什么是page frame？ 操作系统最重要的作用之一就是管理计算机系统中的各种资源，做为最重要的资源：内存，我们必须管理起来。在linux操作系统中，物理内存是按照page size来管理的，具体page size是多少是和硬件以及linux系统配置相关的，4k是最经典的设定。因此，对于物理内存，我们将其分成一个个按page size排列的page，每一个物理内存中的page size的内存区域我们称之page frame。我们针对每一个物理的page frame建立一个struct page的数据结构来跟踪每一个物理页面的使用情况：是用于内核的正文段？还是用于进程的页表？是用于各种file cache还是处于free状态…… 每一个page frame有一个一一对应的page数据结构，系统中定义了page_to_pfn和pfn_to_page的宏用来在page frame number和page数据结构之间进行转换，具体如何转换是和memory modle相关，我们会在第三章详细描述linux kernel中的3种内存模型。 2、什么是PFN？ 对于一个计算机系统，其整个物理地址空间应该是从0开始，到实际系统能支持的最大物理空间为止的一段地址空间。在ARM系统中，假设物理地址是32个bit，那么其物理地址空间就是4G，在ARM64系统中，如果支持的物理地址bit数目是48个，那么其物理地址空间就是256T。当然，实际上这么大的物理地址空间并不是都用于内存，有些也属于I/O空间（当然，有些cpu arch有自己独立的io address space）。因此，内存所占据的物理地址空间应该是一个有限的区间，不可能覆盖整个物理地址空间。不过，现在由于内存越来越大，对于32位系统，4G的物理地址空间已经无法满足内存的需求，因此会有high memory这个概念，后续会详细描述。 PFN是page frame number的缩写，所谓page frame，就是针对物理内存而言的，把物理内存分成一个个的page size的区域，并且给每一个page 编号，这个号码就是PFN。假设物理内存从0地址开始，那么PFN等于0的那个页帧就是0地址（物理地址）开始的那个page。假设物理内存从x地址开始，那么第一个页帧号码就是（x>>PAGE_SHIFT）。 3、什么是NUMA？ 在为multiprocessors系统设计内存架构的时候有两种选择：一种就是UMA（Uniform memory access），系统中的所有的processor共享一个统一的，一致的物理内存空间，无论从哪一个processor发起访问，对内存地址的访问时间都是一样的。NUMA（Non-uniform memory access）和UMA不同，对某个内存地址的访问是和该memory与processor之间的相对位置有关的。例如，对以某个节点（node）上的processor而言，访问local memory要比访问那些remote memory花的时间长。 三、Linux 内核中的三种memory model 1、什么是FLAT memory model？ 如果从系统中任意一个processor的角度来看，当它访问物理内存的时候，物理地址空间是一个连续的，没有空洞的地址空间，那么这种计算机系统的内存模型就是Flat memory。这种内存模型下，物理内存的管理比较简单，每一个物理页帧都会有一个page数据结构来抽象，因此系统中存在一个struct page的数组（mem_map），每一个数组条目指向一个实际的物理页帧（page frame）。在flat memory的情况下，PFN（page frame number）和mem_map数组index的关系是线性的（有一个固定偏移，如果内存对应的物理地址等于0，那么PFN就是数组index）。因此从PFN到对应的page数据结构是非常容易的，反之亦然，具体可以参考page_to_pfn和pfn_to_page的定义。此外，对于flat memory model，节点（struct pglist_data）只有一个（为了和Discontiguous Memory Model采用同样的机制）。下面的图片描述了flat memory的情况： 需要强调的是struct page所占用的内存位于直接映射（directly mapped）区间，因此操作系统不需要再为其建立page table。 2、什么是Discontiguous Memory Model？ 如果cpu在访问物理内存的时候，其地址空间有一些空洞，是不连续的，那么这种计算机系统的内存模型就是Discontiguous memory。一般而言，NUMA架构的计算机系统的memory model都是选择Discontiguous Memory，不过，这两个概念其实是不同的。NUMA强调的是memory和processor的位置关系，和内存模型其实是没有关系的，只不过，由于同一node上的memory和processor有更紧密的耦合关系（访问更快），因此需要多个node来管理。Discontiguous memory本质上是flat memory内存模型的扩展，整个物理内存的address space大部分是成片的大块内存，中间会有一些空洞，每一个成片的memory address space属于一个node（如果局限在一个node内部，其内存模型是flat memory）。下面的图片描述了Discontiguous memory的情况： 因此，这种内存模型下，节点数据（struct pglist_data）有多个，宏定义NODE_DATA可以得到指定节点的struct pglist_data。而，每个节点管理的物理内存保存在struct pglist_data 数据结构的node_mem_map成员中（概念类似flat memory中的mem_map）。这时候，从PFN转换到具体的struct page会稍微复杂一点，我们首先要从PFN得到node ID，然后根据这个ID找到对于的pglist_data 数据结构，也就找到了对应的page数组，之后的方法就类似flat memory了。 3、什么是Sparse Memory Model？ Memory model也是一个演进过程，刚开始的时候，使用flat memory去抽象一个连续的内存地址空间（mem_maps[]），出现NUMA之后，整个不连续的内存空间被分成若干个node，每个node上是连续的内存地址空间，也就是说，原来的单一的一个mem_maps[]变成了若干个mem_maps[]了。一切看起来已经完美了，但是memory hotplug的出现让原来完美的设计变得不完美了，因为即便是一个node中的mem_maps[]也有可能是不连续了。其实，在出现了sparse memory之后，Discontiguous memory内存模型已经不是那么重要了，按理说sparse memory最终可以替代Discontiguous memory的，这个替代过程正在进行中，4.4的内核仍然是有3中内存模型可以选择。 为什么说sparse memory最终可以替代Discontiguous memory呢？实际上在sparse memory内存模型下，连续的地址空间按照SECTION（例如1G）被分成了一段一段的，其中每一section都是hotplug的，因此sparse memory下，内存地址空间可以被切分的更细，支持更离散的Discontiguous memory。此外，在sparse memory没有出现之前，NUMA和Discontiguous memory总是剪不断，理还乱的关系：NUMA并没有规定其内存的连续性，而Discontiguous memory系统也并非一定是NUMA系统，但是这两种配置都是multi node的。有了sparse memory之后，我们终于可以把内存的连续性和NUMA的概念剥离开来：一个NUMA系统可以是flat memory，也可以是sparse memory，而一个sparse memory系统可以是NUMA，也可以是UMA的。 下面的图片说明了sparse memory是如何管理page frame的（配置了SPARSEMEM_EXTREME）： （注意：上图中的一个mem_section指针应该指向一个page，而一个page中有若干个struct mem_section数据单元） 整个连续的物理地址空间是按照一个section一个section来切断的，每一个section内部，其memory是连续的（即符合flat memory的特点），因此，mem_map的page数组依附于section结构（struct mem_section）而不是node结构了（struct pglist_data）。当然，无论哪一种memory model，都需要处理PFN和page之间的对应关系，只不过sparse memory多了一个section的概念，让转换变成了PFNSectionpage。 我们首先看看如何从PFN到page结构的转换：kernel中静态定义了一个mem_section的指针数组，一个section中往往包括多个page，因此需要通过右移将PFN转换成section number，用section number做为index在mem_section指针数组可以找到该PFN对应的section数据结构。找到section之后，沿着其section_mem_map就可以找到对应的page数据结构。顺便一提的是，在开始的时候，sparse memory使用了一维的memory_section数组（不是指针数组），这样的实现对于特别稀疏（CONFIG_SPARSEMEM_EXTREME）的系统非常浪费内存。此外，保存指针对hotplug的支持是比较方便的，指针等于NULL就意味着该section不存在。上面的图片描述的是一维mem_section指针数组的情况（配置了SPARSEMEM_EXTREME），对于非SPARSEMEM_EXTREME配置，概念是类似的，具体操作大家可以自行阅读代码。 从page到PFN稍微有一点麻烦，实际上PFN分成两个部分：一部分是section index，另外一个部分是page在该section的偏移。我们需要首先从page得到section index，也就得到对应的memory_section，知道了memory_section也就知道该page在section_mem_map，也就知道了page在该section的偏移，最后可以合成PFN。对于page到section index的转换，sparse memory有2种方案，我们先看看经典的方案，也就是保存在page->flags中（配置了SECTION_IN_PAGE_FLAGS）。这种方法的最大的问题是page->flags中的bit数目不一定够用，因为这个flag中承载了太多的信息，各种page flag，node id，zone id现在又增加一个section id，在不同的architecture中无法实现一致性的算法，有没有一种通用的算法呢？这就是CONFIG_SPARSEMEM_VMEMMAP。具体的算法可以参考下图： （上面的图片有一点问题，vmemmap只有在PHYS_OFFSET等于0的情况下才指向第一个struct page数组，一般而言，应该有一个offset的，不过，懒得改了，哈哈） 对于经典的sparse memory模型，一个section的struct page数组所占用的内存来自directly mapped区域，页表在初始化的时候就建立好了，分配了page frame也就是分配了虚拟地址。但是，对于SPARSEMEM_VMEMMAP而言，虚拟地址一开始就分配好了，是vmemmap开始的一段连续的虚拟地址空间，每一个page都有一个对应的struct page，当然，只有虚拟地址，没有物理地址。因此，当一个section被发现后，可以立刻找到对应的struct page的虚拟地址，当然，还需要分配一个物理的page frame，然后建立页表什么的，因此，对于这种sparse memory，开销会稍微大一些（多了个建立映射的过程）。 四、代码分析 我们的代码分析主要是通过include/asm-generic/memory_model.h展开的。 1、flat memory。代码如下： #define __pfn_to_page(pfn) (mem_map + ((pfn) - ARCH_PFN_OFFSET)) #define __page_to_pfn(page) ((unsigned long)((page) - mem_map) + ARCH_PFN_OFFSET) 由代码可知，PFN和struct page数组（mem_map）index是线性关系，有一个固定的偏移就是ARCH_PFN_OFFSET，这个偏移是和估计的architecture有关。对于ARM64，定义在arch/arm/include/asm/memory.h文件中，当然，这个定义是和内存所占据的物理地址空间有关（即和PHYS_OFFSET的定义有关）。 2、Discontiguous Memory Model。代码如下： #define __pfn_to_page(pfn) ({ unsigned long __pfn = (pfn); unsigned long __nid = arch_pfn_to_nid(__pfn); NODE_DATA(__nid)->node_mem_map + arch_local_page_offset(__pfn, __nid); }) #define __page_to_pfn(pg) ({ const struct page *__pg = (pg); struct pglist_data *__pgdat = NODE_DATA(page_to_nid(__pg)); (unsigned long)(__pg - __pgdat->node_mem_map) + __pgdat->node_start_pfn; }) Discontiguous Memory Model需要获取node id，只要找到node id，一切都好办了，比对flat memory model进行就OK了。因此对于__pfn_to_page的定义，可以首先通过arch_pfn_to_nid将PFN转换成node id，通过NODE_DATA宏定义可以找到该node对应的pglist_data数据结构，该数据结构的node_start_pfn记录了该node的第一个page frame number，因此，也就可以得到其对应struct page在node_mem_map的偏移。__page_to_pfn类似，大家可以自己分析。 3、Sparse Memory Model。经典算法的代码我们就不看了，一起看看配置了SPARSEMEM_VMEMMAP的代码，如下： #define __pfn_to_page(pfn) (vmemmap + (pfn)) #define __page_to_pfn(page) (unsigned long)((page) - vmemmap) 简单而清晰，PFN就是vmemmap这个struct page数组的index啊。对于ARM64而言，vmemmap定义如下： #define vmemmap ((struct page *)VMEMMAP_START - SECTION_ALIGN_DOWN(memstart_addr >> PAGE_SHIFT)) 毫无疑问，我们需要在虚拟地址空间中分配一段地址来安放struct page数组（该数组包含了所有物理内存跨度空间page），也就是VMEMMAP_START的定义。 总之，Linux内存模型是一个非常重要的概念，可以帮助你更好地理解Linux系统中的内存管理。
1.Keil编程开发环境(必备) 这个是最核心的工具了，用来编写和编译程序，还有一个最重要的功能就是仿真，快速地帮你定位程序BUG，不过要配合ST-Link或者其他仿真器用。 一般51我是用C51V9.0的，STM32我是用Keil4.72...
一定有很多人都听说过嵌入式和单片机，但在刚开始接触时，不知道大家有没有听说过嵌入式就是单片机这样的说法，其实嵌入式和单片机还是有区别的。单片机与嵌入式到底有什么关系？ 下面我们就来说说嵌入式和单片机之间的联系和区别吧。 01 什么是单片机？ 首先，我们来了解一下到底什么是单片机。 嵌入式系统的核心是嵌入式处理器。嵌入式处理器一般可以分为以下几种类型： 嵌入式微控制器MCU（Micro Control Unit） 嵌入式DSP处理器（Digital Signal Processor） 嵌入式微处理器MPU（Micro Processor Unit） 嵌入式片上系统SoC（System on Chip） 可编程片上系统SoPC（System on a Programmable Chip） 我们的单片机属于嵌入式微控制器MCU（Micro Control Unit） MCU内部集成ROM/RAM、总线逻辑、定时/计数器、看门狗、I/O、串口、A/D、D/A、FLASH等。典型代表如8051、8096、C8051F等。 单片机就是在一个芯片（Chip）上集成了CPU、SRAM、Flash及其他需要模块，在一个Chip上实现一个微型计算机系统，所以就叫Single Chip Microcomputer，也就是单片机了。 它其实就是一种集成电路芯片，是通过超大规模集成电路技术，将CPU、RAM、ROM、输入输出和中断系统、定时器/计数器等功能，塞进一块硅片上，变成一个超小型的计算机。 这么说来，单片机不就是一个嵌入式系统？ 别急，我们往下看。 “单片机”其实是一种古老的叫法。在那个年代半导体工艺还在起步阶段，集成能力很差，往往是CPU一个芯片，SRAM一个芯片，Flash一个芯片，需要中断的话又得有个专门处理中断的芯片，所以一个完整可用的计算机系统是很多个芯片（Chip）做在一个PCB板上构成的。 不同的功能无法做进一个芯片（Chip），所以会有多片机。现在半导体技术早已非常发达，所以不存在多片机。但是，“单片机”的叫法却一直延用至今。 单片机技术从上世纪70年代末诞生，早期的时候是4位，后来发展为8位，16位，32位。它真正崛起，是在8位时代。8位单片机功能很强，被广泛应用于工业控制、仪器仪表、家电汽车等领域。 我们在研究单片机的时候，经常会听到一个词——51单片机。让我们来了解一下它究竟是什么。 51单片机，其实就是一系列单片机的统称。该系列单片机，兼容Intel 8031指令系统。它们的始祖，是Intel（英特尔）的8004单片机。 注意，51单片机并不全是英特尔公司产品。包括ATMEL（艾德梅尔）、Philips（飞利浦）、华邦Dallas（达拉斯）、Siemens（西门子）、STC（国产宏晶等公司，也有很多产品属于51单片机系列。 ATMEL公司的51单片机，AT89C51这是一个51单片机的开发板，中间那个芯片才是51单片机 51单片机曾经在很长时间里都是市面上最主流、应用最广泛的单片机，占据大量的市场份额。 51单片机其实放在现在毫无技术优势，是一种很老的技术。之所以它的生命力顽强，除了它曾经很流行之外，还有一个原因，就是英特尔公司彻底开放了51内核的版权。 所以，无论任何单位或个人，都可以毫无顾忌地使用51单片机，不用付费，也不用担心版权风险，所以很多学校也都在用这个。 此外，51单片机拥有雄厚的存量基础和群众基础。很多老项目都是用的51单片机，出于成本的考虑，有时候只能继续沿用51单片机的技术进行升级。 而且，很多老一辈的工程师，都精通51单片机开发技术。 所以，51单片机的生命力得以不断延续。 02 什么是嵌入式？ 嵌入式系统是一种专用的计算机系统，作为装置或设备的一部分。通常，嵌入式系统是一个控制程序存储在ROM中的嵌入式处理器控制板。 事实上，所有带有数字接口的设备，如手表、微波炉、录像机、汽车等，都使用嵌入式系统，有些嵌入式系统还包含操作系统，但大多数嵌入式系统都是由单个程序实现整个控制逻辑。 从应用对象上加以定义，嵌入式系统是软件和硬件的综合体，还可以涵盖机械等附属装置。国内普遍认同的嵌入式系统定义为： 以应用为中心，以计算机技术为基础，软硬件可裁剪，适应应用系统对功能、可靠性、成本、体积、功耗等严格要求的专用计算机系统。 嵌入式系统具体应用于哪些“专用”方向呢？ 举例如下： 办公自动化：打印机，复印机、传真机 军事及航天类产品：无人机、雷达、作战机器人 家电类产品：数字电视、扫地机器人、智能家电 医疗电子类产品：生化分析仪血液分析仪、CT 汽车电子类产品：引擎控制、安全系统、汽车导航与娱乐系统 网络通信类产品：通信类交换设备、网络设备 (交换机、路由器、网络安全) 通信与娱乐：手机、数码相机、音乐播放器、可穿戴电子产品、PSP游戏机 工业控制类产品：工控机交互式终端 (POS、ATM)、安全监控、数据采集与传输、仪器仪表 上述这些领域，都使用了嵌入式系统。这还只是冰山一角。 可以说，嵌入式系统完完全全地融入了我们，时刻影响着我们的工作和生活。 嵌入式系统，既然是一个计算机系统，那么肯定离不开硬件和软件。 一个嵌入式系统的典型架构如下： 这里最重要的就是嵌入式操作系统和嵌入式微处理器。 从硬件角度来看，嵌入式系统就是以处理器（CPU）为核心，依靠总线（Bus）进行连接的多模块系统： 其实大家不难看出和个人PC是一样的方式。 单片机是有清晰定义的，就是单个片（chip）上的计算机系统。而不同的单片机虽然配置不同，性能不同，厂家不同，甚至指令集和开发方式不同，但是都是在一个片上的完整的计算机系统，这个定义不会错。 而嵌入式就是个不清晰的定义了，并没有非常明确的关于“嵌入式”这个词的定义。他也不像单片机一样，是个确定的“物”的名字。 03 单片机是不是嵌入式？ 那么单片机到底是不是嵌入式呢？ 简单来说：是。 因为很多嵌入式产品中被嵌入的计算机系统就是单片机，譬如空调中嵌入的控制板其实核心就是个单片机。实际上大部分家电产品中嵌入的计算机系统都是单片机。 因为单片机足够简单便宜而且够用，所以使用单片机是最划算最适合的。 而单片机现在出货量最大的领域也就是家电产品了，当然未来IOT类的应用会越来越多，会成为单片机的很大的增量市场。 04 广义和狭义的嵌入式 嵌入式这个概念实际上很泛化，现在讲嵌入式这个词的人，可能想表达的意思并不相同。咱们上面讲的嵌入式的概念是嵌入式本来的定义，也就是所谓广义上的嵌入式。 而狭义的嵌入式，其实是“嵌入式linux系统”的简称。 这种狭义的嵌入式最初指的是运行了linux系统的嵌入式计算机系统。后来也包括运行了和linux同级别的其他嵌入式系统（譬如WinCE、Vxworks、Android等）的计算机。 看过上面的介绍之后你就知道到底单片机是不是嵌入式了，其实这两者之间的联系有很深，总之，不管你是准备学习嵌入式或是单片机，都要自己想好了再做决定。 05 嵌入式和单片机的区别 说到这里，我们来看看，嵌入式和单片机的区别到底是什么。 从前文的介绍来看，嵌入式系统是一个大类，单片机是其中一个重要的子类。嵌式系统像是一个完整的计算机，而单片机更像是一个没有外设的计算机。 以前单片机包括的东西并不算多，两者的硬件区别较为明显。 但是，随着半导体技术的突飞猛进，现在各种硬件功能都能被做进单片机之中。所以，嵌入式系统和单片机之间的硬件区别越来越小，分界线也越来越模糊。 于是，人们倾向于在软件上进行区分。 从软件上，行业里经常把芯片中不带MMU（memory management unit，内存管理单元）从而不支持虚拟地址，只能裸奔或运行RTOS（实时操作系统，例如ucos、华为LiteOS、RT-Thread、freertos等）的system，叫做单片机（如STM32、NXP LPC系列、NXP imxRT1052系列等）。 同时，把芯片自带MMU可以支持虚拟地址，能够跑Linux、Vxworks、WinCE、Android这样的“高级”操作系统的system，叫做嵌入式。 在某些时候，单片机本身已经足够强大，可以作为嵌入式系统使用。它的成本更低，开发和维护的难度相对较小，尤其是针对一些针对性更强的应用。而嵌入式系统理论上性能更强，应用更广泛，但复杂度高，开发难度大。 06 我们为什么要学习嵌入式和单片机 今天我也只是给大家简单地介绍了一下单片机和嵌入式以及他们之间的关系和区别，虽然嵌入式系统已经有30多年的历史，但其实一直隐藏在背后的，自从物联网上升为国家战略后，嵌入式系统也渐渐从后台走到前台。 嵌入式和单片机并不是纯“硬件”类方向。如果你想学好嵌入式和单片机，只懂数字电路和微机接口这样的硬件知识是不够的，你更需要学习的，是汇编、C/C++语言、数据结构和算法知识。拥有软硬结合的能力，远远比单纯掌握某种程序开发语言更有价值。 其次，嵌入式和单片机拥有广泛的应用场景，在各个领域都有项目需求和人才需求。而且我们国家现在正在大力发展芯片产业，也会带动嵌入式人才的就业，提升待遇。 随着5G建设的深入，整个社会正在向“万物互联”的方向变革。 物联网技术也将迎来前所未有的历史机遇。嵌入式和单片机技术是物联网技术的重要组成部分，也将进入快速发展的时代。 技术越难，过程越苦，越有利于构建竞争壁垒。大学里很多同学都热衷于学习各种编程语言，往往忽视了这一块，可以说在嵌入式开发这一块的人才我们国家还是比较欠缺的。因此，我觉得大家非常值得投入时间去学习嵌入式开发的技能。原文：https://www.zhihu.com/question/315310041/answer/2179945564
嵌入式开发，特别是单片机os-less的程序，最易范的错误是全局变量满天飞。 这个现象在早期汇编转型过来的程序员以及初学者中常见，这帮家伙几乎把全局变量当作函数形参来用。 在.h文档里面定义许多杂乱的结构体，extern一堆令人头皮发麻的全局变量，然后再这个模块里边赋值123，那个模块里边判断123分支决定做什么。 每当看到这种程序，我总要戚眉变脸而后拍桌怒喝。没错，就是怒喝。 不否认全局变量的重要性，但我认为要十分谨慎地使用它，滥用全局变量会带来其它更为严重的结构性系统问题。 为什么全局变量要越少越好？ 它会造成不必要的常量频繁使用，特别当这个常量没有用宏定义“正名”时，代码阅读起来将万分吃力。 它会导致软件分层的不合理，全局变量相当于一条快捷通道，它容易使程序员模糊了“设备层”和“应用层”之间的边界。写出来的底层程序容易自作多情地关注起上层的应用。 这在软件系统的构建初期的确效率很高，功能调试进度一日千里，但到了后期往往bug一堆，处处“补丁”，雷区遍布。说是度日如年举步维艰也不为过。 由于软件的分层不合理，到了后期维护，哪怕仅是增加修改删除小功能，往往要从上到下掘地三尺地修改，涉及大多数模块， 而原有的代码注释却忘了更新修改，这个时候，交给后来维护者的系统会越来越像一个“泥潭”，注释的唯一作用只是使泥潭上方再加一些迷烟瘴气。 全局变量大量使用，少不了有些变量流连忘返于中断与主回圈程序之间。 这个时候如果处理不当，系统的bug就是随机出现的，无规律的，这时候初步显示出病入膏肓的特征来了，没有大牛来力挽狂澜，注定慢性死亡。 无需多言，您已经成功得到一个畸形的系统，它处于一个神秘的稳定状态！ 你看着这台机器，机器也看着你，相对无言，心中发毛。你不确定它什么时候会崩溃，也不晓得下一次投诉什么时候道理。 全局变量大量使用有什么后果？ “老人”气昂昂，因为系统离不开他，所有“雷区”只有他了然于心。当出现紧急的bug时，只有他能够搞定。你不但不能辞退他，还要给他加薪。 新人见光死，但凡招聘来维护这个系统的，除了改出更多的bug外，基本上一个月内就走人，到了外面还宣扬这个公司的软件质量有够差够烂。 随着产品的后续升级，几个月没有接触这个系统的原创者会发现，很多雷区他本人也忘记了，于是每次的产品升级维护周期越来越长， 因为修改一个功能会冒出很多bug，而按下一个bug，会弹出其他更多的bug。在这期间，又会产生更多的全局变量。 终于有一天他告诉老板，不行啦不行啦，资源不够了，ram或者flash空间太小了，升级升级。 客户投诉不断，售后也快崩溃了，业务员也不敢推荐此产品了，市场份额越来越小，公司形象越来越糟糕。 要问对策，只有两个原则 能不用全局变量尽量不用，我想除了系统状态和控制参数、通信处理和一些需要效率的模块，其他的基本可以靠合理的软件分层和编程技巧来解决。 如果不可避免需要用到，那能藏多深就藏多深。 如果只有某.c文件用，就static到该文件中，顺便把结构体定义也收进来； 如果只有一个函数用，那就static到函数里面去； 如果非要开放出去让人读取，那就用函数return出去，这样就是只读属性了； 如果非要遭人蹂躏赋值，好吧，我开放函数接口让你传参赋值； 实在非要extern侵犯我，我还可以严格控制包含我.h档的对象，而不是放到公共的includes.h中被人围观，丢人现眼。 如此，你可明白我对全局变量的感悟有多深刻，悲催的我，已经把当年那些“老人”交给我维护的那些案子加班全部重新翻写了。 最后补充 全局变量是不可避免要用到的，每一个设备底层几乎都需要它来记录当前状态，控制时序，起承转合。但是尽量不要用来传递参数，这个很忌讳的。 尽量把变量的作用范围控制在使用它的模块里面，如果其他模块要访问，就开个读或写函数接口出来，严格控制访问范围。 这一点，C++的private属性就是这么干的，这对将来程序的调试也很有好处。 C语言之所以有++版本，很大原因就是为了控制它的灵活性，要说面向对象的思想，C语言早已有之，亦可实现。 当一个模块里面的全局变量超过3个(含)时，就用结构体包起来吧，要归0便一起归0，省得丢三落四的。 在函数里面开个静态的全局变量，全局数组，是不占用栈空间的，只是有些编译器对于大块的全局数组，会放到和一般变量不同的地址区。 若是在keil C51，因为是静态编译，栈爆掉了会报警，所以大可以尽情驰骋，注意交通规则就是了。 单片机的os-less系统中，只有栈没有堆的用法，那些默认对堆分配空间的“startup.s”，可以大胆的把堆空间干掉。 程序模型？如何分析抽象出来呢，从哪个角度进行模型构建呢？很愿意聆听网友的意见。 本人一直以来都是从两个角度分析系统，事件--状态机迁移图 和 数据流图，前者分析控制流向，完善UI，后者可知晓系统数据的缘起缘灭。 这些理论，院校的《软件工程》教材都有，大家不妨借鉴下。只不过那些理论，终究是起源于大型系统软件管理的，牛刀杀鸡，还是要裁剪一下的。
【前面的话】在近几年的嵌入式社区中，流传着不少关于面相Cortex-M的Bootloader科普文章，借助这些文章，一些较为经典的代码片断和技巧得到了广泛的传播。 在从Bootloader跳转到用户APP的过程中，使用函数指针而非传统的汇编代码则成了一个家喻户晓的小技巧。相信类似下面 JumpToApp() 函数，你一定不会感到陌生： typedef void (*pFunction)(void); void JumpToApp(uint32_t addr){ pFunction Jump_To_Application; __IO uint32_t StackAddr; __IO uint32_t ResetVector; __IO uint32_t JumpMask; JumpMask = ~((MCU_SIZE-1)|0xD000FFFF); if (((*(__IO uint32_t *)addr) & JumpMask ) == 0x20000000) //�ж�SPָ��λ�� { StackAddr = *(__IO uint32_t*)addr; ResetVector = *(__IO uint32_t *)(addr + 4); __set_MSP(StackAddr); Jump_To_Application = (pFunction)ResetVector; Jump_To_Application(); }} 为了读懂这段代码，需要一些从事Cortex-M开发所需的“热知识”： 向量表是一个由 32bit 数据构成的数组 数组的第一个元素是 uintptr_t 类型的指针，保存着复位后主栈顶指针（MSP）的初始值。 从数组第二个元素开始，保存的是 (void (*)(void)) 类型的异常处理程序地址（BIT0固定为1，表示异常处理程序使用Thumb指令集进行编码） 数组的第二个元素保存的是复位异常处理程序的地址（Reset_Handler） 从理论上说，要想保证APP能正常执行，Bootloader通常要在跳转前“隐藏自己存在过的事实”——需要“对房间进行适度的清理”，并模拟芯片硬件的一些行为——假装芯片复位后是直接从APP开始执行的。 总结来说，Bootloader在跳转到App之前需要做两件事： 1. 清理房间——仿佛Bootloader从未执行过一样 2. 模拟处理器的硬件的一些复位行为——假装芯片从复位开始就直接从APP开始执行 一般来说，做到上述两点，就可以实现App将Bootloader视作黑盒子的效果，从而带来极高的兼容性。甚至在App注入了“跳床（trumpline）”的情况下，实现App既可以独立开发、调试和运行，也可以不经修改的与Bootloader一起工作的奇效。 如何在App中加入“跳床（trumpline）”值得专门再写一篇独立的文章，不是本文所需关注的重点，请允许我暂且略过。 这里，“清理房间”的步骤与Bootloader具体“弄脏了什么”（或者说使用了什么资源）有关；而“模拟处理器硬件的一些复位行为”就较为简单和具体：即，从Bootloader跳转到App前的最后两个步骤为： 从APP的向量表中读取MSP的初始值并以此来初始化MSP寄存器； 从APP的向量表中读取Reset_Handler的值，并跳转到其中去执行——完成从Bootloader到APP的权利交接。 结合前面的例子代码，值得我们关注的部分是： 1. 使用自定义的函数指针类型 pFunction 定义一个局部变量： pFunction Jump_To_Application; 2. 根据向量表的首地址 addr 读取第一个元素——作为MSP的初始值暂时保存在局部变量 StackAddr 中： StackAddr = *(__IO uint32_t*)addr; 3. 根据向量表的首地址 addr 读取第二个元素——将Reset_Handler的首地址保存到局部变量 ResetVector 中： ResetVector = *(__IO uint32_t *)(addr + 4); 4. 设置栈顶指针MSP寄存器： __set_MSP(StackAddr); 5. 通过函数指针完成从Bootloader到App的跳转： Jump_To_Application = (pFunction)ResetVector; Jump_To_Application(); 其实，无论具体的代码如何，只要实现步骤与上述类似，就存在一个隐藏较深的漏洞，而漏洞的“触发与否”则完全“看脸”——简单来说： 只要你是按照上述方法来实现从Bootloader到App的跳转的，那么就一定存在问题——而“似乎可以正常工作”就只是你运气较好，或者“由此引发的问题暂时未能引发注意”罢了。 在你试图争辩“老子代码已经量产了也没有什么不妥”之前，我们先来看看漏洞的原理是什么——在知其所以然后，如何评估风险就是你们自己的事情了。 【C语言基础设施是什么】 嵌入式系统的信息安全（Security）建立在基础设施安全（Safety）的基础之上。 由于“确保信息安全的很多机制”本质上是一套建立在“基础设施能够正常工作”这一前提之上的规则和逻辑，因此很多针对信息安全的攻击往往会绕开信息安全的“马奇诺防线”，转而攻击基础设施。芯片数字逻辑的基础设施是时钟源、供电、总线时序、复位时序等等，因此，针对硬件基础设施的攻击通常也就是针对时钟源、电源、总线时序和复位时序的攻击。此时，好奇的小伙伴会产生疑问：固件一般由C语言进行编写，那么C语言所依赖的基础设施又是什么呢？ 对C语言编译器来说，栈的作用是无可替代的： 函数调用 函数间的参数传递 分配局部变量 暂时保存通用寄存器中的内容 …… 可以说，离开了栈C语言寸步难行。因此对很多芯片来说，复位后为了执行用户使用C语言编译的代码，第一个步骤就是要实现栈的初始化。 作为一个有趣的“冷知识”，Cortex-M在宣传中一直强调自己“支持完全使用C语言进行开发”，这让很多人“丈二和尚摸不着头脑”甚至觉得“非常可笑”——因为这年月连51都支持用户使用C语言进行开发了，你这里说的“Cortex-M支持使用C语言进行开发”有什么意义呢？ 其实门道就在这里： 由于Cortex-M处理器会在复位时由硬件完成对C语言基础设施（也就是栈顶指针MSP）的初始化，因此无论是理论上还是实践中，从复位异常处理程序Reset_Handler开始用户就可以完全可以使用C语言进行开发了，而整个启动代码（startup）也可以全然不涉及任何汇编； 由于Cortex-M的向量表是一个完全由 32位整数（uintptr_t）构成的数组——保存的都是地址而非具体代码，可以使用C语言的数据结构直接进行描述——因此也完全不需要汇编语言的介入。 这种从复位一开始就完全不需要汇编介入的友好环境才是Cortex-M声称自己“支持完全使用C语言进行开发”的真实意义和底气。从这一角度出发，只要某个芯片架构复位后必须要通过软件来初始化栈顶指针，就不符合“从出生的那一刻就可以使用C语言”的基本要求。 【C语言编译器的约定】 栈对C语言来说如此重要，以至于编译器一直有一条默认的约定，即： 栈必须完全交由C语言编译器进行管理（或者用户对栈的操作必须符合对应平台所提供的调用规约，比如Arm的AAPCS规约）。 简而言之，如果你“偷偷摸摸”的修改了栈顶指针，C语言编译器是会“假装”完全不知道的，而此时所产生的后果C语言编译器会默认自己完全不用负责。 回头再看这段代码： StackAddr = *(__IO uint32_t*)addr; ResetVector = *(__IO uint32_t *)(addr + 4); __set_MSP(StackAddr); Jump_To_Application = (pFunction)ResetVector; Jump_To_Application(); 虽然我们觉得自己“正大光明”的使用了 __set_MSP() 来修改了栈顶指针，但它实际上是一段C语言编译器并不理解其具体功能的在线汇编——在编译器看来，无论是谁提供的 __set_MSP()，只要是在线汇编，这就算是用户代码——是编译器管不到的地带。 /** \brief Set Priority Mask \details Assigns the given value to the Priority Mask Register. \param [in] priMask Priority Mask */__STATIC_FORCEINLINE void __set_PRIMASK(uint32_t priMask){ __ASM volatile ("MSR primask, %0" : : "r" (priMask) : "memory");} 或者说：C语言编译器一般情况下会默认你“无论如何都不会修改栈顶指针”——它不仅管不着，也不想管。 从这点来看，上述代码的确打破了这份约定。即便如此，很多小伙伴会心理倔强的认为：我就这么改了，怎么DE了吧？！ 【问题的分析】 从原理上说，开篇那个典型的Bootloader跳转代码所存在的问题已经昭然若揭： typedef void (*pFunction)(void); void JumpToApp(uint32_t addr){ pFunction Jump_To_Application; __IO uint32_t StackAddr; __IO uint32_t ResetVector; __IO uint32_t JumpMask; JumpMask = ~((MCU_SIZE-1)|0xD000FFFF); if (((*(__IO uint32_t *)addr) & JumpMask ) == 0x20000000) //�ж�SPָ��λ�� { StackAddr = *(__IO uint32_t*)addr; ResetVector = *(__IO uint32_t *)(addr + 4); __set_MSP(StackAddr); Jump_To_Application = (pFunction)ResetVector; Jump_To_Application(); }} 我们不妨结合上述代码反汇编的结果进行深入解析： AREA ||i.JumpToApp||, CODE, READONLY, ALIGN=2 JumpToApp PROC000000 b082 SUB sp,sp,#8000002 4909 LDR r1,|L2.40|000004 9100 STR r1,[sp,#0]000006 6802 LDR r2,[r0,#0]000008 400a ANDS r2,r2,r100000a 2101 MOVS r1,#100000c 0749 LSLS r1,r1,#2900000e 428a CMP r2,r1000010 d107 BNE |L2.34|000012 6801 LDR r1,[r0,#0]000014 9100 STR r1,[sp,#0]000016 6840 LDR r0,[r0,#4]000018 f3818808 MSR MSP,r100001c 9001 STR r0,[sp,#4]00001e b002 ADD sp,sp,#8000020 4700 BX r0 |L2.34|000022 b002 ADD sp,sp,#8000024 4770 BX lr ENDP 000026 0000 DCW 0x0000 |L2.40| DCD 0x2fff0000 注意这里，StackAddr、ResetVector是两个局部变量，由编译器在栈中进行分配。汇编指令将SP指针向栈底挪动8个字节就是这个意思： 000000 b082 SUB sp,sp,#8 虽然 JumpMask 也是局部变量，但编译器根据自己判断认为它“命不久矣”，因此直接将它分配到了通用寄存器r2中，并配合r1和sp完成了后续运算。这里： __IO uint32_t JumpMask; JumpMask = ~((MCU_SIZE-1)|0xD000FFFF); if (((*(__IO uint32_t *)addr) & JumpMask ) == 0x20000000) //�ж�SPָ��λ�� { ... } 对应： 000002 4909 LDR r1,|L2.40|000004 9100 STR r1,[sp,#0]000006 6802 LDR r2,[r0,#0]000008 400a ANDS r2,r2,r100000a 2101 MOVS r1,#100000c 0749 LSLS r1,r1,#2900000e 428a CMP r2,r1000010 d107 BNE |L2.34|...|L2.34|000022 b002 ADD sp,sp,#8000024 4770 BX lrENDP 000026 0000 DCW 0x0000|L2.40|DCD 0x2fff0000 考虑到JumpMask的内容与本文无关，不妨暂且跳过。 接下来就是重头戏了： 编译器按照用户的指示读取栈顶指针MSP的初始值，并保存在StackAddr中： StackAddr = *(__IO uint32_t*)addr; 对应的汇编是： 000012 6801 LDR r1,[r0,#0]000014 9100 STR r1,[sp,#0] 根据Arm的AAPCS调用规约，编译器在调用函数时会使用R0~R3来传递前4个符合条件的参数（这里的条件可以简单理解为每个参数的宽度要小于等于32bit）。根据函数原型 void JumpToApp(uint32_t addr); 可知，r0 中保存的就是形参 addr 的值。所以第一句汇编的意思就是：根据 （addr + 0）作为地址读取一个uint32_t型的数据保存到r1中。 第二句汇编中，栈顶指针sp此时实际上指向局部变量 StackAddr，因此其含义就是将通用寄存器r1中的值保存到局部变量 StackAddr 中。 对于局部变量 ResetVector 的读取操作，编译器的处理如出一辙： ResetVector = *(__IO uint32_t *)(addr + 4); 对应： 000016 6840 LDR r0,[r0,#4]00001c 9001 STR r0,[sp,#4] 其实就是从 (addr + 4) 的位置读取 32bit 整数，然后保存到r0里，并随即保存到sp所指向的局部变量 ResetVector 中。到这里，细心地小伙伴会立即跳起来说“不对啊，原文不是这样的！”。是的，这也是最有趣的地方。实际的汇编原文如下： 000016 6840 LDR r0,[r0,#4]000018 f3818808 MSR MSP,r100001c 9001 STR r0,[sp,#4] 作为提醒，它对应的C代码如下： ResetVector = *(__IO uint32_t *)(addr + 4); __set_MSP(StackAddr); 后面的 __set_MSP(StackAddr) 所对应的汇编代码 MSR MSR,r1 居然插入到了ResetVector赋值语句的中间？！ “C语言编译器这么自由的么？” “在我使用sp之前把栈顶指针更新了？！” 先别激动，还记得我们和C语言编译器之间的约定么？C语言编译器默认我们在任何时候都不应该修改栈顶指针。因此在他看来，“你 MSR 指令操作的是r1，关我sp和r0啥事”？“我就算随意更改顺序应该对你一毛钱影响都没有！（因为我不关心、也没法知道用户线汇编语句的具体效果，因此我只关心涉事的通用寄存器是否存在冲突）” 上述“骚操作”的后果是：保存在r0中的Reset_Handler地址值被保存到了新栈中（MSP + 4）的位置。这立即带来两个潜在后果： 由于MSP指向的是栈存储器的末尾（栈是从数值较大的地址向数值较小的地址生长），因此 (MSP+4）实际上已经超出栈的合法范围了。 这一操作与其说是会覆盖栈后续的存储空间，倒不如说风险主要体现在BusFault上——因为相当一部分人习惯将栈放到SRAM的最末尾，而MSP+4直接超出SRAM的有效范围。 我们以为的ResetVector其实已经不在原本C编译器所安排的地址上了。 精彩的还在后面： Jump_To_Application = (pFunction)ResetVector; Jump_To_Application(); 对应的翻译是： 00001e b002 ADD sp,sp,#8000020 4700 BX r0 通过前面的分析，我们知道，此时r0中保存的是Reset_Handler的地址，因此 BX r0 能够成功完成从Bootloader到APP的跳转——也许你会松一口气——好像局部变量ResetVector的错位也没引起严重的后果嘛。 看似如此，但真正吓人的是C语言编译器随后对局部变量的释放： 00001e b002 ADD sp,sp,#8 它与一开始局部变量的分配形成呼应： 000000 b082 SUB sp,sp,#8...00001e b002 ADD sp,sp,#8 好借好还，再借不难。但此sp非彼sp了呀！ 这里由于JumpToApp没有加上__NO_RETURN的修饰，因此C编译器并不知道这个函数是有去无回的，因此仍然会像往常一样在函数退出时释放局部变量。 就像刚才分析的那样：由于MSP指向的是栈存储器的末尾（栈是从数值较大的地址向数值较小的地址生长），因此 (MSP+8）实际上已经超出栈存储空间的合法范围了。 考虑到相当一部分人习惯将栈放到SRAM的最末尾，而MSP+8直接超出SRAM的有效范围，即便刚跳转到APP的时候还不会有事，但凡APP用了任何压栈操作，（无论是BusFault还是地址空间绕回）就很有可能产生灾难性的后果。 【宏观分析】 就事论事的讲，单从汇编分析来看，上述代码所产生的风险似乎是可控的，甚至某些人会觉得可以“忽略不计”。但最可怕的也就在这里，原因如下： 从原理上说，将关键信息保存在依赖栈的局部变量中，然后在编译器不知情的情况下替换了栈所在的位置，此后只要产生对相关局部变量的访问就有可能出现“刻舟求剑”的数据错误。这种问题是“系统性的”、“原理性的”。 （此图由GorgonMeducer借助GPT4进行一系列关键词调校、配上台词后获得） 不同编译器、同一编译器的不同版本、同一版本的不同优化选项都有可能对同一段C语言代码产生不同的编译结果，因此哪怕我们经过上述分析得出某一段汇编代码似乎不会产生特别严重的后果，在严谨的工程实践上，这也只能算做是“侥幸”，是埋下了一颗不知道什么时候以什么方式引爆的定时炸弹。 根据用户Bootloader代码在修改 MSP 前后对局部变量的使用情况不同、考虑到用户APP行为的不确定性、由上述缺陷代码所产生的Bootloader与APP之间配合问题的组合多种多样、由于涉及到用户栈顶指针位置的不确定性以及新的栈存储器空间中内容的随机性，最终体现出来的现象也是完全随机的。用人话说就是，经常性的“活见鬼” 【解决方案】 既然我们知道不能对上述缺陷代码抱有侥幸心理，该如何妥善解决呢？第一个思路：既然问题是由栈导致的，那么直接让编译器用通用寄存器来保存关键局部变量不就行了？修改代码为： typedef void (*pFunction)(void); void JumpToApp(uint32_t addr){ pFunction Jump_To_Application; register uint32_t StackAddr; register uint32_t ResetVector; register uint32_t JumpMask; JumpMask = ~((MCU_SIZE-1)|0xD000FFFF); if (((*(__IO uint32_t *)addr) & JumpMask ) == 0x20000000) //�ж�SPָ��λ�� { StackAddr = *(__IO uint32_t*)addr; ResetVector = *(__IO uint32_t *)(addr + 4); __set_MSP(StackAddr); Jump_To_Application = (pFunction)ResetVector; Jump_To_Application(); }} 相同编译环境下得出的结果为： AREA ||i.JumpToApp||, CODE, READONLY, ALIGN=2 JumpToApp PROC 000002 6801 LDR r1,[r0,#0]000004 4011 ANDS r1,r1,r2000006 2201 MOVS r2,#1000008 0752 LSLS r2,r2,#2900000a 4291 CMP r1,r200000c d104 BNE |L2.24| 00000e 6801 LDR r1,[r0,#0]000010 6840 LDR r0,[r0,#4]000012 f3818808 MSR MSP,r1 000016 4700 BX r0 |L2.24|000018 4770 BX lr ENDP 00001a 0000 DCW 0x0000 |L2.28| DCD 0x2fff0000 可见，上述汇编中半个 sp 的影子都没看到，问题算是得到了解决。 然而，需要注意的是 register 关键字对编译器来说只是一个“建议”，它听不听你的还不一定。加之上述例子代码本身相当简单，涉及到的局部变量数量有限，因此问题似乎得到了解决。 倘若编译器发现你大量使用 register 关键字导致实际可用的通用寄存器数量入不敷出，大概率还是会用栈来进行过渡的——此时，哪些局部变量用栈，哪些用通用寄存器就完全看编译器的心情了。 进一步的，不同编译器、不同版本、不同优化选项又会带来大量不可控的变数。 因此就算使用 register 修饰关键局部变量的方法可以救一时之疾（“只怪老板催我催得紧，莫怪我走后洪水滔天”），也算不得妥当。 第二个思路：既然问题出在局部变量上，我用静态（或者全局）变量不就可以了？修改源代码为： #include "cmsis_compiler.h" typedef void (*pFunction)(void); __NO_RETURNvoid JumpToApp(uint32_t addr){ pFunction Jump_To_Application; static uint32_t StackAddr; static uint32_t ResetVector; register uint32_t JumpMask; JumpMask = ~((MCU_SIZE-1)|0xD000FFFF); if (((*(__IO uint32_t *)addr) & JumpMask ) == 0x20000000) //�ж�SPָ��λ�� { StackAddr = *(__IO uint32_t*)addr; ResetVector = *(__IO uint32_t *)(addr + 4); __set_MSP(StackAddr); Jump_To_Application = (pFunction)ResetVector; Jump_To_Application(); }} 这种方法看似稳如老狗，实际效果可能也不差，但还是存在隐患，因为它“没有完全杜绝编译器会使用栈的情况”，只要我们还会通过 __set_MSP() 在C语言编译器不知道的情况下更新栈顶指针，风险自始至终都是存在的。 对某些连warning都要全数消灭的团队来说，上述方案多半也是不可容忍的。 第三个思路：完全用汇编来处理从Bootloader到App的最后步骤。对此我只想说：稳定可靠，正解。 只不过需要注意的是：这里整个函数都需要用纯汇编打造，而不只是在C函数内容使用在线汇编。 原因很简单：既然我们已经下定决心要追求极端确定性，就不应该使用线汇编这种与C语言存在某些“暧昧交互”的方式——因为它仍然会引入一些意想不到的不确定性。 本着一不做二不休的态度，完全使用汇编代码来编写跳转代码才是万全之策。 【说在后面的话】 在使用栈的情况下，on-fly 的修改栈顶指针就好比在飞行途中更换引擎——不是不行，只是要求有亿点点高。 我在微信群中帮读者分析各类Bootloader的见鬼故障时，经常在大费周章的一通分析和调试后，发现问题的罪魁祸首就是跳转代码。可怕的是，几乎每个故障的具体现象都各不相同，表现出的随机性也常常让人怀疑是不是硬件本身存在问题，亦或是产品工作现场的电磁环境较为恶劣。最要命的当数那种“偶尔出现”而复现条件颇为玄学的情形，甚至在办公室环境下完全无法重现的也大有人在。同样的问题出的多了，我几乎在每次帮人调试Bootloader时都会习惯性的先要求检查跳转代码——虽然不会每次都能猜个正着，但也有个恐怖的十之七八。这也许是某种幸存者偏差吧——毕竟大部分普通问题大家自己总能解决，到我这里的多半就是“驱鬼”了。见得多了，我突然发现，出问题的代码大多使用函数指针来实现跳转——而用局部变量来保存函数指针又成了大家自然而然的选择。加之此前很多文章都曾大规模科普上述技巧，甚至是直接包含一些存在缺陷的Bootloader范例代码，实际受影响的范围真是“细思恐极”。特此撰文，为您解惑。
STM32最小系统板电路知识学习 单片机最小系统是指用最少的电路组成单片机可以工作的系统，通常最小系统包含：电源电路、时钟电路、复位电路、调试/下载电路，对于STM32还需要启动选择电路。总之，刚开始如果不太懂电路的话，就抄别人的电路，然后自己拼凑。下图为stm32c8t6经典电路原理图 文章目录 STM32最小系统板电路知识学习 一、电源转换电路 二、JTAG/SWD调试接口电路 三、时钟电路 四、复位电路 提示：以下是本篇文章正文内容，下面案例可供参考 一、电源转换电路 开发板通常采用USB供电，通常USB都为5V，因此需要将5V转换成3.3V，使用TPS73633或者AMS1117芯片电源芯片即可实现。 首先设计电源入口部分，现在大多数开发板所使用的都是USB的5V供电，所以我们本次设计也采用USB接口供电，所以我们电源接口就采用5Pin的mini贴片的USB，将5V的电源引入开发板使用，其电路图如下，1脚为电源正极，5脚为负极，串接的二极管是为了保护我们的开发板，防止有个别的连接线极性不对烧坏板子，保护电路在我们设计任何电路时都要考虑到，这个大家以后自己设计时也要注意。这样我们就可以通过连接线将5V的USB电源引入到开发板中进行使用了。 接下来便是电源电路，STM32工作电压是DC3.3V，所以我们需要一个能将大于3.3V电压转换为稳定的3.3V电压的芯片，这里我们使用的是TPS73633或者AMS1117芯片电源芯片即可实现。 下图为TPS73633芯片的相关说明，TPS73633DBVR是一款3.3V固定输出低压降（LDO）线性稳压器，采用了一种新的拓扑-电压跟随器配置中的NMOS调整元件。使用具有低ESR的输出电容器，这种拓扑是稳定的，甚至可以在没有电容器的情况下运行。它还提供高反向阻塞（低反向电流）和接地引脚电流，该电流在所有输出电流值上都几乎恒定。该器件使用先进的BiCMOS工艺来产生高精度，同时提供非常低压降（LDO）的电压和低接地引脚电流。未启用时，电流消耗低于1uA，非常适合便携式应用。极低的输出噪声非常适合为VCO供电。该器件受热关断和折返电流限制保护。 二、JTAG/SWD调试接口电路 JTAG/SWD调试接口电路采用了标准的JTAG接法，这种接法兼容SWD接口，因为SWD只需要四根线（SWCLK、SWDIO、VCC和GND）。需要注意的是，该接口电路为JLINK或ST-Link提供3.3V的电源，因此，不能通过JLINK或ST-Link对STM32核心板进行供电，而是STM32核心板为JLINK或ST-Link供电。JLINK和ST-Link不仅可以下载程序，还可以对STM32微控制器进行在线调试。 三、时钟电路 MCU是一个集成芯片，由非常复杂的数字电路和其它电路组成，需要稳定的时钟脉冲信号才能保证正常工作。时钟如同人体内部的心脏一样，是芯片的“动力”来源。时钟产生一次，就推动处理器执行一下指令。除了CPU，芯片上所有的外设(GPIO、I2C、SPI等)都需要时钟，由此可见时钟的重要性。芯片运行的时钟频率越高，芯片处理的速度越快，但同时功耗也越高。为了功耗和性能兼顾，微处理器一般有多个时钟源，同时还将时钟分频为多个大小，适配不同需求的外设。下图为stm32的时钟树 这里我们将两个晶振电路，电源，以及各引脚的网络符号对应连接好即可，除去晶振和电源，其余的标号都是连接在我们引出的排针上边的，晶振电路这里包含了一个8MHz的主晶振，以及一个32.768kHz的内部RTC实时时钟晶振，这里时钟晶振作为预留，如果有用到时钟的小伙伴直接焊接上即可，方便使用，每个晶振后边并联的为起振电容，方便晶振起振，电源部分的电容C3-C7组成了一个低通滤波电路，目的是为了让32更好的工作 四、复位电路 嵌入式系统中，由于外界环境干扰，难免出现程序跑飞或死机，这时就需要复位让MCU重新运行。该电路将一个按键接在了NRST引脚，一旦按键按下，NRST就会接地，拉低NRST，实现复位。
扫码关注面包板社区
