On Sun, 1 Nov 2015 18:18:36 -0700, you wrote: >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 > >On Sun, Nov 1, 2015 at 6:13 PM, Harvey White <[email protected]> wrote: > >> On Sun, 1 Nov 2015 17:55:19 -0700, you wrote: >> >> >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 >> >> -- >> For more options, visit http://beagleboard.org/discuss >> --- >> You received this message because you are subscribed to the Google Groups >> "BeagleBoard" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> For more options, visit https://groups.google.com/d/optout. >> -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
