у меня В 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 в отладчике, это сэкономит массу времени, хотя и не гарантированно сработает (как впрочем и другие способы).

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

Прнятно. Уровень сложности может измеряться, только количеством лампочек. Ладно, попробую обьяснить "в лампочках". Лампочек в светильнике стало так много, что они не поместились в один светильник и даже на один континет. Пришлось думать, как организовать управление.

Читайте ВНИМАТЕЛЬНЕЕ. В Вашей терминологии, для решения всех пробоем требуется "осциллограф" и он соответственно сделан. Зачем поосле этого "лампочка с батарейкой"?

Про эмулятор я вообше ничего ни думал, ни решал, ни писал.

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

Потому, что это:
1) опечатка, а не ошибка
2) текст не компилировался
3) и даже не перечитывался, поскольку на русском языке я пишу раз в 100 быстрее, чем на Си.

Может.

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

А перечитать написанное не помогает

Могу Вас заверить, что для действительно сложных систем, а не для торшеров с лампочками, тесты в тысячи раз сложнее тестируемого объекта. Я большую часть жизни занимался телекомуникационным оборудованим. Посмотрите, например, что такое SS7. Потом буду готов буду выслушать, что Вы беретесь написать протоколтестер. Кстати, никакого колхоза в работе не бвло - протокол тестеры покупались, использовались, поддерживалась подписка, ВЫЛАВЛИВАЛИСЬ ИХ ОШИБКИ. Но все не покрывали и НЕ ПОКРОЮТ никогда. Просто сложность фантастическая получается.

Продумывать - считает. И писать считает нужным. Проверить сложно. И такой проверке никакой отладчик не поможет, ибо дело в многообразии воздействий. А отладчик для явных, поыторяющихся хоть 100500 раз неправильных ситуаций.
Так-что для очень большого количества всяких ошибочных веток, рецепт хорошей работы - ТОЛЬКО хорошо писать и понимать написанное, а не смотреть а результат отладчиками.

Изумительно. Если я уже узнал, что проблема в том, что именно эта переменная портится, то это уже финиш решения проблемы поиска ошибки, а не ее начало. Ну ладно, пусть мне было божье проведение об этом факте

Значит к каждому устройству находящемуся в эксплуатации, надо приложить компьютер, одладчик, софт отладчика, проект, исходники и обученого человека. Про условия эксплуатации, где все это принципиально невозможно вообще не говорю.
Значит таки должен быть механизм отлавливания ошибок в процессе экспуатации БЕЗ всего это счастья и САМОЕ ГЛАВНОЕ без божественного провидения дарующего свыше знание, что именно за этой переменной надо следить.
Если такой механизм и умение им владеть, есть, то роль отладчика стремится к нулю.
Проблема только в том , что уметь пользоваться тяжелее, чем мышкой c кнопкой. Но и возможности другие .

Развели тут срач ну пустом месте. Выяснилось, что системы сильно разные бывают (кто бы мог подумать?!). Соответственно, подходящие методы разработки тоже разные! Капитан Очевидность нервно курит в сторонке.

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


Вы счастливый человек, раз у Вас только такие простые задачи, что чтобы восстановить ход мыслей, достаточно несколько строк перечитать!
Я когда такие простые вещи пишу, тоже поверите-ли, отладчиком практически не пользуюсь. Даже если несколько сот строк кода - всё обычно практически сразу начинает работать как надо.
А представьте, если для написания кода Вам надо держать в голове несколько определений сложных типов данных (структур), распределения и алгоритма работы структур хранения данных в нескольких чипах, если процесс, который сейчас описываете, состоит из взаимодействия нескольких задач и ISR-ов (временные соотношения между которыми нужно держать в голове), с несколькими десятками рабочих переменных и когда пишешь текущую строку исходника, ещё держишь в голове, что нужно будет внести такие-то и такие-то модификации в такое-то и такое-то место, поправить ту структуру и убавить кол-во элементов массива в другой, изменить значение того enum-а и увеличить размерность этой переменной.
Когда в голове целый комплексный ворох информации. И чтобы потом это восстановить надо много чего просмотреть и многое ещё вспомнить ибо пока нигде не записано, а только в планах, в голове.
И поверьте - по кусочкам такой процесс бывает невозможно отладить, чтобы хоть что-то заработало надо сначала много написать.
А к вам в отдел набрали кучку студентов с глупыми вопросами или рядом сидящим коллегам, лень самим разбираться в чём-то и они считают что гораздо проще отвлечь тебя. И так каждые 15-20 минут.
После такого бывает такие ошибки вылавливаешь, самому поверить трудно как такое мог написать.


Согласен с Вами.
Уважаемый zltigo пытается доказать, что пользоваться отладчиком - моветон. И что те, кто им пользуется только от него полностью зависят как наркоманы и ничего другого не умеют делать и сами думать не умеют. Не понимаю почему, если не хочешь пользоваться - не пользуйся на здоровье.

