Hi there, I have some problem with the code at the moment. So what i want to do is to make the qduino read the code and display the inclination value. I am trying to measure the inclination angle.
code:
#include <Qduino.h>
#include <MPU9250.h>
// an MPU9250 object with the MPU-9250 sensor on I2C bus 0 with address 0x68
MPU9250 IMU(Wire,0x68);
int status;
float ax0 = 0 ;
float ay0 = 0 ;
float az0 = 0 ;
void setup() {
// serial to display data
Serial.begin(115200);
while(!Serial) {}
// start communication with IMU
status = IMU.begin();
if (status < 0) {
Serial.println(“IMU initialization unsuccessful”);
Serial.println(“Check IMU wiring or try cycling power”);
Serial.print("Status: ");
Serial.println(status);
while(1) {}
}
ax0 = IMU.getAccelX_mss();
ay0 = IMU.getAccelY_mss();
az0 = IMU.getAccelZ_mss();
Might not be of any help. But …
Have looked at Sparkfun schematic and library on Github. Dont know which MPU9250 library you are using, so I chose the first one in the list, Bolder Flight systems. The begin routine first intialises the SPI or I2C interfaces depending on which you are using. Then there is a whole lot of if statements that return negative which is where your code is dropping out. If you check these values it might give you a clue. But …
UNO Qdino differences, 16Hz clock 8MHz clock, Atmega328P Atmega32u4.
Anyway, hope you get it resolved, cheers
Jim
EDIT: Further investigation. Status return of -1 (as you have shown) is first read / write to the MPU9250. It writes a value then reads it back, if it is not the same it returns with an error. The register is the clock source to the gyro. I ran the code on a UNO (dont have Qduino or MPU9520) status returned is -1. Which it would be as there is no device connected to the I2C bus.
From this I conclude the I2C interface is not working in your set up and may be due to the CPU clock difference.
Yes, that’s almost definitely the issue here (the incompatibility or continuity issues with the I2C comms) the best way I can think of to prove that is to use the Qduino with another I2C device to see whether you can replicate the issues, try another script that depends on I2C comms with that board to see whether the issue appears there as well, and try another script with a different device connected to the Qduino to see whether there could be issues with the I2C connections to the board itself. Otherwise, even something as simple as using another microcontroller to see whether the same issue occurs could provide some useful info. The script looks good, so I imagine that won’t be causing any issues here. Please let us know if you solve the issues, the solution could be useful for future users of that board.
I believe that they both use the 9250 chip, so code should drive both boards without change. The Sparkfun tutorial should be a good starting point. There is also a link in the tutorial to more information on the algorithms used.
You can see the CPU clock is tied in with the generation of the SCL clock. The original problem is that the MPU9250 does not work with the Qduino but does with a UNO. One is 8MHz the other 16MHz. It would be my starting point.
The library might not be setting the right values. Happy to look at it if you let me know which you are using.
Also for @Jinkyung128517, the Arduino Uno is a 5V device, and the qduino is a 3.3V device. You may need a level shifter with the qduino to get appropriate voltage levels to drive the 9250 successfully.
Search for level shifter in the Core store to find something suitable.
Have not found any reason why the MPU-9250 library should not work with both UNO and Qduino I2C interface.
When using the Arduino IDE you select the board you wish to program. When the program is compiled it accesses a text file related to the board you have selected and sets a number of environmental parameters. One of these is F_CPU, which is then used to set the correct clock frequency. Serial.println(F_CPU); Will show what clock it is set to, UNO = 16000000, Qduino = 8000000.
The I2C library is set up using F_CPU.
This setting of the correct clock rate has got me a number of times in my projects.
Anyway, just an idea, hope you get it to work, cheers
Jim
Hi thanks James, I am currenctly using this library: https://github.com/bolderflight/MPU9250
I am a design student with just basic knowledge with these electronics and coding so it takes a while (some language i don’t quite understand) to fully understand these maths and etc. Thank you for your consideration and if you could explain in simple terms after looking at the library it will be great. I will follow procedures according to you feedback.
As @Robin57159 mentions you probably should check what voltage you are running on the MPU9250. Your circuit diagram shows it connected to 3.3V on the Arduino and that’s what you want when connecting to the Qduino. The MPU9250 is designed to run at 3.3V and the DOF board has a built in regulator to drop a 5V supply voltage to 3.3V. When connecting the MPU9250 directly to 3.3V you should bridge the jumper near the voltage regulator with some solder so that the voltage regular is bypassed.
Next, check the I2C wiring. The Qduino I2C bus is on pins D2 (SDA) and D3 (SCL). Check that you are connecting to these pins and swap these connections just in case the SDA and SCL signals are the wrong way around.
It might also be possible that you need the Wire library in order to get I2C to work on the Qduino. Try adding #include <Wire.h> to the top of your sketch.
If none of that works try Bryce’s suggestion and connect a different I2C sensor (eg MPU6050) to the Qduino to see if that works.
Glad to hear the I2C interface is working. Checking the pins would have been my next port of call as you have the library setup ok.
It is interesting to note the pin differences between the Atmega328p and Atmega32U4 microcontrollers and how Sparkfun have named the pins on the board. This could lead to much confusion, if you dont use the libraries.