Добрый день, столкнулся с проблемой в одном из своих проектов. Решил исключить все остальное, чтобы точно убедиться в источнике этой проблемы и вот, что вышло в итоге...
В STM32CubeMx создаю пустой проект для STM32F103, активирую только таймер TIM3, канал Channel4, в режиме генерации PWM-сигнала. Частота тактирования таймера 48 МГц, на таких настройках получаю 300 Гц и скважность 50%. Это все работает хорошо, проверяю осциллографом. Проблемы начинаются при дальнейшем углублении...
Изначально у меня цель - изменять период генерируемого PWM-сигнала в процессе работы устройства. Изменять период планирую прямой записью в регистр ARR, плюс в регистр CCR4, чтобы сохранить скважность 50%:
void HAL_TIM_PeriodElapsedCallback(TIM_HandleTypeDef *htim)
{
if (htim == &htim3)
{
TIM3->ARR = new_period;
TIM3->CCR4 = new_period / 2;
}
}
Все это действо добавил в прерывание по окончанию периода - самый безопасный момент для изменения настроек таймера. Значение переменной new_period точно меняется - вижу в отладчике. При этом также вижу, что реальный период сигнала не реагирует - снова подключаю отладчик, и бинго! Программа не попадает в прерывание, хотя в STM32CubeMx включено:
P. S. Вот настройки таймера:
Добрый день!
Cube при запуске ШИМ функцией HAL_TIM_PWM_Start_IT() включает только прерывания при срабатывании схемы сравнения:
case TIM_CHANNEL_1:
{
/* Enable the TIM Capture/Compare 1 interrupt */
__HAL_TIM_ENABLE_IT(htim, TIM_IT_CC1);
break;
}
case TIM_CHANNEL_2:
{
/* Enable the TIM Capture/Compare 2 interrupt */
__HAL_TIM_ENABLE_IT(htim, TIM_IT_CC2);
break;
}
case TIM_CHANNEL_3:
{
/* Enable the TIM Capture/Compare 3 interrupt */
__HAL_TIM_ENABLE_IT(htim, TIM_IT_CC3);
break;
}
case TIM_CHANNEL_4:
{
/* Enable the TIM Capture/Compare 4 interrupt */
__HAL_TIM_ENABLE_IT(htim, TIM_IT_CC4);
break;
}
Уж не знаю, баг ли это или тактическая задумка, возможный путь решения - добавить:
__HAL_TIM_ENABLE_IT(&htim3, TIM_IT_UPDATE);
Заработало! Три дня убил не это... Нет слов, спасибо!
Вот знал же про эту особенность и тему читал, но все равно напоролся на эти же грабли, пока не вспомнил, в чем тут дело 😆
Мда. Без HAL всё проще. Сам напортачил, сам исправил.
Я так понимаю, есть 2 лагеря любителей STM. Один на HAL, другие на CMSIS. Сам начал изучение STM на CMSIS. Мне интересно, что сложнее, изучить функции ХАЛа или назначение битов регистров и по ним писать на CMSIS? Согласен с Эдуардом, что на CMSIS держишь почти полный контроль над программой, если понимаешь, что пишешь, оперируя регистрами и битами. Но ведь в функциях ХАЛа тоже устанавливаются/сбрасываются определённые биты, то есть их тоже нужно знать. Или там по названию функции понимаешь, что функция делает? Согласен также, что в ХАЛЕ есть защита от дурака, разные проверки, но в СМСИС в относительно НЕогромных проектах тоже можно правильно без ошибок написать. Или кому как, кто как привык?
@aleksej_bajdin По мне так во всем должен быть баланс в целом по жизни, в том числе и в этом вопросе. Я абсолютно никакой катастрофы в использовании HAL не вижу. Но с другой стороны это ни в коей мере не отменяет того, что должно быть понимание как все работает на низких уровнях. Кроме того, в том случае, если для конкретной задачи минусы HAL начинают оказывать влияние на работу, то конкретные участки, либо части, стоит переделать, либо вообще для этого проекта отказаться от HAL. А минусов тут основных два - быстродействие и объем. Причем эти минусы не стали никаким откровением, неожиданностью или сюрпризом, они логично вытекают из концепции библиотеки в целом, и было еще на этапе создания HAL очевидно, что эти проблемы будут.
Это уже какие-то наши "менталитетные" особенности - куда не зайди на русскоязычный форум, по сути задаваемого вопроса ноль информации, но по 10 страниц о том, как HAL плоха, а все, кто ее используют идиоты. Видимо таким образом интернет-знатоки просто изливают желчь и свое недовольство в виде критики всего и вся.
Да, у HAL есть минусы, в определенных случаях они становятся значительными, просто нужно это понимать и учитывать. Минусов не лишено ничто и не лишен никто.
А вот Эдуард как раз не из этого лагеря критиков. Он адекватно понимает, в чем ограничения HAL, соответственно, принял решение, что это его не устраивает и вместо того, чтобы налево и направо критику раскидывать, сел и занялся своей собственной библиотекой и добился отличных результатов.
Короче, резюме мое лично такое) Как использование HAL не от меняет необходимости понимать что и как работает, так и в самом этом использовании HAL нет ничего драматичного. В обоих случаях есть и свои плюсы, и свои минусы.
Если честно, не было бы HAL, я бы никогда не разобрался бы с I2C.
Это мрак какой то. На разных ядрах, он реализован по разному. И то, что я сделал для STM32F4xx не подойдёт для других.
И HAL я то же использовал и немного использую, особенно если нужно что то простое и быстро. Так же, если что то не получается или понять не могу, я делаю это на HAL. Если заработало, я начинаю смотреть как там это реализовано и ищу ошибки у себя.
Мне интересно, что сложнее, изучить функции ХАЛа или назначение битов регистров и по ним писать на CMSIS?
Мне проще на CMSIS. Потому что я начал изучение микропроцессоров ещё в 1983 году. А тогда языков высокого уровня, например для КР580ВМ80, особо то и не было.
Все языки высокого уровня использовались в основном в математических расчётах. Поэтому я привык программировать микропроцессоры, а позже и микроконтроллеры на Ассемблере, а там нужно знать всю архитектуру МК и его регистры.
