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

杨***

社区闲人 发表于 2024-4-5 13:34
如果仅仅停掉CPU的时钟，还保留IO时钟，这样串口接收数据就不会受到影响。----very good!!!
而如果在停掉CP ...

我对LAOXU的语文理解好像又出问题了：

事实是
（1）STC8H上的MDU16在执行乘法指令（ ARCON = 4 << 5;  ）的时候，
        CPU并没有停止时钟，继续执行下一条指令；

（2）现在STC32G上的MDU32在执行乘除法指令（ MOV  DMAIR, #N  ）的时候，
        CPU停止时钟指令，直到运算完成后继续执行下一条指令；

那么LAOXU到底是想要 新的按草案2设计的DPU351 在进行乘除法计算时，
CPU的时钟像MDU16一样的不停止？还是像MDU32那样的停止？

我现在被他几个帖子给绕糊涂了，你帮分析下，按你的阅读，到底LAOXU是要哪一种？

杨***

lijun4545 发表于 2024-4-5 16:08
正常情况下，CPU应该等待DPU运算结束后再运行，但中断也可以单独配个时钟，发现中断立即启动CPU时钟，中断 ...

这不可靠，比如：

（1）当进入中断时，DPU运算还未结束，中断现场保存程序就
        把作为运算操作数的DR0/DR4（EAX/EBX）保存到系统堆栈里了，
（2）然后中断处理ISR正在进行的时候，假如DPU运算结束了，
        就会立即把ISR运行中的DR0/DR4给覆盖掉了
      （这就是姚总说的“硬件重入了”），
        DR0/DR4这时变成了DPU的运算结果，你猜中断服务程序ISR还会正确地运行下去吗？
        大概率是不会，系统不崩溃就万幸了。
（3）然后当中断完成返回时，中断现场恢复程序就从系统堆栈里
        把原来作为运算操作数（而不是运算结果）保存的DR0/DR4（EAX/EBX）给恢复出来，
        由于运算实际已经完成了，而DR0/DR4再也不会是运算的结果，
        你猜被中断的程序下面会正常运行吗？

社区***

我认为是这样：
如果CPU不停止工作，对中断响应的实时性就有保证。
但这样MCU设计的难度大，且兼容性不好。
退而求其次，MDU32在运算时让CPU停止工作时，
能保证串口通信在115200波特率正常工作，就很好了。
对中断的些许延时响应可以容忍。

神***

多个各种中断在 DPU351传输数据和运行期间产生，会用哪些资源 ？
===会用到哪些共同的资源，会产生冲突吗
       肯定会啊，十万用户十万兵，各有风格啊


DPU351作为指令来处理就简单了，DPU351执行指令，
CPU32就等 DPU351 执行完 DPU351 当前的指令就行了
DPU351和STC32传输数据是 DMA 传输的

===这个暂时是最优解法，其他的建议，
       我暂时看到的都是考虑不周

神***

社区闲人 发表于 2024-4-5 17:01
我认为是这样：
如果CPU不停止工作，对中断响应的实时性就有保证。但这样MCU设计的难度大，且兼容性不好。
...

CPU执行当前指令时，是无法立即实时响应中断的，
DPU351 没有降低 CPU 的实时响应中断的实时性

DPU351的扩展指令如放在CPU中运行就是这个效果
===当前指令执行完才会去响应下一条指令

杨***

lijun4545 发表于 2024-4-5 16:08
正常情况下，CPU应该等待DPU运算结束后再运行，但中断也可以单独配个时钟，发现中断立即启动CPU时钟，中断 ...

（1）“正常情况下，CPU应该等待DPU运算结束后再运行”。你这句话很对。
（2）“为什么要设计成硬件重入？我觉得不合理。DPU竟然能影响中断，这不合理”。
          你这句话也很对。
（3）现在的STC32G上的MDU32已经是CPU应该等待DPU运算结束后再运行，可是LAOXU不满意，
         是LAOXU想要把未来的DPU351设计成为进行运算时CPU不停机，
         这样就会产生硬件重入，DPU就会影响到可能的中断服务程序和中断服务过程中用到的单元，
         所以LAOXU这个要求不合理！

LA***

草案1 我提了建议(没人回复), 话题有重复多次.
现听从了 tzz1983 意见.
草案2 我仅提了 R12-R15 被 C251循环语句(WHILE,FOR)占用, 不能使用的问题.
其余我不参与了.
结果 XX 又跳出来, 指名要我参与, 好的, 我正式给出我的建议.

