Зачем stm32 требует самостоятельно настраивать startup.s ?

[AVI-crak]

И какое сообщество может быть у STM32 с такими граблями?

Чрезвычайно токсичное, есно с точки зрения аурдинщика.
Когда почти на любой вопрос посылают изучать доки. Когда портянки свои постят - изучай доки. Даже на риторические вопросы чисто автоматически - изучай доки.
Потому как желающих обучать языку Си не столь много. Читать документацию для клиента в режиме онлайн - можно всего несколько раз в своей жизни. Потом возникает стойкое ощущение бесполезности подобных действий. Отчего количество "откровений" ещё меньше чем рабочего кода на CMSIS.

Насчёт документации.
Скачивать доку на чип stm нужно непосредственно со страницы продукта, st.com есно. Сначала нужно прочитать название своего чипа полностью. Аурдинщики часто не понимают столь простого задания, для них всего 3-4 продукта существует на всём свете, и для каждого короткое уникальное название. ARM уже больше тысячи (учитывая китай). Одна буква, или даже графический символ - может кардинально менять направление поисков документации.

Случилось странное, у вас получилось найти страницу с доками, которых отчего-то слишком много. Крайне рекомендую установить хром с поиском в гугле, и включить отображение расширений файлов в проводнике. Документацию нужно скачать всю, в отделанную папку (чтоб не потерялось). Первый файл для изучения - самый жирный, на очень много страниц. Читать по диагонали не получится. Информация в доке представлена в очень грамотном порядке - первым идёт то, без чего невозможно продвижение вперёд. Не просто читать сверху вниз, но и применять знание в коде. Программируется чип в точно таком-же порядке как инфа представлена в доке. Это очень важный момент - он поможет вам избежать множества ошибок.
Остальные документы вам тоже нужны, но не сразу и не сейчас. Желательно иметь "слепок" документации не просто свежих версий, а версий одного времени создания. Когда вам понадобится доки, крайне желательно чтобы содержимое не менялось кардинальным образом. А там хоть трава не расти.

Ой, а можно посмотреть эти "ужасные" примеры? Просто как раз пишу на CMSIS

Не надо рекламировать примеры ужасного Си, там и без вас справляются. Если что, они все в соцсетях, и почти всегда в закрытых сообществах. Даже не знаю как они друг друга находят, по запаху наверное. Результат подобного обучения регулярно всплывает здесь, и на других ресурсах. Всплывает как какашка. Многие пользуются ёршиком, отчего вопрошающий обратно ныряет в свои соцсети, и больше не всплывает (и это хорошо).

[VladislavS]

ddr4, направьте вашу злость в правильное русло и всё получится!

У меня нет такого контроллера как у вас, но есть очень похожий. Сделал на нём самый простой проект, как я это понимаю, без всяких библиотек. Компилируется с помощью makefile. Должно и в Windows, и в Linux собираться. Только пути к компилятору прописать.

Линкерскрипт и стартап можете, конечно, посмотреть, но править в них что-то никакой необходимости нет.

Остались два .cpp файла с кодом - там и творите.

F303_Blink.zip

(151.97 КБ) 77 скачиваний

Думаю, сделать по аналогии на ваш контроллер - дело 10 минут.

[MLX90640]

GPIOE->ODR ^= 1 << 8; или GPIOE->ODR ^= GPIO_ODR_ODR8;

[VladislavS]

Вариантов можно много предложить. Вот так, например

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

  if(GPIOE->ODR&GPIO_ODR_8) 
    *((volatile uint16_t *)&GPIOE->BSRR+1) = GPIO_BSRR_BS_8; 
  else
    GPIOE->BSRR = GPIO_BSRR_BS_8;

или вот так

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

GPIOE->BSRR = GPIO_BSRR_BR_8 | ((GPIOE->ODR^GPIO_ODR_8)&GPIO_ODR_8);

Ваш совсем плохой. Почему, поспрашивайте у местных, может расскажут.

[azhel12]

