Так исторически сложилось, что "настоящим" С-компилятором я все время считал тот, с которого начинал - это Borland C (ранее Turbo C). Когда круг задач модифицировался в Embedded, продолжаю использовать модификацию Borland C++ 5.02 под названием Paradigm C++. Его приходится применять, если задачи требуют x86 машинок. 8-битные всегда ранее программировал на ассемблере, а несколько лет назад перешел на Tasking, который так же могу назвать "настоящим" С-компилятором. Во-первых, при портировании кода на другую машинку и переходя на этот компилятор с "честных" С-приложений, не возникает никаких трудностей. Во-вторых, что часто бывает очень важно при обработке сигналов, "честная" поддержка арифметики с плавающей точкой.

Какие средства разработки вы используете, если проекты выходят за рамки одного семейства процессоров? Заботит ли вас, как и меня переносимость исходного кода на другие процессоры, отличающиеся разрядностью, архитектурой и пр.?

Я писал почти под все возможные DSP и могу сказать следующее.
Среда разработки у всех разная и соотв. надо привыкать, от этого никуда не денешся. Собрать проект можно и в файле линкера, а вот отлаживать приходится на средствах именно под этот процессор.
Последнее время я перешел на следующую архитектуру проектов. Для написания программы я пользуюсь обычным текстовым редактором, а для отладки уже фирменным именно той фирмы, которая производит.
Если писать на ANSI C/C++ то переносимость 100% за исключением случаем передачи сассивов. В этом случае различаются BigEndian and LitleEndian.
Я решил эту проблему написанием макроса обработки данных символов. Сначала масси преобразуется в структуру с использованием преобразования (если форматы одинаковы в процессорах то ничего не выполняется) а потом уже идет обработка. Это имеет место в основном при передаче через порты. Например у PC один формат, а у ADSP другой. Соотв. надо переносить.

Теперь про разрядность и про типы.
Я все программы пишу с использованием собственно обьявленных типов данных:

typedef char BYTE; // 8-bit data
typedef unsigned char UBYTE;
typedef short WORD; // 16-bit data
typedef unsigned short UWORD;
typedef int LONG; // 32-bit data
typedef unsigned int ULONG;

(это из uCos)

Теперь про ресурсы. Есть ф-и которые специфичны для процессора или должны быть написаны на ассемблере. В этом случае я стараюсь ядро программы делать независимым от этих ф-й, для возможности работы на других платформах. Для этого могут пригодиться виртуальные ф-и (если это С++) или просто выносить эти ф-и во внешние файлы, и подлинковывать их в зависимости от платформы. При этом Header file остается не изменяемым. В последнем проекте я имею
DMA.h - common header
DMA_ADSP-BF53x.cpp - ADSP oriented file
DMA_PC_Model.cpp - ADSP oriented file
DMA_Bla-Bla.cpp - любой другой

И вообще, в последнее время для меня нормальная практика писать программу и отлаживать работу ядра на PC (Borland C Builder) а потом просто ее адаптировать на требуемый процессор. Причем отлаживать используя модели. Это имеет неоспоримые плюсы, хотя многим будет лень писать модели и заменители некоторых ф-й. :P


Резюме:
Если писать на ANSI C/С++ то переписывать программу не надо. Надо только менять вещи, которые специфичны для процессора (адаптировать под процессор).

100% согласен, только я стараюсь платформозависимые "куски" выносить строго в один файл, когда работаешь в группе с другими разработчиками. Тогда легче "искать блох".

Я переносил С код с PIC(8bit) на MSP430(16bit) и Cyglal (51-8bit). На асемблере это нереально. Полностью перенос невозможен, но достаточно быстро. Переносил функции типа работа с протоколом на RS232, меню на графическом LCD и т.д. Инициализация и работа с железом, естественно отдельно, но не всегда можно сделать один в один, слишком большое разнообразие. Пишу как можно проще - многие компилеры близко не лежат к ANSI C тем более С++. С++ особенно неэкономный для малых процессоров(до 64к программы - пример Keil) - по размеру кода. и особенно по использованию ОЗУ (что катастрофичнр). Получкный код желательно посмотреть в асемблере и потом оптимизировать.

Полностью согласен с тем, что многие компиляторы для микроконтроллеров далеки от ANSI. Именно поэтому я использую Tasking EDE, честно скажу, местами круче моего любимого Borland-а.

Заботит однако.
Но есть некоторые и минусы. Например, я стараюсь минимально использовать
особенности МК того или иного семейства Эффекты есть и положительные.
Перевод промышленного прибора. достаточно сложного (локальная сеть, ввод/вывод, "черный ящик", и др.) на другие "рельсы" заняло всего несколько дней. Последняя крайность - я стараюсь в последних разработках не допускать не единой строчки на ассемблере. Может это и не "здорово" но последние 2-3 года меня это очень выручает, т.к. я очень перегружен, а работать более некому

Это я, так сказать, с точки зрения ДЕЛА, а что использовать keil. iar, borland, tasking ... - без разницы, впрочем как и семейство МК.

Hmm
Спасибо за продолжение обсуждения.

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

