讨论稿，向【64位超算中心】前进 ! DSP/DPU351 + TFPU, DPU32@全新32位8051

Debu***

杨为民 发表于 2024-4-13 15:07
大仙路过，观棋不语真君子！

神仙打架又看了一遍，个人觉得在TFPU/DPU/DSP运算期间CPU继续执行指令如果存在硬件重入的问题，保护现场和恢复现场也是需要CPU来完成的，受制程和架构的限制，CPU时钟本来就做不快，保护现场和恢复现场会耽误更多的时间（CPU时钟），得不偿失，那么只能让CPU等待TFPU/DPU/DSP运算结束，可以用PLL输出一个几百兆的时钟给TFPU/DPU/DSP用，争取绝大多数TFPU/DPU/DSP运算在一个CPU时钟内完成，同时这个时钟可以在一定范围内变化，分频后输出给HSPWM和I2S等需要特殊频率和高速时钟的外设

杨***

DebugLab 发表于 2024-4-13 23:09
神仙打架又看了一遍，个人觉得在TFPU/DPU/DSP运算期间CPU继续执行指令如果存在硬件重入的问题，保护现场 ...

请大神不要在乎我下面说话的语气，我不是生你的气，我实在是生LAOXU的气。



哥们，你的看法和建议都很正确，不过STC在STC32G单片机上早就这样做了，并且已经写在芯片手册里了。


同时姚总多次在帖子里以各种方式告诉大家CPU的主频和DPU的主频是分开的：

这些STC早就做到、已经做得正确的事情，姚总在帖子里已经两次明确地回复了LAOXU。
然而在此情况下，LAOXU像着了魔，仍然忽悠着你们要不停地讨论“TFPU/DPU/DSP运算期间CPU继续执行指令”这个问题，
我使用“跟风车打架”来形容他的行为已经是很文雅了。


最令我不耻的是LAOXU 是“不怀好意”的挑唆。
大家请看，对于他推崇的“执行运算时不停止CPU”的MDU16，他自己写的库函数如下：
?PR?_UIDIV?UIDIV SEGMENT CODE         
PUBLIC ?C?UIDIV
RSEG  ?PR?_UIDIV?UIDIV
?C?UIDIV:
                        CLR_EA
                        MOV      DPTR, #MD1
                        LD_MD    R6, +1
                        LD_MD    R7, +1
                        LD_MD    R4, +1
                        LD_MD    R5, +1
//                        MOV      DPTR,#ARCON
                        LD_MD         #0xA0, +1                           // 16位/16位除法(clock:9)
                        WAIT
                        MOV         DPTR, #MD1
                        ST_MD    R6, +1
                        ST_MD    R7, +1
                        ST_MD    R4, +1
                        ST_MD    R5,  0
                        SETB_EA
                        RET


其中又是关闭总中断，又是用“WAIT”的死循环等待MDU16运算的完成：
WAIT                    MACRO
                        MOV      A,#0x01
                        MOVX     @DPTR,A
                        MOVX     A,@DPTR
                        JB       ACC.0,$-1
                                 ENDM  

这说明LAOXU他当然知道在“执行运算时不停止CPU”所要付出的代价，而且知道的一清二楚，否则不会写出避免你说的“硬件重入的问题”的正确措施：“关闭总中断”的语句！


同时在他为的STC32G单片机上采用了他提倡废除的“执行运算时停止CPU”工作模式的 MDU32模块所写的库函数：
        ?PR?ULDIV?ULDIV   SEGMENT  CODE         
PUBLIC        ?C?ULDIV
PUBLIC        ?C?ULIDIV
        RSEG       ?PR?ULDIV?ULDIV
?C?ULIDIV     PROC         NEAR
                                XRL      WR0,WR0               
?C?ULDIV :
                                MOV      DMAIR,#0x04  // 32位无符号除法
                                RET
