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

[Up2805]

"Говорят, в Москве кур доЯт". ... Есть стандартный SWD-интерфейс отладки и загрузки, зачем мучиться с UART-загрузчиком? Загрузчики через иные интерфейсы нужны для перепрошивки или первичной заливки в готовые устройства.

[VladislavS]

ddr4 писал(а):

Я же не знаю как оно в реальности запускается

Точно так же как в AVR. Включаете питание и код начинает выполняться с Reset_Handler.

ddr4 писал(а):

возможно в линкере указывается куда МК (операционная система) должна разместить секции программы после её запуска.

Не придумывайте, какая ещё операционная система? Всё то же самое как в AVR.

ddr4 писал(а):

На деле МК размещает секции по адресам в адресном пространстве, желательно чтобы МК размещал секции в ОЗУ, так как во-первых ОЗУ быстрей FLASH'a, а значит скорость программы возрастает,

Это заблуждение. К флэш у контроллера широкая шина с предвыборкой и кэшами. При расположении кода во флэш, а данных в SRAM программа работает частенько даже быстрее чем чисто из SRAM.

ddr4 писал(а):

а во-вторых FLASH имеет ограниченный ресурс на число записей. То есть МК с размещением секций в ОЗУ проживёт дольше.

Как вы себе это представляете? Вот включили вы питания контроллера, флэш девственно чистая (экономите ресурс). Откуда код и данные появятся в ОЗУ? В ОЗУ размещаются переменные (нулевые занулением, ненулевые копированием из флэш в стартапе), а во флэш лежит код. Лежит себе, положенный туда один раз при программировании.

Экономят флэш когда занимаются постоянно отладкой. Тогда с помощью отладчика (ST-Link, J-Link и др.) загружают код в SRAM. Тогда флэш и правда не используется. Именно при таком сценарии использования нужен скрипт линкера с перенаправленными в SRAM секциями. Для штатной прошивки, которая должна работать в контроллере при включении питания это всё не работает.

ddr4 писал(а):

Но видимо указание линкеру разместить секцию в >RAM, ещё не является гарантией что она будет находится именно в ОЗУ ..? Так как нельзя сказать точно на какое устройство отражается кусок адресного пространства.

У контроллера в документации написано по каким адресам какая память находится. У вашего контроллера по адресу 0x08000000 всегда флэш, а по адресу 0x20000000 всегда SRAM. Так устроен чип. Если сказано разместить в SRAM (0x20000000), то ничем иным это не будет.

ddr4 писал(а):

В коде стартапа секция данных копируется по адресу (не факт что ОЗУ),

Подумайте и ответьте на два вопроса. Откуда копируется секция данных? Куда кроме ОЗУ она может копироваться?

ddr4 писал(а):

Возможно сам МК и размещает секции в адресном пространстве, может у него есть какие-то внутренние механизмы?

Сам МК ничего поместить не может. Есть три основных механизма загрузки кода:
1. Программа программатором прошивается во флэш и лежит там постоянно. При включении питания из него и стартует.
2. Отладчиком программа загружается в SRAM и работает оттуда до выключения питания.
3. С помощью перемычки в МК запускается программа-загрузчик, находящаяся в системной памяти. Эта программа-загрузчик позволяет прошить флэш через UART, USB и т.д. без программатора. После прошивки перемычка снимается и работает всё как в п.1.

ddr4 писал(а):

В коде целый файл sbrk.c под подготовку кучи, + в .map-файле heap'a навалено. Вроде оно всё не мешает, но когда этого всего "не мешает" - много, оно как-то начинает мешать.

Поверьте, проблема не в скрипте линкера, а в том что пример своего блинка вы на какой-то помойке нашли. Оставьте в проекте скрипт, который я выкладывал и больше в него не заглядывайте. Поверьте, там проблем нет.

Когда вы работали с Ардуино, то "под капотом" было всё то же самое. Просто IDE всё от вас прятала и дурные мысли не приходили.