Дураком не прикидывайтесь. Четко написано и даже выделено шрифом.

В основом головой. Чудес не бывает.

Сразу, простите, видно, что именно Ваши проекты "из десяток строчек" , но щеки надувать хочется . Для описаной Вами ситуации БОЛЬШОГО ПРОЕКТА в которой Вы явно сами ни разу не бывали, иначе-бы понимали, что даже узнав чудесным образом "переменную" которую кто-то портит и воспользовавшись чудесным отладчиком и узнав адрес команды, которая портит, Вы на самом деле должны сделать самое сложное - исправить ошибку в большом чужом коде. Исправить так, что-бы это было именно исправление, а не заплатка, которая вылезет боком в другом месте. Отладчики, кстати, очень многих начинаюих провоцируют на заплаточный стиль написания - ой! нолик получился, сейчас сделаем +1 и будет хорошо.

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

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

Не все, так однозначно. Чаще более мягкий случай - типа нормальный человек, но выпил и начал гнать код из под отладчика . Протрезвеет и опять нормальный . Хотя даже не так - памперсы это хорошо, сухо и комфортно, но не всегда удобно, прилично и возможно их носить. Но самое ГЛАВНОЕ, что его использование решает только часть проблем, причем достаточно небольшую в действительно больших проектах. Отчего, наблюдаю, что если вырабатывается привычка "ни шагу без отладчика", то при росте сложности программ доходит до шокового эффекта - отладчик не помог, что ни правится, все ведет к новым проблемам... Остановится и подумать уже невозможно - только "трясти надо" .

Я и не пользуюсь и перечислил почему. Если все это не Ваш случай, то тогда и не должно Вас все это волновать. Не читайте и пользуйтесь.

Опять ушли от конкретного ответа, скрывшись за кучей демагогии.
Так и не ответили как именно знание, что данная переменная портится поможет в устранении проблемы.
Как найдёте причину кто её портит???? Вы вообще отлаживали когда-нить что-то, если не можете ответить на конкретный вопрос или только теоретизируете?


Фантазии - вещь хорошая при написании книг.

Много лет назад я писал и отлаживал без отладчика. И это было на TMS320VC5502 почти полностью на ассемблере (это очень далеко не простейшая ARM-архитектура). Только светодиоды и вывод в лог (UART).
И ничего - доводил до конечного продукта и не раз. Только времени на это тратилась уйма. Тогда было можно, сейчас - жалко времени.
А стиль программирование и факт пользования отладчиком - не имеют никакой связи сколько не утверждайте обратное.

Вообще-то отвечал. Только видимо ответ показался Вам общим . На самом деле вопрос Вами поставлен, о чем уже писал, абсолютно некорректно, для реальной системы - ну НЕ известно, что портится именно эта переменная. Поиск моих ошибок в РЕАЛЬНОЙ жизни, начинался обычно так - что-то изменилось в окружающем мире и Вы, набрав телефонный номер в Гондурасе не смогли дозвоиться до желаемого абонента. Вопрос куда втыкать отладчик в телефонную станцию с оборудованим размещенном в нескольких стативах и где искать "переменную которую испортили" ? Так-что все начинается с трассирвки вызова, с просмотра логов, активизации дополнительных уровней отладочной печати. Все это закладывается уже на этапе разработки и служит и средстовом пошагово поднимать систему.
А "кто-то портит переменную" это уже много много позже, не говоря уже о том, что сама ситуация с "портит переменную" практически нереальная с тех пор, как программирование в кодах умерло, а в АSM минимизировалось. На чужие пременные залезть уже можно только специально, ну или при грубейшей ошибке перпахав много памяти. Ну выяснили Вы отладчиком, что у Вас перепахан стек (что явно стант ясным и без отдадчика по вылету), а не какой-то вырожденно-ПАРКЕТНЫЙ случай аккуратно измения одной переменной. Ну и?

А я начинал еще на первых советских, наших рижских, "ренатах" c ошибками в ядре. DSP это на самом деле несколько другая жизнь (натягивие линуксов на все, что попало не рассматриваем), то, что для них пишется это на 90% процентов работа с математическими моделями и симуляторами. Ума не приложу к чему-бы мне был отладчик для разбирательсва с алгоритмом фильтра или кодека. Ну а остальное можно и через UART.

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

Нереальная??? А указатели уже отменили? А приведение типов? А массивы, с индексами выходящими за границы? Да хотя-бы то же самое переполнение стека?
Это всё паркетные случаи? Или Вы всё-таки на яве пишете, а не на си?
И как станет ясно по вылету? Вылет произошёл в одном месте системы (из-за разрушения переменной, а переполнение - совсем в другом, где в переполненном стеке попортился лежавший там указатель, запись по которому и разрушила чужую переменную).
И Ваше "писать по 10 строк, потом отлаживать написанное" здесь не пройдёт, так как когда этот кривой кусок писался и отлаживался, эта запись по случайному адресу не попадала на важные данные, а после добавления кода через N месяцев, она стала портить важные данные.


