Здравствуйте, стоит задача разработки сложного протокола обмена по 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 еще бы можно побороться, благо мощная и удобная библиотека, то про исключения лучше сразу забыть. Ну, и проц уже посоветовали - смотреть в сторону кортексов.

jack_avenger

Если не лень, гляньте исходные тексты протокола wake. Большое сходство с Вашим случаем.

Спасибо, посмотрел. У меня посложнее будет. Нужно одновременно держать несколько сеансов связи с разными опрашивающими станциями на каждом из нескольких каналов связи.

Решил отказаться от исключений в пользу setjmp / longjmp.

Прямо сейчас сижу с небольшой железкой 8 каналов связи, до десятка тысяч сеансов. И никаких "исключений" с "setjmp / longjmp" в протоколах всех 4x уровней. За полной нахренненужностью, и не побоюсь этого слова - вредностью.

Как говорил Жванецкий:"Может в консерватории чего надо подправить?" Сдается, что вы переходите в embedded мир с PC и над вами давлеют те методы и приемы, которые там вовсю применяются. Вон уже людям 4 Gb RAM на борту не хватает.

Еще раз - всякие исключения, setjmp / longjmp - не лучшие варианты проектирования software.

Вот, немного почитайте http://ru.wikipedia.org/wiki/Switch-%D1%82...%B3%D0%B8%D1%8F
Вообще, там то и С++ не нужен не говоря уже об исключениях.

C++ не так уж плох. Пример scmRTOS тому доказательство. Только не надо пользоваться бездумно всякими наворотами.

На PC я не написал ничего стоящего, а для embedded сделал несколько прошивок для устройств, коих выпущено уже слава Богу более 200 000 штук и работают они круглосуточно без нареканий (тьфу-тьфу). "В консерватории чего надо подправить", это да. Опыта написания на С++ для embedded у меня действительно нет, но деваться некуда, поэтому и полез на форум.

Спасибо всем, кто откликнулся!

Главное прислушиваться к тому, что говорят на форуме
Тут много хороших сппециалистов с опытом.

GCC на многих платформах идёть, вообщето не имеет смысл использовать C++, разве только что из за расширенной проверки синтаксиса C.

Только за более безопасную работу с типами уже стоит использовать С++. А там еще много вкусного есть.

Ну так распишите это "вообще-то" подробнее. А то "мужики-то не знают". Попытаемся разобраться - которые из мужиков.

Это почему? Ничто не мешало использовать Си++ на AVR и радоваться удобному инструменту)

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