Sida 2 av 3

Postat: 1 december 2006, 13:47:37
av sodjan
Japp. :-)
När jag kollade förrut så fick jag inte special-siten för den att fungera...

Postat: 1 december 2006, 14:38:15
av oJsan
Att skriva en programvara som kan dra nytta av ett smalt urval av devices är nog ett stort projekt. Jag sitter precis och modifierar källkod för _en_ USB-device (AudioClass). Bara det är nog jobbigt... Jag tror inte att det finns något företag som sätter sig ner och skriver en stack för en USB-host. Men om du har mycket fritid över så varsågod! ;)
Någon kanske redan frågat i tråden, men vad är det du ska använda den till? Datormöss snackar ju PS/2 också, vilket är mycket lättare att skriva kod för...

Edit: Oj va pessimistisk jag lät. =) Inte illa menat alls, vill bara säga att det är ett stort jobb som förmodligen tar lång tid...

Postat: 1 december 2006, 15:23:52
av JimmyAndersson
Tid? ...ja sånt har jag massor av. ..INTE. :D

Jag ska använda det till några synthar som saknar MIDI-interface. Det finns alltså bara en USB-port. Jag vill kunna koppla dem till egenbyggda synthar utan att blanda in datorn.

Nu har jag ingen erfarenhet av USB på den här nivån, men det är alltså inte så att man kan läsa av signalerna som kommer från t.ex MAX3421E som sodjan länkade till ?

Det fungerar alltså inte såhär:
Initiera och sånt...
Hitta USB-devicet
Ta emot det som skickas från devicet
Gör nåt med informationen...

eller?

Postat: 1 december 2006, 16:14:44
av Andax
Problemet med syntharna är att du inte vet högnivå-protokollet över USB. Skulle tro att varje synth har sitt eget överföringsformat även om de har USB som gemensam nämnare.
Det innebär att du måste göra ganska mycket reversed-engineering på informationen. Vilket visserligen är ganska spännande!
Finns något program (kommer dock inte på namnet just nu) som du kan köra på datorn som loggar alla datapaket som skickas via USB. Det kan man använda för att försöka avkoda protokollet..

Postat: 1 december 2006, 16:24:42
av bearing
Borde väl också gå att få den informationen från tillverkaren.

Postat: 1 december 2006, 16:31:33
av JimmyAndersson
Det kanske låter konstigt, men jag har sett fram emot lite reversed-engineering. Vrida och trycka för att se vad som skickas. :)

Men det går alltså att lyssna på USB-porten ganska enkelt? (Allt är ju relativt, men om vi säger att RS232 och SPI är enkelt.) :)

Postat: 1 december 2006, 16:33:22
av bearing
Jo, det kan vara kul. Men jag fick intrycket av att du inte hade all tid. :wink:

Postat: 1 december 2006, 16:36:33
av B1n4ry
SPI och RS232 jämfört med USB-HOST (som jag bara sneglat lite på)
är väl ungefär som att jämföra ett radiostyrt modellflygplan med en rymdfärja... ;-)

Om det handlar om att du vill få ut midi ur ett sådant där USB-anslutet PC-keyboard så är det nog 100ggr enklare att köpa ett nytt klaviatur med midi-port. ELLER så öppnar du det keyboard du har och stoppar in lite egen elektronik före USB-interfacet. (byter all elektronik i värsta fall)

//B1N4RY

Postat: 1 december 2006, 16:41:24
av JimmyAndersson
bearing:
Sant, men den delen brukar gå ganska fort. Man kan ju trycka/vrida på synthen och låta informationen från USB'n visas på en LCD eller skickas till ett terminalprogram på datorn. Sedan är det bara lägga in rätt data i PIC-koden.

Postat: 1 december 2006, 16:43:56
av JimmyAndersson
B1n4ry:
Nej nej nej, jag har redan fullt med synthar och det skulle inte lösa problemet med att jag vill bygga in en USB-host i mina egentillverkade synthar/kontrollers.

"100ggr enklare att köpa ett nytt klaviatur med midi-port."

Allt fler synthar/klaviaturer görs med USB-portar. Det är därför som jag vill bygga in USB-anslutning i mina projekt.

Postat: 1 december 2006, 17:11:20
av Andax
B1n4ry skrev:SPI och RS232 jämfört med USB-HOST (som jag bara sneglat lite på)
är väl ungefär som att jämföra ett radiostyrt modellflygplan med en rymdfärja... ;-)
Är väl en ganska stor överdrift! :)

USB nackdel är väl att det krävs en del insikt om hur saker funkar. Sedan är det inte extremt komplicerat i princip.
Vad som komplicerar USB är också att man just har abstraherat upp saker i operativsystemet med protokollstackar mm så att man måste göra drivrutinger som sköter kommunikationen.
Det finns en del sätt där man kan göra kommunikationen på en lägre (och i viss mån mer lättförståelig) men det är inte helt kompatibelt med t.ex. windows (tänker på libusb-win32).

Jimmy, jag säger: Kör på!!! Den där MAX3421E verkar helt ok...

Postat: 1 december 2006, 17:31:20
av bearing
Det är väl antagligen en hel OSI-modell inblandat i ett USB-system, så ju fler lager som kan skötas automatiskt av färdiga kretsar destå bättre, antar jag.

Postat: 1 december 2006, 17:40:31
av Jeppsson
För ett tag sedan så sniffa jag USB-enheter med denna...

USB Monitor

Screenshot

Den räckte till mina behov men jag tror att det finns bättre! :?

Postat: 1 december 2006, 17:43:55
av sodjan
> Allt fler synthar/klaviaturer görs med USB-portar.

Jo, men det är inte lika enkelt/generellt som om det var (t.ex) en RS232 port.

Antagligen (om prylen ett USB "device") så är tanken att det ska
köras mot en Windows-burk med de USB-drivers som leverantören
skickade med.

Visst, det är enkelt att säga "kör på !", men det är ta mig fanken inget
enkelt reverse-engineering projekt !

Det hade inte ens varit "enkelt" *även* om du hade all dokumentation
över USB-kommunikationen från leverantören !

Och även med Maxim kretsen, så vet du ju inte vad du ska skicka/ta imot...

Sniffers i all ära, men det ger sällan hela bilden.

Postat: 1 december 2006, 18:51:37
av JimmyAndersson
Men om jag kopplar upp USB-synth --> Maxim-kretsen --> PIC --> MAX232 --> Dator, och loggar all data som Maxim-kretsen ger i ett terminalprogram på datorn.
Sedan tittar på skärmen när jag inte gör något alls, trycker ner en knapp, släpper upp knappen.

Räcker inte det för att kunna se vilken data PIC-programmet behöver för att kunna läsa av knappen? Trycker man på en annan knapp så ser man ju vilken data som ändras (beroende av knapp) och vilken som är statisk (hör till själva USB-komunikationen.)

Eller har jag fel? Som sagt, jag är helt ny på detta.