[uquote="VladislavS",url="/forum/viewtopic.php?p=4279676#p4279676"]Ваш совсем плохой.[/uquote]На основе двухгодичного входа в мир программирования под stm (чтения форумов) придумал универсальный ответ: Иди прочитай доки, переделай нормально, иначе придет Емельянов Эдуард и тебя уничтожит.

[VladislavS]

Не придёт. Он является на заклинания "куб" или "windows"

[MLX90640]

Ваш совсем плохой.

Не выдумывайте ереси. Чтобы оценить плохой или хороший, надо знать почему плохой или хороший. А вы просто скопипастили кусок кода не подумав куда вы его вставляете. Попытка же выпендриться знанием тренарного оператора - нифкатывает тут.
Для простого блинка без ничего другого - ничего плохого нету. Нужно ведь понимать, что пишите, а не просто копипастить, как вы сделали. Иль вы хотите со мной поспорить? Ой, не советую, не советую У меня опыта и знаний невпример больше. Вы судя по всему весьма недавно на ARM сели. Так что давайте без умничаний - я умнее вас даже без вариантов, и не пытайтесь спорить На любое ваше слово я десять дам. Так что поостерегитесь без нужды заикаться.

[Eddy_Em]

VladislavS, точно ☺

тобы оценить плохой или хороший, надо знать почему плохой или хороший.

Понятно, что в "блинке" можно спокойно ODR использовать. Но в общем случае состояние порта может поменяться DMA, периферией, в прерывании и т.п. Поэтому надежней атомарные операции использовать. А т.к. их нет, то менять состояние пина через BSRR.

[MLX90640]

Ну, до DMA тут еще как до китая, тут автор вначале хотябы просто проект бы собрал, без блинков пусть даже. Автор темы пока еще просто находится в ужасе от увиденного и от того, что STM32 - это нихрена не AVR, и всё настолько непривычно и непонятно, что он ну совсем потерялся. Так что какие уж ему тут DMA... И даже BSRR тоже нафик, пусть хоть через ODR и программный дилей сбацает. Ему щас надо простенько и примитивненько, не травмируя психику чувствительную, без излишеств.
А то я тож могу блинк через FSMC замутить, так автор темы вообще свихнется.

[Мурик]

Не выдумывайте ереси. Чтобы оценить плохой или хороший, надо знать почему плохой или хороший.

Потому что чтение/модификация/запись. Если в этот момент прилетит прерывание в котором похожим образом изменяется бит на том же порту, будет... Надеюсь знаете или объяснить?

[Eddy_Em]

Идеальнейшим вариантом для ТС было бы вычитать всю нужную документацию и практически с полного нуля начать разработку, чтобы все понять. Взять образцы, да написать свой Makefile, ld-скрипт, стартап (выкинуть все ненужное из классики - в С нафиг не надо держать все эти секции конструкторов-деструкторов, еще выкинуть запуск всякого говна вроде SystemInit - их правильней вызывать в начале main). Качнуть CMSIS с заголовочными файлами под свой камень и разрабатывать.

[MLX90640]

чтение/модификация/запись.

"Спасибо што сказали". А то без вас прям не знал. Я это узнал даже раньше, чем вы, если чо так Тожемне, "учителя" собрались, хахаха Но здесь, в примере того блинка, там никде нет потенциального "модификация-запись". Нужно же не тупо копипастить, а понимать, что где и для чего пишите. А то начали вдруг умничать прям. Ха. Вы вначале попробуйте топикстартеру доходчиво объяснить насчет сборки чистого проекта, потом будет блинками хвастаться А то топикстартер уже готов разломать пополам плату BlackPill

[VladislavS]

[uquote="Eddy_Em",url="/forum/viewtopic.php?p=4279779#p4279779"]в С нафиг не надо держать все эти секции конструкторов-деструкторов,[/uquote]Компилятор всё равно их создаёт. И с чего вы взяли, что в проекте не будет С++? ТС ардуиньщик, а они на плюсах пишут.

