1，42步进电机出三线怎么接线
42步进电机出三线接线方法是：1、将步进电机驱动器脉冲输入信号和方向输入信号的正极连接到表控的5v端子。2、将步进电机驱动器脉冲输入信号的负端连接到表控的y1输出端子上。3、将步进电机驱动器方向输入信号的负端连接到表控的y2输出端子上。4、接下来就是设置步进电机驱动器的细分，一般可以放在8（1600）左右，通过初步调试后设置实际需要的细分。5、设置步进电机的正转设置，参考设置，一行实现正转。x1是正转的启动开关。6、步进电机反转的设置：x2是反向启动开关，y1输出脉冲，y2输出方向信号。两行实现反转动作。所谓的42步进电机就是指的安装机座尺寸是42mm的电机,其最大输出力矩是0.5nm;57电机是指安装机座尺寸是57mm的电机,其最大输出力矩是3.0nm。
2，42步进电机怎么驱动
42步进电机可以选择控制控制型驱动器如ndm432，需要控制器发送控制脉冲频率，可以接收5~24v的差分控制信号，安装尺寸：86*56.5*20.5mm，工作电压：12~40vdc；在有些应用领域，需要自带控制脉冲发生器的驱动器ndc552，通过io口实现电机的控制。如果是接驳台应用领域可以常用ndc456d，可以控制2路42电机同步运行。用户通过io控制信号实现电机的正反转和启停动作，速度可以通过电位器调速。也有些领域可以选择控制驱动一体产品，人单轨接驳控制台，需要2轴42步进电机进行同步传输，可以选择nps102ac接驳控制器，集成了电源、控制器和电机驱动器，可以接入位置开关，和控制开关信号和上下工位的smema控制信号，实现完整接驳控制，也可以多台结连，实现单轨长链接驳。
3，驱动如何调试
驱动程序开发的一个重大难点就是不易调试。本文目的就是介绍驱动开发中常用的几种直接和间接的调试手段，它们是：1、利用printk2、查看oop消息3、利用strace4、利用内核内置的hacking选项5、利用ioctl方法6、利用/proc 文件系统7、使用kgdb前两种如下：一、利用printk这是驱动开发中最朴实无华，同时也是最常用和有效的手段。scull驱动的main.c第338行如下，就是使用printk进行调试的例子，这样的例子相信大家在阅读驱动源码时随处可见。338 // printk(kern_alert wakeup by signal in process %d\n, current->pid);printk的功能与我们经常在应用程序中使用的printf是一样的，不同之处在于printk可以在打印字符串前面加上内核定义的宏，例如上面例子中的kern_alert（注意：宏与字符串之间没有逗号）。#define kern_emerg <0>#define kern_alert <1>#define kern_crit <2>#define kern_err <3>#define kern_warning <4>#define kern_notice <5>#define kern_info <6>#define kern_debug <7>#define default_console_loglevel 7这个宏是用来定义需要打印的字符串的级别。值越小，级别越高。内核中有个参数用来控制是否将printk打印的字符串输出到控制台（屏幕或者/sys/log/syslog日志文件）# cat /proc/sys/kernel/printk6 4 1 7第一个6表示级别高于（小于）6的消息才会被输出到控制台，第二个4表示如果调用printk时没有指定消息级别（宏）则消息的级别为4，第三个1表示接受的最高（最小）级别是1，第四个7表示系统启动时第一个6原来的初值是7。因此，如果你发现在控制台上看不到你程序中某些printk的输出，请使用echo 8 > /proc/sys/kernel/printk来解决。在复杂驱动的开发过程中，为了调试会在源码中加入成百上千的printk语句。而当调试完毕形成最终产品的时候必然会将这些printk语句删除想想驱动的使用者而不是开发者吧。记住：己所不欲，勿施于人），这个工作量是不小的。最要命的是，如果我们将调试用的printk语句删除后，用户又报告驱动有bug，所以我们又不得不手工将这些上千条的printk语句再重新加上。oh，my god，杀了我吧。所以，我们需要一种能方便地打开和关闭调试信息的手段。哪里能找到这种手段呢？哈哈，远在天边，近在眼前。看看scull驱动或者leds驱动的源代码吧！#define leds_debug#undef pdebug #ifdef leds_debug #ifdef __kernel__ #define pdebug(fmt, args…) printk( kern_emerg leds: fmt, ## args) #else #define pdebug(fmt, args…) fprintf(stderr, fmt, ## args) #endif#else #define pdebug(fmt, args…)#endif#undef pdebugg#define pdebugg(fmt, args…)这样一来，在开发驱动的过程中，如果想打印调试消息，我们就可以用pdebug(address of i_cdev is %p\n, inode->i_cdev);，如果不想看到该调试消息，就只需要简单的将pdebug改为pdebugg即可。而当我们调试完毕形成最终产品时，只需要简单地将第1行注释掉即可。上边那一段代码中的__kernel__是内核中定义的宏，当我们编译内核（包括模块）时，它会被定义。当然如果你不明白代码中的…和##是什么意思的话，就请认真查阅一下gcc关于预处理部分的资料吧！如果你实在太懒不愿意去查阅的话，那就充当vc工程师把上面的代码copy到你的代码中去吧。二、查看oop消息oop意为惊讶。当你的驱动有问题，内核不惊讶才怪：嘿！小子，你干吗乱来！好吧，就让我们来看看内核是如何惊讶的。根据faulty.c（单击下载）编译出faulty.ko，并 insmod faulty.ko。执行echo yang >/dev/faulty，结果内核就惊讶了。内核为什么会惊讶呢？因为faulty驱动的write函数执行了*(int *)0 = 0，向内存0地址写入，这是内核绝对不会容许的。52 ssize_t faulty_write (struct file *filp, const char __user *buf, size_t count,53 loff_t *pos)54 55 56 *(int *)0 = 0;57 return 0;58 }1 unable to handle kernel null pointer dereference at virtual address 000000002 pgd = c38940003 [00000000] *pgd=33830031, *pte=00000000, *ppte=000000004 internal error: oops: 817 [#1] preempt5 modules linked in: faulty scull6 cpu: 0 not tainted (2.6.22.6 #4)7 pc is at faulty_write+0×10/0×18 [faulty]8 lr is at vfs_write+0xc4/0×1489 pc : [] lr : [] psr: a000001310 sp : c3871f44 ip : c3871f54 fp : c3871f5011 r10: 4021765c r9 : c3870000 r8 : 0000000012 r7 : 00000004 r6 : c3871f78 r5 : 40016000 r4 : c38e516013 r3 : c3871f78 r2 : 00000004 r1 : 40016000 r0 : 0000000014 flags: nzcv irqs on fiqs on mode svc_32 segment user15 control: c000717f table: 33894000 dac: 0000001516 process sh (pid: 745, stack limit = 0xc3870258)17 stack: (0xc3871f44 to 0xc3872000)18 1f40: c3871f74 c3871f54 c0088eb8 bf00608c 00000004 c38e5180 c38e516019 1f60: c3871f78 00000000 c3871fa4 c3871f78 c0088ffc c0088e04 00000000 0000000020 1f80: 00000000 00000004 40016000 40215730 00000004 c002c0e4 00000000 c3871fa821 1fa0: c002bf40 c0088fc0 00000004 40016000 00000001 40016000 00000004 0000000022 1fc0: 00000004 40016000 40215730 00000004 00000001 00000000 4021765c 0000000023 1fe0: 00000000 bea60964 0000266c 401adb40 60000010 00000001 00000000 0000000024 backtrace:25 [] (faulty_write+0×0/0×18 [faulty]) from [] (vfs_write+0xc4/0×148)26 [] (vfs_write+0×0/0×148) from [] (sys_write+0x4c/0×74)27 r7:00000000 r6:c3871f78 r5:c38e5160 r4:c38e518028 [] (sys_write+0×0/0×74) from [] (ret_fast_syscall+0×0/0x2c)29 r8:c002c0e4 r7:00000004 r6:40215730 r5:40016000 r4:0000000430 code: e1a0c00d e92dd800 e24cb004 e3a00000 (e5800000)1行惊讶的原因，也就是报告出错的原因；2-4行是oop信息序号；5行是出错时内核已加载模块；6行是发生错误的cpu序号；7-15行是发生错误的位置，以及当时cpu各个寄存器的值，这最有利于我们找出问题所在地；16行是当前进程的名字及进程id17-23行是出错时，栈内的内容24-29行是栈回溯信息，可看出直到出错时的函数递进调用关系（确保config_frame_pointer被定义）30行是出错指令及其附近指令的机器码，出错指令本身在小括号中反汇编faulty.ko（ arm-linux-objdump -d faulty.ko > faulty.dis ；cat faulty.dis）可以看到如下的语句如下：0000007c : 7c: e1a0c00d mov ip, sp 80: e92dd800 stmdb sp!, 84: e24cb004 sub fp, ip, #4 ; 0×4 88: e3a00000 mov r0, #0 ; 0×0 8c: e5800000 str r0, [r0] 90: e89da800 ldmia sp, 定位出错位置以及获取相关信息的过程：9 pc : [] lr : [] psr: a000001325 [] (faulty_write+0×0/0×18 [faulty]) from [] (vfs_write+0xc4/0×148)26 [] (vfs_write+0×0/0×148) from [] (sys_write+0x4c/0×74)出错代码是faulty_write函数中的第5条指令（(0xbf00608c-0xbf00607c)/4+1=5），该函数的首地址是0xbf00607c，该函数总共6条指令（0×18），该函数是被0xc0088eb8的前一条指令调用的（即：函数返回地址是0xc0088eb8。这一点可以从出错时lr的值正好等于0xc0088eb8得到印证）。调用该函数的指令是vfs_write的第49条（0xc4/4=49）指令。达到出错处的函数调用流程是：write(用户空间的系统调用)–>sys_write–>vfs_write–>faulty_writeoop消息不仅让我定位了出错的地方，更让我惊喜的是，它让我知道了一些秘密：1、gcc中fp到底有何用处？2、为什么gcc编译任何函数的时候，总是要把3条看上去傻傻的指令放在整个函数的最开始？3、内核和gdb是如何知道函数调用栈顺序，并使用函数的名字而不是地址？ 4、我如何才能知道各个函数入栈的内容？哈哈，我渐渐喜欢上了让内核惊讶，那就再看一次内核惊讶吧。执行 cat /dev/faulty，内核又再一次惊讶！1 unable to handle kernel null pointer dereference at virtual address 0000000b2 pgd = c3a880003 [0000000b] *pgd=33a79031, *pte=00000000, *ppte=000000004 internal error: oops: 13 [#2] preempt5 modules linked in: faulty6 cpu: 0 not tainted (2.6.22.6 #4)7 pc is at vfs_read+0xe0/0×1408 lr is at 0xffffffff9 pc : [] lr : [] psr: 2000001310 sp : c38d9f54 ip : 0000001c fp : ffffffff11 r10: 00000001 r9 : c38d8000 r8 : 0000000012 r7 : 00000004 r6 : ffffffff r5 : ffffffff r4 : ffffffff13 r3 : ffffffff r2 : 00000000 r1 : c38d9f38 r0 : 0000000414 flags: nzcv irqs on fiqs on mode svc_32 segment user15 control: c000717f table: 33a88000 dac: 0000001516 process cat (pid: 767, stack limit = 0xc38d8258)17 stack: (0xc38d9f54 to 0xc38da000)18 9f40: 00002000 c3c105a0 c3c1058019 9f60: c38d9f78 00000000 c38d9fa4 c38d9f78 c0088f88 c0088bb4 00000000 0000000020 9f80: 00000000 00002000 bef07c80 00000003 00000003 c002c0e4 00000000 c38d9fa821 9fa0: c002bf40 c0088f4c 00002000 bef07c80 00000003 bef07c80 00002000 0000000022 9fc0: 00002000 bef07c80 00000003 00000000 00000000 00000001 00000001 0000000323 9fe0: 00000000 bef07c6c 0000266c 401adab0 60000010 00000003 00000000 0000000024 backtrace: invalid frame pointer 0xffffffff25 code: ebffff86 e3500000 e1a07000 da000015 (e594500c)26 segmentation fault不过这次惊讶却令人大为不解。oop竟然说出错的地方在vfs_read（要知道它可是大拿们千锤百炼的内核代码），这怎么可能？哈哈，万能的内核也不能追踪函数调用栈了，这是为什么？其实问题出在faulty_read的43行，它导致入栈的r4、r5、r6、fp全部变为了0xffffffff，ip、lr的值未变，这样一来faulty_read函数能够成功返回到它的调用者——vfs_read。但是可怜的vfs_read（忠实的aptcs规则遵守者）并不知道它的r4、r5、r6已经被万恶的faulty_read改变，这样下去vfs_read命运就可想而知了——必死无疑！虽然内核很有能力，但缺少了正确的fp的帮助，它也无法追踪函数调用栈。36 ssize_t faulty_read(struct file *filp, char __user *buf,37 size_t count, loff_t *pos)38 39 int ret;40 char stack_buf[4];41 42 43 memset(stack_buf, 0xff, 20);44 if (count > 4)45 count = 4;46 ret = copy_to_user(buf, stack_buf, count);47 if (!ret)48 return count;49 return ret;50 }00000000 : 0: e1a0c00d mov ip, sp 4: e92dd870 stmdb sp!, 8: e24cb004 sub fp, ip, #4 ; 0×4 c: e24dd004 sub sp, sp, #4 ; 0×4，这里为stack_buf[]在栈上分配1个字的空间，局部变量ret使用寄存器存储，因此就不在栈上分配空间了 10: e24b501c sub r5, fp, #28 ; 0x1c 14: e1a04001 mov r4, r1 18: e1a06002 mov r6, r2 1c: e3a010ff mov r1, #255 ; 0xff 20: e3a02014 mov r2, #20 ; 0×14 24: e1a00005 mov r0, r5 28: ebfffffe bl 28 //这里在调用memset78: e89da878 ldmia sp, 这次oop，深刻地认识到：内核能力超强，但它不是，也不可能是万能的。所以即使你能力再强，也要和你的team member搞好关系，否则在关键时候你会倒霉的；出错的是faulty_read，vfs_read却做了替罪羊。所以人不要被表面现象所迷惑，要深入看本质；内核本来超级健壮，可是你写的驱动是内核的组成部分，由于它出错，结果整体崩盘。所以当你加入一个团队的时候一定要告诫自己，虽然你的角色也许并不重要，但你的疏忽大意将足以令整个非常牛x的团队崩盘。反过来说，当你是team leader的时候，在选团队成员的时候一定要慎重、慎重、再慎重，即使他只是一个小角色。千万别惹堆栈，它一旦出问题，定位错误将会是一件非常困难的事情。所以，千万别惹你的领导，否则将死得很难看。