This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

  • Resolved

EK-TM4C123GXL: ek-tm4c123gxl-boostxl-senshub compdcm_mpu9150 example interrupt timing irregularity.

Intellectual 940 points

Replies: 6

Views: 216

Part Number: EK-TM4C123GXL

Hello,

I started re-arranging the compdcm_mpu9150 example, commenting out part parts, and irrelevant parts of the code, in an attempt to change the sensor speed. I was measuring the sensor speed with the scope on pin PB_2.

One thing I noticed was the timing of those interrupts are not always same amount of time. some take longer, some take shorter with in a range of %1-%3. I am attaching a video of the scope output. I was able to change the sampling speed of the mpu9150, and I tried 500hz and 250hz, but all have the same problem. Interrupt times are not equal.

For the compdcm algorithm to work properly, the read times must be equal. This is the worst kind of error that you can introduce to a filtering system. Is this because of the mpu9150 or is it because the way the interrupts are handled in the example:

// Called by the NVIC as a result of GPIO port B interrupt event. For this
// application GPIO port B pin 2 is the interrupt line for the MPU9150
void IntGPIOb(void) {

    unsigned long ulStatus = GPIOIntStatus(GPIO_PORTB_BASE, true);

    // Clear all the pin interrupts that are set
    GPIOIntClear(GPIO_PORTB_BASE, ulStatus);

    if(ulStatus & GPIO_PIN_2) {
        // MPU9150 Data is ready for retrieval and processing.
        MPU9150DataRead(&g_sMPU9150Inst, MPU9150AppCallback, &g_sMPU9150Inst);
    }
}

I am thinking that this ISR is doing too much. I tried to set and use a boolean flag, and do the MPU9150DataRead within the while loop, but it did not work, because when I did that the interrupt failed to clear.

I am almost sure this timing irregularity is because of the ISR, but I could not pinpoint it.

Best Regards,

C.

Click here to play this video

  • Unfortunately I am unable to view your video. Just scope shot of the GPIOB[2] and the I2C bus over two samples should help. I don't think the interrupt routine will affect the timing of the request from the MPU9150 unless you make the conversion rate faster than the I2C can transfer the data.

    Best Regards,
    Bob Crosby

  • In reply to Bob Crosby:

    Hello,

    I have uploaded the video at : vimeo.com/352668503

    Scope shoot is i2c bus is coming soon. I will also hookup a mpu9150 to another mcu (an arduino) running similar code, and see if it behaves similar.

    Btw, when you post videos or video links to this forum software, it tries to embed content, but it can not do it properly, thats why the video was not visible.

    Best regards,

    Can

  • In reply to can altineller:

    Do you have results from the Arduino board yet?

    Best Regards,
    Bob Crosby

  • In reply to Bob Crosby:

    Were you able to identify the source of the jitter in the response from the MPU9150?

    Best Regards,
    Bob Crosby

  • In reply to Bob Crosby:

    I have not heard back from you so I assume you have resolved this issue. If not, please just reply to this post, or ask a related question.

    Best Regards,
    Bob Crosby

  • In reply to Bob Crosby:

    Hello,

    No I have not been able to find the source of the jitter, and I could not get around to check it with an arduino.

    I also moved to a new sensor, FXOS8700 + FXAS21002, first made a sketch in energia, verified results with ROS, and now I am writing it again in CCS, using (timer interrupt) for now. I managed to use github.com/counterwound/fxas21002c

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.