MPU6050 & teensy 3.1 problem

Status
Not open for further replies.
You have a scope or logic analyzer? I'm using four MPUs on a single physical i2c bus (with pin muxing to switch to switch between two pairs) and it works fine for me at 400k and 800k i2c rates. I have quite long wires (2m of ribbon cable to each MPU in star topology) and I did need to add 100-ohm series resistors to the i2c lines to make it read reliably but YMMV.
The basic concept of muxing four MPUs definitely works (with i2c_t3).
One thing is if your i2c devices all have internal pullups you may have too many pullups on the bus. A scope is super handy here.
 
I haven't tried it yet. My plan was to just brute force toggle in software between i2c ports 16/17 and 18/19 using wire.begin calls to interrogate two (0x68 and 0x69) MPU6050 devices per port, just to see if it would work. Maybe this weekend I'll get some time to try it.
 
I think I understand how you are doing the muxing. I wanted to see if I could do the same thing by using the higher level wire.begin function to alternately toggle between two sets of pins that access the same physical i2c port (or more since there seems to be several pairs of pins that can be used to access either of the two i2c ports on the Teensy 3.1). The GY-521 boards I would start with all have 2K2 Ohm pullups so i might run into the "too-many-pullups" issue when I try this. The nice thing about toggling wire.begin calls is that it is straightforward to specify the pin pairs and keep track of the i2c devices that might be hanging off that port access node. In this way, many of the same device with the same device address could be alternately accessed in the same circuit just like you are doing. I'll post my results when I get around to doing the experiment.
 
DrTune said:
You have a scope or logic analyzer? I'm using four MPUs on a single physical i2c bus (with pin muxing to switch to switch between two pairs) and it works fine for me at 400k and 800k i2c rates.
Click to expand...
Yes, I'll put an analyzer on it when I get back to that and test properly. I figured if onehorse had already done it I would look more closely at my particular setup.

DrTune said:
I have quite long wires (2m of ribbon cable to each MPU in star topology) and I did need to add 100-ohm series resistors to the i2c lines to make it read reliably but YMMV.
Click to expand...
For one use case, I'll have around 3-5m and will be using drivers that I've already tested with a single MPU6050 and other I2C devices successfully.
DrTune said:
The basic concept of muxing four MPUs definitely works (with i2c_t3).
Click to expand...
Are you saying you have successfully used i2c_t3 library in this muxing approach? or just that it *should work*? If this does in fact work with multiple MPUs I can delete the hardware mux from my design (which works great but removing one more piece would be great).

DrTune said:
One thing is if your i2c devices all have internal pullups you may have too many pullups on the bus. A scope is super handy here.
Click to expand...
I am suspecting this....multiple internal pullups. I know a couple of the devices do in fact have internal pullups..I'll get more focused on this next time around - probably next weekend. I'll be interested to hear your results onehorse.
 
Yes it definitely works I have it working right now and it's fine.

To be crystal clear for anyone re-reading:

You can run 4 MPUs (or two i2c buses of whatever you have either because of colliding i2c addresses or if you want better fanout) on a single teensy 3.1 (and I assume 3.0) I2C output, by switching only SDA between two possible pin mux options.
I use:
19 b2 scl
18 b3 sda0
17 b1 sda1
and I run SCL to all chips, pin 18 to one pair and pin 17 to the other pair (one module in each pair has address select changed so 0x68 and 0x69)
I found it beneficial to put 100ohm series resistors on the Teensy end but didn't capture a before/after on the scope to prove it, running 2m ribbon (i.e. from waist to hand/foot with extra) to each MPU (I used 3v3 power for the MPUs even though they have a 3v3 LDO on the module which I didn't bypass and they work fine)

I just hit the pin mux registers before calling i2c_t3 (after 'begin' of course) and switch just pins 17/18 pin mux registers.

Other notes:
I hacked in 'i2c complete' callbacks into i2c_t3 and did a simple i2c state machine for interrupt-driven MPU6050 polling (with no interrupt line to each MPU so only 4 wires total: power, gnd,scl,sda)

I set the DMP to update at 50fps (currently) and trigger a round-robin poll the MPU interrupt registers every 100hz to see if there's anything in the fifo, and read it.
800khz i2c works for me fine

