VladislavS, да кто же Вас учит? Правильно, изучать надо С, а не его подмножество, не позволяющее даже использовать стандартные для целевой платформы библиотеки. И это будет быстрей, проще и эффективней, чем доставать левой ногой правое ухо, пытаясь на подмножество языка программирование изобразить что-то вразумительное. А зная язык и изучая доступные коды этих самых стандартных библиотек и переферию изучить будет заметно проще.
Мурик, нулевое кольцо защиты и привилегированный режим процессора - синонимы. Просто на тех системах, где только два кольца защиты, их нередко называют privileged и user mode. На тех же системах, где этих колец защиты больше двух - их нумеруют. Например, на x86 четыре кольца защиты. На ARM - два или три, в зависимости от модели.
Мурик писал(а):
библиотеки от производителя более оптимальны
Я писал "стандартные библиотеки" и отношу к стандартным, в том числе, и библиотеки производителя. Вы считаете их не стандартными? Почему?
Мурик писал(а):
Речь идет о МК, а не PC и других платформах.
Изучение языка или иного способа коммуникации с объектом изучения первично для любых платформ, да и вообще всех сфер человеческой деятельности. Например, научиться управлять автомобилем можно и не зная его устройство. Но научиться ремонтировать автомобиль, не умея им управлять - мало реально. Так же и на Cortex-M можно быть профессионалом, даже не заглядывая ни разу в описания регистров Ethernet контроллера, но пользуясь им через библиотечные функции.
Любая разработка начинается с чтения документации и изучения доступных средств разработки. Данный материал целиком посвящен средствам разработки, включая детальные инструкции по запуску вашего первого приложения на BlueNRG-LP. Описана работа с отладкой STEVAL-IDB011V1, набором инструментов и пакетом ПО позволяющим разработчику быстро войти в курс дела.
нулевое кольцо защиты и привилегированный режим процессора - синонимы.
В МК нечасто используется привилегированный режим. Необходимости нет. Даже в популярных ОС (например FreeRTOS) он не используется.
ПростоНуб писал(а):
Я писал "стандартные библиотеки" и отношу к стандартным, в том числе, и библиотеки производителя. Вы считаете их не стандартными?
Я писал что лучше использовать библиотеки от производителя МК, а не ядра, хотя бы потому что производитель ядра не имеет отношения к периферии. Это все равно что искать драйверы на дискретную видеокарту или USB устройство у производителя CPU.
ПростоНуб писал(а):
Так же и на Cortex-M можно быть профессионалом, даже не заглядывая ни разу в описания регистров Ethernet контроллера, но пользуясь им через библиотечные функции.
Ethernet контроллер это периферия и библиотеку нужно брать у производителя МК, а не у производителя ядра ARM, потому что он к периферии отношения не имеет.
dosikus, без хамства и перехода на личности общаться не можете?
Что привлекает в SiC по сравнению с кремнием, и какие особенности делают компоненты SiC часто используемыми, несмотря на более высокую стоимость в сравнении с кремниевыми высоковольтными устройствами? – Объясняет специалист ведущего разработчика силовых приборов из карбида кремния, компании Infineon.
Мурик, Вы так и не ответили на вопрос. Почему библиотеки производителя МК Вы считаете не стандартными?
По поводу привилегированного и пользовательского режима Вы сильно заблуждаетесь. На ARM он использует очень часто, так как заметно увеличивает надежность готовой продукции. Про FreeRTOS Вы опять не правы. Переход в пользовательский режим и работу в нем он поддерживает.
dosikus, я ни во что вообще не верю, тем более в галиматью.
Мурик, Вы так и не ответили на вопрос. Почему библиотеки производителя МК Вы считаете не стандартными?
Где я написал что они нестандартные?
ПростоНуб писал(а):
На ARM он использует очень часто
ARM это множество ядер процессоров с разными возможностями. В данном случае речь идет о МК с ядрами Cortex-M. Не так часто нужно использование привилегированного и пользовательского режимов.
лучше освоить стандартные библиотеки для работы с этой переферией.
Как правило библиотеки от производителя более оптимальны.
И не судите по себе. Использование привилегированного и пользовательского режима существенно повышает надежность готовой продукции. При выполнении кода только в привилегированном режиме, любая ошибка в программе и даже переполнение стека приведут к неработоспособности МК, по крайней мере до перезагрузки по таймауту. А при выполнении этого же кода в пользовательском режиме, отвалится только одна нить, которая благополучно может быть перезапущена сразу же.
По вашему слова "оптимальные" и "нестандартные" являются синонимами? Вы предложили использовать функции ARM_CAN_Initialize(), ARM_I2C_Initialize() и другие из CMSIS-Driver на что я ответил что для STM32 есть библиотеки от производителя, SPL, HAL, LL и т. д. которые более оптимальные.
Мурик, по моему, возражать предложению освоить стандартные библиотеки, утверждением, что библиотеки производителя оптимальней, исключает последние из "стандартных" по мнению возражающего.
И я ничего не предлагал. Я только указал, что в данных функциях используются параметры указатели на callback функции. Просто констатировал факт.
А ограниченное количество памяти вынуждает пользоваться динамическими структурами данных (а значит и указателями на указатели), вместо так любимых начинающими массивов.
Ограниченное количество памяти вынуждает тратить её больше? Сами разве не замечаете противоречия в своих словах? Нужность дин.памяти и размер ОЗУ - вещи вообще никак не связанные между собой. Подавляющее большинство написателей программ пользуют дин.память из-за своей некомпетентности, а не необходимости. Так же как и float/double, там где достаточно целых типов.
Тот же граф (или его вырожденный случай - дерево) без динамической памяти не обойти. Ну если Вы, конечно, не против зависания своего МК по переполнению стека
Здорово! Впервые слышу чтобы дин.память увеличивала размер стека. Не поделитесь секретами магии?
jcxz, еще один "чукча не читатель, чукча писатель"? А почитать? На подавляющее большинство Ваших вопросов уже даны выше ответы.
Кто Вам в голову вообще вбил знак равенства между "динамическими структурами данных" и "динамической памятью"? Вы вообще об обходе графа почитайте, чтобы не позориться тут публично. Там только два вида вариантов имеются, либо рекурсивные, когда мы не контролируем стек и в любой момент можем нарваться на его переполнение, или не рекурсивные, но уже только через динамическое распределение памяти.
Кто Вам в голову вообще вбил знак равенства между "динамическими структурами данных" и "динамической памятью"?
Если вы какой-то свой птичий язык изобретаете - так разъясняйте его понятия. А "дин.память", как и "дин.распределение памяти" - в си имеет совершенно чёткое определение. А значит и "динамическое" - в понятиях си будет относится к созданному в динамической памяти. Вот когда свой язык программирования изобретёте, тогда и будете устанавливать свои правила.
Вы вообще об обходе графа почитайте, чтобы не позориться тут публично. Там только два вида вариантов имеются, либо рекурсивные, когда мы не контролируем стек и в любой момент можем нарваться на его переполнение, или не рекурсивные, но уже только через динамическое распределение памяти.
Если у вас ума хватает только на это, то это совсем не говорит о том, что не существует других путей реализации.
jcxz, алгоритм обхода графа без рекурсии и динамического выделения памяти в студию!
А динамические структуры данных в С никто не запрещает размещать в статически выделенной памяти. Более того, большое количество программных продуктов аналогичным образом и поступают, работая в фиксированном объеме памяти, определяемом при инициализации. Просто потому, что это быстрее и эффективнее, чем пользоваться динамическим распределением хоть сишного хепа, хоть системы.
Как часто вам это проходится использовать в МК, особенно тех что имеют мало памяти? Не помешают примеры устройств где это понадобилось и по другому сделать не получилось.
ПростоНуб писал(а):
А динамические структуры данных в С никто не запрещает размещать в статически выделенной памяти.
Заново кучу изобрели? В простейшем случае создается массив заданного размера и его пространство используется для динамического выделения памяти. Именно так устроен менеджер памяти в FreeRTOS.
"Эвона чо! Граф приехал! Обойду-ка я его лесом, кабы не выпорол" - подумал Пафнутий.
_________________ если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе удивительно, но при взгляде на многих сверху ничего не меняется...
Как часто вам это проходится использовать в МК, особенно тех что имеют мало памяти? Не помешают примеры устройств где это понадобилось и по другому сделать не получилось.
Автор недавно узнал новое слово, вот теперь и старается блеснуть своей "эрудицией" на каждом углу к месту и не к месту.
Нередко. Даже на STM8L151C4 приходилось. Благо, конфигурация менялась редко, поэтому сам граф хранился в EEPROM, а в RAM - только битовая маска активности его узлов и ребер.
jcxz, жду алгоритма обхода графа без рекурсии и динамической памяти. Или Вы только трепаться можете, а отвечать за свои слова уже нет?
Сейчас этот форум просматривают: Zhuk72 и гости: 12
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения
Вход
Регистрация
Правила
FAQ
Поиск
