Arduino Pro Micro mit MPU6050 nur kurz in Funktion

[Erik H. (erik_h)]

Guten Tag,

Ich habe ein MPU6050 an ein Arduino Pro Micro gestöpselt mit Interupt. 
Test Programm von i2cdevlib hochgeladen mit der DMP V6.12 Version. 
Serial Monitor zeigt alles super an nur nach einer kurzen unbestimmte 
Zeit erlischt die LED auf dem Board und die Verbindung ist weg. USB raus 
und wieder rein und es funktioniert wieder nur eine kurze Zeit. 
geschätzt unter einer Minute.

Weis jemand Rat?

mfg Erik

[Stefan F. (Gast)]

Um welches Boards geht es und was zeigt dessen LED an? Welches Programm 
löst den Fehler aus? Welcher Teil dieses Programms ist ausschlaggebend? 
Ein Schaltplan und ein Foto vom Aufbau wäre nicht schlecht.

[Erik H. (erik_h)]

Ich schicke einfach mal das ganze Programm. Die Mouse.move() hier bitte 
ignorieren, es passiert auch ohne Mouse library.
Es geht um ein Arduino Pro Micro Board. Beim Uploaden muss man den als 
Leonardo auswählen. Den Interupt Pin musste ich versetzen auf die 6 
wegen der beiden SLC und SDA.

// I2C device class (I2Cdev) demonstration Arduino sketch for MPU6050 class using DMP (MotionApps v6.12)
// 6/21/2012 by Jeff Rowberg <[e-mail]>
// Updates should (hopefully) always be available at https://github.com/jrowberg/i2cdevlib
//
// Changelog:
//      2019-07-10 - Uses the new version of the DMP Firmware V6.12
//                 - Note: I believe the Teapot demo is broken with this versin as
//                 - the fifo buffer structure has changed
//      2016-04-18 - Eliminated a potential infinite loop
//      2013-05-08 - added seamless Fastwire support
//                 - added note about gyro calibration
//      2012-06-21 - added note about Arduino 1.0.1 + Leonardo compatibility error
//      2012-06-20 - improved FIFO overflow handling and simplified read process
//      2012-06-19 - completely rearranged DMP initialization code and simplification
//      2012-06-13 - pull gyro and accel data from FIFO packet instead of reading directly
//      2012-06-09 - fix broken FIFO read sequence and change interrupt detection to RISING
//      2012-06-05 - add gravity-compensated initial reference frame acceleration output
//                 - add 3D math helper file to DMP6 example sketch
//                 - add Euler output and Yaw/Pitch/Roll output formats
//      2012-06-04 - remove accel offset clearing for better results (thanks Sungon Lee)
//      2012-06-01 - fixed gyro sensitivity to be 2000 deg/sec instead of 250
//      2012-05-30 - basic DMP initialization working

/* ============================================
  I2Cdev device library code is placed under the MIT license
  Copyright (c) 2012 Jeff Rowberg

  Permission is hereby granted, free of charge, to any person obtaining a copy
  of this software and associated documentation files (the "Software"), to deal
  in the Software without restriction, including without limitation the rights
  to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
  copies of the Software, and to permit persons to whom the Software is
  furnished to do so, subject to the following conditions:

  The above copyright notice and this permission notice shall be included in
  all copies or substantial portions of the Software.

  THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
  IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
  FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
  AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
  LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
  OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
  THE SOFTWARE.
  ===============================================
*/

// I2Cdev and MPU6050 must be installed as libraries, or else the .cpp/.h files
// for both classes must be in the include path of your project
#include "I2Cdev.h"

#include "MPU6050_6Axis_MotionApps_V6_12.h"
//#include "MPU6050.h" // not necessary if using MotionApps include file

// Arduino Wire library is required if I2Cdev I2CDEV_ARDUINO_WIRE implementation
// is used in I2Cdev.h
#if I2CDEV_IMPLEMENTATION == I2CDEV_ARDUINO_WIRE
#include "Wire.h"
#endif

