Hi Harvey,
Yeah, I’m honestly not interested in I2C, at least not yet. I was just trying to express that I know the register in memory layout “ok” and that the OP was not using a driver, really.
Thanks for the offer though.
You're welcome. I use it extensively, so I can at least make some of
it work.
Harvey
I am curious though. So keep in mind I’m not so much of an EE type when I ask this. But why would you use I2C over another serial communications type ? I’ve used SPI on the msp430’s before, and know that if one were to use SPI through the PRU’s on the BBB, it would / could be amazingly fast.
Is this just some sort of "x.y.z only comes in I2C peripheral . . . " sort of deal ?
By the way, that’s an honest to god question. I see people use I2C all the time, and I do not know why. From a software developer’s perspective, I’m often in the frame of mind that “faster is better”. I kind of feel like I’m missing something though.
I do know that some parts only come in I2C, UART, or SPI. Sometimes two of these serial types, but usually not all 3. So I’ve always assumed, that people pick a part they like, and deal with the serial protocol as needed.
I am curious though. So keep in mind I'm not so much of an EE type when I
ask this. But why would you use I2C over another serial communications type
? I've used SPI on the msp430's before, and know that if one were to use
SPI through the PRU's on the BBB, it would / could be amazingly fast.Is this just some sort of "x.y.z only comes in I2C peripheral . . . " sort
of deal ?
I2C is meant for longer distances, off board, for instance.
It's also an addressed scheme, where everything has an address, so
items can be added easily, just don't let the streams touch... er....
don't duplicate addresses.
SPI is meant for very fast communications over short distances, and
you need an individual SS line (think chip/device select) for each
thing you add.
So I2C, two lines, runs board to board. Add additional boards as
needed without modifying hardware, just watch the addresses.
SPI, 3 lines plus an individual select line, more difficult to add
devices, you have to dedicate one I/O line per device to be added to
get anything added. In addition, I wouldn't want to run the lines
more than a few inches. I2C can run feet.
I2C also has a built in "are you there, did you get this" mechanism,
while SPI has less of a one.
So I use SPI for talking to SD cards, graphics controller chips, fast
add-on memory, with clock rates of about 8 Mhz.
I use I2C to talk to peripheral chips, LED controllers, other smart
functions, EEPROM, clock chips, displays, smart processors, etc. The
idea is that the commands are reasonably short, and rather than
updating a display with the data on a per-pixel basis, I just say
"draw one of these, here....".
Some functions are available in only some interfaces, but for me, I2C
was more like an ethernet situation where things can be dynamically
added as needed, so I picked that for board to board communications.
Oddly enough, one of the designs I'm working on now that has a BBB
style form factor runs SPI to the add on "cape", although it's not a
BBB cape. I'll see how that works.
The choices in picking a communications method run down to the
following kind of questions....
1) how fast is it?
2) how far can it go?
3) how complicated is it to use?
4) how complicated is it to implement? (not the same thing)
5) how much hardware do I need to add? (I2C, two resistors with a
built-in interface on the chip)
6) how much do I need to say on the interface?
7) is it high level or low level? Which do I need?
Harvey
By the way, that's an honest to god question. I see people use I2C all the
time, and I do not know why. From a software developer's perspective, I'm
often in the frame of mind that "faster is better". I kind of feel like
I'm missing something though.
Maybe. From the hardware developer's perspective it's often a matter
of how much additional circuitry it takes as well and how expandable
it is.
I do know that some parts only come in I2C, UART, or SPI. Sometimes two of
these serial types, but usually not all 3. So I've always assumed, that
people pick a part they like, and deal with the serial protocol as needed.
Sometimes, yes. Lots of times it's also a question of what do you
have that's implemented already. I have system level SPI and I2C
implemented, so I use (more or less) what I need when I need it.
Controlling a graphics chip...? (Epson S1D13781)... faster is better,
no I2C interface at all.
Putting a console interface on something that has a standard I2C
interface on it but no SPI? I2C to UART bridge and thence to USB.
Inexpensive addon...
Processor expansion memory... RAM... acts somewhat like an external
disk drive and *not* in program or data space.... SPI.
Thermometer, LED controller, smart keyboard, smart power supply, use
I2C.
SD card, graphics chip, OLED display, TFT color display, large flash
memory? SPI, even if you could use I2C. If the distance is short
enough for the lines (2 inches or so), then definitely SPI.
Harvey
Yeah, thanks. I always forget about the distance factor. It’s a shame that I2C is so “slow” though. ~400Khz is it’s max speed right ?
Yeah, thanks. I always forget about the distance factor. It's a shame that
I2C is so "slow" though. ~400Khz is it's max speed right ?
There's a 1.5 Mhz implementation that's out there, and I think one
that's a bit faster. The processors probably support at least 400
Khz, perhaps the 1.5 Mhz.
Consider, though, that this is not all that bad, it depends on the
message length. 4 bytes at 9 bits/byte, that's 11,000 such
messages/second (very roughly).
If you're doing high level commands, that's not bad. Look up the
speed of wireless transfers, for instance. Not all that much more for
the "inexpensive" methods.
Harvey