1 Jul
2012
1 Jul
'12
3:03 p.m.
On 07/01/2012 03:42 PM, Tony Duell wrote:
Yes. More often than not, availability is the deciding factor.
Yup.
You're not convinced that SPI supports multiple word widths?? I can
show you the datasheet of the microcontroller in my current design,
where it's configurable, if you like.
I agree 100%. When I have a choice between the two for the same
functionality, I err on the side of I2C.
:-)
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
others. I
personally prefer I2C, but there are situation in which SPI
is a better choice. It is MUCH faster (I2C tops out at 400KHz, I've
One bvious tiem to use SPI is if the chip you want only has an SPI
interfce :-). seen SPI up in
the several-MHz range), and I2C's transfer size is fixed
True. It depends -- a lot -- on what uou are using it for. Most of the time
I use I2C to transfer small amounts of data to display drivers, low-speed
DACs, etc. It weorks fine for that. I ssem to rememebr that SD cards implement a form of
SPI. In which case
you have to use SPI for that.
They do. SD cards can also be accessed via a four-bit-wide, much
faster interface that is proprietary and undocumented, or at least it
used to be. I'm sure the specs are floating around in the wild by now,
but the SPI mode works just fine, and is fast enough for many applications.
at eight bits,
while SPI can transfer arbitrary word widths. (this is
handy for, say, ADCs and DACs).
Hmm.. I am nto convinced. Any microprocesosr/controller is goinf to have
a 'natural' word size (8 bits, 16 bits, etc). The hardware SPI interface
is goign to trasnfer in chunks of that size -- you write a byte, or
whatever to a particualr I/O register and it sends it (or part of it). If
you bit-bang it, you will be shifitng the data in one of the procesor
registers, again of a definted size.
No, that's not at all how it works Tony. Or rather, that's perhaps a
suboptimal way to look at it. My particular example is the
Philips...erm, "NXP" (grumble) LPC2000-series ARM7 processors, which I'm
using all over the place now. They are 32-bit processors, and their SPI
controllers can be configured (by setting bits in very well-documented
registers) for 8, 9, 10, 11, 12, 13, 14, 15, or 16 bits per transfer.
You write to the SPI data register, which is sixteen bits wide, and just
treat the other bits as "don't cares".
As a digression, normally, assuming programming in C, you'd place a
"unsigned short" variable at the address of the SPI data register. (I'll
have none of that uncivilized "uint32_t" bullshit that these kids have
dreamed up...and, surprise, my code is VERY portable)
So what I am sayign is that if you have an 8 bit
processor and want to
talk to a 12 bit DAC, you are essnetially goign to ahve ot load 2 bytes
into the SPI interface. It may only send 4 bits of one of said bytes, of
course. That;'s no better or worse than having to send 2 bytes to an I2C
interface .
Yes, of course. But the transfer width of the SPI interface is not at
all dependent upon, or even relevant to, the width of the processor it's
connected to. Thank heaven. :)
I2C,
however, uses in-band addressing so it saves board space and I/O
pins over SPI.
YEs, that;'s the main reason I think it's more elegant. The separate chip
selects ot each SPI device are somethign fo a pain. So, while I
personally prefer I2C, I believe it is incorrect to
consider SPI to be inferior, since it they both have their strengths and
weaknesses. The industry agrees, as both have been around for decades
and are still considered de-facto standards for local low-speed
communications. (I first used I2C on a Philips 87C751 microcontroller on
a gov't related project in 1991, and it was well-established even then!)
About when I was using it to talk to Philips teletext ICs, etc :-)