SPI vs I2C - Page 1
Forum section: electronics / projects

author: NiHaoMike
author_rank: Super Contributor
timestamp: January 13, 2011, 01:47:06 am
content: 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?

author: RayJones
author_rank: Frequent Contributor
timestamp: January 13, 2011, 10:21:28 am
content: 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....

author: NiHaoMike
author_rank: Super Contributor
timestamp: January 13, 2011, 04:16:42 pm
content: 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.

author: NiHaoMike
author_rank: Super Contributor
timestamp: January 13, 2011, 11:22:14 pm
content: 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...

author: tyblu
author_rank: Frequent Contributor
timestamp: January 14, 2011, 01:44:39 am
content: 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.

author: JohnS_AZ
author_rank: Frequent Contributor
timestamp: January 14, 2011, 02:46:45 am
content: I thought HDTV was delta encoded, that is, it only sends data for pixels that have changed since the last frame. I could be wrong.

author: Time
author_rank: Frequent Contributor
timestamp: January 14, 2011, 03:37:47 am
content: HD starts at 480i or something like that.

author: NiHaoMike
author_rank: Super Contributor
timestamp: January 14, 2011, 03:48:20 am
content: In the US, a single HDTV channel is just under 20Mbps, or 2.5MB/s.

author: tyblu
author_rank: Frequent Contributor
timestamp: January 14, 2011, 06:45:05 am
content: But.. but.. why? 2.5 MB/s at 24Hz and 24-bit color depth leaves 36400 pixels, which is only 254x143 in a 16:9 display. Does this delta encoding make up for it? Maybe only 16-bit color depth, bumping it up to 312x175? Almost at VGA woo!

author: ziq8tsi
author_rank: Regular Contributor
timestamp: January 14, 2011, 10:24:03 am
content: Quote from: tyblu on January 14, 2011, 06:45:05 amAs a rule of thumb, current generation lossy compressed video with acceptable quality requires 0.15 to 0.3 bits per pixel per frame, minimum. (2500000*8) / (1920*1080*30) = 0.322, so that sounds plausible.You get about 10:1 compression using techniques like those of JPEG, and a further 10:1 because the content of a frame is largely predictable from previous frames.(Even "uncompressed" video probably does not need 24 bits per pixel, because the eye resolves colour information at a lower spatial resolution than brightness. So it is normal to use a luminance-chrominance colourspace and bicimate the chrominance at source.)

author: tyblu
author_rank: Frequent Contributor
timestamp: January 14, 2011, 03:50:51 pm
content: Huh - didn't know we still used YCC.. though it was left behind in analog history. Good to know - thanks! Back to your regularly scheduled program: I think NiHaoMike was talking about I2C or something.