Gå til innhold

Kan jeg bruke DVI til noe annet enn kun skjerm?


Force

Anbefalte innlegg

Videoannonse
Annonse

Jeg trodde at jeg forklarte greit nok, men nei :(

Altså bruke skjerm kontakt til andre formål enn bare bilder som vi forstår. Dere vet at VGA, DVI, HDMI er for å vise BILDER men jeg vil bruke til andre formål enn bare å vise på skjerm. F.eks USB kan vise bilder men den blir jo brukt til andre formål.

Endret av Force
Lenke til kommentar

Jeg trodde at jeg forklarte greit nok, men nei :(

Altså bruke skjerm kontakt til andre formål enn bare bilder som vi forstår. Dere vet at VGA, DVI, HDMI er for å vise BILDER men jeg vil bruke til andre formål enn bare å vise på skjerm. F.eks USB kan vise bilder men den blir jo brukt til andre formål.

Dere vet at HDMI, VGA, DVI er for å vise mange lyspunkter på en flatt objekt, men jeg vil at lysdioder skal bli skiftet ut til og brukt til stepper motor.

Lenke til kommentar

 

Jeg trodde at jeg forklarte greit nok, men nei :(

Altså bruke skjerm kontakt til andre formål enn bare bilder som vi forstår. Dere vet at VGA, DVI, HDMI er for å vise BILDER men jeg vil bruke til andre formål enn bare å vise på skjerm. F.eks USB kan vise bilder men den blir jo brukt til andre formål.

Dere vet at HDMI, VGA, DVI er for å vise mange lyspunkter på en flatt objekt, men jeg vil at lysdioder skal bli skiftet ut til og brukt til stepper motor.

 

sånn å forstå .

 

min mening er at du satser på feil type kontakt / kabel.

 

Da er det bedre å bruke en av de standard kablene som er beregnet til signal overføring . som feks USB

Det har også med å gjøre for finne grensesnitt som passer inn

 

du kan jo ta en titt på denne oversikten :

 

https://www.google.no/search?q=usb+step+motor&client=firefox-a&hs=2dw&rls=org.mozilla:nb-NO:official&channel=fflb&tbm=isch&imgil=ZDK8JJXa6lCmnM%253A%253Bhttps%253A%252F%252Fencrypted-tbn0.gstatic.com%252Fimages%253Fq%253Dtbn%253AANd9GcRaTRUMLGTtsiNMJA_E_vsXDdvfQUS-wp36kU-RTvrH9pwWRO0f%253B666%253B330%253BYcd7mFfWzjyCtM%253Bhttp%25253A%25252F%25252Fwww.imagesco.com%25252Fcatalog%25252Fmotors%25252Fstepper.html&source=iu&usg=__mcCegpR1HnyvsQDH455R2POUdEk%3D&sa=X&ei=acRSU76WC6KL4ASH54Bw&ved=0CDsQ9QEwAA#facrc=_&imgdii=_&imgrc=ZDK8JJXa6lCmnM%253A%3BYcd7mFfWzjyCtM%3Bhttp%253A%252F%252Fwww.imagesco.com%252Fcatalog%252Fmotors%252Fimg%252Fstep-ctrlu.jpg%3Bhttp%253A%252F%252Fwww.imagesco.com%252Fcatalog%252Fmotors%252Fstepper.html%3B666%3B330

Endret av den andre elgen
Lenke til kommentar

Men _hvorfor_? Det finnes mange bedre løsninger til formålet enn DVI, og da lurer eg veldig på hvorfor du skal bruke _bildesignal_ til å drive motorene dine. Dvs, hvorfor bruke masse tid, energi og penger på å få til noe som er lite effektivt og uegnet når det finnes løsninger som er laget for formålet?

Lenke til kommentar

Men _hvorfor_? Det finnes mange bedre løsninger til formålet enn DVI, og da lurer eg veldig på hvorfor du skal bruke _bildesignal_ til å drive motorene dine. Dvs, hvorfor bruke masse tid, energi og penger på å få til noe som er lite effektivt og uegnet når det finnes løsninger som er laget for formålet?

Hvilken løsninger da ?

Lenke til kommentar

 

Men _hvorfor_? Det finnes mange bedre løsninger til formålet enn DVI, og da lurer eg veldig på hvorfor du skal bruke _bildesignal_ til å drive motorene dine. Dvs, hvorfor bruke masse tid, energi og penger på å få til noe som er lite effektivt og uegnet når det finnes løsninger som er laget for formålet?

Hvilken løsninger da ?

 

La oss se hvilken alternativer jeg har... i rangert rekkefølge; COM port, LPT port, USB, PCIe x16.

Lenke til kommentar

Hvis du skal oppdatere hundrevis av ting er det kanskje greiere å sende addresserte datapakker ... hva med å trekke nettverkskabel, og bruke et par-tre beaglebone black pluss litt egen kode til å lytte på nettverket / drive motorene? Det er antageligvis mye enklere enn å finne noe som kan dekode DVI, finne ut hvordan den addresserer pixler, og å jobbe med den trolig veldig lave spenningen den vil produsere.

 

(Pluss at DVI har en temmelig kort makslengde.)

Lenke til kommentar

Hvis du skal oppdatere hundrevis av ting er det kanskje greiere å sende addresserte datapakker ... hva med å trekke nettverkskabel, og bruke et par-tre beaglebone black pluss litt egen kode til å lytte på nettverket / drive motorene? Det er antageligvis mye enklere enn å finne noe som kan dekode DVI, finne ut hvordan den addresserer pixler, og å jobbe med den trolig veldig lave spenningen den vil produsere.

 

(Pluss at DVI har en temmelig kort makslengde.)

Jeg har en Arduino kort som gir opptil 54 digital signalkilder, da trenger jeg hmm... 4 stk av den, men skal finne ut hvor mye. Hvis jeg skal sende datapakker, da krever det enorm databredde fordi en integer har 256 forskjellige valuer men jeg trenger minst 2048 per instrument. Da blir det mye hvis jeg velger float metode; da blir det mye tom minnemengde. Det er derfor jeg ønsker å hardkode den.

Lenke til kommentar

 

Hvis du skal oppdatere hundrevis av ting er det kanskje greiere å sende addresserte datapakker ... hva med å trekke nettverkskabel, og bruke et par-tre beaglebone black pluss litt egen kode til å lytte på nettverket / drive motorene? Det er antageligvis mye enklere enn å finne noe som kan dekode DVI, finne ut hvordan den addresserer pixler, og å jobbe med den trolig veldig lave spenningen den vil produsere.

 

(Pluss at DVI har en temmelig kort makslengde.)

Jeg har en Arduino kort som gir opptil 54 digital signalkilder, da trenger jeg hmm... 4 stk av den, men skal finne ut hvor mye. Hvis jeg skal sende datapakker, da krever det enorm databredde fordi en integer har 256 forskjellige valuer men jeg trenger minst 2048 per instrument. Da blir det mye hvis jeg velger float metode; da blir det mye tom minnemengde. Det er derfor jeg ønsker å hardkode den.

 

 

Vel. Si du vil oppdatere hvert instrument 50 ganger i sekundet (kanskje i overkant), og at det er 200 av dem - da er du oppe i 10000 pakker/sekunder om du gjør det på enklest mulig måte. Hvis du sender UDP, er det overhead på 28 bytes per pakke, pluss faktiske data. For enkelhets skyld, si du sender 16 bit instrument-ID og 16 bit verdi, for totale 32 byte per pakke. Da er du oppe i 320kB/sek, eller ca 2.5 Mbit.

 

Det er dog ikke en veldig elegant måte å gjøre det på, og å håndtere 10000 pps kan være litt drøyt. For å være mer praktisk: Se for deg at du har er array av 200 16-bits verdier (så 400 byte) som du holder oppdatert. 50 ganger i sekundet sender den verdiene ut til de 4 kontrollerene. For å være forsiktige kan vi fortsette å sende det som et par av ID+verdi. Det blir 50*4=200 byte, pluss headere = 228 byte per kontroller per oppdatering.

 

Totalt sett er det 228*4*50= 44.5kB/sec, eller 356 kbit/sec.

 

Jeg vil ikke kalle det en enorm databredde - det er 0.03% av en Gbit-link, eller 0.3% av 100Mbit om du må gå ned til det.

 

edit: Etter å ha sett litt på det - du kan nok også bruke SMBus. Med litt kreativ stapping av bits [1] og dropping av redundant info [2] er du nede i 27 kbit/sek pluss overhead per kontroller (108 kbit/sek pluss overhead totalt), som er litt for mye til å sende gjennom den aller tregeste versjonen (100kbit/sek), med mindre du trekker en separat kabel per kontroller. Fast mode (400kbit/sek) skal holde fint, og det finnes en high speed mode på 3.4mbit/sek som er direkte overkill.

 

Dette med forbehold om at jeg aldri har rørt I2C/SMBus , og ikke kan mer om det enn hva jeg fant på litt rask googling. Det ser ikke ut som om det skal være for vanskelig å få koblet det til på Arduino-siden, men jeg vet ikke hvor mye styr det er å få sendt det fra kontroller-siden.

 

 

[1] Hvis du trenger 2048 verdier (11 bit), kan du pakke 8 verdier på 11 byte - eller 50 verdier på 69 byte med et par bits til overs. Litt irriterende å pakke opp igjen, men du behøver i det minste bare skrive den koden én gang.

[2] Hvis du vet du alltid vil sende 50 verdier i samme rekkefølge hver gang, trenger du ikke sende med instrument-IDer. Totalt blir det da 69 byte * 50 ganger i sekundet = 3450 byte/sek , eller altså 27600 bits/sek per kontroller.

Endret av Djn
  • Liker 1
Lenke til kommentar
  • 3 uker senere...

Opprett en konto eller logg inn for å kommentere

Du må være et medlem for å kunne skrive en kommentar

Opprett konto

Det er enkelt å melde seg inn for å starte en ny konto!

Start en konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
×
×
  • Opprett ny...