Searching for I2C literature

See also the relevant reference manual (not just the datasheet) for the MCU you're using.

Best regards, Spehro Pefhany

Philips.

I've seen this question (or one like it before). Choose a PIC with a UART. Tie Tx to Rx and vise versa. Much simpler.

Luhan

Ahh, good idea.

Thanks.

Al

Return to I2C when you need to hang multiple devices off your bus...

Hello Joel,

True. However, I have the impression that I2C devices are slowly losing ground versus SPI. Even Philips as the originator of that bus doesn't have a lot on the buffet these days, at least not for DACs. Just a few audio parts AFAICT.

PIC chips only have I2C *slave* hardware, you need to do the *master* in software. Also, you can do a rather simple one-line network with the USARTs for multiple units.

Luhan

Hello Luhan,

That's true for many uCs but considering that you rarely need much speed it's not such a big deal. What surprised me was how small the device selection is.

When will ppl stop using 24C0X EEproms ? I2C has been around for *yonks*. Philips originally came up with the idea for their TeeeVeees.

Graham

Hardly a problem. It's trivial to code I2C protocol. I use my own routines as it happens - not library ones.

Graham

You can make any 2 general purpose port pins into an I2C i/f.

Graham

Probably not during our lifetimes.

Best regards, Spehro Pefhany

So, you don't want your computer to know how much RAM is installed? You don't want your computer to identify your monitor?

Your ignorance knows no bounds it seems.

Graham

I've done the same with a 16F877 & a 16F873 talking to each other just using a Tx & Rx connection to the 2 pins on each PIC I defined for that purpose. Both PICs are running from the same 20MHz CMOS oscillator and they are on the same board, so I don't have any clock sync problems. The PIC to PIC data transfers are running at 115K baud. Even though the ports I use have built-in weak pull-ups, I tied each line to 5V thru a

Using SPI you can go a lot faster than I2C and you don't have to worry about the protocol, or Master/Slave issues. Hope this helps.

You are the raging Queen of USENET ignorance. Both item mentioned use I2C chips to identify themselves to the motherboad, and the OS.

Sure and I'm all for I2C. Can't you read FFS ?

Graham

Or serial async, or anything else for that matter. I like some schemes that use just one line to network a bunch of micros together.

Luhan

SPI is faster, of course, but it requires 4 lines rather than 2 and it's more difficult to have an "open bus" where you can just "drop in" additional peipherals (since you need to switch your data in/out lines to each new device as it's dropped in).

RS-232's main advantage seems to be its ubiquity on older PCs. It's not particularly fast (i.e. 115kbps typically) and requires either a hardware UART or at least "well controlled timing" if you're going to bit-bang it... for ultra-low-end microcontrollers (where all you have is something like a timer interrupt and 1 MIP) it's often difficult to get much more than 9600bps full-duplex working robustly.

So, in my mind, I2C is actually one notch better than RS-232 (works on the lowest of the low microcontrollers, significantly more robust for multiple devices, more or less the same throughput), and while it's certainly not as "slick" as SPI, it's a decent tradeoff if you don't need SPI's higher data throughput.

---Joel