// class default I2C address is 0x68
// specific I2C addresses may be passed as a parameter here
// AD0 low = 0x68 (default for SparkFun breakout and InvenSense evaluation board)
// AD0 high = 0x69
MPU6050 mpu;
//MPU6050 mpu(0x69); // <-- use for AD0 high

/* =========================================================================
   NOTE: In addition to connection 3.3v, GND, SDA, and SCL, this sketch
   depends on the MPU-6050's INT pin being connected to the Arduino's
   external interrupt #0 pin. On the Arduino Uno and Mega 2560, this is
   digital I/O pin 2.
   ========================================================================= */

/* =========================================================================
   NOTE: Arduino v1.0.1 with the Leonardo board generates a compile error
   when using Serial.write(buf, len). The Teapot output uses this method.
   The solution requires a modification to the Arduino USBAPI.h file, which
   is fortunately simple, but annoying. This will be fixed in the next IDE
   release. For more info, see these links:

   http://arduino.cc/forum/index.php/topic,109987.0.html
   http://code.google.com/p/arduino/issues/detail?id=958
   ========================================================================= */



// uncomment "OUTPUT_READABLE_QUATERNION" if you want to see the actual
// quaternion components in a [w, x, y, z] format (not best for parsing
// on a remote host such as Processing or something though)
//#define OUTPUT_READABLE_QUATERNION

// uncomment "OUTPUT_READABLE_EULER" if you want to see Euler angles
// (in degrees) calculated from the quaternions coming from the FIFO.
// Note that Euler angles suffer from gimbal lock (for more info, see
// http://en.wikipedia.org/wiki/Gimbal_lock)
//#define OUTPUT_READABLE_EULER

// uncomment "OUTPUT_READABLE_YAWPITCHROLL" if you want to see the yaw/
// pitch/roll angles (in degrees) calculated from the quaternions coming
// from the FIFO. Note this also requires gravity vector calculations.
// Also note that yaw/pitch/roll angles suffer from gimbal lock (for
// more info, see: http://en.wikipedia.org/wiki/Gimbal_lock)
#define OUTPUT_READABLE_YAWPITCHROLL

// uncomment "OUTPUT_READABLE_REALACCEL" if you want to see acceleration
// components with gravity removed. This acceleration reference frame is
// not compensated for orientation, so +X is always +X according to the
// sensor, just without the effects of gravity. If you want acceleration
// compensated for orientation, us OUTPUT_READABLE_WORLDACCEL instead.
//#define OUTPUT_READABLE_REALACCEL

// uncomment "OUTPUT_READABLE_WORLDACCEL" if you want to see acceleration
// components with gravity removed and adjusted for the world frame of
// reference (yaw is relative to initial orientation, since no magnetometer
// is present in this case). Could be quite handy in some cases.
//#define OUTPUT_READABLE_WORLDACCEL

// uncomment "OUTPUT_TEAPOT" if you want output that matches the
// format used for the InvenSense teapot demo
//#define OUTPUT_TEAPOT

#include "Keyboard.h"
#include "Mouse.h"

float FixPointX;
float FixPointY;
float Offset = 100.0;

#define INTERRUPT_PIN 7  // use pin 2 on Arduino Uno & most boards
#define LED_PIN 16 // (Arduino is 13, Teensy is 11, Teensy++ is 6)
bool blinkState = false;

// MPU control/status vars
bool dmpReady = false;  // set true if DMP init was successful
uint8_t mpuIntStatus;   // holds actual interrupt status byte from MPU
uint8_t devStatus;      // return status after each device operation (0 = success, !0 = error)
uint16_t packetSize;    // expected DMP packet size (default is 42 bytes)
uint16_t fifoCount;     // count of all bytes currently in FIFO
uint8_t fifoBuffer[64]; // FIFO storage buffer