Plenty of time for other stuff on a Teesny 3.1 @ 96mhz, I'm doing an 8x300pixel WS2812B strips @110hz with a modicum of RGB pixel processing (color waves, fades etc)
Teensy 3.1 is a really nice microcontroller for small projects, I have to say; fast, capacious and modern yet definitely an MCU. The libs are quick and straightforward. It gets the job done really nicely. :)

In fact gotta get back to it ;-) I'll throw github up of the irq-driven mpu reader hack if anyone wants it but not right now.
 
Last edited:
Sorry to resurrect this thread, but I was wondering - DrTune - do you have your example code to post so I can try this muxing trick? I'll be putting a few sensors on a telescope mount and this could help me.

And apologies if I missed a thread elsewhere where you did this.

Thanks!
Matt
 
rootScript said:
@JV88

Did you manage to get the MPU6050_DMP.ino example working with Teensy 3.1 interrupts pin?
I tried adding, this code to the //INTERRUPT DETECTION ROUTINE, but no joy:
Code: 
pinMode(0, INPUT);
attachInterrupt (0, dmpDataReady, RISING);//I tried RISING or CHANGE
all I get in the Serial monitor is:
Code: 
Initializing I2C devices...
Testing device connections...
MPU6050 connection successful

Send any character to begin DMP programming and demo: 
Initializing DMP...
Enabling DMP...
Enabling interrupt detection (Teensy external interrupt 0)...
DMP ready! Waiting for first interrupt...
Just in case anyone else is inteested, Jeff's Docs & Library info are here:
http://www.i2cdevlib.com/devices/mpu6050#source
Click to expand...

For what it's worth I had this same problem but got everything working when I added this
Code: 
uint8_t TeensyIntPin = 2;
at the top to identify the pin on the Teensy 3.1 I wanted to use for the interrupt.
Then the code around line 215 got modified to look like this
Code: 
        Serial.println(F("Enabling interrupt detection (Teensy external interrupt TeensyIntPin)..."));  //MattC
        pinMode(TeensyIntPin, INPUT); // sets the digital pin as input  //MattC
        attachInterrupt(TeensyIntPin, dmpDataReady, RISING);  //MattC

I installed the 3.x (latest) version of "Processing" and had some issues with Java. For whatever reason some of the demos for that would work fine and others wouldnt. In any case, when I changed the code in the "Teapot" demo to look at the COM port the Arduino IDE was using, I got the little flying airplane.

Hope this helps someone,
Matt
(using Teensy 3.1, Arduino 1.6.3, TeensyDuino 1.22, Processing 3.0a5 Win32 and toxiclibs 0022 on Windows Vista 64bit O/S)
 
Last edited:
mconsidine said:
For what it's worth I had this same problem but got everything working when I added this
Code: 
uint8_t TeensyIntPin = 2;
at the top to identify the pin on the Teensy 3.1 I wanted to use for the interrupt.
Then the code around line 215 got modified to look like this
Code: 
        Serial.println(F("Enabling interrupt detection (Teensy external interrupt TeensyIntPin)..."));  //MattC
        pinMode(TeensyIntPin, INPUT); // sets the digital pin as input  //MattC
        attachInterrupt(TeensyIntPin, dmpDataReady, RISING);  //MattC

I installed the 3.x (latest) version of "Processing" and had some issues with Java. For whatever reason some of the demos for that would work fine and others wouldnt. In any case, when I changed the code in the "Teapot" demo to look at the COM port the Arduino IDE was using, I got the little flying airplane.

Hope this helps someone,
Matt
(using Teensy 3.1, Arduino 1.6.3, TeensyDuino 1.22, Processing 3.0a5 Win32 and toxiclibs 0022 on Windows Vista 64bit O/S)
Click to expand...

I just wanted to say thank you for posting this. I've read basically every thread on using the MPU6050 DMP with Teensy 3.1/3.2, and was able to get the code working by switching libraries with various other fixes. Still, I couldn't figure out why reading any pin would only return low, even when pulled high, and when other example code worked. For most Arduinos, all pins default to input mode, so specifying it is redundant. It's really valuable to know this for the future, so thanks.

Edit: Sorry for the necro. Got carried away after squashing my bug.
 
For teensy, they default to "disabled". This saves power.
yes, a AVR->Teensy translation "howto" is needed.
 
Status
Not open for further replies.
Back
Top