I need to be updating the screen, the GPS, the IMU, the SD card, receiving network data, etc. It's that 2nd mode, interrupt-driven tasks, is really helpful for highly async apps like mine. When you trigger an interrupt, it's run loop is interrupted and it acts on your request.
No management needed.Ģ) Interrupt driven tasks - You can spawn an infinite task that uses zero cpu and does not block. A FreeRTOS task is basically a multi-threaded process but since its implemented in hardware it has some cool features.ġ) One-off tasks - You can spawn a task to run a function and after the function exits, it dies. Gammaburst Posts: 651 Joined: Thu 12:06 pmĮSP32 runs FreeRTOS and provides all sorts of hardware goodness. Bosch messed-up the Euler angles math, so if you plan to tilt the sensor more than about 20 degrees, read the quaternion instead. The BNO055 datasheet is lacking, frustrating. Furthermore, you may need to apply additional pullup to SDA to speed-up its rise-time to help overcome an occasional bus timing problem caused by the BNO when it exits its clock-stretching cycle. Also, some broken microcontrollers don't support I2C clock-stretching. The BNO055 uses I2C clock-stretching, so some byte transfers take much longer than you may expect. Sorry to hear you went down that rabbit hole. The Bosch BNO055 library is a monstrosity.
My minimal implementation: reset it, wait 800ms, write desired operating mode to one register, wait 10ms, then periodically read desired data registers.
What is the "Task" software you're using? If it's multi-threading, be sure you understand thread-safe techniques. But it's a cool piece of kit and the missing link in my project. This device feels very 'greedy' on the I2C bus and seems to have a lot of assumptions about its run environment that I don't usually find in I2C devices.
if anyone can figure out how to read IMU data in a callback it would be slick, I hate using loop() (once you go Tasks, you never want to go back.).
While not perfect, it's faster than a human can press the button that needs the data so it should be ok for now.īut. My callback task reads out of the structure. So I instantiated a second Wire interface dedicated to the BNO and passed it into the constructor, which solved the basic loop i2C collision but not the callback BNO access.įor now, I have a basic loop sampling at 10hz to get my Euler data to a global data structure on that regular cadence. Any IMU access in Bosch or Adafruit freezes the task.Įven in a basic loop configuration, TwoWire crashes regularly with what I assume is I2C contention with the GPS at the default bus speed ( I can not bump to 400, it stops my GPS from registering). I also tried the Bosch libraries which are even worse, although they do actually communicate in my Task for non-IMU tasks (ex: Temp or firmware revision). Yes, I run other I2C intensive tasks (ex: RTK GPS updates and reads, OLED etc).