// orientation/motion vars
Quaternion q;           // [w, x, y, z]         quaternion container
VectorInt16 aa;         // [x, y, z]            accel sensor measurements
VectorInt16 gy;         // [x, y, z]            gyro sensor measurements
VectorInt16 aaReal;     // [x, y, z]            gravity-free accel sensor measurements
VectorInt16 aaWorld;    // [x, y, z]            world-frame accel sensor measurements
VectorFloat gravity;    // [x, y, z]            gravity vector
float euler[3];         // [psi, theta, phi]    Euler angle container
float ypr[3];           // [yaw, pitch, roll]   yaw/pitch/roll container and gravity vector

// packet structure for InvenSense teapot demo
uint8_t teapotPacket[14] = { '$', 0x02, 0, 0, 0, 0, 0, 0, 0, 0, 0x00, 0x00, '\r', '\n' };



// ================================================================
// ===               INTERRUPT DETECTION ROUTINE                ===
// ================================================================

volatile bool mpuInterrupt = false;     // indicates whether MPU interrupt pin has gone high
void dmpDataReady() {
  mpuInterrupt = true;
}



// ================================================================
// ===                      INITIAL SETUP                       ===
// ================================================================

void setup() {
  Mouse.begin();
  Keyboard.begin();
  
  // join I2C bus (I2Cdev library doesn't do this automatically)
#if I2CDEV_IMPLEMENTATION == I2CDEV_ARDUINO_WIRE
  Wire.begin();
  //Wire.setClock(400000); // 400kHz I2C clock. Comment this line if having compilation difficulties
#elif I2CDEV_IMPLEMENTATION == I2CDEV_BUILTIN_FASTWIRE
  Fastwire::setup(400, true);
#endif

  // initialize serial communication
  // (115200 chosen because it is required for Teapot Demo output, but it's
  // really up to you depending on your project)
  Serial.begin(115200);
  //while (!Serial); // wait for Leonardo enumeration, others continue immediately

  // NOTE: 8MHz or slower host processors, like the Teensy @ 3.3V or Arduino
  // Pro Mini running at 3.3V, cannot handle this baud rate reliably due to
  // the baud timing being too misaligned with processor ticks. You must use
  // 38400 or slower in these cases, or use some kind of external separate
  // crystal solution for the UART timer.

  // initialize device
  Serial.println(F("Initializing I2C devices..."));
  mpu.initialize();
  pinMode(INTERRUPT_PIN, INPUT);

  // verify connection
  Serial.println(F("Testing device connections..."));
  Serial.println(mpu.testConnection() ? F("MPU6050 connection successful") : F("MPU6050 connection failed"));

  // wait for ready
  Serial.println(F("\nSend any character to begin DMP programming and demo: "));
  //while (Serial.available() && Serial.read()); // empty buffer
  //while (!Serial.available());                 // wait for data
  //while (Serial.available() && Serial.read()); // empty buffer again

  // load and configure the DMP
  Serial.println(F("Initializing DMP..."));
  devStatus = mpu.dmpInitialize();

  // supply your own gyro offsets here, scaled for min sensitivity
  mpu.setXGyroOffset(51);
  mpu.setYGyroOffset(8);
  mpu.setZGyroOffset(21);
  mpu.setXAccelOffset(1150);
  mpu.setYAccelOffset(-50);
  mpu.setZAccelOffset(1060);
  // make sure it worked (returns 0 if so)
  if (devStatus == 0) {
    // Calibration Time: generate offsets and calibrate our MPU6050
    mpu.CalibrateAccel(6);
    mpu.CalibrateGyro(6);
    Serial.println();
    mpu.PrintActiveOffsets();
    // turn on the DMP, now that it's ready
    Serial.println(F("Enabling DMP..."));
    mpu.setDMPEnabled(true);

    // enable Arduino interrupt detection
    Serial.print(F("Enabling interrupt detection (Arduino external interrupt "));
    Serial.print(digitalPinToInterrupt(INTERRUPT_PIN));
    Serial.println(F(")..."));
    attachInterrupt(digitalPinToInterrupt(INTERRUPT_PIN), dmpDataReady, RISING);
    mpuIntStatus = mpu.getIntStatus();

    // set our DMP Ready flag so the main loop() function knows it's okay to use it
    Serial.println(F("DMP ready! Waiting for first interrupt..."));
    dmpReady = true;

    // get expected DMP packet size for later comparison
    packetSize = mpu.dmpGetFIFOPacketSize();
  } else {
    // ERROR!
    // 1 = initial memory load failed
    // 2 = DMP configuration updates failed
    // (if it's going to break, usually the code will be 1)
    Serial.print(F("DMP Initialization failed (code "));
    Serial.print(devStatus);
    Serial.println(F(")"));
  }

  // configure LED for output
  pinMode(LED_PIN, OUTPUT);
}



