Software-only USB host

mhi

  • *****
  • 500
    • Zobrazit profil
Software-only USB host
« kdy: 24. 07. 2020, 15:37:42 »
Existuje nekolik implementaci ciste SW USB device (nejznamejsi je asi vusb, ale je jich cela rada); tzn. v MCU, ktery nema USB periferii se pomoci 2 GPIO udela softwarove USB zarizeni.

Hodilo by se mi ted opacne reseni, ktere by implementacne nemuselo byt nijak extremne slozite - aby genericky MCU (pocitejme nejaky ARM Cortex-Mx/MIPS na 50+ MHz) umel udelat USB host pro pripojitelny FS device (12Mbps). Cilem je pripojit mass storage, o rychlost tu nejde-spis velikost kodu a nutne periferie hostitelskeho MCU, pocitejme ze pujde pouzit DMA (a nejaky capture/compare, aby byl co nejvetsi offload do HW). Akceptovatelna je i druha alternativa kdy to na chvili plne vytizi MCU a bude to treba i bez interruptu. Znate nekdo nejaky takovy projekt ? Staci mi ta USB komunikace, mass storage se pokusim na to potom nejak naroubovat, pripadne mi staci i nejaka inspirace "jak na to".

Predpokladam, ze to je uplne mimo USB spec, ale je mozne FS zarizeni ktere mi spravne signalizuje pres pullup ze je FS provozovat jako LS, tzn. na 1,5Mbps ? Ze bych mu vnutil LS komunikaci i kdyz je FS ?


Re:Software-only USB host
« Odpověď #1 kdy: 24. 07. 2020, 16:12:30 »
Jenom tak ze zvědavosti: proč bys to dělal, když už je dneska na trhu dostatek čipů s minimálně OTG za rozumnou cenu?

RDa

  • *****
  • 2 465
    • Zobrazit profil
    • E-mail
Re:Software-only USB host
« Odpověď #2 kdy: 24. 07. 2020, 17:13:29 »
Proc to hrotit tak na krev? Osobne bych pouzil SPI-USBhost mustek - MAX3421E

Ale jako cviceni a honeni ega by to bylo zajimavy.. mam tu tlustou a velice podrobnou knizku o USB :-)

S DMA se tady neda pocitat - vzdyt je to bitbang kdyz to chces na GPIO. Leda ze bys ty zapisove waveformy predpocital asynchronne, a nechal to dma tam tlacit pakety a zatim mel prostor na jiny kod, na prijem ale bude potreba busy-loop se zakazanym prerusenim, at je tam zcela presny casovani.

RDa

  • *****
  • 2 465
    • Zobrazit profil
    • E-mail
Re:Software-only USB host
« Odpověď #3 kdy: 24. 07. 2020, 17:35:54 »
Predpokladam, ze to je uplne mimo USB spec, ale je mozne FS zarizeni ktere mi spravne signalizuje pres pullup ze je FS provozovat jako LS, tzn. na 1,5Mbps ? Ze bych mu vnutil LS komunikaci i kdyz je FS ?

Ne, to nejde. Ten pull indikuje jak se na nej ma mluvit. USB je ponekud lepsi "seriovy port" ve sve podstate, tj. kdyz tam posles neco pomaleji, nebo rychleji, tak se nedomluvis. Rychlost se meni jen u HS (480M USB2.0) a to smerem nahoru, zarizeni se identifikuje jako FS (12M) po resetu, aby bylo s nim mozne komunikovat s USB1.1 hostem (ktery umi jenom FS/LS).

mhi

  • *****
  • 500
    • Zobrazit profil
Re:Software-only USB host
« Odpověď #4 kdy: 24. 07. 2020, 18:34:13 »
LS/FS: myslel jsem si to, ale tak treba jsem doufal, ze je nejaky fallback kdyz je po ceste LS HUB, aby na nem slapaly FS zarizeni.

