Hi, hat jemand Erfahrung mit AVR-basierten Midi-Controllern mit (Software-)USB-Schnittstelle? Ich will was vergleichbares zu dem hier bauen: http://cryptomys.de/horo/V-USB-MIDI/index.html Kann man in etwa abschätzen, welche Latenz zu erwarten ist (die eigentliche Anwendungssoftware auf dem Atmega sollte keine wesentliche Rolle spielen)? Wäre ein Chip mit eingebautem USB-Stack, wie der ATmega32U2, wesentlich besser für so einen Zweck? Wenn euch noch weitere Aspekte einfallen, die man bei einem solchen Projekt beachten sollte, bitte auch gerne mitteilen! Grüße k
Midi ist Bulk und Bulk heißt kein Lowspeed. Auch wenn es früher funktioniert hat weil MS auch bei Lowspeed Bulk zugelassen hat. Es ist eindeutig gegen die Spec und funktioniert ab W7 nicht mehr. Thomas
Meinst du mit MS Microsoft und mit W7 Windows 7? Falls ja, spielt das für mich nicht so eine große Rolle, da ich nur Linux verwende ;-) Ich kenn mich mit beiden Standards (USB und Midi) leider nicht aus. Du meinst, dass die Midi-Charakteristika gegen die USB-Spec sprechen, nicht umgekehrt?
Ich verwende GM5 von Ploytec. Das ist eine simple Schaltung mit At90USB162, einem AVR mit 16k Flash, USB2.0 Hardware und einem USB-Bootloader, der von Windows aus befühlt werden kann. Ach ja, der hat 5 Midi-Kanäle gleichzeitig, rein und raus.
k. anton schrieb: > Kann man in etwa abschätzen, welche Latenz zu erwarten ist (die > eigentliche Anwendungssoftware auf dem Atmega sollte keine wesentliche > Rolle spielen)? Die variable Latenz beträgt mindestens 1ms, da mit den üblichen PC-seitigen Treibern nur einmal pro USB-Frame eine Übertragung stattfindet, denn LowSpeed darf lt. Standard keine Bulk- oder Isochron-Endpoints haben, bei denen das anders wäre. > Wäre ein Chip mit eingebautem USB-Stack, wie der ATmega32U2, wesentlich > besser für so einen Zweck? Ja, denn bei Fullspeed sind eben auch Bulk/Isochron-Transfers erlaubt, da können also mehrmals pro Frame Daten übertragen werden.
k. anton schrieb: > Meinst du mit MS Microsoft und mit W7 Windows 7? Falls ja, spielt das > für mich nicht so eine große Rolle, da ich nur Linux verwende ;-) Auch bei Linux wurden irgendwann die USB-Treiber gepatched, um sie auf standardgerechtes Verhalten zu trimmen. Hier funktionieren solche Geräte allerdings wenigstens weiterhin, denn die Bremse wird hier dadurch erreicht, daß Bulk-EPs bei LowSpeed-Geräten wie Interrupt-Endpoints behandelt werden. Den einzigen Vorteil den du bei Linux hast: Du kannst diesen Patch verhältnismäßig leicht auch selber wieder aus dem Treiber entfernen. Bei Windows ist das "etwas" komplizierter...
Hallo Anton, schau Dir doch mal die Seite ucApps.de an. Für mich immer noch die erste Adresse im Bereich Selbstbau rund um die MIDI-Schnittstelle. Gruss Roman
> Ich verwende GM5 von Ploytec > Ach ja, der hat 5 Midi-Kanäle gleichzeitig, rein und raus. klar die FW stammt ja auch in großen Teilen von mir das ist aber keine LowSpeed HW. Da der USB Midi Standart Bulk Transfers für die Übertragung nutzt fällt halt Low Speed per Definition raus. Zur Latenz Frage: rechne mal aus wie lange ein Midi Kommando bei 32kBaud braucht das sind schon zwischen 600 µS und 900 µS daraus musst du nach USB Midi 4 Bytes basteln und in den Puffer stellen. Bei einer optimalen Firmware wird es mit 2 ms funktionieren. Soweit mir bekannt ist funktioniert USB Midi auch unter Linux nicht mehr auf LowSpeed. > Ich kenn mich mit beiden Standards (USB und Midi) leider nicht aus dann wird das mit dem Selbstbau eher nichts werden. Ich würde ein fertiges Gerät kaufen. Einen normkonformen Midiinterpreter schreibt man nicht an einem Wochenende. Thomas
Roman schrieb: > Hallo Anton, > > schau Dir doch mal die Seite ucApps.de an. Für mich immer noch die erste > Adresse im Bereich Selbstbau rund um die MIDI-Schnittstelle. > > Gruss > > Roman War ich auch schon mal drüber gestolpert. Trotzdem danke für den Tipp :)
Thomas schrieb: > >> Ich kenn mich mit beiden Standards (USB und Midi) leider nicht aus > dann wird das mit dem Selbstbau eher nichts werden. Ich würde ein > fertiges Gerät kaufen. Einen normkonformen Midiinterpreter schreibt man > nicht an einem Wochenende. das ist schon klar. Ich hatte auch nicht vor, das Protokoll selbst zu implementieren. Da gibt's ja Libraries. Mit einem Atmega32U2 habe ich auch schon mal erfolgreich einen minimalistischen Midi-Controller auf Basis des LUFA-Projekts gebaut. Insofern wäre ich nicht so grundsätzlich pessimistisch ;-) Aber der 32U2 ist ein SMD-Bauteil und ich wollte erstmal mit (vorhandenen) Atmels auf Steckbrett und Lochraster experimentieren bevor ich eine Platine designe. Deswegen die ursprüngliche Frage. Aber ich habe mich überzeugen lassen, dass Lowspeed wenig Sinn ergibt. Danke und Gruß
Thomas schrieb: > rechne mal aus wie lange ein Midi Kommando bei 32kBaud braucht das sind > schon zwischen 600 µS und 900 µS daraus musst du nach USB Midi 4 Bytes > basteln und in den Puffer stellen. Bei einer optimalen Firmware wird es > mit 2 ms funktionieren. Ist das MIDI-Protokoll mit USB nicht schnellet geworden, oder wie ist das zu verstehen?
Ach so, mein Suchansatz war der hier: http://www.studio96.de/artikel/art030226%20verzoegerungen%20bei%20midi.html Ich meine aber mit USB2.0 geht das erheblich rascher,oder?
> Ich meine aber mit USB2.0 geht das erheblich rascher,oder?
warum soll es schneller gehen die Schnittstelle zu den Geräten ist ja
immer noch die Gleiche. Natürlich geht die USB Übertragung wesentlich
schneller. USB ist aber nur die Bridge auf dem Midikabel bleibt alles
beim alten. Dies ist übrigens auch der Grund warum die Midi
Schnittstelle selbst auf einem Lowspeed Device funktioniert wenn das OS
mispielt.
Die USB Maus wird ja auch nicht schneller wenn Sie an USB 2 hängt.
Die Daten werden bei USB ganz erheblich schneller übertragen, wobei
die Tabelle im oben genanten Link schlicht falsch ist.
Das Keyboard liefert die Midi Daten immer noch mit 32kBaut und diese
kommen auch nicht schneller am PC an.
Thomas
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.