Electronics > Projects, Designs, and Technical Stuff

SPI vs I2C

(1/3) > >>

NiHaoMike:
I'm planning to add a peripheral bus to my Asus RT-N12. Would it be better to use I2C or SPI? The bus master is implemented in software using the GPIOs, so I cannot use anything timing critical. I'm going to add only a RTC for now, but I'm planning for other features like a non-802.11 ISM transceiver and maybe even a small text LCD or other display.

From my understanding, I2C might be a better choice for that application since there are only 3 GPIOs (the mode switch) that are easy to repurpose. (There are 4 other GPIOs that could be repurposed, but it would take a little more effort.) SPI is designed to be faster but is there going to be much of a difference given that it's a software bus master?

RayJones:
I think you may have already answered your own question.

If you are considering future expansion, I reckon I2C is the way to go.
It all really depends upon how many SPI chip selects you have at hand....

NiHaoMike:
I think I'm going to stick to I2C for now since I found a DS3231 RTC chip in my parts bin.

Is SPI going to offer much speed advantage with a software bus master? I'm thinking that some future applications like LCDs might need quite a lot of bandwidth.

I have thought about implementing my own 4 bit protocol for communicating with a peripheral control processor, perhaps a high end PIC or low end ARM. It would use 4 bidirectional data lines, a unidirectional clock line, and a bidirectional control line. The command (read/write and a 3 bit base address) is latched when the host pulls the control line low to initiate a transfer. For a write (from the host to the peripheral), the upper 4 bits are latched on the rising edge of the clock and the lower 4 bits on the falling edge of the clock. That continues until the control line is released (pulled up by a resistor) to finish the transfer. A read is similar except the host latches the bits just prior to toggling the clock or releasing the control. If the peripheral wants to request attention, it pulls the control line low. Then whatever interface I need (I2C, SPI, RS232, CAN, whatever) would be handled by the peripheral processor. It would not have any "maximum" delay specifications as unexpected delays can occur in a multitasking system.

However, as fast as that would be, it's just too complex for now. So I would need to implement an I2C interface that will coexist with the proposed 4 bit bus. I've thought about using an analog switch chip to disconnect the I2C when the control line is low. If the 4 bit peripheral tries to pull the line low during an I2C transfer, nothing happens since there will be a series resistor to limit current and the host will be driving the line high during I2C transfers. The 4 bit peripheral can also be designed to be able to operate in I2C mode. That could get interesting since if I end up adding a GPS receiver, the peripheral processor could possibly set the RTC without any intervention needed from the host.

NiHaoMike:
I just did a quick test with a userspace program. I had it drive a GPIO high and then low. The pulse width was about 50us, which would be too slow for future applications. The rise time, however, was decent at 10ns, which translates into about 35MHz. With a conservative 15MHz max clock for the future 4 bit bus, that's about 7.5MB/s. (In contrast, HDTV is only 2.5MB/s, so it's theoretically possible to use the GPIOs to interface a ATSC tuner!) Time to start working at the kernel level...

tyblu:
How is HDTV only 2.5MB/s? Isn't it at least 1920x1080 pixels, 24 bits each, at ~120Hz? Or 712MB/s raw data (no packet overhead)? Though I admit compressed movie streams go from ~1MB/s to ~6MB/s from the NAS server.

Navigation

[0] Message Index

[#] Next page