在aarch64嵌入式应用开发中，经常会遇到段错误(segmentation fault)，但是通常情况下系统报错后直接退出，没有异常调用打印信息，定位出错原因十分困难。经确认，该问题是由于没有设置捕获段错误，并调用backtrace打印异常调用栈，笔者实现该异常捕获处理方案后，发现仍然没有异常调用栈输出。经进一步定位发现，该嵌入式设备上使用的glibc库版本过低，并不支持aarch64的back

AR属于计算密集型技术，其实现需要高带宽、低时延和比较强的计算能力支撑，为此之前的解决方案大多采用有线的方式将AR眼镜连接到本地计算机上，这限制了用户的使用场景。随着5G和边缘计算技术的兴起，AR的移动性大大提升，AR眼镜可以通过高带宽的无线方式接入到网络中，在就近的边缘计算设备上进行计算，这为移动AR的实现提供了新的方向。本文总结了基于边缘计算的移动AR解决方案，首先对AR的概念和业务进行了分析

tcl脚本语言在嵌入式开发，通信设备开发调试中经常被用到。它是一种跟shell语言类似的解释型语言，不需要编译就可以运行，语法简单，作为程序员可以在几小时或者几天内就可以熟练掌握，但是它网络功能强大，又是开源免费的，因此在日常的网络设备调试，自动化测试，复现定位概率性问题中被广泛使用。参考文献【1】【2】的两个链接是tcl脚本的基本语法学习路径，笔者将其中重要的语法点总结如下图所示。图中上半部分是

笔者从毕业至今已经8年有余，所以想将先前的工作和实践经验总结一下，帮助自己系统化地梳理知识结构，找出知识的盲点。为何选择《嵌入式系统那些事》这个主题，首先笔者8年多一直在嵌入式领域耕耘，从mcu到arm芯片开发，从裸机开发到操作系统上的开发，从底层的驱动开发到应用层的开发，从toc的消费类产品到tob的通信产品，笔者都有所涉猎，但是发现这些知识都是零散地存在，没有形成一张网，于是笔者想通过这种形式

订阅管理是客户端从服务端根据主题获取需要的信息，包含正常的订阅流程，控制报文、有效载荷和异常的处理流程。两者交互的依据是主题。

前面笔者从arm的指令集开始，依次解读了文件视角下的arm汇编文件、arm elf文件，其目的是帮助读者系统地了解arm体系结构下指令转换和执行过程。本文是文件视角主题下的最后一篇文章，将对arm运行时的文件进行解读，即被加载后的代码如何被一步一步执行的。这个部分的核心是函数调用栈，尽管系统已经帮我们做了这件事，但是了解其内部的机制和原理，对我们来说仍然是很有裨益的，特别是解决一些踩内存的问题，可

移动AR的实现上，本文主要立足于业务，根据业务特点设计移动AR的实现架构。移动AR业务属于计算密集型，涉及大量的数据处理，加之AR终端设备通常是便携可穿戴的产品形态，在设备实现上小巧轻量，因此需要将业务部分卸载到边缘侧或者云端进行处理。基于以上原则，我们将实现框架划分为三层，分别是AR终端，移动边缘端和云端。每一层根据计算能力，能量消耗，分别处理不同的业务，各层之间相互配合完成整个功能。各层详细的

边缘计算可以支持就近的计算卸载，让数据在靠近数据源的设备上处理。对于边缘计算低时延的应用场景来说，网络性能的好坏，直接影响着卸载算法的整体耗时，决定着整个算法模型的可行性。因此如果想实现低时延卸载算法，除了获得合适的计算资源以外，还需要更加精细的网络资源的管理。对于需要进行低时延处理的数据，在网络上提供单独的通道和资源，报文在调度和转发时具备更高的优先级，保证报文可以第一时间被响应。要实现上述功能

网络切片作为一种比较前沿的技术，当前并没有太多系统的资料可以学习，很多的技术资料都是比较分散地分布在论文和一些技术博客中，笔者当前是通过论文的解读获取相关的技术信息，在过程中笔者总结了相关的技术栈，本文就是针对该技术栈的一次探讨，抛砖引玉，为读者入门网络切片提供一些帮助。

当然在传统的CDN视频领域，除了网宿科技这样的老牌企业外，新兴的PPIO，字节跳动的火山引擎，UCloud等企业，也依赖布局的视频节点，利用边缘计算技术，提供更低时延，更佳用户体验的业务。参与角逐的公司，包括传统的通信设备企业，如华为、中兴、新华三，也有传统的服务器公司，如浪潮、联想，还包括三大电信运营商，电信、移动、联通，互联网BAT也不甘示弱，从阿里云到腾讯云、百度云，都在往边缘计算方向延伸，