Гражданские МП41-42(те что без ромбика) дохли ещё больше и имели такой разборос параметров что хоть плачь. Лак, неведомые плетения проводов, куча хаков схем в виде напаянного МГТФ и прочего, вот что из себя представляли гражданские образцы того времени.
Это работает — работает, выполняет поставленные задачи — выполняет, есть производители — есть, зачем отказываться? А вообще задавая подобные вопросы следует ответить когда в каком-нибудь типичном вузе отказались от дискет, или больнице. Всякое сравнение должно быть правильным по времени и месту действия.
Когда требуется решить конкретную задачу не связанную с гражданским сектором обычно сертификация заменяется приёмкой заказчика и там гораздо проще привнести нововведения — собственно те же гибридные схемы начинались с военки и аэроспейса, также как и гибкие и жёстко-гибкие печатные платы. Тут весь вопрос в надёжности и соотношени других показателей.
Как раз наоборот, обычно ставят то что позволяет наиболее быстро и гарантированно решить поставленную задачу, это видно как по космической программе так и по военным — там где надо будут стоят логические элементы, а где есть необходимость так будут вполне современные микропроцессоры, кластера вычисилительных ядер и прочие радости в жизни, большиство из которых не увидишь в гражданке. Вопрос целесообразности, а она у вояк и аэроспейса весьма отличается от гражданской продукции.
Так можно собрать конструкцию которая будет выставлять необходимые биты в нужное значение (это не проблема). Порой бывает в stm32 что даже 16 бит собрать по одному порту это достаточно сложно — т.к. ноги заняты другими функциями.
Это и есть HAL, когда мы представляем в виде одной сущности несколько более низкоуровневых, когда делаешь параллельную шину на МК где у каждого порта меньше выводов чем необходимая разрядность это прям существенно помогает. Эмбеддер должен думать о задаче по хорошему а не каждый раз вспоминать путь до неё. Таким образом будет более продуктивным. А оптимизации оставить уже на тот момент когда действительно видны проблемы.
Можно без повторения cr1, использовав ещё немного шаблонной магии, когда компилятор сам будет знать куда писать значения для регистров. А генерацию из SVD это прям тоже вариант (я в комментарии выше кидал как это прям будет выглядеть).
Очень сильно похоже на мои изыскания — github.com/no111u3/stm32l476_examples, правда я так не нашёл в себе силы довести всё это до логического финала (уж слишком много труда требуется на всю экосистему).
Можно с помощью тепловой и электростимуляции управлять. По крайней мере эта часть достаточно изучена и есть даже готовые киты (для насекомых правда, но не суть).
Хм, очень интересно, у меня просто нет в наличие именно этого процессора, А вообще проверить частоту которая на выходе из ФАПЧ достаточно несложно — берём эту частоту, запускаем для таймера делитель равный нулю (что даёт частоту кратную той что приходит на таймер) (учитывая делители для шин AHB и APBx(где х это та шина на которой висит таймер). Далее заполняем для таймера регистр перезагрузки в значение 1000, а для регистра совпадения — 500, выставляем режим — шим, и получается таймер будет аппаратно переключать с частотой не более 180 кГц. Это и будет частота на которую вы настроили ФАПЧ (PLL).
Просто тут такой вопрос что оно реально на выходе даёт 90 МГц — так как для работы ULPI (Physic Layer USB 2.0 HS) нужно 60 МГц на вводе — выводе. Там конечно могут другие факторы накладываться, но факт остаётся фактом.
Ну насчёт отсутствия светодиодов вы это зря, их там аж целых 4. Второй момент, это то что работа с портами ввода — вывода, если у них правильно настроена скорость реакции то они работают с частотой шины на которой они «сидят» — AHB, а это внимание 168 МГц. То есть дело скорее в том что вы не совсем верно настроили периферию. Ну и наконец третий момент: слишком много параметров которые можно было бы по хорошему оптимизировать, поручив это грамотной системе сборки. А так хотелось бы посмотреть побольше кода и преимущества данной ОС перед другими: например стабильность планировщика, отказоустойчивость и многое другое.
Меня немного смущает фраза «должен компилироваться в прямой доступ к регистрам». Обычно битовые операции разделённые по времени не оптимизируются, поэтому я от них отказался в пользу свёртки во время компиляции набора битовых констант через вариативные шаблоны.
Ну для остальной периферии пока я пока ещё не реализовал настолько высокоуровневый API уж извините, к сожалению в компайл-тайм не влезает сильный ии. Тот API который я разрабатываю помогает случайно не записать не в тот регистр не те настройки, позволяет выбирать из заранее объявленных констант. Ну и самое главное не накладывает избыточного кода поверх того который может сгенерировать компилятор языка С. Пока более ничего сверхестественного моя библиотека не выполняет. Для части периферии отвязана от записи в регистры напрямую, а также настройки (EXTI, GPIO, USART), но от понимания того что такое USART оно не избавляет да и не должно. Компилятор за вас думать не будет. И не должен. А когда будет тогда не будете нужны вы. Кстати видел я ваш код, он нисколько не помогает оптимизировать ту работу которую делает программист. Потому, что сложные операции должны быть эффективными.
Если уж совсем в двух словах — «используй метапрограммирование». А если не в двух то использование шаблонов с вычислением масок и констант во время компиляции. Небольшой фрагмент кода я приводил выше.
Весь вопрос в том что макросы не избавляют вас от тех же действий в вашем случае. Да вообще из знакомых мне вариантов есть один который избавляет, второй пишу я. Но там подход меняется достаточно сильно и скажем так порог вхождения программиста в этот код выше чем у лапши любым выше перечисленным способом.
В радиолюбительской практике достаточно часто. Причём вариант 2 преобладает.
vjordan.info/log/fpga/stm32f4-bare-metal-start-up-and-real-bit-banging-speed.html