I need to get my Pi to talk to a Seeeduino XIAO however the standard Arduino SPI library/examples online don't work with the Seeeduino eg. AVR vs. SMD21.
There is this example code here which is close to what I'm after however they have switched the MISO/MOSI pins around, and I need to keep/use the i2c pins.
I have never used SPI before so I need to put some time in to learn it. But I figured I'd ask in case anyone happened to know some basic code to get the two devices talking to each other (I should be able to do the Pi side).
My alternative is to use software serial (since I'm already using the only serial port on my Pi) however I have read that it has high error rate. Hopefully SPI is solid. I would be expecting to transfer IMU strings at low-ish rate, say 10Hz would be "fast" to me.
I'd appreciate any help otherwise I'll figure it out over time and respond back to this thread.
Yes ideally it would just use i2c and that's what I was trying to do initially. My project is a little complicated (not really) but it is using a lot of ports.
I had confirmed that everything worked individually and the MPU6050 is very touchy, keeps crashing for some reason (IO error). At first I was using the two separate i2c ports on the Pi (sorry this is an Arduino forum) and it seemed bus 0 was more reliable. So I went there, the addresses are different between the two devices (MPU vs. VL53L0X) eg. 29 vs. 68. The VL53L0X is rock solid, always works as long as you want. The MPU for some reason keeps dying... it performs best when nothing else is plugged into the GPIO ports on the Pi but it still crashes.
So I plug it into a Seeeduino (smallest Arduino that I have and 3.3V GPIO rails) and it's solid... runs as long as you want... so that's why I want to use it just to get past this problem of the communication not working/being reliable. What I want is to have the IMU running "perpetually" as a separate thread and then I can just ping it when I need a sequence of data eg. start/end times.
So yeah... I'm already using the serial port for the TFmini-s lidar. If I can get SPI to work then great... assuming it has no error.
I will put the time in to learn it but yeah I'm starting from 0 for SPI, I haven't used it before.
I thought they swapped pins because they had some reason with whatever they were interfacing with but maybe you're right about some weird difficulty.
I did try an Arduino Nano I had lying around but didn't think about the 5V vs. 3.3V which yeah I'm pretty sure I killed the MPU6050 I plugged into it, thankfully I have more than one.
Maybe you can move the I2C interface from SERCOM0 to SERCOM4 (so you'd use D6 and D7).
I can look into this. I need to get to a basic point where I see bidirectional messaging working between the two devices (Pi and Seeeduino).
I'm quite sure you don't use the chip directly, so a link to the breakout board you're using would help.
Interesting because most MPU6050 boards are made for 5V, so that should work on the Nano but that's just the most common case.
So disconnect the MPU for the tests, use the pins the project supports and try the transfer on the SPI bus.
Keep in mind, SPI is completely different from an UART device. The slave can never initiate a communication and the master dictates how many bytes are transferred. It's definitely not a replacement for a missing UART interface.
BTW: Your XIAO can also be connected to the Raspberry Pi by the USB interface. There you get a serial communication as you're probably familiar with.
I'm not sure if this is "direct" enough? GY-521 MPU-6050 it's very common.
If I unplug everything from the GPIO ports, the loop I have sampling the IMU can run say 10+ times a few times, most times it'll run once before hitting an IO error. That's the problem.
The Seeeduino on the other hand, it just works, I can leave it running for minutes and it's running idk how many times a second.
Yeah I wouldn't mind the top-down communication I just need to periodically sample data from the IMU.
BTW: Your XIAO can also be connected to the Raspberry Pi by the USB interface.
I was thinking about this, would need a special cable/figure out how to do all that. It's a USB-C might be hard to make a little harness that's like 2-3 inches long at most. Unless you only need four wires.
Anyway I'll try some things in a couple hours will report back.
Well call me a quitter but I don't want to take the time to learn SPI right now.
I just switched to another sensor (MPU9250) while it is bigger, it actually works... I think my Bus 0 is busted somehow. I test it on Pigpio and it says none of the pins are messed up/passes the tests.
However when I run the bus check all addresses light up...
Anyway sorry I'm abandoning this, I'm just trying to work on other/higher level abstraction things and SPI is too difficult for me to get into right now.
I can provide more info if you are interested. I figured I would drop the subject since I am now just 100% RPi. Granted I am still facing problems. The MPU9250 does not show up on the bus scan on the first run. It shows up after the first run. The other issue is when I run the code to sample it, it fails every time for the first idk say 5 calls. I'll re-call the bus scan but then suddenly it'll start working. Once it's working it's solid... I can let it sample for minutes and it'll just go through the loop 10 times a second.
"Disconnect everything" by this I mean only one thing is plugged into the Pi as in the IMU itself. No other peripherals plugged into other GPIO pins are connected.
Regarding the cable I did not get a cable, it was just a pack of 3 of them (Seeeduinos). Anyway the cable I use to program them is the standard ones like to charge a phone... I can't stick that on my device which is built to be compact hence I said "3 inches long" or something like that.
I can provide a wiring diagram, although it's arguable anything I show will be negated by the physical device eg. crappy connections or something.
So a lazy fix at the moment is to write a startup sequence that runs the process I described above as a promise/async deal until the IMU is ready and then I can use it as expected. I have other startup processes anyway like centering the servos/pulling down the LED GPIO pin (since it usually leaks some power on boot).
