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

Само собой использование STL в программе под микроконтроллер сомнительно, так как, к примеру, работа с STL в Keil uVision 4 (видимо их порт STL) обходится в минимум 40 Кбайт (собрал пример из Keil examples). Поэтому выходом из этой ситуации вижу использование либо специальных готовых light библиотек либо написание базовых шаблонов/классов самому. Но так уже стадия "начинающий и все хочу попробовать" прошла уже давно, поэтому писать самому не сильно тянет.
Кто какие C++ библиотеки использует для работы с периферией и данными?

Вообще-то должен. Посмотрите вот эту тему,
потом дополнительно убедитесь, что:

• вы не забыли ключики -fno-exceptions и -fno-rtti для компилятора;
• все варианты new() переопределены с nothrow;
• к проекту подключен вот этот файл;
• вы не забыли написать свой вариант _sbrk() (штатный вариант от codesourcery может тянуть за собой исключения. kgp в этом смысле лучше);

Я уверен, что после выполнения всех этих условий ваши волосы станут мягкими и шелковистыми

Все, что Вы перечислили у меня есть (от части из scmRTOS). Но шампунь не помогает) Волосы мягкими и шелковистыми не стали) В мап-файле видно, что тянутся исключения
Во вложениее полный map-файл...

А если взять kgp?
Или попробуйте скомпилировать приложенный пример. У меня он компилируется в следующие объёмы:
codesourcery : 32K
kgp : 18K.
 stm32_minimal_with_printf_and_new.zip ( 119.2 килобайт ) Кол-во скачиваний: 123

Ваш компилируется) Мой не компилируется сборкой от Клена( Просто выдает это

Кстати, а за счет чего kgp так рулит по объему (почти в два раза)?

Насколько я вижу из вашего map-файла, eh_exception.o тянет за собой ваш ./obj/main.o из-за использования std::ios_base::Init::Init().
Каким образом это связано с операторами new и delete, я не знаю...

Похоже это дело тянул <iostream>, который у меня был подключен. Я его исключил, и теперь код уменьшился в два раза ( 150 кБ). Если поключить файл new.cpp из проекта, выложенного выше уважаемым пользователем AHTOXA, то размер уменьшает до 50 кБ

Правда без я лишился строк Си++, которые очень удобны в работе...(

И какой объём у вас получился?
Видимо за счёт того, что klen специально боролся с исключениями. Или же наоборот, cs что-то понапихали своего.

ЗЫ. У кого есть YAGARTO, посмотрите пожалуйста, в какой объём компилится мой проект?


Ага! Значит всё же не был выполнен пункт

32500 (cs)
kgp вылетает с той же ошибкой(


Верно, слона-то я и не заметил

arm-none-eabi-gcc.EXE (GCC) 4.7.1

text data bss dec hex filename
27636 2244 600 30480 7710 ./exe/hello-stm32-printf-and-new.elf

Нет, не лишился. Но конструкторы строк за собой тянут около 100 кб дополнительно...

Кстати, классы, шаблоны, перегрузку и тп в embedded делаем, тут сомнений нет. А строки Си++ используем, или по старинке строки Си да что-нить printf-подобное? Я для себя сделал вывод, что последнее (т.е. printf) проще во встраиваемых приложениях, да и на большом брате тоже...

наткнулся на статью интересную Паттерны проектирования в Embedded . можете поделиться подобным образом (лучше, конечно, поподробнее, а если и с реальными примерами - будет здорово!) кто какие паттерны использует, какие полезны в embedded?

сейчас многие возбудятся, но патерны - это собственно для блондинок от программирования(чисто имхо). почему? очень просто. Читаете Буча(надеюсь авторитет одного из пап практического применения ООП и ООА не вызывает сомнений?) и видите, что помимо технических аспектов (полиморфизм, наследование и т.д.) всплывает очень мощная методология по переходу от задумки к коду. Именно методология. Именно она имеет ряд мощных плюсов. Ведь первым шагом идёт анализ задачи, нахождения сущностей, декомпозиция, нахождения связей и т.п.. Т.е. вы строите код от задачи(!). Т.е. если люди из предметной области говорят что машина крутит колёсами и перемещается из пункта А в пункт Б = то Вы используя именно эти сущности получаете статическое построение модели(!) которая не будет меняться во времени жизни всего проекта!!! Понимаете какая мощь? т.е. машина не превратиться в верблюда, а дорога в озеро! ни под каким соусом!!! Это только я озвучил первый плюс данной методы

ну а теперь возвращаемся к патернам. И ответьте мне - разве существуют в жизни одинаковые задачи? надеюсь смысл понятен? на мой взгляд инструмент патернов придумали для упрощения(читай снижения затрат) на обучение программистов(читай издержки производства) в эпоху 2000 годов, когда все домохозяйки шли в пилоты, тьху в программисты ну и к чему привело - понятно, шлёпнулось IT отрасль у них в 2001 (для тех кто не помнит).

по поводу, что читать.
не буду оригинален - Гради Буча естественно. Более того скажу - читать маловато будет. Именно стэп бай стэп конкретной вашей задачи сверяясь с книгой.

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

Задач одинаковых не существует. Смысл понятен.
Вот только, как по мне, паттерны = идиомы = методологии удобны при создании архитектурных частей системы. Тот же pimpl хорош, чтобы разделить абстрактный интерфейс, например, SPI от архитектурной реализации в используемом процессоре (регистры процессора). Потом просто достаточно менять реализацию под выбранный процессор - удобно, геммора меньше (ведь все мы ленивы, и делать одно и тоже сызнова для каждой новой задачи - не айс).
Делюсь найденными ссылками.
youdevelop : даны тезисы когда следует применять
Design Patterns for Real-time and Embedded System Design



за авторов спасибо! Закачаю, гляну

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

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

Сообщение отредактировал kolobok0 - Oct 8 2012, 09:41

ну да да. все логично говорите. согласен