Программирование STM32: Работа с датчиком MPU6050. Using STM32 I2C to read data from MPU6050 

Ого, интересный проект! Только есть пара замечаний: Первое замечание: Отправка данных по i2c относительно медленная операция - камень работает на 24MHz, т.е. за 1ms, грубо говоря, процессор выполняет 24к инструкций (на деле меньше из-за того, что инструкции выполняются дольше чем за 1 такт, но порядок оценить хватит). В то же время, при стандартной частоте шины i2c в 100кбит/с за 1ms отправится 100 бит данных. В функции MPU6050_GgetAllData считывается 14 байт + на шину сначала отправляется адрес микросхемы, что ещё 1 байт. В итоге, по шине придётся перегнать 120 бит данных, что займёт примерно 1.2 ms не учитывая накладные расходы. Во время считывания данных по i2c камень тупо ждёт в цикле пока данные не отправятся => на 1.2 ms камень впадает в ступор, хотя за это время мог выполнить примерно 28к каких-нибудь полезных инструкций. Но это не самое страшное, хуже всего, что все эти 1.2 ms камень проводит внутри прерывания HAL_SYSTICK_Callback, таким образом блокируя все остальные прерывания (HAL_SYSTICK_Callback это просто враппер над SysTick, а SysTick - это прерывание ядра Cortex, оно имеет приоритет выше, чем приоритет любой периферии от STM), в том числе и сам HAL_SYSTICK_Callback, т.к. HAL_SYSTICK_Callback вызывается 1 раз в 1ms, а чтение с i2c занимает 1.2 ms. Это очень грубая ошибка, которая может вызвать серьёзные проблемы в самых неожиданных местах, особенно если говорить об авиации. Золотое правило программирования под МК(микроконтроллер) - внутри прерывания нельзя выполнять длительные операции. Т.е. чтение из сенсора внутри HAL_SYSTICK_Callback выполнять нельзя. Правильный путь делать чтение из гироскопа внутри главного цикла с использованием delay() или аналога для формирования задержки между считыванием показаний. Во время delay() процессор также впустую крутится в цикле, но уже способен моментально реагировать на прерывания. Бывает так, что использование delay() также не допустимо. На этот счёт есть несколько решений. Поступают обычно так: создаётся где-нибудь uint32_t или uint64_t счётчик, назовём его curr, при старте МК curr инициализируется нолём. В прерывании HAL_SYSTICK_Callback curr увеличивается на единицу (т.е. фактически в счётчике хранится число миллисекунд, прошедших со старта работы МК). Также создаётся дополнительная переменная, в которую можно положить значение curr, назовём её prev. Перед главным циклом в prev записывается значение curr. В главном цикле из curr вычитается prev - это число миллисекунд, прошедшее после обновления prev. Ждём пока разница между prev и curr не будет равна нужной нам задержке, обновляем prev, делаем то что нам нужно и так по кругу. Допустим, нам нужно считать значение из сенсора 50 раз в секунду, или каждые 20ms, тогда код чтения будет выглядеть следующим образом: volatile uint32_t curr; int main(void) { uint32_t prev = curr; while(1) { if (curr - prev >= 20) { prev = curr; // payload ReadSenssor(); } } } void HAL_SYSTICK_Callback(void) { curr++; } В Arduino IDE есть показательный пример на эту тему: Digital->BlinkWithoutDelay. Переменную curr необходимо пометить ключевым словом volatile, иначе компилятор подумает что curr никогда не обновляется и тупо выкинет весь код из if (curr - prev >= 20). В stm32 есть замечательная штука, называется dma, позволяет взаимодействовать периферии с оперативкой напрямую, в обход процессора. Т.е. можно просто дать задание на перекачку данных, и как только мы перегнали все 14 байт с гироскопа, сработает прерывание и уже в нём можно обработать результат. Таким образом можно по кд считывать данные с гироскопа, примерно раз в 1.5ms или 666 раз в секунду (можно ещё увеличить в настройках скорость i2c в 4 раза и обрабатывать показания 2.5к раз в секунду. Главное, чтобы сам гироскоп успевал выдавать показания с такой скоростью). При этом ресурсы процессора будут использоваться по минимуму, главный цикл программы будет просто пустой, вся обработка будет производится в прерываниях. Откровенно говоря, подход разработки под МК с использованием прерываний немного хитрее, чем может показаться на первый взгляд, приходится контролировать очень много тонких моментов, и чем больше проект - тем больше моментов. И если проект большой, имеет смысл глянуть в сторону FreeRTOS и писать код в более естественном стиле. Ресурсов у данного МК достаточно, оперативки маловато конечно, но если не слишком много места выделять под кучу или вообще без динамической памяти обойтись, то хватит с головой даже для автопилота. На крайняк использовать stm32f103c8t6 за 2 бакса с али, там оперативки 20кб, с ним хоть ракету в космос запускай :) Второе замечание касается оформления кода: хорошая практика - прятать реализацию функций MPU6050_Init, MPU6050_Calibrate, MPU6050_GgetAllData, MPU6050_GgetAllData в отдельный файлик, например, MPU6050.c, а в main.c или в любом другом месте просто дёргать API этих функций. Т.к. i2c актуален только в рамках работы с MPU6050, инициализацию I2C можно перенести из main() в MPU6050_Init(). Соответственно, функции I2C_ReadBuffer, I2C_WriteBuffer также перенести в MPU6050.c и пометить ключевым словом static, таким образом изолируя модуль нашей программы и унифицируя интерфейс работы с MPU6050. По сути мы создадим свой HAL для работы с MPU6050, если сменится микроконтроллер, нам нужно будет немного подправить код внутри MPU6050.c, не затрагивая всё остальное. Такие действия сильно помогут в будущем, когда проект разрастётся. Если планируется на одну шину i2c вешать несколько устройств (например, гироскоп + барометр + компас), то функции I2C_ReadBuffer, I2C_WriteBuffer лучше вынести в отдельную библиотеку и дёргать эти функции в драйверах гироскопа/барометра/компаса, но нужно следить за тем, чтобы одновременно разные драйверы в i2c не ломились, иначе на шине получится каша. Если возникнут вопросы - могу проконсультировать. С удовольствием буду следить за развитием проекта!

Вот это отличная серия уроков будет. В закладочки.

Крутота!!!

Вот то что нужно.+++ за видос + подписка.

26:29 могли бы Вы рассказать как получены эти формулы? И ещё. В следующем видео, чтобы определять угол рыскания, Вы пользуетесь показаниями магнитометра. Однако для пересчёта крена и тангажа относительно рыскания, вы пользуетесь показаниями угла рыскания с гироскопа. Почему для пересчёта тангажа и крена можно использовать рыскание с гироскопа, а для определения самого рыскания Вы используете магнитометр?

Здравствуйте! Как я вижу вы пишите код в VS code. Пробовал прикрутить компилятор и отладчик к QTCreator, но путного ничего не вышло. Не могли бы вы поделиться мануалом/статьей с инструкцией по подключению и работе в VS code под stm32? Или вы все делали опираясь на свои знания?

Класное видео, спасибо! Но что такое рысканье?

Ну и как продолжение было? :)) У меня уже летает и квадрик и крыло правда перешел с AVR на STM32F103.

Добрый день, не могли бы Вы предоставить исходный код? Спасибо.

can you share your source code?

Можно шрифт по максимому, на смартфоне не видно. Я за то что бы использовать всю полезную область для предостовления информации...

Есть готовые значительно более компактные решения на F3/4 от коптеров и самолетов, прошивка с открытым исходным кодом

Здравствуйте. Ссылка на код никуда не ведет.

Не понимаю как код компилится, если в функциях есть куча неиницилизованных переменных

Вот то что нужно.+++ за видос + подписка.