реклама на сайте
подробности

 
 
> Embedded C++, Кто какие библиотеки использует?
segment
сообщение Oct 28 2010, 12:12
Сообщение #1


Местный
***

Группа: Участник
Сообщений: 352
Регистрация: 10-08-06
Из: Санкт-Петербург
Пользователь №: 19 471



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

Само собой использование STL в программе под микроконтроллер сомнительно, так как, к примеру, работа с STL в Keil uVision 4 (видимо их порт STL) обходится в минимум 40 Кбайт (собрал пример из Keil examples). Поэтому выходом из этой ситуации вижу использование либо специальных готовых light библиотек либо написание базовых шаблонов/классов самому. Но так уже стадия "начинающий и все хочу попробовать" прошла уже давно, поэтому писать самому не сильно тянет.
Кто какие C++ библиотеки использует для работы с периферией и данными?
Go to the top of the page
 
+Quote Post
5 страниц V  < 1 2 3 4 > »   
Start new topic
Ответов (15 - 29)
Major
сообщение Sep 6 2012, 01:37
Сообщение #16


Знающий
****

Группа: Свой
Сообщений: 618
Регистрация: 7-12-04
Из: Новосибирск
Пользователь №: 1 375



Указатели на структуры - это практически когда возникает аналог this.
Есть функции и им передается инкапсулированное состояние состояние процесса (объекта). Пример - конечный автомат приема и обработки потока данных. Если такой процесс один, то в языке C можно закрыть доступ через описатели static внутри модуля, экспортируя толко нужные функции. Если процессов несколько, а код для них один, то на С вы начнете делать сами ++.
Полиморфизм - у вас есть абстрактный интерфейс, его наследуете и реализуете. Обработчику передаете указатель на абстрактный интерфейс.
Легко подменить реализацию, сделав параметрическую фабрику объектов. Некоторые в таких случаях делают через указатели на функции и самописные виртуальные таблицы.

По поводу ненужного в C и C++ спорить не хочется.
Во встроенных системах я старюсь избегать динамического перераспределения памяти. Если конкретно - память это не конкурентный ресурс.
Размеры областей памяти под все структуры расписаны на этапе компиляции. То есть если это будет std::list, то я приложу все усилия чтобы буфер под узлы был выделен при инициализации и не изменял свой размер при эксплуатации (сам list при этом динамический).
Мой подход к памяти упрощает анализ устойчивости системы на основе отчета компилятора.

Все написанное относится к АРМ (любым) с к компилятором Keil (ARM). Этому компилятору я верю, потому что много смотрел на код который он создает.

P.S.
На больших системах я себе ни в чем не отказываю. И boost и все остальное использую (и динам. память со смарт указателями).
Go to the top of the page
 
+Quote Post
beaRTS
сообщение Sep 6 2012, 02:19
Сообщение #17


Местный
***

Группа: Участник
Сообщений: 211
Регистрация: 27-12-11
Из: Челябинск
Пользователь №: 69 111



Цитата(Major @ Sep 6 2012, 05:37) *
Указатели на структуры - это практически когда возникает аналог this...

очень занимательно!!!
Выходит, разработчик-embedder в итоге, как ни крути, становится (должен стать/должен быть) полноценным программистом С++ (в смысле, которых специализированные кафедры выпускают) ??? таков путь развития?

Сообщение отредактировал beaRTS - Sep 6 2012, 02:41


--------------------
"Об уме человека вернее судить по его вопросам, нежели по его ответам" (с)
Go to the top of the page
 
+Quote Post
Major
сообщение Sep 6 2012, 03:09
Сообщение #18


Знающий
****

Группа: Свой
Сообщений: 618
Регистрация: 7-12-04
Из: Новосибирск
Пользователь №: 1 375



Ну про пути я говорить не буду sm.gif Есть мнения что C++ уже умер как перспективный ООП в широком смысле (и мне кажется есть основания).

