roboforum.ru

[devel]

Здравствуйте, уважаемые форумчане! Есть нубский вопрос - какую литературу посоветуете посмотреть по поводу программирования встраиваемых систем на языке C++? Только не отсылайте к учебникам, интересуют именно особенности/возможности применения/подводные камни разработки с применением плюсов. Целевая платформа - STM32F103. Спасибо.

[Michael_K]

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

[Romikgy]

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

PPS хотя для такого проца можно и плюсы применить ... был бы смысл

[devel]

вот эту статью посмотрите http://easyelectronics.ru/rabota-s-port ... na-si.html например.

[Michael_K]

Статья изначально декларирует странную аксиому, поэтому и выводы получены странные:
"Под эффективностью здесь следует понимать не только скорость выполнения и минимальный размер кода, но и эффективность написания и сопровождения кода."

Если немножко посмотреть на типовые применения микроконтроллеров (ну, например, стиральная машинка или какая-нибудь автосигнализация), то становится понятно несколько вещей:
Цена (время) разработки кода мало кого волнует - цена разработки "размазывается"
на партию изделий, да и подготовка к производству занимает всяко больше времени, чем разработка кода.

Гораздо более важным является эффективность исполнения кода -
эффективный код снижает требоваия к производительности, объему памяти контроллера,
позволяет выбрать более дешевый МК, снизить его потребление и т.п.

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

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

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

[=DeaD=]

Если немножко посмотреть на типовые применения микроконтроллеров (ну, например, стиральная машинка или какая-нибудь автосигнализация), то становится понятно несколько вещей:
Цена (время) разработки кода мало кого волнует - цена разработки "размазывается"
на партию изделий, да и подготовка к производству занимает всяко больше времени, чем разработка кода.

Это сильно зависит от масштаба. Сколько стоит месяц работы хорошего ембед-программера с накладными расходами? пусть 2K$. Переход с одного МК на аналогичный более дешевый скорее всего даст что-то типа 0.5$ выгоды не более, они же периферией в основном отличаются? Так что наверное правило "цена мало кого волнует" начинает работать где-то от 1-10 тысяч изделий, я правильно прикидываю?

[Michael_K]

Ну вы оцените, сколько ХОРОШИЙ эмбеддед-программер будет писать код для битиков в порту...
Сколько конкретно времени он сэкономит, если воспользуется классами? Ну пусть даже 15 минут...
Ну пусть даже час... o_O (я вообще не уверен, что он что-то сэкономит, но допустим)

Это окупится уже на десяти процах по полбакса.

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

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

[devel]

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

это частично подходит под мою задачу. есть и гуй и сети Ethernet, CAN, RS-485

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

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

[Michael_K]

это частично подходит под мою задачу. есть и гуй и сети Ethernet, CAN, RS-485

Ну, замечательно. Плюсы, как и любой другой инструмент, удобно использовать для своего круга задач. Если вы чувствуете, что ваши задачи хорошо ложатся на плюсы - вопросов нет. (использовать плюсы для битиков в порту - это "из пушки по воробьям", по-моему).

Возможные проблемы я написал чуть выше - поддержка компиляторами, как правило менее эффективный код на выходе. Хочу еще отметить поддержку отладчиками - отладчик тоже должен понимать неявную передачу параметра (который this)...

Увольте чуваков из отдела продаж!

[devel]

Увольте чуваков из отдела продаж!

Ну это уже не от меня зависит =)

Спасибо всем за ответы!

[DI HALT]

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

[Tiphon]

"Восток дело тонкое, Петруха" (с)
Как программист с 20 летним стажем, из которых 10 отдано С++ (и, к сожалению, отдается... и отдается... и отдается...) - могу сказать, что он - не нужен... в 90% мест, где его пихают, по крайней мере.

В полной своей обвеске С++ избыточен. В конечных приложениях на С++ стиль того, как приходится писать на столько разный в зависимости от того, какие библиотеки ты используешь! И всеми признанных правил тут фактически нет. Разница того, как выглядит твой код, логика и, не побоюсь сказать, мышление С++ программ на столько велика... Что можно скзать, С++ НЕ ЯВЛЯЕТСЯ языком программирования, а как бы конструктором. И самое ужасное, что каждый из этого конструктора делает свой "язык С++". А у каждого ли это хорошо получится?

Не у каждого. И тут работает правило 80/20, в том смысле, что только 20% пишут действительно грамотно вещи. Все бы ничего, если бы всегда люди сами себе писали бы плохие библиотеки и сами мучились... Но постоянно приходится работать с чужими библиотеками... А там... И при отсутствии стандартов... Ну вы поняли.

Более того, когда программы обретают громозкозть, особенности С++ начинают мешать даже при очень хорошо продуманном проходе. Реально. Посмотрите на мега фреймворки класса Qt, MFC и т.д. Ни один из них под С++ не обладает тем изяществом и логичной конструкцией, как те же наборы библиотек более высокоуровневых языков вроде Java, .Net, python. Может даже вроде все хорошо, но вот тут костыль, тат приходится использовать, сям...

В то время, как С - вполне себе самодостаточный язык.

Поэтому на высоком уровне С++ проигрывает .Net, Java, python и Ко. На низком - си... Остается достаточно узкая прослойка, где со всеми наворотами С++ оказывается оптимален...

Конечно, в историческом смысле С++ сыграл огромную роль. При этом, по историческим же причинам впитал в себя много детских ошибок зори разработки (параличную работу со строками от Си, например. А работа со строками за все время программирования человечеством, как известно, оценивается экспертами, как источник 60% найденных уязвимостей)

Значит Си хороший, С++ плохой? - а вот тут и дело тонкое. Ведь С++ можно, и многие используют, как "Си с инициализацией структур" и некоторыми другими С++ введениями. Быстродействие не страдает. Например, взять классы, даже вызов функций (тут, конечно, еще дело в компиляторе, но для gcc) пока нет виртуальной таблицы функций перформанс ничем не омрачается по сравнению с Си. И при использовании такого подхода многие известные Си заморочки вроде компоновки переменных для попадания в регистр/одну страницу памяти - вполне сохраняются.

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

По поводу вычислений эффективности с 0.5 чипом... ну они невыносимо далеко от реальной жизни. Вот только за 30 минут до чтения этой темы встретился мне американский фрилансер с опытом работы hardware+программингчас работы которого стоит 90$.
Я работаю с америкой, там оно там примерно и есть. При этом один удобный дебаггер может для кого-то стоить большей "эффективности" на порядок. В общем, не занимайтесь ерундовыми теорикрафтами.