Proc to delat? Potrebuju to v podstate na nejaky vyvoj, a je rozdil jestli na nejakou desku navesim 2 draty USB, nebo resim jiny MCU (kdyz v produktu ma byt neco co nema OTG, to neni o bastleni par kusu kde si muzu koupit doslova co chci). A ten MAX to kompikuje uz uplne extremne-myslim. Nebudu zastirat, ze tam je i vyssi motivace - potrebuju odladit jedno problematicke USB-CDC zarizeni (mam podezreni, ze MCU odesle nejaka data, ktera host nepotvrdi, a vykasle se na retransmit, resp. neco se tam pokoni-nevim co, USB analyzator nemam, tak to asi nasypu do nejakeho FPGA, jakoze poslednich X prenosu).

Mozna jsem naivni a bude to o hodne slozitejsi, ale par sbernic jsem podobnym zpusobem uz implementoval, napr. SAE J1850 (VPW i PWM), navic v pomalem 8bitu :); a tam to byl skutecne masakr. Prvni verze na stole chodila OK, ale pak se objevily ruzne problemy po zapojeni do aut, kdy jsou ruzne nahnile draty, necekane odpory a kapacity vedeni, odpory mezi vodici, ruzne mezni stavy (vynuceny BUS ERR nejakou ridici jednotkou), atd. Ted mne to ceka preimplementovat na ARMa, vubec se na to netesim.

ad DMA: To samozrejme lze pouzit jak na odesilani (pres SPI, GPIO bitbang), i pro prijem, kdy to navesim na capture/compare.


RDa

  • *****
  • 2 465
    • Zobrazit profil
    • E-mail
Re:Software-only USB host
« Odpověď #5 kdy: 24. 07. 2020, 20:01:13 »
LS/FS: myslel jsem si to, ale tak treba jsem doufal, ze je nejaky fallback kdyz je po ceste LS HUB, aby na nem slapaly FS zarizeni.

imho "LS only" hub se podle standardu nepripousti

Proc to delat? Potrebuju to v podstate na nejaky vyvoj, a je rozdil jestli na nejakou desku navesim 2 draty USB, nebo resim jiny MCU (kdyz v produktu ma byt neco co nema OTG, to neni o bastleni par kusu kde si muzu koupit doslova co chci). A ten MAX to kompikuje uz uplne extremne-myslim. Nebudu zastirat, ze tam je i vyssi motivace - potrebuju odladit jedno problematicke USB-CDC zarizeni (mam podezreni, ze MCU odesle nejaka data, ktera host nepotvrdi, a vykasle se na retransmit, resp. neco se tam pokoni-nevim co, USB analyzator nemam, tak to asi nasypu do nejakeho FPGA, jakoze poslednich X prenosu).

Pokud na to nespechas, tak s FS/LS by to slo vytrasovat - mam Cypress FX3 devkit v roli analyzatoru (ale kamarad tvrdi ze tam jsou hlucha okna kdyz to prepina buffery - to jeste musim overit treba rychlym citacem.. ktery nemam) a nad raw streamem (16bit wide) mam udelany sw ktery dekoduje na zaklade triggeru ruzne protokoly (gpio, pwm, i2c, serial, spi) a nad protokoly je jeste povesena abstrakce odposlouchavaneho zarizeni.. takze to dumpuje pak uz i high-level veci.

Jiste by to slo rozsirit do realtime nekonecneho provozu (pac zatim to spis jedu k offline parsovani). Puvodne jsem tim dekodoval inicializaci a provoz Canon snimacu, a posledne jsem to vyuzil k urceni kde selze Avoton C2000.. kdyz to bylo poveseno na spi bios cipu (selze to pri zapisu na port 0x80 - protoze to je prvni LPC transakce, a ma to chciplej LPC clock)... taky to odhalilo mnoho pristupu nez se vubec udela onen resetovaci jump na F000:FFF0 a to, ze ta bios flashka ma partisny ktere maj rizeni pristupu, takze cpu/soc dela hw preklad adres.

To USB FS jsem se tam chystal dopsat, protoze bych rad mel trace k firmware updatu ruznych zarizeni - bez toho aniz bych musel resit OS-specific "usb wireshark" (coz by tobe mozna i stacilo).

mhi

  • *****
  • 500
    • Zobrazit profil
