Здравствуйте, стоит задача разработки сложного протокола обмена по UART-y.
Чтоб не париться с отладкой, многократной заливкой прошивок в контроллер и т.д. было решено писать под обычную персоналку.
Так случилось что код использует STL и исключения.
Попробовал код скомпилировать под какой-нибудь контроллер и обламался.
Не могу найти среду разработки c поддержкой STL и исключений.
Keil под 8051 вообще не понимает С++
IAR под 8051 STL понимает, но нет поддержки исключений, как и ІAR для MPS430 и  для ARM.

Посоветуйте, пожалуйста, среду разработки под контроллеры для программирования в С++ с поддержкой STL и exceptions.
Или все придется переписывать без исключений?

AVR32 + GCC.

Может сначала выбрать контроллер, оценить необходимую производительность, а потом выбирать язык программирования и среду.
Для размышления:

как будете реализовывать?

Переопределением функции open в libc.

Забыл сказать что не хотелось бы связываться с "экзотическими" или дорогими (>$5) контроллерами,
но всеравно спасибо за ответ.
Значит кроме GCC исключения никто не умеет обрабатывать?

Производительность не особенно критична при скорости обмена 9600 / 19200 бод.
А работа с устройствами через дескрипторы мне не нужна, код работающий с регистрами UART напишу отдельно.
Насчет того что сначала нужно выбрать контроллер, то Вы правы. Но я кроме AVR, 8051, PIC ничего не знаю, а им эта задача не по зубам, так что всеравно что изучать.

Уже linux на 8051 поставили?! Или всю libc править для работы с потоками?
А это как править:

Ставить winCE на контроллер? У автора непонятно что на PC

Есть ОС, нет ОС наука не в курсе?

GCC точно умеет. И в GCC можно libc переписать. Посмотрите ARM7 Или Cortex C3 процессоры. Там и дешевые есть, а GCC там нормальной пойдет. Может можно будет и просто под AVR переписать, но ХЕЗ получится портировать или нет.


Нет. Только ту часть, которая нужна.

1. Исключение - аварийный вариант поведения программы. На PC обработка исключений оправдывается более-менее быстрой локализацией ошибок. Кто и как будет реагировать на исключения в embedded системе?
2. Исключения - сильный тормоз.
3. Выкинуть обработку исключений. Это займет максимум день.

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

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

Выкину, если убедите меня вторым пунктом. Пока я считаю что исключения позволят мне написать более компактный код.

Боюсь, что только завал Вами сией простой работы, только и сможет убедить Вас в том, что через анус, с помянутыми Вами припарками, на 51 ее делать не надо . Вперед.

51-й я уже "похоронил" после того как сравнил объем кода сгенерированный IAR-ом для 51 и для MSP430 (2.5 : 1 в пользу MSP). Смотрю в сторону МSP430 или ARM7

Тогда уж и в сторону МК с ядром Cortex посмотрите.

90% этих исключений есть на самом деле хорошо замаскированный goto, а остальные 10% setjmp/longjmp.

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

IAR сделал абсолютно верно, что выкинул из своего компилятора поддержку исключений. Т.к. они для embedded устройств слишком тяжеловесны. Не могу придумать ни одного примера, где бы их использование было наиболее удобным/рациональным/правильным/...

Исключения С++ и STL не очень коррелируют с МК за 5 баксов. Исключения - достаточно тяжелый механизм по накладным расходам - там при возникновении исключения происходит "раскручивание" стека, что, также, не очень хорошо сказывается и на таймингах.

STL требует работы со свободной памятью, что тоже обычно вызывает вопросы на embedded платформах - накладные расходы стандартного менеджера памяти + фрагментация кучи. Либо писать свой менеджер памяти и аллокаторы для контейнеров STL. Сами по себе задачи будут посложнее какого-то (да любого) там протокола передачи данных по UART.

Если за STL еще бы можно побороться, благо мощная и удобная библиотека, то про исключения лучше сразу забыть. Ну, и проц уже посоветовали - смотреть в сторону кортексов.