本帖最后由 xhackerustc 于 2025-4-21 00:01 编辑
#申请原创# @21小跑堂
谢谢二姨家谢谢ST，STM32N6570-DK这块板子非常震撼，比笔者手里的任何开发板包括能跑linux的SBC都大都沉，配置齐全，工艺上佳，笔者爱不释手，由此也感觉到这个系统复杂度不低。开箱等帖子咱就不做了，可参考版友@一路向北lm或者其它版友的帖子，笔者直接进入今天主题：对于STM32N6570-DK，最方便最适合Linux下开发的开发环境是什么样的？笔者个人理解开发环境狭义上包括工具链、源码工程组织、烧录和调试这三大类，需要为这三大类找到合适的称手的工具；而广义上其实还包括源码版本管理，RTOS or 裸机选择，如果选RTOS环境那RTOS的选型是什么。
1. arm-none-eabi-gcc + openocd + STM32CubeProgrammer + west/cmake/git + zephyr
笔者选型了半天选择了如上组合，其中arm-none-eabi-gcc是工具链，openocd用来调试和烧录（openocd目前还无stm32n6的外置flash算法支持，但stm官方或社区开发者或笔者自己加上是迟早的事，在此之前先用STM32CubeProgrammer烧录，但其实开发过程中STM32CubeProgrammer很少用到，至于为什么下面会讲），zephyr是一款开源的RTOS，git是源码版本管理，cmake用于源码工程组织，west是zephyr组织基于python语言开发的一款多用途工具，它集合了android的repo工具的功能+用于zephyr的编译和烧录命令。下面说说这么选择的理由：
1.1 芯片复杂度不低
查阅STM32N6570的文档发现，这款芯片复杂度已经超过一些跑linux的基于Cortex-A7之类的SoC，而且资源丰富（自身就有4.2MB的连续sram，再结合外扩的psram），没必要在资源上上太抠，这时候跑裸机意义不大而且工作量是天量，所以必须上一款有着完善生态的RTOS。
1.2 zephyr获得了芯片原厂的支持
目前比较流行的RTOS有zephyr、nuttx、RT-Thread、FreeRTOS、threadx。其中后两者更像是一个基本调度调度功能的基本OS核心，虽然它们也有配套的各种网络协议栈、文件系统、usb栈。但笔者个人觉得对于资源有限的低端MCU，这种OS理念比较合适，所有硬件设备上操作基本都是裸机那种做法，基本无OS级别的抽象和隔离，好处是省资源嘛；而对于资源丰富的如STM32H7、STM32N6系列的MCU，这种OS理念有点过时了，基于这种OS对于任何一款类似资源丰富的SoC把项目做好的工作量几乎是天量，虽然以前的经验可以复用，但你总得修改适配，维护性太差，那如果以稍许sram/flash甚至cpu计算资源换来OS级别的抽象，那应用代码就可以完全复用一行都不改，这样代码维护性、可重用性大大提高。本段开始提及的流行RTOS前三者都是有基本完备生态的RTOS，但笔者观察它们的git log和仓库issues、PR发现一个很残酷的现实：世界上几乎所有的芯片原厂都重度参与了zephyr的开发，这里“重度”的意思是有全职的工程师员工参与代码提交、code review等过程，而其它两款RTOS虽然也有芯片原厂参与，比如nuttx就有乐鑫公司的员工参与，但相比zephyr太少了，更为明显的是：这些芯片原厂不仅仅参与了zephyr对其自身芯片的支持，而且深度参与了zephyr公共部分比如usb协议栈、网络协议栈、蓝牙协议栈等通用部分的开发。综上虽然zephyr的学习曲线比较抖，但笔者觉得zephyr可能是MCU领域的linux，值得学习使用并参与开发。当然对于资源有限的MCU，FreeRTOS仍不失为一个好选择。
2. zephyr代码下载
具体参考zephyr官方文档，https://docs.zephyrproject.org/latest/develop/getting_started/index.html
简单来说步骤就是，生成python venv环境，pip安装west工具，用west初始化zephyr仓库，west update
3. stm32n6570_dk上zephyr初尝试
如前所述，zephyr获得了芯片原厂的大力支持，这不stm32n6570_dk才出来没多久，zephyr已经完全支持上啦，而且是ST自己全职工程师做的哦，这代码质量与响应速度和社区爱好者做是完全不一样的。至于zephyr对stm32n6570-dk板子目前已经支持到什么程度，大家可以看看这个链接https://docs.zephyrproject.org/latest/boards/st/stm32n6570_dk/doc/index.html。可以看到大部分的外设已经支持了，包括can、usb、dma、mmc、eth、xspi、mem controller（用于psram等），暂未被支持的外设有lcdc、audio、NPU、camera。
3.1 执行如下命令编译zephyr自带shell
west build -b stm32n6570_dk --build-dir=/tmp/build samples/subsys/shell/shell_module
编译结束后在/tmp/build/zephyr/目录下会有zephyr.elf, zephyr.bin等文件生成，其中zephyr.bin即是笔者要加载到sram中运行的zephyr固件
4. openocd cfg文件的书写
笔者研究stm32n6的文档特别是debug部分相关章节后，自己写了一个用于stm32n6的openocd cfg文件，完整版本如下:
# SPDX-License-Identifier: GPL-2.0-or-later
# script for stm32n6
source [find target/swj-dp.tcl]
if { [info exists CHIPNAME] } {
set _CHIPNAME $CHIPNAME
} else {
set _CHIPNAME stm32n6
}
set _ENDIAN little
#jtag scan chain
if { [info exists CPUTAPID] } {
set _CPUTAPID $CPUTAPID
} else {
if { [using_jtag] } {
set _CPUTAPID 0x4ba00477
} {
# this is the SW-DP tap id not the jtag tap id
set _CPUTAPID 0x6ba02477
}
}
swj_newdap $_CHIPNAME cpu -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id $_CPUTAPID
dap create $_CHIPNAME.dap -chain-position $_CHIPNAME.cpu
set _TARGETNAME $_CHIPNAME.cpu
target create $_TARGETNAME cortex_m -endian $_ENDIAN -dap $_CHIPNAME.dap
if {![using_hla]} {
# if srst is not fitted use SYSRESETREQ to
# perform a soft reset
cortex_m reset_config sysresetreq
}
5. 板子上加载与运行zephyr固件
stm32n6的sram有4.2MB之巨，如此大的sram使得很多事情成为可能如完全sram上执行，更别提还有板载的psram。所以stm32n6570_dk的开发与以往MCU大有不同，完全可以将固件通过调试器加载到sram执行，等功能基本开发完备后再烧录到xspi flash中，所以目前笔者很少用到STM32CubeProgrammer。先把BOOT1调至1的位置，意思是进Development boot模式，笔者用openocd加载zephyr固件过程如下：
5.1 一shell中执行如下命令：
openocd -f interface/stlink.cfg -c "transport select dapdirect_swd" -f target/stm32n6.cfg -c "adapter speed 8000"
5.2 另一shell中执行如下命令：
5.3 在openocd的上述telnet seesion中依次执行如下命令：
halt
load_image /tmp/zephyr.bin 0x34180400
reg pc 0x341855f0
resume
注1：之所以加载到0x34180400，是因为zephyr的stm32n6570_dk板级dts就是这么布局的：
因无"zephyr,flash"这个属性，所以代码都是链接于axisram2处，它的首地址0x34180400
注2：之所以pc改成0x341855f0，是因为查看编译后的zephyr.elf对应的map文件reset entry就是放这里
openocd telnet session运行相关全套命令截图如下：
执行完resume命令后，板载stlink对应的虚拟串口上应该有一个zephyr shell了，可以用minicom等命令打开stlink的虚拟串口。
6. 来几张运行美图供欣赏
| 
楼主
标题置顶
标题高亮
