软件SPI驱动，兼容类比芯片的spi驱动  感谢分享！

楼主这结论有点冤枉姚总了，以我个人使用经验说一下51架构下STC的DPTR问题： 1、受限于51架构本身和没有自己编译器等原因，STC的DPTR1确实很鸡肋，这从STC官方不提供任何高级语言例程而是仅仅提供了一个基本上属于罗列指令表的简单汇编代码就可以看出。而更换到STC32的251架构后，已从根本上避免了51架构这一性能瓶颈问题，也就没人再去关心有没有DPTR1了。 2、STC的双 DPTR指针, 支持 XRAM 读出/写入，也完全支持CODE 读出/写入，这点不用质疑，本人已有实际工程代码在运行可以充分证明这一点。楼主遇到的问题应该是自己程序或仿真有BUG（因为STC的在线仿真确实有BUG，尤其是涉及中断或reentrant时）。 3、个人认为，老姚这个双DPTR设计在机理上最大的致命伤在于：在没有自己编译器的致命软肋下又没有避开这一软肋将DPTR1纳入指令集（仅仅是个人看法，实现的难度或成本得去问姚总本人了）；同时也没有采用借篷使风的方式，做到与其它具有双DPTR且受Keil支持的大厂MCU兼容（可能涉及专利问题），以致造成现在这个既不上又不下的尴尬局面。 4、说它‘’不上‘’是因为，按STC自己双DPTR的‘独特’机制，若想发挥极限性能就需要关中断，大写的一个‘尬’字，即便为此还专门设计了TA寄存器的锁定机制也基本于事无补，适用面有限；对这个娘胎里带来的病，也只能说老姚算是用心了。 5、说它‘’不下‘’是因为，即便有种种影响性能发挥的限制，但如果正确使用DPTR1还是能在敏感任务中大幅提高涉及xdata及code段数据操作程序的性能。按本人实测大于8字节就值得一试，16字节xdata搬运可提高至少一倍的性能，原地反序约1.5倍。字节数越大、逻辑越复杂提高越明显。 6、如果你主要关心的是内存搬运性能且有可选择性的话，更建议你使用STC新型号MCU的DMA来代替这个不争气的DPTR1。 我的结论是：2024年了，如果你没有在51架构上涉及大量xdata及code段数据操作的时间敏感任务，或使用的是251架构的MCU（ARM、RISC不在本帖讨论范围），恭喜你大可睁大双眼问一句：什么是DPTR1？ 另外，STC USB口仿真性能只会比232口仿真强，不会弱。接口不是仿真的核心，只是负责仿真数据的传输。USB接口性能自不必说，看一下现在计算机上遍布的都是USB口而不是RS232也能证明这个结论了。 楼主说的非法操作死机退不出的问题，感觉更大可能是Keil C51软件的问题。Keil已经放弃对C51的支持了，但没办法我们还在用，你起个中文项目名或用个中文路径偶尔它也会死机的，何况是非法操作。 楼主说的USB口仿真比用 232口 速度慢 2-3倍(估算)，建议检查一下USB接口硬件设计（PCB差分走线、阻抗匹配电阻、供电、滤波等）与所用的连接线材，USB的高速性使它可能比232更挑剔些。最好更新一下STC USB仿真的驱动（我现在用的是V1,19版本），至少我还没遇到过USB仿真比232仿真慢的情况。

:kiss: 好文一定要顶！！！！！！！

顶一个，看看是啥报备

谢谢楼主分享 ！！！

顶:)

好贴就要回啊！拼命回复一下，谢谢！

很好很强大，此贴必顶。:kiss:

原理图也一并贴上才真有意义

"USB接口: 配置SLAVE USB..."要是Master的就更超值了;P

$1.44 for 64Kbyte devices in the 64-pin LQFP64 package, for quantities of 10,000 units也不太便宜啊:L

看的一头雾水:L

STM32F103的很多，STM32F107很少，这个要顶！

非常不错的资料。。。