Обновить

Драйвер шагового двигателя с векторным управлением

Уровень сложностиСложный
Время на прочтение27 мин
Охват и читатели11K
Всего голосов 41: ↑41 и ↓0+52
Комментарии19

Комментарии 19

Эт - прямо вот хорошо! Отложил в закладки - мало ли когда понадобится!

Единственное в чем наверное разочарую - компилятор скорее всего вырезал ваши трюки с кешированием переменных при расчете. Там конечно надо посмотреть ассемблерный листинг, но в большинстве случаев оно прекрасно видит ситуации когда идет цепочка присваиваний a->b->c и помечает 'b' как no-effect. Ну и дальше вообще убирает его из внутреннего представления программы. Раньше в чистых Сях был допустим трюк со словом 'register' - который рекомендовал компилятору выделить регистр для хранения локальной переменной в блоке. Но работало это не всегда - и в современных процессорах обычно компилятор распределяет регистры лучше человека. Если вы все-таки хотите туда вмешаться - то надо смотреть не-портабельные расширения платформы или компилятора (прагмы, аттрибуты переменных и проч).

Если сейчас набегут варвары, которые будут кричать что ваша поделка не имеет смысла и ее изготовление обошлось дороже покупки готовой в Китае с доставкой - гоните их в сад! Умение повторить - это минимальный уровень владения технологией. Без этого нет и не будет следующих шагов: ни улучшения/адаптации, ни разработки нового.

Удачи!

Спасибо. Оптимизации точно повлияли. Первая версия алгоритма работала примерно в 3-4 раза медленнее. Я мониторил начало и конец прерывания по осциллографу. Не могу утверждать, что ни одна из оптимизаций не была вырезана компилятором, но что-то явно помогло.

А при сборке в параметрах компилятора какая оптимизация задана?

Я скорее всего в дебаге шил с флагом -00.

Ну вот поэтому ручные оптимизации помогают: просто потому что с -o0 компилер собирает "как есть"... А так начиная с -o2 уже руками чаще всего лучше не сделаешь (если это не какие-то специфические случаи)

А в чем вообще смысл шить управление силовой электроникой в дебаге без оптимизаций ? Все равно же не имеете роскоши подключиться отладчиком, остановиться, почитать переменные, и т.д. - система реального времени под отладчиком ведет себя совершенно не так как без него... Я содрал для себя подход у ракетчиков - система пишет в отдельную микросхему (мне нравится FRAM) телеметрию по кругу. После рабочего цикла или аварии - читаем микросхему, анализируем логи... Но сборка кода ведется с O2 или Os - иначе сколько раз было что с O0 - работает, с O2 - падает из-за какой-то невнимательности с указателями или UB. Если не уверены - смотрим ассемблер (к сожалению современный C++ довели до того, что без чтения ассемблера - обойтись сложно).

У меня не C++ , а C, ну не суть. Оптимизации компилятора меня вообще не волнуют, я обычно всё в дебаге шью с -o0 и ни разу не было проблем. Отлаживать можно через Cube Monitor очень удобно(не в этом проекте). Если нужна отладка до микросекунд, то можно выводить цифровые сигналы на логический анализатор или аналоговые на осциллограф. Вроде костыли, а большего и не нужно.

Воспоминание разблокировано. Серьезность темы электропривода я понял в момент, когда керамический конденсатор размером около 1210 прожег в плате такую дыру, что можно было палец просунуть. После этого я тоже начал считать импульсные токи)

Да, в этом что-то есть... У меня похожее было: неправильно посчитанный дроссель BUCK-конвертера насыщался и у электролитического конденсатора ноги грелись почти до выпаивания... Нагреть конденсатор это видимо какое-то становление начинающего электроника... Нагреть сердечник дросселя при холодной обмотке в принципе тоже :D

У меня так однажды мелкий дисковый конденсатор на 0.1мкф отгорел от драйвера TB6600HG

Компаратор сравнивает падение напряжения на шунте с опорным напряжением и отключает ключи на фиксированный интервал времени.
Мало того, что такое решение просто некрасивое, оно еще и сомнительное с точки зрения электромагнитной совместимости.

Это оптимальное решение для драйверов слабых двигателей. Недостатком может быть сниженная точность управления током на микрошаге, и акустический шум.

так называемый Fast Decay и Low Decay режим.

А в вашем проекте это не используется? Ключи в фазе PWM-off просто закрываются, и остаются закрыты до момента PWM-on?

У меня симметричный ШИМ просто переключает диагональные ключи. Получается типа Fast Decay, но с фиксированной частотой ШИМ и аккуратной регулировкой с помощью ПИ регулятора. По обмотке всегда течёт ток либо в одном, либо в другом направлении. Это абсолютно правильно и нормально. Костыль с Low Decay введен в примитивные драйверы из-за отсутствия нормального регулятора

Я так понял, что использование разных режимов decay актуально когда ток регулируется по синусоиде, и для разных фаз (фаза увеличения тока, и фаза уменьшения тока) оптимальным будет разный режим decay. Это не связано только лишь с использованием fixed off-time.

Я знаю, что это для этого сделано, но это не необходимо при наличии нормального ПИ регулятора и ШИМ. ШИМ с регулятором работает на порядок лучше

Отлично сделано!

Но ведь ШИМ остался, и помехи тоже остались. Чтобы от помех избавиться, имеет смысл на выход выводить уже сглаженный сигнал. Или хотя-бы фильтр поставить, чтобы фронты немного сгладить.

Я ещë не очень понял, зачем USB- UART. Выбранный мк и без него может по USB получить прошивку.

И защита лишней не бывает: входы оптронов чувствительны ко всему, особенно при переполюсовке.

Спасибо!

1) Я стремился не избавиться от помех, а нормировать их по частоте, чтобы они нормально фильтровались.

2) Да , я знал про USB DFU, но у меня была библиотека Modbus RTU написанная под USART и я хотел использовать её.

3) Че то я не замечал выгорания оптронов от переполюсовки никогда. Резистор их всегда успешно спасал.

Че то я не замечал выгорания оптронов от переполюсовки никогда. Резистор их всегда успешно спасал.

Вам везёт, наверное. Но обычно светодиоды очень боятся статического разряда. Если бы они где-то в середине платы стояли - не страшно. А прямо на интерфейсе - без защиты от высокого обратного напряжения им уже не очень хорошо будет.

Особенно "спасёт" диод конденсатор, включённый параллельно токоограничивающему резистору :)

Странно. У меня прямо противоположный опыт. В моём понимании светодиод это неубиваемый стабилитрон с побочным эффектом в виде свечения)) Шучу конечно, но у меня светодиод всегда был самой выносливой деталью. Вот лазерный диод неженка, это да)

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации