协议栈

本文将介绍Nordic nRF5 SDK软件架构以及softdevice工作原理，以加深大家对Nordic产品开发的理解，这样开发过程中碰到问题时，大家也知道如何去调试。 如果你刚开始接触Nordic nRF5 SDK，建议先看一下这篇文章“ Nordic nRF5 SDK和softdevice介绍 ”，以建立nRF5 SDK的一些基本知识。 首先说明一下，Nordic nRF5系列产品都是使用Flash存储器的，确切说，是eFlash存储器，也就是说，代码是可以直接在上面运行的，这个跟很多其他BLE厂商是不一样的（他们使用的是nand Flash，代码是不能直接在nand Flash中运行的，必须先装载到RAM中才能跑，所以你会发现这些厂商的RAM都非常大）。Nordic Flash是带cache机制的，以保证大部分代码执行速度可以达到64MHz，在cache失败的时候，等待周期也只有1个cycle，可以说Flash的执行速度和效率都是非常不错的。另外，Nordic芯片是纯Flash产品，里面没有其他NVM，所有非易失性数据都放在Flash中，包括蓝牙协议栈，这也是为什么Nordic蓝牙协议栈也可以OTA的根本原因所在。 Nordic nRF5 SDK将芯片的存储器划分成如下格局： Flash 结构图 从上图可知，Flash存储器最下面放的是softdevice

Nordic是协议栈以hex文件的方式提供，那么app怎么是怎么通过api来调用协议栈的呢。 一、应用层通过API的方式调用协议栈的函数，通过SVC中断方式。 1）SVC的宏定义 #define SVCALL(number, return_type, signature) return_type __svc(number) signature SVCALL(SD_BLE_GAP_DAT A_LENGTH _UPDATE, uint32_t, sd_ble_gap_dat a_length _update(uint16_t conn_handle, ble_gap_dat a_length _params_t const *p_dl_params, ble_gap_dat a_length _limitation_t *p_dl_limitation)) ; 2)当协议栈被使能时，共用了0X10~0XFF，具体来说就是每个API函数对应一个number。通过SVC来调用的功能有： NRF_SOC_SVCS // SoC library，主要是一些外设PPI, FLASH, CLOCK等 NRF_SD_SVCS // SoftDevice Manager, 协议栈管理，主要用来开启关闭协议栈，查询协议栈是否开启，以及在bootloader被enabled时指明中断向量表 BLE

接触过BLE的朋友，我想基本上都听过Nordic吧，如果真有用过BLE的人没听说过这个品牌，那你很大可能性就是骗别人说你做过BLE开发。Nordic是挪威一家只做2.4G频段的无线通讯技术半导体芯片厂商，明年也就是2019年中旬也会推出量产级别兼芯片级的NB-IOT即nRF91，其目前在BLE行业中占据了百分之60以上的市场份额 （数据来源于Nordic官方） ，不得不说这样的数据是相当恐怖的。当然了，Nordic的成功是有原因的，其BLE芯片出色的性能、完善的资料系统以及对工程师相当友好的开发社区等等都是广大用户有目共睹的。简单地介绍完Nordic之后，接下来我们直接进入主题。 不管是新手还是老鸟工程师，接触到之前没有用过的芯片，首先要做的就是去官方网站或者代理商获取芯片相关的文档进行查阅，从而为后面的芯片开发铺路或者打下基础。理所当然，对于Nordic 52840也是这样，所有的资料均可在官方网站下载得到，但是对从来没有用过Nordic BLE芯片的人来说，肯定是一脸懵逼的，有的人可能在哪里下载到相关的文档都不知道。大家莫慌，随我慢慢道来，但是我不会马上就告诉你相关的文档在哪里下载，因为写这篇文章就是让你初识Nordic 52840，假设直接就告诉你相关的文档在哪里，那么你看了这篇文章就等于没看。因此，要想知道如何开发这个芯片，就应该先看看这个芯片相关的框架。 我们

5G NR协议栈及功能2 - MAC RLC PDCP SDAP 　　备注：本文所有图片均来自3GPP标准，包括3GPP TS 38.300 V15.0.0 (2017-12)和3GPP TS 38.202 V15.0.0 (2017-12)等。本文主要介绍截止目前（2018年1月25日），3GPP 5G NR相关的协议内容，后期可能会有更新。 　　本系列共分为两部分： 　　1. 5G NR协议栈及功能1 - 总体架构与物理层 http://blog.csdn.net/jxwxg/article/details/79160245 http://blog.csdn.net/jxwxg/article/details/79160449 一 层2功能介绍 　　NR层2包含SDAP、PDCP、RLC和MAC层。 二 MAC层 2.1 MAC层实体 　　MAC层实体如下图所示： 　　当配置了双链接时，MCG和SCG的MAC层实体如下图所示： 2.2 服务和功能 2.3 逻辑信道 　　逻辑信道根据传输信息的类型来区分。逻辑信道主要分为两类：控制信道和业务信道。 　　业务信道用于传输用户平面的信息，包含以下逻辑信道： 2.4 逻辑信道&传输信道&物理信道映射 　　逻辑信道按照传输信息类型区分，所以不存在上下行。传输信道按照信息怎么传输区分，所以区分上下行传输信道。 （图片来自 www