// ================================================================
// ===                    MAIN PROGRAM LOOP                     ===
// ================================================================

void loop() {
  // if programming failed, don't try to do anything
  if (!dmpReady) return;
  // read a packet from FIFO
  if (mpu.dmpGetCurrentFIFOPacket(fifoBuffer)) { // Get the Latest packet 

#ifdef OUTPUT_READABLE_QUATERNION
    // display quaternion values in easy matrix form: w x y z
    mpu.dmpGetQuaternion(&q, fifoBuffer);
    Serial.print("quat\t");
    Serial.print(q.w);
    Serial.print("\t");
    Serial.print(q.x);
    Serial.print("\t");
    Serial.print(q.y);
    Serial.print("\t");
    Serial.println(q.z);
#endif

#ifdef OUTPUT_READABLE_EULER
    // display Euler angles in degrees
    mpu.dmpGetQuaternion(&q, fifoBuffer);
    mpu.dmpGetEuler(euler, &q);
    Serial.print("euler\t");
    Serial.print(euler[0] * 180 / M_PI);
    Serial.print("\t");
    Serial.print(euler[1] * 180 / M_PI);
    Serial.print("\t");
    Serial.println(euler[2] * 180 / M_PI);
#endif

#ifdef OUTPUT_READABLE_YAWPITCHROLL
    // display Euler angles in degrees
    mpu.dmpGetQuaternion(&q, fifoBuffer);
    mpu.dmpGetGravity(&gravity, &q);
    mpu.dmpGetYawPitchRoll(ypr, &q, &gravity);
    Serial.print("ypr\t");
    //Serial.print(ypr[0] * 180 / M_PI);
    //Serial.print("\t");
    //Serial.print(ypr[1] * 180 / M_PI);
    //Serial.print("\t");
    //Serial.print(ypr[2] * 180 / M_PI);

    //Mouse.move(ypr[1] * 180 / M_PI*-1, ypr[2] * 180 / M_PI*-1);
    //FixPointX = ypr[0] * 180 / M_PI*-1;
    
    Serial.print(((ypr[0] * 180 / M_PI) - FixPointX) * Offset);
    Mouse.move(((ypr[0] * 180 / M_PI) - FixPointX) * Offset, ((ypr[2] * 180 / M_PI*-1) - FixPointY) * Offset);
    FixPointX = ypr[0] * 180 / M_PI;
    Serial.print("\t");
    Serial.print(((ypr[2] * 180 / M_PI*-1) - FixPointY) * Offset);
    FixPointY = ypr[2] * 180 / M_PI*-1;
    
    Serial.println();
    if (Serial.available()){
      char data = Serial.read();
    }
    

#endif

#ifdef OUTPUT_READABLE_REALACCEL
    // display real acceleration, adjusted to remove gravity
    mpu.dmpGetQuaternion(&q, fifoBuffer);
    mpu.dmpGetAccel(&aa, fifoBuffer);
    mpu.dmpGetGravity(&gravity, &q);
    mpu.dmpGetLinearAccel(&aaReal, &aa, &gravity);
    Serial.print("areal\t");
    Serial.print(aaReal.x);
    Serial.print("\t");
    Serial.print(aaReal.y);
    Serial.print("\t");
    Serial.println(aaReal.z);
#endif

#ifdef OUTPUT_READABLE_WORLDACCEL
    // display initial world-frame acceleration, adjusted to remove gravity
    // and rotated based on known orientation from quaternion
    mpu.dmpGetQuaternion(&q, fifoBuffer);
    mpu.dmpGetAccel(&aa, fifoBuffer);
    mpu.dmpGetGravity(&gravity, &q);
    mpu.dmpGetLinearAccel(&aaReal, &aa, &gravity);
    mpu.dmpGetLinearAccelInWorld(&aaWorld, &aaReal, &q);
    Serial.print("aworld\t");
    Serial.print(aaWorld.x);
    Serial.print("\t");
    Serial.print(aaWorld.y);
    Serial.print("\t");
    Serial.println(aaWorld.z);
#endif

#ifdef OUTPUT_TEAPOT
    // display quaternion values in InvenSense Teapot demo format:
    teapotPacket[2] = fifoBuffer[0];
    teapotPacket[3] = fifoBuffer[1];
    teapotPacket[4] = fifoBuffer[4];
    teapotPacket[5] = fifoBuffer[5];
    teapotPacket[6] = fifoBuffer[8];
    teapotPacket[7] = fifoBuffer[9];
    teapotPacket[8] = fifoBuffer[12];
    teapotPacket[9] = fifoBuffer[13];
    Serial.write(teapotPacket, 14);
    teapotPacket[11]++; // packetCount, loops at 0xFF on purpose
#endif

    // blink LED to indicate activity
    blinkState = !blinkState;
    digitalWrite(LED_PIN, blinkState);
  }
}

