最近由于疫情问题，欧美等许多国家电路企业停工，同时因为疫情，各种居家办公、远程视频等设备需求增加，美国对华为等的制裁，导致这些公司大量囤积芯片，由于以上原因，全球范围内晶圆产能严重缺乏，从而引起各种芯片大幅涨价。ST的MCU也不例外，我们公司现在正在使用的STM32F072CBT6这款芯片就是如此，价格大概涨到了原来的10倍之多，出于成本考虑，所以公司决定找替代芯片。
找替代芯片，当然最好是pin to pin，功能能够完全兼容的，而能够替代STM32F072CBT6的，有其他非ST品牌的芯片，也有同品牌的STM32F103CBT6，当然，为了顺利替代，并投入最少的开发测试成本，最佳方案就是使用同一品牌的芯片来替代，所以就选择了STM32F103CBT6来替代STM32F072CBT6。
下面谈一下，在这个替换过程中，两款芯片的差异及需要注意的问题。
1、USB外设
在USB外设功能上，两款芯片存在有差异，STM32F072CBT6是内部带有DP脚的上拉电阻的，可编程配置来决定用不用，而STM32F103CBT6内部是没有DP脚的上拉电阻的，所以如果原来072的用了内部的上拉电阻，则替换成103之后，需要在外部增加上拉电阻。
2、FLASH扇区大小不同
STM32F072CBT6的flash扇区是2KB的，而STM32F103CBT6属于同系列中的中容量器件，其flash扇区是1KB的，所以在读写FLASH的过程中，需要对这个差异进行修改，尤其是bootloader这种大规模进行flash擦写的功能，这个更加要注意，扇区大小搞错了，升级功能是没法使用的。
3、时钟频率不同
STM32F072CBT6的时钟频率是48M，而STM32F103CBT6的时钟频率是72M，而且两款芯片的内核不同，一个是M0，一个是M3，这就意味着，执行同样的指令，两者所花费的时间是不同的，这就涉及到了一个时序的问题，比如说写入有时序要求的器件，如DSP，在原来的STM32F072CBT6的环境下，读写都是正常的，但是移植到STM32F103CBT6环境下，即使代码完全一样，但是时序也是不同的，尤其是软件模拟的不精确延时函数，时间上差别挺大的，所以在做了MCU更换后，需要重新调整代码的时序，以确保能够和有时序要求的器件正常通讯。
PS：关于软件模拟的延时函数，在从一款芯片换到另一款芯片时，也不要费力去查它们的时钟频率，计算函数执行时间了，这样太麻烦，最简单的，找台示波器测一下，对比在不同平台上的时间，调整下代码就好了。
4、bootloader功能需要注意的问题
比较需要注意的一点就是，在从APP跳转至BOOT时，一定要关闭所有已打开的中断，我在开发过程中，发现使用NVIC_Init()这样的库函数，并不是能够完全关闭中断，所以建议是在跳转前，可以手动的把已打开的中断一个一个的关闭掉，这样可以确保万无一失，不会在跳转过程中或者跳转之后发生了中断，但是却找不到中断入口，无法响应的情况。
5、GPIO的差异
有个点需要特别注意下，就是STM32F072CBT6里面，PB3、PB4、PA13等几个脚，复位后默认是用作普通IO的，但是如果换到STM32F103CBT6之后，则复位后默认是用作JTDO、JNTRST、JTMS功能的，所以这几个脚在移植时要额外处理下，把模式设置成普通IO来使用。
其他问题：
1、如下代码，在编译时会产生警告：integer operation result is out of range。
GPIOB->CRL &= ~(0xF<<28)
考虑下这个代码为什么警告说整型范围超限呢？按理来说，0xF左移28位也刚好32bit，没有超出32位整型的长度呀。其实是这样的，因为这里0xF并没有指定具体的数据类型，而KEIL MDK编译器，在这种情况下，会默认将该常量的类型认为是有符号型的，即有符号整型signed int，这样一来，符号位就占了一位，剩下的数据位就只有31位了，所以上面左移28位是会提示范围超限的，改成下述代码就可以了。
GPIOB->CRL &= ~(((uint32)0xF)<<28)
即先强制转化为无符号型整数，然后再移位，这样就不会提示范围超限了。
2、测试也好开发也好，一定要尽可能的使用好的器件，不要用那些半好半坏的器件，本来程序没问题，结果就是不正常，搞来搞去也找不出原因，白白浪费大量时间。