Совет - создайте чистый проект руками. В него включите:
1. Стартап файл.
2. Линкерскрипт.
3. Заголовочный файл от вашего микроконтроллера.
4. Папку CMSIS. Заголовочные файлы из неё понадобятся для пункта 3.
5. Один файл программы с функцией SystemInit. В ней включите тактирование GPIO-порта, на котором висит диод.
6. Второй файл программы, в котором в main мигайте себе светодиодом.

Так и разберётесь как что работает, и с "лишним" бороться не надо будет.

Добавлено after 15 minutes 38 seconds:

ddr4 писал(а):

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

Ну так не собирайте его на всяких помойках. Самому, конечно, трудно с нуля проект сделать. Но можно же на форуме попросить. Минимальный проект без всякого мусора. IDE нормальную используйте, с нормальной отладкой. Тогда никакие симуляторы не понадобятся.

ddr4 писал(а):

Пока не знаю, хотел сначала с эмулятором поиграться, а после уже через uart-ttl через сериал. Говорят в F4 есть встроенный загрузчик он это позволяет.

ST-Link самый дорогой $3. Зажали и будете без отладки через загрузчик шить? Ну-ну. Чем тогда это от ардуины будет отличаться?

ddr4 писал(а):

Иначе всё в 2 кБ не впихнуть.

А чё, прикольно. Купить контроллер с 256к на борту и впихнуть всё в 2к. Занятная цель.

Добавлено after 20 minutes 10 seconds:

AVI-crak писал(а):

С секциями init_array - даже у меня вопросы имеются.

Так это, там хранятся адреса конструкторов глобальных объектов.
В стартапе для их использования вот такое пишут

Код:

for(void(**fConstr)() = __preinit_array_start; fConstr < __preinit_array_end; (*fConstr++)());
for(void(**fConstr)() = __init_array_start;    fConstr < __init_array_end;    (*fConstr++)());


[Мурик]

На деле МК размещает секции по адресам в адресном пространстве

Размещает компилятор, а не МК.
МК в стартапе может скопировать что-то из флеша в ОЗУ, но к размещению секций это отношения не имеет.

желательно чтобы МК размещал секции в ОЗУ, так как во-первых ОЗУ быстрей FLASH'a, а значит скорость программы возрастает

В теории да но на практике, обычно скорость выполнения из флеша примерно такая же как из ОЗУ. Учтите что ОЗУ намного меньше чем флеша. Размещать в нем код без необходимости обычно не имеет смысла.

во-вторых FLASH имеет ограниченный ресурс на число записей.

Как это влияет на работу прошивки? Релизную все равно нужно шить во флеш потому что ОЗУ хранит данные только пока есть питание. А отладочные прошивки можно грузить в ОЗУ. В IDE выбираете цель сборки Debug RAM или подобную (зависит от IDE), компилируете и заливаете в МК.

То есть МК с размещением секций в ОЗУ проживёт дольше.

Вы прошиваете МК 1500 раз за день? У флеша гарантированный ресурс перезаписи около 10 тысяч.

В коде стартапа секция данных копируется по адресу (не факт что ОЗУ)

В МК переменные могут быть еще где-то кроме ОЗУ?

Остальные секции возможно размещает сам МК, может у него есть какие-то внутренние механизмы?

Дизассемблируйте прошивку и посмотрите как она устроена. Посмотрите map файл. Запустите отладку и по шагам проследите как выполняется программа, что и куда пишет/копирует и т. д.

В коде целый файл sbrk.c под подготовку кучи, + в .map-файле heap'a навалено.

Нормально создавайте проект не добавляя то что не требуется.

С секциями init_array - даже у меня вопросы имеются.

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

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

Библиотеки HAL/LL/SPL/CMSIS в файлах проекта и там тысячи строк кода. Будете вручную выпиливать все что не используется?
А сколько подобного кода было ардуине, о котором вы похоже даже не знали.

Когда флеша не хватает, то из библиотеки берётся одна функция, без подключения хедера зависимого от других хедеров. Иногда это экономит и память и флеш.

А если флеша хватает?
Откуда столько заблуждений? Видимо негативное влияние ардуины!

Пока не знаю, хотел сначала с эмулятором поиграться, а после уже через uart-ttl через сериал.

Отладчик освойте (купите ST-Link если его нет). Многие вопросы отпадут, потому что когда видно как работает программа что и где находится, не приходится догадываться о работе МК.

