spi & i2c sharing pins

[alband]

Hi,

This is another tank-related post.

I recently got that accelerometer to work with a lot of help from this forum. It uses i2c and so uses pins 11 & 13 on a 20X2. I also want to interface this compass module with the same 20X2. It is designed for "basic stamps" and specifically the "shifit/out" command. I've check a few posts on this module and found that this command seems to be almost identical to our "shifin/out".
However, as the manual states, because I'm using a 20X2 I should go for "hspiin/out".

The problem then, is that the spi and i2c pins are the same. Can I wire up both modules on the same pins? I should be able to just turn off the compass module with its enable pin, and ditto with the accel, but this just requires a further bit of wiring, and crucially, slower code.
A simple high/low command doesn't take long, but I'm planning on this one chip doing A LOT of things at once, so if I could just issue the i2c and spi commands without enabling and disabling the chips, it would help to make the code as streamlined as possible.

Thanks in advance as usual,
David.

 

[westaust55]

David you may run into problems with that Parallax module.
Others on this forum have had problems in the past with similar Parallax devices.
The key issue is that the "Stamps" have more limited IO pins and they can rapidly switch one IO pin to be an input or an output whereas the PICAXE (other than 08's) typically have pins dedicated to one direction or slower to change such as port C on the 28X1/40X1 (okay - not sure about speed for direction change for X2 parts).

Why are you considering that particular device?
Rev Ed thru their online store sell the Devatech CMPS03 compass module which is i2c comms comnnected and thus resolves your question.

 

[alband]

Oh dear. Well at least this time I haven't bought the device before I find it a little bugger (hehem aforementioned accel).

I chose it because it was very small and seemed like it could be quite simple to interface (depending on the answer to this post). Mainly the small thing though.

That one you've mentioned sounds great but I cant find it You do mean tech supplies don't you?

 

[westaust55]

Yes I did mean Tech Supplies but when I look more closely although Rev Ed do sell a number of Devatech modules such as the ultrasonics and speech modules, seems the compass module is seemingly not included.

Have a look at:
http://www.robot-electronics.co.uk/acatalog/Compass.html

You may also find other sources of the CMPS03 module near you.

Problem with the Parallax items, having a common input/output pin for bidirectional data flow, is that although several members have tried to use them and I have tried to help them with suggests, do not off the cuff recall one member ever coming back to say they actually got it working. Makes it hard to know if the problems were solved in the manner I previously suggested.

EDIT:

if you do a search on this forum you will find several threads with code relating to the CMPS03 module.

I found I could easily calibrate mine with the switch method described on the datasheet, but have never managed to get the calibration via i2c comms method working.

 

[hippy]

It may be possible to mix SPI and I2C on the same bus but there may be problems. One would have to analyse it in depth on a case-by-case basis, and even then reality may turn out to be different to theory.

The easiest option is to use the hardware for one, bit-banging for the other, or use multiple PICAXE each handling one bus.

 

[alband]

I though there might be some kind of issue, and since there is, and the parallax has been problematic, the best solutions does seem to stand out as the CMPS03.
This would be where I get it from. Is it just me, or is that a 28pin PIC interfacing with two sensors and an opamp? Wonder if the 20X2 could interface directly with the sensors?

Anyway, thanks for the help as always. I'm sure I'll be back soon with a post along the lines of "interfacing CMPS03" although you said there were lots of previous posts so I'll do a search first...

 

[westaust55]

Definitely is a PIC as the main device.

Their CMPS03 photo is better quality than I have found even on the Devantech site so I will update my photo in PEBBLE as well.

Have fun with your new project.

 

[BCJKiwi]

Picaxe can interface to the CMPS03 using either i2c, OR, Reading pwm pulse width ReadADC (of a pwm output).

Check out the datasheet here http://www.robot-electronics.co.uk/htm/cmps3tech.htm
and the link there to sample code for an 18X using i2c. Have only used i2c with a 28X1 myself.

SPI and i2c can be shared and there a documents that exist on the topic. Only one pin is shared and one protocol is basically ignored by the other but obviously only one can be used at a time. Lots of additional complications.

The board runs off 5V or 3.3 and has an onboard 3.3V reg which can provide a small amount of power out when the board is run from 5V.

As space is a concern be aware that this board is 32mm x 34mm.

 

[alband]

As space is a concern be aware that this board is 32mm x 34mm.

Exactly. That's why I wonder if I can interface the PICAXE directly with the sensors. The board isn't particularly dense either so it could he an option to make my own version and transfer the components?

 

[BCJKiwi]

If you were to take that approach then probably better to start from the base chip of which there are a number available - it appears you enjoy a challenge!

 

[westaust55]

Since space is a major constrain for you, I had another look at the module you first mentioned which as around 12mm x 12mm.

Looking more closely at the datasheet for that particular module, unlike some other modules from the same source, the compass module does have separate data input and data output pins with a common clock signal pin so it could be an option.

The datasheet also has BS program example code which seemingly includes calibration routines. As it is in BASIC it should be relatively easy to port to your PICAXE.

 

[alband]

Hold on I thnk I may have misunderstood. The main problem with this module is that it uses one pin for data in and out. PICAXE's can't switch a pin to be an output and input as fast as a basic stamp chip (which the paralax module is designed for). But doesn't it just use the SPI protocol for which the PICAXE has hardware pins. However, these are the same pins as the I2C accel uses so they can't be used. So, (this is the bit I'm sketchy on) it would be good if I could use another pin for the communication with the compass. But as stated it wouldn't be able to switch between input and output. However, since the actual chip uses seperat input and output pins, it would be possible to have two seperate pins (+ clock) for comunication, thus avoiding the switching problem.
Now, surely this would be possible evern if it had one pin on the module, and two pins on the PICAXE using diodes?

It certainly would he easier to use this module sizewise so I'd be interested if it would be easier communicationwise.

Thanks.

 

[westaust55]

Two pins for the hspi related commands are shared with the pins for the i2c comms.

Although the hspi commands are recommended as they use the hardware of the PIC chip, you can alternatively (still) use the SHIFTIN and SHIFTOUT which can use other pins that you select.

Note also the earlier comment by BCJKiwi:

SPI and i2c can be shared and there a documents that exist on the topic. Only one pin is shared and one protocol is basically ignored by the other but obviously only one can be used at a time. Lots of additional complications.

So give it a try on the hspi pins and there can be a fall back to other pins if all else fails but seems you should be right with hspi pins.


For the compass module you initially emntioned there are two seapare data pins (datain and dataout) which the examples on the BS are interconencted to a single BS pin.

 

[BCJKiwi]

Hmm confused this device with another - 3.3v not applicable to this device - see notes in original post #8

To expand on the i2c / SPI; source here http://www.i2cchip.com/mix_spi_i2c.html

You can normally mix I2C and SPI on the same pins. I2C only does something between START and STOP.
START is when SCL is HI, SDA goes to HI->LO.
STOP is when SCL is HI and SDA goes LO->HI.
So if you arrange your code such that SDA only changes value when SCL is LO, there will be no problems. The I2C will not notice any SPI transactions. Of course all the SPI devices have thier own individual CS pin, but this is the disadvantage of SPI.
So to spell it out.

• You can use I2C devices on an SPI bus. Just connect SCL to SCLK and SDA to SDIO.
• You can use SPI devices on an I2C bus, just give each chip its own CS signal.
• Between START and STOP you can only do I2C transactions.
• The bit timing will be set by the I2C bus,even when doing SPI, ie use 100 or 400kHz
• Write your routines so that SCL and SDA don't change at the same time. This also removes the problem of SPI devices with rising vs falling clock
• The "SPI" type devices do have to have a common-able data in and out pins.
• You can use the same routines for both if you are short of code space. Some SPI devices will need non 8 bit sized transfers.
• I2C devices have noise filters on the input. SPI devices don't. Bear this in mind if you have long cable runs.
• You will need to have a reset function that makes sure everything is in the correct state. In particular, some non-I2C serial devices needs some clocks to bring them into a defined state.