- 2023-03-18
-
回复了主题帖:
大家帮忙分析一下: 这是怎么回事???
同样的程序, 在 stc8h 上测试, 工作正常.
测试结果: _nop_(); 一个都不加, 测试结果 time1 = 1
加一个 _nop_(); 测试结果 time1 =2
加二个 _nop_(); 测试结果 time1 = 3
加三个 _nop_(); 测试结果 time1 = 4
加四个 _nop_(); 测试结果 time1 = 5
-
发表了主题帖:
大家帮忙分析一下: 这是怎么回事???
很简单的测试程序, 没有任何中断, 仅测试指令执行时间.
上例中: _nop_(); 一个都不加, 测试结果 time1 = 1
加一个 _nop_(); 测试结果 time1 = 9 (异常!!!)
加二个 _nop_(); 测试结果 time1 = 10
加三个 _nop_(); 测试结果 time1 = 11
加四个 _nop_(); 测试结果 time1 = 12
.......
芯片型号是 STC32G, 在仿真时, 是全速执行的.
- 2023-03-10
-
回复了主题帖:
请问STC, 这官方示范程序, 你们测试过吗???
言归正传!!!
经过多次更改程序(使用 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口仿真的, 能够正常退出.
-
回复了主题帖:
笑死,STC8H的双DPTR仿真问题折腾三天,绝望的发帖前30秒解决……
经过多次更改程序(使用 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口仿真的, 能够正常退出.
- 2023-03-05
-
回复了主题帖:
请问STC, 这官方示范程序, 你们测试过吗???
huo_hu 发表于 2023-3-5 11:10
库本身不和实际结合就不好优化,比如如果是串口发送字符串,提出字符串数据直接送串口就行了,根本不用往 ...
内部函数库, 每个库都是独立的, 通过 约定寄存器或者 RAM传递 输入/输出参数.
-
回复了主题帖:
请问STC, 这官方示范程序, 你们测试过吗???
huo_hu 发表于 2023-3-5 11:04
太细节的东西不仿真有困难
正解
-
回复了主题帖:
请问STC, 这官方示范程序, 你们测试过吗???
在学习改写 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 库程序.
- 2023-03-04
-
回复了主题帖:
请问STC, 这官方示范程序, 你们测试过吗???
APT32F102X系列使用手册
APT32F1023B数据手册 V1.0
-
回复了主题帖:
请问STC, 这官方示范程序, 你们测试过吗???
据说 APT32F1023B 24MHz 12位ADC 0.85元/PCS
- 2023-03-03
-
回复了主题帖:
请问STC, 这官方示范程序, 你们测试过吗???
huo_hu 发表于 2023-3-3 13:42
如果要搬运数据从ROM到XRAM我就用分页256字节的方式,不用倒腾DPTR
最低 256字节 xram 可以, 超范围就行不通了.
-
回复了主题帖:
请问STC, 这官方示范程序, 你们测试过吗???
huo_hu 发表于 2023-3-3 13:34
以前也试过双指针,是根据例程改的,结果未能如预期,到底什么原因不太好追踪,主要是仿真程序在里面掺和着 ...
改写 Keil 字符串操作函数库(原型在 STRING.H 中), 优化精简代码, 提升执行速度.
所以要用到 双指针.
-
回复了主题帖:
请问STC, 这官方示范程序, 你们测试过吗???
吾妻思萌 发表于 2023-3-3 06:41
会不会刚好碰见坏料了?
代码看着没问题啊
换了好几块板子, 故障依旧, 跑其他程序工作正常.
-
回复了主题帖:
请问STC, 这官方示范程序, 你们测试过吗???
lugl4313820 发表于 2023-3-2 21:36
现在玩8位单片机,可能也是情怀了吧。大厂都转32位了。
确实是情怀, 仅玩一下其基本数据库函数.
- 2023-03-02
-
发表了主题帖:
请问STC, 这官方示范程序, 你们测试过吗???
本帖最后由 xuyiyi 于 2023-3-3 12:45 编辑
从STC-ISP中下载的示范程序, STC8H系列-增强型双数据指针示例代码2-ASM
直接下载编译, 测试芯片为 STC8H8K64U
测试结果显示, 根本无法从ROM中拷贝数据到XRAM中!
- 2023-02-25
-
回复了主题帖:
笑死,STC8H的双DPTR仿真问题折腾三天,绝望的发帖前30秒解决……
yubinwu 发表于 2023-2-25 11:15
最笑死的居然叛变到STC
STC号称死太惨
正确的道路应该是从STC叛变到别的
中颖51, 自疫情的几年中, 一直买不到芯片, 现在也不正常, 搞不到芯片, 没办法~~~
-
回复了主题帖:
笑死,STC8H的双DPTR仿真问题折腾三天,绝望的发帖前30秒解决……
后记:
我随意设断点, 单步或连续跟踪调试,发现该软件模拟传输测试程序不稳定, 时好时坏(查看数组, 传输的结果错误), 经不断更改断点位置, 单步或连续跟踪.
得出以下结论:
STC8H的仿真, 不支持第二个DPTR指针, 无论是单步, 还是连续, 只要在使用第二个DPTR指针过程中有停留(停顿), 就会出错, 永远停止第二个DPTR指针的工作!!!
像前面我调试 函数strcmp,strncmp,strcpy,strncpy,memcmp,memcpy,memccpy,memmove,就是在 双DPTR指针应用中, 加了断点, 造成STC8H的仿真过程中,
在第二个DPTR指针执行过程中有了停顿, 而产生第二个DPTR指针不工作的结果!
-
发表了主题帖:
笑死,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的仿真及软件是有问题的?
- 2023-02-24
-
回复了主题帖:
执行代码超级短的 STC系列专用 初始化IO口函数 宏定义!!!
本帖最后由 xuyiyi 于 2023-2-24 19:19 编辑
damiaa 发表于 2023-2-20 09:51 我指的是编程风格。
那是老姚向STM32编程风格看齐。
我个人是反对的, 比如 51向STM8(STM32)编程风格看齐。
STM8是什么指令集? 继承扩展了原6502(6800)指令集, 6502指令集侧重于间接寻址, 原6502指令集间接寻址功能已经比 51强大太多了, 加上STM8扩充了6502(6800)指令集,
使用结构体指针, 如鱼得水. 对比之下, 使得原本就是 鸡肋的 51片外DPTR指针寻扯, 更放不上台面.
- 2023-02-19
-
回复了主题帖:
执行代码超级短的 STC系列专用 初始化IO口函数 宏定义!!!
楼上库已更新 !!!
- 2023-02-18
-
回复了主题帖:
为什么ARM CONTEX-M0 M0+ 性能这么好,可以凭它赚大钱,而ARM公司却几乎是免费授权用
前几年看过一篇贴子, 好像 这种低挡的 M0, 核算下来 授权费 0.1元人民币/片, 现在估\计 几分钱/片.
听老妖吹, 其 STC33(M4核), 是买断的,
因此, 可能 ARM 公司的 版权 分 2种, 一种是一次性买断某个内核, 人民币 N万元.
另一种是每生产一片支付 版权费 几分到几元人民币(视挡次) , 也可能有上限, 生产的最多支付的 版权费 越低. 生产到一定量后(前面ARM公司已收了N多版权费了), 可能不再收取此种核的 版权费