Wire.begin(I2C_MASTER, 0x00, I2C_PINS_18_19, [B]I2C_PULLUP_INT[/B], I2C_RATE_400);
Wire.pinConfigure(I2C_PINS_18_19, [B]I2C_PULLUP_INT[/B]);
Hi All,
My first project with my new Teensy 3.1 is to use I2C to read a temperature sensor. I constructed the code below based on the examples, and using the library provided by nox771 (thank you!).
I checked the SDA and SCL lines with an oscilloscope. After reset they are in high imp, and after 1 sec they both go high and stay high.
The serial monitor says:
Error - Set mode: I2C timeout
Arduino: 1.6.7 (Windows 7), TD: 1.27, Board: "Teensy 3.0, Serial, 48 MHz, US English"
C:\Users\...\Documents\Arduino\libraries\i2c_t3\i2c_t3.cpp: In static member function 'static uint8_t i2c_t3::setOpMode_(i2cStruct*, uint8_t, i2c_op_mode)':
C:\Users\...\Documents\Arduino\libraries\i2c_t3\i2c_t3.cpp:289:84: error: 'DMAMUX_SOURCE_I2C1' was not declared in this scope
i2c->DMA->triggerAtHardwareEvent((bus == 0) ? DMAMUX_SOURCE_I2C0 : DMAMUX_SOURCE_I2C1);
^
exit status 1
Error compiling.
Ah thanks, I'll look into it.
Hi,
@nox771, did you ever have any luck in sorting this out? I am having the same issue. Running Latest Arduino IDE and latest Teensyduino. If so, can you elaborate wrt what is meant by, "This line should be wrapped with a preprocessor if."
FWIW, the defines for the specific Teensy 3.x/LC's are:
- If __MK20DX128__ is defined, it is a Teensy 3.0 (without i2c1);
- If __MK20DX256__ is defined, it is a Teensy 3.1 or Teensy 3.2;
- If __MKL26Z64__ is defined, it is a Teensy LC.
Yes the i2c_t3 lib has internal defines for the buses, however those are useful in general. That info should probably be added to the Code Tips post:
https://forum.pjrc.com/threads/25395-Teensy-Quick-Reference-Code-Examples-Tips-and-Tricks
Looking at your example code in I see that it says:
// **********************************************************************************************
// ** Note: This is a Teensy 3.1/LC ONLY sketch since it requires a device with two I2C buses. **
// **********************************************************************************************
//
but in another place I found:
Uploaded i2c_t3_lib_and_sketch_v6.zip
Added Teensy 3.1 support, including Wire1 (I2C1) interface on pins 29/30 and 26/31.
All new code structure used to maximize function sharing between the two buses. For single bus configuration the code/ram size change is minimal relative to v5 library on Teensy 3.0.
Added new header defines to control number of enabled buses and interrupt flags.
Fixed some bugs in ISR code with respect to very high speed transfers.
Added new example sketches for Teensy 3.1: quad_master and dual_bus_master_slave
Can you elaborate on this? I've got several different Teensies and if I need to I can purchase an LC and see if I can shoehorn my code into 8k. But I'm surprised that the 3.x Teensies might be providind a subset of the LC functionality, i.e. the dual i2c bus.
On a Teensy 3.1 or 3.2 with a single TMP102 temp sensor, with 10K pullups I measure about 5 usec risetime, and less than 20 nsec fall time. This is way too slow. The standard Wire library often fails, leaving SCL and/or SDA low. I wonder if it is partly because of the slow rise on clock contributing to missed data bits? With 2k2 pullups, risetime is about 500 nsec - 10X faster. This is in a white breadboard with 24" of 100-mil ribbon cable between Teensy and TMP102. I also get I2C lockups with much shorter prototype wires between a Teensy and Adafruit 14- or 7-segment display using the HT16K33 backpack. These lockups are what led me here to a hopefully more robust library.
I think I've patched this, but you'll need to test it. I've pushed the update to GitHub, and I've attached a new zip to the top post.
I wasn't able to see this error when I compiled. Although trying to work with I2C1 will fail on a T3.0, the defines exist in the kinetis.h file, so I'm not sure how you got the compile to fail (although I'm not running the newest stuff, so that might explain it).
If you have a scope or logic analyzer that would be best for verifying communication, otherwise you will just have to gauge lockups/corruption with respect to different pullup values. If your program checks return values and such for errors that can also help isolate problems.
Hacking for a demo v.s. software engineering.Astonishingly, the Adafruit 7- and 14-segment display example code never checks anything. If the display is completely missing, the demo application runs fine and reports no errors! My mind is boggled.