Nixon

Может и не влияет. Но лучше последовательность соблюдать. Кроме того посмотрите на время нарастания напряжений на источниках - не более 40ms до уровня 95%

"The recommended power-on sequence to achieve minimum current draw for the GTH or GTY transceivers is VCCINT, VMGTAVCC, VMGTAVTT OR VMGTAVCC, VCCINT, VMGTAVTT. There is no recommended sequencing for VMGTVCCAUX. Both VMGTAVCC and VCCINT can be ramped simultaneously." Т.е. обязательно требуется чтобы VMGTAVCC был раньше чем VMGTAVTT Я бы больше поставил все же на правильную последовательность чем на механический дефект - на это указывает также и то что при выключении и включении все работает нормально. Если вы не применяете rail discharge для своих питаний то это говорит о том что в этом случает неразряженные конденсаторы на VMGTAVCC (а там токи гораздо меньше) помогают соблюсти правильную последовательность

Если используете трансиверы то важно чтобы VMGTAVCC было раньше VMGTAVTT.

Тема всплывает не в первый раз: Возможно поможет.

LSF0102 и ему подобные почти от всех производителей. Хоть это и преобразователи уровня, но с входом EN. Отлично у меня работали и в качестве разделения шин I2C

Для конфигурации отладки в ./debugger/svd разместите svd файлы для вашего mcu и подправьте ./.vscode/launch.json (для openocd еще и ./debugger/openocd.cfg). Остальное (cmsis, startup's, и т.п.) размещайте как угодно - все через CMakeLists.txt указывается project template.zip

Я один раз сделал для себя несколько скриптов и с небольшой модификацией они кочуют из репозитория в репозиторий моих проектов для MCU Один разворачивает среду компиляции и сборки на чистой машине, второй подтягивает все для отладки под vscode для debian-based систем. Переделать под другое не составит никакого труда. bootstrap.sh bootstrap_debug.sh Если кому то интересно будет то выложу шаблон проекта под cmake

Round-robin обычно идет всегда в довесок к обычной схеме реакции RTOS на событие.

А вы дебажную информацию генерируете? "-g" флаг включен?

А я порекомендую посмотреть в сторону scmRTOS (тем более что ее авторы обитают на форуме). Очень полезно для понимания полезности С++ в МК.

Тема закрыта. Топикстартер перманентно забанен. Остальных предупреждаю усно - не ведитесь на грубость и провокации, жалуйтесь сразу модераторам.

Я тоже так думаю. Памяти на виртуалку и проца хватит чтобы не иметь проблем с недоделанным портом. Хотя я все же попробую на оракле. Чисто из интереса.

Как я и ожидал в процессе установки идет попытка установки rpm пакета /opt/mentorgraphics/EEVX.2.12/SDD_HOME/common/amd64_linux/bin/../../../../SDD_HOME/common/amd64_linux/bin/sdd_startmw: 1: /opt/mentorgraphics/EEVX.2.12/SDD_HOME/common/amd64_linux/bin/../../../../SDD_HOME/common/amd64_linux/MainWin5/setup-mwuser: rpm: not found ну а затем ошибка осутствия какого-то файла и вылет. Т.е. на debian-based дистрибутивах вряд ли получится. Вечером еще попробую на oraclelinux9 (клон rhel9), там скорее всего получится, но как говорил ранее makc, портированный сс винды софт скорее всего будет не полностью функциональным, наверное все же проще и надежнее будет запускать win-версию в виртуалке. P.S пытался поставить на kubuntu 22

Я вчера залил 2.12 для обеих платформ. Может там поправили. Но в любом случае в списке поддерживаемых linux платформ есть (и всегда были) только rpm-based.

Они же все имеют возможность настройки адреса I2С. Мы так и цепляем несколько десеров на одну шину с сома