we have a project, with display output on an Adafruit TFT Display, the display is powered by a RA8875 display driver from Adafruit.
Also we have 2 AMIS 30543 Motor Controllers, that are controlling 2 Pololu-Stepper Motors.
Everything is powered from an Arduino Due.
When we tried every component for itself, everything works fine, motors running, display shows its content, but when we did the combination either the display didn’t work at all, or display worked, but motor drivers didn’t.
We found that page http://arduino.cc/en/Reference/DueExtendedSPI
So our Chip-Select Pins are at the pins 4 (TFT), 10 (AMIS #1) and 52 (AMIS #2)
The SPI from the Arduino is connected to a small board, from where MOSI/MISO/CLK are then connected to each of the 3 SPI Slaves.
Appended is our current Code for that project, i stripped out the displayMethods, which are just drawing stuff on the display and triple the code.
We tried to start SPI with following but then nothing worked
factory.ino (15.7 KB)
The way you are initializing the steppers in your
initSteppers() function in the code you provided appears to be correct. There is a note on the Arduino reference page you linked to that when you use the
SPI.begin(int ssPin) function with a slave select pin, that pin becomes unavailable from the
digitalWrite() function we use in our library, so you should not use that function for the two pins you are using with our board, but it should OK to use the function with other SPI SS pins.
I was able to get two of our drivers working with a Due using the code below. You might try a very simple test case with just two of our drivers to see if you can get that working and then add some simple code to see if you can get the graphics driver to respond at the same time. Is there a simple example sketch for the display you are using? Also, using a logic analyzer (if you have access to one) to look at the SPI pins might help with your debugging.
AMIS30543 stepper1, stepper2;
SPI.begin(); //Do not use the CS pin numbers of any AMIS driver boards.
//SPI.begin(11); //It's OK to call SPI.begin with a different pin number if you have another device that uses that pin.
//SPI.begin(4); //If this line is uncommented, the AMIS driver using pin 4 will no longer work
stepper1.init(4); //Slave select pin for one AMIS driver
stepper2.init(10); //Slave select pin for the other AMIS driver
// Set the NXT/STEP pins to outputs
pinMode(12, OUTPUT); //Connected to the step pin of one AMIS driver
pinMode(2, OUTPUT); //Connected to the step pin of the other AMIS driver
// Give the driver some time to power up.
// Reset the driver to its default settings.
// Set the current limit. You should change the number here to
// an appropriate value for your particular system.
// Set the number of microsteps that correspond to one full step.
// Enable the motor outputs.
//The readPosition() function pulls data over the SPI bus, so if this
//responds appropriately, then the devices are working
//Step one driver twice and the other one once so the positions do not change in sync
//This is so we can be certain we are reading different values from the two different drivers
I tried your testcode and also included the readPosition in our project, but the motors won’t move and i keep getting “511 : 511” as position readings without any changes.
But when our display is included too, it will display and keep the same position output
So probably the problem is not at SPI, but with the STEP/DIR pins
Before we had used 22-24-10 and 23-25-52 for the motors STEP/DIR/CS, now i tried it with 5-6-7 and 8-9-10 still nothing.
So we have either fried the stepper drivers, or the motors i think.
We have both, a logic analyzer and an oscilloscope to look at the SPI-lines, but i don’t have any clue, how it has to look
The step pins work at relatively slow signaling rates (for the microcontroller on the Due), so they should not require any special GPIO pins to work. You might try a single driver with one of the example sketches in our library to test the driver. If you cannot get the example sketch to work, you can post pictures of your setup that show how everything is connected and we can look for any problems.
We tried it again yesterday in the evening, with another Due and completely fresh setup, then it worked, also worked with 2 drivers. So we probably had a problem somewhere with cables or such.
We got the final product working, switched to another Due, then it worked mostly, just had some minor things to fix and now it’s fully working.
I’m guessing something on the first Due is not working anymore, but as it works now, i’m happy
Thanks for your help @nathanb
Thanks for letting us know you found the problem. By the way, I noticed that the ISP header on the Due provides 5V, not the 3.3V Vcc the microcontroller on the Due uses, and, if you supplied the IOREF pin on the AMIS drivers with 5V instead of 3.3V, it would send 5V logic signals back to the Due, which could damage individual pins like that, though I would expect the MISO pin on the Due (which is an output on the AMIS and input on the Due) to be most susceptible to that type of damage.
Thanks for that advice, i had not connected that IOREF yet, but now i connected it to a 3.3V outlet on the Due.
As i took this project over from another guy, it just slipped through.