I’ve got a couple of PicoDev VL53L1X boards and hooked one up via QUIIC to an Adafruit QTY-PY ESP32-S2 board (I also tried an Adafruit ESP32-S3TFT and a Sparkfun Artemis Openlog board) and tried several of the examples from both the Sparkfun VL53L1X library and the Adafruit VL53L1X library. Can’t get anything to work. I can scan the I2C addresses and get a 0x29 for the VL53L1X, which is correct, but that’s it. Neither of them will initialise and of course, in that state they won’t give any reading. I tried setting the I2C address in the code, just to make sure it was trying to communicate with the correct device but that made no difference.
I checked the schematics of both the Picodev VL53L1X board and the equivalent Sparkfun board, just to make sure the I2C was setup the same and it is. I was expecting to be able to just connect and it would just work, like most other quiic setups I’ve played with.
Am I missing something?
Solved! Turns out it was answering on the secondary I2C port for some reason.
What a strange bug! So your QT-Py was writing on one port, and getting messages back on another? Or have I misinterpreted you?
It was actually only using the second port for some reason. Never seen this before and didn’t find it until I ran the I2C scan test prog.
BTW, do you know how to get an ESP32-S3 back into normal bootloading mode? I have one which suddenly required that I put it into bootloading mode in order to load from the Arduino IDE, it then selects a different com port for loading then releases it and goes back to the other com port for serial coms. Odd, as it was fine the first few times.
Heads up, when you reply via email your signature gets attached with all of your details!
Would it be possible to send through a photo of how you have everything setup and link the firmware you are running(Arduino vs a Pythonic language, and the version)?
This sounds like a fuse or pin is being pulled into a different boot mode - taking a look at device manager on boot might shed some light. I havent had a deep look at the S2, there looks to be atleast 2 USB modes.
To solve it I would try a reflash
Let us know how you go!
I’m using Arduino:
CLI Version: 0.28.0 [06fb1909]
I have a feeling the I2C issue may be in one of the libraries. My Arduino environment is a bit of a mess as I just randomly installed libraries back when I started using it. I probably should wipe it all clean and start from scratch. I used to do most of my embedded stuff in C but that seems a bit old fashioned nowadays, python seems to be gaining popularity but I’m not sure my tiny brainlett could handle learning yet another language…
A bit of research about the ESP32-S3 tells me that I will have to manually put it into boot mode every time as it’s not fully supported by the Arduino IDE yet, or something like that. Not the end of the world but a bit tedious.
As someone who started with Arduino, built a large project in MicroPython, and is now starting with bare-metal C embedded stuff on ARM and AVR chips, I’m also unsure where to go:
- Python is definitely easier to “slap together” stuff with. A library from here, a breakout board from there, I found it really quick to get a project going, but certain things really frustrated me.
I could never get my head around Python’s handling of strings, bytes, bytestrings? arrays etc. I missed the simplicity of C’s
char[x]. The character is just a number, and a string is just an array of numbers.
- C is obviously always going to be faster and more deterministic when it comes to timing. You can disassemble your bytecode and see the instructions run on the processor, then add up the cycle counts each one takes! I’ve never had to develop something that needs that, but you really can look all the way down if you want to. You’re closer to the hardware, and can develop for anything you can find a toolchain for.
An interesting example of the use cases for both is the Klipper project. It features a python “master” application running on a full OS that uses the insane speed of a Pi or PC to crunch numbers on what a 3D printer should do next, then hands over a string of commands to a microcontroller running C. to do all the timing-critical stuff. Both have their strengths, The python application can have features added to it faster, but wouldn’t be good enough to coordinate 4+ stepper drivers with perfect timing precision.
Never used an ESP32, but I’ve heard the Espressif IDE isn’t bad, and using that and an ESP-PROG might mean a smoother development experience.