I’ve been reading through the data sheet for the mic5891 and SPI and I seem to reading conflicting information. The mic5891 datasheet seems to indicate that when the strobe pin(SS) is held high data is transferred to their respective parallel outputs. From what I’ve read about SPI everything I’ve read says that when the slave select pin is high, the slave ignores the master. Is this just something unique to the mic5891? It ignores the master when held low?
I have 6 shift registers, 5 daisy-chained from data out to data in. These 5 shift registers share the same SS. The last shift register has its own unique SS.
I seem to be running into problems with the code. So far I have been writing the slave select pin high, calling SPI.transfer() and then writing the slave select pin low. Would this be the correct process? I want individual control of the group of 5 daisy chained mic5891s and the 6th single one.
vwyf11:
The mic5891 datasheet seems to indicate that when the strobe pin(SS) is held high data is transferred to their respective parallel outputs. [...] slave select pin is high, the slave ignores the master.
That's not conflicting if you think about it. SS is low when transfering data to the chip, loading data serially into the registers. Because you load it serially you don't want to change the outputs when you load data. When you're done transferring data to the registers (aka, you loaded all) you make the SS high and the outputs are set to the new state.
Do note, the mic5891 does NOT have a real SS. It's a STROBE/latch pin which is compatible with SS/CS. But when the STOBE is high the chip does NOT ignore the clock/data. And that's what would happen with a real SS/CS.
vwyf11:
The last shift register has its own unique SS.
Why?????
vwyf11:
So far I have been writing the slave select pin high, calling SPI.transfer() and then writing the slave select pin low.
That is exactly backwards Most SPI devices have an active LOW SS/CS aka they listen when the SS/CS is LOW and ignore data when it's HIGH. And that's exactly the way the STROBE of this chip is compatible with. SS/CS LOW => transfer all the data (outputs keep the old state in the mean time) => SS/CS HIGH (outputs latch the new states)
vwyf11:
Would this be the correct process? I want individual control of the group of 5 daisy chained mic5891s and the 6th single one.
The MIC5891 does not have SPI input. One can make it work using the SPI of the ATmega, but it's latch is not an SS pin, nor is it a part of every shift register. It is designed to maintain the outputs in one state while shifing shifting in/out bits. Then, all outputs can be changed at the same time by asserting the strobe pin.
So if I write the strobe pin low, call SPI.transfer(), and then write the pin high, this should transfer data and then driving the strobe high latches to the outputs?
I ask because this is how I originally set things up but could not get it to work.
vwyf11:
So if I write the strobe pin low, call SPI.transfer(), and then write the pin high, this should transfer data and then driving the strobe high latches to the outputs?
I ask because this is how I originally set things up but could not get it to work.
I do not use SPI, but GPIO for controlling an MIC5891, and the following code... If this code is too slow, I opted for direct port manipulation of the same GPIO. I haven't spent enough time with the SPI library to know the code equivalence for SPI.
void shiftOut8(byte value) {
for (byte i = 0; i < 8; i++) {
digitalWrite(DataPin, ((value & (HIGH << i)) ? HIGH : LOW));
digitalWrite(ClockPin, HIGH);
digitalWrite(ClockPin, LOW);
}
digitalWrite(StrobePin, HIGH);
digitalWrite(StrobePin, LOW);
}
While this code is my own, I was directly influenced by wiring_shift.c
vwyf11:
I have 6 shift registers, 5 daisy-chained from data out to data in. These 5 shift registers share the same SS. The last shift register has its own unique SS.
I want individual control of the group of 5 daisy chained mic5891s and the 6th single one.
since the last has it's own strobe pin (SS...) you have individual control, but for speed, you can put 3 and 3, shift in dummy bits for the registers that won't be latched. with shift registers (serial to parallel type) you sacrifice speed to put more IO on the same ports. As the MIC5891 is a source driver, whatever you might be driving may suffer from a longer than desirable refresh rate due to the fact that you have to do the DataPin and ClockPin(x2) 40 times. if instead you did DataPin0 and DataPin1 and ClockPin(x2) only 24 times, you could improve your refresh rate.