[VladislavS]

Мурик писал(а):

В МК переменные могут быть еще где-то кроме ОЗУ?

Ну, как вам сказать... Да! В IAR для AVR можно переменные в EEPROM размещать.

Код:

__eeprom int x;

int main()
{
  x++;
//        LDI     R20, LOW(`x`)
//        LDI     R21, (`x`) >> 8
//        RCALL   __eeget16_16
//        SUBI    R16, 255
//        SBCI    R17, 255
//        LDI     R20, LOW(`x`)
//        LDI     R21, (`x`) >> 8
//        RCALL   __eeput16_16
}


[ddr4]

Up2805 писал(а):

"Говорят, в Москве кур доЯт". ... Есть стандартный SWD-интерфейс отладки и загрузки, зачем мучиться с UART-загрузчиком? Загрузчики через иные интерфейсы нужны для перепрошивки или первичной заливки в готовые устройства.

Наверное есть, но у меня нет SWD-программатора, есть только usb-ttl. Если можно просто прошить меня это устраивает. Дебаг на работающей плате мне не особо нужен, в AVR мне это не потребовалось. Там отлаживаю на коде для компа, или перепрошивкой с выводом значений printf().

VladislavS писал(а):

Подумайте и ответьте на два вопроса. Откуда копируется секция данных? Куда кроме ОЗУ она может копироваться?

Из флеша во флеш, этакий недокументированый swap. С одной стороны это бессмыслено, так как данные копируются из флеша во флеш. Но если это убьёт МК быстрей производитель только порадуется, а виноват программист, - незачем было указывать размещение во флеш). Таким образом мы ограничивает МК не только по числу перезаписей, но и по числу включений. Это я опять выдумываю).

VladislavS писал(а):

Сам МК ничего поместить не может. Есть три основных механизма загрузки кода:
1. Программа программатором прошивается во флэш и лежит там постоянно. При включении питания из него и стартует.
2. Отладчиком программа загружается в SRAM и работает оттуда до выключения питания.

А зачем отладчик загружает программу в SRAM, если флеш настолько хорош? И почему так не делают в рабочем режиме, если только не из экономии RAM?

VladislavS писал(а):

Поверьте, проблема не в скрипте линкера, а в том что пример своего блинка вы на какой-то помойке нашли. Оставьте в проекте скрипт, который я выкладывал и больше в него не заглядывайте. Поверьте, там проблем нет.

Когда вы работали с Ардуино, то "под капотом" было всё то же самое. Просто IDE всё от вас прятала и дурные мысли не приходили.

Я в vim'e писал, в том числе простой makefile с компиляцией каждого файла. Но вот avr-gcc действительно скрывало многое, что просто gcc для stm32f4 не скрывает.

VladislavS писал(а):

Совет - создайте чистый проект руками. В него включите:
1. Стартап файл.
2. Линкерскрипт.
3. Заголовочный файл от вашего микроконтроллера.
4. Папку CMSIS. Заголовочные файлы из неё понадобятся для пункта 3.
5. Один файл программы с функцией SystemInit. В ней включите тактирование GPIO-порта, на котором висит диод.
6. Второй файл программы, в котором в main мигайте себе светодиодом.

Так и разберётесь как что работает, и с "лишним" бороться не надо будет.

Спасибо, примерно это я сейчас и пытаюсь сделать.

VladislavS писал(а):

Ну так не собирайте его на всяких помойках. Самому, конечно, трудно с нуля проект сделать. Но можно же на форуме попросить. Минимальный проект без всякого мусора. IDE нормальную используйте, с нормальной отладкой. Тогда никакие симуляторы не понадобятся.

Впринципе всё понятно, можно и на Эклипсе жить, отладчик gdb и printf(), если дойду до Хеллоу Ворлда.

VladislavS писал(а):

ST-Link самый дорогой $3. Зажали и будете без отладки через загрузчик шить? Ну-ну. Чем тогда это от ардуины будет отличаться?

