А счёт разрешили?
Неужели так сложно написать работу с таймерами на CMSIS? Тогда бы сразу было видно, что сделано, а что нет. Вы хоть мурзилку на ХАЛ прочитали, чтобы понимать, что нужно делать?

я же написал: счетчик меняется, счет разрешил.
как мне кажется, всё по мурзилке я сделал. но, видимо, не всё... а что - не могу понять.

к слову: с USART, например, я никуда не лез - оно заработало сразу после галочки в кубе... а с таймерами нужен бубен, а у меня он порвался...

Добавлено after 30 minutes 14 seconds:
Ничего не понимаю.

По пунктам из журнала "мурзилка для начинающих":

1. Убедитесь, что прерывание TIM6 зарегистрировано в контроллере прерываний (NVIC)  - убедился, зарегистрировано (в отладчике смотрел бит).

2. Значение PSC (предделитель) правильно рассчитано для достижения нужной частоты - как-то рассчитано.

3. Значение ARR (автоматическая перезагрузка) также правильно рассчитано - как-то рассчитано.

4. Таймер запущен (TIMx->CR1 |= TIM_CR1_CEN) - запущен (в отладчике смотрел).

5. Убедитесь, что бит прерывания в регистре TIMx->DIER установлен - убедился, стоит (в отладчике смотрел).

6.  Убедитесь, что приоритет прерывания TIM6 установлен корректно и не ниже приоритета других активных прерываний - установка есть, приоритет 0 (по умолчанию), пробовал ставить 2 - результат тот же.

7. Убедитесь, что в файле stm32xxxx_it.c есть правильный обработчик прерывания для TIM6 - есть, куб сгенерировал, туда и не попадаю!

8. Убедитесь, что TIM6 правильно подключено к тактовой шине - куб генерировал, в регистре RCC->APB1ENR установлен RCC_APB1ENR_TIM6EN (смотрел в отладчике)

9. Если вы используете HAL-библиотеку, убедитесь, что вы правильно инициализируете TIM6 через функцию HAL_TIM_Base_Init() - ну, само собой, использую, и все эти вызовы делает куб.

10. Убедитесь, что флаг прерывания (TIMx->SR) правильно установлен - установлен, отладчик подтвердил.

11. Проверьте приоритеты всех прерываний - ну, куб все делал по умолчанию, может. оно и не правильно, но я пока не могу понять, что не так, если не так. приоритет - см. выше, делал и 0 и 2, безрезультатно.

И какого, извините, корнеплода, этому прерыванию не хватает?!

? Ну тогда не знаю...

у меня HAL_TIM_Base_Start(&htim6);
...

Добавлено after 2 minutes 17 seconds:

Б**Ь!!!
это оно самое и есть! Ну кто бы мог подумать, что при "галочном" стиле подготовки периферии надо вручную ПО_РАЗНОМУ включать таймер для прерываний и без них?!

Добавлено after 1 minute 2 seconds:
отладчик-то я сотрел до вызова этой функции... видимо, она выключает потом прерывания...

В продаже новые LED-драйверы XLC компании MEAN WELL с диммингом нового поколения

Компания MEAN WELL пополнила ассортимент своей широкой линейки светодиодных драйверов новым семейством XLC для внутреннего освещения. Главное отличие – поддержка широкого спектра проводных и беспроводных технологий диммирования. Новинки представлены в MEANWELL.market моделями с мощностями 25 Вт, 40 Вт и 60 Вт. В линейке есть модели, работающие как в режиме стабилизации тока (СС), так и в режиме стабилизации напряжения (CV) значением 12, 24 и 48 В.

Подробнее>>

Сразу видно человека, не читающего документацию. Это всё написано в UM на HAL каждой линейки. Если бы вы читали доки от СТМ, то знали бы, что для каждого режима работы таймера есть свои пуск и стоп. И даже думать не надо, достаточно просто открыть и прочитать.

Спойлер

Код:

