Raspberry pico处理器的移植SMP教程
raspberry pico 是一款双核cortex-m0的处理器，在rt-thread提供的bsp中目前是默认采用libcpu/arm/cortex-m0，其并没有对多核进行支持。在coremark的测试中pico的性能很一般，只用一个核心实在是太浪费了，所以下面用一种不太优雅的方式基本实现pico的smp，简单测试没有问题，当然由于萌新对于内核的理解程度有限，总是可能存在一些问题，不过总算跑起来了不是~
移植smp
在这之前，官方的文件完全没有支持cortex-m的多核。
首先是几个基本的函数对接：
rt_hw_cpu_id：最首先需要实现的一个也是最容易的实现的一个，直接访问pico的sio就可以
rt_hw_interrupt_disable/enable: 在smp框架当中，关闭中断不只是屏蔽中断，其还要通过spinlock来保证对资源访问的互斥，对于此rtt在rthw通过宏定义将其替换，并且重新命名原来的中断控制函数
rt_hw_spin_lock_xxx：自旋锁，用于多核之间的资源保护，在rp2040中芯片提供硬件spinlock使用，这一部分同样使用pico-sdk的api即可，选择unsafe版本
rt_hw_secondary_cpu_up：在主cpu启动后，运行调度器，调度器会调用main线程运行，main线程运行前会首先调用该api来启动第二个核心。rp2040两个核心其实是上电以后同时启动的，cpu-1会在bootrom中被拦截下来进入等待状态，我们可以通过sio的fifo来唤醒第二个核心，pico-sdk中提供了api,可以直接指定cpu-1唤醒后执行的函数。在唤醒过程中同时使能两个cpu的sio中断，用来进行ipi_handler.
在需要调度的时候，cpu之间可能会互相通知让其进行调度，该部分通过rt_hw_ipi_send和rt_hw_ipi_handler对接，
上面对接的函数都比较基础，其次是对接上下文的汇编代码部分，这一部分就不是特别顺利了。简单梳理一下cortex-m的调度流程，rt_schedule获取最高优先级的任务然后使能pendsv中断并在全局变量中保存调度信息，最后在完成高优先级中断（或者直接进行pendsv）后进行实际的上下文切换，在smp中基本同理，但是由于rt-thread的smp是针对cortex-a提供的，这里出现了一些问题。
首先在调度中必须关注一个函数，rt_cpus_lock_status_restore(thread)，其将要调度的线程绑定到当前的cpu上，调用该函数的位置是一个关键问题
在cortex-a中其在rt_hw_context_switch中被调用，这对于cortex-a是可行的，因为在非中断情况下a核会直接进行线程切换而不需要pendsv,但是对于cortex-m核心放在这个位置会存在下面一个问题：pendsv是中断，所以需要使能中断才能运行，因此在rt_hw_context_switch后立马就有一个rt_hw_interrupt_enable，如果m核工作在非smp框架下这是没有问题的，但是在smp框架下当前的线程已经变了，而rt_hw_interrupt_enable是同当前线程绑定的，所以这里会导致cpu的scheduler_lock_nest,cpus_lock_nest错乱，从而导致调度器不能正常工作
基于上面的描述，我考虑把rt_cpus_lock_status_restore放在pendsv中进行调用，这样就可以保证scheduler_lock_nest工作的正确性，但是导致一个更大的问题！！！在rt_schedule函数中，如果中断还没有使能的情况下重复调用rt_schedule（systick中多层中断）会导致已经被标记为running的线程无法正常被加入到就绪列表中。因为在上一次的rt_schedule中线程已经被移除了，其等待在pendsv中绑定到当前cpu的时候rt_schedule再次到来，其应该被重新加入到就绪列表（如果优先级低的话），但是schudler是基于当前cpu上的线程来管理的，由于之前被调度的线程当前还没有绑定，所以线程变成游离状态而无法被调度，就会出现下面的情况：
所以rt_cpus_lock_status_restore(thread)只能在rt_hw_context_switch中被调用，但这种情况下我们需要处理scheduler_nest和cpus_lock_nest错乱的问题，由于smp框架将nest绑定到线程上，但实际上锁针对的还是cpu,我也认为将太绑定到cpu上更合适，为了不修改内核源码的情况下实现，我在rt_hw_context_switch中将当前cpu线程的nest绑定到需要调度的线程上，这样就等价于把nest绑定到cpu上，此时就可以正常工作了。
解决上述问题后知剩下最后一个问题，我们前文的讨论都是基于非中断情况下的，对于cortex-m而言中断中的调度和非中断中的调度是一致的，都是基于pendsv实现的，所以我们rt_hw_context_switch,rt_hw_context_interrupt_switch用一套一样的代码就可以，但是在smp框架中这两个部分具有两个调度函数，在中断中调用rt_schedule，smp框架会直接跳过当前调度并且给当前cpu打上中断调度标记，最后在离开中断的时候调用rt_scheduler_do_irq_switch(void *context)来实现，对于cortex-a的中断结构来说这是没有问题的，只要保证switch能够在本次调度过程中直接切换就行，但是对于cortex-m这样就不太合适，我们可以把nvic弄成统一irq的样子，但是我觉得直接废弃rt_scheduler_do_irq_switch更加合适。
为了使得调度器不知道我们在中断状态，我把rt_interrupt_enter/leave注释掉了(应该在涉及内核调度的中断中全部采用这种办法)，这样irq_nest就一直是0,调度器也不会去调用do_irq了，其实我们不用这个处理方法也能够工作的，但是中断中就没法调度了，实时性也没法保障。按照我的理解在cortex-m中这样的处理并不会有太大的问题，但是总不太好是吧~
最后基于上面全部的修改，rp2040的smp能够正常工作，小灯能够按照正常闪烁。
最后
我对于rt-thread的理解还很有限，萌新，有很多问题我可能预料不到，这样的实现方式我也觉得不太优雅，不过总算是跑起来了（肝了两天还是有点累emmm）。后续会优化整理并且再经过一段时间的测试，或许能够喜提自己的第一个rt-thread pr ～
最后是关于smp,我不明白为什么把nest绑定到thread而不是cpu上，因为总还是在锁cpu，其次rt-thread的smp似乎是专门给a核设计，目前的多核mcu也有蛮多，希望可以提供一些相关支持。
attention please!!（2022-5-12）: 评论区有提供bsp的压缩包
只是一个可以玩玩的状态，目前可以确定的是存在和调度相关的bug会导致系统崩溃（目前测试在shell反复调用list_thread可能崩溃，可能和kservice有关）。
另外如果线程在调度器启动前被创建，即init_borad_export方式创建则一切正常（list_thread不会崩溃），在main中创建就可能出现崩溃,希望各位大佬可以给点调试思路。
由于最近事情很多比较忙绿，没有时间调试和阅读代码，但会在后续一段时间（六月-七月）调试完善smp调度并在后续添加完善pico的驱动支持，希望感兴趣的同学一起交流哈。(也在看看rtthread v5.0的消息哈)
来源：rtthread物联网操作系统
电子声学防水网的特点，喇叭听筒如何防尘防水
关于AGV无人搬运叉车，它的七大优点是什么
PSoC之太阳能应用
浙江40座电力北斗基准站建成，提高智能电网的弹性
解析如何给稳压器构建监控和控制提供解决方案
Raspberry pico处理器的移植SMP教程
防爆燃气流量计的应用场合及产品优势
美芯晟推出2A, 24V降压DC-DC转换器MT8102
必达安保系统i1A8FK-AN2门锁简介
一家医疗保健AI初创公司推出了一款软件
三星S8最新谍照曝光：全面屏+虹膜识别开孔一览无余
PCIe串行总线发展历史及工作原理
机器人在无人咖啡店中的应用介绍
DS1859内部校准及右移位(可扩展动态范围)
电瓶修复技术——简单介绍电池反应关系
无人车将美团送上市
一文详解世界杯上的5G和通信技术
特斯拉发布自动驾驶芯片
锂电池购买完全手册
高手讲解PIC单片机：单片机的入门就是这么简单
移植smp
在这之前，官方的文件完全没有支持cortex-m的多核。
首先是几个基本的函数对接：
rt_hw_cpu_id：最首先需要实现的一个也是最容易的实现的一个，直接访问pico的sio就可以
rt_hw_interrupt_disable/enable: 在smp框架当中，关闭中断不只是屏蔽中断，其还要通过spinlock来保证对资源访问的互斥，对于此rtt在rthw通过宏定义将其替换，并且重新命名原来的中断控制函数
rt_hw_spin_lock_xxx：自旋锁，用于多核之间的资源保护，在rp2040中芯片提供硬件spinlock使用，这一部分同样使用pico-sdk的api即可，选择unsafe版本
rt_hw_secondary_cpu_up：在主cpu启动后，运行调度器，调度器会调用main线程运行，main线程运行前会首先调用该api来启动第二个核心。rp2040两个核心其实是上电以后同时启动的，cpu-1会在bootrom中被拦截下来进入等待状态，我们可以通过sio的fifo来唤醒第二个核心，pico-sdk中提供了api,可以直接指定cpu-1唤醒后执行的函数。在唤醒过程中同时使能两个cpu的sio中断，用来进行ipi_handler.
在需要调度的时候，cpu之间可能会互相通知让其进行调度，该部分通过rt_hw_ipi_send和rt_hw_ipi_handler对接，
上面对接的函数都比较基础，其次是对接上下文的汇编代码部分，这一部分就不是特别顺利了。简单梳理一下cortex-m的调度流程，rt_schedule获取最高优先级的任务然后使能pendsv中断并在全局变量中保存调度信息，最后在完成高优先级中断（或者直接进行pendsv）后进行实际的上下文切换，在smp中基本同理，但是由于rt-thread的smp是针对cortex-a提供的，这里出现了一些问题。
首先在调度中必须关注一个函数，rt_cpus_lock_status_restore(thread)，其将要调度的线程绑定到当前的cpu上，调用该函数的位置是一个关键问题
在cortex-a中其在rt_hw_context_switch中被调用，这对于cortex-a是可行的，因为在非中断情况下a核会直接进行线程切换而不需要pendsv,但是对于cortex-m核心放在这个位置会存在下面一个问题：pendsv是中断，所以需要使能中断才能运行，因此在rt_hw_context_switch后立马就有一个rt_hw_interrupt_enable，如果m核工作在非smp框架下这是没有问题的，但是在smp框架下当前的线程已经变了，而rt_hw_interrupt_enable是同当前线程绑定的，所以这里会导致cpu的scheduler_lock_nest,cpus_lock_nest错乱，从而导致调度器不能正常工作
基于上面的描述，我考虑把rt_cpus_lock_status_restore放在pendsv中进行调用，这样就可以保证scheduler_lock_nest工作的正确性，但是导致一个更大的问题！！！在rt_schedule函数中，如果中断还没有使能的情况下重复调用rt_schedule（systick中多层中断）会导致已经被标记为running的线程无法正常被加入到就绪列表中。因为在上一次的rt_schedule中线程已经被移除了，其等待在pendsv中绑定到当前cpu的时候rt_schedule再次到来，其应该被重新加入到就绪列表（如果优先级低的话），但是schudler是基于当前cpu上的线程来管理的，由于之前被调度的线程当前还没有绑定，所以线程变成游离状态而无法被调度，就会出现下面的情况：
所以rt_cpus_lock_status_restore(thread)只能在rt_hw_context_switch中被调用，但这种情况下我们需要处理scheduler_nest和cpus_lock_nest错乱的问题，由于smp框架将nest绑定到线程上，但实际上锁针对的还是cpu,我也认为将太绑定到cpu上更合适，为了不修改内核源码的情况下实现，我在rt_hw_context_switch中将当前cpu线程的nest绑定到需要调度的线程上，这样就等价于把nest绑定到cpu上，此时就可以正常工作了。
解决上述问题后知剩下最后一个问题，我们前文的讨论都是基于非中断情况下的，对于cortex-m而言中断中的调度和非中断中的调度是一致的，都是基于pendsv实现的，所以我们rt_hw_context_switch,rt_hw_context_interrupt_switch用一套一样的代码就可以，但是在smp框架中这两个部分具有两个调度函数，在中断中调用rt_schedule，smp框架会直接跳过当前调度并且给当前cpu打上中断调度标记，最后在离开中断的时候调用rt_scheduler_do_irq_switch(void *context)来实现，对于cortex-a的中断结构来说这是没有问题的，只要保证switch能够在本次调度过程中直接切换就行，但是对于cortex-m这样就不太合适，我们可以把nvic弄成统一irq的样子，但是我觉得直接废弃rt_scheduler_do_irq_switch更加合适。
为了使得调度器不知道我们在中断状态，我把rt_interrupt_enter/leave注释掉了(应该在涉及内核调度的中断中全部采用这种办法)，这样irq_nest就一直是0,调度器也不会去调用do_irq了，其实我们不用这个处理方法也能够工作的，但是中断中就没法调度了，实时性也没法保障。按照我的理解在cortex-m中这样的处理并不会有太大的问题，但是总不太好是吧~
最后基于上面全部的修改，rp2040的smp能够正常工作，小灯能够按照正常闪烁。
最后
我对于rt-thread的理解还很有限，萌新，有很多问题我可能预料不到，这样的实现方式我也觉得不太优雅，不过总算是跑起来了（肝了两天还是有点累emmm）。后续会优化整理并且再经过一段时间的测试，或许能够喜提自己的第一个rt-thread pr ～
最后是关于smp,我不明白为什么把nest绑定到thread而不是cpu上，因为总还是在锁cpu，其次rt-thread的smp似乎是专门给a核设计，目前的多核mcu也有蛮多，希望可以提供一些相关支持。
attention please!!（2022-5-12）: 评论区有提供bsp的压缩包
只是一个可以玩玩的状态，目前可以确定的是存在和调度相关的bug会导致系统崩溃（目前测试在shell反复调用list_thread可能崩溃，可能和kservice有关）。
另外如果线程在调度器启动前被创建，即init_borad_export方式创建则一切正常（list_thread不会崩溃），在main中创建就可能出现崩溃,希望各位大佬可以给点调试思路。
由于最近事情很多比较忙绿，没有时间调试和阅读代码，但会在后续一段时间（六月-七月）调试完善smp调度并在后续添加完善pico的驱动支持，希望感兴趣的同学一起交流哈。(也在看看rtthread v5.0的消息哈)
来源：rtthread物联网操作系统
电子声学防水网的特点，喇叭听筒如何防尘防水
关于AGV无人搬运叉车，它的七大优点是什么
PSoC之太阳能应用
浙江40座电力北斗基准站建成，提高智能电网的弹性
解析如何给稳压器构建监控和控制提供解决方案
Raspberry pico处理器的移植SMP教程
防爆燃气流量计的应用场合及产品优势
美芯晟推出2A, 24V降压DC-DC转换器MT8102
必达安保系统i1A8FK-AN2门锁简介
一家医疗保健AI初创公司推出了一款软件
三星S8最新谍照曝光：全面屏+虹膜识别开孔一览无余
PCIe串行总线发展历史及工作原理
机器人在无人咖啡店中的应用介绍
DS1859内部校准及右移位(可扩展动态范围)
电瓶修复技术——简单介绍电池反应关系
无人车将美团送上市
一文详解世界杯上的5G和通信技术
特斯拉发布自动驾驶芯片
锂电池购买完全手册
高手讲解PIC单片机：单片机的入门就是这么简单