mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik UART / MIDI


Autor: Alisa 1387 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Michael Wilhelm (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Alisa 1387 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Christian Schifferle (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: TravelRec. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Rahul (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@TravelRec:
Es geht um 7 Bytes, von Bits war keine Rede...

Autor: Alisa 1387 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"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?

Autor: Swen Strobel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
... 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.

Autor: Alisa 1387 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Chief Brady (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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)

Autor: Alisa 1387 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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."

Autor: TravelRec. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.)...

Autor: Chief Brady (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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'.

Autor: Alisa 1387 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Alisa 1387 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das Gerät war nicht von Behringer, oder?

Autor: Chief Brady (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.