Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

SPI->I2C Converter

Status
Not open for further replies.

dknguyen

Well-Known Member
Most Helpful Member
Is there any IC out there (short of a PIC) that is able to "turn" an SPI device into I2C by acting as a buffer between the SPI device and the I2C bus? Maybe something like an IC that has its own I2C address and picks it up from the I2C line and deals with the I2C start/stop bits, but other than that, when it picks up it's own address on the I2C bus, basically filters out the start/stop bits and sends the data via over the SPI link?

I have a high priority device running off SPI and bunch of low-priority devices that, except for one, run off I2C. It'd really be preferable to run this last low-priority device off the I2C bus so I don't have to deal with chip-selecting the high-priority device (and let it have the SPI bus all to itself).

Not an SPI-I2C bridge IC that is controlled by SPI (like internal registers, if any), but a bridge that is controlled by I2C. Not one that lets a SPI master behave as a I2C master, but one that allows an SPI slave to appear as an I2C slave (ie. completely transparent and setting free from the SPI side of the IC).
 
Last edited:
Aside from a PIC how about an AVR?

SPI is so much faster than I2C you'd have to really slow it down.

Besides most I2C stuff exists as SPI (EEPROM, RTC)
 
Yeah. I'm trying to avoid the chip select line though (which is still needed to combine them on the same bus) and replace it with an I2C address.

And yeah the I2C/SPI lines are all pin combined on all but the largest PICs so even if I wanted to code a small PIC to do the job, it wouldn't work because it doesn't have separate I2C SPI pins! I can only find seem to find SPI-controlled I2C bridges, but no I2C controlled SPI bridges.

3v0 said:
Why not use a PIC with enough pins so you can have both buses?
It does have enough buses, but I am trying to dedicate the SPI bus to the single high-data device and stick all the low data stuff on the I2C bus.
 
It seems that there is some confusion over what I'm looking for. My PIC is able to handle both SPI and I2C on separate pins. But I have a very high-data, time sensitive device that's running on the I2C line. All my low-data devices run off I2C except for one. I want to use this low-data SPI device on the I2C bus along with all the other low-data devices.

THe issue isn't being short of I2C or SPI busses. It's that I want to use this SPI device on the I2C bus along with the other I2C devices and keep it off the regular SPI bus.

blueroomelectronics said:
Do you realise many SPI chips need to have the CS line toggle before they execute their instructions?

Yeah, but that's sort of what I'm talking about. When the I2C-bridge IC detects the right I2C address, it enables the CS line to the SPI slave and then passes all the I2C data on the line through over the SPI bus to the slave (after taking care of all the stop/start bits of course).

Slow SPI is just fine since I won't be reading at it from insane rates. It doesn't matter if the 100kHz of the I2C is the bottleneck for data transmission the SPI slave.
 
Last edited:
Never seen anything like it. You could do I2C in software on a separate pair of I/O lines. And as I've stated before change the I2C devices to SPI and use a bigger PIC. It's kind of silly to throw all sorts of glue logic at something that would simply increase the complexity all to save from using a larger PIC.
 
I could always use a second SPI bus and have the device on that, but I really want to avoid running a CS line because the device is a compass is not necessarily on the same PCB or very close to the PIC itself. I'd rather run two low-speed (more noise resistant?) I2C wires. Plus it's just kind of nice to group all the intermittent data devices onto the same (I2C) bus.

I can't really change the existing I2C devices over to SPI because, well, that's what they are and they are all fairly "unique" sensors my hands are somewhat tied as to what I can use. (PLus all the CS lines, yuck).

I'm entirely willing to throw that glue logic at the thing if it means I can run less wires around the plane and have more streamline coding to control groups of sensors. But, it would take a bit more work than I want to for such a sideline thing if no IC exists.
 
Last edited:
dknguyen said:
I could always use a second SPI bus and have the device on that, but I really want to avoid running a CS line because the device is a compass is not necessarily on the same PCB or very close to the PIC itself. I'd rather run two low-speed (more noise resistant?) I2C wires. Plus it's just kind of nice to group all the intermittent data devices onto the same (I2C) bus.
Is it possible to place a 2nd PIC with the compass and have it do SPI to I2C (or whatever) for you. Thinking there may be an issue with powering a remote PIC in this setup. Too much work?
 
3v0 said:
Is it possible to place a 2nd PIC with the compass and have it do SPI to I2C (or whatever) for you. Thinking there may be an issue with powering a remote PIC in this setup.
It is. Just smaller PICs best suited for the job tend to share their SPI and I2C pins. If I use a larger PIC (as in >40 pins, total overkill for the job) I might as well not use the 2-axis compass (which I chose because all the calibration and algorithms have been done for me), and instead use the 3-axis magnetic sensor (which is also SPI and uses the same technology as the compass) and have the PIC do all that processing and spit out the processed data over the I2C which is what I am considering now.
 
speakerguy79 said:

Every IC I can find are those kinds. Those let a let an SPI master communicate with I2C slaves. Special code (like the configuration and setting registers, etc) is required on the SPI side to communicate with the I2C, but it is transparent on the I2C side.

Since my microcontroller is supposed to be an I2C master controlling an SPI slave, I need an IC that works the opposite way (ie. is configured using the I2C, not the SPI). I need an IC that is transparent to SPI devices since I am unable to modify the code inside the compass to make it properly manipulate the SPI bus to communicate via an I2C-SPI bridge. I can however, manipulate the code in my uC to properly manipulate the I2C bus in such a way to communicate with the SPI via a bridge IC (If such an IC indeed exists).

Instead of an IC that lets an SPI-equipped, I2C unequipped uC communicate to IC devices, I need an IC that allows an I2C-equipped SPI-unequipped uC to communicate with SPI devices. If that makes it more clear.
 
Last edited:
Sorry, I saw the title but got the transmission direction backwards.

Honestly, I think I would just use a PIC in this case. Maybe buy something small and code your own I2C/SPI functions so you don't have to buy something big enough to have two I2C/SPI ports on it?
 
speakerguy79 said:
Honestly, I think I would just use a PIC in this case. Maybe buy something small and code your own I2C/SPI functions so you don't have to buy something big enough to have two I2C/SPI ports on it?

Too bad < 44 pin PIC's all share the SPI/I2C on the same pins! And uhhh. I'm too lazy to bit blast. Oh well. I've decided to try and pursue some COldfire stuff again and just combine the work of 3 dsPICs into a single coldfire.

Now...how to get that development software so I don't have to deal with the maze-like GCC.
 
Last edited:
Well, I guess when you're looking for something go straight to the source. Phillips NXP produces them:

SC18IS602/603

lets a microcontroller's I2C port communicate with the SPI bus. And of course, they also have a bunch of other bridges that let a uC's SPI port communicate with the I2C bus as well as I2C->UART and UART->I2C.

I'm still pretty much set on replacing a bunch of dsPICs with one Coldfire though...
 
Last edited:
Status
Not open for further replies.

Latest threads

New Articles From Microcontroller Tips

Back
Top