Friday, 25 October 2013

RPi Interfacing

Progress report on the Raspberry Pi computer control & software.


A couple of evenings ago, decided to bite the bullet, and power up the Armdroid connected to my Raspberry Pi.

Needless to say, nothing happened...  but I could hear a slight clunk coming from one of the stepper motors.

Eventually, I realized everything was working, but my delay statements was initially so large, it was taking minutes just to crank a few rotations.   I gradually reduced the pulse delays to approx 500 milliseconds.

The motor addressing is a bit weird.....
Selecting motor 1, results in motor 5 spinning into life, etc.   I spent hours double checking everything, and so far, my only conclusion is that the fly leads connecting the Armdroid's interface PCB to the driver PCB is mixing up the address selection.   A couple of months ago I traced the entire interface board and was pretty happy I knew what to expect here, so I don't think the issue is with the software or that part of the interface circuity.

I really need to run everything with the board outside of the base, but to do that, I'll have to extend my motor cables and modify the power connections.   Hopefully, I can then probe away with my Logic Probe on the running circuit to see what's happening.



Anyway, here is an example of my test program written in "C"  :

 /*  
  * ArmTest.c: Armdroid Test  
  *  
  * Copyright (C) Richard Morris 2013 - http://armdroid1.blogspot.co.uk  
  ***********************************************************************  
  *  
  */  
   
 #include <stdio.h>  
 #include <wiringPi.h>  
   
   
 //// interface definitions ////  
   
 #define SYNC        0x01            // sync - output Low / input High  
 #define CDIR        0x10            // motor direction  
 #define CCLK        0x20            // clock driver circuitry  
   
 #define PULSE_DELAY    500                // delay in milliseconds  
   
   
 void setup()  
 {  
   wiringPiSetup();  
   
   // set pins 0-7 as outputs  
   int pin;  
   for (pin = 0; pin < 8; pin++)  
   {  
     pinMode( pin, OUTPUT );  
   }  
   
   // set Armdroid initially to input mode  
   digitalWriteByte( SYNC );  
 }  
   
 void drive_motor( int mtr, int steps, int dir )  
 {  
   if (mtr < 1 || mtr > 6)            // check motor number in range  
     return;  
   if (steps <= 0)                    // no steps, nothing more to do  
     return;  
   if (dir < 0 || dir > 1)            // check direction flag  
     return;  
   
     // construct control byte  
   // shift motor address into correct position  
   // add SYNC and CLCK bits  
   int output = CCLK + (mtr << 1) + SYNC;  
   
   // add direction bit if necessary  
   if (dir == 1)  
   {  
         output += CDIR;  
   }  
   
   int i;  
   for (i = 0; i < steps * 2; i++)  
   {  
     // output control byte, and delay  
     digitalWriteByte( output );  
     digitalWriteByte( output-SYNC );  
     delay( PULSE_DELAY );  
   
     // output again with sync bit - returns to input mode  
     digitalWriteByte( output );  
   
     // toggle clock-bit to generate next pulse  
     output = output ^ CCLK;  
   }  
 }  
   
 int main()  
 {  
   int motor, steps, direction;  
   
   setup();  
   printf( "Raspberry Pi - ARMDROID TEST\n" );  
   
   for (;;)    /* repeat forever */  
   {  
     printf( "Enter motor number (1 - 6) ? " );  
     scanf( "%d", &motor );  
     printf( "Enter steps ? " );  
     scanf( "%d", &steps );  
     printf( "Enter direction (0 = clockwise, 1 = counter-clockwise) ? " );  
     scanf( "%d", &direction );  
   
     drive_motor( motor, steps, direction );  
   }  
   return 0;  
 }  
   

Very much work in progress, so might not be the final cut, just yet !   The pulse delay of 500 milliseconds is still very slow, but this is good enough for debugging.

Having written this simple test program for 'prototype' variants, I fancy writing another version for Direct-Drive models.   Only the implementation of drive_motor() will need to change,  but, at the moment, I wont be in a position to test it.

I'll be adding the code to the resource page just as soon as I've figured out the best way to share files with eBlogger.