[uquote="Eddy_Em",url="/forum/viewtopic.php?p=4279779#p4279779"]еще выкинуть запуск всякого говна вроде SystemInit - их правильней вызывать в начале main).[/uquote]Это неправильно. Даже если взять простые чипы, где вся память включена при подаче питания, то в Systeminit обычно поднимают тактовую. Инициализировать данные на 16 МГц или 72 МГц (или даже на 480) это достаточно большая разница в скорости запуска получается.

PS: Ещё вспомнил. Есть одна достаточно распространённая стандартная библиотека (название умолчу), которая при инициализации данных использует FPU. И если его не включить перед её вызовом, то будет такой смачный HardFault на ровном месте. Только из-за выкинутого SystemInit.

[Eddy_Em]

VladislavS, на отсутствие инита FPU я уже натыкался, спасибки. Но я таки предпочитаю явно иметь вызов функции systemreset() в начале main(), нежели гадать, что за хрень неведомая происходит!!!
А если нужно тупо поблимкать светодиодом на минимальной частоте, то ничего вызывать не нужно. И все идет ровно по накатанной - как написано в даташите, а не как какой-то автор нарисовал в SystemInit, который вызывается из стартапа без твоего явного желания!
В общем, все должно быть именно так, как я задумал, а не как во всяких пытхонах, где, чтобы себе выстрелить из гранатомета в голову, нужно приложить нехилые усилия...

[VladislavS]

Ну так оно и идёт всё ровно по накатанной начиная с Reset_Handler. Почему ты считаешь, что жизнь начинается с main? И кто кроме тебя в твоём проекте что-то в SystemInit может написать? Всё под контролем.

[ddr4]

[uquote="MLX90640",url="/forum/viewtopic.php?p=4279526#p4279526"]А что ужасного в STM32? Это просто гораздо более мощный микроконтроллер с гораздо более высоким порогом вхождения, для более умных и опытных программистов. Документация - да, на порядок объемнее. Про стартап линкерскрипт уже сто раз объяснили. Автор вопроса либо тупит, либо капризничает. Ну да, STM32 гораздо сложнее, это вы ещё не видели системы тактирования в каком-нибудь STM32H743. Но это просто совершенно иной уровень. Если программист не тянет мозгом, то незачем и начинать. А то как в басне про обезьяну и очки.

Автору - не волокешь, не хватает соображаловки, мозги не проворачивают объем информации - просто не лезь в эти дебри, сдохнешь. STM не виноват, что он сложный. Виноват программист, недостаточно подготовленный и не понимающий. А ведь есть и гораздо более сложные системы, для весьма подготовленных специалистов.[/uquote]Причём здесь тянет мозгом, не волокёшь, вы на СТМке уже 10 лет сидите, а я лишь описал впечатления после 2-х дней знакомства с СТМ после AVR. Причём, если бы я не был знаком с AVR, то таких впечатлений скорее всего бы не испытал, так как сравнивать было не с чем.
Причём здесь соображалка. Пример с uart_print() у меня собрался, раз уж я понял что HAL не той версии.
Я и не собирался лезть в дебри, мне нужно было понять проект-примера это же не дебри - это на поверхности, только поверхность была большая от ld-скриптов и стартапа до HALa.
По моему вы как-то приняли на свой счёт мои впечатления о знакомстве STM32-после-АVR и перешли на обсуждения меня. Причём я написал этот отзыв после того, как уже разобрался с API HAL. Это был скорее юмор, но как мне показалось его слишком серьёзно восприняли.

Добавлено after 1 hour 9 minutes 34 seconds:
[uquote="VladislavS",url="/forum/viewtopic.php?p=4279615#p4279615"]ddr4, направьте вашу злость в правильное русло и всё получится!

У меня нет такого контроллера как у вас, но есть очень похожий. Сделал на нём самый простой проект, как я это понимаю, без всяких библиотек. Компилируется с помощью makefile. Должно и в Windows, и в Linux собираться. Только пути к компилятору прописать.

Линкерскрипт и стартап можете, конечно, посмотреть, но править в них что-то никакой необходимости нет.

Остались два .cpp файла с кодом - там и творите.

F303_Blink.zip

