请问STC, 这官方示范程序, 你们测试过吗???
本帖最后由 LAOXU 于 2023-3-3 13:03 编辑从STC-ISP中下载的示范程序, STC8H系列-增强型双数据指针示例代码2-ASM
直接下载编译, 测试芯片为 STC8H8K64U
测试结果显示, 根本无法从ROM中拷贝数据到XRAM中!
“测试结果显示”－－照你的截图，你是想把所谓结果从KEIL界面（软件仿真）看到。但是KEIL并不认识STC大量的新外设。DPTR0、DPTR1这两个指针共用同一个寄存器地址，通过DPS切换和设置是否自动递增递减等功能。你就会发现你认为的结果跟KEIL得出的完全不同。这些都应该在实物上运行和回显，比如使用硬件仿真或者串口回发数据。 飞哥 发表于 2023-3-3 09:47
“测试结果显示”－－照你的截图，你是想把所谓结果从KEIL界面（软件仿真）看到。但是KEIL并不认识STC大量 ...
谢谢飞哥回复.
说明一下,DPTR0、DPTR1这两个指针不是共用同一个寄存器地址，详见STC相关手册.
我是通过全速运行的, DPS切换中未设置任何断点及单步运行(上次测试就发现, STC仿真不支持双数据指针), 详见:
笑死, STC8H的双DPTR仿真问题折腾三天,绝望的发帖前30秒解决...
https://www.stcaimcu.com/forum.p ... id=1122&fromuid=559
(出处: 国芯论坛-STC全球32位8051爱好者互助交流社区)
另外, 我是通过 STC8H实物板子来仿真的, 换过好几块板子, 结果一样, 无法从ROM中, 将数据拷贝到XRAM中.
官方的示范程序, STC8H系列-增强型双数据指针示例代码2-ASM
运行后, 应该将 CODE中内容拷贝到 XRAM中才是, 实际运行结果是, 拷贝全FF 到 XRAM中.
在学习改写 Keil 字符串操作函数库(原型在 STRING.H 中)过程中, 发现原库 memmove 程序, 有一个 bug, 在将 code (或 xdata) 中内容 拷贝到 xdata中, 正向移动没问题, 反向移动时, 没有保护 指针返回的高位地址, 引起返回指针错误.
另外, 在将 code 中内容 拷贝到 xdata中, 程序中对移动地址作了判断, 决定采用正向移动还是反向移动, Keil 这段程序是多余的, 完全没必要, 因为51的CODE 和 XDATA 地址空间, 永远不会重叠, 这判断及反向移动, 我给优化了, 以精简代码提升执行速度.
MOVE_CODE_XDATA:
/* SETB C // Keil 这段程序是多余的, 因为C51的CODE和XDATA地址空间, 永远不会重叠
MOV A,R1
SUBB A,R0
MOV A,R2
SUBB A,R4
JNC MOVE_013
MOV A,R1
ADD A,R7
MOV DPL,A
MOV A,R2
ADDC A,R3
MOV DPH,A
MOV A,R0
ADD A,R7
MOV R0,A
MOV A,R4
ADDC A,R3
XCH A,R4 // Keil的BUG, 反向传送时, s1指针高位地址未保护, 现已修正
MOV R2,A // R4 -->R2
MOVE_010: INC DPL
DJNZ DPL,MOVE_011
DEC DPH
MOVE_011: DEC DPL
CLR A
MOVC A,@A+DPTR
XCH A,R0
XCH A,DPL
XCH A,R0
XCH A,R4
XCH A,DPH
XCH A,R4
INC DPL
DJNZ DPL,MOVE_012
DEC DPH
MOVE_012: DEC DPL
MOVX @DPTR,A
XCH A,R0
XCH A,DPL
XCH A,R0
XCH A,R4
XCH A,DPH
XCH A,R4
DJNZ R7,MOVE_010
DJNZ R6,MOVE_010
SJMP MOVE_END3 */
MOVE_013: MOV DPL,R1
MOV DPH,R2
MOV A,R4
MOV R2,A
MOVE_014: CLR A
MOVC A,@A+DPTR
........
下面为修正后的 memmove 程序, 可挂在 c51项目中编译, 以替代有错误的 memmove 库程序.
上面的代码，应该是KEIL C51的通病，对指针的支持很差。一定要使用基于存储器的指针，才能得到较为精炼的代码。 经过多次更改程序(使用 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口仿真的, 能够正常退出. 参考王珢的帖子，做WAV播放器，DPTR0 写到XRAM , DPTR1 从XRAM中读。工作正常。 社区闲人 发表于 2023-3-10 10:17
参考王珢的帖子，做WAV播放器，DPTR0 写到XRAM , DPTR1 从XRAM中读。工作正常。
DPTR0 / DPTR1 读写 XRAM 。确实没问题, 工作正常。
但是,一但打开双模式, 那怕最简单的自动切换模式, 哪怕用 DPTR0 读 CODE,DPTR1 写 XRAM 。就出错.
唯一正确的, 是全程关闭 双 DPTR模式, 只用最原始的DPTR0 读 CODE, 结果才是正确的!!!
STC8H8K64U的双数据指针用汇编语言操作，可以将功能全部发挥出来
===C语言暂时KEIL C51支持不了，就不要管了，
===STC8H同频的速度是普通8051的13.2倍以上，还有DMA、MDU16来减轻CPU压力，估计快20倍以上
===主频能到45MHz, 不是传统的12MHz/24MHz
一，STC8H8K64U不用仿真功能，直接裸机运行时
1, 对 XRAM 读出/写入, STC8H8K64U的 双DPTR指针, 完全正确, 工作正常.
2, 对程序区的 CODE 读出, STC8H8K64U的 双DPTR指针, 完全正确, 工作正常.
二，STC8H8K64U用仿真功能时
1, 对 XRAM 读出/写入, STC8H8K64U的 双DPTR指针, 完全正确, 工作正常.
2, 对程序区的 CODE 读出, STC8H8K64U的双 DPTR指针, 访问code程序区
===第一指针 DPTR0 支持对 CODE 读出, 完全正确, 工作正常.
===第二指针 DPTR1 不支持对 CODE 读出，仿真系统没考量到这，请仿真时注意，后续会改进 本帖最后由 熊仔 于 2023-9-3 08:51 编辑
LAOXU 发表于 2023-3-5 06:32
在学习改写 Keil 字符串操作函数库(原型在 STRING.H 中)过程中, 发现原库 memmove 程序, 有一个 bug, 在将...
正向移动和 反向移动是判断用户的代码
下面的例子能说明。
char xdata buf1 [] = "123456789";
memmove(buf1,&buf1, 5);//向左 正向移动
memmove(&buf1,buf1, 5);//向右 反向移动
memmove函数主要是考虑是否有覆盖区的移动，才有正向和反向移动算法
如果没有不考虑覆盖，直接用memcpy就行，正向移动算法。
反向移动测试返回指针对的。buf1开始分配地址是0x1234。移动后返回地址0x1236