Jump to content
    

Документация на USB Power Delivery 3.0

Подскажите пожалуйста линк на подробную документацию по "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 находятся только обрывочные данные. Хочется более-менее детального описания. Чтобы не нужно было собирать по кусочкам отовсюду.

Share this post


Link to post
Share on other sites

Спасибо! Почему-то до сюда не дошёл.

Самое полезное получается здесь: 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: Получается, что в зависимости от ревизии - одни и те же поля данных структур имеют разное значение. И интерпретировать их нужно в зависимости от номера ревизии.  :sad:

Share this post


Link to post
Share on other sites

Ещё один вопрос по USB Power Delivery. Может кто знает...

Проверил два имеющихся под рукой ноутбука с портами USB-C: Оба в сообщении Source_Capabilities выдают список напряжений (которые они могут выдать наружу) состоящий всего из одного пункта: "5V, 3A":sad: Причём один бук работает в ревизии "Power Delivery 2.0"; 2-й - "Power Delivery 3.0". Буки от разных вендоров.

А хотелось получить от бука напряжение большее 5V. (именно от бука или от стационарного ПК; "power bank"-и не интересуют).

 

Вопрос такой: кому-нить из здесь присутствующих достоверно известно - это все ноуты могут выдать только дефолтные +5V и более ничего? Или просто мне попались такие убогие модели, больше ничего не умеющие? Может кто знает модели буков/материнки_ПК, которые могут выдавать через Power Delivery бОльшие напряжения?

Или где посмотреть такую инфу (по возможностям буков/материнок как источников питания через USB-C)?

Share this post


Link to post
Share on other sites

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 пины...

Share this post


Link to post
Share on other sites

В 18.01.2024 в 21:59, Flood сказал:

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

Да, печально. Надеялся, что уже есть.  :sad:

В 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):

LPC1768-PowerDelivery.thumb.png.4e4586ba5d5752298869bd6860ce62af.png

И написал драйвер - работает стабильно. Резисторы R1, R2 - защитные, работе не мешают (номиналы взяты наугад, может не самые оптимальные). После R2 можно поставить защитный стабилитрон на GND. R4 задаёт начальное питание +5V и уровень тока.

На LPC1768 драйвер работает используя периферию: ШИМ (на ввод; P1.28, P1.29) и один таймер+DMA (вывод; P1.22).

Драйвер позволяет запрашивать нужное напряжение от источника через PowerDelivery3.0. Схема рассчитана на запитку от USB-C без дополнительного источника питания (стартует с +5V).

 

Смысл всего этого: Проверить возможность получения высокого питания для схемы без использования специализированного дорогого контроллера PD на обычном МК без аппаратной поддержки PD. Работает.  :dance4:

Share this post


Link to post
Share on other sites

Странно, что если запросить (и получить) через PowerDelivery3.0 от источника высокое напряжение через какой-либо профиль фиксированного напряжения, то это напряжение источник выдаёт похоже сколь угодно долго. Без каких-либо дополнительных транзакций от потребителя. А если запросить напряжение через PPS-профиль этого же источника, то источник выдаёт его только 14 сек. После чего сбрасывается на дефолтные +5V. Как будто он ожидает ещё какого-то сообщения от потребителя? (если выбран PPS-профиль). Которое я не выдаю. Какого - непонятно. :umnik2:

Где бы найти дорожные карты (блок схемы алгоритмов) обмена потребитель<->источник для разных сценариев работы? Чтобы понять - что ему ещё нужно?

Share this post


Link to post
Share on other sites

по-моему это все расписано в стандарте.

 

в целом особенность выдачи напряжения выше 5В и скольки-то ампер заложена еще и в самой микросхеме PD и самим дизайном платы ноутбука.

если порт type-C это совсем не значит он выдаст 100Вт (20В/5А) как этим стандартом описано.

в целом есть процедура обмена между PS/PD и источник говорит сколько может выдать, а потребитель сколько принять.

гуглите type-C PD handshake 

image.png.dcf7888793147999bfcb3c7e4b2dd0ae.png

 

https://www.embedded.com/usb-type-c-and-power-delivery-101-power-delivery-protocol/ 

 

Share this post


Link to post
Share on other sites

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/

Share this post


Link to post
Share on other sites

В 26.01.2024 в 20:43, UART сказал:

в целом есть процедура обмена между PS/PD и источник говорит сколько может выдать, а потребитель сколько принять.

К чему это всё понаписали? :wacko2:  Вы хоть бы вопрос прочитали, что-ли....

В 27.01.2024 в 09:31, Flood сказал:

Понятно, что основа - в стандарте, но некоторые примеры можно найти здесь:

https://usbchargingblog.wordpress.com/

Прошерстил многое из этого, но не нашёл ни одного примера запроса питания из профиля с напряжением, заданным диапазоном (PPS или подобных).

Не можете ли указать конкретную ссылку?

В 27.01.2024 в 09:31, Flood сказал:

Касательно темы вопроса, там есть только один пример, близкий к теме:

Цитата

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". И в последовательности запросов/ответов не вижу ничего принципиально отличающегося от аналогичной последовательности при работе моей программы.