草案2 中, 51的 EAX-EBX /ECX-EDX , 分别指定 2组 R0-R7 寄存器,
其本质依然是只使用 1组 R0-R7 寄存器,
另一组还是使用 RAM 内存(和草案1相同).
反而增加了复杂性(寄存器切换指定), 没有草案1 简洁.

在 草案1 中, 我提了在 DPU32 中, 增加 EAX'/EBX'/ECX'/EDX' 映像寄存器 的概念.

本人方案:
在 DPU32 中, 增加 EAX'/EBX'/ECX'/EDX' 映像寄存器.
C251 状态下 DPU32 执行动作:
1. 读入 CPU 的 EAX/EBX/ECX/EDX 寄存器
2. 执行 DPU32 动作
3. 结果写入 DPU32  EAX'/EBX'/ECX'/EDX' 映像寄存器.
4. 由 CPU 读入 最终结果

C51 状态下 DPU32 执行动作:
1. CPU 预装 ECX/EDX 内容到 ECX'/EDX' 映像寄存器(按需要执行).
1. 读入 CPU 的 EAX/EBX 和 ECX'/EDX' 寄存器
2. 执行 DPU32 动作
3. 结果写入 DPU32  EAX'/EBX'/ECX'/EDX' 映像寄存器.
4. 由 CPU 读入 最终结果
由于输出都是暂存 DPU32  EAX'/EBX'/ECX'/EDX' 映像寄存器中. 不存在硬件重入问题.

针对我的方案, 欢迎大家指出可能存在的缺点和错误, 欢迎拍砖!
至于老姚最终选啥方案, 那是老姚的事.

LA***

这里, 我纠正一下说法, 我上面指的挑刺, 是指 欢迎大家找出 我程序中可能 存在的缺点和错误.
找到了肯定要修正, 而不是指我编写的 程序 毫无缺点(连 KEIL 都做不到, 里面都能找到 BUG).

本人非专业程序员(只是爱好).
以前工作的角色是 "百得胶", "救火队员" , 无论机械设计, 工艺流程, 光电,
化工 .....  还是 动手能力, 车铣刨钳, 电子装配 ......
强电弱电(硬件设计, 软件, PLC.... ) , 反正找不到人干的事都论到我干.

学的多学的杂, 结果每样都不精, 只不过略懂一点而已.  

现在退休了, 来 STC论坛找点乐子, 总比整天 上X音, 打牌 有意义的多吧.

LA***

这次正好出差，当救火队，去接了一个"烂尾楼"项目.

XX老师 接了 Y公司的一个项目, 仿制 Z公司生产线上的一台专用进口设备.

结果, 做了几年(前面好说,疫情), 现在, XX老师 也没信心了(找不到合适人员编程).

仿制设备 被厂方拉回, 我看了, 粗看一下, 硬件基本齐全.

仔细分析, 问题多多, 其机械精度达不到厂方要求, 考虑了好几天.

给出解决方案:
1. 先花几千元, 局部修改部分关键细节上的机械精度问题, 如能达标过关, 那最好.
2. 如不行, 则需花几万, 更换伺服传动部分, 以提高机械精度.
3. 电气方面, 由于是国外 20年前的产品, 关键某些部件已买不到了, 要找到最佳的替代品.
4. 对方能用的电气部分尽量利用起来, 修改不适当地方, 补全硬件.
5. 最后 PLC编程, 包括厚度动态检测(0.001mm精度), 宽度摄像头动态检测(0.1mm精度),
伺服曲线跟踪, 双刀头滚切连动, 放料, 收料 张力控制, HMI 显示....

总之, 价值上百万的设备, 不会太简单的, 要花我几个月时间.

这段时间上网时间会少很多, 回复不及时, 请见谅.

神***

老许 最近忙，在出差，干系统技术的国产替代应用大项目
===都是在忙独立自主，不受外国控制的事
老许 参加 杨教授主导的 高峰论谈，
增加了本坛 国产32位8051 巅峰论坛 的技术含金量 ！

两位大侠的高峰对话，无疑再次证明
本坛在为科技强国独立自主而砥砺前行中 ！

STC351 / RISC-V / ARM 必将三分天下
STC 一定实战每个分场，为科技强国而努力奋斗

发展 STC351, 是大势所趋，x51 MCU 的未来
是 DSP/DPU351 + TFPU + STC 32位8051
===STC的强项 是 高稳定 / 高抗干扰，全球领先的 ISP 技术

三人行必有我师，大侠们高峰论谈，
风声到处，就是华夏的宣言
STC351 = DSP/DPU351 + TFPU + STC 32位8051