New I2C library for Teensy3

[lovebird1238]

Hello. I am new to this whole arduino stuff. Made a few cool things. However, I have a 1602 I2C display and a teensy 3.2 and I'm looking for how to make them go together. This seems hopeful, however upon opening the example basic_echo it does not work. I notice in the comments of the code it says for 3.6 and, well. I'd like to ask for help, if possible. All pins could be blank or filled, if required. Thanks, and sorry if this is confusing. Thank you, have a nice day!

[Theremingenieur]

The basic_echo example is for doing communication tests between the two integrated I2C h/w units of the T3.5 and T3.6, one set up as I2C master, the other one as I2C slave. As you understood already, that can't work on a T3.2.

To check basic communication with EXTERNAL I2C devices like displays and other, use File -> Examples -> i2c_t3 -> basic_scanner and, if needed, fix your wiring of the display until it properly responds at its i2c base address.

[MichaelMeissner]

On the Teensy, you typically need to add two pull-up resistors, one between pin 18/A4 to 3.3v and the other between pin 19/A5 and 3.3v. These resistors are needed to enable i2c to work. Note, some devices have resistors already. As Theremingenieur says, run the scanner first, and if finds the device, then it should work. The typical resistor needed for Teensy's i2c is 2.2K resistors, but you can use other resistors between 2.2K and 4.7K (4.7K is the appropriate value for 5v systems). If you use a higher resistor, it will prevent you from using higher i2c bus speeds (the default speed should work).

When I still used the 16x2 displays, one of my displays worked with 5v. With that display, I needed to use level shifters. In general, if you need a level shifter, it is probably simpler to get a new display that runs on 3.3v. At the moment, you can get a 128x64 OLED display from a US seller on ebay for under $6:

• https://www.ebay.com/itm/US-SELL-0-9...QAAOSwxzdaHRbO

You would use the Adafruit_SSD1306 driver for this, and look at the ssd1306_128x64_i2c example. While the Adafruit driver is open source, if you buy the official Adafruit device, it funds other device/driver development:

• https://www.adafruit.com/product/938

[hw999]

Hi nox771

just a short question : is it correct that each bus has its own callback functions (onTransmitDone, onReqFromDone etc ? I think so but want to be sure.

[KurtE]

I am about 99% sure that each wire object (buss) has it's own callback function, which is stored in the Wire object and is called from the ISR for the specific Wire buss.

[hw999]

Thanks, 99% is a probability high enough for trying.

[nox771]

is it correct that each bus has its own callback functions (onTransmitDone, onReqFromDone etc ?

Yes each bus has its own callback functions.

There is a subtle priority escalation bug if you try doing Wire calls inside the callback, as described here: https://github.com/nox771/i2c_t3/issues/14
The fix is known, I just need to get it out. I'll try to work on it sometime today.

[hw999]

Thanks for information. No need to rush things.

[nox771]

All, I uploaded a v10.1 release on GitHub and the top-post.

This has a fix for a subtle priority escalation bug involving nested Wire calls inside callbacks (refer to: https://github.com/nox771/i2c_t3/issues/14). There is now a user #define (I2C_DISABLE_PRIORITY_CHECK) to disable the checks if anyone has further problems with it (in that case set priorities manually). No other major change.

[hw999]

Hi nox 771

implemented the latest version tested especially the onError() callback and resetBus(). Works really nice. Is it a big deal to provide information about the I2C adress that
was involved in the error occurence - something like onError(uint8_t i2caddress) ?

[nox771]

Is it a big deal to provide information about the I2C adress that was involved in the error occurence - something like onError(uint8_t i2caddress) ?

The library error tracking functions do not log addresses (it is more of an error "counting" system instead of an error "logging" system). This is really the only way to do it since a true error log could use an indeterminate amount of space.

User code could augment the onError() callback to create an actual error log. This would be something like the Master storing the Slave address in some variable, and then grabbing it if onError() occurs, then writing the output to a SD card or similar (with relevant space available checks and all that). If there was an RTC it could also include a timestamp.

[hw999]

The library error tracking functions do not log addresses (it is more of an error "counting" system instead of an error "logging" system). This is really the only way to do it since a true error log could use an indeterminate amount of space.

User code could augment the onError() callback to create an actual error log. This would be something like the Master storing the Slave address in some variable, and then grabbing it if onError() occurs, then writing the output to a SD card or similar (with relevant space available checks and all that). If there was an RTC it could also include a timestamp.

Hi

I did not mean having a logging system implemented. I had a quick look at the code and had the impression that someting like :

if(i2c->user_onError != nullptr) i2c->user_onError(addr); // run Error callback if
instead of
if(i2c->user_onError != nullptr) i2c->user_onError(); // run Error callback if

might be helpfull for erro-tracking on busses with multiple slaves and not require a big change in the coding.

[rstuart]

I have a Teensy 3.2 operating as a slave to a Raspberry Pi. It works just fine, often for several minutes, and then everything stops. Putting a scope on the bus shows that both the SDA an SCL are being held low. Powering down the Teensy brings everything back and after resetting, the Teensy joins the bus again until the next time it stops. The initialization and operation are pretty standard:

Wire.begin(I2C_SLAVE, 0X1c, I2C_PINS_18_19, I2C_PULLUP_EXT, 400000);
Wire.onReceive(receiveEvent);
Wire.onRequest(requestEvent);

The callbacks are just like the basicSlave example. There is an IMU on the same bus but it is completely synchronous with the Teensy so there is unlikely to be any bus contention. Any help on debugging this would be greatly appreciated.

By the way, it is probably irrelevant but I will add this piece of information in case it is related. In trying to get this to work I tried to get the standard Wire library to work. It appeared to work but the high bit on many of the bytes seemed to be wrong so that I would get 128 when the the value should have been 0.

[PaulStoffregen]

In trying to get this to work I tried to get the standard Wire library to work. It appeared to work but the high bit on many of the bytes seemed to be wrong so that I would get 128 when the the value should have been 0.

Would you like me to look into that issue?

If so, please start a new thread about this problem using RPi and the normal Wire lib. Follow the "forum rule" with the complete code to be used on both sides. Please be specific about exactly what needs to be done in the RPi side. Usually when people have posted issues involving Raspberry Pi, setting up a Pi and getting everything working to the point of actually reproducing the problem has required far too much time. On the Teensy side, I can just copy & paste into Auduino and upload. If there's some way to quickly set up the RPi side, please be specific and please understand I won't spend more than about 20 minutes if the code or instructions don't work when I try them on the RPi side.

[rstuart]

Would you like me to look into that issue?

If so, please start a new thread about this problem using RPi and the normal Wire lib. Follow the "forum rule" with the complete code to be used on both sides. Please be specific about exactly what needs to be done in the RPi side. Usually when people have posted issues involving Raspberry Pi, setting up a Pi and getting everything working to the point of actually reproducing the problem has required far too much time. On the Teensy side, I can just copy & paste into Auduino and upload. If there's some way to quickly set up the RPi side, please be specific and please understand I won't spend more than about 20 minutes if the code or instructions don't work when I try them on the RPi side.

The code is too large and complex to post. I will spend some time extracting out the critical parts to reproduce the problem and then post it to a new thread as you suggest.

[rstuart]

Teensy3.2-RPi issue

While preparing the code for Paul, I discovered a bug in the compile environment: I had the CPU speed set to "96 (overclock)". After setting this correctly, the Wire library works just fine and I am happy but a little embarrassed. However, the "New i2c library still locks up the bus from time-to-time. If anyone thinks this is a problem and wants to look into it, I am willing to help out in any way I can.