здрасьте здрасьте люди добрые. скажите пожалуйста как правильно включить тактирование? МК stm32f103c8. нарыл что порты ввода|вывода расположены на шине APB2. причем все порты. нельзя включить отдельно порт допустим
GPIO A
GPIO B
можно только подать тактирование на шину
APB2
нахожу
RCC_APB2ENR
в этом регистре нахожу бит
IOPC// так как светодиод висит у меня на PC13
и теперь видимо мне нужно его выставить в едниницу.
нахожу в memory map вижу адрес не APB2 а RCC
RCC 0x40021000
и правильно ли я понимаю что теперь чтобы мне включить бит нужно вычислить адрес по формуле
40021000-40000000=offset
(offset*32)+(4*4)
потому что (4*4) IOPC=4 битом
поправте пожалуйста уважаемые форумчане меня. я не совесем понимаю как правильно считать
SystemInit(): update to don’t reset RCC registers to its reset values.
Уродский стартап на асме, к сожалению, так и не убрали. У них там функция инициализации переменных багованная, но их спасает то, что она вызывается до того, как будет обнулена секция .bss. Линкер скрипт тоже только для флешки, когда легко сделать универсальный — и для рамы и для флеша, чтобы его не дрочить постоянной перезаписью.
На сайте STM по запросу «STM32 Standard Peripheral Libarary» выдают забагованное, некомпилируемое старьё 2011 года — версию 3.5.0.
здрасьте здрасьте люди добрые. скажите пожалуйста как правильно включить тактирование?
Если тебе хочется освоить программирование микроконтроллеров на промышленном уровне, то лучшим решением будет даже временное трудоустройство на оборонное приборостроительное предприятие, изделия которого напрямую или в составе других изделий поставляются зарубеж. Оборонщики грамотно ставят задачи и решают их шаг за шагом, создавая собственные решения с нуля.
Сейчас ты пытаешься научиться шить сапоги, а спрашиваешь совета у сапожников, которые всю жизнь сидели в своей убогой лачуге, да отдирали старые подошвы, заменяя их новыми. Чтобы стать мастером нужно трудиться рядом с настоящими мастерами.
Тут меня заинтересовал вопрос: можно ли этот бит считать? Для проверки считаем в переменную…
Открываем RM:
In the STM32F10xxx both peripheral registers and SRAM are mapped in a bit-band region. This allows single bit-band write and read operations to be performed.
И показал вам как этот процесс обучения происходит у здорового человека.
Вот чем только люди ни занимаются, лишь бы не использовать Куб и HAL…
А потом получается нечитаемая и непереносимая каша, которую под другой проц нужно переписывать с нуля вместо того, чтобы просто перекомпилировать.
Ну вот нафига сходу лезть во все эти бесконечные регистры и магию констант? Если уж интересно, как правильно включать тактирование, можно почитать код того же HAL. Лучше потом выкинуть оттуда лишнее, чем с чистого листа пытаться родить нетривиальную последовательность инициализации. Это же не AVR какой-нибудь, где включил питание и поехал…
Ну вот нафига сходу лезть во все эти бесконечные регистры и магию констант?
Для того, чтобы: а) понять, как это все работает, б) писать нормальный код, который можно будет читать и поддерживать. Калокуб не позволяет выполнить ни одного из этих пунктов.
Лучше потом выкинуть оттуда лишнее
Если из кала выкидывать лишнее, то куда быстрей с нуля на голом CMSIS написать, чем в этом бредовом индусокоде разбираться. Я уж молчу о том, что в кале до сих пор находят серьезные ошибки!
Это же не AVR какой-нибудь, где включил питание и поехал…
Лично для меня освоение аврки по времени не сильно быстрей STM32 было: полистал даташит, собрал необходимый минимум (makefile и т.п.)… Единственная разница — элементарным восьмибиткам не нужен стартап и линкер-скрипт. С теми же STM8 значительно проще работать, чем с STM32, однако, учитывая то, насколько отстают по своим возможностям восьмибитки даже Cortex-M0, я поигрался с ними одно время и забросил, полностью сосредоточившись на STM32F0x2 и STM32F103. Когда-нибудь, как будет уйма времени, хочу еще освоить STM32F303, очень даже удачная штука вроде бы, разве что ковыряться в OTG наверняка придется долго (я потратил достаточно много времени на реализацию USB под STM32F0x2 и F103, только сравнительно недавно в интернете стали появляться чужие реализации CDC и HID, написанные по-человечески, а не с упором на быдлокодерство).
Прикалываешься? В нем пока один только RCC настроишь как надо уже кукухой поехать можно. Чтобы битики переключать нужно знать какие именно, в какой последовательности, и ничего не забыть при этом, а этих битиков в STM32 и более навороченных МК овердохуя. Вместо запоминания этого цифрового шума лучше про архитектуру фирмвари подумать.
Вот чем только люди ни занимаются, лишь бы не использовать Куб и HAL… А потом получается нечитаемая и непереносимая каша, которую под другой проц нужно переписывать с нуля вместо того, чтобы просто перекомпилировать.
Вот у меня есть камни AVR, есть RISC-V. Как мне перенести на них код USB-Audio?
Если уж интересно, как правильно включать тактирование, можно почитать код того же HAL.
Поверьте, не проще. Я пытался. Но в HAL настолько много ненужных слоев накручено, что пока разберешься что куда идет, поседеть можно.
Ну вот нафига сходу лезть во все эти бесконечные регистры и магию констант?
Очевидно же - чтобы заставить данный модуль работать так, как надо. Реализация USB на HAL занимает около 14 кБ флешки. Человеческая - 2-4 кБ. По скорости тут недавно на Хабре статья вышла https://habr.com/ru/post/558556/ (спойлер: HAL снова в пролете).
вот, кстати, почему я быдлохабру быдлохаброй называю: мой комментарий по теме заминусили (6 плюсов, 8 минусов), а саму эту бессмысленную говнотему подняли (+55 — видано ли, за совершенно отстойный контент)!
Потому что комментарий был не по теме. Вы голословно обвинили автора, что у него руки из жопы. Но он молодец, воспринял критику адекватно и потратил время чтобы найти ваш репозиторий, адаптировать ваш код под себя и постараться объективно оценить результаты. На счет объективности не уверен, поскольку в статье тестировалась только скорость, а не корректность, но в личке он утверждает, что на корректность все эти варианты он потом проверил.
Признайте, что подобных нам маньяков-байтокрутов немного. Чаще народ ищет библиотеки и пляшет от них. А для решения отвлеченной задачи взять HAL и смириться с его косяками и непониманием устройства все же быстрее, чем разбираться с наркоманскими регистрами с нуля.
Вы же эту работу уже проделали, так что кинуть ссылку и помочь автору собрать свой вариант могли легко (я так и сделал, попутно обнаружив и исправив в своей реализации баг). Тогда бы выглядело не как оскорбление диванного эксперта, который обо всем имеет мнение, но результатов которого никто не видел, а хорошего специалиста, который разобрался в теме.
+55 — видано ли, за совершенно отстойный контент
Здесь опять зря, потому что гораздо больше плюсов набирают откровенно мусорные статьи. Ругаться именно на эту не стоит: она хотя бы техническая. И благодаря автору, наглядно показывает, что и HAL не идеален. Теперь ей можно тыкать в нос HAL’о-фанам, что я с удовольствием и делаю.
Вы голословно обвинили автора, что у него руки из жопы
Не голословно, а фактически. Потому что автор решил, что ограничение скорости USB у STM32 — проблема камня, а не кривого кала!
Кстати, я так и не понял, каким именно образом он проверял скорость. Неоднозначно все как-то.
взять HAL и смириться с его косяками и непониманием устройства
Это - абдуриноподход. Любители, задача которых — тратя как можно меньше времени и напрягая свои мозги как можно меньше получить желаемую фиговину — могут и побыть ардуинщиками. А вот профессионал, пользующийся калом или другими уродскими библиотеками (да теми же SPL или даже opencm3) недостоин называться профессионалом.
(кстати, я - не профессионал, я - любитель; просто так получилось, что у меня работа и хобби — практически одно и то же множество)
Вы же эту работу уже проделали, так что кинуть ссылку и помочь автору собрать свой вариант могли легко
Запросто, если бы автор попросил меня об этом в моей ЖЖшке или еще где. На быдлохабре движок таков, что я не могу писать больше 1 сообщения в сутки.
Не голословно, а фактически. Потому что автор решил, что ограничение скорости USB у STM32 — проблема камня, а не кривого кала!
Потому что вы не привели аргументов. Крикнуть «это не в камне проблемы, а в твоем кривом коде» может каждый. А вот доказать - нет. Хал писали разработчики контроллера, с чего автор должен подозревать их в рукожопии?
Это - абдуриноподход. А вот профессионал, пользующийся калом или другими уродскими библиотеками недостоин называться профессионалом.
Какой бы ты ни был профессионал, ты не можешь знать все особенности всех камней. Это любителю позволено тратить месяцы на освоение новой периферии, а над профессионалом стоят заказчики, которым плевать на красоту кода или то, что скорость маловажной периферии на 30% меньше максимальной. Надо чтобы работало и чтобы можно было впарить быстрее конкурентов.
Запросто, если бы автор попросил меня об этом в моей ЖЖшке или еще где. На быдлохабре движок таков, что я не могу писать больше 1 сообщения в сутки.
В личку тоже? Я правда не знаю какие ограничения накладывает отрицательная карма.
В любом случае это не отменяет, что даже в первом сообщении стоило критику делать конструктивной.
Надо чтобы работало и чтобы можно было впарить быстрее конкурентов.
Вот только если этот код нужно поддерживать, то кал - очень плохой выбор. Там же нечитаемое месиво получается!
В личку тоже?
Там личка что ли есть?
А вообще, меня просто бесит то, что на БХ просто засилье вендузятников. И подавляющее большинство — совершенно некомпетентны! Хабра позиционирует себя как технарская ЖЖшка с огораживанием в виде «кармы», однако, фактически в топ попадает всякая дрянь, которой разве что на «пикабу» место! А хорошие годные статьи либо в минусах сидят, либо около нуля. Не раз такое замечал.
Вы же писали там статьи. Неужели никогда не присылали «сообщить об ошибке автору»? Но если и правда интересно - можно зайти в профиль человека и нажать вверху на иконку письма. Или навести на ник в комментариях и всплывет бесячее окошко, в котором тоже есть кнопка «написать».
А хорошие годные статьи либо в минусах сидят, либо около нуля.
Да. Но их все равно можно найти по тегам или выдать в поисковых результатах. Лично мне этого достаточно. А вот чтобы на поисковый запрос выдавало записи из ЖЖ - с ходу не припомню. Гораздо чаще Хабр, Изиэлектроникс (как площадка для статей - почему бы и нет) и всякие рандомные сайты.
Неужели никогда не присылали «сообщить об ошибке автору»?
А, что-то припоминаю. Давно это было. Сейчас я в дриме пишу и в ЖЖ дублирую. Не вижу смысла вообще что-нибудь на БХ выкладывать: все равно заминусуют (если не саму публикацию, так мои комменты оборзевшим ослам).
А вот чтобы на поисковый запрос выдавало записи из ЖЖ - с ходу не припомню.
И правда. Видимо, гугол очень плохо ЖЖшку кэширует. Даже если мое ФИО ввести, ссылка на жжшку только седьмая (а первая - почему-то вообще на профиль в ЮФУ, где я на четверть ставки числюсь). Что-то у гугола поломалась логика.
Если это в принципе возможно для таких то камней - либо переписать приложение на том слое абстракции, который есть [которого нет] на платформе, либо написать свой HAL/AVR или HAL/RISC-V, сохранив внешний API для приложения.
Или про AVR / RISCV ? С ними сложнее, потому что AVR не очень-то интересно, а RISCV не очень удобно отлаживать: либо дергать RESET+BOOT0, либо по JTAG со скоростью ~70 байт/сек
Про «HAL c человеческим лицом», хотя бы на тех же STM32 и/или других ARM того же поколения, т.е. про API не менее удобный, чем HAL, снаружи, но «правильный» внутри.
Так берите, читайте. Сейчас работоспособны библиотека для портов (pinmacro.h) и usb. Еще есть наработка по АЦП, но ее я не выкладывал, поскольку слабо представляю как сделать ее и универсальной, и эффективной.
Или вы имеете в виду заведомо порочный подход пихать весь функционал в одну библиотеку? Таким заниматься, естественно, не буду.
Ну, посмотрел… идея оптимизации по скорости понятна, но там даже эти блоки только для F1 и L1… а с остальными что делать?
Вот вы можете сделать улучшенный аналог HAL, который будет
иметь единый согласованный API поверх всего поддерживаемого железа;
покрывать хотя бы все STM32, желательно другие C-Mx тоже, те же NXP LPC etc;
покрывать все функциональные блоки в каждом МК (HAL этого до конца не умеет);
внутри написан «правильно», оптимизирован, ну или что вы там делаете…
точно так же, как и HAL, допускать неподключение неиспользуемых частей библиотеки и вырезание нахер всех неиспользуемых символов из выходного бинарника;
там даже эти блоки только для F1 и L1… а с остальными что делать?
У меня нет ни задач под другие камни, ни отладочных плат. У вас есть? Так пишите.
иметь единый согласованный API поверх всего поддерживаемого железа;
Аналогично. Мое API вы видели. Есть идеи как сделать лучше - покажите.
покрывать хотя бы все STM32, желательно другие C-Mx тоже, те же NXP LPC etc;
Ну,«все STM» - явно не приоритет. «Максимальный диапазон» ближе.
покрывать все функциональные блоки в каждом МК (HAL этого до конца не умеет);
см. выше: реализацию делают под то, чем пользуются и только если это необходимо. Как для портов или usb. Для всяких таймеров, АЦП или SPI это и не нужно, и вряд ли реализуемо. Тут лучше примеры кода с подробным описанием.
точно так же, как и HAL, допускать неподключение неиспользуемых частей библиотеки и вырезание нахер всех неиспользуемых символов из выходного бинарника;
Зачем же городить костыли поверх неудачного подхода? Надо не «отключать ненужное», а «подключать нужное». Соответственно и необходимости в единой «библиотеке для всего» просто нет. Есть задача - ищем решение.
Единственная разница — элементарным восьмибиткам не нужен стартап и линкер-скрипт.
Ага, не нужен. Но только лишь потому, что грамотно и с любовью настроен дефолт. И как раз-таки в стм-ах оно в принципе не всегда нужно, так как они умеют выполнять код из рамы, в отличие от авр.
Ну можно не «отключать не нужное», а выборочно «подключать нужное», это просто игра слов, главное при этом выбирать из полной библиотеки. Тут получается такое же различие подходов, как у Qt vs GTK+…+…+… - одна понятная модульная библиотека с хорошей документацией вместо лоскутного одеяла из разнородных частных решений.
На счет ADC/DAC/SPI/I2C/таймеров не согласен. Вы предлагаете до регистров опускаться? Ну не должно быть ничего такого выше вызова API, иначе код становится привязанным к железке.
У меня, например, сниппеты под F0 и F1. С остальными пока ничего делать не нужно: у меня их нет. Вот к осени планирую начать знакомство с F303. В принципе, большинство моих сниппетов (кроме USB) в легкую на него перенесется, а вот с USB придется с месяцок покорпеть по вечерам. Но это не страшно. Зато потом будет готовый код: скопипастил — и работай!
единый согласованный API поверх всего поддерживаемого железа
Это невозможно без аккуратного разбора "низов". И это лучше делать на С++ (но т.к. я этот ЯП презираю, то не буду никогда). Есть на форумах товарищ Vladimir_S, постоянно хвастается своими наработками, только целиком никогда не выкладывал. Типа — посмотри, как сделал я, и сделай сам. В принципе, правильно делает. Потому что халявщикам вроде EtherealPhantom нельзя давать готовое к непосредственному употреблению. Я на все 100% уверен, что ты просто сопрешь код и используешь его в закрытой поделке!
покрывать
Как бык корову кроет? Если тебе нужно, делай. Разработчикам это не нужно. И еще раз повторю: подобный подход может привести к созданию очередного кала. И — прощай оптимизация...
внутри написан «правильно», оптимизирован
Ты вообще подходишь к делению на нуль. Выбери что-то одно.
Сравнил два сорта говна. Тоже мне... Если что, хуже Qt я вообще ничего не встречал. GTK — тоже дерьмо, потому что тоже превратился bloatware, как Qt. Ну и GTK основан на glib — мерзость!
Вы предлагаете до регистров опускаться?
Только так можно написать нормальный код, если не хочешь тратить уйму времени на создание своей базы на С++.
код становится привязанным к железке
Ничего подобного! Скажем, между F0 и F1 я легко переношу свои сниппеты — с минимумом изменений. И, кстати, есть еще отличный набор сниппетов от STm для F0, которые с совсем незначительной переделкой идут под F1 (ну, понятно, что многие вещи ты на F1 не сделаешь, т.к. у нее убогая периферия, но остальное - вполне).
Это мы еще будем посмотреть, пока он даже и не хочет :)
Мне не надо быстро, достаточно в нормальном темпе решить задачу вместо бесконечного курения мануалов.
На счет ADC/DAC/SPI/I2C/таймеров не согласен. Вы предлагаете до регистров опускаться? Ну не должно быть ничего такого выше вызова API, иначе код становится привязанным к железке.
Нет, ардуино-подход не интересует.
Если пересечение множества возможностей данной периферии в разных камнях меньше необходимого минимума, его и абстрагировать смысла нет.
Ну пожалуйста, можно сделать API типа libOpenCM3, но через него должно быть доступным все, что есть в МК. Оптимизация никуда не денется, если директивами подключать свою реализацию для каждого проца, хотя вообще то с этой работой прекрасно должен справляться препроцессор даже при одном исходнике на несколько разных железок.
Все, что не написано ниже уровня API из-за оптимизации, будет написано сверху :)
Вот та же libOpenCM3 зачастую слишком низкоуровневая, чтобы этим было удобно пользоваться нужно еще много чего написать поверх, в результате получится ну не совсем HAL, но что-то похожее.
А какой смысл ухудшать читаемость кода? Вместо того, чтобы иметь прокомментированные операции над регистрами, лучше иметь на этом месте функцию с понятным названием и понятными аргументами. Компилятор прекрасно все оптимизирует, заинлайнит, и т.д. и на выходе будет точно такой же бинарник.
Оно, конечно, не такое жирное, как кал, но все равно дерьмо. Потому что нельзя писать библиотеки работы с периферией, используя функции! В крайнем случае — true inline. Но самый лучший вариант для C — макросы, а для C++ — шаблоны.
Любой, кто попытается написать библиотеку абстракций по-другому, используя функции, в конце-концов родит такую же блотварь, как опенцм3 или кал!!!
Компилятор прекрасно все оптимизирует, заинлайнит, и т.д. и на выходе будет точно такой же бинарник.
Если у тебя там 100500 ассертов и проверок переменных, да еще какие-нибудь математические действия (скажем, вычисления значений регистров для тактирования), то точно такой же бинарник никогда не получится.
Еще раз повторю: если хочешь «близости к человеку», напиши на С++ базовый набор шаблонов, где все вычисления и ассерты будут проводиться не в рантайме, а во время сборки. Вот тогда получится классно.
Думаю, человек, хорошо знающий С++, сможет для какого-либо семейства STM32 за пару лет напряженной работы полностью подготовить нужный набор шаблонов. И потом просто будешь не парясь писать что-то вроде
pin LED = pin(PA8, opendrain, slow); LED = 1; ...; LED = 0;
А когда потратит еще годик-другой, то дополнит свои наборы шаблонов до других семейств.
Насколько я его видел, там абстракции почти нет. Оно не позволяет легко переносить код между контроллерами.
Оптимизация никуда не денется, если директивами подключать свою реализацию для каждого проца
Это делается не так. Это делается вынесением конкретной платформо-зависимой реализации в отдельный файл, как делается в ядре. Объединять стоит только если общего кода намного больше, чем отличий. Все же условная компиляция здорово ухудшает читаемость.
Вместо того, чтобы иметь прокомментированные операции над регистрами, лучше иметь на этом месте функцию с понятным названием и понятными аргументами.
И получится либо говнокод в стиле ардуины, когда функция как бы может все, но настолько извращенным способом, что лучше ее не трогать. Либо писать 100500 функций на все случаи жизни. Совместимости это, понятно, не прибавит.
Ну пожалуйста, можно сделать API типа libOpenCM3
Так что там с вашей реализацией USB на других контроллерах?
Там такое Г понаписали... Когда я впервые стал разрабатывать под STM32, попробовал использовать SPL. Охренел от дикости инициализации (все эти дурацкие структуры заполняй - не проще ли сразу в регистры писать?), а когда увидел внутренности этих функций, вообще офонарел от говнокода и перешел на opencm3. Там USB был реализован значительно более вменяемо, однако, тоже сохранался градус неадекватности и оверхеда. Особенно когда разрабы взяли, да поломали полностью API! Плюнул и перешел на чистый CMSIS, без всяких ненужных оберток. И USB на основе тестов одного форумчанина с easyelectronix запилил: CDC (и эмулятор PL2303) и HID, больше мне от USB ничего не нужно (HID в принципе тоже не особо нужен, т.к. я его использовал лишь как эмуляцию клавиатуры для упрощения подключения ко всяким андроидодевайсам).
Не собирался я делать реализацию USB ни на каких контроллерах. Мне пока хватает того, что в ST понаписали.
То есть сами делать ничего не хотите, зато готовы давать советы другим. Будь ваши советы полезны, я бы поблагодарил. Но ваши советы пока основаны на незнании устройства библиотек и их применения.