Share this post


Link to post
Share on other sites

8 hours ago, jcxz said:

Но даже здесь похоже напряжение выбирается из фиксированного профиля "Fixed 28V 5A". И в последовательности запросов/ответов не вижу ничего принципиально отличающегося от аналогичной последовательности при работе моей программы.

Похоже, между пакетами 57 и 523 в этом примере происходил периодический обмен сообщениями.

Возможно, один из простых вариантов - сделать вариант вашей программы сниффером PD и посмотреть, какие идут обмены между БП и "правильным" PD триггером в различных режимах.

Я когда-то хотел разобраться с PD, но изучив документацию и рынок, просто поставил CH224K 🙂

 

Share this post


Link to post
Share on other sites

9 часов назад, Flood сказал:

Похоже, между пакетами 57 и 523 в этом примере происходил периодический обмен сообщениями.

Судя по тому логу, запрошенное напряжение предоставляется источником после пакета 62:

scr001.jpg.8fd2b557230ae44f985e30f814ede96f.jpg

До него (от 57-го до 62-го) - обычная последовательность. Точно такую же я наблюдаю у себя при работе своего ПО. У меня всё заканчивается на моём кадре GoodCRC после принятого кадра PS_RDY.

Как видно - дальше следует какой-то Get_Status от потребителя, на который источник отвечает Not_Supported. А что дальше - не видно. Да и вряд-ли полезно, так как тут похоже запрошен fixed-профиль, а с ним и так всё ок.

9 часов назад, Flood сказал:

Возможно, один из простых вариантов - сделать вариант вашей программы сниффером PD и посмотреть, какие идут обмены между БП и "правильным" PD триггером в различных режимах.

Это уже всё сделано. Но только сделал сниффер обмена своей программы.

А просмотреть чужой обмен просто не на чем: У меня в качестве эталонного потребителя с PowerDelivery последней версии есть только ноут. Но он запрашивает только +20V и отказывается питаться если источник не выдаёт такого напряжения. А в PD-источнике имеется только один PPS-профиль = 3.3...11V + несколько фиксированных профилей. Соответственно запрос ноута попадает на фиксированный профиль и PPS не используется. :sad:

И все примеры обменов, которые я находил где-либо - везде только запросы фиксированных профилей.

Так что правильный обмен по PPS-профилю (или по AVS-профилю) посмотреть негде.  :sad:

Лог обмена моего ПО с PD-источником с запросом напряжения 11.3V из PPS-профиля:

scr002.thumb.png.d35687df95ebb03c0f45780b64e850f6.png

Лог каждого кадра начинается со строки с "-+-+-+-+-+-+..."; заканчивается - "=========...".

"<<<<-+-+-+-+..." - исходящие кадры (от моего ПО).

">>>>-+-+-+-+..." - входящие кадры (от 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.  :sad:

Сам лог выглядит нормальным. Точно таким же, как и для фиксированного профиля (такая же последовательность сообщений; их содержимое конечно иное).

Единственная странность: в GoodCRC-кадре, выдаваемом PD-источником на мой Request-кадр, почему-то указана версия спецификации == 2.0. В то время как во всех других кадрах = 3.0. Но это и в случае с запросом fixed-профиля - то же самое.

 

Вот запрос +15V из fixed-профиля:

scr004.thumb.png.63e7975280436aac84f8d549367035ca.png

Как видно - последовательность сообщений такая же, как с PPS. Но после неё выданные +15V держатся сколь угодно долго, без какой-либо активности по CC-линии.

Share this post


Link to post
Share on other sites

2 hours ago, jcxz said:

Так что правильный обмен по PPS-профилю (или по AVS-профилю) посмотреть негде. 

https://www.witrn.com/?p=1315

Посоветовал бы купить такой брелок, модели C4 или C5. Читает профили с источников и триггерит что угодно. Может вставать в разрыв.

Share this post


Link to post
Share on other sites

13 hours ago, jcxz said:

Лог обмена моего ПО с PD-источником с запросом напряжения 11.3V из PPS-профиля:

scr002.thumb.png.d35687df95ebb03c0f45780b64e850f6.png

Лог каждого кадра начинается со строки с "-+-+-+-+-+-+..."; заканчивается - "=========...".

"<<<<-+-+-+-+..." - исходящие кадры (от моего ПО).

">>>>-+-+-+-+..." - входящие кадры (от 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.  :sad:

Сам лог выглядит нормальным. Точно таким же, как и для фиксированного профиля (такая же последовательность сообщений; их содержимое конечно иное).

Единственная странность: в GoodCRC-кадре, выдаваемом PD-источником на мой Request-кадр, почему-то указана версия спецификации == 2.0. В то время как во всех других кадрах = 3.0. Но это и в случае с запросом fixed-профиля - то же самое.

Отправляйте запросы PPS каждые 10 секунд или меньше в качестве механизма поддержания активности.

Share this post


Link to post
Share on other sites

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.

scr007.thumb.png.6a1ee34734a42e1c1956d992bdeb3e52.png

Забыл написать. Ещё не попробовал. Но всё равно - спасибо. Где-ж вы были раньше?  :smile:

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...