Хочу отметить что большинство GNU проектов пишутся на C, и реализуют каждый раз C++. Причины:
1. Каждый певец в ООП поет по своему, чатос не понимая нот.
2. Документировать ООП сложнее (особенно когда широкая и глубокая родословная классов и интерфейсов)
3. В среде ГНУ не любят подчинения архитекторам (главным инженерам)

В своих работах надо это учитывать.
Читать ООП код написанный не по типовым шаблонам (Гамма и компания) и с размахом в наследовании очень тяжело.
Если кратко: тестовые наборы (test-case) и самодокументирование кода это обязанность программиста.
Go to the top of the page
 
+Quote Post
haker_fox
сообщение Sep 6 2012, 03:25
Сообщение #19


Познающий...
******

Группа: Свой
Сообщений: 2 963
Регистрация: 1-09-05
Из: г. Иркутск
Пользователь №: 8 125



QUOTE (Major @ Sep 6 2012, 09:37) *
Во встроенных системах я старюсь избегать динамического перераспределения памяти.

В моем случае ситуация следующая. Есть сеть. К этой сети могут быть подключены приборы. Количество не превышает 32. Но может быть 32 одинаковых прибора, а может быть 32 совершенно разных. А могут быть пять одинаковых, и десять - разных. Всем этим делом рулит "мастер", у которого программа скомпилирована раз и навсегда и не меняется. Я имею в виду системное ПО. О конфигурации приборов он или сам спрашивает, или ему услужливо "дают" список rolleyes.gif

Для каждого прибора свой драйвер, за исключением одинаковых приборов.

Вот так и получается, что "поняв", чем ему придется управлять, он выделяет необходимое количество памяти для драйверов. Буду рад услышать как это можно сделать без использования кучи rolleyes.gif


--------------------
Выбор.
Go to the top of the page
 
+Quote Post
beaRTS
сообщение Sep 6 2012, 04:23
Сообщение #20


Местный
***

Группа: Участник
Сообщений: 211
Регистрация: 27-12-11
Из: Челябинск
Пользователь №: 69 111



Цитата(Major @ Sep 6 2012, 07:09) *
Есть мнения что C++ уже умер как перспективный ООП в широком смысле (и мне кажется есть основания).

чую - пахнет холиваром =)) maniac.gif . но я даж спорить не будут - не компетентен))

Цитата(Major @ Sep 6 2012, 07:09) *
Ну про пути я говорить не буду sm.gif

а почему? все так запутанно? или как у Кастанеды: "Каждый идет своим путем. Но все дороги всё равно ведут в никуда. (прим. к смерти) Весь смысл в самой дороге, как по ней идти, дорога должна быть "с сердцем": если идешь с удовольствием, значит, это твоя дорога. Если тебе плохо – в любой момент можешь сойти с нее, как бы далеко ни зашел. И это будет правильно"

Сообщение отредактировал beaRTS - Sep 6 2012, 05:04


--------------------
"Об уме человека вернее судить по его вопросам, нежели по его ответам" (с)
Go to the top of the page
 
+Quote Post
Major
сообщение Sep 6 2012, 05:10
Сообщение #21


Знающий
****

Группа: Свой
Сообщений: 618
Регистрация: 7-12-04
Из: Новосибирск
Пользователь №: 1 375



Цитата
Вот так и получается, что "поняв", чем ему придется управлять, он выделяет необходимое количество памяти для драйверов. Буду рад услышать как это можно сделать без использования кучи


У вас нет динамического распределения памяти, в классическом смысле.
Динамика это когда в рамках процесса (процессора) разные потоки исполнения в ходе работы запрашивают память и возвращают ее.
Время жизни объектов на куче неизвестно или сложно предсказуемо.
Когда функция запрашивает динамическую память есть вероятность отказа (исчерпание кучи).
Есть еще вариант когда многопроцессная система (есть ОСь) имеет менеджер памяти и память как ресурс раздается по приоритету. Такое приходится делать, ноя стараюсь избегать если имею достаточное количество памяти.
В моем опыте это упрощает запуск системы и позволяет снизить количество гонок за ресурсы. Если памяти мало, то конечно блочная куча.

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

