Jan 17, 2024
本文阅读量次CPU体系架构 # 2.1 CPU体系架构有哪些？ # 我们常见的CPU架构有哪些呢？
如果我们熟悉Linux，那么这个问题肯定不难回答！
我们查看内核目录下的arch子目录，就可以看到Linux所支持的处理器架构，基本属于我们常见的类型了。
# ls ./arch alpha arc arm arm64 c6x h8300 hexagon ia64 Kconfig m68k microblaze mips nds32 nios2 openrisc parisc powerpc riscv s390 sh sparc um unicore32 x86 xtensa 准确来说，CPU处理器架构主要有以下几种类型：
CISC（复杂指令集计算机）：CISC架构的CPU设计理念是尽可能减少程序指令的数量，以降低CPU和内存之间的通信频率。这种架构的一个显著特点是拥有大量的寄存器和复杂的指令集。Intel的x86架构就是一个典型的CISC架构 RISC（精简指令集计算机）：RISC架构的CPU设计理念是通过简化指令集来提高CPU的运行效率。这种架构的一个显著特点是拥有较少的寄存器和简单的指令集。ARM架构就是一个典型的RISC架构 MISC（中间指令集计算机）：MISC架构的CPU设计理念是在CISC和RISC之间寻找一个平衡点，既不过于复杂也不过于简单。这种架构的一个显著特点是指令集的复杂度介于CISC和RISC之间 VLIW（超长指令字计算机）：VLIW架构的CPU设计理念是通过增大指令长度来提高并行执行的可能性。这种架构的一个显著特点是指令长度远大于其他架构的CPU EPIC（显式并行指令计算）：EPIC架构的CPU设计理念是通过显式标记并行指令来提高CPU的运行效率。这种架构的一个显著特点是指令集中包含了并行执行的信息。Intel的Itanium架构就是一个典型的EPIC架构 超标量架构：超标量架构的CPU设计理念是通过在一个时钟周期内执行多条指令来提高CPU的运行效率。这种架构的一个显著特点是CPU内部包含了多个执行单元，可以同时执行多条指令 超线程技术：超线程技术是Intel公司为其部分CPU所采用的一种使单一处理器像多个逻辑处理器那样并行处理多个线程的技术 多核心架构：多核心架构的CPU设计理念是在一个CPU芯片内集成多个处理器核心，以提高并行处理能力。这种架构的一个显著特点是CPU内部包含了多个独立的处理器核心，每个核心可以独立执行指令 这里就有一个疑问，我们什么时候说RISC架构，什么时候说ARM架构，这两个有什么区别呢？
以ARM和RISC为例：
ARM架构和RISC架构的主要区别在于ARM实际上是RISC的一个具体实现，而RISC则是一个更广泛的处理器设计理念。换句话说，ARM是RISC的一个子集。
同理，X86架构是CISC的一个子集。
2.2 常见的问题 # Q1：你所熟知的处理器架构有哪些？
我们常见的处理器架构有ARM、X86、mips架构等；
Q2：STM32属于什么架构的？
STM32是ST公司开发的32位微控制器集成电路，基于 ARM 的 Cortex-M 系列内核。因此，STM32 属于 ARM 架构的微控制器。
Q3：RISC和CISC的区别是什么？
RISC：精简指令集架构，通过简化指令集，使得大多数的操作都能够在一个指令周期内完成，提高CPU运行效率 CISC：复杂指令集架构，指令集丰富，能够完成一些较为复杂的任务，并且可以降低CPU和内存之间的通信频率，提高性能。 欢迎关注【嵌入式艺术】，董哥原创！
Jan 17, 2024
本文阅读量次【一文秒懂】TOP命令详解 # 1、Top命令介绍 # Linux系统中，Top命令主要用于实时运行系统的监控，包括Linux内核管理的进程或者线程的资源占用情况。
这个命令对所有正在运行的进程和系统负荷提供不断更新的概览信息，包括系统负载、CPU利用分布情况、内存使用、每个进程的内容使用情况等信息。
2、Top命令使用 # Top的命令介绍如下：
top -hv|-bcHiOSs -d secs -n max -u|U user -p pid -o fld -w [cols] 常用的Top指令有：
top：启动top命令 top -c：显示完整的命令行 top -b：以批处理模式显示程序信息 top -S：以累积模式显示程序信息 top -n 2：表示更新两次后终止更新显示 top -d 3：设置信息更新周期为3秒 top -p 139：显示进程号为139的进程信息，CPU、内存占用率等 top -n 10：显示更新十次后退出 除此之外，在top进程运行过程中，两个最重要的功能是查看帮助（h 或 ？）和退出（q 或 Ctrl+C）。
3、Top信息详解 # top展示界面由从上到下3部分组成
概览区域 表头 任务区域 还有一个输入/消息行，位于概览区域和表头之间。 3.1 概览区详解 # top - 14:46:08 up 5:46, 1 user, load average: 0.00, 0.00, 0.
...
Jan 17, 2024
本文阅读量次Linux内存管理 | 二、虚拟地址空间布局 # 上一章，我们了解了内存管理的由来以及核心思想，下面我们按照顺序，先来介绍一下Linux虚拟内存空间的管理。
同样，我们知道Linux内核抽象出来虚拟内存空间，主要是为了让每个进程都独享该空间，那虚拟内存空间是如何布局的呢？
前提：针对于不同位数的CPU，寻址能力不同，抽象出来的虚拟内存空间大小也不同，我们以常见的32位的CPU为例。
1、虚拟内存空间布局 # 对于32位的CPU，寻址范围为0~2^32，也就是0x00000000-0xFFFFFFFF，即最多抽象出来4G的虚拟内存空间。
这4GB的内存空间，在Linux中，又分为用户空间和内核空间，其中0x0000000-0xBFFFFFFF，共3G为用户空间，0xC00000000-0xFFFFFFFF，共1G为内核空间，如下：
无论内核空间还是用户空间，其仍然是在虚拟内存空间基础之上进行划分的，其直接访问的依旧都是虚拟地址，而非物理地址！
我们编写代码后，所生成的可执行程序，运行之后就成为一个系统进程，我们在"虚"的角度来看，每个进程都是独享这4G虚拟地址空间的，
2、用户态空间布局 # 如上所述，用户空间在虚拟内存中分布在0x0000000-0xBFFFFFFF，大小为3G。
每一个用户进程，按照访问属性一致的地址空间存放在一起的原则，划分成5个不同的内存区域（访问属性一致指的是：可读，可写，可执行）：
代码段：Text Segment，也就是我们的二进制程序，代码段需要防止在运行时被非法修改，所以该段为只读。 数据段：Data Segment，主要存放初始化了的变量，主要包括：静态变量和全局变量，该段为读写。 BSS段：BSS Segment，主要存放未初始化的全局变量，在内存中 bss 段全部置零，该段为读写。 堆段：Heap Segment，主要存放进程运行过程中动态分配的内存段，大小不固定，可动态扩张和缩减，通常使用malloc和free来分配释放，并且堆的增长方向是向上的。 文件映射和匿名映射段：Memory Mapping Segment，主要存放进程使用到的文件或者依赖的动态库，从低地址向上增长。 栈段：Stack Segment，主要存放进程临时创建的局部变量，函数调用上下文信息等，栈向下增长。 一个可执行程序，可以通过size命令，查看编译出来的可执行文件大小，其中包括了代码段，数据段等数据信息，如下:
donge@Donge:$ size Donge-Demo text data bss dec hex filename 12538 1916 43632 58086 e2e6 Donge-Demo text：代码段大小 data：数据段大小 bss：bss段大小 dec：十进制表示的可执行文件大小 hex：十六进制表示的可执行文件大小 运行该程序后，可以通过cat /proc/PID/maps命令，或者pmap PID命令，来查看该进程在虚拟内存空间中的分配情况，其中PID为进程的PID号，如下:
donge@Donge:$ cat /proc/16508/maps 55976ff9e000-55976ffa0000 r--p 00000000 08:10 184922 /home/donge/WorkSpace/Program/Donge_Programs/Donge_Demo/build/Donge-Demo 55976ffa0000-55976ffa2000 r-xp 00002000 08:10 184922 /home/donge/WorkSpace/Program/Donge_Programs/Donge_Demo/build/Donge-Demo 55976ffa2000-55976ffa3000 r--p 00004000 08:10 184922 /home/donge/WorkSpace/Program/Donge_Programs/Donge_Demo/build/Donge-Demo 55976ffa3000-55976ffa4000 r--p 00004000 08:10 184922 /home/donge/WorkSpace/Program/Donge_Programs/Donge_Demo/build/Donge-Demo 55976ffa4000-55976ffa5000 rw-p 00005000 08:10 184922 /home/donge/WorkSpace/Program/Donge_Programs/Donge_Demo/build/Donge-Demo 55976ffa5000-55976ffaf000 rw-p 00000000 00:00 0 559771d91000-559771db2000 rw-p 00000000 00:00 0 [heap] 7fec1ad84000-7fec1ad87000 rw-p 00000000 00:00 0 7fec1ad87000-7fec1adaf000 r--p 00000000 08:10 22282 /usr/lib/x86_64-linux-gnu/libc.
...
Dec 13, 2023
本文阅读量次【Linux API 揭秘】container_of函数详解 # Linux Version：6.6
Author：Donge
Github：linux-api-insides
1、container_of函数介绍 # container_of可以说是内核中使用最为频繁的一个函数了，简单来说，它的主要作用就是根据我们结构体中的已知的成员变量的地址，来寻求该结构体的首地址，直接看图，更容易理解。
下面我们看看linux是如何实现的吧
2、container_of函数实现 # /** * container_of - cast a member of a structure out to the containing structure * @ptr: the pointer to the member. * @type: the type of the container struct this is embedded in. * @member: the name of the member within the struct. * * WARNING: any const qualifier of @ptr is lost. */ #define container_of(ptr, type, member) ({ \ void *__mptr = (void *)(ptr); \ static_assert(__same_type(*(ptr), ((type *)0)->member) || \ __same_type(*(ptr), void), \ "pointer type mismatch in container_of()"); \ ((type *)(__mptr - offsetof(type, member))); }) 函数名称：container_of
...
Nov 17, 2023
本文阅读量次
二、uboot启动流程分析 # 上一篇文章：（一）uboot基础了解 下一篇文章：（三）Uboot驱动模型
同大多数的Bootloader一样，uboot的启动过程也分为BL1、BL2两个阶段，分别对应着SPL和Uboot。
SPL（BL1阶段）：负责开发板的基础配置和设备初始化，并且搬运Uboot到内存中，由汇编代码和少量的C语言实现
Uboot（BL2阶段）：主要负责初始化外部设备，引导Kernel启动，由纯C语言实现。
我们这篇文章，主要介绍Uboot（BL2阶段）的启动流程，BL1阶段启动流程的详细分析，可以见我的后续文章。想要深入了解的，可以好好研究下！
2.1、程序执行流程图 # 我们先总体来看一下Uboot的执行步骤，这里以EMMC作为启动介质，进行分析！
无论是哪种启动介质，基本流程都相似，我们这就往下看！
==打开图片，结合文档、图片、代码进行理解！==
2.2、u-boot.lds——Uboot的入口函数 # u-boot.lds：是uboot工程的链接脚本文件，对于工程的编译和链接有非常重要的作用，决定了uboot的组装，并且u-boot.lds链接文件中的ENTRY(_start)指定了uboot程序的入口地址。
如果不知道u-boot.lds放到在哪里，可以通过find -name u-boot.lds查找，根目录要进入到uboot的源码的位置哦！
如果查找结果有很多，结合自己的板子信息，确定自己使用的u-boot.lds。
当然，准确的方法是查看Makefile文件，分析出来u-boot.lds所生成的位置。
在u-boot.lds的文件中，可以看到.text段，存放的就是执行的文本段。截取部分代码段如下：
OUTPUT_FORMAT("elf32-littlearm", "elf32-littlearm", "elf32-littlearm") OUTPUT_ARCH(arm) ENTRY(_start) SECTIONS { . = 0x00000000; @起始地址 . = ALIGN(4); @四字节对齐 .text : { *(.__image_copy_start) @映像文件复制起始地址 *(.vectors) @异常向量表 arch/arm/cpu/armv7/start.o (.text*) @启动函数 } ...... } ENTRY(_start)：程序的入口函数，_start在arch/arm/lib/vectors.S中定义.globl _start
SECTIONS定义了段，包括text文本段、data数据段、bss段等。
__image_copy_start在System.map和u-boot.map中均有定义
arch/arm/cpu/armv7/start.o对应文件arch/arm/cpu/armv7/start.S，该文件中定义了main函数的入口。
Tip：上面只进行大概分析，有汇编经验的朋友，可以详细进行分析！
2.3、board_init_f——板级前置初始化 # 跟随上文的程序执行流程图，我们看board_init_f这个函数。其位于common/board_f.c。
void board_init_f(ulong boot_flags) { gd->flags = boot_flags; gd->have_console = 0; if (initcall_run_list(init_sequence_f)) hang(); } static const init_fnc_t init_sequence_f[] = { setup_mon_len, .
...
Jan 20, 2024
本文阅读量次WiFi无缝漫游详解 # 1、WLAN漫游简介 # 百度百科：：当网络环境存在多个相同SSID的AP，且它们的覆盖范围的重合时，无线用户可以在整个WLAN覆盖区内移动，无线网卡能够自动发现附近信号强度最大的AP，并通过这个AP收发数据，保持不间断的网络连接，这就称为无线漫游。
简单来说：WLAN漫游是指STA在不同的AP覆盖范围之间移动，且保持用户业务不中断的行为。
AP：也就是无线接入点，是一个无线网络的创建者，是网络的中心节点。一般家庭或办公室使用的无线路由器就一个AP。 STA：每一个连接到无线网络中的终端(如笔记本电脑、PDA及其它可以联网的用户设备)都可称为一个站点。 如下图所示，STA1从AP1的覆盖范围移动到AP2的覆盖范围时保持业务不中断。
2、WiFi漫游由来 # 当家庭面积超过一定面积后，为了保证全家范围的wifi网络覆盖，我们就需要引入2个以上的WiFi接入点了。在多个WiFi接入点下，为了优化网络使用体验，免去手动切换wifi接入的麻烦，就需要引入WiFi漫游。
伪漫游： 一般最常见的伪漫游方法就是将2个以上的wifi接入点的SSID名称及密码设置相同，虽然起到了一定的切换作用，不过用过的朋友都知道效果非常的不好，先不说能否自动切换的问题，就算切换成功了，也会造成IP地址的改变，游戏掉网、断连接是必须的！因此在多AP情况下就必须引入一个新的名词：Wifi快速漫游
WiFi漫游 上文提到的设置SSID名称及密码相同的方案是最低能的做法，稍微懂一点网络知识的朋友都不会采用的；
最次的方案也是要保证DHCP服务器的统一，保证切换Wifi时候IP地址不变。
更进一阶，引入AC控制器，利用AC+AP的组合形式实现wifi漫游。目前市面上主流的TPlink、爱快、Mesh等产品的方案多是如此。
其根本的原理是通过AC设定AP的RSSI阈值，将信号不稳定的设备T下线，迫使终端设备重新连接信号最强的AP，实现AP的自动切换。
实话实说这种方案对于绝大多数的用户是完全够用的，AP切换过程中网络中断时间一般在200ms-500ms左右，影响不大，确实优化了网络体验。对于网络要求不高的朋友推荐选择。不过在该方案下游戏会有一段明显的卡顿，但不会掉线。
WiFi快速漫游 如果你是一个追求完美网络体验的朋友，而且想一次到位部署网络，不再折腾了，那么你就需要Wifi快速漫游了。上面介绍的第二种方案，虽然效果说得过去，但仍然无法保证切换过程尽可能的少丢包及进一步缩短网络中断时间。这个时候就必须引入Wifi快速漫游方案了，通过Wifi快速漫游进一步缩短网络中断时间，提高网络使用体验，真正实现游戏中不卡顿
对于有AC控制器的Wifi网络系统中，漫游过程可以简单分为3个阶段：漫游触发→选择新AP→重新认证。这时候就需要802.11k/v/r协议登场了。
由于Wifi网络密码的存在，在重新认证阶段终端在切换AP的时候需要出示其缓存的密钥，AP检查密钥并进行四次握手，产生数据加密密钥，漫游完成。802.11r协议可以在以上基础上省略4次握手，进一步缩减了断网的时间。 802.11k能告诉终端，如何快速选择漫游AP。 802.11v能优化漫游触发。 能够应用802.11k/v/r协议的Wifi漫游都可以称之为快速漫游，不过这需要AP和终端都支持哦，实际上目前能够支持802.11k/v/r协议的终端并不多，苹果算是一个例外吧，新产品全都支持802.11k/v/r，所以Wifi快速漫游更适合使用苹果的土豪们
综上，WLAN漫游策略主要解决以下问题：
避免漫游过程中的认证时间过长导致丢包甚至业务中断：802.1x认证、Portal认证等认证过程报文交互次数和时间，大于WLAN连接过程，所以漫游需要避免重新认证授权及密钥协商过程。 保证用户授权信息不变：用户的认证和授权信息，是用户访问网络的通行证，如果需要漫游后业务不中断，必须确保用户在AC上的认证和授权信息不变 保证用户IP地址不变：应用层协议均以IP地址和TCP/UDP Session为用户业务承载，漫游后的用户必须能够保持原IP地址不变，对应的TCP/UDP Session才能不中断，应用层数据才能够保持正常转发 3、漫游基础知识 # WLAN漫游的网络架构
AC控制器：可用来集中化控制和管理无线AP，是一个无线网络的核心，负责管理无线网络中的所有无线AP，对AP管理包括：下发配置、修改相关配置参数、射频智能管理、接入安全控制等。 漫游组：在WLAN网络中，可以对不同的AC进行分组，STA可以在同一个组的AC间进行漫游，这个组就叫漫游组。如图，AC1和AC2组成一个漫游组。 AC间隧道：为了支持AC间漫游，漫游组内的所有AC需要同步每个AC管理的STA和AP设备信息，因此在AC间建立一条隧道作为数据同步和报文转发的通道。 Master Controller：STA在同一个漫游组内的AC间进行漫游，需要漫游组内的AC能够试别组内其他AC。通过选定一个AC作为Master Controller，在该AC上维护漫游组成员表，并下发到漫游组内AC，使各AC之间相互试别并建立AC间隧道，如图，选的AC1作为Master Controller. Master Controller既可以是漫游组外的AC，也可以在漫游组内选择一个AC Master Controlle管理其他AC的同时，不能被其他Master Controlle管理 AC内漫游：如果漫游过程中关联的是同一个AC，则是AC内漫游，如图STA从AP1漫游到AP2即是AC内漫游 AC间漫游：如果漫游过程中关联的不是同一个AC，则是AC间漫游，如图STA在从Ap1漫游到AP3的过程即为AC间漫游 HAC （Home AC）：STA首次与漫游组内某个AC进行关联，则该AC为它的HAC HAP （Home AP）：STA首次与漫游组内某个AP进行关联，则该AP为它的HAP FAC（Foreign AC）：STA漫游后关联的AC即为它的FAC FAP（Foreign AP）：STA漫游后关联的AP即为它的FAP 4、漫游的分类 # 漫游根据实际的架构我们将它分为两类：有缝漫游和无缝漫游。无缝漫游又可以分为二层漫游和三层漫游。
有缝漫游：有两种情况
所有网络部署的AP是胖AP，没有AC。 所有网络部署的AP是瘦AP，没有AC也可以工作。 胖瘦AP的区别：https://zhuanlan.zhihu.com/p/64648479
上面两种情况，主要是我们国情产生的，客户不停的压价还要一大堆需要。大家为了降低成本，没有部署AC。只需要SSID、加密配置和信道岔开即可。实际效果第中远好于第一种，因为第二种是在一个DHCP下，第一种就相当安装了很多的家用路由器，问题多多!
无缝漫游：
...
Jan 19, 2024
本文阅读量次为什么 Linux 内核中不经常使用 typedef？ # 我们在进行Linux驱动开发过程中，有没有出现过这样的报错？
WARNING: do not add new typedefs 不允许使用typedef！
虽然只是一个警告，但是如果你想往开源仓库提交代码，这就是一个必优化项。
那么，为什么Linux内核不建议使用typedef呢？
1、Linus Torvalds 的态度 # > On Mon, 10 Jun 2002, Linus Torvalds wrote: > > –snip/snip > > But in the end, maintainership matters. I personally don’t want the > > typedef culture to get the upper hand, but I don’t mind a few of them, and > > people who maintain their own code usually get the last word.
...
Jan 19, 2024
本文阅读量次【一文秒懂】Linux内核调试工具——Debugfs # 1、介绍 # Debugfs其存在的主要意义是为了内核开发者向用户空间传递更多有用的信息，与proc不同，proc只提供进程相关的信息；同时也与sysfs不同，sysfs对每个文件都要求一定的规则，而Debugfs没有任何的规则。
简而言之，Debugfs是一种用于内核调试的虚拟文件系统。
2、如何调试 # 2.1 配置Debugfs # 进去menuconfig选项中，按下/搜索CONFIG_DEBUG_FS关键词即可！
当然，可以看Location在内核中的位置。
2.2 挂载Debugfs # mount -t debugfs none /sys/kernel/debug #挂载 mount #查看挂载情况 ___ none on /sys/kernel/debug type debugfs (rw,relatime) 2.3 GPIO调试 # cat gpio gpio-43 ( |wakeup ) in lo IRQ gpio-64 ( |cd ) in lo IRQ 上述只是简单的调试GPIO的方法，而Debugfs功能远不止于此，其提供了一些API接口，方便我们在内核中Debug使用。
而我们要做的，就是在我们想要进行Debug的地方，注册debugfs接口，然后查看我们要调试的信息。
2.4 GPIO的实现 # 文件kernel\drivers\gpio\gpiolib.c中
`static const struct file_operations gpiolib_operations = { .owner = THIS_MODULE, .open = gpiolib_open, .
...
Jan 19, 2024
本文阅读量次【MMC子系统】三、MMC子系统框架 # 上章，我们简单了解了EMMC协议，感兴趣的可以查阅一下SD和SDIO的协议，之所以Linux内核能够对SD、SDIO、EMMC进行统一管理，根本原因就是三者协议上的相似性，我们该系列文章均以EMMC为剑，一层层划开包裹着的盔甲。
本系列文章，均以Linux 4.19为参考
1、MMC子系统框架 # 如上图所示，MMC子系统的整体框架包括：MMC Host、MMC Core、MMC Block。我们从下网上看：
MMC HOST：即MMC控制器驱动层，正如其名，该层主要是为了实现MMC控制器的初始化，以及MMC底层的数据收发操作，其直接控制的是底层寄存器，用以产生相应的通信时序。 MMC CORE：即MMC核心层，该层主要起到了承上启下的作用。对下，主要体现在注册MMC总线，实现对MMC device和MMC driver的统一管理；对上，体现在实现MMC通信协议，并向上提供相应的读写操作接口。 MMC BLOCK：即MMC块设备驱动层，其主要作用是屏蔽底层的实现逻辑，将底层抽象为卡设备，并且与虚拟文件系统关联，负责块设备请求的处理以及请求队列的管理，又称为card卡驱动。 哈哈，简单吧，我们刚开始对MMC子系统框架就先了解这么多，不着急，慢慢来。
2、MMC子系统文件结构 # 了解完MMC子系统后，我们看一下MMC驱动在Linux下的目录结构，我们进入到drivers/mmc目录
drivers/mmc/ ├── core ├── block.c ├── bus.c ├── core.c ├── mmc.c ├── mmc_ops.c ├── ...... ├── host ├── sunxi-mmc.c ├── ...... 这里介绍一个方法
如果刚接触的朋友，不知道文件之间的关系是怎么样的，可以通过Makefile和Kconfig文件来大致看一下。
obj-$(CONFIG_MMC) += mmc_core.o mmc_core-y := core.o bus.o host.o \ mmc.o mmc_ops.o sd.o sd_ops.o \ sdio.o sdio_ops.o sdio_bus.o \ sdio_cis.o sdio_io.o sdio_irq.o \ slot-gpio.o 由上面可知，MMC CORE核心层，包括的文件有：core.
...
Jan 19, 2024
本文阅读量次【Bluetooth|蓝牙开发】三、一篇文章，带你总览蓝牙协议 # 1、前言 # 在我们上一章节，学习了蓝牙的基础概念，发展历程，以及常见的蓝牙架构，相信大家对蓝牙也有了一定的了解！
为了更好的去踏入蓝牙开发的大门，蓝牙协议栈是一个我们不得不去跨越的门槛！
蓝牙协议及其复杂，并非一文能够道尽，本篇文章主要在于对蓝牙整体的协议架构进行梳理，文末官方协议附下载链接。
2、蓝牙芯片架构 # 蓝牙的核心架构，由一个Host和一个或多个Controller组成。
BT Host：一个逻辑实体，在HCI（Host Controller Interface）的上层。 BT Controller：一个逻辑实体，在HCI（Host Controller Interface）的下层。 Bluetooth的主控制器，可能是以下几种：
BR/EDR Controller：内部包含Radio, Baseband，Link Manager，可选的HCI。 LE Controller ：内部包含LE PHY，Link Layer ，可选的HCI BR/EDR & LE Controller ：BR/EDR与LE的组合的控制器 MAC/PHY (AMP) Controller：二级控制器，可替代的，内部包含 802.11 PAL (Protocol Adaptation Layer)，802.11 MAC，PHY，可选的HCI。 根据Host与Controller的组成关系，常见的蓝牙芯片也分为以下几种架构：
单模蓝牙芯片：单一传统蓝牙的芯片，单一低功耗蓝牙的芯片。即（1个Host结合1个Controller） 双模蓝牙芯片：同时支持传统蓝牙和低功耗蓝牙的芯片。即（1个Host结合多个Controller） 如下图：
3、蓝牙协议架构——视角1 # ==上图为官方协议中所提及的图片，由全局到局部来看==
3.1 全局分析 # 由下到上分析
Controller：
BR/EDR Controller：由BR/EDR Radio、Link Controller、Link Manager组成 LE Controller：由 LE Radio 、Link Controller、Link Manager组成 AMP Controller：由, AMP PHY 、AMP MAC, 、AMP PAL组成 Host：
...