Помогите выбрать среду для разработки на С++ Опции

[jack_avenger]

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

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

[Methane]

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

AVR32 + GCC.

[mdmitry]

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

Код

fd = open(SERIALDEVICE, O_RDWR | O_NOCTTY | O_NONBLOCK);

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

[Methane]

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

Код

fd = open(SERIALDEVICE, O_RDWR | O_NOCTTY | O_NONBLOCK);

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

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

[jack_avenger]

AVR32 + GCC.

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

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

Код

fd = open(SERIALDEVICE, O_RDWR | O_NOCTTY | O_NONBLOCK);

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

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

[mdmitry]

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

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

Код

hCom = CreateFile(P, GENERIC_READ | GENERIC_WRITE, 0, NULL, OPEN_EXISTING, 0, NULL);

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

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

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

[Methane]

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

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

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

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

[sergeeff]

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

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

[jack_avenger]

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

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

2. Исключения - сильный тормоз.

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

3. Выкинуть обработку исключений. Это займет максимум день.

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

[zltigo]

Выкину, если убедите меня вторым пунктом.

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

[jack_avenger]

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

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

[rezident]

Смотрю в сторону МSP430 или ARM7

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

[SSerge]

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

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

[shreck]

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

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

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

[dxp]

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

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

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

[mdmitry]

jack_avenger

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

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

[jack_avenger]

Если не лень, гляньте исходные тексты протокола

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

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

[zltigo]

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

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

[sergeeff]

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

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

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

[sigmaN]

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

[sergeeff]

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

[jack_avenger]

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

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

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

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

[sigmaN]

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

[dch]

AVR32 + GCC.

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

[Dima_G]

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

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

[Сергей Борщ]

вообщето не имеет смысл использовать C++

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

[haker_fox]

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

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

[dch]

"вообще-то"

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