jcxz

Чего не сделаешь, когда боишься паяльник в руки взять.

Не нужно мне приписывать чужие слова! Уверены? Чем подтвердите? Например из документации IAR: В других компиляторах тоже видел нечто подобное.

Для отключения SPI EEPROM, достаточно коммутировать только её CS. И коммутировать нужно логическим элементом или аналоговым коммутатором или джампером/переключателем, а не транзисторным колхозом.

У меня в разных проектах - по-разному. Где как удобнее. Где-то и в середине есть. Кстати - почему Вы в своих исходниках применяете такие имена?: Разве имена, начинающиеся с _ или с __ не зарезервированы для компиляторов (или их встроенных библиотек)?

А почему не первым, раз так удобнее? Просто передоговориться по новой и всё.

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

А если всё же включить голову и перечитать ещё раз?:

Вы вообще прочитали то, что я писал?: А вы опять пытаетесь слепить вместе несколько неизвестных: передачу + приём вашим устройством. Отлаживать неизвестное (ваш девайс) нужно, работая совместно с заранее известно работоспособным (чужим готовым девайсом; например - роутером). А не два неизвестных вместе. Вы занимаетесь разработкой чего-то на Ethernet, даже не приобретя нормального оборудования для отладки??? На самом дешёвом роутере для домохозяек??? Нет. Вы вообще читали, что я писал? Я писал, что конфигурируя роутер можно включить дуплексный или полудуплексный режим работы. Проверив тем самым ваше предположение и неработе в дуплексном режиме. Также можно проверить работу на разных скоростях. Какая "автоподстройка в процессе работы"? Вы в курсе, что такое "Ethernet auto negotiation"? Используете её в своём устройстве или нет? https://ru.wikipedia.org/wiki/Автосогласование

Кошмар.... Отрубание хвоста собаки по частям.

Понятия не имею. Но думаю (учитывая экономность китайцев) - должны быть. Про опциональность я читал где-то в документации USB PD. Когда разбирался с PD.

Это вроде как опционально. Каждый кабель не обязан (но может) поддерживать 2-стороннее втыкание. А значит и не все цепи могут быть спарены.

В чём именно "передёргивание"? В детстве у тётки в деревне я переловил кучу мух просто рукой. Именно - на лету рукой. Иногда удавалось поймать сразу 2-х за раз. Никакие ганглии им не помогали. И то были надёжные, советские мухи. Не в пример нынешним. Неужто за прошедшие десятилетия произошли мутации и вывелся какой-то особо вёрткий вид мух? Или нынешние дети стали тормознее и не способны ловить мух? И на лету - запросто. При должной сноровке. Тут главное - предугадывать куда она полетит и делать нужное упреждение. Мухи не такие манёвренные, как вам кажется. Хотя...... всё относительно. Для улитки наверное даже неспешно двигающийся человек кажется адски мельтешашим...

Нет, не правильно. Одним коннектором не обойтись. Нужно ещё: 1) или реализовать у себя в контроллере протокол USB Power Delivery 2.0 или выше (и через него общаться и запрашивать от источника нужные токи/напряжения) и согласовать МК с цепью USB-CC; 2) или поставить внешний чип, реализующий такой протокол через USB-CC. Без этого сможете получать только +5V с USB. Кроме того: USB-хост должен поддерживать выдачу высоких напряжений через USB PD. А с этим сейчас сложно: В настоящее время это умеют только зарядники с USB PD. А в ПК/буках как правило стоит драйвер PD, умеющий выдавать только +5V. Хотя платы расширения USB с PD с высокими напряжениями для ПК уже вроде начали появляться. И возможно что и буки скоро появятся. А может в некоторых материнках/буках вообще нужно только обновить прошивку для появления поддержки выдачи высоких напряжений (это было бы круто!). Вообще я же совсем недавно здесь создавал тему про USB PD: Там всё есть про мои недавние эксперименты с USB PD. Почитайте. PS: И зачем тащить SPI через USB? К тому же - так далеко. SPI - интерфейс не предусмотренный для длинных линий. Лучше на большие расстояние передавать через тот же USB. Который гораздо более для этого подходит.

Тогда получится = баг в квадрате. И проблему будет вообще не найти. Проблему ищут убирая неизвестные, по частям. Если есть подозрение, что не работает какая-то скорость/режим, то следует отключить все прочие скорости/режимы (оставив только исследуемую) и подключить отлаживаемый девайс к заведомо исправно работающему устройству на заведомо известной скорости/режиме.

В чём именно проблема? Вы же конфигурируете физику и MAC? Если да, то среди прочих настроек там указывается режим работы: дуплекс или полудуплекс и скорость (10M, 100M, ...). Обычно ставят "Auto", тогда подходящий режим выбирается на стадии согласования двух сторон во время negotiation-фазы. Но никто не мешает указать конкретные разрешённые режимы - например только полудуплексные (10M_half, 100M_half, ...). Кроме того - можно ограничить используемые режимы в роутере, в который воткнуто устройство. Вот например как соответствующая вкладка свойств для одного из Ethernet-разъёмов выглядит в моём Mikrotik-е: Ограничить используемые Auto Negotiation-процессом режимы работы, можно с помощью этих чекбоксов. Можно и вообще фазу Auto Negotiation запретить, оставив только один из режимов-скорость.