SII

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

А... Тады может быть. У меня-то 2019 Community.

Т.е. при наведении мышиного курсора? Этого действительно нет. На курсор клавиатурный реагирует, как должно. Мне последнего вполне хватает, но мышиный вредным бы не был, конечно.

Студия умеет это подсвечивать (и подсвечивает -- просто по умолчанию подсветка не особо контрастна). Ежели что, настройка -- в Tools -> Options -> Environment (раздел параметров) -> Fonts and Colors (подраздел) -> Text Editor (в выпадающем списке) -> Brace Matching. Не свободный, но бесплатный, ежели Community.

Представляете, идея от русскоязычных пользователей: полностью выкинуть русский интерфейс из всех программ? :) Я, кстати, проголосовал бы за такое, ибо в принципе не вижу никакого смысла в локализации любого профессионального ПО. Другое дело -- возможность использования любых символов внутри ПО (для свойств и т.п.), вот это нужно сделать. Но вряд ли мы дождёмся такого, ибо это надо полностью всё переписать...

А по куску имени секции не получится? i.__sti___ -- это, похоже, всегда будет.

Ну, допустимый ток низкого уровня для ТТЛ-выхода -- до 16 мА, а там на землю замыкает обычный транзистор без резистора. В верхнем же плече стоит резистор в 130 Ом; соответственно, если отталкиваться от него, может течь ток около 40 мА.

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

Разве что если не подали питание на одну из питающих ног, к которой привязан и этот -- но тогда подобное поведение будет у всей группы ног, подключённых к общему питанию (это не обязательно ноги одного порта). Но, скорей всего, нога таки убита (статикой, например -- у меня такое было, но с совершенно другим МК и лет 10 назад). Ну а на выброс или нет -- зависит от того, насколько дохлая нога реально нужна. ADD. Если он с открытым стоком (OD вроде ж это означает?), то надо обеспечить подтяжку к питанию. Вы её сделали? ADD2. А нет, OD -- это выходные данные, а не открытый сток, который явным образом нигде, похоже, не задаётся...

Для STM32H745/755/747/757 описание, как работать с питанием, содержится в соответствующем разделе Reference Manual'а (не даташита!), там же есть и варианты подачи питания. Там довольно хитро, причём, если проц будет гоняться на максимальной частоте, не все схемы годятся. Надо полагать, что и для Вашего МК подобное приведено. А ST-LINK, вполне вероятно, нужно именно третий: проц же достаточно новый, да ещё двухъядерный...

Если память не изменяет, в такой ситуации никакой сдвиговый регистр по стандарту получен быть _не_ может: при срабатывании блока always, т.е. по фронту clk, текущее значение A0 мгновенно переносится в А1, А1 (т.е. то же, что было в А0 на момент начала) -- В А2 и т.д. В итоге получаем, что A1, A2, A3 -- это идентичные сигналы, а посему для хранения состояния достаточного одного триггера. А вот если <= использовать, тогда уже да -- сдвиговый регистр, поскольку значение справа от <= вычисляется логически перед фронтом clk, а присваивание левой части выполняется уже после фронта, а не мгновенно. А синтезаторы все кривые и глючные, это да...

Если высота только одна, её проще задать в свойствах Cell Editor: Если же построен сложный контур с разными высотами, то это нужно уже в собственно редакторе выбирать нужные элементы контура и в их свойствах менять.

Это неполноценное решение по той причине, что читать выпущенный pdf можно лишь на машине, где эти шрифты имеются. Нет шрифтов -- будут крякозябры, т.к. десигнеровский экспортрёр в pdf не умеет не только правильные атрибуты символов указывать, но и шрифты внедрять в документ (что технически возможно). В жадности акционеров и руководства компании. Чтобы внедрить поддержку Юникода, надо переписать продукты полностью -- а это, понятное дело, большие трудозатраты, усугубляемые тем, что всё было написано давным-давно, исходных разработчиков, вполне может быть, уже и в живых-то нет, и уж практически наверняка их нет в Менторе, ну и т.д. и т.п. Т.е. решить эту проблему можно, но дорого, и "эффективные менеджеры" на такое не пойдут -- тут нужны Иосиф Виссарионович с Лаврентий Палычем. Кстати говоря, кривая поддержка национальных кодировок и т.п. встречается в основной массе профессионального софта -- не только в САПР, но и, например, средств разработки ПО. Современные программисты ленивы, менеджеры жадны и все вместе тупы :)

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

