Все нормально сделано в скетче. Сенсор BNO055 начинает "замешкиваться" при не правильной работе тактового генератора - когда конденсаторы в цепи кварца(22пф) установлены не той емкости.
В случае кривых конденсаторов в цепи кварца сенсор начинает эпизодически "замешкиваться" или постоянно? Если это на постоянной основе, то это не тот случай, о котором я говорю.
Поясню подробнее.
Я заметил, что после запуска компас немного поработав иногда (но не всегда) начинает ресетиться бесконечно по кругу. Начал разбираться, проанализировал код.
В скетче немца сделано следующее. Есть таймаут 5 секунд на "расчухивание" сенсора после старта системы (с момента загрузки ESP32). В этот период нулевые показания акселерометра (0,0,0), поступающие от сенсора, не воспринимаются как зависание сенсора и перегрузки не происходит. Однако, как только 5 секунд с момента последнего запуска (перезапуска) системы истекают, то первые же показания 0,0,0 от акселерометра воспринимаются как "завис" сенсора. При этом автор скетча ресетит сенсор дропая его ногу RESET, которая управляется с ноги GPIO18 модуля ESP32, а затем отправляет модуль ESP32 в ребут.
Начал копать дальше. Включил режим отладки, который немец благоразумно встроил в код. В этом режиме в компорт отсылаются полученные от сенсора данные, а также я временно отключил ребут всей системы. Что я обнаружил? Я обнаружил, что иногда (но не всегда) 5 секунд после запуска сенсору было мало чтобы начать выдавать реальные данные. И если он не успевал "очухаться" после ребута в течении 5 секунд, то скетч снова перегружал систему, и так по кругу, бесконечный ребут или несколько ребутов один за другим. И так могло происходить достаточно долго, "компас при этом как бы "зависал", не реагируя на внешние воздействия. Мало того, даже если сенсор успевал за 5 секунд с момента старта выйти на нормальные показания, когда эти 5 секунд заканчивались, то первые же показания 0,0,0 от акселерометра воспринимаются скетчем как "зависания" и снова вся система отправляется в ребут
Мне кажется, описываемые в этой теме некоторыми участниками "зависания" компаса связанны именно с этим.
По результатам наблюдений за отладочными данными было замечено, что в случаях, когда сенсор ловил магнитные помехи, или по питанию было что-то не так, сенсор начинал подтупливать и иногда выдавал 0,0,0. Иногда это были единичные 0,0,0 после которых продолжались нормальные показания. Но иногда сенсор реально впадал в "кому", причины впадения в эту "кому" я ни с чем не смог скоррелировать, но подозреваю виной тому слабое питание - на столе я запитал сенсор от платы ESP32, а она питается от USB. Причем, если сенсор все же впал в эту "кому", то ресет сенсора подачей низкого уровня на RESET толком не помогал, а помогал только ребут всей системы ESP32. Возможно, это глюк библиотек или неправильно подобранные задержки. Думаю, немец столкнулся с тем же самым и не придумал ничего лучше чем сделать этот ребут при получении от сенсора 0,0,0 по акселерометру.
Увидев такую картину я сделал следующие модификации скетча немца. Во-первых, я увеличил таймаут "невосприятия" 0,0,0 от акселерометра. Также я ввел игнорирование единичных показаний 0,0,0 от акселератора сенсора, если они проскакивают эпизодически, перемежаясь нормальными посылами. И только когда сенсор начинает слать 0,0,0 подряд в течении заданного периода, только тогда я отправляю весь компас в ребут. И только один ребут, поскольку увеличенный таймаут ожидания сенсора после ребута позволяет сенсору гарантированно успеть проснуться . Итого компас при зависании сенсора пропадает со связи с эхолотом совсем ненадолго, только на время одного ребута, а это около 2-3 секунд.
Как-то так.
