Re: Napití USB-C

Petr Labaj labaj na volny.cz
Sobota Červenec 30 17:55:39 CEST 2022


Velice děkuji za dobrý popis ąpatného stavu.
Hned si ho jdu uloľit do archívu.

Jeątě jednou díky.

PL

***********************

Dne 30.7.2022 v 17:44 Jan Waclawek napsal(a):
> Ja som posledny kto by to chcel obhajovat, ale pokusim sa vysvetlit z
> historickeho pohladu.
>
> Zacnime tym, ze historia USB je historiou nie najlepsie napisanych
> standardov, ktore boli takmer vzdy obratom ignorovane.
>
> Povodny model bol, ze napaja sa zhora nadol (od hostov k device,
> predpokladam znalost hierarchie v USB vratane nomenklatury ktora je podla
> horeuvedenej zasady zle definovana a rozsiahlo ignorovana) kazde
> zariadenie berie pocas enumeracie 100mA, pravdivo oznami svoju ocakavanu
> maximalnu spotrebu, z coho host urobi patricne vypocty (zahrnujuc
> vlastnosti hubov v ceste) a zariadeniu podla toho moze odmietnut
> enumeraciu, taketo zariadenie nesmie prejst do rezimu s vyssou spotrebou.
> Ak host chce, moze cast stromu dat do stavu suspend, ked ma byt spotreba
> vsetkych device v ceste drasticky obmedzena (nemam chut hladat, presne
> ako). Huby maju vediet detekovat nadprud a selektivne za/vypinat porty
> (self-powered by mali, bus-powered musia), a mali by to indikovat
> predpisanym indikacnym svetlom (a nie, modra tam nie je). Z tohoto
> vsetkeho su vypocitane pozadovane vlastnosti prepajacich kablov.
>
> Na toto vsetko - a to doslova vsetko - sa takmer hned od zaciatku rozsiahlo
> kaslalo najma pod heslom "ono to funguje". Dokazom je, ze kazdy z nas sa s
> tym stretol a mnohi z nas toto "kaslanie" v nejakej podobe bezne vyuzivaju.
>
> Oficialne stanovisko USB specifikacie vzdy bolo, ze ak zariadenie potrebuje
> viac stavy nez kolko mu je pridelene, ma sa o to postarat nejako same
> (t.j. ma mat vlastny zdroj). A kupodivu pomerne rychlo sa objavilo aj
> dokonale korektne riesenie problemu, ze niektore zariadenia (napr. externy
> disk, alebo tlaciaren) maju notoricky vacsiu spotrebu, pritom vsak nie je
> prilis velka a je vhodne pre ne nemat dalsi kabel a extra zdroj. Bohuzial,
> to riesenie https://en.wikipedia.org/wiki/PoweredUSB (v podobe
> "rozsireneho" konektora) bolo obmedzene patentom IBM a do oficialneho USB
> sa nedostalo - ostatni clenovia konzorcia sa bud s IBM nevedeli dohodnut,
> alebo v tom case este nevideli dovod na riesenie napajania, napokon, bezne
> na USB existovali vtedy len mysi, klavesnice a zvukovky.
>
> Potom prisla potreba mensich konektorov. miniB bolo fajn, ale bohuzial sa
> presadil mechanicky aj elektricky mizerny mikroB.
>
> Potom prislo OTG, tlacene najma zo strany vyrobcov fotoaparatov a
> tlaciarni, ktori su notoricky znami tym, ze sa snazia veci robit co
> najsvojskejsie a podla moznosti klast vsetkym ostatnym prekazky.
> Kazdopadne to prinieslo sadu dalsich konektorov (AB komba), potrebu
> jedneho identifikacneho signalu naviac (tu je pociatok toho ze "moze sa ku
> klasickym 4 signalom pridat dalsi"), sadu kablov ktore nikto nevie rozozna
> a nikto poriadne nepouziva, a sadu pravidiel, ktore kazdy podla dobrej
> tradicie veselo porusuje. Ale prinieslo to aj dalsi problem, a to ako
> rozhodnut, ze kto je napajaci a kto napajany. Pretoze s OTG sa bura
> klasicka hierarcha host-device, kedze sa roly mozu podla potreby otocit, a
> rola v napajacej hierarichii uz nemusi prirodzene zodpovedat roli v
> "datovej" hierarchii. Vysledkom su protokoly ADP/SRP/HNP definovane v OTG
> dodatku k USB2.0, pomocou ktorych si OTG par dohaduje tieto roly
> signalizaciou jednak na VBUS (tj. +) vodici a druhak na D+ vodici pocas
> nadvazovania spojenia.
>
> Uz toto bolo dost nechutne.
>
> Potom prisla era mobilov a tabletov a s nimi nabijacky. Cielom bolo
> pretlacit viac nez oficialnych 500mA (ktore napokon oficialne vyzadovali
> enumeraciu, ale na toto uz v tomto okamihu bolo univerzalne zabudnute). To
> prinieslo doslova zaplavu pomerne improvizovanych rieseni vo forme rozne
> zapojenych odporov roznych hodnot medzi D+ a D-, co potom vyustilo v
> oficialnu tzv. Battery Charging specifikaciu, ktora znova bola vselijako
> porusovana. Pred par rokmi som sa snazil nieco v tejto oblasti riesit,
> ostali mi mimoriadne traumaticke spomienky a mam kdesi odlozene tabulky a
> nakresy atd. a najma pocit odporu k celej tejto oblasti.
>
> Potom prislo Super Speed (co si mnohi mylia s USB3.x, rovnako ako FS si
> mylia s USB 2.x) a s nim dalsia hromada divnych konektorov a kablov (a
> mimochodom, v relativnej tichosti zdvihnuty "defaultny" prudovy limit na
> 900mA - no ano, SS prislo najma kvoli diskom).
>
> V tomto okamihu uz tych signalov bolo dost vela, a ten SS mikro B konektor
> je fakt dost nanic, takze pomerne pochopitelne sa prebral navrh od Apple
> (hoci Apple charakteristicky okamzite zacalo robit veci po svojom, ako
> vzdy) urobit konektor pre tu cast obyvatelstva ktori dusevne nezvladaju
> princip "logom hore" prip. "ak to tam nejde vsunut tak otoc" nedajboze "ak
> sa pozries tak je vidiet ktora strana je uzsia". S tym prisla aj potreba
> detekovat, ako je ten konektor otoceny, a ked su tam uz kvoli tomu dva
> piny (ktore mimochodom aj detekuju, o ktory z asi osemtisic variant kabla
> ide, co vyrobcovia kablov z dalekeho vychodu samozrejme tiez veselo
> ignoruju), tak preco ich nevyuzit na komunikaciu na temu napajania.
> Napokon, uz si chceme vypytat aj nieco viac nez 5V a to nie je dobre
> nechat na nieco ako odporovo-kondenzatorovy delic.
>
> Na druhej strane, ta komunikacia je o nieco jednoduchsia ako samotne USB.
> ST predtym, ako prisli s radom 'G0 ktory ma Power Delivery zabudovany,
> malo nejake riesenie (v podobe rozsirenia k nejakemu Nucleo) ktore myslim
> ze bolo pasivne a cela komunikacia sa riesila v nejakom 'F0 softwarom.
>
> Nie som v tejto oblasti expert a urcite som aj na vela veci zabudol.
>
> wek
>
>
> ----- Original Message ---------------
>
> Subject: Re: Napití USB-C
>     From: Petr Labaj <labaj na volny.cz>
>     Date: Sat, 30 Jul 2022 16:29:46 +0200
>       To: hw-list na list.hw.cz
>
> Děkuji pěkně za informace. I kdyµ nepříjemné.
> Roz±lapal jste mi bábovičky. :-(
>
> Já si dlouhodobě myslím (podle vněj±ích projevů, bez znalosti podrobností),
> µe v napájení po USB-C  je pěkný bordel.
> Zatím jsem si myslel, µe je to třeba jen přechodný stav, něco jako poporodní
> bolesti, a časem se do toho zavede pořádek.
> Ale pokud je na to třeba jiné piny (proč?) a specializované chipy
> (proč?), tak
> je moje skepse je±tě hlub±í.
>
> Jinde počet vodičů sniµují na nezbytné minimum (např. Xbase-T1, kde po
> 2 drátech po±lu duplexní data i napájení), a tady se kvůli nějakému datovému
> dohadování zavedou dráty navíc.
>
> Prostě mizernej den. Furt chčije a rajčata děsně praskají. A napájení přes
> USB-C je je±tě hor±í, neµ jsme doufali.
>
> PL
>
> **********************
>
> Dne 30.7.2022 v 16:14 Jan Waclawek napsal(a):
>>> To vyjednávání o napětí a proudu běµí zřejmě na nějakých vy±±ích
>>> vrstvách USB, ne?
>> Nie. Je to tzv. Power Delivery (USBC-PD) protokol, ktory bezi na inych
>> vodicoch nez USB. Je to po vsetkych strankach uplne iny protokol nez USB,
>> spolocny maju len ten vonkajsi obal kabla.
>>
>>> Tak bych skoro čekal, µe se na tohle téma objeví nějaké open-source
>>> projekty pro nějaká ta lep±í "Arduina", co mají nativní USB (třeba
>>> Blue-pill nebo Arduino Due).
>> Nejake open-source implementacie su. Ale cely ten protokol je nechutne
>> zlozity. Vlastne, zle som to povedal - on nie je ani nejako zvlast
>> zlozity, ale je nechutne rozsiahly, s nechutne roztahanou dokumentaciou.
>>
>> Z toho potom vyplyva existencia jednoucelovych cipov, ktore implementuju PD
>> a napr. na zaklade nejakeho nastavenia ich pinov nutia pripojeny zdroj do
>> nejakeho konkretneho napatia. Dost sa to charakterom podoba napr. na
>> USB-COM prevodniky.
>>
>>> Ten zdroj zřejmě má nějakou tabulku parametrů, co zvládne, a tu by mohl
>>> umět reportovat.
>> Tak ja neviem. Je ta slovencina naozaj taka nezrozumitelna?
>> https://list.hw.cz/pipermail/hw-list/2022-July/553117.html
>>
>> wek
>



Další informace o konferenci Hw-list