EmbDev.net

Forum: FPGA, VHDL & Verilog I2C vs. SPI (64 slaves)


Author: Daniel Greenheck (dgreenheck)
Posted on:

Rate this post
0 useful
not useful
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
Author: Schreiberling (Guest)
Posted on:

Rate this post
0 useful
not useful
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.

Author: Klaus Skibowski (Guest)
Posted on:

Rate this post
0 useful
not useful
maybe you could you cascaded I2C multiplexer (like TCA9548A)

Author: Klaus Skibowski (Guest)
Posted on:

Rate this post
0 useful
not useful
Klaus Skibowski wrote:
> maybe you could you cascaded I2C multiplexer (like TCA9548A)

should be: maybe you could use cascaded I2C multiplexer (like TCA9548A)

Author: Lothar Miller (lkmiller) (Moderator)
Posted on:

Rate this post
0 useful
not useful
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.

Author: René B. (reneb)
Posted on:

Rate this post
0 useful
not useful
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
Author: Michael Fischer (mifi)
Posted on:

Rate this post
0 useful
not useful
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

Author: Daniel Greenheck (dgreenheck)
Posted on:

Rate this post
0 useful
not useful
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.

Author: wtf (Guest)
Posted on:

Rate this post
0 useful
not useful
Daniel Greenheck wrote:
> They will need to be read out simultaneously.

WTF?

Author: dunno.. (Guest)
Posted on:

Rate this post
0 useful
not useful
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..

Author: Daniel Greenheck (dgreenheck)
Posted on:

Rate this post
0 useful
not useful
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.

Author: Daniel Greenheck (dgreenheck)
Posted on:

Rate this post
0 useful
not useful
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!

Author: Lothar Miller (lkmiller) (Moderator)
Posted on:

Rate this post
0 useful
not useful
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...

Author: ABC (Guest)
Posted on:

Rate this post
0 useful
not useful
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

Author: Lothar Miller (lkmiller) (Moderator)
Posted on:

Rate this post
0 useful
not useful
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
Author: ABC (Guest)
Posted on:

Rate this post
0 useful
not useful
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.

Reply

Entering an e-mail address is optional. If you want to receive reply notifications by e-mail, please log in.

Rules — please read before posting

  • Post long source code as attachment, not in the text
  • Posting advertisements is forbidden.

Formatting options

  • [c]C code[/c]
  • [avrasm]AVR assembler code[/avrasm]
  • [vhdl]VHDL code[/vhdl]
  • [code]code in other languages, ASCII drawings[/code]
  • [math]formula (LaTeX syntax)[/math]




Bild automatisch verkleinern, falls nötig
Note: the original post is older than 6 months. Please don't ask any new questions in this thread, but start a new one.