у меня В IAR 7.4 обнаружилось отсутствие файла inc/nxp/iolpc4074.h
вернее там вообще по 40xx ничего нету

Ну ядро поддерживается, а остальное можно написать, или пользовать всякую всячину с LPCWARE
https://www.lpcware.com/content/nxpfile/lpc...er-library-keil

да не только ядро IAR знает этот чип "в лицо"

просто похоже начали выталкивать на CMSIS, но все равно странно что для хидеров надо examples скачивать там есть LPC4000CMSIS

А вот для 43xx хидеры есть.

Лично я хидеры от производителя компиляторов использую разве только в качестве болванки. Не устраивают проталкиваемые ими "внутрифирменные" навороты и нередки и отступления в аббревиатурах от того, что в документации производителя. Так-что как правило сам спокойно, вдумчиво по мере изучения чипа. Иногда использую и собственные альтернативные алиасики - для совместимости с предыдущими вариантами. А то и производитель часто фигней страдает меняя аббревиатуры от семейства к семейству.

Типа еще скрипт-болванка линкера есть? Так все равно его писать/менять для чего-либо кроме "Hello World!".

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

тут для меня важнее что отладчик его знает, для быстрого начала работы - это полезно.
только почему то про SPIFI не знает, и кстати в хидерах из IAR овских примеров - его тоже нет

да и инициализация в IAR примерах с багами, по крайней мере user manual не соответствует, например там power boost устанавливается как |=3, а в даташите указано что старшие биты при чтении могут быть любыми, а записывать туда надо только 0. wait stait для флешь акселератора тоже не соответствует...

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

Не помню уж сколько лет отладчиком последнй раз пользовался. Для того, что-бы было всегда покупаю под все чипы, но не пользуюсь - моргнул светодиодиком, выкинул байтик по UART, поднял консольку и вперед.

Ну этого всегда и везде навалом

Аналогично!
Я оттуда максимум - таблицу распределения входов для NVIC вытаскиваю.
Всё остальное - описываю сам, структурами, дефайнами по даташиту.
Может и используемых мной МК нету в хидерах IAR - я и не знаю даже
Поддержка контроллера IAR-ом мне нужна только чтобы JTAG-ом к нему коннектиться, ибо свои файлы конфигурации отладчика писать ещё не научился

Раз уж пошел такой разговор, а когда по Вашему мнению, отладчик именно необходим? Ну и как отладчик Вам помогает, когда надо вылавливать РЕАЛЬНЫЕ ошибки возникающие а РЕАЛЬНЫХ условиях эксплуатации в реальном окружении?

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

Имхо, отладчик незаменим при старте на новой платформе.

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

Всегда можно обойтись без, и обходились мы раньше, но сложность ПО растёт, соответственно и время поиска багов в нём увеличивается. JTAG позволяет во многих случаях (не всегда конечно) хоть сколько-то сократить это время. А время - деньги. И если это время можно сократить, то почему этого не сделать?

В том-то и проблема, что именно с ростом СЛОЖНОСТИ изделия, растет и слжность ошибок в нем, и полезность отладчика резко стремится к нулю. Для изделия, условно, "нажал кнопку- загорелась лампочка" все изумительно - берем отладчик, повторяем нажатие кнопки 100500 раз и находим почему (например "программист" думал, что 2+2=5 ) не загорелась. Для изделия, котрое взаимодействует по каким-то интрефейсам и протоколам с изделиями других производителей (а именно таого типа изделие похоже на сложное), полезность отладчика равна ровно 0. Ну не поможет он никак найти ошибку в какой-нибудь ветке отрабатывающей ошибки протокола взаимодействия с неведомым чужим изделием, которая вылезает на объекте несколько раз в год. Для поиска такого, нужны другие механизмы, и, если они построены, то и для поиска ошибки в "нажал кнопку - загорелась лампочка" они тоже годятся. Тем более, если уже человек умеет делать сложные вещи, то в "нажал кнопку" он вообще ошибок не сделает, а если еще и в школе учился, а не сразу стал "программистом", то и ошибок "2+2=5" не сделает, а если и сделает, то опечатку и сооответственно просто ее увидит глазами.

Странные какие-то рассуждения....
Следуя Вашей логике, если скажем имеем например какой-нить светильник, то мультиметр вполне поможет в его ремонте, но с увеличением количества лампочек - он всё менее полезен в ремонте, а если это уже гирлянда со всякими эффектами - то пользы от мультиметра почти никакой, а для контроллера, который ей управляет так и совсем 0. С чего бы это??? Даже в самом сложном, самом микропроцессорном контроллере управления гирляндой, вполне себе можно прозвонить какие-то контакты, проверить питающие напряжения. Это не говорит о том, что он полносстью заменяет осциллограф, но всему своё место.
Так же и с отладчиками. Почему Вы решили, что если кто-то пользуется эмулятором, то он не использует другие средства отладки???


Да ну!!!? Правда что-ли?? И в нескольких тысячах строках текста сразу увидите?? А почему не увидели ошибку уже в первом предложении, которое написали?
А Вы всегда АБСОЛЮТНО внимательны когда пишете ПО? Вас АБСОЛЮТНО никто и ничто не может отвлечь?
Имхо, по моему опыту, большинство ошибок, которые делаются, делаются не потому что плохо учились, а потому что когда писал эту строчку, кто-то к тебе подошёл и отвлёк или что-то отвлекло.
И например у меня, это ~ 95% всех ошибок.
И эмулятор как раз очень хорошо помогает в быстром поиске большинства таких ошибок.

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

PS: Если Вы вдруг обнаруживаете, что какая-то из десятка задач в Вашем устройстве портит некую Вашу переменную, то, чтобы обнаружить виновника, можно конечно вынести её в отдельную область памяти и закрыть эту область встроенной в процессор защитой памяти, чтобы отловить исключение; можно написать ISR от высокочастотного прерывания таймера, в котором контролировать эту переменную и момент её модификации.
А можно просто поставить watchpoint в отладчике, это сэкономит массу времени, хотя и не гарантированно сработает (как впрочем и другие способы).

не то что бы незаменим, а сильно уменьшает время на осваивание.