Arlleex

Как и от всего расчета надежности как феноменальной дури в индустрии разработки.

Ну, например, платы-носители для SoM на Rockchip, банально несколько производств испытывало проблемы с позиционированием и пайкой разъемов DF-40. Нужно было вносить коррективы в технологию. Из последнего - туда же пайка LGA-микросхем и GSM-модулей, MEMS-датчиков. Определенные проблемы. BGA, шаг 0.5мм, под брюхом на другой стороне платы россыпь 0201-конденсаторов. На первых порах - проблемы. Дальше - серия, на которой дается представление о скрытых недостатках схемотехники, которые тяжело или невозможно было выяснить на макетах или пробных партиях в несколько десятков штук. И т.д. и т.п. Мне приходилось один раз переразводить плату лишь по той причине, что при смене производства, линия по производству ПП не могла обеспечить Резонитовский уровень, поэтому пришлось переделывать под них. И официально делать это всегда больно, т.к. это сопряжено еще и с кучей бумажной работы, помимо основной.

Значит платы такие, в которых ничего сложного нет. Ни в одном ТЗ такие детали не описываются. На то и существует инженер-тополог, чтобы такие знания в его черепной коробке были по-умолчанию. Другое дело - это, если уж трассировщик и схемотехник - лица разные, это создать между ними единый контракт работы в выбранном САПР-е. А так - схемотехник должен схемы делать, а не писать талмуды напутствий для трассировки для любой домохозяйки.

ЕМНИП, а не связано ли это с тем, что в AVR-ках, вроде как, 16-битная ширина Flash-памяти?

Как трассировать DDR4/5, как разводить питание DC/DC-конверторов, тащить SATA/USB/и т.д. тоже схемотехник должен писать топологу? А не много ли? Считаете, что тополог это обезъяннная работа, которая не требует интеллекта, а сугубо навыков механического клацания-соединения дорожек? В реальности тополог, который не понимает схемотехники (на достаточном для своей работы уровне), сидит-пердит в пролете либо на ГЗП в 30 тыщ рублей и его это устраивает. А насчет КД за 1000км тоже не смешите - любое производство перед, непосредственно, производством, прошло мучительный путь адаптации КД, технологии и т.д. где группа тех же инженеров, технологов, и других сопричастных доводило техпроцессы до идеала. То, что описано в вакансии, весьма сносная возможность вчерашнему студенту позаниматься всем понемногу и понять, в каком направлении ему больше нравится расти. Но естественно, бывалый разраб за такие деньги и такой список хотелок пройдет мимо.

А вы его сюда пришлите. В частности, кусок выхлопа препроцессора над исходником, где объявлен bool door_vkz[MAX_COUNT_DOORS].

А посмотреть полный выхлоп после препроцессора в IAR можно? Наверное, это было бы самое интересное.

Значит все-таки глюк компилятора. А вообще, интересно глянуть, что за значение молча принял для себя IAR 7.3. Полагаю, это можно проверить в том числе, анализируя значение DLC передаваемого CAN-фрейма, судя по строчке кода:

Ну тогда можно закинуться таблетками и творить всякую дичь типа #define HELPER_MACRO M##A##X##_##C##O##U##N##T##_##D##O##O##R##S // удачи в поисках по 'DOORS', 'COUNT' или 'MAX' enum { HELPER_MACRO = 1 }; bool door_vkz[MAX_COUNT_DOORS];

Вот именно.

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

Речь не о том (как я понял). Речь о том, что если бы (именно если) макросы умели по внутренней логике генерировать некоторые имена, которые потом были бы полноценными эквивалентами обычного дефайна, то вот тогда никакие поиски по кускам имен не помогли бы. Но в препроцессоре нет таких возможностей, т.е. как таковой логики в макрос-кухне не может быть. То, о чем Вы говорите: #define CHK_DMACHAN_MAP2(unit, ch) CHK_DMACHAN_MAP##unit##ch требует "вызова" этого макроса из кода. А ТС сказал, что у него сразу bool door_vkz[MAX_COUNT_DOORS], а не bool door_vkz[ХИТРЫЙ_МАКРОС_РАЗ_ДВА_ТРИ_СКРОЙ_СВОЙ_КОД_И_ОТВАЛИ(...)]. Понимаете разницу? И что это дает? Поиск по имени не дает никакого результата. Значит его нет в исходном тексте программы. И без разницы, что этот идентификатор из себя представляет.

Нельзя, он не понял о чем речь.

Ну, я трактую это как закрыть версию 7.3, потом запустить 9.2, потом File->Open project->... и потом нажать кнопку Compile.

