STM32 новичку в ARM что к чему

[tonyk]

[uquote="ARV",url="/forum/viewtopic.php?p=4700243#p4700243"]но прерываний нет[/uquote]
А счёт разрешили?
Неужели так сложно написать работу с таймерами на CMSIS? Тогда бы сразу было видно, что сделано, а что нет. Вы хоть мурзилку на ХАЛ прочитали, чтобы понимать, что нужно делать?

[ARV]

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

к слову: с 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, безрезультатно.

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

[uldemir]

Код: Выделить всё

HAL_TIM_Base_Start_IT(&htim6);

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

[ARV]

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

Добавлено after 2 minutes 17 seconds:
[uquote="uldemir",url="/forum/viewtopic.php?p=4700283#p4700283"]

Код: Выделить всё

HAL_TIM_Base_Start_IT(&htim6);

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

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

[tonyk]

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

Сразу видно человека, не читающего документацию. Это всё написано в 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
...
и далее пос списку старт-стоп

[ARV]

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

[tonyk]

[uquote="ARV",url="/forum/viewtopic.php?p=4700385#p4700385"]меньше читаешь - больше успеваешь [/uquote]
Н-да, без зазрения совести такое говорить, расписываясь в неуважении к людям, которые потратили время на изучение предмета и дачи вам ответа.

[ARV]

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

[Аlex]

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

[smacorp]

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

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

[ARV]

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

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

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

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

[Уош]

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

[smacorp]

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

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

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

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

[Уош]

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

[Аlex]

[uquote="ARV",url="/forum/viewtopic.php?p=4700827#p4700827"]Минимальная куча для задачи 360 с хвостиком байт. Для обработчика прерывания достаточно 64 байта стека. Есть разница?[/uquote] Разница есть. Только эти 64 байта + использование локальных переменных (на стеке) в прерывании, будут накладываться на стек потока, в котором мы находились на момент вызова прерывания.
Т.е., используя прерывания, мы должны расчитывать для них стек в каждом потоке ! А если они ещё будут отложенными (с приоритетами), то расчёт нужен для каждого из них.
Нужно не забывать об этом. Иначе можно себе в ногу.

[jcxz]

[uquote="smacorp",url="/forum/viewtopic.php?p=4700834#p4700834"]Всё зависит от того, как относиться программированию вообще. Если это ремесло (суть заработать деньги), подход "либы и галочки в IDE" это правильный вариант.[/uquote]Совершенно не согласен.
Это "правильный" подход, когда стремятся по-быстрому что-то сляпать, срубить бабло, а дальше - хоть трава не расти.
А реальные серьёзные проекты длятся годами. И "либы и галочки" - стреляют в ногу уже в первое же время. Потом галочкотыкатель сбегает и всё приходится переделывать.
Речь конечно не о проектах уровня: "помигать лампочкой". Там можно писать как угодно.

[uquote="smacorp",url="/forum/viewtopic.php?p=4700834#p4700834"]за несколько дней я дважды натыкался на мнение о крутости написания программ через DeepSeek даже на местном котовском форуме.[/uquote]Всё зависит от точки зрения....
Что есть бордюр на краю дороги? С точки зрения человека - мелкая неровность на пути; подними ногу чуть выше и не заметишь. С точки зрения червя - непостижимая высота.

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

Добавлено after 32 minutes 57 seconds:
[uquote="ARV",url="/forum/viewtopic.php?p=4700827#p4700827"]Пока ардуинщики на готовых либах делают от http-сервера[/uquote]В HTTP-сервере доля "работы с регистрами" = ~5%. Не более. В HTTPS-сервере - и того меньше (если не используется аппаратная криптография). Писал HTTP-серверы и HTTP- и HTTPS-клиенты самостоятельно, на регистрах. Знаю о чём говорю.
А точнее - работы с регистрами в HTTP-сервере вообще нет. Так как эта работа выполняется в драйвере канала (Ethernet или какого другого).

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

Добавлено after 1 hour 18 minutes 17 seconds:
[uquote="Аlex",url="/forum/viewtopic.php?p=4700846#p4700846"]Т.е., используя прерывания, мы должны расчитывать для них стек в каждом потоке ![/uquote]Что там рассчитывать то? Размер стекинга + контекст FPU (если используется и если есть).
Т.е. - без FPU = +8 слов на стекинг. Но с учётом того, что для вытеснения задачи, требуемый размер на стеке должен быть достаточен для сохранения всех регистров CPU, то размер стекинга полностью поглощается этим размером вытеснения. И его можно вообще не учитывать.

[uquote="Аlex",url="/forum/viewtopic.php?p=4700846#p4700846"]Т.е., используя прерывания, мы должны расчитывать для них стек в каждом потоке ! А если они ещё будут отложенными (с приоритетами), то расчёт нужен для каждого из них.[/uquote]Как я понимаю - речь идёт об 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".

[ARV]

В HTTP-сервере доля "работы с регистрами" = ~5%. Не более. В HTTPS-сервере - и того меньше

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

И "либы и галочки" - стреляют в ногу уже в первое же время.

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

Потом галочкотыкатель сбегает и всё приходится переделывать.

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

[ARV]

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

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

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

[tonyk]

в итоге от источника питания за 50 рублей пришлось отказаться в пользу источника питания за 300.

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

[Adrift]

[uquote="ARV",url="/forum/viewtopic.php?p=4702720#p4702720"]вот только что убедился, что при питании 3.2-3.3 вольта контроллер работает, а при 3.4 - уже нет. Хотя по даташиту вроде же +0,5В от нормы может быть... или не может?[/uquote]
По даташиту норма - до 3.6V и, естественно, там все с запасом.