I am designing an FPGA-based project that will connect with 32-64 gyroscope sensors (all the same make & model) on a single circuit board either using I2C or SPI. Obviously I2C seems like the way to go here since there are so many devices. However, there is only one pin on the gyro to change the LSB in the I2C address, meaning that there are only 2 unique addresses possible. This would require implementing up to 32 I2C buses on a single FPGA (is this even possible?), as well as the 32 pull-up resistors I would need. I've been leaning towards SPI since I can afford the extra CS lines and can run it all off of one bus. It also has lower power consumption and doesn't require any pull-up resistors. I am just worried about the capacitance being too large and slowing it down with that many devices connected. Am I correct in choosing SPI for this application? Are there any disadvantages to using SPI that I am not thinking of? Or perhaps a way to get around the address problem with I2C? Thank you Dan
:
Edited by User
SPI is "better" than I2C, because it is: - fully bidirectional - is push-pull -> faster and more robust - a lot easyer to implement both in VHDL and Software the main disatvantage is pin usage - you need 4 instead of 2. So, if you can afford the pin usage, SPI is the "better" choice. 64 CS pins are a lot of pins and a lot of Tracks on your board. You could use shiftregisters for that. This can go down to 5-6Pins for your whole board : CLOCK DATA Enable for shiftregisters, MOSI, MISO, SCK. And only 2 Blocks in your FPGA. You also may need drivers for your signal because the fanout of your FPGA pins may not be enough to drive 64 Targets. Perhaps there is another possibility: You can ask the supplier of your I2C-Device, if there are more different slave addreses avaliable. This is sometimes the case. Every bit of address difference saves half the busses.
Klaus Skibowski wrote: > maybe you could you cascaded I2C multiplexer (like TCA9548A) should be: maybe you could use cascaded I2C multiplexer (like TCA9548A)
Daniel Greenheck wrote: > Am I correct in choosing SPI for this application? Are there any > disadvantages to using SPI that I am not thinking of? The implementation of an SPI Master ist extremely simple because SPI is just connected shift registers. And with fixed SPI slaves you can use fixed hard coded CPHA and CPOL values. Have a look at this: http://www.lothar-miller.de/s9y/categories/45-SPI-Master Try Google translator, its German. This SPI is used many times and it is very straightforward. > I am just worried about the capacitance being too large and slowing it > down with that many devices connected. I would implement 8 of the simple SPI masters. Then theres no hassle with bus loads or high capacitive load.
If you have enough lines and space left you should prefer SPI. A stable and robus I2C state machine on an FPGA together with a data handler for 64 slaves is lot's of effort and risk. Try to use multiples SPIs of course. You may have a chance to collect all slaves at once by slowing down and doing a quick math of course. Let's make an rough(!!!) capacitance estimation and a rough (!!!) frequency of operation estimation: 64 slaves on a signle line with each a I/O and line capacitance of 22pF: 64 * 22e-12 = 1,40800 × 10-9 => Lets say 2nF. Driver output resistance of about 100Ohms. => CutOffFrequency is at about (1/2*Pi*R*C) 800kHz. => FrequencyOfOperation is at about 800kHz/10 => 80kHz. If each participant is capable of charging/discharging a 2nF load then you may try at 80kHz. I would hardly give it a try at an SPI rate of 80kHz, maybe 100kHz. More needs a much better calculation. And it just "feels" to risky. But the same math with four SPIs and each of them having only 16 participants leads to: ~0,5nF and about 3,2Mhz => 300kHz SPI-Rate. Finally to say: Do the math with real values and give it a lot's of reserve and see what the results are and if you can take the responsibility for that. BTW: As you can see an I2C is very speed-limited by the PullUp-Resistor and the load-capacitance. Although you can not connect 64 participants in your application the same math (2nF, 1k PullUp, x10 reserve) will lead to 8kHz I2C rate :-)
:
Edited by User
Hello Daniel, I could not find any information if it is OK to read out the devices one after another or must it read out simultaneously? Best regards, Michael
Michael Fischer wrote: > Hello Daniel, > > I could not find any information if it is OK to read out the devices > one after another or must it read out simultaneously? > > Best regards, > Michael They will need to be read out simultaneously.
what exactly is the point in having 64 gyros on one board anyway..? 64 dimensional movements..? furthermore.. if you want to read simultaniously, you will need a single bus for each one..
Let me rephrase that. The sensors measurements should be done "simultaneously" in the sense that the frequency at which they are sampled is much much higher than their bandwidth, so they are essentially sampled at the same time.
Thank you all for your responses! You all have confirmed the worries I had and provided several feasible solutions which I will be looking into. Thank you for taking the time to answer my question, this forum is very helpful!
Daniel Greenheck wrote: > You all have ... provided several feasible > solutions which I will be looking into. Pls let us know what the final solution is...
at least one more idea: You have 64 I2C devices, which runs simultiounously. For my understanding you have the chance to reduce the number of pin counts, when you use only 1 clock line for every 64 devices, and 64 data lines. So you have 65 lines instead of 128. If it is possible to share 2 Gyros on on I2C bus, you can furthermore reduce some pins by using only 1 clock pin! For my opinion this results in a comfort way using many I2C devices. Cheers
ABC wrote: > For my understanding you have the chance to reduce the number of pin > counts, when you use only 1 clock line for every 64 devices This is not possible when the unknown devices use clock stretching...
:
Edited by Moderator
Lothar Miller wrote: > ABC wrote: >> For my understanding you have the chance to reduce the number of pin >> counts, when you use only 1 clock line for every 64 devices > This is not possible when the unknown devices use clock stretching... That's correct. I missed this information. Normally I2C devices are very simple and don't use clock stretching. Which device does the TO use? I think the TO can find out if he had to care about clock stretching.
Watch this topic
Disable multi-page viewPlease log in before posting. Registration is free and takes only a minute.
Existing account
Do you have a Google/GoogleMail account? No registration required!
Log in with Google account
Log in with Google account
No account? Register here.