Low-level I2C functions

[bojanpotocnik]

Hello!

I want to connect MLX90614 temperature sensors on NXT, but those sensors are using SMBus protocol, not exactly I2C, so integrated I2C function doesn't work.

First, I wanted to manually wrote I2C functions with SensorPort.SetSensorPin and Delay.usDelay functions, but then I realized that that delay functions are not accurate and that everything is too slow for proper communication.

I wanted to create following functions:
- I2Cinit(port, SCL_pin, SDA_pin); //Define SCL (PA23/PA28/PA29/PA30) and SDA (PA2/PA18/PA20/pin6) as output and set them to high level (1)
- I2Cstart(port); //pull SDA line to low level (0)
- bool I2Csendbyte(port, ubyte); //shift out one byte and return boolean variable if ACK/NACK was received
- ubyte I2Creceivebyte(port, ack_nack); //receive one byte and return ACK (0) or NACK (1)
- I2Cstop(port); //release SCL line to high-level (1) and then SDA

I don't think this is possible directly in Java (I'm low-level programmer, used programming in AVR C and Assembler), so I'm asking if is there any possibility to add this features to firmware or if anyone have already done SMBus communication in leJOS, please share the code with me.

I should mention that SMBus communication is working properly on AVRs with hardware (TWI) and software I2C.

Thank you for you help
Bojan

[gloomyandy]

Looking at the spec I don;t really see why this would not work with our current i2c implementation, unless there is some sort of issue on the hardware side. Did you remember to add the external pull up resistors to the data and clock lines (the NXT does not contain them). One possible source of problem is the series resistor in line with the I/O lines, this may mean that it is not possible to pull the lines down to below 0.8V as required for SMBus. Have you tried all of the various i2c modes to see if any of them will operate. You may also want to try the test firmware I made available on the other i2c thread. Is there anything in particular that you can see that will prevent the current i2c code from working?

If you want to try doing this stuff yourself I don't see why you should not be able to get this working to some extent in Java. I assume you will be a bus master, in which case the clock is driven from the NXT and even though as you say the timing routines are not that accurate you should still be able to make it work (though perhaps rather slowly). Remember that to allow the lines to float to the logic 1 pull up level you will need to set the line to be an input, or disable it...

Andy

[bojanpotocnik]

You gave me some hope when you mentioned internal NXTs' resistors. But then I calculated that with 4.7k internal resistors and (recommended) 82k pull-up resistors I can get voltage as low as 0.23V. Even with 47k pull-up resistors I get 0.4V. But anyway, I will replace them with 330R, which is more than enough for ARM's I/O pins protection (they can handle maximum 20mA of current - 5V/0.02A = 250ohm). I always use external resistors.

