GD芯片带多路步进电机工作不正常，请高手们指点一下

只看该作者 · 2022-4-15 21:19

楼主方便发下代码吗，我用示波器看下波形

只看该作者 · 2022-4-16 10:31

gdszzyq 发表于 2022-4-15 16:48
试过用一个定时器输出4路PWM，也一样出这样，PWM的周期最短才100微妙，就算是7路电机同时抢中断也就差别 ...

一个定时器都有问题，而且程序是从STM那边移植过来的，说明程序主体是没有问题的，芯片的区别无非就是主频，还有就是下面一位网友说的GD32低速Flash区了，还有最值得怀疑的就是芯片的抗干扰性能，实在不行的话换沁恒的CH32F103看看，感觉这个跟STM32更接近些。先试试看吧，库函数一样。

只看该作者 · 2022-4-16 10:39

再不行，就换终极BOSS，APM32F103，换后假如还不行，就是你程序的问题，不要问为什么，这里是GD板块。

只看该作者 · 2022-4-16 14:05

onebank 发表于 2022-4-15 17:20
我觉得可以从以下三个方面检查下：
1、你说的加速过程问题，可以把加速时间拉长看看会不会丢步；
2、电源 ...

加速时间加长等忙完测试一下，我是用驱动器带电机的，用一个环形变压器给驱动器供电，一个12伏开关电源给控制板供电，供电是没问题的。现在只保留了电机测试代码及按钮扫描代码，只有在掉电中断里才有FLASH操作，平常是不可能进去的

只看该作者 · 2022-4-16 14:08

13226636021 发表于 2022-4-15 18:05
是不是用的FLASH超出了GD的高速FLASH区，如果代码在低速FLASH区跑算法这些肯定不行的，GD的低速区没什么用 ...

如果真是这样真有可能出现我的那种情况，但我的代码包含数组才才20多K，应该不会跑到低速FLASH吧，而且只有3路以上电机同时运转时才会出现丢步，单独运行都没问题

只看该作者 · 2022-4-16 14:09

lifeforrent 发表于 2022-4-15 21:19
楼主方便发下代码吗，我用示波器看下波形

好的，谢谢你！

只看该作者 · 2022-4-16 14:11

本帖最后由 gdszzyq 于 2022-4-16 14:25 编辑

xdqfc 发表于 2022-4-16 10:31
一个定时器都有问题，而且程序是从STM那边移植过来的，说明程序主体是没有问题的，芯片的区别无非就是主 ...

干扰问题倒从来没遇到过，难道电机运转时干扰了MCU？干扰的现象是什么？程序跑飞还是自动复位？我这只是个别电机丢步，不是所有电机一起丢步

只看该作者 · 2022-4-16 14:14

非常感谢大家的热心帮助，下面我把ST和GD的工程都发上来请大家分析下
端口配置以下：
按键扫描：PCin(14)
1号电机PWM：PDout(10)
2号电机PWM：PDout(8)
3号电机PWM：PBout(14)
4号电机PWM：PBout(12)
5号电机PWM：PEout(14)

只看该作者 · 2022-4-16 14:15

本帖最后由 gdszzyq 于 2022-4-16 14:19 编辑

GD工程，这个工程用了2个定时器输出PWM信号，GD的定时器编号与ST的不同，是从0开始的，包括串口及ADC编号都不一样，GD的库函数就是折腾人的，各种绕，连个外设的基地址都算来算去的

只看该作者 · 2022-4-18 11:03

你这样试一下，先测试哪个电机丢步，然后在对应的通道中断中计数，看看进了多少次中断，每个通道希望输出多少脉冲肯定是给定的吧，然后对比一下，确定下是不是进中断次数不够引起的丢步

只看该作者 · 2022-4-18 11:15

TIMER时钟你选择的是108M，程序中基本上TIMER计数1~400次就会进一次中断，这个时间可能来不及处理中断服务函数

只看该作者 · 2022-4-18 13:54

lifeforrent 发表于 2022-4-18 11:15
TIMER时钟你选择的是108M，程序中基本上TIMER计数1~400次就会进一次中断，这个时间可能来不及处理中断服务 ...

中断里本来就有对脉冲计数，程序设定出700个脉冲，MCU也输出了700个脉冲，但电机转的角度却没有转700步，也就是产生了堵转了。
我选择的系统时钟是72M，产生PWM信号的定时器采用的是1M时钟，最多也是50微妙进入一次中断，处理中断函数不到1微妙，就算7路同时产生中断请求，最多也就误差几个微妙而已，对电机运转影响不大。

只看该作者 · 2022-4-18 14:05

今天测试了把加速周期由1毫秒改为2毫秒，还是一样会丢步。

只看该作者 · 2022-4-18 14:48

Second_Motor_Speed_Down_Step这个数组的值太小了，每个后面加个0看看

只看该作者 · 2022-4-18 15:27

一个定时器带一个通道的电机，不要全带，两个定时器就带两路电机看看。极度怀疑是中断引起的。

只看该作者 · 2022-4-18 15:33

本帖最后由 xdqfc 于 2022-4-18 15:36 编辑

主程序假如时间够用的话，就到主程序去查询各个中断标志算了，不要弄各定时器中断。我感觉好像漏掉一些中断了。一个定时器就安排几个中断请求，时间又没有错开，感觉很不保险，之前就吃过这亏。

只看该作者 · 2022-4-18 15:53

lifeforrent 发表于 2022-4-18 14:48
Second_Motor_Speed_Down_Step这个数组的值太小了，每个后面加个0看看

你说的是数组太小吗？就70个数据要那么大干嘛？

只看该作者 · 2022-4-18 15:55

xdqfc 发表于 2022-4-18 15:27
一个定时器带一个通道的电机，不要全带，两个定时器就带两路电机看看。极度怀疑是中断引起的。
...

我也是怀疑是中断引起的，但ST的都带过7个电机都没事。1个定时器带1路电机那有那么多定时器

只看该作者 · 2022-4-18 16:06

本帖最后由 gdszzyq 于 2022-4-18 16:19 编辑

xdqfc 发表于 2022-4-18 15:33
主程序假如时间够用的话，就到主程序去查询各个中断标志算了，不要弄各定时器中断。我感觉好像漏掉一些中断 ...

主程序查询中断标志肯定来不及的，几路一起产生中断请求的概率非常低，就算出现了7路一起产生中断请求，对于我这种应用来说应该没什么影响的，处理一个中断请求才零点几微秒，对于50微秒来说可以忽略了。除非是GD的芯片会丢失中断请求，比如定时器1当前在处理CH1的中断函数时定时器1的CH2有新的中断请求，这时会不会丢弃CH2的中断请求，如果会那就会丢步了。

只看该作者 · 2022-4-18 22:12

你这个函数明显是错的啊，，，你使能的是CCX通道，，极性却是配置CCXN通道的，，，
把这句
timer_ocintpara.ocnpolarity = TIMER_OCN_POLARITY_HIGH; //输出极性
换为
timer_ocintpara.ocpolarity = TIMER_OC_POLARITY_HIGH; //输出极性

否则你的通道都对应不了

GD芯片带多路步进电机工作不正常，请高手们指点一下

技术新星奖章