У меня та же проблема была, и она не лечится подобным образом. Кажется -- но я не уверен -- она возникала при физическом отсутствии реального принтера в сети (Designer не видел тогда вообще никаких принтеров, хотя все остальные программы благополучно видели майкрософтовскую печать в pdf).

Ага, но я-то говорю про Экспедишн с ЕДМ -- как по мне, он абсолютно превосходит по удобству датабук. Мне, кстати говоря, цепочки поставок даром не нужны, а вот возможность организовывать иерархию компонентов, не совпающую с недоиерархией (плоский набор разделов) ЦБ, -- очень даже полезна.

Странно, судя по скриншоту, сервер не разворачивался -- поэтому здесь есть Config and Deploy, т.е. настроить и развернуть сервер. Когда он уже развёрнут (даже если остановлен), вместо этого появляется Undeploy. А насчёт мороки... Ну, в своё время я, кажется, на 7.9.5, довольно долго со всем этим помучился, но в дальнейшем особых проблем не возникало. Сейчас вот перешёл на PADS Pro, и с Databook работать не могу: она отвратительна со всех точек зрения. Поэтому ей не пользуюсь вообще, ищу прямо в ЦБ -- примерно так же неудобно, но, во всяком случае, не требуется присобачивать внешнюю базу, всё это настраивать и т.п. и при этом всё равно иметь крайне убогие возможности. Чесслово, был бы миллионером -- купил бы Экспедишн, а не Падс, только ради этого :) Хотя реально не только б ради этого, понятно дело.

А ещё может оказаться, что АЦП требуется отдельное тактирование. Кажись, в STM32L1xx именно так: проц и шины (а значит, и регистры АЦП) -- отдельно, а собственно АЦП -- отдельно.

У меня ставился и успешно работал на довольно хилой машине (то ли 8, то ли 16 гигами ОЗУ, но не больше). Посмотрите параметры его конфигурации -- там их довольно много, и не все показываются вот так сразу (надо вытащить значки для их просмотра), так что может оказаться, что он по умолчанию много пользователей поставил или ещё что в этом роде.

Разработкой ОС, написанием драйверов и т.п. низкоуровневой фигнёй занимается тоже меньше 1% программистов, а основная масса тусуется в веб-разработке. Разработчиков компиляторов, кстати, ничуть не больше. Значит, всё это не нужно -- всем в веб, остальное упразднить.

Если память не изменяет, всё выражение будет считаться знаковым, если в нём есть знаковые операнды -- а 25 у Вас было знаковое, как Вы сами и написали (примерно то же самое с вычислениями с плавающей запятой: если есть операнд double, то и все вычисления будут в double, а по умолчанию константы трактуются именно как double. если принудительно f не написать). Соответственно, компилятор moFault тоже преобразовал в знаковое -- и загрузил из памяти уже как знаковое, а не беззнаковое. Но для точности надо б стандарт читать -- а это лениво :)

Какое-нибудь там БПФ и прочая обработка сигналов с приличными по размерам массивами данных, например. Но да, "нормальные люди" под такие задачи используют ПЛИСы или, на худой конец, 100500-тыщеядерные процы на 100500-тыщ ГГц. А, ещё, программировать всё это сейчас надо на Питоне.

А если эти несколько тактов идут в цикле, выполняемом миллионы раз?

Если не изменяет память, B0[31-:16] -- это взять 16 линий подряд из шины B0, начиная с линии 31 и двигаясь в сторону уменьшения номеров -- т.е. взять линии 31:16. Соответственно, для B0[15-:16] -- взять 16 линий, начиная с линии 15, и тоже в сторону уменьшения -- т.е. линии 15:0. Для чего так писали, непонятно.

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