移植zephyr到AT32_SURF_F437开发板

感谢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级别的移植。

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

  • 供应商支持
    • zephyr会对供应商进行管理,只有记录在vendor-prefix.txt内的供应商名称,才可以作为vendor出现在设备树中。
  • 板极支持(boardat_surf_F437)
    • 板级设备树
      • 这里一般会描述LED、按键、串口等板级外设的配置。
    • 板级kconfig配置
      • 对一些设定进行配置,例如LOG等级,IP地址等。
    • 调试工具配置
      • openocdpyocd以及各个厂家特有的下载工具等进行配置,以便对目标设备进行调试和烧写。
    • 文档
      • 一般会描述开发板的功能和简单的编译烧写方法。
  • 芯片级支持(SOCAT32F437ZMT7)
    • 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采样

移植zephyr到AT32_SURF_F437开发板”的一个响应

发表评论

Fill in your details below or click an icon to log in:

WordPress.com 徽标

您正在使用您的 WordPress.com 账号评论。 注销 /  更改 )

Twitter picture

您正在使用您的 Twitter 账号评论。 注销 /  更改 )

Facebook photo

您正在使用您的 Facebook 账号评论。 注销 /  更改 )

Connecting to %s