拿到这样的需求，我们当然是先得担保通讯正常。于是我找了一个USB例程与一个CAN例程，分别调试验证。
经由几番折腾已经担保了USB与上位性能正常通讯了，也能担保了CAN的正常收发（拿了两块开拓板做验证）。
两头都没有问题了，再加上一些数据处理就差不多完成了。USB与CAN我都是第一次用，没想到那么顺利，美滋滋，正准备放松的时候，问题就来了。这是一个整体的东西，终极都要把这两部分凑集起来吧。
我把CAN工程里关于CAN的部分移到USB工程里，这时候CAN竟然用不明晰。这时候我就开始在疑惑自己是不是手贱误删了哪里了，于是重新来一遍，创造还是弗成。
查了代码良久也没找出什么缺点了，于是决定先不找缺点了，进度要紧，这时候以为该当是工程哪里有问题了，先想其它办法避过这个问题。
于是乎我就换着来，我把USB的工程里关于USB的部分移到CAN工程里。大家猜一猜发生了什么？USB竟然打都打不开！
要炸了。。但是这时候已经很明确肯定不是移植问题了。CAN部分首先想到了波特率是不是对不上了，USB部分首先想到USB的时钟是从哪来的，之前没用过也没仔细看。带着这两个问题去查看了参考手册与代码，果真，STM32F429的USB的时钟还真有点分外（不知道其它芯片是不是也是这样），其来自于PLL输出，而不是我们熟知的APB1、APB2：
从时钟树中我们可以看出：（1）的输出是系统时钟，（2）的输出是USB时钟。干系公式：
当然（2）的输出不仅仅是给USB供应时钟，还给RNG与SDIO供应时钟：
这一部分对应的代码在system_stm32f4xx.c中。下面看看USB工程、CAN工程中该文件的差别：
可见，问题找出来了。在USB工程中，CAN通讯不正常是由于系统时钟降为168MHz，导致APB1时钟变为42MHz，而代码中是用APB1=45MHz来打算CAN的波特率的，以是导致波特率对应不上导致CAN通讯缺点。
在CAN工程中，系统时钟为180MHz，USB OTG FS时钟变为51MHz，超过了正常的48MHz，导致USB不能正常事情。
以是，每当用到USB，都得单独配置PLLCLK = 168MHz了，这样的话其他外设可能得改变原有的配置，比如这里的CAN就得用APB1=42MHz来打算波特率了，否则就会出错。这很未便利。。
正如野火火哥说的，这是ST的一个奇葩设计。
以是，大家往后再利用USB的时候当心这个陷阱！
以上便是本次的条记分享，如有缺点，欢迎指出！
