在刚开始接触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，后者可知晓系统数据的缘起缘灭。 这些理论，院校的《软件工程》教材都有，大家不妨借鉴下。只不过那些理论，终究是起源于大型系统软件管理的，牛刀杀鸡，还是要裁剪一下的。
都说MCU本身不算什么高级东西，在MCU开发过程中，需要按照一定的标准化来执行，比如对变量，函数的定义，要确定他的生命周期，调用范围，访问条件等；常用的通信协议读写的协议往往应该抽象化，规定固定的输入输出，方便产品移植。 但实际上，很多时候，针对同一个需求其实有多种实现方案，但总有一个最优解。所以在这个过程中，总会有一些“脑洞大开”的操作，为人提供很多思路，今天就举几个例子给大家作为参考。 那些很惊艳的用法 当需要通过串口接收一串不定长数据时，可以使用串口空闲中断；这样就可以避免每接收到一个字符就需要进入中断进行处理，可以减少程序进入中断次数从而提高效率。 当需要测量一个波形的频率时，很多人会选择外部中断，其实通过定时器的外部时钟输入计数波形边沿，然后定时读取计数值计算频率的方式可以大大减少中断触发频率，提高程序执行效率。 在处理复杂的多任务场景时，可以利用实时操作系统（RTOS）来管理任务调度，提高系统的响应性和资源利用率。 对于需要低功耗运行的场景，可以采用动态电压频率调整（DVFS）技术，根据系统负载实时调整 MCU 的工作电压和频率，以降低功耗。 在进行数据存储时，采用闪存的磨损均衡算法，延长闪存的使用寿命。 利用硬件加密模块（如 AES 加密引擎）来保障数据的安全性和保密性，而不是通过软件实现加密，提高加密效率和安全性。 对于传感器数据的处理，采用数字滤波算法（如卡尔曼滤波），提高数据的准确性和稳定性。 当需要与多个设备进行通信时，采用总线仲裁机制和优先级设置，确保通信的高效和稳定。 在进行电源管理时，通过监测电源电压和电流，实现智能的电源管理策略，例如在低电量时进入低功耗模式。 对于实时性要求极高的控制任务，采用硬件直接触发中断，而不是通过软件轮询，减少响应延迟。 在单片机上跑的任何非线性系统的动态控制，都是高级用法。 用单片机去实现某种特殊的运动控制，赚很多钱，就是高级用法。 GPIO模拟一切 名为ShiinaKaze的网友，就非常“勇”，做了一个很折磨的事。 他用STM32F1利用GPIO模拟摄像头接口驱动OV2640摄像头模块。他表示，这是一个很折磨人的过程，我最多优化到了 1.5 FPSQ，所以选型一定要选好，不要折磨自己。设备采用STM32F103C8T6，OV2640，实现效果如下： OV2640实际时序图： 这个项目难点在于： 1.SCCB 模拟:SCCB 是12C-bus 的改版，主要是 OV2640 模块没有上拉电阻，无法进行通信，花了好长时间才发现这个问题； 2.并行接口的模拟:如果使用 IO 模拟的话，只能达到1FPS，但是使用了 Timer 和 DMA，就可以达到 1.5～2 FPS。 关于 image sensor 的数据接收和处理的问题背景：现有 ov2640 image sensor，接口为 DCMI（并行接口）问题：现有 STM32H7 想获取 OV2640 的 mjpeg 流数据，并通过传输数据到 PC 软件 1.采用 USART 还是 USB？ 2.接收数据选择哪种中断，Line interrupt 还是 Frame interrupt ？ 3.DCMI 通过 DMA 将数据转到 RAM 中的 Buffer，那么 Buffer 该如何设计，是设置一块大的连续 buffer？还是需要做一个 ring buffer，避免数据覆盖和数据顺乱？ 4.触发中断后，是否关闭 DCMI 和 DMA ？ 嵌入式软件架构挺重要的，特别是大型项目。这是 STM32 的软件架构，不知道各位还有没有其他架构。 有网友吐槽，你要是在学校，我敬你是条汉子，你要是在工作岗位上干这鸟事，那你们的架构也太坏了。而他也表示——“我错了，再也不模拟了。” 关于MCU不一样的观点 虽然如此，很多人还是认为，MCU不高级，使用单片机也不高级。高级的内容都是可以发论文的，使用单片机发不了论文。但使用单片机解决指定的任务，这很高级。 尤其是上面所说的一些例子，确实是MCU外设的一些高端玩法。只不过，这些机制可能只是一种标准用法。名为lion187的网友就表示，毕竟许多硬件机制有实际需求后才添加进来的，比如接收不定长数据，最初没有超时中断的情况下只能软件实现，极大的浪费了CPU的效率，所以才设计了超时中断来减少软件工作量，进而形成了一种标准使用方法。 当然，这也是芯片设计和制造工艺的提升带来的红利，早期芯片设计和工艺无法满足复杂外设电路时，谁也不敢会去想用硬件来实现这么复杂的功能，任何产品的开发，都离不开具体业务需求，MCU也不例外， 对产品来说，MCU外设的驱动只是完成开发的基本要素，更多的工作是围绕着业务逻辑展开的应用程序的开发。这时候数据结构与算法，各种控制算法和数值计算方法，设计模式，软件工程和设计理念成了高级的东西。 比如说，Linux 内核中的各驱动子系统的设计，设备对象和驱动对象这些沿用了 C++ 面向对象编程的思路，其实也可以沿用到 MCU的开发中，将设备与驱动分离，就可以使用同一套驱动算法来实现同类设备的不同驱动方法， 比如:同一个 UART 驱动可以根据配置的不同来驱动 UARTO，也可以驱动 UART1，而且波特率也可以不同(只要为 UART 类创建不同的实例对象就可以了，用 C 语言就行)，这就是 C++ 中方法与属性分离带来的好处。 同样在业务应用部分，单件模式、工厂模式等设计模式，状态机模型的使用也会给开发带来很多便利，使系统结构清晰，有效减少Bug数量，且易于维护和扩展。 当然，也有人认为，论高级还得是FPGA。就比如AMD（赛灵思）的ZYNQ，当你需要通过串口接收一串不定长数据时，可以直接用Programmable Logic部分写一个专用的，最终结果放到DRAM里，发个信号通知ARM处理器来读就好了；当你需要测量一个波形的频率时，可以直接用Programmable Logic部分写一个专用的，实时不间断测量。这就很高级。 所以，对此你有什么看法，你有什么很“高级”的用法想要分享？
扫码关注面包板社区