总共3行汇编指令（其中“XRL      WR0,WR0”这条指令还是错的，根本不该有这条指令），
通过他这个亲自编写得库函数，说明LAOXU他当然知道在“执行运算时停止CPU”的优点：既无需关闭总中断，又无需用软件死循环等！


既然LAOXU很清楚这两种情况的效果，为什么却忽悠你们不停地向STC提出人家早已采用的技术路线的建议，要求STC放弃已经做好的成功的MDU32的技术路线，回到MDU16的工作模式？


这是什么意思？我猜他是想用你们的“中招的笨”，来衬托他自己的“下套的聪明”! 自己躲在后面偷偷地乐

xiang***

DebugLab 发表于 2024-4-13 23:09
神仙打架又看了一遍，个人觉得在TFPU/DPU/DSP运算期间CPU继续执行指令如果存在硬件重入的问题，保护现场 ...

本人做应用的,对于芯片内部的各种调度理解得并不透彻,但感官上认可你的说法,说的极端一点,
如果这一堆 TFPU/DPU/DSP 运算期间,CPU不停下来,恰好外面来了几个要处理的东西,那cpu的保护恢复工作会非常繁重.
至于时钟给各种外设的做法,如果可行,那就更加简单了.
新的cpu频率非常高了,让cpu停下来的时间相对而言也就足够短了.完全没有必要让cpu去调度一堆东西而浪费更多的时间.

其实速度还真的可以改变好多,当年STC和AVR同样的频率,好多时候STC确实处于下风,可频率提升之后,根本不在一个水平线了.

所以我感觉,确实没有必要让cpu响应中断啥的.

这玩意儿搞起来就是芝麻西瓜的事,得不偿失哦..毕竟都108M了,真的没必要,没必要啊..

LA***

tzz1983 发表于 2024-4-12 11:21
亲, 你没明白, 发个图给你看就明白了, 说外置的FLASH是不用停CPU的

明白你的意思, 这是 IAP/FLASH 公用的通病.

我前面的例子, 不适合于大量数据, 以一页以内的数据为例, 占用 2页, 通过初始化时 清 IAP/FLASH (6毫秒), 断电时再统一保存数据, 有效避开程序运行时 IAP/FLASH (6毫秒) 擦除,

LA***

对 xx 自以为是 , 断章取义 的责问, 已不想回答.

LA***

DebugLab 发表于 2024-4-13 23:09
神仙打架又看了一遍，个人觉得在TFPU/DPU/DSP运算期间CPU继续执行指令如果存在硬件重入的问题，保护现场 ...

同意你的观点!
要做到 不 保护现场和恢复现场 , 必须满足 2个条件.
参数传递 入口: 必须放在 cpu 受中断保护的 寄存器中(例如 r0-r7), 不能放在其他 ram 中.
参数回传 出口: 必须放在 TFPU/DPU/DSP 中, 供 cpu需要时读取.
你可看一下前面我写的方案 2, 有什么疑问, 欢迎技术讨论.

LA***

原以为受技术限制, DMAIR 寄存器写入指令码，只能使用立即数寻址方式的指令“MOV DMAIR,#N”，

现在看来不存在这个问题.

那就有一个问题值得思考.
DPU32, 状态寄存器 和 控制寄存器, 地址的连续性问题.
在 C251 环境下, 因能执行写 16位数据, 地址是否连续性 ,
决定了是否能用一条指令写16位数据,
完全代替原先只能用2条指令写8位数据
(非原子操作带来的函数不可重入问题, 在软件上, 一般用短暂关中断解决, 但需额外增加多条指令).
如把 MDU32C, 状态寄存器 和 控制寄存器, 地址连在一起(注意偶地址在先),
则以一条16位数据写指令(原子操作), 装载和触发 状态寄存器 和 控制寄存器,
此时的函数是可重入的, 在软件上, 不用关中断, 不会额外增加多条指令.

注: 在 纯 51 环境下, 因指令只能执行写 8位数据, 与地址是否连续性无关.