Лидеры

Да вся тема выеденного яйца не стоит. Сравнил распиновку - принял решение. Можно еще сравнить альтернативные функции выводов. Ради этого тему вообще поднимать не стоило.

Это делают суммирующим усилителем, местные рули какого-то ОУ здесь не при чём.

Есть, используя скрытые Pin. Но не советую.

При достаточном упорстве, наличии свободного времени и провода ПЭВТЛ - можно посадить любой STM32, даже в BGA . Выглядеть будет очень завораживающе. Примерно так:

Для этого надо делать резервное копирование. Некоторые люди считают, что система контроля версий git служит и для этого, но это заблуждение. Удалённые репозитории для публикации и обмена, а не для хранения резервных копий. Например, вы можете публиковать далеко не все ветки, которые есть у вас. И эти локальные ветки в случае утери локального репозитория потеряются безвозвратно. А пушить всё подряд на удалённый сервер -- так себе практика, оно не для этого предназначено. Кстати, именно поэтому git -- это система управления версиями с локальным репозиторием, а не с распределённым, как её частно называют. Никакой распределённости репозитория реально нет, а есть только локальные, которые могут обладать уникальным содержимым, которое не может быть восстановлено в случае утраты из репозиториев других участников проекта. Кроме того, в рабочих материалах могут находиться какие-то временные файлы, которые не удостоины того, чтобы попасть в истоирию, но которые в моменте важны, их утеря может создать препятствия в работе. Поэтому регулярное резервное копирование рабочих материалов и решает все эти проблемы. У меня оно делается автоматически каждую ночь по расписанию (комп вы выключается).

Такого не может быть от слова совсем. Разбирайтесь с ПО. Дело только в нём. Вот с прерываниями и нужно разбираться. "Лаба простая" - ни о чём не говорит. Может быть у Вас там в обработчике прерывания задержка стоит, или иные, другие команды, сильно влияющие на ход выполнения программы.

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

Продолжаем разматывать использование входных ресурсов для приёма быстрых последовательных потоков данных. Новости на сегодняшний день следующие. 1. IEM, созданный по заверениям производителей для работы в связке с IODELAY, оказался подключенным не к выходу последнего, а непосредственно ко входному паду. Уж не знаю, это программный баг Gowin FPGA Designer 1.9.8.08, или аппаратная фича кристалла, но в любом случае IEM становится бесполезен. Придётся от него отказаться совсем. 2. На IODELAY отсутствует сброс, что немного усложняет жизнь при перетренировке линии. Начинать придётся не с начала, а с ранее накрученной задержки. 3. Косвенно измерил задержку на один тап IODELAY. Измерения, конечно, никакой метрологической критики не выдерживают, но хоть что-то о количестве настройщиков пианино в Нью-Йорке Чикаго теперь известно. Мерял глаз для 675 Мбит/с Измерение 1 Длина от первого кроссовера до последнего - 64 тапа Измерение 2 с дополнительной ёмкостью на линии в виде пальца. Получилось, опять же, 64 тапа. При длительности битового интервала 1/675 = 1481 пс получаем, что один тап примерно равен 23 пс. Что ближе к модели (25 пс), чем к даташиту (18 пс). Хотя и не соответствует точно ни тому, ни другому.

Проверил появление DONE относительно фронта PERST# - от появления единицы на DONE до появления единицы на PERST# проходит около 200 мс при холодном старте. При теплой перезагрузке длительность активного уровня PERST# около 8 мс. Проверил источники и с ними оказалось всё в полном порядке по всем без исключения номиналам. В итоге решил прозвонить линии PCI-E методом обратной прозвонки (красный щуп мультиметра на земле, чёрным щупаю контакты) в режиме прозвонки диода и здесь начались чудеса. У исправно работающей платы: на MGTREFCLK(P/N) и на MGTPRX(P/N) падение около 0,83 В; на MGTPTX(P/N) около 0,42 В. У сбоящей платы значения оказались совсем другими: на MGTREFCLK(P/N) те же 0,83 В, что и у рабочей; на MGTPRX(P) падение около 0,43 В, на MGTPRX(N) падение около 0,25 В (явная аномалия); на MGTPTX(P) около 0,25 В, а на MGTPTX(P/N) около 0 В. Итого: всё выглядит так, что на проблемной плате статикой прошило блоки приёма/передачи гигабитного трансивера ПЛИС, но не убило до конца. Когда-то был случай, когда прошило MGTREFCLK и в этом случае линк не поднимался даже при холодном старте (что логично). Здесь же линк работал, но только один раз и похоже после ресета приёмнику на мат.плате становилось совсем грустно и он отказывался видеть передаваемые платой TS1/TS2, т.к. LTSSM из Polling.Active уходит в Polling.Compliance. Удивляет только то, что после теплой перезагрузки на короткий миг там всё-таки проскакивает состояние L0, но из него уходит в Recovery из которого уже не возвращается (переходит в Disabled). На ещё одной сбоящей плате была непонятно какая прошивка и после перепрошивки актуальной версией всё стало работать корректно, при учёте правильный показателей при обратной прозвонке.