移植zephyr到GD32E103_EVAL板子

未分类 1 Minute

背景

终于考完日语了,虽然够呛能过 o.o 105分飘过了o.o

不过也算是有点空闲时间能随便玩玩了.迫于近年来半导体价格飞涨, 国产MCU的应用也越来越广(大部分是替代STM32的样子)

整个移植过程可以看出GD32和STM32高度相似.

具体代码参考: https://github.com/zephyrproject-rtos/zephyr/pull/36833 PR的使用方法请参考后面

本次移植大概花费三四天,本文不会记录详细的移植过程(因为代码在上一行)只会记载几个移植中的小问题.

主要参考资料:https://docs.zephyrproject.org/latest/guides/porting/index.html

基础知识

为了能够移植zephyr系统,下面知识是我认为必须要先了解的,可能会有些不全,仅供参考,如有不足欢迎补充

  • 最低限度的计算机组成原理以及单片机构成常识(一般来说MCU由内核(arm,risk-v等,执行指令,提供中断系统)存储(flash, ram等)外设(gpio,uart,can,ethernet等),一般芯片是要放在电路板上才能工作,综上zephyr的硬件驱动划分为arch, soc, board)
  • cmake(虽然使用west命令进行编译,但是实际的构建环境是cmake,因此在移植前,我建议了解最低限度的cmake知识)
  • kconfig(官方仓库https://github.com/ulfalizer/Kconfiglib,用于配置内核宏, 会影响构建过程以及C程序)
  • dts(devicetree 设备树)(zephyr系统通过设备树对arch,soc,board进行抽象,类似linux设备树,但是系统调用方式不同,zephyr通过将dts编译为宏,在程序和构建过程中调用)
  • linux(虽然据说windows也可以使用,但是我建议如无特殊原因,请尽量养成在linux或mac中开发程序,避免各种麻烦)
  • openocd(MCU调试工具) 这个东西的使用的话相对简单,但是编写tcl脚本需要对jtag/swd的底层原理比较熟悉.一般的MCU openocd中都包含了支持文件, 但是不巧的是GD32E103_eval的这款板子和芯片均不在支持范围内.
  • yaml(一种配置文件格式,类似json/xml)简单了解即可
  • git(zephyr版本通过git管理)
  • C Marco (C语言宏)
    • 虽然因为zephyr项目使用C语言编写,为了移植掌握C语言是必要的无需多做说明,但是在处理设备树的过程中,会用到极其复杂的宏调用,数十层的宏包装人脑展开已经极为困难,有些时候只能根据编译器预编译结果来检查问题. 所以如果您是C语言新手或关于预编译器工作原理不是很清楚的话,强烈建议您补全此处知识,包括但不限于宏拼接(##运算),可变参数列表宏(__VA_ARGS__)
  • vscode调试和编译的配置方法(可能经常使用keil,iar等IDE环境的朋友会比较陌生)

相关文件

zephyr的移植主要设计下面文件(module需要单独建立仓库,可以参考https://github.com/feilongfl/hal_gd32, 仓库内GD32E1的支持包来自gigadevice官网)

  • boards(板级外设)
  • socs(芯片外设)
  • drivers(驱动)
  • west.yml(module)

绝大多数都可以参考STM32F1x的芯片进行移植,其实从手册来看,驱动也可以共用, 但是为了避免STM32的驱动应用在其他厂家的芯片上所产生的法律和道德问题, 我主要使用GD32官方提供的代码.

主要问题

  • arm mpu可能在移植初期带来一些问题,所以在初期最好关闭
  • zephyr使用systick定时器运行,所以在开始配置时,我们可以不用从时钟系统开始.我认为从gpio led灯开始会比较容易.
  • 我的移植顺序(目前只做了这些,至此芯片基本功能已经完成,但是我适配的串口只能支持基本的收发,如果要应用console或其他subsys可能还要支持中断和DMA):
    • 已实现
      • led灯(GPIO的输出)
      • RCU时钟树
      • 按键(GPIO输入)
      • 串口(GPIO pinmux, uart外设)
    • 计划中
      • 串口(runtime config)
      • 串口(中断驱动)
      • 串口(DMA)
      • CAN
      • USB
  • openocd 这个是移植过程中比较头痛的,因为虽然会使用openocd调试一些芯片,但是编写tcl脚本适配芯片debug系统确实没怎么研究过.只了解一些边界扫描之类的理论知识.这个位置氛围两个部分,一个是debugger,另一部分是debugger和MCU间的通讯支持
    • debugger
      • GD32开发板接入pc,执行 lsusb,可以得到Bus 001 Device 006: ID 28e9:058f GDMicroelectronics CMSIS-DAP,因此debugger是CMSIS-DAP,这部分驱动openocd内提供.
    • debugger和MCU间的通讯支持
      • 因为GD32基本与STM32相似, 仔细调查发现是与STM32F1x系列相似(新系列例如G4等不兼容), 于是常识STM32F1的openocd配置,发现jtag和swd的ID芯片信息需要修改,修改后即可工作.
  • west.yaml 这个和android的repo命令所使用的manifest原理很相似,看来大家都觉得git submodule不好用
  • 感觉GD32的EVAL板质量一般
    • 目前手中的板子信号振铃极其严重,串口波特率115200就已经开始乱码了,有点怀疑是不良品
      • 也可能是usb串口不良,因为我没想到只有两个DB9的串口接口可以使用,用的淘宝8元包邮的那种,后续可能会更换usb串口测试下
      • 印象里CMSIS DAP是自带虚拟串口的,不清楚为啥GD的这个调试器没有接串口.像ST-link一样调试串口可能更友好一些.
    • 吐嘈下,好多年没用锉刀打磨PCB板子边角了o.o
    • 从手册来看,芯片支持CANFD协议,但是PHY芯片手册标识最高速率1M,不是CANfd应该使用的PHY芯片.
      • 后续不稳定可能要自己更换
      • 不过确实是第一次见国产CAN phy,以前只用过NXP的产品,不知道国产芯片是否能有超越数据手册的性能 o.o
      • 我猜GD是不想管理太多芯片,整个eval系列物料共用了
  • 移植过程中发现STM32的官方支持确实很到位, GD32就没有找到太多的支持.

写完之后再看感觉会移植的人也不需要看了,不会的可能看完还是看不会 o.o

PR用法

动图如下(顺便发现了termtosvg和asciinema这几个好玩的工具):

https://asciinema.org/a/443449

未知 的头像

发布者：飞龙

已发布

《移植zephyr到GD32E103_EVAL板子》有2条评论

  2. Pingback： 移植zephyr到AT32_SURF_F437开发板 – 飞龙的博客

留下评论