قرارداد توان، نقشها، دستگاههای PD و ارتباط SOP*
در دومین مقاله این مجموعه، فصل دوم مشخصات USB Power Delivery Revision 3.2, Version 1.1 را بررسی میکنیم: تفاوت Default Contract، Implicit Contract و Explicit Contract، جایگاه مستقل نقشهای توان، داده و VCONN، ساختار دستگاههای سازگار با PD و نحوه آدرسدهی Port Partnerها و Cable Plugها با SOP، SOP’ و SOP’’.
دامنه این مقاله
محتوای این مقاله فقط از فصل ۲، بخشهای 2.1 تا 2.5 و صفحات ۵۳ تا ۶۵ سند استخراج شده است. این فصل یک نمای عملیاتی سطحبالا ارائه میکند؛ بنابراین نام Messageها، Stateها و Timerها در حدی توضیح داده میشوند که خود فصل دوم برای شناخت روند Source، Sink و Cable Plug بیان کرده است. جزئیات بیتها، قالب Packet، ماشین حالت و قواعد دقیق توان به مقالههای بعدی واگذار میشوند.
از اتصال فیزیکی تا یک توافق عملیاتی
فصل دوم نشان میدهد که اتصال کابل فقط آغاز کار است؛ سطح و جهت توان باید در قالب یک Contract مشخص شود.
USB Power Delivery سازوکاری برای جفت Portهایی است که مستقیماً به یکدیگر متصل شدهاند. این دو Port که Port Partner یا Port Pair نیز نامیده میشوند، از طریق PD درباره ولتاژ، جریان و در صورت پشتیبانی درباره جهت جریان توان مذاکره میکنند. ارتباط PD روی سیم CC کانکتور USB Type-C انجام میشود و سازوکار آن مستقل از روشهای توان تعریفشده در USB 2.0، USB 3.2، USB Battery Charging 1.2 و USB Type-C است. وقتی مذاکره PD شکل میگیرد، قرارداد آن بر روشهای پیشین تأمین توان اولویت پیدا میکند.
این استقلال به معنای کنارگذاشتن USB نیست. دستگاهها در لحظه اتصال از USB Default Operation آغاز میکنند و PD روی همان زیرساخت USB Type-C، امکان توافق دقیقتر را اضافه میکند. در نتیجه یک اتصال میتواند ابتدا با vSafe5V و جریان اعلامشده توسط Rp شروع شود و سپس پس از شناسایی قابلیتهای طرفین، به سطح توان دیگری منتقل شود. جهت توان، نقش داده و مسئولیت تأمین VCONN نیز الزاماً یک رابطه ثابت و همیشگی ندارند.
کاربرد PD به توان محدود نیست. Structured Vendor Defined Messageها برای کشف ویژگیهای Port و کابل، شناسایی SVIDها و Modeها و ورود یا خروج از برخی Modeها به کار میروند. نمونههایی که فصل دوم نام میبرد شامل USB4 Mode، Alternate Mode استاندارد مانند DisplayPort و Mode اختصاصی مانند Thunderbolt 3 است. بنابراین همان کانال CC هم برای ایجاد Contract توان و هم برای مدیریت برخی قابلیتهای جانبی استفاده میشود.
سه وضعیت Contract برای Source
فصل دوم وضعیت عملیاتی Source را در یکی از سه Contract قرار میدهد. تفاوت آنها فقط مقدار توان نیست؛ زمان ایجاد، مدت اعتبار و رویدادی که باعث خروج از هر وضعیت میشود نیز متفاوت است.
بلافاصله پس از Connect شکل میگیرد. Source ولتاژ ۵ ولت را ارائه میکند و مقدار جریان قابلتحویل را با مقدار Rp مطابق USB Type-C اعلام مینماید. این وضعیت تا جداشدن Sink یا مذاکره موفق برای ورود به Explicit Contract ادامه دارد.
بلافاصله پس از Power Role Swap یا Fast Role Swap ایجاد میشود و ماهیتی گذرا دارد. Source جدید ۵ ولت و جریان اعلامشده با Rp را فراهم میکند، اما Port Pair باید فوراً برای ایجاد یک Explicit Contract مذاکره کند.
نتیجه مذاکره رسمی PD است. Source قابلیتها را میفرستد، Sink یک قابلیت را درخواست میکند، Source درخواست معتبر را میپذیرد و پس از آمادهشدن منبع تغذیه با PS_RDY پایان انتقال را اعلام میکند. این حالت وضعیت عادی کار در PD است.
Explicit Contract دقیقاً چگونه ایجاد میشود؟
مذاکره با ارسال Message قابلیتهای Source آغاز میشود. این پیام مجموعهای از گزینههای توان قابلارائه را در اختیار Sink میگذارد. Sink موظف است یکی از قابلیتهای موجود را انتخاب و با Request Message درخواست کند. Source درخواست را بررسی میکند؛ اگر معتبر باشد، Accept میفرستد و سپس زمانی که منبع تغذیه برای سطح توافقشده آماده شد، PS_RDY را ارسال میکند. رسیدن این توالی به PS_RDY یعنی Source و Sink وارد Explicit Contract شدهاند.
Contract ایجادشده هم سطح توان موجود و هم جهت انتقال توان را تعیین میکند. مذاکره PD هر قرارداد پیشین حاصل از USB 2.0، USB 3.2، USB BC 1.2 یا USB Type-C را کنار میزند. Port Pair تا زمانی در Power Delivery Mode باقی میماند که Detach، Hard Reset، USB Type-C Error Recovery یا قطع توان از سوی Source رخ ندهد؛ قطع توان مرتبط با Power Role Swap یا Fast Role Swap از این قاعده جداست، زیرا بخشی از فرایند کنترلشده تعویض نقش محسوب میشود.
Explicit Contract هنگام مذاکره مجدد از بین نمیرود. Source میتواند قابلیتهای جدیدی اعلام کند یا Sink درخواست خود را تغییر دهد و Contract در جریان این Re-negotiation همچنان صریح باقی میماند. خروج واقعی از آن هنگام قطع اتصال، Hard Reset، تعویض نقش توان یا Error Recovery رخ میدهد. پس از قطع و اتصال دوباره، Source از Default Contract شروع میکند؛ پس از Power Role Swap یا Fast Role Swap نیز از Implicit Contract بهسرعت به سمت Explicit Contract تازه میرود.
پیش از نخستین Explicit Contract
DFP توان vSafe5V را فراهم میکند و UFP مطابق قواعد USB پایه جریان میکشد. پیش از نخستین Contract صریح، فقط Source که در این مرحله VCONN Source نیز هست میتواند با کابل متصل ارتباط برقرار کند. این کشف برای تشخیص قابلیت ۵ آمپر، پشتیبانی EPR و مشخصاتی مانند سرعت کابل اهمیت دارد.
پس از برقراری Explicit Contract
امکان مذاکره در ولتاژهای بالاتر یا پایینتر و جریانهای بیشتر فراهم میشود. Portها میتوانند نقش توان، نقش داده یا VCONN Source را تعویض کنند، وارد EPR یا USB4 Mode و Alternate Mode شوند و Vendor Defined Message مبادله کنند؛ البته هر قابلیت تنها در صورت پشتیبانی طرفین قابل اجراست.
Local Policy و System Policy در تخصیص توان
هر Provider یک Local Policy دارد که مشخص میکند توان موجود چگونه میان Portهای آن تخصیص یابد. Consumer نیز Local Policy خود را برای نحوه دریافت و مصرف توان اجرا میکند. بنابراین قابلیت الکتریکی منبع تنها عامل تصمیمگیری نیست؛ سیاست داخلی دستگاه تعیین میکند چه گزینههایی در یک لحظه ارائه یا درخواست شوند.
فصل دوم همچنین امکان اعمال System Policy روی USB را مطرح میکند. این سیاست سطح سیستم میتواند Local Policy را تغییر دهد و تخصیص کلی توان را مدیریت کند. چنین تفکیکی به ما یادآوری میکند که Contract نتیجه گفتوگوی دو Port است، اما تصمیمهای پشت آن ممکن است به وضعیت کل دستگاه، ذخیره انرژی یا سیاست چند Port وابسته باشند.
سازگاری Revision 3.x با USB PD 2.0
Revisionهای 3.x برای همکاری کامل با سامانههای PD 2.0 که از BMC Signaling روی کانکتور USB Type-C استفاده میکنند طراحی شدهاند و با سختافزار Revision 2.0 سازگارند. هر سامانه Revision 3.x باید کارکرد Revision 2.0 را بهطور کامل پشتیبانی کند، Revision موردپشتیبانی Port Partner و Cable Plugهای متصل را کشف کند و بر اساس پایینترین Revision مشترک عمل نماید.
Extended Messageها میتوانند تا ۲۶۰ بایت داده حمل کنند؛ اندازهای که ممکن است از انتظار سختافزار PHY قدیمی بزرگتر باشد. برای حفظ سازگاری، Chunking اجباری است تا پیامها در محدوده اندازه Revision 2.0 باقی بمانند، مگر آنکه کشف شود هر دو سامانه از طول بزرگتر پشتیبانی میکنند. این سازوکار مانع میشود قابلیت جدید، همکاری با نسل پیشین را مختل کند.
قالب برخی Vendor Data Objectها برای کشف کابلهای علامتگذاریشده Passive یا Active و Alternate Mode Adapterها نیز تغییر کرده است. SVDM Version به 2.x افزایش یافته و خود VDOها هم شماره Version دارند تا گیرنده بتواند قالب مورد استفاده را تشخیص دهد و زمینه برای تغییرات آینده فراهم بماند.
یک دستگاه PD از چه اجزایی ساخته میشود؟
فصل دوم USB Host، USB Device، Hub و Charger را بهعنوان نمونه نشان میدهد، اما این شکل محدودیتی برای طراحی محصولات ایجاد نمیکند. فرض پایه این است که هر دستگاه سازگار با USB PD دستکم یک Port دارد.
UFP
UFP توان را بهعنوان Sink دریافت و با SOP Packet ارتباط برقرار میکند. ارتباط SOP’ و SOP’’، تأمین توان در قالب Dual-Role Power، ارتباط USB و پشتیبانی Alternate Mode برای آن اختیاری است.
DFP
DFP توان را بهعنوان Source ارائه و با SOP Packet ارتباط برقرار میکند. پشتیبانی SOP* برای ارتباط با Cable Plug، دریافت توان در قالب Dual-Role Power، ارتباط USB و Alternate Mode برای آن اختیاری است.
Source، Sink و VCONN Source را جدا ببینیم
| نقش | وظیفه اصلی | نمونههای بیانشده در فصل |
|---|---|---|
| Source | ارائه توان به اتصال PD | منبع دارای تغذیه خارجی، ذخیره انرژی مانند باتری یا پاوربانک، یا توانی که از Port دیگری گرفته شده است؛ مانند Hub با تغذیه باس |
| Sink | دریافت و مصرف توان اتصال PD | شارژ ذخیره انرژی، تغذیه عملکرد داخلی دستگاه یا تأمین دستگاههای متصل به Portهای دیگر |
| VCONN Source | تأمین VCONN و مدیریت ارتباط با Cable Plug | تغذیه Cable Plugها و VCONN Powered Deviceها؛ تنها Port مجاز برای گفتوگو با Cable Plugها در هر لحظه |
SOP*؛ آدرسدهی روی یک سیم مشترک
Start of Packet یا SOP فقط علامت شروع Packet نیست؛ در فصل دوم بهعنوان روش آدرسدهی معرفی میشود. گیرنده از نوع SOP تشخیص میدهد پیام برای یکی از Port Partnerهاست یا برای یک موجودیت ارتباطی داخل کابل. SOP، SOP’ و SOP’’ در مجموع SOP* نامیده میشوند و همه این ارتباطها از همان سیم CC عبور میکنند.
اصطلاح Cable Plug در بحث SOP’ و SOP’’ یک موجودیت منطقی دارای توانایی ارتباط PD را نشان میدهد. این موجودیت ممکن است از نظر فیزیکی داخل خود Plug قرار گرفته باشد یا جای دیگری از کابل باشد. استاندارد SOPهای دیگری نیز برای کاربردهای ویژه مانند Debug دارد، اما فصل دوم آنها را وارد این نمای عملیاتی نمیکند.
جلوگیری از تداخل ارتباطی SOP*
چون همه SOP* Communicationها روی یک سیم CC انجام میشوند، Source هماهنگی ارتباط را بر عهده دارد تا دو فرستنده همزمان باس را اشغال نکنند. پس از ایجاد Explicit Contract، Source با تغییر مقدار Rp به Sink اعلام میکند چه زمانی اجازه آغاز یک Atomic Message Sequence را دارد.
هنگامی که Source نیاز فوری به ارسال ندارد، Rp برابر حالت 3A را بهعنوان اجازه آغاز AMS توسط Sink نشان میدهد. اگر خود Source بخواهد AMS را شروع کند، Rp را به حالت 1.5A تغییر میدهد و منتظر میماند ارتباط SOP* در حال اجرای Sink کامل شود. مستقل از اینکه آغازکننده کدام Port است، ارسالکننده باید پیش از قراردادن Message روی CC از Idle بودن کانال اطمینان حاصل کند.
SOP Communication میان Source و Sink نسبت به ارتباط با Cable Plugها اولویت دارد، زیرا عملیات مرتبط با توان باید در سریعترین زمان ممکن کامل شوند. اگر SOP در جریان SOP’ یا SOP’’ ظاهر شود، ارتباط کابل میتواند قطع شود. این قطعشدن برای ارتباط Cable Plug به Soft Reset یا Hard Reset منتهی نمیشود؛ Cable Plug ممکن است Timeout شود و خودش Retry نکند.
چه کسی اجازه دارد با Cable Plug صحبت کند؟
SOP Packet برای ارتباط Source و Sink است. هر دو Port Partner آن را میشناسند، اما Cable Plugهای میان آنها نباید آن را بهعنوان پیام خود تلقی کنند. SOP’ توسط الکترونیک یکی از Cable Plugها شناخته میشود و SOP’’ در صورتی قابل پشتیبانی است که SOP’ نیز پشتیبانی شود. انتساب SOP’ و SOP’’ در کابل ثابت است و بهصورت پویا جابهجا نمیشود.
در Default Contract یا Implicit Contract فقط Source Portی که VCONN را تأمین میکند اجازه دارد SOP’ Packet را برای Cable Plug ارسال کند و به Packet آن با GoodCRC پاسخ دهد. هدف این فاز کشف ویژگیهای کابل است. Sink با Cable Plug ارتباط برقرار نمیکند و SOP’های دریافتی را Discard میکند. کنترل متمرکز ارتباط توسط VCONN Source مانع برخورد SOP با SOP’ میشود.
پس از ایجاد Explicit Contract نیز فقط VCONN Source، خواه DFP باشد یا UFP، میتواند با SOP’ یا SOP’’ با Cable Plugها ارتباط داشته باشد. Port دیگر مجاز به این ارتباط نیست و Packetهای کابل را تشخیص نمیدهد. محدودیت دیگری نیز وجود دارد: فقط DFP هنگامی که VCONN Source است اجازه دارد با SOP* ورود و خروج Modeها و Modal Operation در کابل را کنترل کند.
چیدمان نقشها در لحظه Attach
در هر اتصال PD میان Port Partnerها فقط یک Source و یک Sink وجود دارد. در لحظه Attach، Portی که Rp را Assert کرده Source است و همزمان نقش DFP و VCONN Source را دارد. Portی که Rd را Assert کرده Sink است، UFP محسوب میشود و VCONN Source نیست. این آرایش نقطه شروع است، نه یک قفل دائمی؛ سه خانواده نقش میتوانند بعداً مستقل از یکدیگر Swap شوند.
سه Swap مستقل، سه نتیجه متفاوت
Power Role Swap / Fast Role Swap
Source و Sink جای خود را عوض میکنند. Port جدید Source ابتدا وارد Implicit Contract میشود و باید بلافاصله برای Explicit Contract تازه مذاکره کند. نقش داده و VCONN الزاماً تغییر نمیکنند.
Data Role Swap
DFP و UFP جابهجا میشوند. اگر قابلیت ارتباط USB وجود داشته باشد، Host و Device نیز مطابق نقش جدید تغییر میکنند. Source/Sink و VCONN Source ثابت میمانند.
VCONN Swap
مسئولیت تأمین VCONN میان دو Port منتقل میشود. هر دو سمت در گذار برای مدتی VCONN را اعمال میکنند تا انتقال بهصورت make-before-break انجام شود. نقش توان و داده بدون تغییر میمانند.
Portی که هر دو نقش Source و Sink را پشتیبانی میکند Dual-Role Power Port یا DRP نام دارد. Port دارای هر دو نقش DFP و UFP نیز Dual-Role Data Port یا DRD است. پشتیبانی DFP همراه قابلیت USB امکان Host بودن را فراهم میکند و پشتیبانی UFP همراه قابلیت USB امکان Device بودن را میدهد.
چرا نخستین Explicit Contract همیشه SPR است؟
محدوده کلاسیک USB PD تا ۱۰۰ وات Standard Power Range یا SPR نامیده میشود. نخستین Explicit Contract پس از Default Contract یا Implicit Contract همیشه یک SPR Contract است. حتی اگر Source، Sink و کابل همگی EPR را پشتیبانی کنند، اتصال مستقیماً از حالت پیشفرض به توان EPR نمیرود.
Extended Power Range یک Mode اختیاری با امکان تحویل توان تا ۲۴۰ وات است. ورود به آن فقط از SPR Mode انجام میشود و فرایند ورود برای جلوگیری از فعالشدن تصادفی توان بالاتر طراحی شده است. وجود SPR Explicit Contract و پشتیبانی EPR توسط Source Port، Sink Port و کابل، هر سه شرط ورود هستند.
نمای عملیاتی Source از Attach تا Ready
Source-only Port اتصال Sink را تشخیص میدهد. DRP نیز اگر هنگام Toggle به Sink متصل شود، در این اتصال Source میشود. سپس Source ولتاژ vSafe5V را روی VBUS قرار میدهد.
پیش از Source_Capabilities، منبع میتواند قابلیت کابل را بررسی کند. ظرفیت پیشفرض کابل USB Type-C برابر ۳ آمپر است؛ اگر Cable Plug پاسخ دهد، Source با SOP’ ویژگیهایی مانند پشتیبانی ۵ آمپر را کشف میکند. سپس قابلیتهای خود را بهصورت دورهای در فاصله tTypeCSendSourceCap اعلام میکند.
Source حضور Port Partner سازگار با PD را از دریافت GoodCRC در پاسخ به Source_Capabilities یا دریافت Hard Reset Signaling تشخیص میدهد. GoodCRC نشان میدهد طرف مقابل Message را در لایه ارتباطی دریافت کرده است.
Sink یک Request میفرستد. Source برای درخواست معتبر Accept ارسال میکند و پس از آمادهشدن منبع تغذیه در سطح توافقشده PS_RDY را میفرستد. از این نقطه، Source وارد PE_SRC_Ready و اتصال وارد Explicit Contract شده است.
Source در Explicit Contract چه وظایفی دارد؟
Source در PE_SRC_Ready تمام Messageهای دریافتی را پردازش میکند و در صورت نیاز پاسخ میدهد. هر زمان Local Policy ایجاب کند Message مناسب میفرستد. اگر قابلیتهای آن تغییر کنند، Source_Capabilities جدید ارسال میشود. اگر Sink در Request بیت Capabilities Mismatch را تنظیم کرده باشد، Source باید قابلیتهای خود را با بیشینه توان موجود دوباره اعلام کند.
Source همیشه روی CC مورد استفاده برای Collision Avoidance مقدار Rp دارد. اگر DRP باشد میتواند Power Role Swap را آغاز یا دریافت کند؛ اگر DRD باشد Data Role Swap را مدیریت میکند؛ و در VCONN Swap میتواند نقش تأمینکننده VCONN را منتقل یا دریافت کند. این عملیات همان اصل استقلال نقشها را در اجرا نشان میدهد.
هنگامی که Source هم VCONN Source است، در زمان آزادبودن SOP Communication میتواند با SOP’ یا SOP’’ با Cable Plug ارتباط برقرار کند. دریافت SOP در حین این گفتوگو ارتباط کابل را فوراً پایان میدهد. اگر Source برای تغییر قابلیتها به SOP نیاز داشته باشد، ارتباط SOP’ یا SOP’’ جاری را قطع میکند. زمانی که Source هم DFP است، میتواند ورود و خروج Modeهای کابل و Sink را کنترل و Structured یا Unstructured VDM ارسال کند.
نمای عملیاتی Sink از Attach تا Ready
Sink اتصال Source را از حضور vSafe5V تشخیص میدهد. اگر Port یک DRP باشد، هنگام اتصال به Source در نقش Sink قرار میگیرد. پس از مشاهده vSafe5V روی VBUS منتظر Source_Capabilities میماند تا حضور Source سازگار با PD مشخص شود. اگر این Message تا پایان tTypeCSinkWaitCap نرسد، Sink میتواند Hard Reset Signaling ارسال کند تا Source سازگار با PD را وادار به ارسال قابلیتهایش کند.
با دریافت Source_Capabilities، Sink یک GoodCRC میفرستد و سپس برای ایجاد نخستین Explicit Contract، یکی از قابلیتهای اعلامشده را با Request انتخاب میکند. حتی گزینه vSafe5V مطابق استانداردهای پایه نیز میتواند موضوع Request باشد؛ این کار امکان مذاکرههای آینده را حفظ میکند. درخواست نکردن هیچ قابلیت معتبر خطاست.
اگر هیچ قابلیت ارائهشده برای عملکرد کامل Sink کافی نباشد، Sink باید یکی از قابلیتهای معتبر موجود را درخواست کند، بیت Capability Mismatch را تنظیم نماید و یک نشانه فیزیکی از وضعیت نامطلوب به کاربر ارائه دهد؛ مثال فصل دوم استفاده از LED است. Mismatch به معنای ارسال درخواست خارج از فهرست Source نیست، بلکه اعلام میکند گزینه پذیرفتهشده نیاز کامل Sink را تأمین نمیکند.
پس از Accept و PS_RDY، Sink وارد PE_SNK_Ready میشود. تغییر نیاز توان با Request جدید اعلام میشود. Sink در SPR PPS Mode باید حتی بدون تغییر درخواست، در بازه tPPSRequest پیام Request دورهای ارسال کند. در EPR Mode نیز باید در بازه tSourceEPRKeepAlive با EPR_KeepAlive یا Message دیگری با Source ارتباط داشته باشد. Sink همواره Rd را روی سیم CC خود Assert نگه میدارد.
Detach، Soft Reset و Hard Reset در نمای عملیاتی
Detach
Source با تشخیص جداشدن Plug، VBUS را در محدودههای زمانی تعریفشده به vSafe5V و سپس vSafe0V میرساند. Sink حذف VBUS یا نبود Rp را پایان اتصال میداند، مگر افت توان بخشی از Hard Reset یا تعویض نقش توان باشد.
Soft Reset
خطای Protocol میتواند با Soft_Reset از سوی هر Port رسیدگی شود. شمارندهها، Timerها و Stateهای ارتباطی Reset میشوند، اما ولتاژ و جریان مذاکرهشده، نقشهای Port و Modal Operation تغییر نمیکنند.
Hard Reset
خطای جدی با Hard Reset رسیدگی میشود. Protocol Reset و توان به USB Default Operation برمیگردد، نقش داده به وضعیت پیشفرض بازمیگردد، VCONN Source دوباره Source Port میشود و Active Modeها پایان مییابند.
شکست در دریافت GoodCRC در محدوده tReceive ابتدا میتواند به Soft Reset منتهی شود و اگر این فرایند کامل نشود، Hard Reset برای بازگرداندن VBUS به USB Default Operation صادر میشود. خطا در انتقال توان نیز بهطور خودکار Hard Reset را در پی دارد تا سطح توان به حالت پیشفرض بازگردد و Sink محافظت شود.
در SPR PPS، اگر ارتباط دورهای Sink برقرار نشود، Source Hard Reset میدهد و VBUS به vSafe5V بازمیگردد. در EPR نیز نرسیدن EPR_KeepAlive یا Message دیگر در مهلت تعیینشده همین نتیجه را دارد. این الزام نشان میدهد حفظ توان برنامهپذیر یا محدوده توسعهیافته به ارتباط زنده و دورهای وابسته است.
رفتار Cable Plug با رفتار Port Partner یکسان نیست
Cable Plug هنگام حضور VCONN تغذیه میشود، اما از وضعیت Contract میان دو Portی که کابل به آنها وصل است آگاه نیست. Cable Plug آغازکننده AMS نیست و فقط به Messageهایی پاسخ میدهد که برای آن ارسال شدهاند. در نتیجه نقش آن در ارتباط واکنشی است، نه مدیریتکننده Contract.
ارتباط Cable Plug میتواند هر لحظه قطع شود و میان DFP/UFP و Cable Plug طرح Timeout ارتباطی مستقلی وجود ندارد. Cable Plug باید آماده پاسخگویی به درخواستهایی باشد که ممکن است تکرار شوند. خودش توان ایجاد Hard Reset Signaling را ندارد، اما Hard Reset میان Source و Sink را تشخیص میدهد و باید خود را Reset کند. Power Cycle شدن VBUS و VCONN در این فرایند معمولاً همان Reset موردنیاز را ایجاد میکند.
Cable Reset Signaling نیز مستقیماً به Cable Plug اعلام میکند که باید رفتاری معادل Power Cycle و Reset را انجام دهد. این سازوکار با Hard Reset کلی Port Pair تفاوت دارد، هرچند هر دو میتوانند وضعیت ارتباطی کابل را از نو آغاز کنند.
چگونه یک لاگ PD را با منطق این فصل بخوانیم؟
نخست باید تشخیص دهیم اتصال در Default، Implicit یا Explicit Contract است. مشاهده vSafe5V و Rp بهتنهایی اثبات Explicit Contract نیست. توالی Source_Capabilities، Request، Accept و PS_RDY مرز روشن ورود به Contract صریح را نشان میدهد.
سپس نقشها باید جداگانه ثبت شوند: کدام Port Source است، کدام DFP است و کدام VCONN را تأمین میکند. فرض اینکه Source همیشه Host یا DFP باقی میماند پس از Swapها میتواند تحلیل را اشتباه کند. نوع SOP نیز مشخص میکند Message برای Port Partner است یا Cable Plug.
در نهایت باید Context خطا بررسی شود. Soft Reset الزاماً سطح توان را تغییر نمیدهد، اما Hard Reset Contract و Modal Operation را به وضعیت پایه بازمیگرداند. قطع ارتباط SOP’ در برابر SOP با اولویت بالاتر نیز لزوماً خطای جدی نیست؛ قواعد فصل دوم اجازه میدهند ارتباط Cable Plug برای تکمیل عملیات مهم Port-to-Port قطع شود.
جمعبندی
Source پس از اتصال در Default Contract قرار میگیرد؛ Implicit Contract فقط پس از تعویض نقش توان و بهصورت گذرا شکل میگیرد؛ و Explicit Contract با توالی Source_Capabilities، Request، Accept و PS_RDY ایجاد میشود. Contract صریح وضعیت عادی کار PD است و بر قراردادهای توان USB پایه اولویت دارد.
Source/Sink، DFP/UFP و VCONN Source سه مجموعه نقش مستقل هستند. در Attach، Source هم DFP و VCONN Source است و Sink هم UFP، اما Power Role Swap، Data Role Swap و VCONN Swap میتوانند هر محور را بدون اجبار به تغییر دو محور دیگر جابهجا کنند.
SOP برای ارتباط Port-to-Port، SOP’ و SOP’’ برای ارتباط با Cable Plugها و SOP* نام جمعی آنهاست. همه روی CC مشترکاند؛ Source Collision Avoidance را هماهنگ میکند، SOP اولویت بالاتر دارد و فقط VCONN Source مجاز به گفتوگو با Cable Plugهاست.
Source، Sink و Cable Plug در Attach، Ready، Detach و خطا رفتارهای متفاوتی دارند. Soft Reset ارتباط را بدون تغییر Contract توان و نقشها بازنشانی میکند؛ Hard Reset توان، نقش پیشفرض داده، VCONN Source و Active Modeها را به وضعیت پایه بازمیگرداند.
مقاله ۳: معماری USB PD، عملکرد EPR، مدلهای شارژ و الزامات الکتریکی پایه
در مقاله بعدی، Sections 2.6 تا 4.4 را بررسی میکنیم: معماری لایهای USB PD، رابطه Device Policy Manager، Policy Engine، Protocol و PHY، نمای عملیاتی EPR، مدلهای شارژ و قواعد الکتریکی پایهای که ارتباط روی CC و انتقال توان روی VBUS را شکل میدهند.