Где берутся h-файлы на периферию микроконтроллера, где берется файл описания микроконтроллера для отладчика (это я по аналогии с иаром - там ddf-файл)?
А то подумываю, не начать ли учить эти гнушные средства разработки (не ради забавы, а исключительно потому, что пользоваться ломанным коммерческим софтом совесть мучает ). Вот и хочется узнать, какие с ними могут быть проблеммы, трудности в освоении и ,главное, в работе...
И кстати еще вопрос. Подумываю для этих целей прикупить отладчик ARM-USB-TINY (Olimex). Вот хотелось бы узнать мнение о нем... И заодно спросить хочу - он вроде как поддерживает ядра arm7, arm9, cortex-m3. То, какие ядра поддерживаются, зависит от самой железяки, или исключительно от софта (в смысле openOCD)?
Заранее благодарен.

Относительно ARM, в компилаторе появляется поддержка архитектуры, а не конкретного процессора. То есть например появляется новая архитектура, для определенности скажем ARM7TDMI-S. Ее поддержка появляется в binutils, gcc, gdb и пр. А поддержки конкретных микросхем, скажем LPC2368, как отдельной фичи нет. Сам компилятор не содержит никаких фич по конкретным процессорам. Заголовки просто скачиваю с сайта производителя. Они обычно идут составной частью apnote, примеров и т.п. хотя иногда случается они идут отдельным пакетом.
Что касается отладчиков, то тот-же OpenOCD - это самостоятельный проект и никакого отношения к компиляторам не имеет. Поддержка новых микросхем там появляется независимо от компиляторов. Собственно по OpenOCD много сказать не могу, так как пользую его очень редко. В большынстве случаев с головой хватает консольки.
Появление поддержки новых архитектур в gcc достаточно оперативное. Точно по срокам не скажу, но поддержку Cortex-M3, например я увидел в gcc примерно через месяц или чуть больше после ее анонса. Собственно ARM Ltd сама занимается поддержкой своих ядер в gcc.

Хм... Стесняюсь спросить... А насчет консольки - это че такое?
И вообще... С чего начинать то, с какого боку подступиться? Может чего посоветуете. Я пару раз пытался попробовать. В итоге скачал себе winarm, сборку amontec, отдельно файлы как написано в атмеловском aplication note. Увидел страшые скрипты для make, и вообще кроме си-файла еще кучу всяких файлов - испугался .
Попробовал в winarm какой-нибудь пример скомпилить и собрать - не получилось, что-то с make (толи где-то что-то прописать надо, толи хрен его знает что...).
И вообще - а почему все-таки некоторые гнушными средствами пользуются? Можно ведь и ломаным софтом, по-тихой... хе-хе... иаром или кейлом... В смысле пользование гну-средств - это чаще требование начальства или личный выбор программиста?

Консолька - это часть программы, которая предоставляет интерфейс командной строки, и работает с последовательным портом. В паре случаев делал по SPI по причине занятости единственного UART для основной работы. Собственно командная строка довольно редко используется, в основном используется на вывод инфы из программы в удобочитаемом виде о ее состоянии. JTAG-отладка показалась излишне громоздкой в повседневном применении. Ну и плюс симулятор, хоть он конечно не симулирует периферию, а только ядро.
А по поводу использования GNU средств - как то не вижу других вариантов для себя. Плюс ко всему кроссплатформенность. Части программ (и часто большые части) просто копируются в проект. Единая кодовая база, опять-же, не зависит от процессора и ОС (и ее наличия).
У меня полностью все на Linux. В случае необходимости каких-то программ для Windows испоользую CygWin, но в основном ПК не требует написания каких-то программ под проект. В любой ОС достаточно штатных средств для взаимодействия с устройством. Если на ПК нужны красивые окошки - то Qt.
Поначалу, когда Makefile мне казался китайской грамотой, использовал KDevelop. К нему довольно просто прикручиваются собственные типы проектов. Но изучить make его не так уж и сложно. Для нормальной работы достаточно некоторых базовых аспектов. Мануал хороший, почитать и потренироваться пару дней - и можно спокойно его использовать.

Открою страшный секрет - все "средства" и GNU, и IAR, и Keil посторены совершенно одинаково Наличие в качестве штатного бесплатного приложения у некоторых неких ограниченных оберток для тыкания мышкой сути дела не меняет.

еще один страшный секрет - любой компиллер содержит глюки, правда в разных местах. в отличии от прочих в GNU GCC можно быренько поправить глюк или загнуть так как Вам это нада!!! , также быренько пересобрать компиллер и продолжить работать забыв про проблему

лично я пользую сейчас GCC для всего чем занимаюсь
1 Написание приложений OpenGL/DX/Qt
2 Написание расчетных научныз задач ( микс /c/c++/fortran)
3 ну и собсна для микроконтроллеров AVR/ARM
это мой выбор, мне так удобнее и комфортнее, я чувствую себя увереннее и честнее. а чтоб не думать о мнении начальников станьте сами начальником, если сможете