Например: какие-то команды процессора описаны в доке поверхностно, так что трудно понять нюансы исполнения (а у C55xx очень богатая и сложная система команд); либо неполное или запутанное описание периферии (это касательно любого МК) - в таких случаях JTAG очень часто помогает быстро разобраться, быстро глянув на поведение какого-либо бита при определённом воздействии. И воздействие это можно прямо в отладчике применить (меняя данные в отладчике), быстро, не перекомпиляя каждый раз код и не перезаливая его.
И это тоже никакой не паркетный случай, а вполне жизненный. Если конечно сидеть всё время на одном МК, обсосанном вдоль и поперёк, а не осваивать новый МК под каждый новый проект, то тогда это менее актуально.
Не спорю - всё можно отладить и через UART, можно даже одним светодиодом. Но многие вещи гораздо быстрее удобнее - JTAG-ом.
И не вижу смысла так не делать, а заниматься мазохизмом.

Писать можно по разному. В том числе и ИЗНАЧАЛЬНО аккуратно.

Вы вообще способны написанное воспринимать? Я о таком и писал - стек порушен фиг знает когда, в нем уже каша нет ни возвратов ни указателей правильных, и тут о радость, мы по какому-то битому указателю ловим запись отлажчиком в чудесную ячейку. НУ И ЧТО?

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

Правда такой дичайший случай был на прошлой неделе. Искал дистанционно четверо суток. Но вина оказалась не моя. Контролер прерываний с сочетании с контроллером SPI работающим слейвом с софтовым мастером, несколько раз в сутки под большой нагрузкой, выдавал нулевой вектор и все аккуратно перезапускалось. Причем изделие многолетней давности, вносились изменения и поменялся компилятор с 4.x IAR на 7.x IAR. Ничего криминального в коде не было, к компилятору никаких притензий, но все стало шустрее. А вот к контроллеру LPC2103 - появились . Были вдоль и поперек вычинаны ARMовские описания их SPI корки - безрезультатно, пришлось шаманить добавля повторные сбросы. Эффект ушел.

На этапе освоения, если сочтете возможным все-же читать, что я написал, у меня в потенциальной полезности отладчика никаких сомнений нет.

У меня в штатной консольке, котороая, конечно, с изменениями под конкретику чипа, кочует из изделия в изделие лет 25, просто есть команды работы и с памятью/периферией. Так-что посмотреть состояние и воздействовать могу всегда, хоть есть отладчик, хоть нет. Конечно, менее удобно, но зато работает и на объекте.

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

Ну сажу немного не так - не "многие", а НЕКОТОРЫЕ. Некоторые, это значит НЕ ВСЕ. Раз не все, то должны быть, увы, и более универсальные методы отладки. Пусть даже и много менее удобные в ЧАСТНЫХ случаях.

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

Да с чего там каша-то?? Испортилась, например, одна переменная (на стеке есть массив, ошибка в индексе или ошибка при работе с указателем) и происходить это может очень редко, при стечении кучи обстоятельств.
Вобщем - ладно, Вы на своей волне, толчёте что-то своё совсем не воспринимая смысл того, что я пишу. Я про Фому - Вы про Ерёму. Дальнейшую дискуссию считаю бессмысленной.
И в то что у Вас нет ошибок, которые Вы назвали "чрезвычайными", просто НЕ ВЕРЮ. Сказки рассказываете. Если-бы Вы так идеально писали код, у Вас бы и в сообщениях не было ни одной помарки.
Имхо - подавляющее большинство ошибок всегда - из-за невнимательности и они часто как раз дичайшие.

Гы-гы. Говорят, в старину код писали на разлинованных бланках, потом относили перфораторщицам, потом стояли в очереди за машинным временем. Как у них код работал - ума не приложу. Неужели с первого раза без ошибок писали?

Опять НЕ читаете. Мне просто надоедает повторять. Вы пытаетесь подменить причину следствием. СНАЧАЛА испортился стек, ПОТОМ уже из-за этого по битому указателю испортилась Ваша любимая переменная.

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


С этой старины я и начинал в 1976. Фортран. Полусписанный, но зато почти персональный Минск-32. Перфораторщицы, да. Но можно было по быстрому на префоленте немножко набить - c телетайпами напряга не было. Ну и заклеить/пробить отверстие в перфокарте тоже. Вообще-то, блин, дисциплинирует, похоже на всю жизнь
Если об отладчиках, то первый отладчик Intellec 8 попользовал в начале 80х. Позднее для 8085 и Z80 писал и отлаживался в линуксомом эмуляторе.

Как видно уже в 1976-м существовали свои перфо-отладчики.
Даже в те благословенные годы требовалось дырку не только пробить, но иногда и заклеить. Даже тогда zltigo не удавалось с первого раза все дырки пробить правильно.