I already tried all modes of I2C communication (I'm colleague of Matej and we are working together on RoboCup project on Secondary School of Electrical Engineering and Computer Science Maribor, Slovenia. Now, when compass is working properly, we have problems with this sensors). There are some differences, but none of them is working. Tomorrow I can attach analyse results made with USBee DX Logic Analyzer, attached to SCL and SDA lines.

Well, I don't really need additional functions if already included ones will work properly. But I'm just used to have full control of hardware (it's very hard to get used to Java and its' high-level functions, if you program AVRs in ASM and C). I don't like implementing I2C functions in Java, because that is too slow. I have some AVRs attached as TWI/I2C Slaves, which can operate to SCL frequencies up to 1MHz (I will probably use USART for communicating with them, but anyway, sometimes I2C is better). So I would prefer adding this functions to firmware (which, I think, is programmed in C), but I get lost finding firmware files including them.

What are speeds of "Lowspeed", "Standard" and "Hispeed" I2C modes (kHz)?

And, yes, I should mention that communication between AVRs and MLX90614 sensors in working OK, whenever is use hardware (TWI) or software I2C.


Best regards, Bojan

[gloomyandy]

I still suspect that the problem you are seeing may well be a hardware based issue, or perhaps there is some problem with the way you are trying to talk to the device. Perhaps you can post your Java code. Are you sure you are using the correct address, there is often confusion about this due to the 7 bit address with a read/write bit. Are you sure that it has correctly switched out of pwm mode and into SMBus mode? It seems that the clock line needs to be held low to make this happen. You may be better off looking at the signals with a oscilloscope rather than a bus analyser...

Low speed mode operates at 9.6Kbits high speed mode is 125Kbits. Y

You can try adding your code to the firmware, but I don't think we are likely to add it to the standard leJOS version as very few people are likely to benefit from it. I'm afraid I don't have the time to help you with adding that code. Also is there some particular reason that you need to use those particular sensors, I'm sure there are lots of i2c based devices out there. Or since you already have this working with an AVR why not use one of those to convert to i2c that is compatible with the NXT, there are lots of people that have had AVRs working with leJOS...

Good luck

Andy

[bojanpotocnik]

We could'n make MLX sensors working, but we will resolve this with AVR (via USART).


But I'm wondering, why so strange communications speeds? We are using PCF8574, which's maximum SCL frequency is 100kHz. If we use HIGH_SPEED mode, we get some false readings. But 9.6kHz is so (too) slow.

It's possible to make speed around 100kHz (90-100), as is in regular I2C standard (100kHz, 400kHz, 1MHz)?

Thank you.

[skoehler]

We could'n make MLX sensors working, but we will resolve this with AVR (via USART).

Did you give up? Did you take a look with an oscilloscope?

But I'm wondering, why so strange communications speeds? We are using PCF8574, which's maximum SCL frequency is 100kHz. If we use HIGH_SPEED mode, we get some false readings. But 9.6kHz is so (too) slow.
It's possible to make speed around 100kHz (90-100), as is in regular I2C standard (100kHz, 400kHz, 1MHz)?

The I2C Implementation has be implemented completely in software. All I2C hardware is used to connect the big arm with the small avr CPU inside the NXT. I guess, 125kHz is probably simply "as fast the NXT can go".

[bojanpotocnik]

We could'n make MLX sensors working, but we will resolve this with AVR (via USART).

Did you give up? Did you take a look with an oscilloscope?

Yes and yes (2Ch oscilloscope). I decided that is better that we don't use too much of our energy on this sensors and rather concentrate on other sensors. And we must use AVR extension anyway, because of 5 Sharp IR distance sensors - NXT doesn't have enough ADC channels available.

But I'm wondering, why so strange communications speeds? We are using PCF8574, which's maximum SCL frequency is 100kHz. If we use HIGH_SPEED mode, we get some false readings. But 9.6kHz is so (too) slow.
It's possible to make speed around 100kHz (90-100), as is in regular I2C standard (100kHz, 400kHz, 1MHz)?

The I2C Implementation has be implemented completely in software. All I2C hardware is used to connect the big arm with the small avr CPU inside the NXT. I guess, 125kHz is probably simply "as fast the NXT can go".

I mean, 125kHz is too slow for 400kHz and too fast for 100kHz. PCF is failing sometimes at 125kHz, but 10kHz is too slow if we use many sensors on one bus. I would be nice if 100kHz (standard) frequency will be available, because all I2C devices operate on <=100kHz (, and some of them also work on faster modes).

[skoehler]

The I2C Implementation has be implemented completely in software. All I2C hardware is used to connect the big arm with the small avr CPU inside the NXT. I guess, 125kHz is probably simply "as fast the NXT can go".

I mean, 125kHz is too slow for 400kHz and too fast for 100kHz. PCF is failing sometimes at 125kHz, but 10kHz is too slow if we use many sensors on one bus. I would be nice if 100kHz (standard) frequency will be available, because all I2C devices operate on <=100kHz (, and some of them also work on faster modes).

Yes, I realized that you were asking for a 100kHz mode. I let Andy decide whether that is possible/worth it.
I just tried to answer the "why such a strange speed?" part of your question. I can understand your frustration, but it's also partly due to the purchase of NXT/leJOS-incompatible hardware. It would be interesting to see which speeds are supported by RobotC or the Lego firmware.

[gloomyandy]

Well so far this is the only sensor other than the rather odd Lego Ultrasonic sensor that does not work with our i2c implementation in high speed mode. Given that the high speed mode is a bit of a hack anyway and probably actually varies in terms of the actual pulse widths etc. I'm not really inclined to change it for this one device (which may actually have problems other than the speed side of things). So for now I'm going to leave it as it is. If other devices show up with problems we could consider slowing it down, but I think having the extra 20% speed is probably worth it.

The Lego firmware operates at 9.6Kbits, I think there is a high speed mode based on our code in the enhanced firmware which operates at a faster speed but I'm not sure how fast, seem to remember around 40Kbits, I think robotC fast mode is about 50Kbits, seem to remember they claim 5 times faster than standard, but may be wrong...

Andy