Re:Software-only USB host
« Odpověď #6 kdy: 24. 07. 2020, 23:51:55 »
LS hub: nekde jsem videl prave takovy scenar, bylo to snad dokonce v oficialnich USB doku. Ale mozna se pletu, nevim. Z toho jsem doufal, ze by mohla chodit moje obezlicka, pro nejake MCU staci bohate 1,5mbps a zpracovani by bylo jednodussi.

Nejaky cypressacky USB devkit mam taky, kupoval jsem to prave kvuli necemu takovemu (logovat kvanta dat), ale uz jsem se nedostal k tomu s nim neco udelat.

Problem je v tom, ze to dela OBCAS a ja samozrejme poznam ze se to vysypalo az treba za par vterin. Dela to na nekterych pocitacich, zjisteno jenom pod Windows. Bohuzel test typu budu posilat data sem-tam funguje jak ma, je nutne realne pouziti (tzn. i dalsi periferie, atd.). Samozrejme jsem si ve firmware udelal dump pres rychly seriovy port vseho co prichazi po USB (jen stav controlleru) a tam to vypadalo OK, jen Windows jeden z bloku dat neprijaly.

S ohledem na to, ze tam je MCU od Microchipu a vim jake maji jinde 100% demonstrovane problemy  (jednoducha aplikace, ktera spolehlive selhava ... a oni reknou ze to je "vlastnost" a nedaji to ani do errata), nedivil bych se, kdyby byla nejaka bota v tom USBcku, treba nejaka kolize s dalsi periferii, nebo tak neco.

mhi

  • *****
  • 500
    • Zobrazit profil
Re:Software-only USB host
« Odpověď #7 kdy: 26. 07. 2020, 19:01:30 »
Chvili jsem ted koukal na to USBcko a FS device (12Mbps) neni az zase takova sranda. Resp. nejak to asi pujde dat dohromady za predpokladu, ze prijem dat budu nejprve sypat do nejakeho bufferu casy zmen signalu a dekodovat az ex post, protoze to nestiham (dalo se cekat...).

Jako neznalek si kladu otazku jake pakety pouziva mass storage device, hlavne jak jsou ty nejdelsi pakety dlouhe. Tusite nekdo? Podle me je to 64*8 bitu + 8+8 (SYNC,PID) + 16 (CKS) + 3b, do toho muze prijit az cca 90 bitstuffovych bitu...

A pak je samozrejme otazka co se stane kdyz nestihnu poslat nejaky paket dostatecne rychle vcas, protoze si nemyslim, ze dekodovat to budu umet az zase  tak rychle.

Myslenka je tedy zatim takova:

timing_buf bude obsahovat casy segmentu (format bude rozdilny pro odesilani a prijem, u odesilani asi muzu jit po bytech, ale u prijmu budu nejspis zapisovat najednou 4 bity)

Odesilani bude probihat nejspis tak, ze se do timging_buf napocitaji prechody J-K stavu, ktere se pak pomoci jednoducheho cyklu odeslou.

Prijem bude fungovat tak, ze si budu zapisovat do timing_buf  jednotlive casy zmen JK (otazkou je, zda vubec budu stihat dekodovat dif. D+/D- signal!) do doby nez zaplnim buffer, nebo timer prekroci hodnotu 6*83,3ns.; nasledovat by melo prekodovani do stavu (J-K) a dekodovani.

zlepseni ze bych misto casu jen ukladal nejakou bitovou delku+stav (J,K,SE0,error) asi nepujde, protoze i kdybych predpocital tabulku prevadejici cas na pocet zakladnich jednotek, ten pametovy pristup mi to prilis zpomali...

RDa

  • *****
  • 2 465
    • Zobrazit profil
    • E-mail
Re:Software-only USB host
« Odpověď #8 kdy: 26. 07. 2020, 20:33:24 »
Implementace by mela byt takovato:

TX buffer kde bude predpocitany SOF, a pak vlozeny aktivni pakety. Odpali se to kazdou 1ms ven skrze GPIO DMA (nebo instrukcne presny busy loop), pro pozadovanou delku ktera se meni zda probiha aktivita ci nikoliv.. pro cokoliv si vystacis s implementaci 1 paketu s 64B payloadem + prislusne headry. Sw loop ma vyhodu ze si naskladas JK do 1/2 bitu, namisto zrejme bajtoveho pristupu ktery sezere 4-8x vice pameti. Tohle resi control+out pakety.