转自： https://www.cnblogs.com/onepixel/p/7092302.html TCP/IP 协议栈是一系列网络协议的总和，是构成网络通信的核心骨架，它定义了电子设备如何连入因特网，以及数据如何在它们之间进行传输。TCP/IP 协议采用4层结构，分别是 应用层、传输层、网络层和链路层 ，每一层都呼叫它的下一层所提供的协议来完成自己的需求。由于我们大部分时间都工作在应用层，下层的事情不用我们操心；其次网络协议体系本身就很复杂庞大，入门门槛高，因此很难搞清楚TCP/IP的工作原理，通俗一点讲就是， 一个主机的数据要经过哪些过程才能发送到对方的主机上 。 接下来，我们就来探索一下这个过程。 0、物理介质 物理介质就是把电脑连接起来的物理手段，常见的有光纤、双绞线，以及无线电波，它决定了电信号(0和1)的传输方式，物理介质的不同决定了电信号的传输带宽、速率、传输距离以及抗干扰性等等。 TCP/IP协议栈分为四层，每一层都由特定的协议与对方进行通信，而 协议之间的通信最终都要转化为 0 和 1 的电信号，通过物理介质进行传输才能到达对方的电脑 ，因此物理介质是网络通信的基石。 下面我们通过一张图先来大概了解一下TCP/IP协议的基本框架： 当通过http发起一个请求时，应用层、传输层、网络层和链路层的相关协议依次对该请求进行包装并携带对应的 首部 ，最终在链路层生成

转载地址： https://blog.csdn.net/angle0615303/article/details/7716151 Uip源代码可以从 http://www.sics.se/~adam/uip/index.php/Main_Page 上下载得到。 ├―apps ├―doc ├―lib ├―sourceinsight ├―uip └―unix App目录是一些应用层的协议和实例，Doc目录是文档，lib目录下有内存块管理函数，uip下uip协议栈的源代码，unix下是unix环境里的uip应用例子。 研究unix下的代码可以知道uip是如何使用的，关键是理解uip协议栈的主控制循环。 int main(void) { #if UIP_UDP #endif /* UIP_UDP */ } 文章来源: uip协议栈分析（1）

来源： https://www.cnblogs.com/wanpengcoder/p/11764946.html

TCP/IP协议栈 应用层 FTP SMTP HTTP 传输层 TCP UDP 网络层 IP ICMP IGMP 链路层 ARP RARP 来源： https://www.cnblogs.com/Gdavid/p/11744082.html

L2CAP协议概述 L2CAP中文为逻辑链路适配层，主要提供信息数据的分割/重组等传输方式。在bluedroid中，很多的上层会向l2cap注册相关服务，比如rfcomm（虚拟串口，最多可虚拟64路），sdp，gatt等。 1、L2CA_Register (SDP_PSM, &sdp_cb.reg_info) 2、L2CA_Register (BT_PSM_ATT, (tL2CAP_APPL_INFO *) &dyn_info) l2cap的框架结构图如下、 一、通道标识符 l2cap传输是基于信道的概念进行传输，没一个信道都有各自的信道标识符(channel identify,CID),在HCI层完成相关初始化后，信道就会被创建，在ACL链路中通常需要创建一个CID为0x0001的控制信道，用于传输控制命令。 CID为2byte，具体如下图所示（通常用于ER( 常规蓝牙 )传输ACL,ASB和AMP链路） 而在 低功耗蓝牙 中，需要使用如下的CID进行表示 二、信道工作模式 逻辑信道可以工作在5种不同的模式下（可以理解为5种不同的使用场景），最后一种是LE设备特有的： 1、 Basic L2CAP Mode (equivalent to L2CAP specification in Bluetooth v1.1) 默认模式，在未选择其他模式的情况下，用此模式。 2、 Flow

bootloader的程序区域是0X78000~0X7E000 但是在bootloader程序中定义了0X0FF8与0XFFC位置处的数据，此数据与BLE协议栈冲突，BLE协议栈的flash范围是0~0X25FFF，所以烧录协议栈后不能用JLINK仿真 具体在bootloader中的代码为： /** @brief Location (in the flash memory) of the bootloader address. */ #define MBR_BOOTLOADER_ADDR (0xFF8) /** @brief Location (in UICR) of the bootloader address. */ #define MBR_UICR_BOOTLOADER_ADDR (&(NRF_UICR->NRFFW[0])) /** @brief Location (in the flash memory) of the address of the MBR parameter page. */ #define MBR_PARAM_PAGE_ADDR (0xFFC) uint32_t const m_uicr_mbr_params_page_address __attribute__((at(NRF_UICR_MBR_PARAMS_PAGE_ADDRESS))) = NRF