安装开发包和下载源码
编译
对于复杂ui的开发，可以通过GtkBuilder 实现xml来描述ui，同时可以通过 Glade 做图形化配置控件；
https://developer.gnome.org/gtk3/stable/gtk-getting-started.html
对象继承关系；
控件画廊
需要在非root用户 DISPLAY=:0 ./example-0 运行。
同时，x server 限制连接用户。所以如果要通过root调试，会麻烦一些。
基于debian8 的linux设备会低概率的出现的系统完整死机，这里思考给linux添加完整的看门狗策略。
debian8已经采用systemd用以初始化系统和守护、管理系统进程。这里同时存在systemd 的watchdog和keepalive 单元文件，以及sysv init的watchdog keepavlie 初始化脚本，同时systemd也直接看门狗启动，那么该如何选择呢？
systemd直接支持看门狗启动；
debain8同时支持systemd和sysv init的看门狗以及保活机制。
./drivers/watchdog/Kconfig
所以这里只需要使能CONFIG_WATCHDOG=y CONFIG_WATCHDOG_CORE=y
如上使能了过后还是没有出现看门狗设备，参考sunxi 主核发布说明确定4.17之后a64才加入看门狗功能，这里涉及sunxi_wdt和dts和驱动移植。
error
启动日志
/bin/systemd-tty-ask-password-agent --watch
supervisor启动失败，通过/var/log/syslog 直接报错。
该报错通过systemd控制的sysv init启动脚本报出。从直接报错的代码位置来看是start-stop-daemon启动supervisord 失败。
为什么这里会启动进程失败呢？通过man start-stop-daemon 找到了可能的报错原因。
通过如上分析可以知道这里可能存在了--pidfile 指定的进程id，尝试更改/var/log/supervisord.pid 文件进程id为1（systemd进程名）。此时发现supervisd再也启动不了了，同时也直接如上报错。
那么这里为什么会出现相同进程id的进程名呢？
通过分析这里设备可能存在异常断电导致设备未正常销毁pid文件，再次启动的时候又检测到相同pid的进程名，所以直接导致了进程的启动失败。
pidfile单例模式启动进程这么通用的机制为什么会出现该缺陷？其他守护进程也会出现？还是只是概率问题。
其实不然，以下分析。
在systemd#systemd vs sysv init 详细介绍了sysv init 和systemd控制的进程启动。这里的3.0.0 版本supervisor 通过sysv init启动。sysv init通过start-stop-daemon 和--pidfile 单例模式启动supervisor，升级到高版本的由syste...
如下pc0，gpio64 设置中断触发边沿失败。
对比，pb0 gpio32，这里没有edge 属性。
对比3.21.2.1. PB Configure Register 0 (Default Value: 0x77777777) 和3.21.2.10. PC Configure Register 0 (Default Value: 0x77777777) 这里pc0 确实不支持中断。
The BLE protocol stack, the profiles, and all applications are all built around the Operating System Abstraction Layer (OSAL). The OSAL is not an actual operating system (OS) in the traditional sense, but rather a control loop that allows software to setup the execution of events. For each layer of software that requires this type of control, a task identifier (ID) must be created, a task initialization routine must be defined and added to the OSAL initialization, and an event processing routine must be defined.
Optionally, a message processing routine may be defined as well. Several layers of...
详细介绍基于ti-rtos高级调试组件rov用以cc1310/cc2640 等sdk异常主动调试。
正常的，程序会进入IDLE模式，程序会停留在(0x10001486),也就是IDLE模式；通常的，在我们完成我们程序功能时候，不可避免会遇到程序运行至一个死循环。如下图所示：这个时候，我们要考虑程序异常了。
导致异常的原因可以在 View->Registers CFSR寄存器的CPU_SCS 组中确定。最常见的异常有以下几个原因：
对于任务栈溢出，我们可以通过TI-RTOS->Task->Detailed 分析任务栈使用情况。但是IAR这里报错了。
通过TI-RTOS->BIOS->...
在x64（ pc /ubuntu 18.10 ）跨平台编译arm64 的debian rootfs完整镜像，通常地，更新rootfs都是直接放在目标机上面，制作更新好rootfs后再拷贝回编译机。
对于目标机平台，通常拷贝rootfs需要非运行时环境，所以例如在emmc的rootfs需要通过sd卡系统启动去执行拷贝操作。
同时拷贝/压缩还需要关心文件的uid、gid、用户名、组名、执行权限。稍不注意，功亏一篑。
这里通过介绍qemu虚拟跨平台制作、更新rootfs。
如我们知道，debootstrap用以通过源制作debian/ubuntu 的基础rootfs。通常来说其分为下载（--foreign）和安装配置（--second-stage）两个阶段。对于跨平台的第一阶段下载只需要通过--arch置顶平台下载对应deb包，但是对于包安装则需chroot后在编译机上面虚拟目标机的deboosttap 执行安装。
如上讨论，这里我们在x64 平台下载arm64（aarch64）平台rootfs并且尝试通过chroot实现初始用户、包安装重等操作。
安装依赖包；
下载归档keyring
通过源下载rootfs
deiban jessie 如上下载安装可能会因为包缺失提示下载失败，这里搜索寻找替换了老的软件源。
chroot 是linux 用以切换rootfs的一个应用，跨平台操作通过需要切换的rootfs ...
初次安装；
http 代理
详细介绍 images、container、service、stack概念和层次关系，梳理docker基本操作。
dockerfile 语法参考。
Compose file version 3 reference
service 描述文件 compose file语法参考。
docker ps 命令
docker container 操作命令
https://docs.docker.com/engine/reference/commandline/container/
有些疑问，先前错误的理解了image和container的关系，以为container是运行时（running time）的image，其实原文描述的意思是可运行的（runable）。然后可运行的container的再区分正在运行和为未运行的。
那么还有一个问题，docker image和container各自在磁盘的哪里？是否可以备份和删除。
首先， 需要清晰认识zigbee架构的系统框图，zcl 是zigbee 应用框架层上用以约定抽象描述物联网设备的协议，也就是对于不同厂商需要研发的物联网产品，都可以基于zcl 的设备描述，通过这样的标准设备描述语言，那么就可以实现真正意义的万物互联。
在zigbee cluster specification 里，定义如上包含关系，某个设备可以理解为多个cluster的集合（list），而zcl 约定了这里cluster，同时对于每一个固定cluser又是同时包含一个或者多个Attribute、Behavior、Command、Dependency，如下分开解释Cluster下的A、B、C、D。
Attribute
表示某个设备物理特征和状态的数据值，该数据值同其他设备通过如下Command操作关联；
Behavior
行为；
Command
操作或者影响熟悉的动作；
Dependency
依赖；
如上的Command 集合是针对固定Cluster下面的Attribute操作的，同时对于所有的Attribute，zcl还约定一系列的通用操作命令。
接下来需要理解的是z...
zigbee Specification Revision 22 1.0 ->4.2.1.2.1 Security Keys 详细介绍了zigbee 密钥类型，包含用以两个设备应用层(apl)单播的link key和用以所有设备其它层（network、mac）、以及应用层广播的network key。
通常地，network key 通过设备加入网络后密钥传输流程获取，而link key 则通过密钥请求或者出厂预定义安装，类似bdb install code已经实现应用预配置tc link key，oob传输到tc。
link key 区分全局（global）和唯一（unique）的，zigbee 联盟默认约定了一个全局的tc link key 5A 69 67 42 65 65 41 6C 6C 69 61 6E 63 65 30 39 (ZigBeeAlliance09)。
network key
用以网络层和应用层广播的数据帧加密，所有设备之间都共享该唯一密钥。
tc link key
用以两个设备之间应用层单播加密，具有唯一性，不同设备之间不一致，zigbee 联盟预定义了一个全局的link key用以初次获取network key。
通过tc（trust center 信任中心）统一为新加入的设备分发唯一的tc link key，该key作为新加入设备同其他设备应用层单播通信...