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

Если уж на то пошло, то изучать надо С++, а не его подмножество не имеющее шаблонов, классов, пространств имён и т.д. и т.п.

В документе пишут про регионы памяти, а не про кольца защиты.

Как правило библиотеки от производителя более оптимальны. Для STM32 это SPL, HAL, LL и т. д.

Сначала нужно изучить Си и при необходимости изучать C++. Так будет проще.
Речь идет о МК, а не PC и других платформах.

Мурик, нулевое кольцо защиты и привилегированный режим процессора - синонимы. Просто на тех системах, где только два кольца защиты, их нередко называют privileged и user mode. На тех же системах, где этих колец защиты больше двух - их нумеруют. Например, на x86 четыре кольца защиты. На ARM - два или три, в зависимости от модели.


Я писал "стандартные библиотеки" и отношу к стандартным, в том числе, и библиотеки производителя. Вы считаете их не стандартными? Почему?


Изучение языка или иного способа коммуникации с объектом изучения первично для любых платформ, да и вообще всех сфер человеческой деятельности. Например, научиться управлять автомобилем можно и не зная его устройство. Но научиться ремонтировать автомобиль, не умея им управлять - мало реально. Так же и на Cortex-M можно быть профессионалом, даже не заглядывая ни разу в описания регистров Ethernet контроллера, но пользуясь им через библиотечные функции.

В МК нечасто используется привилегированный режим. Необходимости нет. Даже в популярных ОС (например FreeRTOS) он не используется.

Я писал что лучше использовать библиотеки от производителя МК, а не ядра, хотя бы потому что производитель ядра не имеет отношения к периферии.
Это все равно что искать драйверы на дискретную видеокарту или USB устройство у производителя CPU.

Ethernet контроллер это периферия и библиотеку нужно брать у производителя МК, а не у производителя ядра ARM, потому что он к периферии отношения не имеет.

dosikus, без хамства и перехода на личности общаться не можете?

Мурик, Вы так и не ответили на вопрос. Почему библиотеки производителя МК Вы считаете не стандартными?

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

dosikus, я ни во что вообще не верю, тем более в галиматью.

Где я написал что они нестандартные?

ARM это множество ядер процессоров с разными возможностями. В данном случае речь идет о МК с ядрами Cortex-M. Не так часто нужно использование привилегированного и пользовательского режимов.

Кто писал?

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

По вашему слова "оптимальные" и "нестандартные" являются синонимами?
Вы предложили использовать функции ARM_CAN_Initialize(), ARM_I2C_Initialize() и другие из CMSIS-Driver на что я ответил что для STM32 есть библиотеки от производителя, SPL, HAL, LL и т. д. которые более оптимальные.

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

И я ничего не предлагал. Я только указал, что в данных функциях используются параметры указатели на callback функции. Просто констатировал факт.

Вы не уточнили что подразумеваете под стандартными библиотеками. Возможно имеете в виду те же что и я.

А что в этом такого сложного? Даже для начинающего. Имя функции без скобок написать - сложно?

Ограниченное количество памяти вынуждает тратить её больше? Сами разве не замечаете противоречия в своих словах?
Нужность дин.памяти и размер ОЗУ - вещи вообще никак не связанные между собой.
Подавляющее большинство написателей программ пользуют дин.память из-за своей некомпетентности, а не необходимости. Так же как и float/double, там где достаточно целых типов.

Добавлено after 5 minutes 21 second:
Здорово! Впервые слышу чтобы дин.память увеличивала размер стека. Не поделитесь секретами магии?

jcxz, еще один "чукча не читатель, чукча писатель"? А почитать? На подавляющее большинство Ваших вопросов уже даны выше ответы.

Кто Вам в голову вообще вбил знак равенства между "динамическими структурами данных" и "динамической памятью"?
Вы вообще об обходе графа почитайте, чтобы не позориться тут публично. Там только два вида вариантов имеются, либо рекурсивные, когда мы не контролируем стек и в любой момент можем нарваться на его переполнение, или не рекурсивные, но уже только через динамическое распределение памяти.

Если вы какой-то свой птичий язык изобретаете - так разъясняйте его понятия. А "дин.память", как и "дин.распределение памяти" - в си имеет совершенно чёткое определение. А значит и "динамическое" - в понятиях си будет относится к созданному в динамической памяти.
Вот когда свой язык программирования изобретёте, тогда и будете устанавливать свои правила.

Если у вас ума хватает только на это, то это совсем не говорит о том, что не существует других путей реализации.

jcxz, алгоритм обхода графа без рекурсии и динамического выделения памяти в студию!

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

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

Заново кучу изобрели? В простейшем случае создается массив заданного размера и его пространство используется для динамического выделения памяти. Именно так устроен менеджер памяти в FreeRTOS.

"Эвона чо! Граф приехал! Обойду-ка я его лесом, кабы не выпорол" - подумал Пафнутий.

Как правило - маму/папу в помощь зовут, а тут графов с баронами.

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

Нередко. Даже на STM8L151C4 приходилось. Благо, конфигурация менялась редко, поэтому сам граф хранился в EEPROM, а в RAM - только битовая маска активности его узлов и ребер.

jcxz, жду алгоритма обхода графа без рекурсии и динамической памяти. Или Вы только трепаться можете, а отвечать за свои слова уже нет?

Добавлено after 2 minutes 6 seconds:

Куча универсальна, но медленна и фрагментирует память. Пул буферов менее универсален, но быстр и не имеет проблем с фрагментацией.

То есть вы пишите про массив структур определенного размера?