[wer (Gast)]

Zu hoher Strom -> 500mA Polyfuse macht dicht.

[wer (Gast)]

Lade mal einen leeren Sketch hoch und schau ob die LED wieder ausgeht.

[Erik H. (erik_h)]

Jetzt weis ich um welche LED es geht, es ist die TX LED. Würde mich 
wundern, wenn dieses Modul solch ein Stromverbrauch hat.

[wer (Gast)]

Erik H. schrieb:
> Jetzt weis ich um welche LED es geht, es ist die TX LED. Würde
> mich wundern, wenn dieses Modul solch ein Stromverbrauch hat.

Dann nehm ich alles zurück, ich hatte geglaubt zu wissen, dass der Pro 
Micro nur eine rote LED an Vcc hat.

[Stefan F. (Gast)]

Ich habe das Gefühl, dass du gar keine Hilfe brauchst - so schlampig wie 
du auf die Rückfragen eingegangen bist und die Hinweise über dem 
Text-Eingabefeld ignoriert hast.

> Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

[Erik H. (erik_h)]

Ich habe mich selber erschrocken wie lang das plötzlich wurde. Bin 
andere Foren gewöhnt die eine Scrollbox daraus machen. Ich benutze euer 
Forum fast zum ersten mal.

Leerer Sketch ist hochgeladen und die LED leuchtet nicht, es ist aber 
auch die TX LED die ich meinte.

Hab ich noch was ignoriert?

mfg Erik

[Stefan F. (Gast)]

Stefan ⛄ F. schrieb:
> Um welches Boards geht es
> Welcher Teil dieses Programms ist ausschlaggebend?
> Ein Schaltplan und ein Foto vom Aufbau wäre nicht schlecht.

[Erik H. (erik_h)]

Jetzt bin ich grad etwas verwirrt, Board ist doch bestimmt dieses 
Arduino Teil gemeint, also mein Pro Micro. Wenn das nicht gemeint ist, 
bitte im Aufklärung was mit Board gemeint ist.
Den Schaltplan habe ich hochgeladen, der Leider den Thread gefüllt hatte 
und Foto ist nun anbei, ich dachte das wäre optional. Weil ich das 
definitiv richtig angestöpselt habe.
Und ich hatte oben beschrieben, das ich es an Pin 6 den Interrupt 
gesteckt habe, es ist Pin 7.

