Ich möchte für eine MIDI-Applikation Daten-Stings zu je 7 Byte aufm UART ausgeben. Doch es sollen auch Daten am UART-Eingang einen Interrupt auslösen und direkt an den UART-Ausgang weitergeleitet werden. Jetzt zu meiner Frage: Lässt sich das über einen einzigen Hardware UART im Mega 16 umsetzten? Ein- und Ausgang teilen sich das UART Datenregister. Somit ist es nötig, für die Dauer des Sendens des 7 Byte Daten-Strings, die ja nicht zerpfückt werden dürfen, den Empfang zu unterbrechen. Die Zeit währenddessen würde also ausreichen, um 7 Bytes am Eingang zu verpassen. Das kann also nicht gehen, oder? Muß ich also zusätzlich einen Software-UART implementieren?
Du sprichst zwar logisch nur ein Register an, das UDR, aber es sind physikalisch zwei Register. Lesend wird das Empfangsregister und schreibend das Senderegister gewählt. Die zur Verfügung stehenden Interrupts erlauben es dir gleichzeitig zu senden und zu empfangen, ohne daß was verloren geht. MW
Is ja super! FREU Es dürfen lesen & schreiben somit gleichzeitig aktiviert sein? (hatte mich schon gewundert, wieso das überhaupt geht...) Und wenn ich ankommende Daten "durchschleifen" möchte muß ich sie einmal einlesen und wieder ausgeben, damits vom Eingangs- ins Ausgangsregister geschoben wird? (eigentlich ganz klar - doch durch die Gleichnamigkeit der beiden UDR bin ich etwas durcheinander gekommen...) Vielen Dank für die superschnelle Info!
Klingt verdächtig nach MIDI-Controller mit MIDI-THRU Funktion. An deiner Stelle würde ich alles was reinkommt und die von dir selbst erzeugten Daten in einen Rundpuffer mit FIFO-Prinzip schreiben und dann diesen Rundpuffer zyklisch wieder auslesen und die Daten ausgeben. Denk aber daran, dass du ein Speicherproblem bekommst, wenn dein Sender lange SYSEX-Befehle verschickt. Gruss Christian
Mal jetzt ganz ohne Quatsch: MIDI ist ein 8-bit Signal, auch wenn nur Werte von 0-127 übertragen werden. Das höchstwertigste Bit signalisiert das Statusbyte, welches jedem MIDI-Befehl vorangestellt ist. Bei den Datanbytes ist das MSB dann 0, muß aber übertragen werden, da sonst der Datenstrom aus dem Ruder läuft. Also Startbit 0, 8 Bits, Stopbit 1. Keine Parität.
"Denk aber daran, dass du ein Speicherproblem bekommst, wenn dein Sender lange SYSEX-Befehle verschickt." Naja die SYSEX-Befehle sind jeweils 7 Byte lang, wie gesagt. Was passiert eigentlich, wenn die SYSEX-Übertragung mittendrin unterbrochen wird und später nochmal von neuem gestartet? Der einzige wirkliche Nachteil ist doch der entstehende Datentrash, der bei angeschlossenem Sequenzer mit aufgezeichnet wird, oder?
... bedenke dass echte Sysex Daten schon mal einige KB lang sein könnten, z.B. Sysex Dumps oder Firmware (hier bis in den MB- Bereich, sicherlich wird der ja aber nicht während einer Performance übertragen!)/ Progs / Setups für diverse MIDI Geräte. Auch Midi Timecode verursacht einigen "Traffic" der u.U. das Timing negativ beeinflussen kann. Anders herum können Verzögerungen von diversen "Paketen" noch größere Probleme verursachen. Wenn man einen Controller baut, sollte man deshalb vielleicht besser nicht versuchen, "seine" Control Daten in einen aktiven MIDI- Stream "einzuschleifen", sondern nach Möglichkeit dafür einen (physikalisch) separaten MIDI Kanal benutzen.
Was bitte sind denn "echte" SYSEX-Daten?!? Firmware-Updates wollte ich übrigens nicht durch den controller schicken. Bei jedem Anbieter solcher Updates, welcher auch nur ein wenig Ahnung von seinem Produkt hat wird auch explizit davor gewarnt, solche Updates an andere Geräte als das Zielgerät zu schicken. Wieso sollte ich jetzt dafür spezielle Filter einbauen und tausende Updates von hunderten firmen testweise an das Gerät schicken um festzustellen, ob zufällig eine Zeichenfolge enthalten ist, welche als "Note On" oder so interpretiert wird, um dann bei bestimmten vorangehenden Zeichen dieses "Note On?" ebenfalls zu ignorieren, was bei einem zukünftigen Update eines x-beliebigen Herstellers sowieso nichts bringen würde? Für Timecode und fremde Kanäle etc. assembliere ich selbstverständlich noch ein Filter... Da stecken selbst in diesem sehr einfachen Projekt schon schwierigere Sachen als ein solches Filter drin, das ist schnell mal eben in 20 min - max. 2 Stunden (aber nur falls ich wieder auf irgend einen Bug im Simulator stoße) programmiert. Der Controller den ich bastel hat übrigens genau den Zweck, Daten in den MIDI-Strom einzumergen. Das Gerät, an das der Strom weitergeleitet wird hat nur einen MIDI in. Und selbst wenn es zwei MIDI in hätte würden die doch auch wieder gemerged?!? Oder kennst du einen Synthesizer, der zwei getrennte Prozessoren für Note-Daten und Controller-Daten hat? Selbst dann müsste man mergen, falls man Controllerdaten in einen Sequenzer aufzeichnet... Oder der Synthesizer müsste theoretisch zwei MIDI-Prozessoren haben, die gleichzeitig gleichwertig auf die Synthese-Hardware zugreifen können müssten...
> Naja die SYSEX-Befehle sind jeweils 7 Byte lang, wie gesagt.
Das ist wohl nicht richtig. SYSEX-Daten können ja alles mögliche
enthalten, sie sind eben SYStem-EXclucive (und nicht immer 7 Byte lang)
@Chief Brady Bei Dir ist wohl was nicht ganz richtig. Wo sollen denn diese anderen Daten herkommen? Willst Du die per Sendemast einstreuen oder was? Selbst wenn Du ein Gerät baust, welches einen Datenstrom ausgibt, der vorgibt, ein Datenstrom zu sein, der von meinem Gerät nicht herausgefiltert wird (entsprechende ID und entsprechender Aufbau des Datenstromes), wird mein Gerät sich deshalb nicht aufhängen, keine Angst. Sollte es mir sinnvoll erscheinen, bau ich auch noch extra was ein, was auch externe Datenstrings abwürgt, sollten sie eine Länge von 7 Bytes überschreiten. Doch den Sinn dafür kann ich nicht erkennen. Das MIDI Studio ist nicht das Internet, wo man damit rechnen muß, dass jemand einem absichtlich Trash schickt um das System zu überlasten. Für das Gerät, was an meinem Gerät dranhängt kann ich natürlich nicht garantieren. Dennoch wird es mit dem zusätzlichen MIDI-Filter weniger Trash verarbeiten müssen als ohne. Ich versteh nicht was das fürn pralles Argument sein soll, dass es bei anderen Geräten auch länger Datenströme gibt?!? Das ist wie wenn jemand sagt: "Ich hab mir einen Golf gekauft" und man ihm sagt: "Das ist wohl nicht richtig. Es gibt auch LKW."
Hi Alisa 1387! Sorry, dumm von mir, Bits und Bytes nicht unterscheiden zu können (Brille nicht geputzt). Allerdings hat ChiefBrady recht, man muß in der Programmiererei einige Eventualitäten mit einbeziehen und Daten, die auf dem UART einlaufen, erzeugen ja immer (wenn´s so programmiert ist) ´nen Interrupt, somit können ewig lange SysEx Dumps auch reichlich Power aus Deinem Controller abverlangen, der dann alle Millisekunde unterbrochen wird bei der Arbeit. ID-Bytes sind ein guter Ansatz, allerdings auch nicht völlig sicher, weil Übertragungsfehler sind ja auch schon vorgekommen (und das Interrupt-Problem bleibt). Vielleicht machen mehrere IDs durchaus Sinn. Mal ´ne andere Frage, sollen die UART-Eingangsdaten noch verändert werden, bevor sie an den Ausgang weitergeleitet werden? Dann könnte die Zeit ein wenig knapp werden. Wenn der Prozi dann noch lustig andere Sachen treibt und die Daten dann nicht wegholt, kann schonmal der Eingangspuffer überlaufen. Bei ´ner Interrupt-Programmierung kann dann auch schon mal das Hauptprogramm ausgebremst werden, was freilich nur dann stört, wenn andere zeitkritische Dinge derweil erledigt werden (Display-Update, Echtzeitübertragung von Daten etc.)...
Ich habe mal an einem Gerät mitentwickelt, dass hauptsächlich dazu gedacht war, andere MIDI-(fähige) Geräte mittels SYSEX-Befehle ferzusteuern. Dabei kann es durchaus sein, dass grössere Datenströme auftreten. Schliesslich ist es dem Gerätehersteller überlassen, was er für Sachen über SYSEX implementiert. Dabei geht es nicht um Dumps oder Trash. Aber es könnte z. B. ein Synti über SYSEX "mal eben" neu konfiguriert werden und das auch live 'on stage'.
Selbstverständlich habe ich mir die SYSEX Implementation des Herstellers der anzusteuernden Geräte besorgt - ohne wüsste ich ja auch kaum, was ich senden soll... Believe it or not - die zu erzeugenden Strings sind je 7 Byte lang, so wie eingangs in diesem Thread spezifiziert.
Nein, das Gerät kam nie auf dem Makt. Ich werde heute abend mal nachsehen, was ich da noch für Infos habe (ist schon 'ne Weile her). Ich müsste noch die Unterlagen vom Waldorf Microwave 2 haben.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.