Я и ожидал что работа с stm32 от Ардуины ничем принципиально отличаться не будет. Тем более что больший размер памяти упрощают алгоритмы, и приводит к уменьшению кода. А я и ардуину не отлаживал на чипе, только на компе куски кода и через printf(), с этим можно жить.

VladislavS писал(а):

А чё, прикольно. Купить контроллер с 256к на борту и впихнуть всё в 2к. Занятная цель.

Цель была упростить код, который на ардуине впритык расходует 2 кБ RAM, что приводит к усложнению алгоритмов. А хотелось их упростить, так как 64 кБ RAM на stm32 должны были развязать руки. Но не всё так просто оказалось)

[Мурик]

В IAR для AVR можно переменные в EEPROM размещать.

Ну мы тут обсуждаем STM32.
И это не совсем переменная. Это скрытая запись в энергонезависимую память.
С таким же успехом можно разрешить запись во флеш и записывать вызовом FLASH_ProgramByte() или подобной.

меня нет SWD-программатора

ST-Link продается на каждом углу и стоит около 150 рублей.

Спойлер

Его можно самому собрать.

Там отлаживаю на коде для компа, или перепрошивкой с выводом значений printf().

Это не отладка, а много зря потеряного времени!
Вот смотрите просмотр регистров под отладчиком. Как это сделаете на printf()?

Спойлер

Выводить все регистры? Представляете сколько это текста и как неудобно и утомительно анализировать выхлоп?

Из флеша во флеш, этакий недокументированый swap.

Смысл?

незачем было указывать размещение во флеш)

Если не потанцевать с бубном не разблокировав запись во флеш, и не стерев страницы, записать ничего не получится.

Это я опять выдумываю).

Ага!

А зачем отладчик загружает программу в SRAM, если флеш настолько хорош?

Загружает если это явно заданно. Обычно применяется для отладки чтобы флеш не протирать.

И почему так не делают в рабочем режиме, если только не из экономии RAM?

Нет смысла. Программа нормально из флеша выполняется (в AVR разве не также?).

Но не всё так просто оказалось)

Это вы все усложняете начав изучение не с той стороны.

Последний раз редактировалось Мурик Сб авг 27, 2022 20:14:55, всего редактировалось 2 раз(а).

[Up2805]

Я и ожидал что stm32 от Ардуины ничем принципиально отличатся не будет.

Странное ожидание. Лет пять назад вас за такие слова помидорами бы закидали Дело в том, что STM32 это принципиальная и диаметральная противоположность Ардуины. А то, что появились некоторые адруиноподобные шилды на STM32 и в Ардуино-IDE добавили младший STM32, это еще не говорит о принципиальной схожести.

Исполнение не из флеша может быть нужно в очень старших семействах STM32 с выделенной специальной областью SRAM (ITCM RAM), в которую загружаются некоторые небольшие части кода. Своего рода кэш второго уровня.
Так же исполнение из SRAM может использоваться при перепрошивке флеша в готовом устройстве. Однако, оно небезопасно при неожиданном прекращении питания во время перепрошивки - опасность окирпичивания.

Исполнение из общей SRAM чревато снижением скорости, потому как SRAM однопортовая и если нет второго отдельного блока SRAM с отдельным портом, обращения к SRAM будут делиться между исполняемым кодом и данными.

Последний раз редактировалось Up2805 Сб авг 27, 2022 20:24:46, всего редактировалось 2 раз(а).

[VladislavS]

ddr4 писал(а):

Это я опять выдумываю).

Такое выдумать можно только под воздействием чего-то запрещённого.

ddr4 писал(а):

А зачем отладчик загружает программу в SRAM, если флеш настолько хорош?

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

ddr4 писал(а):

И почему так не делают в рабочем режиме, если только не из экономии RAM?

А как вы себе это представляете? К каждому серийному изделию по программатору и программисту запускающему его в коробку класть? А экономия RAM и флэш вообще бессмысленная вещь до тех пор пока код помещается в микроконтроллер и работает с необходимой скоростью. Конечно, когда пишешь какие-то библиотеки или тот же стартап, то надо писать оптимально, ибо использоваться будет в разных проектах и это не станет узким местом в будущем. Но если надо на F4 написать мигалку светодиодом, то нет никакого смысла тратить время на "утаптывание" кода. Спасть лучше от осознания, что прошивка занимает всего 1 кБ из 1 МБ я точно не буду.

