4

I have gone through the below link which says that u-boot support three type of flash technology

http://www.stlinux.com/u-boot/flash

1.Nand 2.NOR 3.SPI Serial Flash

I would want to know why SPI is choosen to be used as flash devices not I2C .

Why can't we have I2C based flash technology?

m.Alin
  • 10,638
  • 19
  • 62
  • 89
Amit Singh Tomar
  • 223
  • 3
  • 8

2 Answers2

9

Bandwidth. I2C tops off at 3.4MHz. SPI doesn't break a sweat at 50MHz. Obviously clever routing is required if you want to reach that speed, but it is possible.

Also, multiple channels. SPI can work in "quad mode", where 4 bits are transferred each cycle instead of 1. This results in a data rate of dozens of megabytes per second.

Ignacio Vazquez-Abrams
  • 48,282
  • 4
  • 73
  • 102
  • Thanks @Ignacio for your quick response .Do you see any other reason for choosing SPI based Flash.I have been told that it is easy to connect/remove SPI controller to flash devices because it uses chip select which allow easy management of flash slave devices but in case of i2c it would be mostly fixed.Would you provide your thoughts on the same. – Amit Singh Tomar Jun 04 '14 at 11:52
  • Usually only one flash device is in a system. The select mechanism is not terribly important at that point. – Ignacio Vazquez-Abrams Jun 04 '14 at 13:19
5

There are three reasons I feel that SPI is a better choice than I2C in most projects.

  1. SPI can be clocked faster than I2C. I've used SPI up to 50Mhz on IC's that support that speed, while the max I2C speed is 3.4Mhz.

  2. Since I2C is a 'shared' data line, the master needs to release control of the data line in order for the slave to respond. I've been burned on several projects before where the master released control and the slave IC proceeded to hang (mostly due to noise on the line). Now you're in a state where both sides are waiting for the other to respond and you need to reset the whole thing. Very frustrating. With SPI you side step the whole shared data lines because each line has a dedicated direction.

  3. If you have a voltage level difference between your IC's (say 3.3V vs 5V) unidirectional voltage translators are easier to deal with than the tri-state needed for I2C.

On a side note, I find it easier to debug SPI if you're using the chip select lines since you can use that line to trigger on your scope. Basically it comes down to, if you have the spare pins, use SPI and save yourself the headache. If on the other hand, you only have 2 pins, you're stuck with I2C. But seriously, add a separate reset line to your I2C slave IC, so you have a means of recovering from a hung bus.

Peter
  • 350
  • 2
  • 13
  • Thanks @Peter for your useful answer ,Would you please elaborate the second point in greater detail. – Amit Singh Tomar Jun 04 '14 at 17:02
  • Is it possible for a one-master-one-slave system to hang? It's certainly possible for two slaves to cooperate to hang the bus, though if slaves would safely current-limit when trying to drive assert SDA when it was externally pulled to a "stiff" high, a master should be able to "unjam" the bus by having the master briefly overpower whatever device is pulling it low well enough that all other devices see a low-high transition. – supercat Jun 09 '14 at 21:14
  • @supercat I can't remember the slave IC that I was using at the time, but it would hang when the master switched to receive mode. The hung IC would pull the entire bus down and I lost communication with everything. Since the I2C standard specifies pull up resistors in order to provide power to the bus, there really isn't a way to unjam it with a stiff high. Even if your master is able to overdrive the lines and can talk to the rest of the slave IC's, they still can't respond because of the original hung IC. I guess what I am saying is I2C is a last resort for me. Signed SPI Fan boy. ;) – Peter Jun 10 '14 at 18:18
  • @Peter: There's no circumstance where a proper slave implementation will deadlock an I2C bus. What can happen is for two slaves to both try to output endless strings of zero bits, and look for ACK pulses at different times. In that case, each slave will release the bus for one clock out of every nine, but together they will hold the bus forever. On a cycle where one slave is outputting a zero and the other is looking for an ACK, overpowering the one that was outputting a zero would cause the other to see a stop/restart, so that it wouldn't drive SDA low anymore. It may be... – supercat Jun 10 '14 at 18:23
  • ...necessary to repeat the overpower/clock sequence nine times before a device that's driving the bus low would look at the bus and be able to see the stop/restart, but it should be possible to unjam things. Of course, SPI doesn't have that problem and does have some other advantages; I wish, though, someone would promote a variation of SPI which used three wires instead of four and could handle handshaking and/or wakeup events. – supercat Jun 10 '14 at 18:26