Да наверное так и было бы получше, но все равно не показанные на картинке другие моменты мешают все повернуть. В общем, я методом собственных проб и ошибок решил все-таки изобразить именно такой метод передачи аналогового сигнала по всей плате до МК. Посидел потыкался в симулятор LTspice, он вообщ все красиво рисует, диффусилитель все вычитает как положено, правда, на частотах порядка 20-30 кГц фазовый сдвиг уже ярко выражен. И МК можно было бы поближе подтащить к мотору, но проблема в том, что с левой стороны там тоже кучка аналоговых сигналов всяких внешних датчиков. Но там и шумных моторов нет))

Нельзя так склеить, чтобы получился неявно определенный макрос MAX_COUNT_DOORS. Макросы не могут порождать другие макросы (речь о конкатенации). В случае ТС обязательно должен быть в наличии идентификатор MAX_COUNT_DOORS где-то по файлам, но, как он убедился, поиск по всем файлам проекта результата не дал. Остается не так много вариантов, и один из них я предложил выше. К тому же, железобетонное подтверждение бага в компиляторе 7.3 обусловлено тем, что в версии 9.2, по словам ТС, все уже ломается с выдачей ошибки. При одних и тех же ключах компиляции, результат должен был как минимум быть таким же, если, правда, IAR соблюдает обратную совместимость версий.

Как минимум "в некоторых". Т.е. сегодня есть, завтра нет. В стандартном такого не бывает. Да, в основном это указание на потенциальную неоптимальность (выравнивания структур, размер объектов, выделенных на стеке, задействование оптимизированных builtin-ов и т.д.). Во-вторых, это симметрия препроцессорному #warning, но на уровне компилятора.

Ну, возможно🙂 Комменты в коде почти никогда не пишу, да и заметить их ещё надо постараться. Да, если говорить строго, моё предложение в том, чтобы дать возможность компилятору выдавать non-fatal diagnostics.

Связался с человеком из комитета по стандартизации, он посчитал мою мысль интересной для обсуждения, и сказал что сможет заняться разработкой официального proposal, в части пересмотра работы static_assert() или создания компаньон-оператора static_warning(). Как минимум, попытка сделать небольшой шаг вперед.

Значит у IAR старой версии кривой препроцессор, который схлопывает отсутствующий токен имени макроса в пробел/пустоту/ничего, и в результате получается подстановка в код bool door_vkz[]; что, при отсутствии внешних определений в других единицах трансляции или позднего уточнения типа в этом же исходном файле, неявно преобразуется в bool door_vkz[1] = {0}; Поэтому программа собирается и даже работает, но это значит лишь, что по логике предполагается, что MAX_COUNT_DOORS == 1 это полностью вас устраивает. Или, подавленная диагностика или вовсе компилятор не является конформным и не диагностирует (а новая версия - уже да), и реализация не определяет дальнейшее поведение (т.е. вплоть до компияции в бинарь, но чему там равна размерность массива - хз). Впишите просто руками дефайн себе в файл опций проекта и все.

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

Так вы говорите, что он собирается. А раз так, что выведет в консоль IAR: #define str_(arg) #arg #define TO_STR(arg) str_(arg) #pragma message(TO_STR(MAX_COUNT_DOORS)) (вставьте этот фрагмент рядом с bool door_vkz[MAX_COUNT_DOORS]).

Ну а там где собирается посмотреть предопределенные макросы проекта? Можно еще сам иаровский проект открыть редактором и глянуть поиском. И еще: в коде строчка bool door_vkz[MAX_COUNT_DOORS]; прямо так и записана? Или вместо MAX_COUNT_DOORS там что-то другое (конкатенатор)?

У ТС компилятор еще 5.06 - это не просто старый, это уже развалившийся на плесень и липовый мед тутанхамон. Возможно, в компиляторе крышу сорвало.

Что значит не соединять? ОУ уже сидит своим минусом питания на этой земле. Вообще нет никаких аналоговых и цифровых земель. Все земли одинаковые - это одна цепь, все микросхемы/фильтры/подтяжки переходными отверстиями цепляются к плейну этой земли. Силовая в том числе. Вот и появилась мысль дотащить выход ОУ на стороне DRV до диффусилителя перед АЦП, а поскольку сигнал проходит под участком "силовой" земли, этот сигнал может подскочить. Значит вместе с сигнальным нужно протащить и сигнал земли прямо с вывода GND ОУ за DRV, а диффусилитель вычтет одно из другого, получив оригинальное значение, которое было на выходе ОУ около DRV. По сути, аналог Кельвин-соединения.