Is it possible to get a chip select after 32 bits as opposed to 8 bits? Or for that matter N * 8 bits (i.e. 16, 24, 32, 64 etc).
I want to daisy chain the L6470 however I don’t have a clue how to change the chip select “frequency”? (if that makes sense)
This would be nice but not possible at this point. Unless you write your own SPI drivers using RLP. You should request this www.netmf.com
Darn, ok I posted it. I guess there would be little to no luck in getting that implemented, so it’s time for plan B
[url]http://www.netmf.com/forum/default.aspx?g=posts&m=8458#post8458[/url]
Isn’t the “normal” implementation to have separate CS lines, and “share” the SPI MISO and MOSI lines between all the devices?
As I understand it, this is an advantage of I2C over SPI, because SPI is 2+n pins, and I2C is 2 pins regardless of slave count…
(I’m a beginner, this could all be wrong)
Nah, it’s more options. I know about the chip select stuff, however the chip that I have allows for such features. It would have simplified the circuit design drastically.
Oh, I see, you’re not trying to SHARE an SPI bus, the device supports an actual daisy-chain configuration. Seems to me you could wire up your devices just like in figure 18 from the datasheet, and write single bytes at a time. If I understand correctly, the first time you wrote a byte, it’d go to device 1, the second time it’d go to the second device, etc.
Again, I could be completely wrong…
the 8 bit value will shift from one device to another until you hit the CS pin (chip select). At that point they all process the information and do what they are supposed to do. This would require that the SPI bus hit chip select after 32 bits are sent. this is however not possible at this time. i’ll keep the idea alive in the event it becomes possible in the future.
Ah, now I understand. You could always use GPIO_NONE for the CS pin and do the CS manually, right?
@ Kurtnelle,
If I’m not mistaken then the ChipSelect is dependent on the number of bytes you write.
So, if you write a buffer with 4 bytes then CS will go active before the first by and go inactive after the last byte. This should be exactly what the chips need, if I recall correctly. They will all latch the data on the high going edge…
For the TLC 5940 programming I use an independent pin for the latching. The LED driver needs to have blank active during latching so that a single CS line would not be sufficient. I had no problems with corrupted data by just sending the data via SPI and latching the data independently.
@ Error, nah the chip select toggles after each byte sent.
@ SteH, Intresting concept. Toggle the chip select independently. It will have performance penalties but I’ll consider it.
You know, “error” hurts every time… ;D
Which chip is this?
Also note that, when you daisy-chain chips, things change.
If you have one chip then what you shift into it is what it sees. Then you must latch on every byte.
If you chain 4 chips then the data for the fourth chip must be shifted through chip one, two and three before it gets to the correct chip. Only then can you latch the data.
That is why I say that you can shift all 4 bytes out then latch, or CS or what-ever…
Depends on the needs whether you get performance penalties.
I do the latch even by hardware. The TLC 5940 does a PWM with up to 4096 grey scales. You need to provide these number of grey scale clocks before a new value can be latched. In that time I write the next value into the shift register and a (hardware) counter generates the latch.
@ Seth, A hardware counter? would that be an external component?
Yes, a 4040 12 bit counter for the 4096 greyscales
That’s a very interesting idea. so i would use an 8 bit cmos counter and an 8 bit cmos and gate. Set one side of the AND gate to get it’s data from 8 Fez pins so that you can set the counter from within code. Then connect the counter to the SPI clock pulses. When the counter and the and gates match you would get a pulse on the AND output. That would then feed into the chip selects and the Fez’s SPI bus is none the wiser.
Is that the idea?
So you’re passing Uint16[] to the SPI bus?
static UInt16[] prog = new UInt16[] {
0x5555, 0xaaaa, 0x5050, 0x0505
};
No, not directly: I implemented both byte[24] = 16 channels *12 bit or 16 bit for LED on / off per channel. The Uint16 is translated to all 12 bits of that channel on or off (needed for a e.g. LED cube where I don’t care too much about the grey value but more about the footprint.
public bool Write(uint layer)
{
try
{
m_SPI.Write(layer_data[layer]);
}
catch (Exception e)
{
Debug.Print(e.Message);
}
return true;
}
writes the actual data and
public bool set_pattern(UInt16 pattern, uint layer)
{
uint16_to_bytear(pattern, layer_data[layer]);
return true;
}
converts the UInt16 to a internally stored byte[24]
so the 16 bits are converted to 2 sets of 8 bits for transmission, got it.