RX buffer kde se nasampluje response z IN paketu - at uz pres timer/dma, nebo znova v sw-loopu, se stejnym problemem co se tyce spotreby pameti jako u TX, ale aktivovat to postaci jen kdyz se pozaduje odezva.

To SOF musis posilat kazdou milisekundu, takze je to jedina casove kriticka/narocna cast (jinak ti po 3-7ms zaspi periferie). Protoze u USB je to host, kdo ridi deni na zbernici, takze si to osefujes jak je libo - klidne muzes dekodovat odezvu post-capture, jak dlouho chces.. jen na pozadi musis delat ty periodicke SOFy.

Pozor na to, ze u prevodu datoveho streamu na fyzicky JK stream nastava doplnovani o nejake dummy bity - takze ty buffery musi byt o neco delsi.

PS: Ukladat casy zmen ti nicemu nepomuzou a je to neefektivni - pac kodovani ma alespon tolik hran jako bitu - takze se spis snaz samplovat spravne (nebo oversamplovat). SW implementace by ti mela zabrat 64B (512bitu) + overhead rekneme 100% .. takze 1000 UI ... coz pri 1ms=12000 UI znamena zatez cpu jenom na 1/12 casu, pokud pujdes cestou 100% exkluzivity pro implementaci USB.
« Poslední změna: 26. 07. 2020, 20:37:48 od RDa »

mhi

  • *****
  • 500
    • Zobrazit profil
Re:Software-only USB host
« Odpověď #9 kdy: 26. 07. 2020, 23:56:04 »
No moment, vzdyt je to NRZI s bitstuffingem, takze to neni az tak jednoduche. Vezmu-li STM32 s nejakym Cortex-M3(-M4) na 72MHz, tak mam na jednu J/K transition zjednodusene 6 taktu a v tom urcite nespocitam aktivni cas po ktery ma bezet u TX dany stav (J,K), ani u RX nezjistim kolik jakych bitu mam prihodit do bitstreamu, natoz abych to tam prihodil a ulozil. Vse v meznich pripadech, ale ty jsou jedine podstatne. Neprisel jsem na to jak to udelat jinak, takze ten megabuffer na casy, ktery sezere hromadu pameti (tech neco okolo 637 bitu + rekneme 520 B jako buffer pro dekodovany paket).

Technicka otazka, mel jsem takovou predstavu, ze bych to neresil skrze interrupty, ale ciste SW s tim, ze po timeoutu (1ms) by se USB zarizeni znovu probouzelo. Nejsem si jist, zda je takovy pristup mozny/prakticky.

RDa

  • *****
  • 2 465
    • Zobrazit profil
    • E-mail
Re:Software-only USB host
« Odpověď #10 kdy: 27. 07. 2020, 00:19:58 »
Tak je pravda ze je to tak akurat na vybaveni neceho z pameti a poslani na port. Mozna v sw by to slo resit stylem predpocitanych translaci celych bajtu (jen ten stuffing na hranici bajtu znamena 5 ruznejch tabulek). Lze neco jako dvojurovnovy lookup udelat v DMA? nebo to umi pipelinovat bloky, ze zatimco se jeden posila, druhej se zaradi do fronty?

Pokud prestanes posilat SOFy, tak to znamena po 3ms "suspend"... reverzovat tento stav lze udalosti "resume", ktera je ale 20ms dlouha.. takze tohle ti podstatne zpomali jakoukoliv aktivitu - a taky muze resetovat ty casti ktere jsi chtel ladit.

Re:Software-only USB host
« Odpověď #11 kdy: 27. 07. 2020, 10:33:41 »
Rozhodně jde o ambiciózní projekt. Jen se obávám, že plán přidat do stávajícího designu levně základní USB by skončil sice s omezeně fungujícím USB, ale MCU už by nestíhalo řešit původní úkoly.