Я не использую в эмбеддед постоянно создание и удаление объектов, как это делается на ПК (например динамические строки и stringbuilder).
И не использую не из-за времени исполнения, а из-за сложность обработки отказов в памяти и возможной фрагментации кучи (время жизни ВКЛ-ВЫКЛ от месяца до годов).
Я не использую исключения для возврата кода ошибки. Всегда проверяю код возврата.
Но использую исключения когда надо пробросить информацию об отказе на самый верх, где будет принято решение о перезагрузке или еще что-то.
На ПК все можно и надо делать наоборот (это может упростить архитектуру и повысить уровень обработки ошибок).

Если закрывать тему, то скажу что С++ надо использовать если вы понимаете, что начинаете его реализовать сами, при помощи семантики языка С. Компилятор Keil(ARM) дает качественный код С++.



Go to the top of the page
 
+Quote Post
dxp
сообщение Sep 6 2012, 06:59
Сообщение #22


Adept
******

Группа: Свой
Сообщений: 3 469
Регистрация: 6-12-04
Из: Novosibirsk
Пользователь №: 1 343



QUOTE (beaRTS @ Sep 6 2012, 11:23) *
чую - пахнет холиваром =)) maniac.gif . но я даж спорить не будут - не компетентен))

Да не, ничем тут не пахнет. С++ - низкоуровневый язык, и в этой нише ему замены нет. Просто по мере развития элементной базы и аппаратных платформ всё больше появляется возможностей для использования более высокоуровневых средств, включая языки программирования, библиотеки, фреймворки. Не редкость уже случаи, когда на embedded платформах используют виртуальные машины и скриптовые движки (жаба, шарп, питон и т.п.), в то время как и на настольных машинах есть место для низкоуровневых языков C/C++, когда надо выжимать производительность.


--------------------
«Отыщи всему начало, и ты многое поймёшь» К. Прутков
Go to the top of the page
 
+Quote Post
beaRTS
сообщение Sep 6 2012, 07:16
Сообщение #23


Местный
***

Группа: Участник
Сообщений: 211
Регистрация: 27-12-11
Из: Челябинск
Пользователь №: 69 111



Цитата(dxp @ Sep 6 2012, 10:59) *
Да не, ничем тут не пахнет. С++ - низкоуровневый язык, и в этой нише ему замены нет. Просто по мере развития элементной базы и аппаратных платформ всё больше появляется возможностей для использования более высокоуровневых средств, включая языки программирования, библиотеки, фреймворки. Не редкость уже случаи, когда на embedded платформах используют виртуальные машины и скриптовые движки (жаба, шарп, питон и т.п.), в то время как и на настольных машинах есть место для низкоуровневых языков C/C++, когда надо выжимать производительность.

да, было внутреннее ощущение, что скоро грани совсем размоются.
Я тут с Питоном познакомился недавно (поверхностно) - понравилось. Его обычно как в embedded используют: пишутся скрипты-тесты, генерирующие входные данные для железяки и программы в ней, написанной, например, на С++ ??? а потом эти тесты анализируют то, что на выходе получено, и говорят "все ок" или "давай, до свиданья" biggrin.gif ?

Сообщение отредактировал beaRTS - Sep 6 2012, 07:17


--------------------
"Об уме человека вернее судить по его вопросам, нежели по его ответам" (с)
Go to the top of the page
 
+Quote Post
ReAl
сообщение Sep 6 2012, 07:35
Сообщение #24


Нечётный пользователь.
******

Группа: Свой
Сообщений: 2 033
Регистрация: 26-05-05
Из: Бровари, Україна
Пользователь №: 5 417



Цитата(haker_fox @ Sep 6 2012, 06:25) *
В моем случае ситуация следующая. Есть сеть. К этой сети могут быть подключены приборы. Количество не превышает 32. Но может быть 32 одинаковых прибора, а может быть 32 совершенно разных. А могут быть пять одинаковых, и десять - разных.
...
Буду рад услышать как это можно сделать без использования кучи rolleyes.gif