ddr4 писал(а):

А я и ардуину не отлаживал на чипе, только на компе куски кода и через printf(), с этим можно жить.

Одно дело когда подруцгому никак, то довольствуешься тем что есть. Но когда есть возможность отладки, это совершенно другой стиль разработки.

ddr4 писал(а):

Но не всё так просто оказалось

Ерунда, всё реально. Было бы желание.

Добавлено after 8 minutes 48 seconds:

Мурик писал(а):

И это не совсем переменная. Это скрытая запись в энергонезависимую память.

В терминах языка программирования, на котором написан код, это именно переменная и есть. Я могу с ней работать как с любой другой - присваивать значения, копировать, выполнять арифметические операции, передавать значения в функции и т.д. Во что это компилируется вообще не имеет никакого значения. Например, при копировании структур или массивов компилятор частенько вызывает незаметно для программиста функцию memcpy. Вы же не отказываете из-за этого им в праве называться переменными?

Мурик писал(а):

С таким же успехом можно разрешить запись во флеш и записывать вызовом FLASH_ProgramByte() или подобной.

А вот это совсем другое. Если бы компилятор сделал всё это незаметно для программиста, как в приведённом мной примере, то да. А так НЕТ!

[AVI-crak]

С секциями init_array - даже у меня вопросы имеются.
Так это, там хранятся адреса конструкторов глобальных объектов.

Вот только сейчас додумался как правильно сформировать запрос для гугла, и за 5 минут узнал всё что хотел.
И таки да, всё связанное с С++, С#, всем тем зоопарком что выше. К функции SystemInit() вообще ни как не относится. Даже сами авторы GCC считают _array некрасивым, уродливым решением. Но ничего лучше предложить не могут.

[VladislavS]

AVI-crak писал(а):

И таки да, всё связанное с С++, С#, всем тем зоопарком что выше.

Намекаю второй раз уже в этой теме. В GCC конструкторы могут быть не только в С++, но и в православном С. Как бы странно это не звучало.

[Мурик]

Намекаете что в проекте могут быть вперемешку *.c и *.cpp файлы или о чем-то другом?
В описании языка Си не встречал упоминаний о конструкторах в структурах или о классах.

[VladislavS]

Это расширение GCC, стандарт С такого не предусматривает. Тык!

[Мурик]

Тогда понятно.
В GCC есть много чего не входящего в стандарт, например вложенные функции.

[VladislavS]

Однако, стартап написан для GCC и должен поддерживать все его возможности. Просто так выкинуть из стартапа вызов конструкторов из-за того что вы не используете С++ можно только из-за великой жадности.

[AVI-crak]

Намекаю второй раз уже в этой теме. В GCC конструкторы могут быть не только в С++, но и в православном С.

Спасибо, я уже наступил на эту лепёшку. Мне всегда подобный код казался странным и непонятным. После глубоко_копания в разные стороны - ощущение укрепилось, мне этого не надо.
Гораздо проще работать с памятью явно и прямо здесь, а не ожидать что память выделится магическим образом через вызов функции из исполняемого файла в другом каталоге проекта.
Ну да, С++ у меня не очень, точнее вообще никак.

ddr4 писал(а):
Там отлаживаю на коде для компа, или перепрошивкой с выводом значений printf().
Это не отладка, а много зря потеряного времени!
Вот смотрите просмотр регистров под отладчиком. Как это сделаете на printf()?

Я уже неоднократно замечал - человек не в состоянии принять и понять информацию, если она имеет базовый конфликт с его опытом.
Кхм, думаю если ему показать левую колонку видимых функций и переменных - он вообще ничего не поймёт. Как например я не понимаю, откуда аурдинщики берут имена функций: без встроенной подсказки, без автоматического дополнения, без динамической фильтрации типов, без той самой левой колонки любой нормальной IDE. Наверное по старинке, из бумажной книжки.

[VladislavS]

AVI-crak писал(а):

Как например я не понимаю, откуда аурдинщики берут имена функций:

