Comments 23
Эт - прямо вот хорошо! Отложил в закладки - мало ли когда понадобится!
Единственное в чем наверное разочарую - компилятор скорее всего вырезал ваши трюки с кешированием переменных при расчете. Там конечно надо посмотреть ассемблерный листинг, но в большинстве случаев оно прекрасно видит ситуации когда идет цепочка присваиваний 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 введен в примитивные драйверы из-за отсутствия нормального регулятора
Отлично сделано!
Но ведь ШИМ остался, и помехи тоже остались. Чтобы от помех избавиться, имеет смысл на выход выводить уже сглаженный сигнал. Или хотя-бы фильтр поставить, чтобы фронты немного сгладить.
Я ещë не очень понял, зачем USB- UART. Выбранный мк и без него может по USB получить прошивку.
И защита лишней не бывает: входы оптронов чувствительны ко всему, особенно при переполюсовке.
Спасибо!
1) Я стремился не избавиться от помех, а нормировать их по частоте, чтобы они нормально фильтровались.
2) Да , я знал про USB DFU, но у меня была библиотека Modbus RTU написанная под USART и я хотел использовать её.
3) Че то я не замечал выгорания оптронов от переполюсовки никогда. Резистор их всегда успешно спасал.
Че то я не замечал выгорания оптронов от переполюсовки никогда. Резистор их всегда успешно спасал.
Вам везёт, наверное. Но обычно светодиоды очень боятся статического разряда. Если бы они где-то в середине платы стояли - не страшно. А прямо на интерфейсе - без защиты от высокого обратного напряжения им уже не очень хорошо будет.
Особенно "спасёт" диод конденсатор, включённый параллельно токоограничивающему резистору :)
Странно. У меня прямо противоположный опыт. В моём понимании светодиод это неубиваемый стабилитрон с побочным эффектом в виде свечения)) Шучу конечно, но у меня светодиод всегда был самой выносливой деталью. Вот лазерный диод неженка, это да)
Совсем недавно STM32 исчезали с российского рынка, потом появились по удесятеренной цене, потом цена снова стала адекватной. Чтобы не зависеть от европриборов, используйте чайнаприборы. Семейство сh32. Раз уж все равно пишете код и тексты с пом. китайских нейросетей (это одобряю).
Мои разработки выпускаются мелкими сериями по 5-50 штук под заказ. На такое и оригинальные stm32 найдутся на скаладах чип и дипа по 300р/шт.
Переход на ту же народную CH32F103 или CH32V307 на RISC-V сейчас и правда выглядит за самый очевидный и бюджетный шаг.
Однако, если мы думаем за долгосрочную стабильность и безопасность (ради чего всё и начиналось), имеет смысл посмотреть также в сторону отечественных микроконтроллеров. И вот почему:
Прямая замена пин-в-пин. Вместо китайских клонов есть смысл глянуть на тот же Миландр. Например, их серия К1986ВЕ91Т (Cortex-M0) или более мощные К1986ВЕ92ФИ (Cortex-M3) — с них выйдет отличная замена старым STM32F103. Под них уже есть горы готового софта, и не надо мучаться с китайскими библиотеками.
Свой RISC-V без сюрпризов. Если вам так сильно приглянулся RISC-V в чипах CH32V, то у нас сейчас активно продвигается проект “Амур” (MIK32) от Микрона. Для простых задач автоматизации и датчиков он подходит идеально, а логистика по нему идет полностью внутри страны, без таможен и банковских блокировок.
Техническая поддержка на родном языке. Архитектура CH32 хорошая, но китайская документация… У отечественных вендоров инженеры ответят сразу на понятном языке, вышлют нормальные схемы и помогут переписать код под проект.
Рост экосистемы. Да, наши чипы раньше стоили сильно дороже. Но сейчас, когда пошли большие тиражи, всё поменялось в лучшую сторону.
Драйвер шагового двигателя с векторным управлением