笑死，STC8H的双DPTR仿真问题折腾三天，绝望的发帖前30秒解决……

xuyiyi

笑死，STC8H的双DPTR仿真问题折腾三天，绝望的发帖前30秒解决…… [复制链接]

声明: 本贴框架格式系抄袭网友hyperma之贴, 版权系网友hyperma所有~~~ 

我真的快疯了，无论淘宝上买的STC8H8K64U（模块），还是 STC官方送的板子，把规划中的改写的使用双DPTR指针的

函数strcmp,strncmp,strcpy,strncpy,memcmp,memcpy,memccpy,memmove，

都用STC8H的大ROM装进去，但没想到在这个STC8H超强双DPTR面前踢了铁板。

由于我是从中颖51叛变过来的，对双DPTR一向自认很有信心，用官方库函数+自编库函数，已经玩得不能再熟练了。

上机调试出错, 那很正常, 单步+断点跟踪调试, 查找原因, 就是发现第二个DPTR指针不工作啊！

更改 DPS寄存器没用, 更改直接地址(0xE3)可行, 但就是第二个DPTR指针死活不工作啊！ 

单步调试跟踪，出现了奇怪的事情，就是发现第一个DPTR指针始终在工作, 第二个DPTR指针永远不工作啊！怎么折腾都这样，

于是我折腾了三天。足足三天啊！换STC8H8K64U板子、重装STC8H8K64U仿真驱动、重装Keil, 重启电脑，都不成……。

实在不行了，凌晨想上来发帖子求救……。唉，揉揉已经通红的眼睛看会儿帖子吧，偶然看到了以前自已发的帖子里, 回网友的疑问? 

在数组数据交换过程中, 用DMA传输快? 还是用软件模拟传输快? 自已编写了测试程序, 两者之间的传输速率当然会复杂一肯步些PK, 

结果 软件模拟传输飞快 完胜 DMA传输, 在软件模拟传输中, 我成功应用了STC8H8K64U的双DPTR功能啊！我……

然后调出该软件模拟传输测试程序, 编译运行一下看数据，正常了……。这是为什么啊！为什么啊！真心向版主求教，是否说STC8H的仿真及软件是有问题的？

 

 

xuyiyi

后记:

我随意设断点, 单步或连续跟踪调试，发现该软件模拟传输测试程序不稳定, 时好时坏(查看数组, 传输的结果错误), 经不断更改断点位置, 单步或连续跟踪.

得出以下结论:

STC8H的仿真, 不支持第二个DPTR指针, 无论是单步, 还是连续, 只要在使用第二个DPTR指针过程中有停留(停顿), 就会出错, 永远停止第二个DPTR指针的工作!!!

像前面我调试 函数strcmp,strncmp,strcpy,strncpy,memcmp,memcpy,memccpy,memmove，就是在 双DPTR指针应用中, 加了断点, 造成STC8H的仿真过程中, 

在第二个DPTR指针执行过程中有了停顿, 而产生第二个DPTR指针不工作的结果! 

 

 

maychang

xuyiyi 发表于 2023-2-25 04:49 后记: 我随意设断点, 单步或连续跟踪调试，发现该软件模拟传输测试程序不稳定, 时好时坏(查看数组, 传输 ...

好久不见！

 

maychang

xuyiyi 发表于 2023-2-25 04:49 后记: 我随意设断点, 单步或连续跟踪调试，发现该软件模拟传输测试程序不稳定, 时好时坏(查看数组, 传输 ...

这应该是仿真软件的BUG，不是硬件问题。

yubinwu

最笑死的居然叛变到STC

STC号称死太惨

正确的道路应该是从STC叛变到别的

xuyiyi

yubinwu 发表于 2023-2-25 11:15 最笑死的居然叛变到STC STC号称死太惨 正确的道路应该是从STC叛变到别的

中颖51, 自疫情的几年中, 一直买不到芯片, 现在也不正常, 搞不到芯片, 没办法~~~  

wangerxian

DPTR指针是STC单片机专有的？

freebsder

看来多半是仿真的问题。

xuyiyi

  经过多次更改程序(使用 DPTR0 和 DPTR1 的不同排列组合 及 前后次序) 测试, 得出以下结论.

1, STC的双 DPTR指针, 支持 XRAM 读入/写入, 完全正确, 工作正常.

2, STC的双 DPTR指针, 第一指针 DPTR0 支持 CODE 读入, 完全正确, 工作正常.
    第二指针 DPTR1 完全不支持 CODE 读入, 一执行就玩蛋, 用 STC8H USB口仿真的直接死机(或数十秒才能退出),
    用 STC8H 232口仿真的能退出, 但执行结果错误.

3, 最终结论是 STC的双 DPTR指针, 第二指针 DPTR1 完全不支持 CODE, 

4, STC8H USB口仿真, 性能比 用 232口仿真的 差很多, 直观上看, 下载程序, 执行单步等, 用USB口仿真 比 用 232口 速度慢 2-3倍(估算),

   执行到非法操作(比如前面提到的, 用 DPTR1读 ROM) , 可能死机退不出, 但用 232口仿真的, 能够正常退出. 

sailing8

楼主这结论有点冤枉姚总了，以我个人使用经验说一下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仿真慢的情况。