Коротко: Искать по нашему форуму по словам placement new

Длиннее:
* Раз может быт 32 одинаковых, то может быть 32 максимального размера, так что можно выделить память сразу на 32 максимального размера. Расход памяти при этом может даже уменьшиться, так как не будет потрачено на управляющие структуры менеджера памяти.
* Раз конфигурируется динамически, то так или иначе во время выполнения определяется тип — толи switch/case, толи виртуальными функциями. Пусть будет полиморфизм.
Код
union {
   TDeviceTtype_1  device_type1;
   TDeviceTtype_2  device_type2;
   TDeviceTtype_3  device_type2;
} TAllDevices;

TAllDevices all_devices[max_devices];
Дальше используем пункт "коротко". Ну еще нужна переменная device_count, но она была бы нужна для массива указателей на TBaseDevice для случая выделения через new.


--------------------
Ну, я пошёл… Если что – звоните…
Go to the top of the page
 
+Quote Post
alx2
сообщение Sep 7 2012, 05:16
Сообщение #25


Местный
***

Группа: Участник
Сообщений: 340
Регистрация: 25-10-05
Из: Пермь, Россия
Пользователь №: 10 091



Цитата(haker_fox @ Sep 6 2012, 04:51) *
Да, Си++ иногда тянет за собой кучу ненужного и тяжелого
А что именно? Мне кроме исключений (которые можно отключить при компиляции) ничего в голову не приходит...

Цитата(haker_fox @ Sep 6 2012, 04:51) *
На AVR я с этим не сталкивался, но столкнулся на ARM7TDMI, когда захотел использовать динамическую память (оператор new). Как только использовал, так код с 40 кБ вырос до 300 кБ.
Пока чихаю на это, т.к. идет отладка. Но потом хочу прикрутить "легкую" реализацию менеджера памяти, любезно представленного уважаемым zltigo, и не менее любезно адаптированным к Си++ уважаемым Сергеем Борщем.
Сейчас провел "экспресс-тест". Весь код программы, использующей new и delete, составил меньше 9 килобайт (arm7tdmi). Почему у Вас new/delete потянули дополнительные 260 килобайт, ума не приложу. Тем более, что Вы не используете исключения... В любом случае, к языку C++ как таковому это не имеет отношения. Напротив, наличие в языке этих операторов (и, главное, возможность их перегружать по своему усмотрению) дает программисту возможность более тонко контролировать работу с памятью. В тривиальном случае new/delete могут работать через malloc/free и, таким образом, ничем не будут отличаться от аналогичного кода на языке C. Ничего "ненужного" эти операторы сами по себе не "тянут".


--------------------
Всего наилучшего,
Alex Mogilnikov
Go to the top of the page
 
+Quote Post
sasamy
сообщение Sep 7 2012, 17:41
Сообщение #26


Знающий
****

Группа: Участник
Сообщений: 783
Регистрация: 22-11-08
Пользователь №: 41 858



Цитата(dxp @ Sep 6 2012, 10:59) *
Да не, ничем тут не пахнет. С++ - низкоуровневый язык, и в этой нише ему замены нет.


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

Сообщение отредактировал sasamy - Sep 7 2012, 21:02
Go to the top of the page
 
+Quote Post
dxp
сообщение Sep 8 2012, 02:49
Сообщение #27


Adept
******

Группа: Свой
Сообщений: 3 469
Регистрация: 6-12-04
Из: Novosibirsk
Пользователь №: 1 343



QUOTE (sasamy @ Sep 8 2012, 00:41) *
Для чистого С как кроссплатформенного ассемблера замены нет и не будет, а вот С++ - это ваше имхо разумеется, очень сильно расходящееся с реальностью. Чтобы не разводить холливар - чем больше ЯП вы владеете тем лучше, но важней изучить парадигмы программирования а не реализации их в конкретных ЯП, в конце концов важнее знание предметной области, а ЯП как инструмент вторичен.

