1，42步進(jìn)電機(jī)出三線怎么接線
42步進(jìn)電機(jī)出三線接線方法是：1、將步進(jìn)電機(jī)驅(qū)動器脈沖輸入信號和方向輸入信號的正極連接到表控的5v端子。2、將步進(jìn)電機(jī)驅(qū)動器脈沖輸入信號的負(fù)端連接到表控的y1輸出端子上。3、將步進(jìn)電機(jī)驅(qū)動器方向輸入信號的負(fù)端連接到表控的y2輸出端子上。4、接下來就是設(shè)置步進(jìn)電機(jī)驅(qū)動器的細(xì)分，一般可以放在8（1600）左右，通過初步調(diào)試后設(shè)置實(shí)際需要的細(xì)分。5、設(shè)置步進(jìn)電機(jī)的正轉(zhuǎn)設(shè)置，參考設(shè)置，一行實(shí)現(xiàn)正轉(zhuǎn)。x1是正轉(zhuǎn)的啟動開關(guān)。6、步進(jìn)電機(jī)反轉(zhuǎn)的設(shè)置：x2是反向啟動開關(guān)，y1輸出脈沖，y2輸出方向信號。兩行實(shí)現(xiàn)反轉(zhuǎn)動作。所謂的42步進(jìn)電機(jī)就是指的安裝機(jī)座尺寸是42mm的電機(jī),其最大輸出力矩是0.5nm;57電機(jī)是指安裝機(jī)座尺寸是57mm的電機(jī),其最大輸出力矩是3.0nm。
2，42步進(jìn)電機(jī)怎么驅(qū)動
42步進(jìn)電機(jī)可以選擇控制控制型驅(qū)動器如ndm432，需要控制器發(fā)送控制脈沖頻率，可以接收5~24v的差分控制信號，安裝尺寸：86*56.5*20.5mm，工作電壓：12~40vdc；在有些應(yīng)用領(lǐng)域，需要自帶控制脈沖發(fā)生器的驅(qū)動器ndc552，通過io口實(shí)現(xiàn)電機(jī)的控制。如果是接駁臺應(yīng)用領(lǐng)域可以常用ndc456d，可以控制2路42電機(jī)同步運(yùn)行。用戶通過io控制信號實(shí)現(xiàn)電機(jī)的正反轉(zhuǎn)和啟停動作，速度可以通過電位器調(diào)速。也有些領(lǐng)域可以選擇控制驅(qū)動一體產(chǎn)品，人單軌接駁控制臺，需要2軸42步進(jìn)電機(jī)進(jìn)行同步傳輸，可以選擇nps102ac接駁控制器，集成了電源、控制器和電機(jī)驅(qū)動器，可以接入位置開關(guān)，和控制開關(guān)信號和上下工位的smema控制信號，實(shí)現(xiàn)完整接駁控制，也可以多臺結(jié)連，實(shí)現(xiàn)單軌長鏈接駁。
3，驅(qū)動如何調(diào)試
驅(qū)動程序開發(fā)的一個重大難點(diǎn)就是不易調(diào)試。本文目的就是介紹驅(qū)動開發(fā)中常用的幾種直接和間接的調(diào)試手段，它們是：1、利用printk2、查看oop消息3、利用strace4、利用內(nèi)核內(nèi)置的hacking選項(xiàng)5、利用ioctl方法6、利用/proc 文件系統(tǒng)7、使用kgdb前兩種如下：一、利用printk這是驅(qū)動開發(fā)中最樸實(shí)無華，同時也是最常用和有效的手段。scull驅(qū)動的main.c第338行如下，就是使用printk進(jìn)行調(diào)試的例子，這樣的例子相信大家在閱讀驅(qū)動源碼時隨處可見。338 // printk(kern_alert wakeup by signal in process %d\n, current->pid);printk的功能與我們經(jīng)常在應(yīng)用程序中使用的printf是一樣的，不同之處在于printk可以在打印字符串前面加上內(nèi)核定義的宏，例如上面例子中的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這個宏是用來定義需要打印的字符串的級別。值越小，級別越高。內(nèi)核中有個參數(shù)用來控制是否將printk打印的字符串輸出到控制臺（屏幕或者/sys/log/syslog日志文件）# cat /proc/sys/kernel/printk6 4 1 7第一個6表示級別高于（小于）6的消息才會被輸出到控制臺，第二個4表示如果調(diào)用printk時沒有指定消息級別（宏）則消息的級別為4，第三個1表示接受的最高（最小）級別是1，第四個7表示系統(tǒng)啟動時第一個6原來的初值是7。因此，如果你發(fā)現(xiàn)在控制臺上看不到你程序中某些printk的輸出，請使用echo 8 > /proc/sys/kernel/printk來解決。在復(fù)雜驅(qū)動的開發(fā)過程中，為了調(diào)試會在源碼中加入成百上千的printk語句。而當(dāng)調(diào)試完畢形成最終產(chǎn)品的時候必然會將這些printk語句刪除想想驅(qū)動的使用者而不是開發(fā)者吧。記?。杭核挥?，勿施于人），這個工作量是不小的。最要命的是，如果我們將調(diào)試用的printk語句刪除后，用戶又報告驅(qū)動有bug，所以我們又不得不手工將這些上千條的printk語句再重新加上。oh，my god，殺了我吧。所以，我們需要一種能方便地打開和關(guān)閉調(diào)試信息的手段。哪里能找到這種手段呢？哈哈，遠(yuǎn)在天邊，近在眼前。看看scull驅(qū)動或者leds驅(qū)動的源代碼吧！#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…)這樣一來，在開發(fā)驅(qū)動的過程中，如果想打印調(diào)試消息，我們就可以用pdebug(address of i_cdev is %p\n, inode->i_cdev);，如果不想看到該調(diào)試消息，就只需要簡單的將pdebug改為pdebugg即可。而當(dāng)我們調(diào)試完畢形成最終產(chǎn)品時，只需要簡單地將第1行注釋掉即可。上邊那一段代碼中的__kernel__是內(nèi)核中定義的宏，當(dāng)我們編譯內(nèi)核（包括模塊）時，它會被定義。當(dāng)然如果你不明白代碼中的…和##是什么意思的話，就請認(rèn)真查閱一下gcc關(guān)于預(yù)處理部分的資料吧！如果你實(shí)在太懶不愿意去查閱的話，那就充當(dāng)vc工程師把上面的代碼copy到你的代碼中去吧。二、查看oop消息oop意為驚訝。當(dāng)你的驅(qū)動有問題，內(nèi)核不驚訝才怪：嘿！小子，你干嗎亂來！好吧，就讓我們來看看內(nèi)核是如何驚訝的。根據(jù)faulty.c（單擊下載）編譯出faulty.ko，并 insmod faulty.ko。執(zhí)行echo yang >/dev/faulty，結(jié)果內(nèi)核就驚訝了。內(nèi)核為什么會驚訝呢？因?yàn)閒aulty驅(qū)動的write函數(shù)執(zhí)行了*(int *)0 = 0，向內(nèi)存0地址寫入，這是內(nèi)核絕對不會容許的。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行是出錯時內(nèi)核已加載模塊；6行是發(fā)生錯誤的cpu序號；7-15行是發(fā)生錯誤的位置，以及當(dāng)時cpu各個寄存器的值，這最有利于我們找出問題所在地；16行是當(dāng)前進(jìn)程的名字及進(jìn)程id17-23行是出錯時，棧內(nèi)的內(nèi)容24-29行是?；厮菪畔?，可看出直到出錯時的函數(shù)遞進(jìn)調(diào)用關(guān)系（確保config_frame_pointer被定義）30行是出錯指令及其附近指令的機(jī)器碼，出錯指令本身在小括號中反匯編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, 定位出錯位置以及獲取相關(guān)信息的過程：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函數(shù)中的第5條指令（(0xbf00608c-0xbf00607c)/4+1=5），該函數(shù)的首地址是0xbf00607c，該函數(shù)總共6條指令（0×18），該函數(shù)是被0xc0088eb8的前一條指令調(diào)用的（即：函數(shù)返回地址是0xc0088eb8。這一點(diǎn)可以從出錯時lr的值正好等于0xc0088eb8得到印證）。調(diào)用該函數(shù)的指令是vfs_write的第49條（0xc4/4=49）指令。達(dá)到出錯處的函數(shù)調(diào)用流程是：write(用戶空間的系統(tǒng)調(diào)用)–>sys_write–>vfs_write–>faulty_writeoop消息不僅讓我定位了出錯的地方，更讓我驚喜的是，它讓我知道了一些秘密：1、gcc中fp到底有何用處？2、為什么gcc編譯任何函數(shù)的時候，總是要把3條看上去傻傻的指令放在整個函數(shù)的最開始？3、內(nèi)核和gdb是如何知道函數(shù)調(diào)用棧順序，并使用函數(shù)的名字而不是地址？ 4、我如何才能知道各個函數(shù)入棧的內(nèi)容？哈哈，我漸漸喜歡上了讓內(nèi)核驚訝，那就再看一次內(nèi)核驚訝吧。執(zhí)行 cat /dev/faulty，內(nèi)核又再一次驚訝！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（要知道它可是大拿們千錘百煉的內(nèi)核代碼），這怎么可能？哈哈，萬能的內(nèi)核也不能追蹤函數(shù)調(diào)用棧了，這是為什么？其實(shí)問題出在faulty_read的43行，它導(dǎo)致入棧的r4、r5、r6、fp全部變?yōu)榱?xffffffff，ip、lr的值未變，這樣一來faulty_read函數(shù)能夠成功返回到它的調(diào)用者——vfs_read。但是可憐的vfs_read（忠實(shí)的aptcs規(guī)則遵守者）并不知道它的r4、r5、r6已經(jīng)被萬惡的faulty_read改變，這樣下去vfs_read命運(yùn)就可想而知了——必死無疑！雖然內(nèi)核很有能力，但缺少了正確的fp的幫助，它也無法追蹤函數(shù)調(diào)用棧。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 //這里在調(diào)用memset78: e89da878 ldmia sp, 這次oop，深刻地認(rèn)識到：內(nèi)核能力超強(qiáng)，但它不是，也不可能是萬能的。所以即使你能力再強(qiáng)，也要和你的team member搞好關(guān)系，否則在關(guān)鍵時候你會倒霉的；出錯的是faulty_read，vfs_read卻做了替罪羊。所以人不要被表面現(xiàn)象所迷惑，要深入看本質(zhì)；內(nèi)核本來超級健壯，可是你寫的驅(qū)動是內(nèi)核的組成部分，由于它出錯，結(jié)果整體崩盤。所以當(dāng)你加入一個團(tuán)隊(duì)的時候一定要告誡自己，雖然你的角色也許并不重要，但你的疏忽大意將足以令整個非常牛x的團(tuán)隊(duì)崩盤。反過來說，當(dāng)你是team leader的時候，在選團(tuán)隊(duì)成員的時候一定要慎重、慎重、再慎重，即使他只是一個小角色。千萬別惹堆棧，它一旦出問題，定位錯誤將會是一件非常困難的事情。所以，千萬別惹你的領(lǐng)導(dǎo)，否則將死得很難看。