1.at��� Դ��
2.OpenHarmony 3GPP协议开发深度剖析——一文读懂RIL
3.BSD协议是框架l框如何处理AT&T源代码版权问题的？
4.阿里开源分布式事务框架seata落地实践
at��� Դ��
互联网上关于 AT 指令的教程多集中在如何使用 AT 固件开发产品，而对 AT 解析器设计的源码研究却相对较少。这是框架l框因为大多数开发者使用现成的 AT 固件，而开发 AT 固件的源码人员较少，设计解析器的框架l框人更是凤毛麟角。芯片原厂通常不公开 SDK 源码，源码源码出党导致了这类内容在网络上的框架l框稀缺。因此，源码关于 AT 解析器的框架l框文章较少，主要关注点在如何使用模块和 MCU 控制 AT 指令。源码
为了编写出好的框架l框 AT 解析器，首先需要理解 AT 指令的源码规则，明确不同指令之间的框架l框共性和差异。AT 指令的源码语法格式可以参考相关文章，而具体实现则需要基于这些规则。框架l框解析器需具备识别指令规则、处理特殊字符和指令数据混合传输的能力。
以乐鑫的 AT 解析器 esp-at 为例，它遵循 3GPP TS . 语法规范。解析器需实现处理 AT 指令的共性和差异性内容，比如启动 AP 热点指令（AT+CWSAP=,,,）的解析，其中涉及中文和非 ASCII 字符的处理。中文等非 ASCII 字符的兼容性通常依赖于兼容 ASCII 的编码格式，如 GBK、GB、UTF-8 等。解析器理论上能支持这些编码，但实际使用时，通达信手机版源码怎么编用户输入的 ssid 和 pwd 可能会被路由器误解，原因在于 Wi-Fi 模块和路由器间编码格式的匹配问题，需要通过 Wi-Fi 扫描来获取编码信息并进行转换。此外，处理指令与数据混合传输也是一个挑战，尤其是在多路数据传输场景中，需要合理管理串口通信，确保数据的独立完整。
乐鑫提供的解析器支持两种数传模式：normal 模式和 passthrough 透传模式，适用于单个或多个连接场景。在有多路 socket 连接时，解析器需管理数据缓存，确保每一路连接的数据独立完整地通过 AT 串口传递。解析器的实现需要进行大量测试，以确保逻辑正确性和特殊字符支持的准确性。
AT 解析器的开发过程复杂，需要细致的逻辑处理和全面的测试。有兴趣的朋友可以尝试实现一个 AT 解析器，体验其中的挑战与乐趣。如有错误，欢迎指出。
OpenHarmony 3GPP协议开发深度剖析——一文读懂RIL
市场上针对终端操作系统3GPP协议开发的相关资料较为稀缺，即便在Android领域，相关学习文档也较为有限，更不用说专门的协议开发书籍了。这可能与市场需求有关，目前市场上从事前后端软件开发的集福卡活动程序源码在哪里人员最多，包括我自己。
鉴于我在某手机协议开发团队工作过一段时间，对协议的AP侧和CP侧开发都有所涉猎，因此我尝试基于OpenAtom OpenHarmony（以下简称“OpenHarmony”）源码编写一些内容，旨在帮助大家了解协议开发领域，尽可能将3gpp协议内容与OpenHarmony电话子系统模块相结合进行讲解。据我所知，目前终端协议开发人才非常紧缺。首先声明，我不是协议专家，且已离开该领域五六年，如有错误，欢迎指正。
谈到终端协议开发，我首先想到的就是RIL。
CP：Communication Processor（通信处理器），通常理解为modem侧，也可以理解为底层协议，这部分由各个modem芯片厂商完成（如海思、高通）。
AP：Application Processor（应用处理器），通常指手机终端，通常理解为上层协议，主要由操作系统Telephony服务进行处理。
RIL：Radio Interface Layer（无线电接口层），通常理解为硬件抽象层，即AP侧将通信请求传给CP侧的抖音摩天轮直播源码下载中间层。
AT指令：AT指令是应用于终端设备与PC应用之间连接与通信的指令。
常规的Modem开发与调试可以使用AT指令进行操作，而各家的Modem芯片的AT指令都会有各自的差异。因此，手机终端厂商为了能在各种不同型号的产品中集成不同modem芯片，需要进行解耦设计来屏蔽各家AT指令的差异。
于是，OpenHarmony采用RIL对Modem进行HAL（硬件抽象），作为系统与Modem之间的通信桥梁，为AP侧提供控制Modem的接口，各Modem厂商则负责提供对应于AT命令的Vender RIL（这些一般为封装好的so库），从而实现操作系统与Modem间的解耦。
框架层：Telephony Service，电话子系统核心服务模块，主要功能是初始化RIL管理、SIM卡和搜网模块。对应OpenHarmony的源码仓库OpenHarmony/telephony_core_service。这个模块也是非常重要的一个模块，后期单独再做详细解读。
硬件抽象层：即我们要讲的RIL，对应OpenHarmony的源码仓库OpenHarmony/telephony_ril_adapter。RIL Adapter模块主要包括厂商库加载，业务接口实现以及事件调度管理。主要用于屏蔽不同modem厂商硬件差异，为上层提供统一的接口，通过注册HDF服务与上层接口通讯。
芯片层：Modem芯片相关代码，申购股票软件源码哪里找即CP侧，这些代码各个Modem厂商是不开放的，不出现在OpenHarmony中。
硬件抽象层又被划分为hril_hdf层、hril层和venderlib层。
hril_hdf层：HDF服务，基于OpenHarmony HDF框架，提供hril层与Telephony Service层进行通讯。
hril层：hril层的各个业务模块接口实现，比如通话、短彩信、数据业务等。
vendorlib层：各Modem厂商提供的对应于AT命令库，各个厂商可以出于代码闭源政策，在这里以so库形式提供。目前源码仓中已经提供了一套提供代码的AT命令操作，至于这个是针对哪个型号modem芯片的，我后续了解清楚再补充。
下面是ril_adapter仓的源码结构：
本文解读RIL层很小一部分代码，RIL是如何通过HDF与Telephony连接上的，以后更加完整的逻辑梳理会配上时序图讲解，会更加清晰。首先，我们要对OpenHarmony的HDF（Hardware Driver Foundation）驱动框架做一定了解，最好是动手写一个Demo案例，具体的可以单独去官网查阅HDF资料。
首先，找到hril_hdf.c文件的代码，它承担的是驱动业务部分，源码中是不带中文注释的，为了梳理清楚流程，我给源码关键部分加上了中文注释。
上述代码中配置了对应该驱动的moduleName为"hril_hdf"，因此我们需要去找到对应驱动的配置文件，以HiDV开发板为例，它的驱动配置在vendor_hisilicon/HiDV/hdf_config/uhdf/device_info.hcs代码中可以找到，如下：
这里可以发现该驱动对应的服务名称为cellular_radio1，那么telephony_core_service通过HDF与RIL进行通信肯定会调用到该服务名称，因此无查找telephony_core_service的相关代码，可以很快定位到telephony_core_service/services/tel_ril/src/tel_ril_manager.cpp该代码，该代码中有一个关键类TelRilManager，它用来负责管理tel_ril。
看tel_ril_manager.cpp中的一个关键函数ConnectRilAdapterService，它就是用来通过HDF框架获取RIL_ADAPTER的服务，之前定义过RIL_ADAPTER_SERVICE_NAME常量为"cellular_radio1"，它就是在vendor_hisilicon/XXXX/hdf_config/uhdf/device_info.hcs中配置的hril_hdf驱动对应的服务名称。
BSD协议是如何处理AT&T源代码版权问题的？
年，加州大学伯克利分校的学生Bill Joy完成了Berkeley Software Distribution（BSD）的首个合并，包含了Pascal系统和ex编辑器，标志着BSD的诞生。最初发行的大约三十份免费拷贝迅速传播。在年，随着用户群体的壮大，2BSD版本发布，升级了Pascal系统、vi和termcap，这些Unix用户熟知的工具，再次免费提供。直到2.BSD，这个版本至今仍在全球范围内活跃运行。
随着VAX计算机的普及，年末3BSD应运而生，这是Berkely的第一个VAX版本，包含了C Shell、大量附加程序和VAX版的Unix标准工具。年，Bill Joy推出了4BSD，集成了Pascal编译器、Franz Lisp系统和邮件处理系统，支持DARPA网络，并采取了以大学为单位的版权控制模式。
同年，成立了专门的CSRG小组，负责BSD的后续发行。年6月，4.1BSD发布，正式开启BSD版本命名的新规则，以4.1开始，后续仅在小版本号上升级。4.2BSD在年8月发布了，短短个月内就分发了多份许可证，声誉大增。年和年，4.3BSD和4.3BSD-Tahoe相继发布，其中4.3BSD-Tahoe首次实现了内核的机器独立性，极大地推动了BSD的移植适应性。
由于BSD使用了部分AT&T Unix代码，随着AT&T源代码费用的增长，一些厂商希望获得BSD的无版权限制版本。年6月，Berkely发布了"Networking Release 1"，这是第一份完全无AT&T Unix源代码的自由再发行版本，允许用户修改和分发代码，无需AT&T许可，这是BSD历史上的重要里程碑，标志着自由软件理念的进一步发展。
阿里开源分布式事务框架seata落地实践
seata是阿里巴巴研发的分布式事务框架，提供AT、TCC、SAGA和XA事务模式。本文以物流后台服务为例，介绍了seata框架的落地实践，包括遇到的问题与解决方案。有道精品课教务系统采用springcloud构建分布式集群服务，存在分布式事务需求。seata框架能实现全局事务，并满足业务需求，灵活兼容多种事务模式，确保数据强一致性。物流业务案例展示了seata框架落地过程及问题解决办法，供读者学习讨论。
物流业务案例中，seata框架由三个组件构成：全局事务状态维护、全局事务范围定义及分支事务管理。seata服务端部署采用解压并执行bin/seata-server.sh启动，配置文件registry.conf与file.conf决定注册中心和配置信息获取方式。使用consul做注册中心，需在registry.conf中修改配置。需确保global_table、branch_table和lock_table在数据库中预建。
客户端配置包括引入seata组件、配置file.conf和registry.conf文件，并在application.yml添加seata配置。此外，替换项目数据源以完成客户端配置。分布式事务分为AT和TCC模式，分别基于本地ACID事务和自定义分支事务管理。TCC模式需定义服务接口和上下文，实现分支事务逻辑。
在实际部署中，常遇到client TM/RM注册TC失败问题，需确保seata项目正确部署到线上环境。高可用部署依赖注册中心模式，需将file.conf信息存至consul。解决namespace支持问题，需修改源码中的Configuration和RegistryProvider接口实现类。全局日志插入问题需调整seata数据源连接部分代码。
利用SPI机制实现自定义组件，seata提供SPI服务发现机制，允许在服务间通过接口调用服务，避免耦合。通过修改ConsulRegistryProvider类并更新META-INF/services目录，可替换seata实现类。为简化配置，可将自定义实现类和公共client配置封装到common-seata工具包中。
物流场景中，通过引入common-seata工具包，实现基于TCC的全局事务链路。当执行成功，可在server端查看日志；若执行失败，进行回滚以删除生成的单据。
本文总结了seata框架部署与使用的关键步骤和技术细节，针对项目落地遇到的技术问题提供了解决方案。后续文章将继续深入seata实现分布式事务的核心原理和技术细节。文章由有道技术团队邓新伟撰写，已获作者授权。