Доброго дня !

Подскажите, уважаемые, где идеологически правильно брать такие файлы ну или рыбу для правки под конкретный камень ?
CMSIS предлагает, производитель предлагает, на просторах инета полно всяких-разных вариаций...

когда писал под LPC1114 очень похоже, что источником служил CMSIS...сейчас LPC1769 и самое время внести ясность где брать...

Да где угодно. Поправить под себя и потом только размер памяти и список векторов менять от кристалла к кристаллу.

Сейчас ковыряю проект для LPC23xx (Keil). Так вот, там стартап настраивает также рабочие частоты различных периферийных устройств. Причём это можно делать из некоего редактора. Без этого редактора кода довольно прилично и так просто портануть на другой кристалл (особенно не близкородственный), думаю, не совсем быстро получиться.
Для ARM известно 3 основных тулчейна: IAR, Keil и Gcc. Синтаксис ассемблеров у них несколько разный.
Тут опять возникают проблемы совместимости.
Поэтому, имхо, нужно брать стартап, какой ближе лежит (в примерах). И лучше сосредотачиваться на грамотном разделении, чтобы не было каши из архитектурно-специфичного кода и собственно самой логики.

С ассемблером на "вы". Когда первый раз писал под cortex-m0 - пришлось со старапом разобраться...чуть ли не каждую директиву комментом сопроводил - это было под GCC+eclipse. С Кейлом таких вопросов не возникает ибо проект настраивается из окошек и достаточно вычитать из мануала, какая галочка что делает.

Сейчас решил идти следующим путём: ld-файл взял из cmsis, startup.c взял из примеров lpcxpresso и минимально адаптировал для работы с ld-файлом.

У автора вопроса Cortex, там ни строчки ассемблера не нужно. Да и для остальных (ARM7, ARM9) на ассемблере достаточно написать только ветвление по векторам. Весь остальной стартап прекрасно, понятно и сопровождаемо пишется на С/С++.

А необходимость портируемости стартапа мне кажется сильно надуманной. Проект пишется и сопровождается с использованием какого-то одного компилятора. И все остальные проекты этого же автора, как правило, тоже. При глобальной смене компилятора подправить стартап много времени не займет на фоне всего остального.

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

Увы, не всегда так. Вот сейчас приходится использовать Keil, потому что нигде больше не удалось завести аппаратный отладчик.
А на танцы с бубнами, пожалуй, времени уже нет. А так обычно я сижу на gcc. Но зато я уверен, что мой код соберётся любым компилятором. Нужно только 2 файла адаптировать: startup.s и retarget.c



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