CoAP（Constrained Application Protocol，受限应用协议）是一种计算机协议，专门用于资源受限的物联网设备，具有轻量级、可靠传输和高效数据交换的特点，适用于资源受限的环境。 由于物联网设备的内存和计算能力有限，传统的 HTTP 协议在这些设备上显得过于庞大和复杂。因此，IETF 的 CoRE 工作组提出了基于 REST 架构的 CoAP 协议（ RFC 7252）。 CoAP 协议有两个不同的层：消息负载和请求/响应层。消息层处理 UDP 和异步消息，而请求/响应层基于请求/响应消息来管理请求/响应交互。CoAP 消息模型是 CoAP 的最低层，处理端点之间的 UDP 交换消息。每个 CoAP 消息都有一个唯一的 ID，这有助于检测消息重复。CoAP 协议使用两种消息：确认消息和不可确认的消息。确认消息是可靠消息，客户端可以使用这种消息确保消息将到达服务器。而不可确认的消息则不需要服务器确认。 协议特点 CoAP 协议网络传输层由 TCP 改为 UDP，以适应资源受限设备的需要。 它基于 REST 架构，这意味着服务器上的资源地址与互联网中的 URL 格式类似。客户端可以使用类似于 HTTP 的 POST、GET、PUT 和 DELETE 方法来访问服务器，这使得对 HTTP 的请求进行了简化。 CoAP 采用二进制格式，相比之下，HTTP 是文本格式，因此 CoAP 更加紧凑，可以减少传输的数据量。 CoAP 协议轻量化，最小长度仅为 4B，相比之下，一个 HTTP 头部可能达到几十个字节。 CoAP 支持可靠传输、数据重传和块传输，确保数据可靠到达。 CoAP 还支持 IP 多播，这意味着可以同时向多个设备发送请求。 CoAP 采用非长连接通信，适用于低功耗物联网场景。这与 TCP 的机制类似，对方必须确认收到消息，以实现可靠的消息传输。 消息类型 CoAP 协议有 4 种消息类型：CON、NON、ACK、RST CON：需要被确认的请求，如果 CON 请求被发送，那么对方必须做出响应。 NON：不需要被确认的请求，如果 NON 请求被发送，那么对方不必做出回应。这适用于消息会重复频繁的发送，丢包不影响正常操作。 ACK：应答消息，对应的是 CON 消息的应答。 RST：复位消息，可靠传输时候接收的消息不认识或错误时，不能回 ACK 消息，必须回 RST 消息。 消息格式 消息头 必备，固定 4 个 byte。 Ver：2 bit，版本信息，当前为 0x01。 T： 2 bit， 消息类型，包括 CON, NON, ACK, RST 这 4 种。 TKL：4 bit，token 长度， 当前支持 0 ~ 8 B 长度，其他长度保留将来扩展用。 Code：8 bit，分成前 3 bit（0 ~ 7）和后 5 bit（0 ~ 31），前 3 bit 代表类型。 0.00 Indicates an Empty message 0.01-0.31 Indicates a request 1.00-1.31 Reserved 2.00-5.31 Indicates a response. 6.00-7.31 Reserved Message ID：16 bit， 代表消息 MID，每个消息都有一个 ID ，重发的消息 MID 不变。在一次会话中 ID 总是保持不变。但在这个会话之后该 ID 会被回收利用。 token 可选，用于将响应与请求匹配。 token 值为 0 到 8 字节的序列。每个请求都带有一个客户端生成的 token, 服务器在任何结果响应中都必须对其进行回应。token 类似消息 ID，用以标记消息的唯一性。token 还是消息安全性的一个设置，使用全 8 字节的随机数，使伪造的报文无法获得验证通过。标记是 ID 的另一种表现。 option 可选，0 个或者多个。请求消息与回应消息都可以有零到多个 options。 主要用于描述请求或者响应对应的各个属性，类似参数或者特征描述，比如是否用到代理服务器，目的主机的端口等。CoAP 选项类似于 HTTP 请求头，它包括 CoAP 消息本身，例如 CoAP 端口号，CoAP 主机和 CoAP 查询字符串等。 payload 可选。实际携带数据内容， 若有， 前面加 payload 标识符 “0xFF”，如果没有 payload 标识符，那么就代表这是一个 0 长度的 payload。如果存在 payload 标识符但其后跟随的是 0 长度的 payload，那么必须当作消息格式错误处理。 请求方法（requests） 0.01 GET 方法——用于获得某资源 0.02 POST 方法——用于创建某资源 0.03 PUT 方法——用于更新某资源 0.04 DELETE 方法——用于删除某资源 URI 一个 CoAP 资源可以被一个 URI（Uniform Resource Identifier，统一资源标识符）所描述，例如一个设备可以测量温度，那么这个温度传感器的 URI 被描述为：coap://machine.address/sensors/temperature CoAP 的 URL 和 HTTP 的有很相似的地方，开头是 “coap” 对应 “http” 或者 “coaps” 对应 “https”。coap 默认端口 UDP 5683，coaps 默认端口是 UDP 5684。默认端口号可以省略。 规则与 http 的 URL 是一样的，比如不区分大小写等。 注：URL（Uniform Resource Locator，统一资源定位器）是一种特定的 URI，这种 URI 还含有如何获取资源的信息（例如 http、coap 等）。 安全性 CoAP 的安全性是用 DTLS 加密实现的。DTLS 的实现需要的资源和带宽较多，如果是资源非常少的终端和极有限的带宽下可能会跑不起来。DTLS 仅仅在单播情况下适用。 通信过程 上面以 GET 流程为例子，有没有发现，其实跟 HTTP 相类似。 Client 发起请求，类型是 CON，0.01 代表 GET 请求，MID 是请求消息 ID，URI-Path:temperature 代表请求温度。例如： coap://example.com:5683/~sensors/temperature Server 收到请求后，就会返回应答 2.05, MID 保持不变，并且返回具体参数 payload 温度 22.3 C 双向收发 基于消息的双向通信（M2M），CoAP Client 与 CoAP Server 双方都可以独立向对方发送请求。双方可当 client 或者 server 角色。传统的 HTTP 协议是主机与 web 服务器之间是单向通信的（用 websocket 除外）。而 CoAP 系统中 CoAP Client 与CoAP Server 是可以双向通信，双方都可以主动向对方发送请求。这也是 CoAP 协议解决物联网场景问题的关键所在。 订阅与发布 MQTT 协议是基于订阅与发布模型的，CoAP 通过扩展协议方式也简单的实现了订阅与发布模型。 当一个客户端需要定期去查询服务器端某个资源的最新状态时，订阅与发布模型就非常有用，不用这个模型，客户端就要周期的不断发送请求到服务器端。 模型框架： 关键概念： 主题 Subject： 代表 CoAP 的某个资源 观察者 Observer：代表对某个 CoAP 资源感兴趣的客户端 登记 Registration： 观察者需要向服务器登记感兴趣的主题 通知 Notification：当观察者感兴趣的主题发生内容变化时，服务器主动通知到观察者 观察协议在 CoAP 基础协议上增加了 1 个 Observe option， 其值为整数，通过该 options 来实现订阅与发布模型管理 在 GET 请求消息里面： oberser value 为 0： 代表向服务器端订阅一个主题。 oberser value 为 1： 代表向服务器端移除一个已订阅主题。 在 notification 消息里面： oberser value 代表 主题发生变化时，检测到顺序，以便客户端可以知道状态变化的先后。 客户端向服务器端登记感兴趣的主题 /temperature 当 temperature 发生状态改变时，服务器端主动通知到客户端。 客户端根据 token，就可以与之前订阅主题关联起来，以此确定是哪个主题订阅的。 一个 CoAP Client 可以分次向 CoAP Server 订阅多个资源主题。 一个 CoAP Server 上的主题可以被多个观察者（CoAP Client）订阅。 这样就通过了 CoAP Server 实现了 CoAP Client 之间直接数据转发通信。 可以通过灵活设计服务器上的资源链接，来实现对某个主题的条件订阅（类似触发器或者阀值等）。 比如订阅主题是: coap://server/temperature/critical?above=42 当温度超过 42，CoAP Server 需要发送通...
《趣味纸电路》系列制作视频
可在下列视频平台观看： 1、抖音号 50553954982 或者直接复制下列网址在浏览器中观看： 01 交通红绿灯 抖音：https://v.douyin.com/PZHu_R08PdQ/ 02 洗衣机 抖音：https://v.douyin.com/JMdPZedAT7U/ 03 魔法城堡 抖音：https://v.douyin.com/nuf31ZfTZOA/ 04 警车 抖音：https://v.douyin.com/0_ceZVxJBDk/ 05 纸风车 抖音：https://v.douyin.com/Nj_tFuX6rPw/ 06 酷科学 抖音：https://v.douyin.com/2z5n_4rm1ww/ 08 小台灯 抖音：https://v.douyin.com/XEpjgyaSyFU/ 10 神奇灯泡 抖音：https://v.douyin.com/LVyLJvuZ1r...
色环电阻色码对照表
插件电阻（轴向封装电阻）使用色环表达电阻的阻值，常见的有4色环电阻（例如一些常见的碳膜电阻）和5色环电阻（例如相对于碳膜电阻精度更高的金属膜电阻）。 不同颜色的环用于表达有效数字、倍率、误差等信息。 色环方向识别方法 方法1：通过色环间距判断 通常最后一环（误差色环）与前一环的间距应该比其他色环的间距大一些，但一些厂商制造的电阻的这一特征可能不是很明显（尤其是色环多封装小的情况下），这时就要使用其他方法来分辨哪个环是第一环。 方法2：找误差环法，快速找出误差环 误差环是末尾环（最右边的色环）。常用的误差环色：棕色、金色、银色。特别是金色、银色、底色，不会用于第一环和第二环，所以只要有金色、银色、底色环，就基本认定末尾环的位置。 方法3：读标称值法，读值是否为标称阻值 仅靠色环间距无法判定方向，可尝试读值，与标称阻值进行对比，与标称值不相符的为错误方向。例如：色序：棕、黑、黑、黄、棕，其值为：100 × 10000 Ω = 1 MΩ 误差为 1％，属于正常标称值，若反色序：棕、黄、黑、黑、棕，其值为 140 × 1 Ω = 140 Ω，误差为 1％，属于非正常标称值。 常用电阻阻值表 电阻标准由 IEC（国际电工委员会）制定，标准文件为 IEC60063 和 EN60115-2。电子元器件厂商为了便于元件规格的管理和选用，同时也为了使电阻的规格不至太多，采用了统一的标准组成的元件的数值。电阻的标称阻值分为 E6、E12、E24、E48、E96、E192 六大系列，分别使用于允许偏差为 ±20、± 10%、±5%、±2%、±1%、±0.5% 的电阻器。其中以 E24 和 E96 两个系列为最常用。这里的 “E” 表示“指数间距”（Exponential Spacing），它指明了电阻的基准值（有效数字），计算公式如下： $$ R=\left(\sqrt[n]{10}\right)^m $$ 指数 n 的值是 E24，E96 等标准中的数值 24 和 96，m 的取值范围为 0 ~ (n - 1)。所以，E24 有 24 个基准值，E96 有 96 个基准值。有了这些基准值，再乘以 10 的 x 次方，就可以得到各种各样的电阻值了。 这里列出 E24 系列标称阻值...
让耳机线“打两份工”
我们可以将天线想象成麦克斯韦方程所定义的自由空间中的电磁能与限制在导体或波导中的射频电压和电流之间的双向换能器。但工程师们总是在尝试获得某个单一路径或互联方式，以服务于另一种不相干的功能。典型例子如，将非屏蔽耳机导线重复用作 FM 天线。 最早的便携式 AM/FM 收音机使用两根天线：一根是缠绕在铁氧体磁芯上的内置长导线，用于较低频率的 AM 波段（550-1600 千赫 (kHz)）；一根是长约一到两米的“鞭状”天线，用于 FM 波段（88 至 108 MHz）。随着无线电变得越来越小、越便携，有些厂家假定用户使用耳机或有线耳塞，则完全取消了内置扬声器。 这样做也实现了一个简单取消 FM 鞭状天线的技术，即简单地重复利用无线电上的耳机插孔来实现天线功能。当时这种方法也扩展到了 MP3 播放器上，因为 MP3 也带 FM 无线电功能（图 1）。这项技术目前仍为许多带 FM 无线电功能的电子设备的设计师所采用。 图 1：SanDisk Clip Jam MP3 播放器的尺寸仅为 55 mm × 35 mm × 10 mm，一次充电可工作 20 小时；其内置的 FM 无线电使用必备的耳机线作为天线。 基本非屏蔽耳机电缆包含三根导线。左右声道由耳机放大器驱动，将信号传递到左右音频线上，而公用音频线则用作音频的返回路径。同样的导线也可以起到 FM 天线的作用，使用一根导线阻止射频信号接地，同时仍让音频信号有一个接地回路。图 2 中所示的电路是围绕 Skyworks Solutions Si47xx AM/FM 接收器而构建的。 图 2：这一基本布置能够让耳机电线起到 FM 天线作用，只需少数几个附加无源元件即可实现。 用一个小电容器就可以让天线射频传递到接收器前端，同时阻断天线输入的音频信号。铁氧体磁珠在耳机放大器和耳机之间提供一个低阻抗的音频路径和一个高阻抗的射频路径。 实际电路要复杂一些，需要一些额外的元件来进行保护和放电，并确保信号只传到其应该去的地方。图 3 中的设计使用了专门为这个功能配置的 Texas Instruments LM4910 耳机功率放大器，同时附带任何需要的天线信号连接/隔离电路。 图 3：这个 LM4910 耳机放大器通过配备一些外加无源元件，可将耳机引线用作 FM 天线。 三线、左/右音频耳机插孔接收来自 LM4910 的放大音频信号，而由耳机屏蔽层/地线拾取的分离 FM 信号则通过一个 100 皮法拉 (pF) 电容器输送到接收器前端。只要任何静电放电 (ESD) 超出耳机放大器和接收器的额定值，二极管 D1、D2 和 D3 就会提供保护。 这项技术看起来不应该只限于 FM 波段的广播信号（88 至 108 MHz），应该对 AM 无线电（550 于 1550 kHz）也有效。理论上，只要耳机线长度合适，对 AM 波段也有用。它之所以适用于 FM 频段，是因为长度在一米到一点五米之间的耳机线大约是广播频段 FM 信号波长的一半，因此可以在该频段产生效果和作用。对于 AM 波段，耳机线需要长到 100 米才有用，显然这是不切实际的。 结语 工程师们一直在寻求利用像电线这样可作多用途使用的资源。将耳机线用作 FM 天线就是一个绝佳实例。综上所述，只要配置一个合适的功率放大器、少数几个控制信号路径的无源元件和以及用于保护的二极管即可实现这种功能。 参考文献 Skyworks Solutions，AN383，“Si47XX 天线、原理图、布局和设计指...
晶体三极管的三种工作状态
晶体三极管的工作状态主要有三种：截止状态、放大状态和饱和状态。我们通常用截止和饱和状态实现开关控制，用放大状态来放大微弱信号（如音频信号）。 1、截止状态 三极管发射结（基极与发射极间的 PN 结）所加正向偏置电压小于导通电压 $U_{on}$（硅管0.7V，锗管0.3V）或是加反向偏置电压： NPN：$U_{be} < U_{on}$ PNP：$U_{be} > -U_{on}$ 此时，$I_b = 0$，$I_c = 0$，CE 间的阻值无穷大，相当于开关断路。 2、放大状态 三极管发射结正向偏置电压大于或等于导通电压 $U_{on}$（硅管 0.7V，锗管 0.3V），并且集电结（基极与集电极间的 PN 结）反偏。 NPN：$U_{be} ≥ U_{on}$，$U_{cb} > 0$ PNP：$U_{be} ≤ -U_{on}$，$U_{cb} < 0$ $I_c$ 不随 $U_{ce}$ 的变化而改变，在 $I_b$ 一定时，$I_c$ 保持恒定，此时可等效为恒流源。 3、饱和状态 三极管发射结正向偏置电压大于或等于导通电压 $U_{on}$（硅管 0.7V，锗管 0.3V），并且集电结正偏。 NPN：$U_{be} ≥ U_{on}$，$U_{cb} ≤ 0$ PNP：$U_{be} ≤ -U_{on}$，$U_{cb} ≥ 0$ $I_c$ 随 $U_{ce}$ 的增大而增大，不受 $I_b$ 的控制。在饱和状态有一个明显的特征：$I_c < β * I_b$。 饱和状态时的 $U_{ce}$ 叫饱和压降 $U_{ces}$，晶体管手册上一般列出在某个条件下的饱和压降 $U_{ces}$，如 3DG130C 在 $I_c$ ＝ 300mA 时， $U_{ces}$ ≤ 0.8V。一般 NPN 型小功率硅管的 $U_{ces}$ 取 0.3V，PNP 锗管取 -0.1V，大功率硅管在大电流工作时， $U_{ces}$ 将大于 1V。 此时 CE 间的压降较小，相当于开关闭合。 值得注意的是，NPN 三极管 与 PNP 三极管的输入输出特性曲线分别在第一和第三象限，也就是说 PNP 三极管的电压条件反向后与 NPN 三极管是一致...
PN 结正向偏置和反向偏置的原理
正向偏置： 当外加直流电压使 PN 结 P 型半导体的一端电位高于 N 型半导体一端的电位时，称为正偏。此时，外加电场的方向与 PN 结产生的内电场方向相反，削弱了内电场，使 PN 结变薄，有利于两区多数载流子向对方扩散，形成正向电流。 正向偏置使 PN 结的电阻降低，呈现出低阻、导通状态。 反向偏置： 当外加直流电压使 PN 结 N 型半导体的一端电位高于 P 型半导体一端的电位时，称为反偏。此时，外加电场的方向与 PN 结产生的内电场方向一致，因而加强了内电场，使 PN 结加宽，阻碍了多子的扩散运动。 反向偏置使 PN 结的电阻增加，呈现出高阻、截止状态。由于少子浓度主要与温度相关，因此反向电流与反向电压几乎无关。...
LwIP 处理链路状态改变
文/告别年代 Email：byeyear@hotmail.com 基本流程 A. link up -> link down: 关闭 MAC 和 DMA； 调用 netif_set_link_down B. link down -> link up: 打开 MAC 和 DMA； 调用 netif_set_link_up C. 注意：当使用 RAW API 时，所有使用 RAW API 的代码（包括处理链路状态的代码）必须运行于同一线程环境。 代码分析 有四个函数和两个标志位和链路状态改变有关： A. netif_set_up 该函数设置 NETIF_FLAG_UP 标记，并在链路已 up 的情况下发送 arp 探测。 如果你的网络使用静态 IP，那么在 lwip 初始化时调用该函数； 如果你的网络使用 DHCP，那么 DHCP 成功后会帮你调用 netif_set_up。 B. netif_set_down 除非你需要关闭网络，否则一般不需要主动调用该函数。 C. netif_set_link_up 该函数设置 NETIF_FLAG_LINK_UP 标记，启动 DHCP 和 AutoIP，并在 NETIF_FLAG_UP 标记有效的情况下发送 arp 探测。 当链路从 down 变化为 up 时调用该函数。 注意：初始化时如果链路有效，low_level_init 将直接设置 NETIF_FLAG_LINK_UP，而不调用 netif_set_link_up 函数，避免在 lwip 没有完全初始化好时启动 DHCP。 D. netif_set_link_down 在链路从 up 变为 down 时调用该函数。 E. NETIF_FLAG_UP和NETIF_FLAG_LINK_UP 前者表示 lwip 协议栈已经就绪（已得到合法 IP 地址，且协议栈已准备好收发数据包）；后者表示链路层有效。 或者说，一个是软件（协议栈）就绪标志，一个是硬件（链路层）就绪标志。 F. 参考 lwip 代码中的 netif.h 文件对这两个标记的详细说明。 网上很多 port 代码不管是否使用 DHCP 都在 lwip 初始化时设置 NETIF_FLAG_UP，这是不正确的。 NETIF_FLAG_UP 必须在获得有效 IP 地址后才能置位，以保证顺利发送 ARP 探测。 情景分析 A. 静态 IP，初始化时链路有效 这是最简情况。驱动层会看到 Link 有效，并直接设置 NETIF_FLAG_LINK_UP。 随后 lwip 初始化过程中调用 netif_set_up，该函数设置 NETIF_FLAG_UP，并发送 arp 探测。 B. 静态 IP，初始化时链路无效 驱动层不会设置 NETIF_FLAG_LINK_UP。 lwip 初始化过程会调用 netif_set_up，该函数看到没有 link，除了设置标记外不会做任何事。 当链路变为有效后，驱动层调用 netif_set_link_up，发送 arp 探测。 C. 动态 IP，初始化时链路有效 驱动层直接设置 NETIF_FLAG_LINK_UP。 lwip 初始化过程中调用 dhcp_start，启动 DHCP 过程。 但 lwip 初始化过程不会调用 netif_set_up，因为还没有获得有效IP地址。 获得有效 IP 后，lwip 会帮我们调用 netif_set_up，发送 arp 探测。 D. 动态 IP，初始化时链路无效 驱动层不会设置 NETIF_FLAG_LINK_UP。 lwip 初始化过程中仍然会调用 dhcp_start。对 dhcp_start 的调用是必须的，因为 dhcp 过程需要的资源将在该函数中分配。 等到链路有效后驱动层调用 netif_set_link_up，该函数会启动 DHCP 过程。 获得有效 IP 后，lwip 会帮我们调用 netif_set_up，发送 arp 探测。 E. 静态 IP，链路断开后重建 链路断开时 netif_set_link_down，重建后 netif_set_link_up 发送 arp 探测。 NETIF_FLAG_UP 在设置后就一直有效。 F. 动态 IP，链路断开后重建 链路重建后 netif_set_link_up 重新启动 DHCP 过程，该过程会清除 NETIF_FLAG_UP 标记。 DHCP 完成后 lwip 自动调用 netif_set_up 重新置位该标记并发起 arp 探测。 总结 使用静态 IP low_level_init 根据当前链路状态设置或不设置 NETIF_FLAG_LINK_UP； lwip 初始化时调用 netif_set_up； 链路状态改变时调用 netif_set_link_up/netif_set_link_down。 使用动态 IP low_level_init 根据当前链路状态设置或不设置 NETIF_FLAG_LINK_UP； lwip 初始化时调用 dhcp_start； 链路状态改变时调用 netif_set_link_up/netif_set_link_down； 不要在使用动态IP时直接调用 netif_set_up，而是由lwip协议栈代码在成功获得 IP 后为你调用这个函...
MAC 与 PHY 组成原理的简单分析
1. general 下图是网口结构简图。网口由 CPU、MAC 和 PHY 三部分组成。DMA 控制器通常属于 CPU 的一部分，用虚线放在这里是为了表示 DMA 控制器可能会参与到网口数据传输中。 对于上述的三部分，并不一定都是独立的芯片，根据组合形式，可分为下列几种类型： 方案一：CPU 集成 MAC 与 PHY； 方案二：CPU 集成 MAC，PHY 采用独立芯片； 方案三：CPU 不集成 MAC 与 PHY，MAC 与 PHY 采用集成芯片； 本例中选用方案二做进一步说明，因为 CPU 总线接口很常见，通常都会做成可以像访问内存一样去访问，没必要拿出来说，而 MAC 与 PHY 之间的 MII 接口则需要多做些说明。 下图是采用方案二的网口结构图。虚框表示 CPU，MAC 集成在 CPU 中。PHY 芯片通过 MII 接口与 CPU 上的 MAC 连接。 在软件上对网口的操作通常分为下面几步： 1）为数据收发分配内存； 2）初始化 MAC 寄存器； 3）初始化 PHY 寄存器（通过 MIIM）； 4）启动收发； 2. MII MII 接口是 MAC 与 PHY 连接的标准接口。因为各厂家采用了同样的接口，用户可以根据所需的性能、价格，采用不同型号，甚至不同公司的 PHY 芯片。 需要发送的数据通过 MII 接口中的收发两组总线实现。而对 PHY 芯片寄存器的配置信息，则通过 MII 总的一组串口总线实现，即 MIIM（MII Management）。 下表列出了 MII 总线中主要的一些引脚 PIN Name Direction Description TXD[0:3] MAC to PHY Transmit Data TXEN MAC to PHY Transmit Enable TXCLK MAC to PHY Transmit Clock RXD[0:3] PHY to MAC Receive Data RXEN PHY to MAC Receive Enable RXCLK PHY to MAC Receive Clock MDC MAC to PHY Management Data Clock MDIO Bidirection Management Data I/O MIIM 只有两个线，时钟信号 MDC 与数据线 MDIO。读写命令均由 MAC 发起，PHY 不能通过 MIIM 主动向 MAC 发送信息。由于 MIIM 只能有 MAC 发起，我们可以操作的也就只有 MAC 上的寄存器。 3. DMA 收发数据总是间费时费力的事，尤其对于网络设备来说更是如此。CPU 做这些事情显然不合适。既然是数据搬移，最简单的办法当然是让 DMA 来做。毕竟专业的才是最好的。 这样 CPU 要做的事情就简单了。只需要告诉 DMA 起始地址与长度，剩下的事情就会自动完成。 通常在 MAC 中会有一组寄存器专门用户记录数据地址，tbase 与 rbase，CPU 按 MAC 要的格式把数据放好后，启动 MAC 的数据发送就可以了。启动过程常会用到寄存器 tstate。 4. MAC CPU 上有两组寄存器用与 MAC。一组用户数据的收发，对应上面的 DMA；一组用户 MIIM，用户对 PHY 进行配置。 两组寄存器由于都在 CPU 上，配置方式与其他 CPU 上寄存器一样，直接读写即可。 数据的转发通过 DMA 完成。 5. PHY 该芯片是一个 10M/100M Ethernet 网口芯片 PHY 芯片有一组寄存器用户保存配置，并更新状态。CPU 不能直接访问这组寄存器，只能通过 MAC 上的 MIIM 寄存器组实现间接访问。 同时 PHY 芯片负责完成 MII 总线的数据与 Media Interface 上数据的转发。该转发根据寄存器配置自动完成，不需要外接干预。 作者：fireaxe_hq@hotmail.c...
RFC 1662: PPP in HDLC-like Framing
点对点协议（PPP）提供了一种标准方法，用于在点对点链路上传输多协议数据报。 本文档描述了使用类似 HDLC 的帧结构对 PPP 封装的数据包进行封装。 帧格式： +----------+----------+----------+ | Flag | Address | Control | | 01111110 | 11111111 | 00000011 | +----------+----------+----------+ +----------+-------------+---------+ | Protocol | Information | Padding | | 8/16 bits| * | * | +----------+-------------+---------+ +----------+----------+----------------- | FCS | Flag | Inter-frame Fill |16/32 bits| 01111110 | or next Address +----------+----------+----------------- 传输前需要转义，转义符为 7d（计算完 CRC 后再转义） 头尾的 7e 不需要转义，其他的 7e、7d、小于 0x20（空格）的字节都需要转义。 字节 c 转义后为：0x7d (c xor 0x20)，例如： 0x7e is encoded as 0x7d, 0x5e. (Flag Sequence) 0x7d is encoded as 0x7d, 0x5d. (Control Escape) 0x03 is encoded as 0x7d, 0x23. (ETX) 协议文本： RFC 1662_ PPP in HDLC-like Framing.p...