Думаю, сделать по аналогии на ваш контроллер - дело 10 минут.[/uquote]
Это была не злость, а скорее юмористический отзыв, который описывал первые ощущения от знакомства с СТМ32. На момент написания которого, я уже разобрался в структуре проекта, то есть нашёл HAL, перевёл найденный пример uart-print() на свою версию HAL и собрал. То есть причины злится у меня не было. К сожалению мне пока негде его проверить собранный пример, так как выводы к плате ещё не припаял. Для проверки пытался использовать QEMU с командой:

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

qemu-system-arm -machine netduinoplus2 -cpu cortex-m4 -kernel test.bin -nographic 

Но программа висит и в окно эмулятора ничего не пишет. Кто-то советует делать вывод в unix сокет, но у меня Windows. Вобщем трудно понять работает ли программа, но видимо это уже на железе надо проверять. Хотя я не оставлю попыток установить QEMU в Линукс и попробовать уже там с выводом в unix-сокет.

Спасибо за пример. Как я понял это прерывания по таймеру, подробности (частота срабатывания и настройка таймера) пока не изучал.

Добавлено after 1 hour 53 minutes 51 second:
[uquote="Eddy_Em",url="/forum/viewtopic.php?p=4279779#p4279779"]Идеальнейшим вариантом для ТС было бы вычитать всю нужную документацию и практически с полного нуля начать разработку, чтобы все понять. Взять образцы, да написать свой Makefile, ld-скрипт, стартап (выкинуть все ненужное из классики - в С нафиг не надо держать все эти секции конструкторов-деструкторов, еще выкинуть запуск всякого говна вроде SystemInit - их правильней вызывать в начале main). Качнуть CMSIS с заголовочными файлами под свой камень и разрабатывать.[/uquote]
С нуля это не разработка, а скорее изучение МК. Разрабатывать приложения можно не заглядывая в CMSIS. Я так и делал в avr-gcc, там своя библиотека avr-libc встроена в компилятор.
Вобщем для разработки на STM32 достаточно рабочих примеров на HAL, можно и над ним подняться при желании, железо с натяжкой позволяет.
И так как STM не сделала свой stm-gcc, то у нас есть библиотеки CMSIS+HAL, cross-gcc + ld-скрипты.
Вот меня такой зоопарк сперва немного удивил.

[Eddy_Em]

ddr4, вот я начал осваивать STM32 лет 10 назад. И если бы мне тогда сказали: "не пользуйся говнищем SPL, не пользуйся говнищем opencm3", я бы не потратил лишних года 3-4 на это рукоблудие, а сразу же сел бы писать свои сниппеты под "чистый CMSIS".
Теперь их есть у меня. По мере разработки регулярно этот набор пополняю. Ну и старое стараюсь развивать: то у меня был блокирующий CDC, потом сделал на кольцевом буфере, а сейчас заметил, что скорость маловата (всего-то 6.5Мбит/с, а в теории как бы 12 должно быть), решил чуть переделать (в прерываниях отправлять следующую часть буфера, как только предыдущая отправлена). И CAN, наверное, стоит на прерывания переписать (т.к. поллинг, возможно, может пропускать сообщения на большой скорости - хотя пока что ничего подобного не замечал).

[MLX90640]

а я лишь описал впечатления после 2-х дней знакомства с СТМ после AVR.

Ну дак надо было просто представлять, что STM32 после мелких AVR - это на два порядка более сложный уровень. Это не равноценная замена, как бы, это надо было сразу осознавать переход на другой уровень. Мы, когда десяток лет назад пересаживались с PIC/AVR, сразу были готовы к смене разрядности с 8 на 32 и к более сложной начинке. Например, для меня главной непоняткой было то, что стмовский даташит содержит только общее описание МК и электрические его характеристики, а описание регистров и битов находятся в двух других документах, да еще и с разделением на ядро Кортекс и периферию СТМ. Но ниче, привык, освоил.
И даже наоборот, предыдущий опыт работы с PIC/AVR очень даже помогл в освоении STM32, потому что не надо было разбираться, что такое память программ, для чего нужны таймеры и как работает SPI, I2C, UART.