Author Topic: Could I use the Digispark Expander Shield to drive stepper motors (via ULN2803)?  (Read 5502 times)

Tommy_2Tall

  • Newbie
  • *
  • Posts: 13

Hi!

I don't have any stepper motors available to test this theory with but would it be possible to hook up a Digispark Expander shield to the inputs of an ULN2803 Darlington array and thereby creating an I2C stepper motor driver?

As a part of my initial KS backer kit I ordered 2 expander shield just because "they are probably useful for something" and now (after a year or so) I have found a potential use for both of them.. so I hope I haven't missed anything really basic and embarrassing..
Well, being a noob I probably wouldn't feel embarassed if someone proved me wrong..  just more educated and more evolved. :-)

The basic plan is to hook up both PCF8574P shields (with individual I2C addresses of course) to one of my Digisparks, with all 16 outputs connected to the input pins of a 2 ULN2803 stepper motor breakout boards.

By alternating the pinstates on the PCF8574P's that change should be propagated to the input end of the Darlington arrays and then to the output end off the Darlington arrays, which acts as the only noticeable current sink in the chain.

Here's when I start to worry that I've missed something but I think that there should be no/neglible currents being sinked/sourced by any of the other pins.. once they go high/low they just maintain that state with a fairly high impedance.. right?
Do I need some form of in-line resistance or pull up/down resitors added to the connections between the PCF8574P's and the ULN2803's just to reduce the risk of "killing" any of the pins?

At some point I also worried that since the PCF8574P only allows you to write a full byte then maybe the pinstate changes are shifted/scrolled into place from LSB to MSB or something like that, rather than each pin being switched to the correct state instantly.
That is probably utter nonsense but if it were true it would possible interfere with the stepper motor phase changes since the pinstates are a bit jittery (at a ridiculously small timeframe) ..


If this part of the plan is actually feasible and I manage to get some stepper motors to try it out then the next step would be to add a serial Bluetooth module (HC-06) that's currently gathering dust in my project box.
"Wireless" mini-CNC gimbal driven by a Digispark.. could it be done?  8)

digistump

  • Administrator
  • Hero Member
  • *****
  • Posts: 1465
I don't see any issues with this - except that the speed of the pin changes will be limited by sending the I2C command - which runs at 1mhz I believe - whether that will be fast enough for running the stepper motors, I have no idea as I'm not very familiar with steppers.

Tommy_2Tall

  • Newbie
  • *
  • Posts: 13

I still haven't received my cheap test subjects (a bunch of steppers and 2 ULN2803 breakout boards) yet but I did find this useful section in a book about advanced Lego NXT projects:
http://books.google.se/books?id=vtUPNDYSTssC&pg=PA248&dq=pcf8574+ULN2003#v=onepage&q=pcf8574%20ULN2003

Basically that layout is what I had in mind and it's good to know that I will most likely need a little "assistance" from some pullup resistors to get the base pins of the Darlington array properly energized.


Another n00b question pops up in my mind.  :-[
Slightly off topic but still concerning the exact same combination of IC's.

Would it be possible to use the same hardware setup to distribute a single input signal line (from the DigiSpark) to 0 - 8 possible "receiving" signal lines depending on the state of the base pins on the Darlington array or does it work the other way around (=several optional inputs to one common output)?

Once I have the hardware and everything hooked up I will do some tests but I don't know if I will fail due to some logical error on my part.
I think it would be pretty efficient to have one single WS2812(/NeoPixel) instance in memory that is re-used to send different pixel values to 8 different physical NeoPixel chains (probably of the same length) by altering the pin states of the I2C port expander.
Just using the port expander without any transistors will most likely result in unwanted "reset" signals whenever the signal is held high/low for (X) ns so a transistor array of some sort is probably necessary for smooth operation. :-)