Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 14
Интересно, зачем нужно измерять в произвольные моменты?
Не может быть проще, преобразовывать непрерывно, а потом брать только нужные? Тогда АЦП может выполнять функцию защиты от перегрузок, и ДМА освободится. Как вариант.
Не может быть проще, преобразовывать непрерывно, а потом брать только нужные? Тогда АЦП может выполнять функцию защиты от перегрузок, и ДМА освободится. Как вариант.
Интересно, зачем нужно измерять в произвольные моменты?
Очень часто нужно измерять при наступлении какого-то события.
Не может быть проще, преобразовывать непрерывно, а потом брать только нужные?
Бывает очень критично энергопотребление.
Бывает очень критично энергопотребление.
Ну тут явно не тот случай :)
Очень часто нужно измерять при наступлении какого-то события.
В приведенной статье, эти события идут из таблицы через полновесный DMA2. Да и в целом, касательно управления BLDC, что может быть примером такого события?
В моем контроллере BLDC мотор управляется с помощью векторного управления. А из векторного управления известно, что всего может быть 8 возможных векторов тока (U+, W-, V+, U-, W+, V-, Zp, Zm). Применяя различную длительность этих векторов, можно задать любой угол и величину DQ тока. Также в моем контроллере, управление осуществляется с частотой 1кГц. Т.е. каждую миллисекунду должны быть измерены токи, которые текут в соответствующих фазах. А поскольку частота ШИМ составляет 20кГц, что в 20раз больше частоты управления, то в момент управления необходимо рассчитать точный момент измерения фазного тока и сделать несколько измерений к следующему моменту управления чтобы скорректировать D ток.
Очень интересно про togle on match, как Вы поняли, что АЦП преобразует не каждый раз?
Я делал led драйвер buck current mode на g071 и АЦП у меня работал в таком же режиме, capture compare был всегда один и тот же т.к. мне интересно было сэмплить после коммутации. И я ничего такого не замечал, но я не то чтобы прям проверял.
Ещё вопрос про HAL, почему вы не проверяете, что халовские функции возвращают? Или это просто для удобства восприятия кода?
>Очень интересно про togle on match, как Вы поняли, что АЦП преобразует не каждый раз?
Экспериментально, я видел, что в CCR записываются новые значения, но в массиве преобразованных значений не появлялись новые.
>Я делал led драйвер buck current mode на g071 и АЦП у меня работал в таком же режиме, capture compare был всегда один и тот же т.к. мне интересно было сэмплить после коммутации.
И я ничего такого не замечал, но я не то чтобы прям проверял.
У меня есть предположение, что если в параметре таймера External Trigger Conversion Edge установлен Trigger detection on the rising/failing edge флаг события по CCR устанавливается и сбрасывается только тогда, когда CNT и CCR равны. и единожды подняв флаг при первом сравнении и сделав преобразование, флаг так и остается висеть не смотря даже на то, что новое значение записано в CCR. Далее при работе в этом же режиме когда произойдет следующее сравнение таймер попытается снова поднять уже поднятый на предыдущем преобразовании флаг но в конечном итоге ADC не увидит никакого изменения флага и останется его ждать. А вот когда флаг при каждом сравнении меняет своё состояние всё работает нормально.
>Ещё вопрос про HAL, почему вы не проверяете, что халовские функции возвращают? Или это просто для удобства восприятия кода?
Это статья не про то, как правильно программировать и обходить различные ошибки. Кому будет необходимо — напишет, в этой же статье я описываю концепцию. Если будет слишком много воды, то самая главная суть описанная в статье будет расплывчата.
Экспериментально, я видел, что в CCR записываются новые значения, но в массиве преобразованных значений не появлялись новые.
>Я делал led драйвер buck current mode на g071 и АЦП у меня работал в таком же режиме, capture compare был всегда один и тот же т.к. мне интересно было сэмплить после коммутации.
И я ничего такого не замечал, но я не то чтобы прям проверял.
У меня есть предположение, что если в параметре таймера External Trigger Conversion Edge установлен Trigger detection on the rising/failing edge флаг события по CCR устанавливается и сбрасывается только тогда, когда CNT и CCR равны. и единожды подняв флаг при первом сравнении и сделав преобразование, флаг так и остается висеть не смотря даже на то, что новое значение записано в CCR. Далее при работе в этом же режиме когда произойдет следующее сравнение таймер попытается снова поднять уже поднятый на предыдущем преобразовании флаг но в конечном итоге ADC не увидит никакого изменения флага и останется его ждать. А вот когда флаг при каждом сравнении меняет своё состояние всё работает нормально.
>Ещё вопрос про HAL, почему вы не проверяете, что халовские функции возвращают? Или это просто для удобства восприятия кода?
Это статья не про то, как правильно программировать и обходить различные ошибки. Кому будет необходимо — напишет, в этой же статье я описываю концепцию. Если будет слишком много воды, то самая главная суть описанная в статье будет расплывчата.
Пишите ещё про BLDC. С удовольствием глянул бы на Ваш проект, если он есть в открытом доступе
Нет, его нет в открытом доступе. Но могу сказать, что я разрабатываю активную электромагнитную подвеску для автомобиля и уже есть некоторые успехи: рассчитал опытный образец линейного электромагнитного двигателя 1:10, изготовил его из металла, и реализовал на нем векторное управление с нуля. На данный момент достиг того времени, когда необходимо научить систему удерживать уровень в зависимости от колебаний основания.
Очень интересна тема управления такими моторами. Пишите ещё
Я очень внимательно слушал лекции Teaching Old Motors New Tricks — Part 1/2/3. И лучше чем там врядли мне удастся рассказать.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
АЦП преобразования в указанные моменты времени на STM32