پیامهای کنترلی USB PD؛ از GoodCRC و Accept تا Swap، Reset و Status
در مقاله هشتم، تمام پیامهای Control در لایه Protocol را بررسی میکنیم؛ پیامهایی که بدون Data Object ارسال میشوند اما تأیید دریافت، پذیرش یا رد درخواست، اعلام آمادگی منبع تغذیه، جابهجایی نقشها، بازیابی ارتباط و درخواست اطلاعات را مدیریت میکنند.
دامنه این مقاله
محتوای این مقاله فقط بر Section 6.3 و صفحات ۱۲۸ تا ۱۳۷ سند USB Power Delivery Specification, Revision 3.2, Version 1.1, 2024-10 استوار است. ساختار Data Messageها، PDO، APDO و Capabilities از Section 6.4 آغاز میشود و برای مقاله ۹ محفوظ مانده است.
پیام کوتاه، نقش بزرگ در کنترل ارتباط
Control Message داده کاربردی حمل نمیکند، اما ترتیب و نتیجه بسیاری از فرایندهای USB PD را تعیین میکند.
در مقاله ۷ دیدیم که مقدار فیلد Number of Data Objects یا NDO نوع کلی پیام را مشخص میکند. اگر NDO صفر باشد، پیام از نوع Control است. چنین پیامی در سطح Protocol فقط Message Header دارد و Data Object پس از آن قرار نمیگیرد. CRC همچنان در Packet وجود دارد، اما مانند سایر Packetها توسط لایه فیزیکی افزوده و بررسی میشود.
نبود Payload به معنی کماهمیتبودن پیام نیست. دریافتکننده با GoodCRC صحت دریافت را اعلام میکند؛ Accept، Reject و Wait نتیجه یک درخواست را مشخص میکنند؛ PS_RDY رسیدن منبع تغذیه به وضعیت خواستهشده را خبر میدهد؛ پیامهای Swap نقشها را جابهجا میکنند و Soft_Reset یا Data_Reset برای بازگرداندن ارتباط به وضعیت سالم بهکار میروند.
نوع دقیق Control Message از بیتهای ۴ تا ۰ Message Header خوانده میشود. جدول 6.5 علاوه بر کد پیام، مشخص میکند کدام موجودیت اجازه ارسال آن را دارد و پیام باید در SOP معمولی یا خانواده SOP* قرار گیرد. بنابراین Decode صحیح تنها با خواندن Message Type کامل نمیشود؛ NDO، نوع SOP، نقش فرستنده و Revision نیز باید همزمان بررسی شوند.
بدون Data Object
Control Message در Protocol Layer فقط Message Header شانزدهبیتی دارد.
کد نوع پیام
پنج بیت پایین Header نام و معنای Control Message را تعیین میکنند.
مقصد معتبر
بعضی پیامها فقط میان دو Port و بعضی برای Cable Plug نیز معتبرند.
نقشه کامل Control Messageها در Table 6.5
استاندارد برای هر کد پنجبیتی، نام پیام، فرستنده مجاز و Start of Packet معتبر را تعیین میکند. مقادیر تعریفنشده Reserved هستند و نباید استفاده شوند. دو کد GotoMin و Ping نیز در نسخه جاری Deprecated شدهاند و نباید مانند پیام فعال تفسیر شوند.
نگاشت کدهای پنجبیتی Control Message به نام پیام، فرستنده مجاز و نوع SOP معتبر.
| Bits 4..0 | Message Type | فرستنده مجاز | Start of Packet | کارکرد کوتاه |
|---|---|---|---|---|
| 0_0001 | GoodCRC | Source، Sink یا Cable Plug | SOP* | تأیید دریافت صحیح پیام |
| 0_0010 | GotoMin (Deprecated) | منسوخ | نامعتبر | کد فعال نیست |
| 0_0011 | Accept | Source، Sink یا Cable Plug | SOP* | پذیرش درخواست یا آغاز فرایند |
| 0_0100 | Reject | Source، Sink یا Cable Plug | SOP* | رد درخواست پشتیبانیشده |
| 0_0101 | Ping (Deprecated) | منسوخ | SOP only | کد فعال نیست |
| 0_0110 | PS_RDY | Source یا Sink | SOP only | آمادگی وضعیت توان |
| 0_0111 | Get_Source_Cap | Sink یا DRP | SOP only | درخواست Source Capabilities |
| 0_1000 | Get_Sink_Cap | Source یا DRP | SOP only | درخواست Sink Capabilities |
| 0_1001 | DR_Swap | Source یا Sink | SOP only | جابهجایی Data Role |
| 0_1010 | PR_Swap | Source یا Sink | SOP only | جابهجایی Power Role |
| 0_1011 | VCONN_Swap | Source یا Sink | SOP only | جابهجایی VCONN Source |
| 0_1100 | Wait | Source یا Sink | SOP only | عدم آمادگی موقت |
| 0_1101 | Soft_Reset | Source یا Sink | SOP* | همگامسازی مجدد Protocol |
| 0_1110 | Data_Reset | Source یا Sink | SOP only | بازنشانی اتصال USB و Modeها |
| 0_1111 | Data_Reset_Complete | Source یا Sink | SOP only | پایان Data Reset |
| 1_0000 | Not_Supported | Source، Sink یا Cable Plug | SOP* | پیام یا قابلیت پشتیبانی نمیشود |
| 1_0001 | Get_Source_Cap_Extended | Sink یا DRP | SOP only | درخواست اطلاعات تکمیلی Source |
| 1_0010 | Get_Status | Source یا Sink | SOP* | درخواست وضعیت جاری |
| 1_0011 | FR_Swap | Sink | SOP only | آغاز Fast Role Swap AMS |
| 1_0100 | Get_PPS_Status | Sink | SOP only | درخواست وضعیت PPS منبع |
| 1_0101 | Get_Country_Codes | Source یا Sink | SOP only | درخواست کدهای کشور پشتیبانیشده |
| 1_0110 | Get_Sink_Cap_Extended | Source یا DRP | SOP only | درخواست اطلاعات تکمیلی Sink |
| 1_0111 | Get_Source_Info | Sink یا DRP | SOP only | درخواست نوع و توانایی فعلی Source |
| 1_1000 | Get_Revision | Source یا Sink | SOP* | درخواست Revision و Version |
Accept دقیقاً در چه سناریوهایی معتبر است؟
- Source در SPR با Accept اعلام میکند توانایی برآوردهکردن Request را دارد.
- Source در EPR با Accept آمادگی برای برآوردهکردن EPR_Request را اعلام میکند.
- گیرنده PR_Swap، DR_Swap یا VCONN_Swap با Accept آغاز AMS مربوط را میپذیرد.
- گیرنده FR_Swap اعلام میکند Fast Role Swap AMS را آغاز کرده است.
- گیرنده Soft_Reset با Accept پایان Soft Reset خود را اعلام میکند.
- گیرنده Enter_USB یا Data_Reset با Accept آغاز فرایند درخواستی را تأیید میکند.
در همه این موارد Accept باید در محدوده tReceiverResponse پس از آخرین بیت پیام ورودی ارسال شود؛ بنابراین تأخیر خارج از این پنجره را نباید پذیرش معتبر تلقی کرد.
پس از Reject چه محدودیتی ایجاد میشود؟
فرستنده Request، EPR_Request، PR_Swap، DR_Swap، VCONN_Swap یا Enter_USB پس از دریافت Reject نباید همان پیام را بدون تغییر شرایط دوباره ارسال کند. برای Request توان، یک New Explicit Contract Negotiation میتواند با Source_Capabilities جدید، Get_Source_Cap، EPR_Get_Source_Cap، Power Role Swap، Soft Reset، Hard Reset یا Disconnect/Re-connect آغاز شود. Data Role Swap یا Data Reset نیز از رویدادهایی هستند که شرایط را تغییر میدهند.
Sink میتواند RDO متفاوتی بفرستد، اما تکرار همان RDO ردشده بدون یکی از رویدادهای بالا مجاز نیست. این قاعده از حلقهای جلوگیری میکند که در آن درخواست غیرقابلقبول بدون هیچ تغییر واقعی بارها تکرار شود.
Wait برای هر درخواست چگونه تفسیر میشود؟
Request / EPR_Request: Source اکنون توان لازم را ندارد، اما ممکن است با مذاکره با Sinkهای دیگر یا Source بالادستی آن را بازیابی کند. Sink باید تا tSinkRequest صبر کند.
PR_Swap: گیرنده برای ارزیابی بیشتر زمان میخواهد. تلاش بعدی نباید پیش از tPRSwapWait انجام شود.
DR_Swap: تغییر Data Role شاید بعداً ممکن شود. ارسال مجدد باید پس از tDRSwapWait باشد.
VCONN_Swap: تلاش بعدی باید پس از tVCONNSwapWait انجام شود. اگر Revision طرف مقابل قدیمیتر از R3.2 V1.1 باشد، Portی که اکنون VCONN Source است باید Accept بفرستد، زیرا طرف قدیمی انتظار Wait ندارد و ممکن است Soft Reset ایجاد کند.
Enter_USB: UFP ممکن است برای ورود به USB Mode به توان بیشتری نیاز داشته باشد. پس از تکمیل مذاکره توان، DFP میتواند بعد از tEnterUSBWait درخواست را دوباره بفرستد.
GoodCRC؛ تأیید دریافت، نه پاسخ به محتوا
دریافتکننده پس از دریافت صحیح پیام باید GoodCRC را ارسال کند و همان MessageID پیام قبلی را در Header بازگرداند. فرستنده از این تطبیق میفهمد دقیقاً همان پیام موردنظر تأیید شده است. اولین بیت GoodCRC باید در محدوده زمانی tTransmit پس از آخرین بیت پیام دریافتشده بازگردد.
GoodCRC تنها صحت دریافت Packet را تأیید میکند و بهمعنای پذیرش معنای پیام نیست. برای نمونه، دریافت صحیح PR_Swap ابتدا با GoodCRC تأیید میشود، اما نتیجه درخواست بعداً با Accept، Wait یا Reject مشخص خواهد شد. این تفکیک برای Analyzer مهم است؛ GoodCRC موفق نباید بهعنوان موفقیت کامل AMS گزارش شود.
اگر فرستنده پیش از پایان CRCReceiveTimer پیام GoodCRC معتبر دریافت نکند، Retry فعال میشود. استاندارد تأکید میکند Retry فقط برای تشخیص خرابی انتقال ناشی از نویز یا اختلال CC است و نباید بهعنوان راهی برای خریدن زمان پردازش پاسخ استفاده شود. در Continuous BIST Mode نیز GoodCRC ارسال نمیشود.
قاعده عملی برای خواندن Capture
Message → GoodCRC یعنی انتقال سالم بوده است؛ Message → Accept یعنی درخواست پذیرفته شده؛ این دو رویداد از نظر Protocol یکسان نیستند.
Accept، Reject، Wait و Not_Supported؛ چهار نتیجه متفاوت
این چهار پیام ظاهراً کوتاهاند، اما معنای آنها باید دقیق از هم جدا شود. Accept اعلام میکند گیرنده درخواست را پذیرفته و فرایند مربوطه را آغاز کرده است. Reject یعنی درخواست شناختهشده است اما گیرنده نمیتواند یا نمیخواهد آن را انجام دهد. Wait یعنی انجام درخواست ممکن است، ولی در وضعیت فعلی آماده نیست. Not_Supported نیز میگوید خود پیام یا قابلیت پشتیبانی نمیشود.
Accept
در SPR برای پذیرش Request، در EPR برای پذیرش EPR_Request و در پاسخ به PR_Swap، DR_Swap، VCONN_Swap، FR_Swap، Soft_Reset، Enter_USB و Data_Reset کاربرد دارد. Accept باید در tReceiverResponse ارسال شود.
Reject
برای درخواست معتبر ولی غیرقابلاجرا استفاده میشود. پس از Reject، تکرار همان Request یا Swap با همان شرایط محدود است و معمولاً باید رویدادی مانند مذاکره قرارداد جدید، Swap، Reset یا اتصال مجدد رخ دهد.
Wait
عدم آمادگی موقت را اعلام میکند. درخواستکننده پس از Timer مرتبط مانند tSinkRequest، tPRSwapWait، tDRSwapWait، tVCONNSwapWait یا tEnterUSBWait میتواند دوباره تلاش کند.
Not_Supported
در پاسخ به پیامی ارسال میشود که Port یا Cable Plug از آن پشتیبانی نمیکند. Not_Supported جای Reject را نمیگیرد؛ Reject برای درخواست پشتیبانیشده ولی ردشده است.
| پاسخ | معنا | آیا تلاش دوباره ممکن است؟ |
|---|---|---|
| Accept | درخواست پذیرفته و فرایند آغاز شده است | نیازی به تکرار همان درخواست نیست |
| Reject | درخواست معتبر است اما اجرا نمیشود | فقط پس از تغییر شرایط تعریفشده |
| Wait | در حال حاضر امکان اجرا وجود ندارد | بله، پس از Timer مربوط |
| Not_Supported | پیام یا قابلیت پشتیبانی نمیشود | تکرار همان پیام مشکل را حل نمیکند |
توالی Data Reset در پنج مرحله
- ۱.DFP اتصالهای داده را متوقف میکند: D+/D- قطع میشود، در USB 3.2 ترمینیشنهای Rx برداشته میشوند و در USB4 خط SBTX به سطح پایین میرود.
- ۲.هر دو Port از تمام Alternate Modeهای فعال خارج میشوند.
- ۳.کابل با UFP VCONN Power Cycle یا DFP VCONN Power Cycle بازنشانی میشود؛ DFP باید در پایان VCONN Source باشد.
- ۴.پس از tDataReset، DFP مسیرهای USB 2.0 را دوباره متصل و در صورت کار با USB 3.2 یا USB4 ترمینیشنهای Rx را دوباره اعمال میکند.
- ۵.DFP پیام Data_Reset_Complete را میفرستد و فرایند USB4 Discovery and Entry را آغاز میکند.
در طول این فرایند هیچیک از دو طرف نباید تا قبل از Data_Reset_Complete، VCONN Swap جدیدی آغاز کند. اگر Initiator در tSenderResponse پاسخ معتبر نگیرد، وارد ErrorRecovery میشود.
GotoMin و Ping؛ کدهایی که دیگر فعال نیستند
GotoMin با کد 0_0010 Deprecated است؛ این Message Type دیگر معتبر نیست و دریافت آن باید با Not_Supported پاسخ داده شود. Ping با کد 0_0101 نیز Deprecated شده است. Port میتواند Ping را نادیده بگیرد یا Not_Supported بفرستد، اما Cable Plug باید آن را نادیده بگیرد.
Decoder حرفهای بهتر است این کدها را با برچسب Deprecated نمایش دهد، نه Reserved و نه پیام فعال. این کار میان «کدی که قبلاً تعریف شده» و «مقداری که هرگز نباید استفاده شود» تفاوت روشنی ایجاد میکند.
PS_RDY و درخواست قابلیتهای پایه
PS_RDY اعلام میکند منبع تغذیه به شرایط عملیاتی خواستهشده رسیده است. در مذاکره عادی Source آن را ارسال میکند؛ در Power Role Swap یا Fast Role Swap ممکن است هر دو نقش جدید در نقاط لازم از فرایند PS_RDY بفرستند. بنابراین PS_RDY صرفاً «روشن بودن شارژر» نیست، بلکه یک نقطه همگامسازی در انتقال توان است.
Get_Source_Cap از Port Partner میخواهد Source_Capabilities و قابلیت Dual-Role Power خود را اعلام کند. پاسخ آن Source_Capabilities Data Message است. در جهت مقابل، Get_Sink_Cap برای دریافت Sink_Capabilities و وضعیت Dual-Role Power استفاده میشود. این دو Control Message فقط درخواست هستند؛ اطلاعات واقعی در Data Message پاسخ قرار میگیرد.
PS_RDY
شرایط توان خواستهشده آماده است.
Get_Source_Cap
درخواست فهرست قابلیتهای Source.
Get_Sink_Cap
درخواست فهرست قابلیتهای Sink.
چهار پیام Swap؛ کدام نقش واقعاً تغییر میکند؟
USB PD نقش توان، نقش داده و منبع VCONN را مستقل نگه میدارد. به همین دلیل DR_Swap، PR_Swap و VCONN_Swap پیامهای جداگانهاند. FR_Swap نیز برای شرایط اضطراری از دست رفتن توان خارجی طراحی شده و با PR_Swap عادی یکسان نیست.
| پیام | آنچه تغییر میکند | آنچه ثابت میماند | پاسخ اصلی |
|---|---|---|---|
| DR_Swap | DFP و UFP | جهت توان VBUS، VCONN Source و Rp/Rd | Accept / Wait / Reject |
| PR_Swap | Source و Sink، همراه تغییر Rp/Rd | Data Role و VCONN Source | Accept / Wait / Reject |
| VCONN_Swap | VCONN Source | DFP/UFP، منبع VBUS و Rp/Rd | Accept / Wait / Reject / Not_Supported |
| FR_Swap | Power Role در فرایند سریع | Data Role و VCONN Source | Accept |
DR_Swap
DFP و UFP را میان دو Port Partner جابهجا میکند، درحالیکه جهت توان VBUS تغییر نمیکند. اگر Active Mode میان Portها برقرار باشد، دریافت DR_Swap به Hard Reset منجر میشود. همچنین DFP پیش از پذیرش یا آغاز Swap باید Active Modeهای Cable Plug را مدیریت و در صورت نیاز خارج کند.
PR_Swap
Source و Sink را جابهجا میکند و به همین دلیل Rp و Rd نیز متناسب با نقش جدید تغییر میکنند. PR_Swap در EPR Mode مجاز نیست و ابتدا باید از EPR خارج شد. پس از Swap موفق، Protocol Layer دو طرف مانند Soft Reset بازنشانی میشود تا MessageIDCounter، RetryCounter و State Machineها برای First Explicit Contract آماده شوند.
VCONN_Swap
تأمین VCONN را جابهجا میکند و باید بهصورت make-before-break انجام شود تا Cable Plug بدون توان نماند. Portی که میخواهد با کابل ارتباط برقرار کند باید ابتدا مطمئن شود VCONN Source است. Source جدید پس از روشنکردن VCONN با PS_RDY آمادگی خود را اعلام میکند.
FR_Swap
پس از تشخیص سیگنال Fast Role Swap، New Source باید در tFRSwapInit پیام FR_Swap را بفرستد و طرف مقابل با Accept پاسخ دهد. سپس مقاومتهای CC به وضعیت درست نقشهای جدید تغییر میکنند و Protocol Layerها بازنشانی میشوند. این فرایند راهکار best effort برای از دست رفتن منبع توان خارجی است و ممکن است وسط AMS رخ دهد.
Soft_Reset، Data_Reset و Data_Reset_Complete
Soft_Reset برای بازیابی خطای Protocol و بازگرداندن شمارندههای Message به وضعیت شناختهشده استفاده میشود. جهت توان، ولتاژ، جریان و Modal Operation را تغییر نمیدهد، اما پس از تکمیل آن مذاکره Explicit Contract دوباره انجام میشود. اگر Soft Reset نتواند خطا را اصلاح کند، Hard Reset باید آغاز شود.
مقصد Soft_Reset به SOP وابسته است. SOP فقط Port Partner را Reset میکند؛ SOP' یا SOP'' همان Cable Plug هدف را Reset میکند. پس از VCONN Swap نیز VCONN Source برای همگامکردن MessageID کابل باید Soft_Reset مناسب را به Cable Plug بفرستد.
Data_Reset هدف دیگری دارد: اتصال USB و تمام Alternate Modeها را Reset میکند، اما Power Contract و Data Role را نگه میدارد. USB4 capable Portها باید آن را پشتیبانی کنند. گیرنده با Accept پاسخ میدهد، مسیرهای داده و Modeها Reset میشوند، کابل Power Cycle میشود و در پایان DFP پیام Data_Reset_Complete را برای UFP میفرستد.
| پیام | دامنه Reset | Power Contract | Data Role | نتیجه |
|---|---|---|---|---|
| Soft_Reset | Protocol Layer و شمارندهها | توان لحظهای تغییر نمیکند؛ قرارداد دوباره مذاکره میشود | بدون تغییر | بازگشت همگامسازی پیام |
| Data_Reset | USB data، Alternate Mode و کابل | حفظ میشود | حفظ میشود | بازسازی اتصال داده |
| Data_Reset_Complete | اعلام پایان فرایند | بدون تغییر | بدون تغییر | DFP پایان Reset را به UFP اعلام میکند |
سه سطح اعتبار کد در Decoder
Defined: کد در Table 6.5 تعریف شده است، اما هنوز باید نقش فرستنده و SOP معتبر بررسی شود. برای مثال Get_PPS_Status پیام تعریفشدهای است ولی فقط Sink آن را در SOP معمولی میفرستد.
Deprecated: GotoMin و Ping سابقه تعریف دارند، اما در Revision جاری پیام فعال نیستند. Decoder باید نام تاریخی و وضعیت Deprecated را همزمان نمایش دهد.
Reserved: مقدار 0_0000 و بازه 1_1001 تا 1_1111 تعریف نشدهاند و نباید استفاده شوند. مشاهده چنین کدی میتواند نشانه Packet خراب، Decode اشتباه بیتها یا رفتار ناسازگار فرستنده باشد.
خانواده Get؛ Control Message درخواست میکند، پیام دیگر پاسخ میدهد
پیامهای Get معمولاً دادهای در خود ندارند. آنها نوع اطلاعات موردنیاز را اعلام میکنند و Port Partner یا Active Cable با Data Message یا Extended Message مرتبط پاسخ میدهد. در Decoder باید درخواست و پاسخ متناظر بهعنوان یک جفت منطقی نمایش داده شوند.
| Control Message | اطلاعات درخواستی | پاسخ مورد انتظار | مقصد |
|---|---|---|---|
| Get_Source_Cap_Extended | اطلاعات تکمیلی قابلیتهای Source | Source_Capabilities_Extended | Port Partner |
| Get_Status | وضعیت جاری Port یا Active Cable | Status | SOP / SOP' / SOP'' |
| Get_PPS_Status | اطلاعات وضعیت PPS Source | PPS_Status | Source |
| Get_Country_Codes | کدهای alpha-2 پشتیبانیشده | Country_Codes | Port Partner |
| Get_Sink_Cap_Extended | اطلاعات تکمیلی قابلیتهای Sink | Sink_Capabilities_Extended | Port Partner |
| Get_Source_Info | نوع، حداکثر قابلیت و قابلیت فعلی Source | Source_Info | Source |
| Get_Revision | Revision و Version پشتیبانیشده | Revision | Port Partner / Cable Plug |
Get_Status after Alert
دریافت Alert نشان میدهد وضعیت Source یا Sink تغییر کرده است؛ Port باید وضعیت تازه را با Get_Status دوباره بخواند. خود Alert تمام جزئیات وضعیت را جایگزین نمیکند.
روش Decode یک Control Message در Analyzer
- ۱.ابتدا صحت Packet، CRC و مرز SOP* را در PHY بررسی کنید.
- ۲.در Message Header مطمئن شوید Extended صفر و NDO برابر صفر است.
- ۳.بیتهای ۴ تا ۰ را با Table 6.5 تطبیق دهید و Reserved یا Deprecated بودن کد را مشخص کنید.
- ۴.بررسی کنید فرستنده از نظر Source، Sink، DRP یا Cable Plug مجاز به صدور این پیام بوده است.
- ۵.SOP مورد استفاده را با ستون Valid Start of Packet مقایسه کنید.
- ۶.پیام را در توالی AMS تحلیل کنید: GoodCRC، پاسخ محتوایی، Timer و پیام بعدی را جدا نشان دهید.
نمونه ۱: درخواست توان پذیرفتهشده
Request → GoodCRC → Accept → GoodCRC → PS_RDY
GoodCRC دریافت را تأیید میکند، Accept پذیرش را نشان میدهد و PS_RDY رسیدن توان به وضعیت جدید را اعلام میکند.
نمونه ۲: Swap موقتاً ممکن نیست
DR_Swap → GoodCRC → Wait
Packet سالم بوده، اما Data Role در همان لحظه تغییر نمیکند. درخواست بعدی باید پس از tDRSwapWait باشد.
نمونه ۳: پیام ناشناخته برای گیرنده
Message → GoodCRC → Not_Supported
دریافت فیزیکی درست انجام شده، اما قابلیت یا پیام در گیرنده پشتیبانی نمیشود.
خطاهای رایج در تفسیر Control Message
- GoodCRC را با Accept اشتباه نگیرید؛ اولی دریافت صحیح و دومی پذیرش درخواست را اعلام میکند.
- Reject و Not_Supported یک معنا ندارند؛ Reject برای درخواست شناختهشده اما ردشده است.
- Wait را شکست قطعی در نظر نگیرید؛ امکان تلاش دوباره پس از Timer مربوط وجود دارد.
- PR_Swap را در EPR Mode معتبر ندانید؛ ابتدا خروج از EPR لازم است.
- Soft_Reset را با Data_Reset یا Hard Reset یکی نکنید؛ دامنه و اثر هرکدام متفاوت است.
- کدهای GotoMin و Ping را پیام فعال گزارش نکنید؛ هر دو Deprecated هستند.
- Get Message را پاسخ اطلاعاتی تصور نکنید؛ داده واقعی در Message پاسخ حمل میشود.
جمعبندی مقاله هشتم
Control Message با NDO صفر شناخته میشود و در Protocol Layer هیچ Data Object ندارد.
پنج بیت Message Type، نام پیام را تعیین میکنند؛ فرستنده مجاز و SOP معتبر نیز باید کنترل شود.
GoodCRC انتقال سالم را تأیید میکند، درحالیکه Accept، Reject، Wait و Not_Supported نتیجه منطقی درخواست را مشخص میکنند.
DR_Swap، PR_Swap، VCONN_Swap و FR_Swap چهار نقش و سناریوی متفاوت را مدیریت میکنند.
Soft_Reset برای همگامسازی Protocol است؛ Data_Reset اتصال USB و Alternate Modeها را بازسازی میکند.
خانواده Get فقط درخواست اطلاعات میفرستد و پاسخ واقعی در Data یا Extended Message متناظر قرار میگیرد.
در مقاله بعدی
مقاله ۹ وارد Section 6.4.1 میشود و پیامهای Capabilities، ساختار Power Data Object و تفاوت PDOهای Fixed، Battery، Variable، SPR PPS APDO و EPR AVS APDO را بررسی میکند.
منبع
USB Power Delivery Specification, Revision 3.2, Version 1.1