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?
> 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
