stop i2c

Hi. I´m not sure if this topic is right in this thread or if my question is answered somewhere else. But I didn´t find anything.

Is there a possibility to stop the i2c-bus, after it is started once? I´d like to stop the transmission so there is nothing left on SDA and SCL. It should be like before typing Wire.begin(); After writing Wire.begin(), this runs forever. I´m searching for a function / method like Wire.end() or something else.

I have to stop and start the i2c-bus within the program several times.

Thanks for help

After writing Wire.begin(), this runs forever.

No.
This just initialises things

I´d like to stop the transmission so there is nothing left on SDA and SCL.

That is what happens when there is no data on it.

Ok. But my problem is: I wired two sensors to the SCL and SCA pin (Arduino Mega). They must be connected with this two wires to the same pins. Otherwise my application doesn´t work. One of the sensors has an i2c-interface. The other hasn´t. I am able to read out the one without interface only before the command "Wire.begin()". After this, it doesn´t work any longer. There appears only the interception that is included in the program, if nothing is sent. In this case it says, the DATA-wire is still HIGH, not LOW as it should be.

I also cannot write any longer to the pins with digitalWrite after the command. So the idea came into my mind, the Wire-library, once initialized, don´t let you do anything with this pins exept the Wire-functions.

Any ideas? Thanks

You are not very clear. You say:-

They must be connected with this two wires to the same pins

Why? there is no reason to do this especially as you say:-

One of the sensors has an i2c-interface. The other hasn´t.

So there is no reason to connect these pins together. Do you need pins as input and outputs, initializing sets the SLC to an output and the SCA to an output or to an input during the back data transfer. Is this the state you want the pins, they have been switched over to the I2C, you can switch them back but I suspect you don't actually know what you are doing and there is a potential that you will damage something. Have you written the code or are you just trying to put two pieces of code together without understanding what you are doing?

There is a reason. This results from the application, as i said. I use one wire harness to connect all sensors to the board. Then i use the adresses of the sensors to communicate with them So I have no possibility to use other pins.

In the final project i won´t be able to use an extra pin for eych sensor. Perhaps there are better solutions, but i can´t devide the sensors up on different wires. I know it would be better, if both types of sensors would support i2c, but i cannot choose them. I shall only write the code.

This is a test if this option works. If something is damaged, there will be another solution.

Thank you

I use one wire harness to connect all sensors to the board. Then i use the adresses of the sensors to communicate with them So I have no possibility to use other pins.

Sorry I just don't understand what you are trying to say here. Especially as you say:-

it would be better, if both types of sensors would support i2c,

If the sensor is not I2C then how can you use it's address to communicate with it.

I mean, i cannot use other pins. Only these two. The one sensor has one adress. I can´t change this. The adress of the other sensor can be changed. So i can use more of these sensors and chose one of them.

Hi, please post a link to the datasheets for both sensors or at least their product names so we can have a guess what are you trying to do.

Eberhard

Good idea. Could have mentioned it myself.

http://home.comet.bg/datasheets/Sensors/MCP9800_1_2_3.pdf

and

www.parallax.com/dl/docs/prod/datast/shtx.pdf or http://www.sensirion.com/en/pdf/product_information/Datasheet-humidity-sensor-SHT1x.pdf

Thank you

For reasons few of us know... Sensirion copied and then altered the I2C specification and used the "non-compatible" result with their sensors. So, while there may even be some pin-name commonality... the Sensirion devices should not share the same bus with the standard Philips style I2C.

Your desire to put them on the same harness (bus) should be reviewed...

The WIRE library uses the built-in hardware I2C support. This does not support Sensirion sensors... so you should really use other pins and bit-bang the data to/from the Humidity sensor.

Yes. This came to my mind, too. There will be a sensor that supports i2c somewhen this year.

http://www.sensirion.com/en/pdf/product_information/Datasheet-humidity-sensor-SHT21.pdf

I hope this will help/work. Thank you very much indeed for your help.

For reasons few of us know

Probably to avoid paying the licence fee to Phillips.

Probably to avoid paying the licence fee to Phillips.

Best reason I've heard. But SPI would have been a better choice for them if that were actually the case.

But SPI would have been a better choice ...

This would require 3 pins (or 4 with SS) compared to 2 for I2C. As standards evolve I guess it's not unusual that rivals compete to win (e.g. BlueRay/HD-DVD etc.). Once the winner is "announced" however, the opposing alternatives will be hard to sell.

As standards evolve

But I2C has been around at least 30 years now!

This would require 3 pins (or 4 with SS) compared to 2 for I2C.

Completely agree. But then the Sensirion chip comes on a 10 pin leadless package with 6 pins listed as (not connected). They were hardly hurting for pins.

Standards are good. If a proprietary standard is uncomfortable, a smart choice is to adopt an existing open standard. Creating a NEW standard should really have compelling reasons... In the case of Sensirion... I just can't see the reason.

It's not like I don't use these chips either... my weatherstation used the SHT15 but it cannot connect to my "purchased" weather station software because it's a non-standard protocol. I have to use the Arduino to convert the received data into a serial string that I interpret into my software.

They were hardly hurting for pins.

There's also the other side of the interface, but I completely agree - standards make sense.