[Stefan F. (Gast)]

Du hast Probleme mit einem MPU6050 Board. Da ist offenbar mehr drauf, 
als nur der nackte Chip (mindestens eine LED). Um deine 
Problembeschreibung nachzuvollziehen, brauchen wir die Unterlagen zu 
diesem Board.

Ich würde zum Beispiel gerne mal hinterfragen, ob am I²C Bus Pull-Up 
Widerstände fehlen und ob die Stromversorgung/Spannung passt.

Dein Programm solltest du auf wenige Zeilen reduzieren, die das Problem 
zeigen. Durch Schrittweise Reduktion findest du heraus, was den Fehler 
auslöst.

> Den Schaltplan habe ich hochgeladen

ich kann ihn nicht finden!

> Weil ich das definitiv richtig angestöpselt habe.

das wiederum kann ich mangels Plan un Unterlagen vom Modul nicht prüfen.

[Stefan F. (Gast)]

Der MPU6050 Chip kann jedenfalls nicht mit 5V betrieben werden. Du hast 
die VCC Leitung aber an 5V angeschlossen. Auch der I²C Bus vom Chip 
verträgt keine 5V.

[Erik H. (erik_h)]

Ich verstehe das grad nicht, das Modul ist doch für 3.3v und 5v 
geeignet. Mein Arduino board arbeitet auf 5V.

[Stefan F. (Gast)]

Wenn es dieses Modul ist: 
https://www.robotics.org.za/image/catalog/generic/GY-521/GY-521%20-%20Layout03.jpg, 
dann hat es einen 3,3V Spannungsregler und Pull-Up Widerstände auf 3,3V.

Die LED müsste permanent leuchten, denn sie hängt an den 3,3V. Das 
widerspricht aber deiner Aussage, dass es die Tx LED sei.

[Stefan F. (Gast)]

Erik H. schrieb:
> Ich verstehe das grad nicht, das Modul ist doch für 3.3v und 5v
> geeignet.

Woher soll ich das wissen? Soll ich das aus deinem Foto heraus lesen? 
Welches Modul verwendest du? Ich brauche den Schaltplan davon!

Nur weil irgendein Chinese 5V in seinen Shop schreibt, heißt es noch 
lange nicht, dass das Ding uneingeschränkt 5V kompatibel ist. Gerade die 
Spannungspegel an den Signal-Leitungen sind hier oft ein Knackpunkt.

Ich habe zum Beispiel einige USBASP Programmieradpater, die knallhart 5V 
Signale ausgeben, obwohl ich VCC per Jumper auf 3,3V eingestellt habe. 
Das sind keine Produktionsfehler, sondern die werden immer noch so 
produziert und verkauft! Aus dem Schaltplan geht das auch klar hervor - 
works as (Kacke) designt.

Außerdem weiss ich immer noch nicht, um welche LED es geht. Wie ist sie 
woran angeschlossen und was soll sie normalerweise anzeigen?

Anstatt zu diskutieren, besorge den Schaltplan von deinem MPU-6050 Modul 
und reduziere dein Programm schrittweise, um den Fehler einzugrenzen. 
Ziege und das kleinstmögliche Programm, so der Fehler noch auftritt.

Ich würde mal damit anfangen, die komplette USB Kommunikation raus zu 
nehmen und stattdessen Debug Meldungen auf einem seriellen Port 
auszugeben.

[Christian S. (roehrenvorheizer)]

>Du hast Probleme mit einem MPU6050 Board. Da ist offenbar mehr drauf,
>als nur der nackte Chip (mindestens eine LED).

Nur nebnebei: Bei mir läuft dieses Modul, das ich von Pollin habe, 
dauerhaft ohne Aussetzer mit 3,3V am Modul und 5V am AVR. Allerdings 
habe ich nicht diese langen Kabel dazwischen. Lesen erfolgt im 
Burst-Modus nach IRQ. Lochrasterplatte, handverdrahtet, Schutzdioden 
drin gegen +5V und Abblock-Cs. Kein Display am Bus.

