1.CAN驱动架构
由于采用了RTT的spi device架构，不能再随心所遇的编写CAN驱动 了，之前内核虽然采用了RTT内核，但是驱动并没有严格严格按RTT推荐的架构来做，这次不同了，上次是因为4个MCP25625挂在了4路独立的SPI总线上， 这次2个mcp25625挂在1个SPI总线上，同时此SPI总线上还挂载了1个铁电，1个norflash，且FM25V10我已经使用了spi device架构驱动起来了，说实话，用RTT的spi架构，还很方便，于是CAN驱动我也只能用spi架构。首先我遇到一个问题就是，怎么处理mcp25625中断，之前是在中断中操作spi总线接收数据的，但在官方spi架构下，这种方法行不通，因为在RTT中，不允许在中断中调用可能导致中断挂起的操作，比如申请信号量、互斥互斥量等，但spi架构的核心函数都要lock（spibus），这直接就导致系统死掉，其实我测试发现不但不能在中断处理函数中调用可能导致中断挂起操作，即使在RT_TIMER_FLAG_SOFT_TIMER定时器中这种操作也是被禁止的，因为我想设计1个50ms定时器，定时发送几个CAN帧，发现直接在超时处理函数中发送CAN帧是不行的，（程序直接打印的原因是timer线程优先级为0，在优先级为0 的线程是不被允许申请资源的！），于是我只能专门新建一个发送线程，超时处理函数向此线程发送邮箱，“发送线程”收到邮箱后，触发发送动作。 接收线程也是类似这样的操作，在mcp25625的中断处理函数中只发送邮箱，而在设置了高优先级的接收线程内收到邮箱信息后， 开启接收CAN帧动作。经过2天的调试，基本可以实现MCP25625驱动。
2, mcp25625，不连接CAN总线时，发送死循环
OSM单次触发，CAN正常情况下，如果 发送不成功的话，会一直尝试发送，直到发送成功，但是也可以设置发1次，就需要使能此位（正常情况禁止）
这个与USB上的HOST会自动再发IN Token,非常像，总线上不回应数据，就一直询问，这2个地方都是发送之后会产生1个中断，造成系统一直在中断、中断处理死循环，其它任务得不到执行。
解决办法也不一样，
对于MERR中断， 直接关闭MERR中断使能，因为在中断处理函数中，MERR中断处理非常简单，就是清了一下中断标志，禁止MERR中断也没有什么影响，
对于USB IN taken产生NACK中断， 只能减少中断次数， 设置为1ms中断1次，也能解决问题。
3, mcp25625接收丢数据
因为RTTHREAD效率问题，也不好改，而且用的是倍受争议的SPI HAL库，同中接收数据不在中断中了，在线程中，这就导致了老是丢CAN数据了 ，试过了很多方法，也没解决，包括，提高接收线程的优先级，提高了6， 仅次于timer系统记数器优先级，结果还是不能，最终通过提高SPI时钟频率解决，因为SPI总线经连通了核心板与底板，上面又挂了很多外设，之前设置的是5Mhz，直接提高到10Mhz,测试SPI总线正常，收发数据正常，CAN也没再丢数据，先这个办了。