Копипастят друг у друга... Ардуина, кмк, сильна сообществом.

[ddr4]

AVI-crak писал(а):

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

Да именно так. Так как большинство ожидает от STM32 уровня программирования даже не Ардуино-IDE, а хотя бы AVR (avr-gcc), но нет, в STM всё намного хуже. И когда после AVR человек пытается использовать STM, он получает отрицательные эмоции во-первых от настройки стартапа, которого в AVR нет. И утешает себя ну мол ладно, стартап переварю и дальше всё пойдёт. Но тут бах и - HAL. И первая реакция, ну ладно, в AVR тоже были библиотеки абстракций, и здесь я избавлюсь от HAL. И чел пытается смотреть примеры без HAL, а там тоже какой-то ужас, и получает ещё отрицательных эмоций с попыткой разбить BluePill об стену . После чего говорит, ну ладно буду использовать этот ужасный HAL. Берёт пример с hal-uart - print "Hello World" ковыряется в библиотеке включая нужные дефайны. Запускает и ..... облом . Копаясь в куче ошибок компилятора ... понимает. Что в этом примере "Hello World" - другая версия HAL и тут терпению приходит конец, как и BluePill'у .
И после таких приключений , кто-то пишет ещё один отрицательный отзыв о STM32, что это ужас-ужас. (и это отзывы не Арудинщиков начального уровня ).
Что вы уже "неоднократно замечали".

AVI-crak писал(а):

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

В AVR для выполнения реальной задачи оперируют 10 функциями в 2-3 файлах, а в STM32 чтобы вывести строку "Hello World" надо оперировать 100 функций расположенной в двух библиотеках. И тогда потребуется IDE не для того чтобы удобно писать код, а для того чтобы исследовать код библиотек, стартапав и прочего. И вот когда вы с этим разберётесь (с помощью IDE - которую вам тоже придётся изучить) - добро пожаловать в STM32.
И какое сообщество может быть у STM32 с такими граблями?
Цены на AVR подтверждают всё вышесказанное. )

[JackSmith]

ddr4 писал(а):

И чел пытается смотреть примеры без HAL, а там тоже какой-то ужас, и получает ещё отрицательных эмоций с попыткой разбить BluePill об стену .

Ой, а можно посмотреть эти "ужасные" примеры? Просто как раз пишу на CMSIS и оч. любопытно чего вы такого ужасного там нашли?

[MLX90640]

А что ужасного в STM32? Это просто гораздо более мощный микроконтроллер с гораздо более высоким порогом вхождения, для более умных и опытных программистов. Документация - да, на порядок объемнее. Про стартап линкерскрипт уже сто раз объяснили. Автор вопроса либо тупит, либо капризничает. Ну да, STM32 гораздо сложнее, это вы ещё не видели системы тактирования в каком-нибудь STM32H743. Но это просто совершенно иной уровень. Если программист не тянет мозгом, то незачем и начинать. А то как в басне про обезьяну и очки.

Автору - не волокешь, не хватает соображаловки, мозги не проворачивают объем информации - просто не лезь в эти дебри, сдохнешь. STM не виноват, что он сложный. Виноват программист, недостаточно подготовленный и не понимающий. А ведь есть и гораздо более сложные системы, для весьма подготовленных специалистов.

Последний раз редактировалось MLX90640 Вс авг 28, 2022 12:05:21, всего редактировалось 1 раз.

[Мурик]

но нет, в STM всё намного хуже.

Это не так. Нет необходимости на начальном этапе разбираться со стартапом и скриптом линкера. Они добавляются в проект при его создании в IDE.
Ваша задача, создать проект и писать код. Но вы решили все усложнить.
Смотрите, проект создается и все сразу готово к компиляции прошивки без необходимости править стартап и скрипт линкера.

Спойлер

Зачем вы решили все усложнить, непонятно.

И когда после AVR человек пытается использовать STM, он получает отрицательные эмоции во-первых от настройки стартапа

Зачем вы полезли его настраивать?
В этом нет необходимости. Сами себе создали сложности!

Но тут бах и - HAL.

Можно писать без HAL. Это одна из библиотек и никто не заставляет ее использовать.