Hallå!
Finns det någon där ute som har använt en Philips PDIUSBD12 usb interface?
Jag ska låta en Pic18F258 agera usb-mus och jag har läst datablad och usb-spec:ar så det bara snurrar i bollen, men jag kommer inte igång.
Målet i framtiden är att jag ska tillverka en hel mus men måste börja från ruta1.
Jag har kommit så långt att pic:en fungerar på labb-plattan, usb-kretsen ligger fortfarande på bordet.
Tips och råd välkomnas!
Usb interface med PDIUSBD12
Jag har ochså en PBxx liggandes i lådan. Där har den legat i ett antal år nu.
Jag har, precis som du - läst specen ett antal gånger. Jag vet inte om den är svår att använda, men jag kom liksom aldrig igång med den.
Däremot så hittade jag en annan krets för ett par år sedan...
Jag fick en FT245BM att snurra på på första försöket, med hem-slaskat kort och allt.
Det enda problemet jag har stött på (hittills) är ett API-anrop som jag måste konvertera ifrån exempelkodens Visual Pascal till VB.
Jag kan hjälpa dig om du är intresserad.
Datablad / typiska kopplingar / drivrutiner : www.ftdichip.com & www.dlpdesign.com
Kretsar / demokit : www.lawicel.com
Jag har, precis som du - läst specen ett antal gånger. Jag vet inte om den är svår att använda, men jag kom liksom aldrig igång med den.
Däremot så hittade jag en annan krets för ett par år sedan...
Jag fick en FT245BM att snurra på på första försöket, med hem-slaskat kort och allt.
Det enda problemet jag har stött på (hittills) är ett API-anrop som jag måste konvertera ifrån exempelkodens Visual Pascal till VB.
Jag kan hjälpa dig om du är intresserad.
Datablad / typiska kopplingar / drivrutiner : www.ftdichip.com & www.dlpdesign.com
Kretsar / demokit : www.lawicel.com
Vad kul att fler än jag jobbar med PDIUSBD12 kretsen !!
Jag jobbade med denna, bland annat i mitt exjobb.. Nu så fort jag orkar och hinner skall jag försöka skriva ett litet ramverk för en ATmega - processor för att handtera just D12:an.
Problemet med D12:an är dess datablad. Databladet är väldigt kort och förutsätter att man verkligen läser mellan raderna och att man verkligen kan USB standarden. Men när man väl kommit över de stora hinderna är det än väldigt bra krets, tycker jag...
Såå hur gör man. Ett lär dig USB standarden, Två lär dig USB standarden. Tre börja leta efter exempel där kretsen användts. Det finns några på Philips hemsida. De är inte jättebra, men orkar man sätta sig in i dem så ger de mycket. Det blev för oss att läsa en hel del taskigt skriven källkod utan kommentarer. En stor hjälp vi hade var att söka efter andra som jobbat med kretsen. Det finns ett diskussionsforum som heter USB-IF på adressen:
http://www.usb.org/phpbb/
Gå med i detta och sök efter PDIUSBD12. Du kommer att hitta oerhört mycket bra info där
. Om det är något du inte hittar som du undrar över, så finns där mycket folk som är väldigt insatta i USB-systemet.
När du väl är har byggt elektroniken du behöver runt kretsen och kopplat den till din CPU (gissar på mikrokontroller) så börjar det roliga. Eftersom en USB-funktion (det du bygger) är ren slav under hosten så skall du egentligen bara svara på en massa anrop, i alla fall tills du blivit enumererad - tilldelad en address i USB systemet.
Det första som händer är att hosten märker att du sitter på bussen när D12-kretsen vaknar. Då börjar den skicka en del anrop för att ta reda på vem du är. Så fort enheten har identifierat sig, skickat sin device descriptor så börjar systemet leta efter en drivrutin. Detta gör att du troligen även får skriva en drivrutin till ditt OS samtidigt som du utvecklar grunkan. Själv jobbade jag med Linux vilket gjorde att jag hade gott om exempel på hur en drivrutin skulle se ut. Jobbar du under windows borde det finnas gott om dokumentation och inte vara allt för svårt om du använder något .NET verktyg, ex visual C++ eller dyl.
Tyvärr har jag inga bra exempel jag kan dela med mig av. Du skulle iofs kunna få den drivrutin vi skrev till Linux-systemet, men jobbar du under windows så är den rätt värdelös. I vårt fall använde vi en tillståndsmaskin i en FPGA, vilket gör att allt vi gjort på funktionssidan är skrivet i VHDL (ren elektronik). Däremot kommer jag så fort jag får grejen att fungera (när jag väl får ork att dra igång det hela) så kommer jag att lägga ut ritningar och källkod etc på en hemsida som jag sitter och knackar på.
Skulle det vara något specifik du undrar över, kolla forumet jag gav dig. Annars kan du alltid fråga så kan jag svara utifrån vad jag vet och kan.
Lycka Till..!
Jag jobbade med denna, bland annat i mitt exjobb.. Nu så fort jag orkar och hinner skall jag försöka skriva ett litet ramverk för en ATmega - processor för att handtera just D12:an.
Problemet med D12:an är dess datablad. Databladet är väldigt kort och förutsätter att man verkligen läser mellan raderna och att man verkligen kan USB standarden. Men när man väl kommit över de stora hinderna är det än väldigt bra krets, tycker jag...
Såå hur gör man. Ett lär dig USB standarden, Två lär dig USB standarden. Tre börja leta efter exempel där kretsen användts. Det finns några på Philips hemsida. De är inte jättebra, men orkar man sätta sig in i dem så ger de mycket. Det blev för oss att läsa en hel del taskigt skriven källkod utan kommentarer. En stor hjälp vi hade var att söka efter andra som jobbat med kretsen. Det finns ett diskussionsforum som heter USB-IF på adressen:
http://www.usb.org/phpbb/
Gå med i detta och sök efter PDIUSBD12. Du kommer att hitta oerhört mycket bra info där
. Om det är något du inte hittar som du undrar över, så finns där mycket folk som är väldigt insatta i USB-systemet. När du väl är har byggt elektroniken du behöver runt kretsen och kopplat den till din CPU (gissar på mikrokontroller) så börjar det roliga. Eftersom en USB-funktion (det du bygger) är ren slav under hosten så skall du egentligen bara svara på en massa anrop, i alla fall tills du blivit enumererad - tilldelad en address i USB systemet.
Det första som händer är att hosten märker att du sitter på bussen när D12-kretsen vaknar. Då börjar den skicka en del anrop för att ta reda på vem du är. Så fort enheten har identifierat sig, skickat sin device descriptor så börjar systemet leta efter en drivrutin. Detta gör att du troligen även får skriva en drivrutin till ditt OS samtidigt som du utvecklar grunkan. Själv jobbade jag med Linux vilket gjorde att jag hade gott om exempel på hur en drivrutin skulle se ut. Jobbar du under windows borde det finnas gott om dokumentation och inte vara allt för svårt om du använder något .NET verktyg, ex visual C++ eller dyl.
Tyvärr har jag inga bra exempel jag kan dela med mig av. Du skulle iofs kunna få den drivrutin vi skrev till Linux-systemet, men jobbar du under windows så är den rätt värdelös. I vårt fall använde vi en tillståndsmaskin i en FPGA, vilket gör att allt vi gjort på funktionssidan är skrivet i VHDL (ren elektronik). Däremot kommer jag så fort jag får grejen att fungera (när jag väl får ork att dra igång det hela) så kommer jag att lägga ut ritningar och källkod etc på en hemsida som jag sitter och knackar på.
Skulle det vara något specifik du undrar över, kolla forumet jag gav dig. Annars kan du alltid fråga så kan jag svara utifrån vad jag vet och kan.
Lycka Till..!
Så bra.. 2 experter på området (jag syftar på Michel och Mattias).
Jag har faktiskt kommit igång lite, elektroniken är uppkopplad, har börjat med programmeringen(lägsta nivå dvs. kommunikationen med D12:an).
Troligtvis kommer jag att köra fast men nu har jag ju nån att vända mig till.
När det gäller drivrutiner så kan man med fördel använda windows egna, detta ska ju trots allt bara bli en mus (till att börja med).
Jag köpte nyligen en Rotokiller 720(en mus).
Den låtsas vara både mus,tanjentbord och har ett eget ostandard kommunikations-system som den använder när man configurerar musen.
Den skickar även axelinfo i 16bitars paket i stället för 8bitars.
Och den kräver inga drivrutiner. Så tydligen går det om man är HID-expert.
Tack för alla bra tips.
Jag har faktiskt kommit igång lite, elektroniken är uppkopplad, har börjat med programmeringen(lägsta nivå dvs. kommunikationen med D12:an).
Troligtvis kommer jag att köra fast men nu har jag ju nån att vända mig till.
När det gäller drivrutiner så kan man med fördel använda windows egna, detta ska ju trots allt bara bli en mus (till att börja med).
Jag köpte nyligen en Rotokiller 720(en mus).
Den låtsas vara både mus,tanjentbord och har ett eget ostandard kommunikations-system som den använder när man configurerar musen.
Den skickar även axelinfo i 16bitars paket i stället för 8bitars.
Och den kräver inga drivrutiner. Så tydligen går det om man är HID-expert.
Tack för alla bra tips.
Expert & expert?
Näe - philipskretsen vill jag inte påstå att jag *kan* - då det var några år sedan jag läste på om den.
FT245BM är en DSS (dead simple stupid) krets.
Om den har sina (få) kringkomponenter rätt kopplade så är den lika avancerad som en 74LS245 att kommunicera med (därav namnet).
Man bygger den, pluggar in den och installerar drivrutinen på datorn när den efterfrågas - enklare blir det knappast.
Den har dock inte flera endpoints, vilket jag har för mig att philips kretsen har.
Näe - philipskretsen vill jag inte påstå att jag *kan* - då det var några år sedan jag läste på om den.
FT245BM är en DSS (dead simple stupid) krets.
Om den har sina (få) kringkomponenter rätt kopplade så är den lika avancerad som en 74LS245 att kommunicera med (därav namnet).
Man bygger den, pluggar in den och installerar drivrutinen på datorn när den efterfrågas - enklare blir det knappast.
Den har dock inte flera endpoints, vilket jag har för mig att philips kretsen har.
Nu börjar det likna något !
Jag har kopplat en LCD display(L167100J) till pic:en så debugging är inget problem längre.
Pic:en har fått sitt första "Setup Packet" från datorn.
Paketet ser ut så här: 08(storlek)80 06 0001 0000 4000
http://www.beyondlogic.org/usbnutshell/ ... etupPacket
Om man kollar på länken ovan så ser man att 80 betyder:
Data Phase Transfer Direction = Device to Host
Type = Standard
Recipient = Device
06 betyder: GET_DESCRIPTOR
Men jag förstår inte vad som ska hända sen.
Det skulle vara trevligt att få lite vägledning av er !
Tack!
Jag har kopplat en LCD display(L167100J) till pic:en så debugging är inget problem längre.
Pic:en har fått sitt första "Setup Packet" från datorn.
Paketet ser ut så här: 08(storlek)80 06 0001 0000 4000
http://www.beyondlogic.org/usbnutshell/ ... etupPacket
Om man kollar på länken ovan så ser man att 80 betyder:
Data Phase Transfer Direction = Device to Host
Type = Standard
Recipient = Device
06 betyder: GET_DESCRIPTOR
Men jag förstår inte vad som ska hända sen.
Det skulle vara trevligt att få lite vägledning av er !
Tack!
Precis som jag sa ovan, läs USB-specifikationen...!!! Där står egentligen allt du behöver veta vad det gäller USB protokollet. Varje device (hubb, eller funktion) på usbbussen identifieras via en divice-descripot. Denna används för att identifiera devicen så att systemet kan välja rätt drivrutin för att sköta den individuella grunkan.Chribbe76 skrev: http://www.beyondlogic.org/usbnutshell/ ... etupPacket
Om man kollar på länken ovan så ser man att 80 betyder:
Data Phase Transfer Direction = Device to Host
Type = Standard
Recipient = Device
06 betyder: GET_DESCRIPTOR
Men jag förstår inte vad som ska hända sen.
Det skulle vara trevligt att få lite vägledning av er !
När man får den första förfrågningen om att skicka sin standard device descriptor, skulle man bara sicka en del av den -- kommer inte ihåg hur stor -- står i USB specen. Detta för att hosten skall få reda på hur stor buffer du har, hur mycket data du kan skicka med ett paket. Därefter kommer hosten igen att fråga efter din standard device descriptor för att därefter gå in i enumeringingsfasen. I Enumeringsfasen blir du tilldelad den adress på vilken du skall svara så länge du sitter ansluten till systemet. Därefter kommer hosten att fråga efter ett antal andra descriptorer. Det finns även en hel drös med standard funktioner som varje usb-device måste kunna utföra, tror det var 11-12 stycken. Allt detta står väl dokumenterat i USB-specen. Jag vet att det kan kännas tråkigt att behöva läsa den (ca 700 sidor), men det är väl värt mödan. Där står verkligen allt som du behöver göra för att enumerera dig och få igång kommunikationen över usb-bussen..
Hoppas att du fick svar på vad du verkligen menade..!
Lycka till..!
'När man får den första förfrågningen om att skicka sin standard device descriptor,...'
Jag känner igen det där.
Gissa varför jag övergav PDIUSBD12?
Man lär sig mycket om USB genom användandet av den kretsen.
Jag anser dock att man inte ska behöva bli expert på USB-specen bara för att kunna skicka ett par byte fram och tillbaka.
FT245BM sköter det där åt dig. 8 bitar in / ut med read / write samt ett par handskakningspinnar för mottagnings- och sänd-bufferten.
Hoppas att du har mer tålamod än mig och lycka till!
Jag känner igen det där.
Gissa varför jag övergav PDIUSBD12?
Man lär sig mycket om USB genom användandet av den kretsen.
Jag anser dock att man inte ska behöva bli expert på USB-specen bara för att kunna skicka ett par byte fram och tillbaka.
FT245BM sköter det där åt dig. 8 bitar in / ut med read / write samt ett par handskakningspinnar för mottagnings- och sänd-bufferten.
Hoppas att du har mer tålamod än mig och lycka till!