Mit Displays ist mir öfter mal der I2C-Bus hängen geblieben, mit diesem 
Modul nicht.


mfG

[Stefan F. (Gast)]

Wenn der verdacht besteht, dass der I²C Bus hängt, schließe ich zwei 
LEDs daran an, die bei LOW Pegel leuchten und stelle auf eine sehr 
niedrige Übertragungsrate um (falls möglich). Meistens leuchtet im 
Fehlerfall eine LED permanent.

Dann trenne ich einen Slave nach dem anderen ab, bis die LED aus geht. 
Der war's dann wahrscheinlich Schuld. Dann kann ich weiter nachforschen, 
warum dieser Slave sich wohl aufgehangen haben könnte.

[Erik H. (erik_h)]

Es gibt in der Schleife 2 verschiedene Aufgaben, die den Loop 
unterbrechen. Beide habe ich mit Serielle ausgaben beobachtet und 
zusätzlich mit LED Funktion. Das Programm wird richtig zwischen durch 
abgebrochen, also nicht bei den 2 bestimmten Aufgaben, und lässt sich 
nur mit Strom aus und wieder an aktivieren. Dann habe ich einfach mal 
den Interrupt Pin entfernt. Jetzt läuft der Problemlos durch. DMP soll 
ja nur mit Interrupt richtig funktionieren (berichtigt mich, wenn ich 
falsch liege), aber es scheint noch alles gut zu laufen, also auch 
saubere Daten. Ist Interrupt trotzdem noch wichtig? Wenn ja, dann müsste 
ich mir ein neues Board kaufen, weil die meisten Interrupts auf SCL und 
SDA laufen und Pin 7 irgendwie nicht richtig funktioniert, da es mein 
Board zum Stillstand bringt.

[Stefan F. (Gast)]

Erik H. schrieb:
> weil die meisten Interrupts auf SCL und SDA laufen

Dieser Satz ergibt für mich keinen Sinn.

Ich sehe da nichts aufregendes:

volatile bool mpuInterrupt = false; 

void dmpDataReady() 
{
  mpuInterrupt = true;
}

attachInterrupt(digitalPinToInterrupt(INTERRUPT_PIN), dmpDataReady, RISING);

Was kann da schon schief gehen? Eigentlich nichts, denke ich. 
Interessanterweise wird diese Variable gar nicht gelesen, deswegen 
stimme ich Dir zu, dass die Interruptleitung offenbar vollkommen unnütz 
ist.

> Pin 7 irgendwie nicht richtig funktioniert, da es mein
> Board zum Stillstand bringt.

Da würde ich mal weiter nachforschen. Denn wenn der Pin vom Programm 
letztendlich gar nicht benutzt wird, wie kann er dann ein Problem 
auslösen? Irgend etwas wichtiges muss ich übersehen haben.

Messe mal die Spannung am Arduino Modul an Pin 7 (und GND). Vielleicht 
ist die Verbindung defekt und da liegt eine undefinierte Spannung an 
(weder eindeutig High noch Low) so dass der Interrupt ständig aufgerufen 
wird und daher das Hauptprogramm zum Stillstand kommt.

[Erik H. (erik_h)]

Der Pin 7 hat 0 Volt. Der Interrupt Pin vom Modul hat 3,26V. Wann sich 
der Interrupt tatsächlich einschaltet weis ich nicht, ist jedenfalls 
nicht zu bemerken.

Alle Interrupts laufen auf ungünstige Pins. RX, TX, SDA und SCL.
https://neonaut.neocities.org/blog/images/pro-micro-fc73b3fa.png
Da steht nun auch Int.6 an Pin 7. Weis nicht was dieser Punkt zu 
bedeuten hat.