Работаю с несколькими типами МК.
Ради совместимости на уровне программы на C/EC++ предпочитаю использовать продукцию от IAR Systems.
При этом могу сказать следующее, что компактность и скорость работы кода зависят не столько от "умности" компилятора, сколько от стиля программирования при достаточно глубоком знании целевой архитектуры, на чем всегда настаивают производители МК.
В результате учета всех тонкостей (а это не так уж трудно) сгенерированный код может получиться в некоторых случаях даже короче и быстрее, чем если бы писался на ассемблере, особенно при включенных методах оптимизации.
Особо хочу отметить тот факт, что нужно ВСЕГДА смотреть полученный код.
Что же касается драйверов устройств, то их практически всегда приходится переписывать для каждой новой платформы. Поддерживаю идею о том, чтобы подобные фрагменты локализовывать в отдельных файлах и тщательно комментировать.

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

Я тут уже сегодня упостился просто, наверное Мы используем GCC для ARM и вполне довольны.

Что касается оптимизации ассемблерной "ручками". Это смотря какой компилятор использовать. Ничего не хочу плохого сказать про борландовские продукты для 86 архитектуры, но способности компиляторов к оптимизации кода сейчас на порядок выше наших

Например, под ARM ассемблерный код ваять дело неблагодарное - четырехступенчатый конвеер оптимально загрузить нетривиальная задача, в итоге получаем пошаговое выполнение инструкций с минимальной скоростью, в этом плане компилятор работу лучше делает - можете сравнить сгенерированный код, задав опции -O0 и -O2 для компилятора gcc-го (как раз мы бы писали как в случае с -O0). Опять же, по размеру оптимизацию тоже предпочитаю отдавать на откуп компиляторам, поумнели они нынче

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

Собрал GCC под ARM, Хочу спросить, как пользоваться printf для вывода в СОМ-порт. Для, скажем, IAR EW надо просто переписать функцию putchar. А здесь так просто не получится? Подскажите, как "заточить" printf?

Попробуйте пользоваться аппаратнонезависимой sprintf() для печати в стринг, а уж потом передавайте в любой поток ввода/вывода.

Спасибо. Это выход.

Паазвольте не согласиться по поводу оптимизации и ваяния асм кода.
Во первых, у арма 7 конвеер 3х ступенчатый, а во вторых, про оптимальную загрузку конвеера особливо думать и не надо - потеря производительности получается при неизвестном заранее адресе следующего кода (например операции перехода с условием).
Ну и в третьих, попробовал сравнить скорость выполнения кода написанного ручками и скорость выполнения кода откомпилированного ИАР (High Speed) - как ни крутил, "ручной" код выполняется быстрее сишного.

Под каждый проц используешь свои средства разработки, от этого не куда не денишься. Единственное исключение редактор, но тут дело вкуса. А когда переходишь к отладке, всё равно и редактор встроеный используешь.

Как только начинаешь тыкаться в регистры процессора или устройства - о любой переносимости можно забыть, здесь даже не важно на чём написан код C/Asm. Ну асм естественно на другой проц не переносим. На C целесообразно платформенно независимые куски собирать в отдельные функции (ну скажем обработка данных) и запихивать в отдельный файл, только для этой части кода можно говорить о какой-то переносимости. Тут Вам необходимо будет позаботиться о размерности переменных на разных платформах, сделать это можно заведя собственные типы через typedef и определить их для каждой платформы.

А по поводу оптимизации кода на асме - ну тут все зависит от того, на сколько голова работает. В идеале код должен получиться одинаковый, что у программиста, что у компилятора, вопрос лишь в том, кто глупее окажется.

И все же, на ассемблере оптимально писать обработку прерываний или критичные ко времени исполнеия операции ввода-вывода.
Эти функции лучше написать и отладить в специализированной IDE. Все остальное - там где Вам удобно, не напирая на особенности диалета компилятора (они всегда описаны в документации). Полезно сверяться по справочнику Шилдта С и С++.
Мы используем в работе все перечисленные выше средства: IAR EW, Paradigm, CCS, VC6 и UltraEdit.

Nu ya bi ne skazal.... po povodu odinakovosti koda ot komilyatora i programmista..
kak pravilo dostup k vozmojnostya proca(DSP) vozmojen cherez Intrinsic funkcii da i to ne vsegda i ne vse vozmojnosti... mojesh prosmotret dlya TI DSP 55xx. instruction set davolno shirokiy a vot compilyator ne dayet dostup ko vsem... prichem menyaetsya ot versii slava bogu kak pravilo obogoshaetsya. Idealniy variant kombinirovanniy kod s tochki zreniya proizvoditelnosti... prichem effekt skajem u togo je 55xx 2-3 raza... a to i celix 100 ( bil odin takoy sluchay ) no eto skoree isklyuchenie. Dlya serii 64, 67 koefficient ne tak visok.... compilyator udachney da i kod na asm slojnee pisat. Vobshem vse eto ot situacii i ne odnoznachno.

bivayut i drugie problemi... skajem alignment structur. Nepriyatnaya vesh. est komilyatori kotorim vse ravno chto v structure, razmer, fundamentalniy tip. Oni vse structuri delayut alignmet 4 i razmer toje kraten 4. Nepriyatnaya shtuka. Kstati mojet kto znaet kak s etim spravitsya s kompilyatorom ot Metrowerks dlya StarCore?