57.2.17 HAL_TIM_Base_Start..................................................................... 823
57.2.18 HAL_TIM_Base_Stop..................................................................... 823
57.2.19 HAL_TIM_Base_Start_IT ............................................................... 823
57.2.20 HAL_TIM_Base_Stop_IT................................................................ 824
57.2.21 HAL_TIM_Base_Start_DMA .......................................................... 824
57.2.22 HAL_TIM_Base_Stop_DMA........................................................... 824
...
57.2.27 HAL_TIM_OC_Start ....................................................................... 825
57.2.28 HAL_TIM_OC_Stop........................................................................ 825
57.2.29 HAL_TIM_OC_Start_IT .................................................................. 826
57.2.30 HAL_TIM_OC_Stop_IT .................................................................. 826
57.2.31 HAL_TIM_OC_Start_DMA ............................................................. 826
57.2.32 HAL_TIM_OC_Stop_DMA ............................................................. 827
...
57.2.37 HAL_TIM_PWM_Start.................................................................... 828
57.2.38 HAL_TIM_PWM_Stop .................................................................... 828
57.2.39 HAL_TIM_PWM_Start_IT............................................................... 828
57.2.40 HAL_TIM_PWM_Stop_IT............................................................... 829
57.2.41 HAL_TIM_PWM_Start_DMA.......................................................... 829
57.2.42 HAL_TIM_PWM_Stop_DMA .......................................................... 829
...
57.2.47 HAL_TIM_IC_Start ......................................................................... 830
57.2.48 HAL_TIM_IC_Stop ......................................................................... 830
57.2.49 HAL_TIM_IC_Start_IT.................................................................... 831
57.2.50 HAL_TIM_IC_Stop_IT .................................................................... 831
57.2.51 HAL_TIM_IC_Start_DMA ............................................................... 831
57.2.52 HAL_TIM_IC_Stop_DMA ............................................................... 832
...
57.2.57 HAL_TIM_OnePulse_Start............................................................. 833
57.2.58 HAL_TIM_OnePulse_Stop ............................................................. 833
57.2.59 HAL_TIM_OnePulse_Start_IT........................................................ 833
57.2.60 HAL_TIM_OnePulse_Stop_IT........................................................ 834
...
и далее пос списку старт-стоп

если бы я читал все эти простыни, то сегодня я бы еще читал.
а так я уже RTOS запустил, с модбасом двухканальным в виде отдельных задач, и вот теперь таймер победил.
меньше читаешь - больше успеваешь

Н-да, без зазрения совести такое говорить, расписываясь в неуважении к людям, которые потратили время на изучение предмета и дачи вам ответа.

Думаю, предыдущие годы моей бескорыстной помощи в AVR и не только вполне дают мне право немножко посидеть и на чужой шее.
Хотя, по большому счету, мне плевать, как было плевать на меня другим.
Равновесие, однако...