Dann noch ne Frage nebenbei. Ich habe den "return;" rausgehaun, bei "if 
(!dmpReady)" und eine Blinkende LED da rein gemacht. Warum Blinkt die 
LED wenn die Serielle Verbindung unterbrochen ist, also wenn der Serial 
Monitor geschlossen wurde? Es ist doch kein Programm da um dmpReady 
umzuschalten auf False.
--Edit: Sie Blinkt auch wenn sie weg ist, am Ende ist ein LED Blinker 
für jede Abfrage am Modul. Aber warum blinkt denn die so langsam wenn 
die Verbindung zum Monitor getrennt wurde?

[Stefan F. (Gast)]

Erik H. schrieb:
> Der Pin 7 hat 0 Volt. Der Interrupt Pin vom Modul hat 3,26V

Wie kann das sein, die sind doch mit einem Kabel verbunden!?

> Alle Interrupts laufen auf ungünstige Pins. RX, TX, SDA und SCL.

Pin 7 (PE6, INT.6) ist doch OK. Alles gut.

> Ich habe den "return;" rausgehauen, bei
> if (!dmpReady) return;

Die Variable ist sowieso sinnlos, weil sie immer true ist:
> Serial.println(F("DMP ready! Waiting for first interrupt..."));
> dmpReady = true;

Da wird überhaupt nicht auf den ersten Interrupt gewartet.

> und eine Blinkende LED da rein gemacht.

Keine Ahnung was das bedeuten soll. Wie macht man eine LED in den 
Quelltext rein? Ist das wirklich eine Blinkende LED, so wie diese: 
https://www.reichelt.de/blink-led-5-mm-bedrahtet-2-pin-rot-5-mcd-60-led-bl-5mm-rt-p10205.html 
? Es wird Zeit für vernünftige Pläne, damit wir wissen, wovon wir reden.

> Sie Blinkt auch wenn sie weg ist,

Wer blinkt wenn wer weg ist? Die LED ist weg und sie blinkt trotzdem? 
Das ergibt keinen Sinn.

> Aber warum blinkt denn die so langsam wenn
> die Verbindung zum Monitor getrennt wurde?

Möglicherweise läuft dein Programm ohne USB Verbindung langsamer, weil 
er Daten an den PC senden will, dieser sie aber nicht annimmt. Nach 
einer gewissen zeit gibt das Framework dann auf und macht trotz 
Kommunikationsfehler weiter.

Da musst du mal die Doku von dem entsprechenden Arduino Core lesen oder 
in dessen Quelltexte gucken. Das ist halt die Krux bei Frameworks. Sie 
sind toll, solange sie wie erwartet funktionieren. Aber wenn sie man 
etwas unerwartetes machen, hat man besonders viel Mühe damit.

[Erik H. (erik_h)]

Danke, das wird es auch sein, dass der Programmablauf sehr langsam dann 
läuft.

Da ich es an Pin 7 messen soll, habe ich die beiden getrennt. Zusammen 
ergeben die aber auch 3,26V.

[Christian S. (roehrenvorheizer)]

> DMP soll ja nur mit Interrupt richtig funktionieren (berichtigt mich, wenn ich 
falsch liege), aber es scheint noch alles gut zu laufen, also auch saubere Daten. 
Ist Interrupt trotzdem noch wichtig? 

Ist die DMP-Software geladen ins Modul?

Ob der Interrupt wichtig ist, geht aus der Konfiguration des Moduls 
hervor. Welche Betriebsart wurde eingestellt?

MfG

[Erik H. (erik_h)]

DMP wird vom Script aktiviert. Da es schon im Modul vorhanden ist.
Ich habe es nur so vernommen, das der interrupt notwendig ist, aber 
bisher scheint es nicht notwendig zu sein, weil alles was ich vorhabe 
super funktioniert.

[Stefan F. (Gast)]

Erik H. schrieb:
> Da ich es an Pin 7 messen soll, habe ich die beiden getrennt. Zusammen
> ergeben die aber auch 3,26V.

Ach so, na dann passt es ja. Ist eindeutig High.