jcxz 184 22 декабря, 2023 Опубликовано 22 декабря, 2023 · Жалоба Подскажите пожалуйста линк на подробную документацию по "USB Power Delivery 3.0". Интересует именно последняя версия = 3.0. И главным образом - уровень протокола обмена (формат сообщений, их последовательность, алгоритм действий сторон (источника и приёмника), DRP (обмен ролями источник-приёмник) и т.д.). Особенно интересует алгоритм DRS (data role swap) в DRP. Из того, что находил, наиболее полное: https://habr.com/ru/companies/sberdevices/articles/571362/ https://habr.com/ru/articles/166661/ но уже устаревшее, неактуальное. Формат структур в PD3.0 несколько изменился. А по PD3.0 находятся только обрывочные данные. Хочется более-менее детального описания. Чтобы не нужно было собирать по кусочкам отовсюду. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Flood 12 22 декабря, 2023 Опубликовано 22 декабря, 2023 · Жалоба https://www.usb.org/document-library/usb-power-delivery Актуальнее и подробнее некуда 🙂 1 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 184 22 декабря, 2023 Опубликовано 22 декабря, 2023 · Жалоба Спасибо! Почему-то до сюда не дошёл. Самое полезное получается здесь: https://www.usb.org/document-library/usb-power-delivery USB PD R3.2 V1.0\USB PD R3.2 V1.0\USB_PD_R3_2 V1.0 2023-10.pdf PS: Получается, что в зависимости от ревизии - одни и те же поля данных структур имеют разное значение. И интерпретировать их нужно в зависимости от номера ревизии. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 184 17 января Опубликовано 17 января · Жалоба Ещё один вопрос по USB Power Delivery. Может кто знает... Проверил два имеющихся под рукой ноутбука с портами USB-C: Оба в сообщении Source_Capabilities выдают список напряжений (которые они могут выдать наружу) состоящий всего из одного пункта: "5V, 3A". Причём один бук работает в ревизии "Power Delivery 2.0"; 2-й - "Power Delivery 3.0". Буки от разных вендоров. А хотелось получить от бука напряжение большее 5V. (именно от бука или от стационарного ПК; "power bank"-и не интересуют). Вопрос такой: кому-нить из здесь присутствующих достоверно известно - это все ноуты могут выдать только дефолтные +5V и более ничего? Или просто мне попались такие убогие модели, больше ничего не умеющие? Может кто знает модели буков/материнки_ПК, которые могут выдавать через Power Delivery бОльшие напряжения? Или где посмотреть такую инфу (по возможностям буков/материнок как источников питания через USB-C)? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Flood 12 18 января Опубликовано 18 января · Жалоба On 1/17/2024 at 4:28 AM, jcxz said: Может кто знает модели буков/материнки_ПК, которые могут выдавать через Power Delivery бОльшие напряжения? Ноутбуков таких не встречал. Десктопные материнки начали появляться. Бывает, один порт делают под Power Delivery (часто в расчете на подключение монитора). Искать придется среди топовых линеек современных на 2022-2023 год плат. Еще вот такое обещают, но что-то оно задержалось: https://www.msi.com/PC-Component/USB4-PD100W-EXPANSION-CARD В разрезе подключения питания и данных в одном разъеме. Понятно, что эта тема на ПК и ноутах только-только начинает появляться. Но вот с точки зрения ведомого девайса - ранее было требование о том, что устройства должны выдерживать КЗ VBUS 5V на линии данных. А теперь VBUS = 20V, а потенциально в ближайшем будущем - 36V и даже 48V. И как жить? В Type-C разъеме рядом с VBUS лежат CC и SuperSpeed пины... 1 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 184 23 января Опубликовано 23 января · Жалоба В 18.01.2024 в 21:59, Flood сказал: В разрезе подключения питания и данных в одном разъеме. Понятно, что эта тема на ПК и ноутах только-только начинает появляться. Да, печально. Надеялся, что уже есть. В 18.01.2024 в 21:59, Flood сказал: Но вот с точки зрения ведомого девайса - ранее было требование о том, что устройства должны выдерживать КЗ VBUS 5V на линии данных. А теперь VBUS = 20V, а потенциально в ближайшем будущем - 36V и даже 48V. И как жить? Так защитные диоды или стабилитроны разве не спасут? Думаю им главное - неск. мсек продержаться, а дальше PD-контроллер источника должен отключить подачу тока. В 18.01.2024 в 21:59, Flood сказал: В Type-C разъеме рядом с VBUS лежат CC и SuperSpeed пины... Линии CC допускают последовательное сопротивление в неск. десятком Ом. Защитное. Я тут сделал схему согласования LPC1768 с USB-C (только питание и CC): И написал драйвер - работает стабильно. Резисторы R1, R2 - защитные, работе не мешают (номиналы взяты наугад, может не самые оптимальные). После R2 можно поставить защитный стабилитрон на GND. R4 задаёт начальное питание +5V и уровень тока. На LPC1768 драйвер работает используя периферию: ШИМ (на ввод; P1.28, P1.29) и один таймер+DMA (вывод; P1.22). Драйвер позволяет запрашивать нужное напряжение от источника через PowerDelivery3.0. Схема рассчитана на запитку от USB-C без дополнительного источника питания (стартует с +5V). Смысл всего этого: Проверить возможность получения высокого питания для схемы без использования специализированного дорогого контроллера PD на обычном МК без аппаратной поддержки PD. Работает. 1 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 184 23 января Опубликовано 23 января · Жалоба Странно, что если запросить (и получить) через PowerDelivery3.0 от источника высокое напряжение через какой-либо профиль фиксированного напряжения, то это напряжение источник выдаёт похоже сколь угодно долго. Без каких-либо дополнительных транзакций от потребителя. А если запросить напряжение через PPS-профиль этого же источника, то источник выдаёт его только 14 сек. После чего сбрасывается на дефолтные +5V. Как будто он ожидает ещё какого-то сообщения от потребителя? (если выбран PPS-профиль). Которое я не выдаю. Какого - непонятно. Где бы найти дорожные карты (блок схемы алгоритмов) обмена потребитель<->источник для разных сценариев работы? Чтобы понять - что ему ещё нужно? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
UART 14 26 января Опубликовано 26 января · Жалоба по-моему это все расписано в стандарте. в целом особенность выдачи напряжения выше 5В и скольки-то ампер заложена еще и в самой микросхеме PD и самим дизайном платы ноутбука. если порт type-C это совсем не значит он выдаст 100Вт (20В/5А) как этим стандартом описано. в целом есть процедура обмена между PS/PD и источник говорит сколько может выдать, а потребитель сколько принять. гуглите type-C PD handshake https://www.embedded.com/usb-type-c-and-power-delivery-101-power-delivery-protocol/ Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Flood 12 27 января Опубликовано 27 января · Жалоба On 1/23/2024 at 4:59 PM, jcxz said: Где бы найти дорожные карты (блок схемы алгоритмов) обмена потребитель<->источник для разных сценариев работы? Чтобы понять - что ему ещё нужно? Понятно, что основа - в стандарте, но некоторые примеры можно найти здесь: https://usbchargingblog.wordpress.com/ И даже сложные случаи частично описаны: https://usbchargingblog.wordpress.com/2022/04/22/apple-140w-usb-c-pd-3-1-epr-power-adapter-part-1-how-it-charges-a-16-inch-macbook-pro-2021/ Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 184 28 января Опубликовано 28 января · Жалоба В 26.01.2024 в 20:43, UART сказал: в целом есть процедура обмена между PS/PD и источник говорит сколько может выдать, а потребитель сколько принять. К чему это всё понаписали? Вы хоть бы вопрос прочитали, что-ли.... В 27.01.2024 в 09:31, Flood сказал: Понятно, что основа - в стандарте, но некоторые примеры можно найти здесь: https://usbchargingblog.wordpress.com/ Прошерстил многое из этого, но не нашёл ни одного примера запроса питания из профиля с напряжением, заданным диапазоном (PPS или подобных). Не можете ли указать конкретную ссылку? В 27.01.2024 в 09:31, Flood сказал: И даже сложные случаи частично описаны: https://usbchargingblog.wordpress.com/2022/04/22/apple-140w-usb-c-pd-3-1-epr-power-adapter-part-1-how-it-charges-a-16-inch-macbook-pro-2021/ Касательно темы вопроса, там есть только один пример, близкий к теме: Цитата Packet #37: The power adapter sent the second part of its EPR Source Capabilities as Fixed 28V 5A and AVS 15-28V 140W. Packet #39: The MacBook requested 28V @ 4.71A. Packet #57: The MacBook wanted 28V @ 5A later on. Packet #523-530: When the MagSafe 3 connector was disconnected from the MacBook, the power adapter initiated a Hard Reset to return to its default state, and the cable acted as a PD trigger again like what it did at the beginning. Но даже здесь похоже напряжение выбирается из фиксированного профиля "Fixed 28V 5A". И в последовательности запросов/ответов не вижу ничего принципиально отличающегося от аналогичной последовательности при работе моей программы. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Flood 12 29 января Опубликовано 29 января · Жалоба 8 hours ago, jcxz said: Но даже здесь похоже напряжение выбирается из фиксированного профиля "Fixed 28V 5A". И в последовательности запросов/ответов не вижу ничего принципиально отличающегося от аналогичной последовательности при работе моей программы. Похоже, между пакетами 57 и 523 в этом примере происходил периодический обмен сообщениями. Возможно, один из простых вариантов - сделать вариант вашей программы сниффером PD и посмотреть, какие идут обмены между БП и "правильным" PD триггером в различных режимах. Я когда-то хотел разобраться с PD, но изучив документацию и рынок, просто поставил CH224K 🙂 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 184 29 января Опубликовано 29 января · Жалоба 9 часов назад, Flood сказал: Похоже, между пакетами 57 и 523 в этом примере происходил периодический обмен сообщениями. Судя по тому логу, запрошенное напряжение предоставляется источником после пакета 62: До него (от 57-го до 62-го) - обычная последовательность. Точно такую же я наблюдаю у себя при работе своего ПО. У меня всё заканчивается на моём кадре GoodCRC после принятого кадра PS_RDY. Как видно - дальше следует какой-то Get_Status от потребителя, на который источник отвечает Not_Supported. А что дальше - не видно. Да и вряд-ли полезно, так как тут похоже запрошен fixed-профиль, а с ним и так всё ок. 9 часов назад, Flood сказал: Возможно, один из простых вариантов - сделать вариант вашей программы сниффером PD и посмотреть, какие идут обмены между БП и "правильным" PD триггером в различных режимах. Это уже всё сделано. Но только сделал сниффер обмена своей программы. А просмотреть чужой обмен просто не на чем: У меня в качестве эталонного потребителя с PowerDelivery последней версии есть только ноут. Но он запрашивает только +20V и отказывается питаться если источник не выдаёт такого напряжения. А в PD-источнике имеется только один PPS-профиль = 3.3...11V + несколько фиксированных профилей. Соответственно запрос ноута попадает на фиксированный профиль и PPS не используется. И все примеры обменов, которые я находил где-либо - везде только запросы фиксированных профилей. Так что правильный обмен по PPS-профилю (или по AVS-профилю) посмотреть негде. Лог обмена моего ПО с PD-источником с запросом напряжения 11.3V из PPS-профиля: Лог каждого кадра начинается со строки с "-+-+-+-+-+-+..."; заканчивается - "=========...". "<<<<-+-+-+-+..." - исходящие кадры (от моего ПО). ">>>>-+-+-+-+..." - входящие кадры (от PD-источника). Синее число в строке "-+-+-+-+..." - значение “Message Header”; зелёное или красное 32-битное значение в [] - CRC кадра. Видно, что у PD-источника 6 профилей, последний из которых - PPS. Запрашивается +10.3V, которое выбирается естественно из PPS-профиля. После последнего исходящего GoodCRC-кадра, PD-источник выставляет +10.3V. Затем - держит его 14сек. Затем - присылает сообщение HardReset (RST-1,RST-1,RST-1,RST-2) и сбрасывает напряжение в дефолтные +5V. Сам лог выглядит нормальным. Точно таким же, как и для фиксированного профиля (такая же последовательность сообщений; их содержимое конечно иное). Единственная странность: в GoodCRC-кадре, выдаваемом PD-источником на мой Request-кадр, почему-то указана версия спецификации == 2.0. В то время как во всех других кадрах = 3.0. Но это и в случае с запросом fixed-профиля - то же самое. Вот запрос +15V из fixed-профиля: Как видно - последовательность сообщений такая же, как с PPS. Но после неё выданные +15V держатся сколь угодно долго, без какой-либо активности по CC-линии. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Flood 12 29 января Опубликовано 29 января · Жалоба 2 hours ago, jcxz said: Так что правильный обмен по PPS-профилю (или по AVS-профилю) посмотреть негде. https://www.witrn.com/?p=1315 Посоветовал бы купить такой брелок, модели C4 или C5. Читает профили с источников и триггерит что угодно. Может вставать в разрыв. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
MGMT 2 30 января Опубликовано 30 января · Жалоба 13 hours ago, jcxz said: Лог обмена моего ПО с PD-источником с запросом напряжения 11.3V из PPS-профиля: Лог каждого кадра начинается со строки с "-+-+-+-+-+-+..."; заканчивается - "=========...". "<<<<-+-+-+-+..." - исходящие кадры (от моего ПО). ">>>>-+-+-+-+..." - входящие кадры (от PD-источника). Синее число в строке "-+-+-+-+..." - значение “Message Header”; зелёное или красное 32-битное значение в [] - CRC кадра. Видно, что у PD-источника 6 профилей, последний из которых - PPS. Запрашивается +10.3V, которое выбирается естественно из PPS-профиля. После последнего исходящего GoodCRC-кадра, PD-источник выставляет +10.3V. Затем - держит его 14сек. Затем - присылает сообщение HardReset (RST-1,RST-1,RST-1,RST-2) и сбрасывает напряжение в дефолтные +5V. Сам лог выглядит нормальным. Точно таким же, как и для фиксированного профиля (такая же последовательность сообщений; их содержимое конечно иное). Единственная странность: в GoodCRC-кадре, выдаваемом PD-источником на мой Request-кадр, почему-то указана версия спецификации == 2.0. В то время как во всех других кадрах = 3.0. Но это и в случае с запросом fixed-профиля - то же самое. Отправляйте запросы PPS каждые 10 секунд или меньше в качестве механизма поддержания активности. 1 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 184 30 января Опубликовано 30 января · Жалоба 18 минут назад, MGMT сказал: Отправляйте запросы PPS каждые 10 секунд или меньше в качестве механизма поддержания активности. Да, я уже нашёл это ещё вчера в "Universal Serial Bus Power Delivery Specification": Цитата • For SPR PPS operation: • the Source starts its keep alive timer. • the Sink starts its request timer to send periodic Request Messages. Цитата A Sink operating in the SPR PPS mode periodically sends Request Message within tPPSRequest even if its request is unchanged. Цитата When the Sink operating in the PPS mode fails to send periodic communication (i.e. a Request Message) to the Source within tPPSRequest, the Source will issue a Hard Reset that results in V BUS going to vSafe5V. Забыл написать. Ещё не попробовал. Но всё равно - спасибо. Где-ж вы были раньше? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