Странно, что никто не сказал, что переход на таймер не избавит от использования стека задач (в частности, heep'а FreeRTOS). И даже усугубит ситуацию.
Стек в прерывании используется (и расчитывается) для всех потоков(задач), т.к. прерывание вызывается в любой момент, и в его обработчике нет переключения контекста, с подменой на собственную область стека, как в случае с потоками.

Никто не сказал потому, что, ИМХО, не так много народа здесь вообще и, тем более, готового делиться знаниями, используют RTOS.

И, опять же ИМХО, ARV поторопился начинать освоение ARM с неё. Ему бы CMSIS / LL / регистры покрутить сначала, углубиться в железо, а потом уже галочками в CubeIDE щёлкать и потоки с кучами распределять.

Минимальная куча для задачи 360 с хвостиком байт. Для обработчика прерывания достаточно 64 байта стека. Есть разница?

Зачем мне лезть в регистры, если мои задачи решаются кубом? Долгие годы увлечения МК привели меня к печальному выводу: чем глубже лезешь, тем сильнее увязнешь. Пока ардуинщики на готовых либах делают от http-сервера до квадрокоптера с видео, я так и не продвинулся дальше мигалок... И толку от того, что регистры AVR для меня открытая книга, а для ардуинщика тарабарщина на китайском?!

Интересно, сколько времени мне потребовалось бы для написания самостоятельно даже простого мастера/ведомого модбас?! А так с ртос и готовой либой я справился за 4 часа, при том что с stm32 до этого не имел дела от слова вообще.

Так что ваши советы, конечно, благие... Но ведут в ад.

Совершенно верно. Сейчас жизни не хватит, чтобы целиком охватить всё, не 8 бит-с...
Надо где-то ставить границу, ниже которой изучение имеет смысл только любопытства ради или как справка в особо тяжёлых случаях.

Всё зависит от того, как относиться программированию вообще. Если это ремесло (суть заработать деньги), подход "либы и галочки в IDE" это правильный вариант. Но если воспринимать программирование как искусство, то чем выше и тоньше это искусство, тем неправильнее выглядят призывы "не лезть глубоко, а лучше вообще всё сформулировать для ИИ" - за несколько дней я дважды натыкался на мнение о крутости написания программ через DeepSeek даже на местном котовском форуме.

И даже вопрос заработать денег на программировании часто зависит от глубины владения вопросом - не этим ли отличаются (ну, или должны отличаться) Juniorы от Seniorов.

А вариант "слепить скетч коленке" вообще не рассматриваем - здесь хоть и форум любителей, но не домохозяек же.

В конце 80-ых и начале 90-ых было мало оперативной памяти, а клавиатуры и MS-DOS были плохо и не всегда русифицированы - приходилось использовать резидентные русификаторы, занимавшие несколько драгоценных килобайт оперативки. А вот у меня получилось полностью русифицировать систему, заняв всего лишь 35 байт ОЗУ. Искусство не искусство, но до сих пор вспоминаю это "достижение" с удовольствием. И хрен бы это получилось, если бы я не знал досконально, как кишки железа, так и кишки MS-DOS на тот момент.

Тоже верно.
Наверное, всё это субъективно... Мне лично хотелось бы знать от и до, и в то же время работать с хорошими инструментариями типа идеального кодо-генератора. Увы, для первого туповат и маложивущ, а вторые неидеальны...

Разница есть. Только эти 64 байта + использование локальных переменных (на стеке) в прерывании, будут накладываться на стек потока, в котором мы находились на момент вызова прерывания.
Т.е., используя прерывания, мы должны расчитывать для них стек в каждом потоке ! А если они ещё будут отложенными (с приоритетами), то расчёт нужен для каждого из них.
Нужно не забывать об этом. Иначе можно себе в ногу.

Совершенно не согласен.
Это "правильный" подход, когда стремятся по-быстрому что-то сляпать, срубить бабло, а дальше - хоть трава не расти.
А реальные серьёзные проекты длятся годами. И "либы и галочки" - стреляют в ногу уже в первое же время. Потом галочкотыкатель сбегает и всё приходится переделывать.
Речь конечно не о проектах уровня: "помигать лампочкой". Там можно писать как угодно.

Всё зависит от точки зрения....
Что есть бордюр на краю дороги? С точки зрения человека - мелкая неровность на пути; подними ногу чуть выше и не заметишь. С точки зрения червя - непостижимая высота.

Никого не хотел обидеть.

Добавлено after 32 minutes 57 seconds:
В HTTP-сервере доля "работы с регистрами" = ~5%. Не более. В HTTPS-сервере - и того меньше (если не используется аппаратная криптография). Писал HTTP-серверы и HTTP- и HTTPS-клиенты самостоятельно, на регистрах. Знаю о чём говорю.
А точнее - работы с регистрами в HTTP-сервере вообще нет. Так как эта работа выполняется в драйвере канала (Ethernet или какого другого).

Так что - не в регистрах дело. Явно в чём-то другом.

Добавлено after 1 hour 18 minutes 17 seconds:
Что там рассчитывать то? Размер стекинга + контекст FPU (если используется и если есть).
Т.е. - без FPU = +8 слов на стекинг. Но с учётом того, что для вытеснения задачи, требуемый размер на стеке должен быть достаточен для сохранения всех регистров CPU, то размер стекинга полностью поглощается этим размером вытеснения. И его можно вообще не учитывать.

Как я понимаю - речь идёт об Cortex-M?
Тогда у меня складывается впечатление, что вы плохо себе представляете как работают прерывания в Cortex-M при работе под вытесняющими РТОС.
Советую почитать в мануале: что такое "Thread mode" и "Handler mode"; и что такое "Main stack" и "Process stack". И когда какой стек используется.

В Cortex-M под вытесняющими РТОС задачи выполняются каждая на своём стеке, используя "Process stack" (указатель PSP). При возникновении прерывания, CPU переключается в "Handler mode" на "Main stack" (указатель MSP), предварительно выполнив только стекинг на стеке задачи (PSP). Все вложенные ISR далее используют уже MSP. Для этого под РТОС существует отдельный стек - стек прерываний.
Не обязательно конечно так делать только под РТОС. Можно и работая без РТОС переключить Cortex-M в такой двух-стековый режим.

Если же речь идёт о "классических ARM", то там вообще всё по иному. Но и там работа ISR не использует стеки задач.

PS: При планировании размеров стеков задач нужно учитывать не глубину ISR-ов, а то - использует ли задача FPU или нет. И где именно в программе используется FPU: в одной задаче или в нескольких? И используется ли FPU в ISR? Вот от этого как раз стеки задач будут очень сильно зависеть. Или если этого не учесть, то баги (из-за переполнения стеков) могут быть крайне трудноуловимыми. Почему? Для понимания "почему"- читать о механизме "Lazy state preservation".

пример с сервером был приведен с целью показать, насколько сложные алгоритмически задачи могут быть решены простыми средствами из "кубиков" готовых решений. понятное дело, что регистры там не особо нужны.
но когда раны заживут - эти решения оказываются ничем не хуже тех, что делались годами. возможно, я так думаю от собственной ограниченности, но пока в моём опыте все так, как я говорю...
я сейчас на месте сбежавшего "негалочкотыкателя" - адаптировать его писанину под слегка отличающиеся требования почти невозможно (опять же, возможно из-за моей тупости так, но...).
и какой вывод? да никакого - необходимость переделывания не связана с тем, о чем вы говорите.

Чем больше я погружаюсь в пучину stm32, тем сильнее я утверждаюсь в мнении, что это контроллеры для тепличных условий. Пины не перегрузи, питание не превысь, от помех защити... Короче, те самые сто рублей, за которые были обещаны высокая производительность и большое количество ресурсов на практике выливаются в еще 1000 рублей обвязки, без которой эта моща превращается в тыкву.

вот только что убедился, что при питании 3.2-3.3 вольта контроллер работает, а при 3.4 - уже нет. Хотя по даташиту вроде же +0,5В от нормы может быть... или не может? в итоге от источника питания за 50 рублей пришлось отказаться в пользу источника питания за 300. так себе экономия...

Добавлено after 3 minutes 34 seconds:
оффтоп
помню AVR: налаживаешь что-нибудь, и вдруг чуешь - воняет что-то... трогаешь МК - он кипяток, аж канифоль дымится (утрирую) - батюшки! да я на него 7 вольт подал! выключил, остудил, подал 5 вольт и пошел дальше работать... как ни в чем ни бывало.

Наверно, вам лучше вернуться к AVR из-за неспособности читать, изучать новое и думать:
https://www.promelec.ru/product/206989/
Зато очень быстро умеете тыкать кнопки в Кубе.

По даташиту норма - до 3.6V и, естественно, там все с запасом.