makc

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

См. вложение Статья Базы знаний Font display issues and icons within dialogs are too small on 4K monitors..pdf

При установке в другой слот устройство в ОС обнаруживается корректно? Ресурсы (адреса и прерывание) ему назначаются? Я наблюдал подобные проблемы в случае некорректной схемотехники самой платы и драйвером это не вылечить.

Чудак без инициативный тоже опасен, но по-другому. Вопрос в том, как организовать разработку, чтобы человеческие качества ("чудачества") в меньшей степени оказывали влияние на результат, но при этом не ограничивали творческую свободу. Взять тот же ГОСТ 2.001-2013 и его п.п.4.2: По-моему для начала ТС нужно определиться с приоритетами целей при разработке "правил кодирования", что именно хочется регулировать и для чего в итоге. Потому что в первом приближении большинство программистов (я включаю сюда и разработчиков на языках описания аппаратуры), глядя на чужой код, говорят не желая разбираться, что "это гуано, а тот кто так пишет - тот ...", многоточие подставить по вкусу. Причем поражает то, что зачастую если бы говорящий это человек сам бы сел за решение этой задачи, то зачастую решение и описание было бы таким же или сходным, но в этом очень сложно признаться себе и другим. Т.е. в принципе это всё психология максимализма, т.к. в своём творении каждый разработчик это бог. А двух богов, как известно, быть не может. Вот и начинаются в итоге holy wars. Стандарт, например, в части оформления может сгладить хотя бы момент первоначального вхождения в тему, на уровне изучения исходников. Но основной вопрос ТС, как я понимаю, простирается намного дальше, только непонятно докуда. Поэтому я и предлагаю начать с того, чтобы сформулировать цели и задачи (вопросы) и отталкиваться от них, а иначе конструктивного обсуждения не получится, как уже показали предыдущие сообщения этой темы, где ТС балансирует на грани получения предупреждений за излишне эмоциональную реакцию и следующие из неё выражения. Я понимаю, наболело, но участники форума в этом совершенно не виноваты и вовсе не обязаны служить средством выпустить пар, поэтому есть правила и им необходимо следовать.

Неудачная транслитерация thermopile [↗θɜ:mɜʊpaɪl] _n. термоэлемент; термостолбик

Да, вы правы. У меня не было потребности в них, поэтому и не обращал внимание. Но тем не менее 5В индикатор не очень хорошо будет дружить с 3.3В МК.

Это, кстати, тоже. Пятивольтовых STM32 ЕМНИП нет.

Здесь, кстати, еще один нюанс. У STM32, на сколько я помню, нет контроллера LCD, аналогичного таковому у ATmega. Поэтому вполне вероятно, что вместе с МК придётся заменить и LCD.

Недостаточно исходных данных: В каком пакете была разработана оригинальная плата, что именно, кроме замены МК, требуется сделать. На каком языке написана оригинальная прошивка. Есть ли описание логики работы оригинальной прошивки или есть только исходный текст. Какой именно МК ST вы хотите использовать, т.к. они сейчас в весьма большом дефиците и пока всё выглядит как замена шила на мыло. По какому договору будет производиться работа.

У меня всё прекрасно качается.

Оффтопик и флуд скрыты. Продолжение в том же духе приведёт к предупреждениям и закрытию темы.

Да, там по сути речь идёт о тулчейне для SDK, который сейчас строится на базе Yocto. Как мне сказал представитель Xilinx, всё нужно постить в соответствующие разделы Xilinx Community и сотрудники будут переносить нерешаемые вопросы (баги) в их внутреннюю багзиллу. Но по моему текущему опыту с проблемой этой темы на такие сложные вопросы никто внимания не обращает, хотя вроде бы и должны. Поэтому и пришлось искать обходной путь.

В итоге подготовленный набор патчей я передал в Xilinx, правда не напрямую, а через разработчика от Xilinx, участвующего в проекте Yocto. Причём он сказал, что общей багзиллы у них нет, поэтому всё общение ведется через Xilinx Community и сотрудники его должно мониторить для последующего создания запросов во внутренней багзилле. Однако если хочется быстрой и более прямой реакции, то следует писать в список рассылки https://lists.yoctoproject.org/g/meta-xilinx. Это должно напрямую дать информацию сотрудникам Xilinx о проблемах, а они уже передадут дальше во внутреннюю багзиллу. PS: Правда судя по всему патчи примут нескоро, скорее всего они будут только в составе 2022.1. Но есть небольшая надежна, что их посчитают достаточно критичными для включения в какое-нибудь обновление для 2021.1

Темы такой не помню, но технически такую защиту можно сделать практически невзламываемой (при условии невозможности реверсинга прошивки ПЛИС и надёжной защиты МК от чтения) с помощью разделяемых между ПЛИС и МК ключей подписи или шифрования. ПЛИС генерит случайную посылку, отправляет в МК (интерфейс не важен), тот её подписывает имеющимся ключом и отправляет обратно. ПЛИС проверяет, если подписано демо-ключом, то работает 10 минут, если рабочим - пока не выключить. Прошивка МК неизвестна, ключ внутри прошивки МК и защищён от чтения, алгоритм подписи неизвестен. Подбирать случайные числа можно до бесконечности.

Это была выдержка из аппнота для седьмой серии: Они аккуратно переложили ответственность на конечного потребителя. В принципе это правильно, т.к. превращать недешевый кристалл в бесполезный кирпич - это ответственность и её должен нести разработчик изделия, делая это сознательно. И, как было написано в аппноте, RMA на такие кристаллы не распространяется, так что финансовые риски все на стороне потребителя. За безопасность нужно платить: