PIC USB och nödvändigheten med Vbus signalering till MCU?

[Birger1234]

Nån som kan detta?

MCHP säger att det är en nödvändighet med Vbus detektering på dsPIC33/PIC24 med intern USB SIE, men inte varför.!!

Däremot finns inte denna insignal på PIC18 utan endast D+/D-,dessutom finns det en uppsjö
av USB till paralell/SPI/I2C enchips lösningar för att inte tala om en drös med USB hubb chips
som inte detekterar Vbus.

Vbus detektering går till interna komparatorer som sätter en flagga i ett register som talar
om för MCU att Vbus är tillgänglig, har förstått att Vbus bara är en nödvändighet för att
vara 2.0 compliant Host/OTG mnode men inte som simpel DEVICE. Närvaro av device brukar
av vad jag förstått detekteras via pullup, pulldown på D+/D-.

PIC's appnotes pratar om möjligheten att stänga av Vbus om applikationens MCU
switchar mellan Host/OTG och Device mode vilket indikerar att MCHP inte säger hela
sanningen.

[Micke_s]

Tror den behöver vusb för följa USB standarden

[Birger1234]

Och ändå har MCHP MCU's utan Vbus detekt.

[Micke_s]

Tror att det har med att du vill köra CPU coren i annan spänning(lägre) än vad usb spec tillåter. T.ex. Texas Msp430 driver usb phy med vusb och matspänningen till MCUn kan då vara lägre, ända ner till 1.8 volt.

[Birger1234]

Nja, på PIC 24 finns det en separat SIE matning 3.3V men dessutom då Vbus och som
redan nämnts, den genererar inget utan bara detekterar tillvaron av en Vbus från Host
eller Hub.

I manualen finns en liten fin text not som säger att Vbus funktionen är inaktiv
när PIC24 används som Device, så varför säger MCHP då att den måste finnas?!?
Drog iväg en support ticket och fick lika menlöst svar där....

En Host t.ex PC kan stänga av Vbus (USB 2.0?)och då ska man enligt manual inte koppla
på en Device (enligt MCHP) utan vänta tills Vbus slås på och detta likadant när PIC24
agerar som Host/OTG.

[Kaggen]

Gäller inte detta i första hand enheter (devices) med egen matning (alltså egen strömkälla)? Detta för att veta om enheten är kopplad till en USB host eller ej.

Tyckte jag såg något sådant beskrivet på nätet när jag kollade lite på USB, kan ha fel dock.

[Birger1234]

Citat:
Närvaro av Device till host brukar av vad jag förstått detekteras via pullup, pulldown på D+/D-.
Vet inte till 100%. Kan detta Vbus detekt vara en USB 1.0 vs 2.0 sak?

[mooo]

VBUS detect är viktigt på en slav enhet (device) som har egen matning.

Orsaken är att devicen talar om för hosten att den finns och är redo att användas genom att koppla en pullup till D+ (High speed) eller D- (Low speed).
Och en av reglerna säger att pullupen får inte aktiveras om inte VBUS är hög!

För att lösa det enklast har man oftast en direktkoppling som gör att pulluppen kopplas bort om VBUS försvinner.

I äldre USB system fick man hantera det här med logik utanför USB chipet.
Moderna USB lösningar har oftast pullup hanteringen inbyggt och har då även automatisk hantering av VBUS detect.
T.ex FTDIs USB till RS232 chip FT232R har sådan styrning.

Är devicen "bus powered" dvs använder VBUS som matning är det här inget större problem. När VBUS försvinner är ju devicen strömlös.

[Birger1234]

>Orsaken är att devicen talar om för hosten att den finns och är redo att
>användas genom att koppla en pullup till D+ (High speed) eller D- (Low speed).

Men det spelar väll ingen roll? Device sätter D+ i vilket fall som helst speciellt
om den har egen matning från egen strömkälla. Att Vbus spänningen finns där
redan spelar ju ingen roll och det beror ju inte på Vbus från Host utan att
device har detekterat en Vbus och sen talar om för Host via resistorn.

>För att lösa det enklast har man oftast en direktkoppling som gör att pulluppen
>kopplas bort om VBUS försvinner.
Tja då kan man ju vinka hej då till en separat Vbus detekt eller hur och det är
ju det jag poängterar. Jag hajjar inte varför PIC24 har en separat Vbus i Device
mode om det ändå är som du säger?

>Moderna USB lösningar har oftast pullup hanteringen inbyggt och har då även automatisk
>hantering av VBUS detect. T.ex FTDIs USB till RS232 chip FT232R har sådan styrning.
Det är just det här jag spånar kring, PIC24 har ju det och då kan man ju undra över
varför MCHP har en separat Vbus detekt?

Tog ner databladet på FT232R och noterar en intressant app, self powered där man
tagit Vbus till reset pinnen så Devicen kan bara bota igång om Vbus finns tillgänglig
och det är det enda stället Vbus går till i den appen så hur kan FT chippet detektera
Vbus då?

vbus2.gif

>Är devicen "bus powered" dvs använder VBUS som matning är det här inget större problem.
>När VBUS försvinner är ju devicen strömlös.

Och hur ofta försvinner Vbus?