C - портабельный макроассемблер, с этим никто не спорит. Что ему замены нет да ещё и не будет - это сильное преувеличение - С++ с успехом заменяет С где угодно. Не стоит забывать, что С является подмножеством С++. Попробуйте доказательно оспорить тезис: "Где уместен С, там уместен и С++".

За моим "имхом" почти полтора десятка лет использования С++, из них десяток в embedded - у меня на глазах и с моим участием происходило проникновение С++ в эту область, поэтому я транслирую собственный опыт и опыт многих очень квалифицированных инженеров, некоторые из которых являются постоянными участниками и этого форума. Сегодня С++ - мэйнстрим в embedded, это факт. Не трогайте моё "имхо", я не буду трогать ваше. Лучше объективные аргументы приводите. Что С++ не заменяется С, с этим спорить не нужно, ибо зря, т.к. не заменяется. То, что немало упёртых линуксоидов во главе с Торвальдсом, который однажды 20 лет назад попробовал С++, находящийся в процессе роста и не имевший многих нынешних средств и но имевший много "детских болезней", не любят плюсы, это объективно характеризует их. Почти во всех случаях оные люди просто не знают С++ хоть сколько-нибудь глубоко (а главное - не желают знать, потому и не знают). Не принимайте на свой счёт, это общее наблюдение (не только моё) за много лет.


--------------------
«Отыщи всему начало, и ты многое поймёшь» К. Прутков
Go to the top of the page
 
+Quote Post
halfdoom
сообщение Sep 8 2012, 03:50
Сообщение #28


Профессионал
*****

Группа: Свой
Сообщений: 1 003
Регистрация: 20-01-05
Пользователь №: 2 072



Совсем не давно, после длительного обсуждения с заказчиком (запад ЕС) платформы для прибора получили следующее на предложение об использовании плюсов:

Цитата
Decision: accept a C-only code with minimal number of native assembler lines.
Reasoning: C++-code requires significant additional costs on verification staff, not an industry mainstream.


И все, либо проходите мимо, либо пишите на C.
Go to the top of the page
 
+Quote Post
dxp
сообщение Sep 8 2012, 05:54
Сообщение #29


Adept
******

Группа: Свой
Сообщений: 3 469
Регистрация: 6-12-04
Из: Novosibirsk
Пользователь №: 1 343



А что это вот такое:
CODE
C++-code requires significant additional costs on verification staff


Какой смысл стоит за этой фразой? У меня вариант такой: "У нас нет специалистов достаточной квалификации, способных понимать и сопровождать С++ код, поэтому пишите на С".


--------------------
«Отыщи всему начало, и ты многое поймёшь» К. Прутков
Go to the top of the page
 
+Quote Post
Major
сообщение Sep 8 2012, 06:10
Сообщение #30


Знающий
****

Группа: Свой
Сообщений: 618
Регистрация: 7-12-04
Из: Новосибирск
Пользователь №: 1 375



Еще раз вмешаюсь.
C++ это язык, возможности которого шире чем C.
Я уже привел доводы почему в ГНУ используют в основном С,реализуя элементы С++.
Мощь С++ в ООП (ООД). Без ООП С++ это всего лишь расширение С. ООП это годы тренировок и учебы.
При этом делать попытки ООП на чистом С, реализуя каждый раз велосипед, это торможение в развитии.

Многие лекарства ядовиты в дозах больше чем 100мгр. Но это не означает что их не надо изготовлять и пользоваться. Горчичник я могу сам сделать, но для антибиотика нужны фармацевты и провизоры.

Go to the top of the page
 
+Quote Post

5 страниц V  < 1 2 3 4 > » 
Reply to this topicStart new topic
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0

 


RSS Текстовая версия Сейчас: 23rd July 2025 - 22:34
Рейтинг@Mail.ru


Страница сгенерированна за 0.01508 секунд с 7
ELECTRONIX ©2004-2016