Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Компилятор GNU AVR GCC, использование STL
Форум разработчиков электроники ELECTRONIX.ru > Микроконтроллеры (MCs) > Cредства разработки для МК > GNU/OpenSource средства разработки
e-leks
Добрый день.
Вопрос по компилятору GNU AVR GCC: Существует ли возможность использования vector и string для 8-ми битных AVR МК(в часности ATMega16)? Рассматриваю использование Code::Block, очень нравится, вот хочу пристреляться. В IAR получилось без проблем, даже удивительно 8-ми битный МК и vector.
Спасибо за внимание, Алексей.
dxp
QUOTE (e-leks @ Dec 24 2011, 00:25) *
Добрый день.
Вопрос по компилятору GNU AVR GCC: Существует ли возможность использования vector и string для 8-ми битных AVR МК(в часности ATMega16)? Рассматриваю использование Code::Block, очень нравится, вот хочу пристреляться. В IAR получилось без проблем, даже удивительно 8-ми битный МК и vector.
Спасибо за внимание, Алексей.

STL требует аллокации памяти под элементы контейнеров - работу со свободной памятью. Не думаю, что на AVR (да и на других процах без MMU) это хорошая затея - накладные расходы по памяти и быстродействию для AVR будут великоваты, и от фраментации кучи не уйти. sad.gif
zhevak
dxp говорит дело.

Использование тяжелых библиотек на слабых вычислительных единицах -- это проявление непрофессионализма. Применение на Кортексах и АРМ-ах -- еще куда ни шло, хотя и там лучше все-таки как-нибудь обходится без ООП. Но на АВР-ах... не-е, лучше не надо!

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

Хотя, опять же! На форуме всегда найдутся спорщики, и начнут доказывать, что это не исключение, а правило. Основной аргумент -- типа принципиально же запускается, работает. А чем это достигается, чем при этом приходится жертвовать -- для них это вопрос второстепенной важности.

Если хочешь растолкать локтями конкурентов на рынке, делай лучше, чем они. Не игнорируй второстепенных вопросов. Конечному пользователю все равно -- на каком языке написан софт. Хоть на Васике! Ему важна надежность оборудования и цена. Если ваш девайс будет периодически сваливаться в синий экран из-за фрагментации памяти, нанося мне убытки, то я приду к вам и... угадайте с одного раза, куда я вам засуну ваше изделие. Более того, я еще всем расскажу, какой есть глюкавый и тормознутый (при такой тактовой частоте на что тратит он свои такты) ваш недо-девайс. А теперь попробуйте сделать свой бизнес и продержаться долго на рынке!
e-leks
Цитата(zhevak @ Dec 24 2011, 00:17) *
Использование тяжелых библиотек на слабых вычислительных единицах -- это проявление непрофессионализма.
Спасибо за очень исчерпывающие ответы, конечно же Вы правы. Я начинающий, попал под влияние Страуструпа, при чтении его последнего шедевра стали появлятся подобные мысли. Хотя в стандартной библиотеке AVR(WinAVR) существует поддержка vector, list, string и др., но 32 битными AVR МК. Наверное здесь и лежит "граница AVR" на использование STL, до 32 битных не стоит использовать, после 32 битных можно. Конечно если задача требует и без контейнеров получится еще сложнее.
Спасибо, Алексей.
neiver
Если хочется удобных контейнеров для АВРок, то можно самому написать легковесные контейнеры со статическим распределением памяти. Это не сложно. И это очень хорошая учебная задача. Так что дерзайте.
Вот, например, минималистичный, но очень эффективный кольцевой буфер
IgorKossak
Пока тема не свалилась в очередную перебранку насчёт допустимости применения C++ на МК, я её от греха подальше закрою.
Но справедливости ради добавлю, что использование STL не является обязательным и ни коим образом не препятствует программированию на C++, даже для мелких МК. И что применение всех этих технологий ни в коем случае не является синонимом синего экрана. Интеллект нужен для любой работы.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.