[mooo]

> Men det spelar väll ingen roll? Device sätter D+ i vilket fall som helst speciellt
> om den har egen matning från egen strömkälla. Att Vbus spänningen finns där
> redan spelar ju ingen roll och det beror ju inte på Vbus från Host utan att
> device har detekterat en Vbus och sen talar om för Host via resistorn.

Orsaken till att man inte får koppla in pullup till D+ när inte VBUS finns är för att då är
troligtvis hosten avstängd. Det är olämpligt att bakmata PCn även om man använder en pullup.


> >Moderna USB lösningar har oftast pullup hanteringen inbyggt och har då även automatisk
> >hantering av VBUS detect. T.ex FTDIs USB till RS232 chip FT232R har sådan styrning.
> Det är just det här jag spånar kring, PIC24 har ju det och då kan man ju undra över
> varför MCHP har en separat Vbus detekt?

Därför PIC24 har en USBOTG lösning. FTID FT232R och PIC18 är rena USB2 devicer och har inte någon direkt användning av VBUS sense.
VBUS sense används troligtvis för att sätta PIC24ans USBOTG i device läge och stänga av HOST delen som ingår i ett USBOTG chip.
Samt att även via register tala om för mjukvaran att VBUS är aktiv.

Vill du ha VBUS sence på PIC18 så måste en GPIO användas (5v tollerant eller via spänningsdelare). Dock bara nödvändigt i selft powered mode.


I en enhet som är self powered är det oftast så att man vill kunna hålla koll på om hosten är igång eller ej.
T.ex att först när VBUS finns aktivera USB stacken med interrupts och efter det aktivera D+ pullup.

Har man BUS powered är det här oftast helt ointressant.
Finns VCC så finns VBUS o då är USBn aktiv.

Det finns många USB lösningar som primärt är designade för BUS powered mode. Och då behövs inte VBUS detect.
Vill man köra self powered och vara säker på funktion i alla konstiga fall så får man lösa VBUS detect
själv om inte USB chipet man använder har VBUS detect.

> Tog ner databladet på FT232R och noterar en intressant app, self powered där man
> tagit Vbus till reset pinnen så Devicen kan bara bota igång om Vbus finns tillgänglig
> och det är det enda stället Vbus går till i den appen så hur kan FT chippet detektera
> Vbus då?

I FTDI chip fallet så har de en enkel och elegant lösning. VBUS är i exemplet kopplad till en reset pinne som
stänger av hela FTDI chipet och sätter det i lågeffektläge. Resultatet blir att även pullupen till D+ (som är intern) kopplas bort.

Finns inte VBUS så är hosten avstäng och då kan man lika gärna stänga av.
Så de har VBUS detect men den stänger av hela USB chipet.

> Och hur ofta försvinner Vbus?
Varje gång PCn enheten är kopplad till stängs av eller om hosten får för sig att stänga av VBUS aktivt till en enhet.

[Birger1234]

>VBUS sense används troligtvis för att sätta PIC24ans USBOTG i device läge och
>stänga av HOST delen som ingår i ett USBOTG chip.

OTG verkar ju vara en slags roll bytar läge, OTG-A eller B (2.0 komplement) som jag
förstått det, Vbus detekt i en PIC24 sätter tydligen bara en flagga i ett register
stänger inte ner några enskilda delar, läste just på ett fora att OTG kan slås
på och vara aktiv när PIC24an fortfarande är i Device mode utan att kolla
vissa register status!?! Rörigt detta minst sagt.

Angående Vbus och de tre protokollen som används kring OTG läge:
http://en.wikipedia.org/wiki/USB_On-The-Go

>Därför PIC24 har en USBOTG lösning. FTID FT232R och PIC18 är
>rena USB2 devicer och har inte någon direkt användning av VBUS sense.

Exakt det jag poängterar ochså. Hur som, nu börjar vi komma nån vart med det här!
Så , jo det är ju det jag vill göra, köra PIC24 som en ren Device utan att behöva använda
den dedikerade Vbus detekt pinnen.

>Har man BUS powered är det här oftast helt ointressant. Finns VCC så finns VBUS o då är USBn aktiv.
>Det finns många USB lösningar som primärt är designade för BUS powered mode. Och då behövs inte VBUS detect.
>Vill man köra self powered och vara säker på funktion i alla konstiga fall
>så får man lösa VBUS detect själv om inte USB chipet man använder har VBUS detect.
>I FTDI chip fallet så har de en enkel och elegant lösning. VBUS är i exemplet kopplad till en reset pinne som
>stänger av hela FTDI chipet och sätter det i lågeffektläge. Resultatet blir att även pullupen till D+ (som är intern) >kopplas bort.

>Så de har VBUS detect men den stänger av hela USB chipet.

Det var det jag ville påvisa med den bilden att det inte var en Vbus detekt i vanlig mening.
Likväl kan man använda den principen på vad som helst, t.ex en PIC24, och varför inte!

Så, om jag tolkar dig rätt nu här till slut och som du nu redan sagt och det
jag misstänkte, Vbus detect behövs inte i en PIC24 Device only applikation?
(bortse från om den är selfpowered eller Vbus eller annat.)