感谢Artery公司提供开发板，以及Artery各位工程师的技术支持。

背景

今年上半年收到了Artery公司 木一川 先生的邀请，有幸白嫖到了AT32的开发板。开发板搭载的AT32F437ZMT7芯片和其他国内芯片公司的xx32产品类似，芯片内核采用ARM Cortex-M4，外设和STM32F1相似。

题外话： 在写这篇文章的时候，翻阅了以前写的GD32移植时候看到当时刚刚考完日语N2，一年半时间飞逝，N1考试因为疫情连续取消了三回。

zephyr移植

基础知识：

请参考gd32移植

对于传统的嵌入式软件开发，可能会使用IAR、KEIL等IDE，而绝大多数的芯片厂家默认提供的BSP也往往基于这些工具进行开发。 然而对于开源项目来说，这些工具费用高昂，并且对工作流的细节控制很难实现。因此，对于第一次接触zephyr项目的朋友优先理解编译器（和目标平台架构相关，对于at32来说是gcc）和构建系统（cmake）的作用。

zephyr系统利用了大量linux的开发工具：

• 为了解决c语言大量宏（marco）的依存关系，zephyr使用linux的kconfig工具来管理宏。
• 为了解决各个平台的硬件区别，zephyr基于使用linux的devicetree框架对硬件设备从Board,SOC,Arch三个层级对硬件平台进行描述。但是zephyr项目的设备树会生成c语言头文件而不是dtb。

为了对开发平台进行调试，一般会使用pyocd或者OpenOCD这两个工具来建立JTAG或者SWD连接，配合gdb对芯片进行调试。 一般gdb不会单独运行，在命令行中调试即使配合tui也是十分痛苦的，但是对于一些高手，利用hook，可以打造出更顺手的调试环境。我个人一般会配合vscode或者gdbgui等工具一同使用，这些GUI界面一般也可以使用hook，并且使用gdb的终端。

以上工具，一般在zephyr项目中也不会直接调用，而是使用west命令进行操作。

AT32移植

zephyr项目支持多种架构和大量厂商的芯片，一般情况下，我们只需要制作最外层的Board级别的移植，即可完成。

但是本次Artery公司尚未被zephyr项目支持，但是arm cortex-m4是被zephyr项目支持的架构arch，所以需要SOC级别的移植。

如果你使用的是Renesas的RH850或者infineon的TriCore系列芯片，那么你将会面对一个arch级别的移植，这会面对很大的工作量，目前我也没有经历过这个级别的适配。

• 供应商支持
  • zephyr会对供应商进行管理，只有记录在vendor-prefix.txt内的供应商名称，才可以作为vendor出现在设备树中。
• 板极支持(board – at_surf_F437)
  • 板级设备树
    • 这里一般会描述LED、按键、串口等板级外设的配置。
  • 板级kconfig配置
    • 对一些设定进行配置，例如LOG等级，IP地址等。
  • 调试工具配置
    • 对openocd、pyocd以及各个厂家特有的下载工具等进行配置，以便对目标设备进行调试和烧写。
  • 文档
    • 一般会描述开发板的功能和简单的编译烧写方法。
• 芯片级支持(SOC – AT32F437ZMT7)
  • soc启动代码(soc.c)
    • 对系统启动进行一些初期设定，arm架构一般会调用cmsis接口SystemInit。
  • 芯片级dts
    • 对芯片级设备进行描述，例如定时器，flash等。
  • 芯片级KCONFIG
    • 对芯片系列进行定义。
  • 芯片片内外设驱动
    • 串口、定时器等外设驱动。
    • 这部分代码会大量利用c语言宏的一些特性，熟练掌握可以很大程度的提升c语言宏的使用技巧。
• 供应商硬件抽象层(对于本次移植来说是hal_artery)
  • 在适配驱动的过程中，如果完全重新写一遍外设驱动的话会产生很大的工作量；同时一般芯片厂商会提供一定的代码以便加速开发。但是，这些代码的维护和zephyr之间关系不大，因此作为module存在。
  • 在使用这些代码的时候，我们需要十分小心。因为c语言没有package或者namespace这些方法对符号的作用域进行限缩，所以在引入供应商HAL代码的时候，符号会重名，这种时候需要对HAL名称进行修正。万幸是这些修正项目往往比较规则，即使在版本更新后，一般也只需要再做一遍即可。如果希望更加一劳永逸的办法，建议了解coccinelle。
  • HAL库的另外一大工作量是芯片的引脚复用的管理(pinctrl)。一般情况下，我们对引脚的处理仅仅局限在某一个系列的兼容，然而在zephyr项目中，我们需要对整个供应商的引脚IP进行描述。并且，zephyr项目一般不允许手动修改这些描述，因此制作一个脚本程序是必要的，例如：hal_gigadevice: gd32pinctrl.py。
  • 作为zephyr模块，根目录应当包含zephyr文件夹和module.yml文件。这些文件的修改可以参考west工具的说明。

应用篇 （zephyr-SUMP）

谈论了很久的移植，最后来聊一下产品的开发。本节将简单的说明下zephyr应用开发的方式，并做一个简单的逻辑分析仪。为了简单起见，本次没有采用out-of-tree的开发方式，而是将代码放在了app文件夹内。

SUMP与SIGROK

• sigrok
  • 这是一个支持大量设备的开源逻辑分析仪程序（也支持示波器、电源等设备）。
• SUMP
  • SUMP是一个基于串口(UART/USBCDC)的逻辑分析仪传输协议。

基于这两个工具，我们实现逻辑分析仪的技术准备就基本完成了。

开发APP

为了获得更高的采样速度，需要在APP层级重新定义端口驱动，以绕开zephyr的IO驱动，较少操作系统抽象造成的性能损失。

• sample文件夹下有大量例子，可以简单的复制出来，作为我们开发的基础。
• APP KCONFIG设置
  • 对于app级别的宏进行描述，这些宏可以根据实际使用的目标平台进行调整。例如：采样频率，采样数据长度等。
• 板级设备树覆写
  • 对于逻辑分析仪来说，为了更快的采样速度，我们需要更快的GPIO驱动，而zephyr提供的接口由于抽象，会损失些许性能。
• app层驱动
  • 这里是对于不同芯片的端口驱动。不同芯片根据资源不同，可能会提供不同数量的端口数和采样方法。例如：
    • Zephyr GPIO方法
    • 汇编方法（目前只实现了ARM）
    • Timer + DMA方法（目前没有做）
• app
  • 启动了一个测试用pwm（绿灯）
  • SUMP协议的处理
• 文档
  • 一些文档更加利于别人理解这个项目的用途
• todos
  • 这个app是我头脑一热做的，还有很多不完善的地方，暂时记录在这里。

图片

开发板照片

PulseView采样