Verschiedene MIDI Befehle in Abhängigkeit der Prozessorgeschwindigkeit

International Deutsch
1

Hallo Liebe Gemeinde,

ich habe mir mit einem AtMega8 ein MIDI Keyboard gebaut. Den Chip habe ich mit Hilfe des Arduino Uno ISP Programmers beschrieben. Das Keyboard funktioniert - alles ist gut. Nun habe ich im Nachhinein gelesen, dass der interne Oszillator aufgrund seiner mangelnden Genauigkeit nicht für serielle Datenübertragung geeignet sei und es zu Problemen während der Datenübertragung kommen kann; das möchte ich während einer Liveperformance gerne verhindern! Der Atmega läuft derzeit mit 1Mhz. Zu Versuchszwecken habe ich mit unterschiedlichen, über den internen Oszillator bereitgestellten Prozessorgeschwindigkeiten experimentiert (2, 4 und 8 Mhz). Dabei habe ich festgestellt, dass nun ganz andere MIDI Befehle gesendet werden. Woran kann das liegen? Sind das vielleicht schon die Probleme, vor denen gewarnt wird, wenn man den internen Oszillator verwendet? Möglicherweise weist die langsamste Geschwindigeit ja die beste Signalübertragung auf - oder? Einen externen 16 MHz Quarz habe ich schon mal ausprobiert. Das hatte leider nicht funktioniert - möglicherweise weil ich als Kondensatoren nicht die richtigen Werte zur Verfügung hatte. Das steht aber als nächstes auf meiner to-do Liste. Hat das schon mal jemand von euch ausprobiert - also einen Quartz mit den "falschen" Kondensatoren?

Viele Grüße
Chris

2

(deleted)

3

warum nimmst nicht einen "Standard" Atmega328 mit 16MHz Quartz der die angegebenen Raten gut einhält?
Schließlich bist du hier im Arduino Forum :wink:

4

besten Dank für die schnelle Rückmeldung. Wie gesagt, ich konnte keine Probleme bei der Datenübertragung unter 1MHz feststellen. Genau genommen hatte die Datenübertragung auch bei anderen Taktraten funktioniert (auch wenn nicht das angekommen war, was geplant war - Controller Befehle statt MIDI Noten)

Ich bin hier auf potenziell mögliche Probleme gestoßen:AVR-Tutorial: UART – Mikrocontroller.net (Siehe: WICHTIGER HINWEIS 2)

Warum soll ich denn einen 328 nehmen? der Atmega8 reicht doch - an den kann ich ja auch einen Quarz anschließen. Mir geht es ja darum, zu verstehen, was da genau passiert. Genau genommen, bin ich ja nach wie vor in der "Arduino-Welt", weil ich den Atmega8 ja damit programmiert habe.

5

Dr-Mbogo:
... Controller Befehle statt MIDI Noten) ...

Ich habe mit dem AtMega8 noch nichts gemacht, aber spontan liest sich das wie eine Diskrepanz zwischen Programm und Fuses. Könnte das sein?

6

Hallo,

da ich mir erst in den letzten Tagen einen perfekt funktionierenden MIDI-2-CV Converter gebaut und selbst programmiert habe, kann ich nur sagen: „Das ‚nebenan‘ mit dem Quarz gesagte ist absolut richtig und wichtig“.

Mit dem internen Taktgenerator kann es (manchmal) zu fatalen Abweichungen kommen. Temperatur, Luftfeuchtigkeit, Jahreszeit, und all so ein Gedöns. Und jegliche Störung und Abweichung bringt dich nur immer weiter vom Verständnis des gesamten Paketes weg...

Mein o.g. erstes MIDI-Teil funktionierte sogar auf dem Winzling AT TINY 4313 anstandslos – jedoch auch hier NUR mit Quarz! Es muß also nicht unbedingt ein 328p sein, die kleinen Brüder (sofern sie eine UART Schnittstelle haben) funktionieren ebenso tadellos. Aber eben NUR mit Quarz. Ich habs noch nicht getestet, wie das mit anderen Quarzen als 16 MHz läuft. „Vielleicht“ mit 4, 8 oder ähnlichen ebenso. Jedoch kommt es eben AUCH darauf an, ob die notwendige Tolleranz von < 1% bei der Berechnung der tatsächlichen Übertragungsrate erreicht wird.

Da ich in diesem Zusammenhang letztens ebenso in genau diesem MIDI-Zusammenhang von Problemen bei „Softserial“ gelesen habe, bin ich abgeneigt, mit solch teilweise haarsträubenden Umgehungen des „Normalen“ zu jonglieren. Dafür fehlt mir die Zeit – und der Sinn. Nimm irgend einen Controller mit UART und 16 MHz Quarz ... und alles funktioniert wie geplant und gewünscht.

Gerade und besonders wenn es um die oben angeschnittene „Liveperformace“ geht, dann sind solche „Kleinlichkeiten“ sicherlich ausschlaggebend für einen gelungenen Auftritt.
Und ich spreche aus eigener Erfahrung :wink:

LG, Rudi

7

So sollte es zuverlässig funktionieren:

  • dem ATmega8 einen Quarz spendieren (z.B. 8 oder 16 MHz) + passende Keramikkondensatoren
  • die Fuses richtig setzen
  • die Programmierung entsprechend anpassen: Dem Programm muss ja "bekannt" sein, was der "Arbeitstakt" ist
8

"Uxomm" hat Recht! Nur SOO funktioniert es zuverlässig.

Okay, dass ich später vom Tiny 4313 abgewichen bin hat andere Gründe. Ich brauchte unter anderem ein paar freie und "zusammenhängende" Ports, die in meinem Fall nur ein Mega 1284 liefern konnte. "Eigentlich" mehr als "Oversized", aber speziell für die Ausgabe von "Pitch" und "Velocity" und ein paar andere "Spielereien" für einen DAC brauchte ich das dann doch. Und zwei freie, zusammenhängende Ports liefert noch nicht mal ein 328p.

Aber generell würde ich bei so etwas heiklem nicht auf einen Quarz verzichten. Schon gar nicht bei der Taktrate von 31250 Baud innerhalb der MIDI-Geschichte.

LG, Rudi

9

Erstmal ganz liebes Dankeschön an euch alle!

Inzwischen hat es "KLICK" gemacht! Das Stichwort lautet: "Bootloader". Den hatte ich bei meinen Projekten nie wirklich beachtet und auch nie gebrannt. (Erlich gesagt hat der mich auch nie Interessiert, weil es ja auch so immer geklappt hat). Nachdem ich nun den Bootloader mit der Einstellung "internal 8MHz" gebrannt hatte, hat der AtMega8 auch ganz brav die MIDI Noten gesendet.

Ich vermute folgendes (und da haben agmue und uxomm voll ins Schwarze getroffen): Die Fuses werden wohl erst durch das Brennen des Bootloaders richtig gesetzt. Wenn ich unter "Werkzeuge / Clock nur die Einstellung vornehme ohne danach den Bootloader zu brennen, dann sind die internen Register des Atmega8 vermutlich noch nicht vollständig gesetzt.

Ich mache gleich noch einen kleinen "Test". Fön auf den Atmega und einen RICHTIG heißen Sommer simulieren. Mal sehen, was passiert... :slight_smile:

10

(deleted)

11

Dr-Mbogo:
Die Fuses werden wohl erst durch das Brennen des Bootloaders richtig gesetzt.

Richtig, wird in der IDE leider nicht erwähnt.

Wenn ich "ATmega8" als Board in der IDE habe, kann ich zwischen Bootloader "Ja" und "Nein" wählen. Bei "Nein" wird eine leere Datei als Bootloader verwendet. Ob man damit etwas gewinnt (schnellerer Start, mehr Speicher), vermag ich aber nicht zu sagen, beim ATtiny85, den ich verwende, ist das so.

12

Inzwischen habe ich einen kleinen Testaufbau, bestehend aus dem Atmega8, einem Taster und einer MIDI Buchse gemacht. Das ganze habe an den Rechner angeschlossen, dann über den Taster ordentlich Noten gesendet und mit MIDIox ausgewertet. Ich habe den ATmega ca. eine Minute lang mit dem Fön drangsaliert! Ergebnis: Der Chip hat die ganze Zeit funktioniert. Es gab keine Aussetzter oder irgenwie komisch veränderte MIDI Noten. Der interne Oszillator scheint zuverlässiger zu sein, als allgemein behauptet...

Gestern hatte ich nochmal einen kleinen Versuch mit dem 16MHz Quarz und den falschen Kondensatoren (100nF) gemacht. Den Bootloader habe ich zwar (warum auch immer) ohne Fehlermeldung aufspielen können - danach ging aber gar nichts mehr. "Yikes! Invalid Device Signature..." Mit etwas "Starthilfe" über Pin9 und dem ISP2 konnte ich den Chip aber wieder zum Leben erwecken!

Es gibt da immer noch eine ganze Menge Wissenslücken bei mir. Vielleicht könnt Ihr mir ja dabei helfen, diese etwas zu verkleinern... Wenn ich das alles richtig verstanden habe, dann braucht man den Bootloader unbedingt - richtig? Er braucht nur einmal aufgespielt werden. Da ich das bei meinen ganzen Experimenten aber nie gemacht habe, muss ich davon ausgehen, dass ab Werk schon einer auch dem Chip war, oder? Aber das wäre schon sehr ungewöhnlich. Kann es sein, dass die IDE den Bootloader - wenn nicht vorhanden - automatisch aufspielt? Oder braucht man den Bootloader doch nicht? Immerhin habe ich mich darum ja nie gekümmert!

Fragen über Fragen...

Besten Dank im Voraus, schönes Wochenende Euch allen und ganz liebe Grüße
Chris

13

Da ich den ATmega8 nicht habe, bilde ich eine Analogie zum ATtiny85.

Dr-Mbogo:
Wenn ich das alles richtig verstanden habe, dann braucht man den Bootloader unbedingt - richtig?

Nein. Die IDE vereinigt nur Bootloader brennen und Fuses setzen unter einem Menüpunkt. Im Verzeichnis1) \hardware\MiniCore\avr\bootloaders\empty\ findest Du die Datei empty.hex mit einem leeren Bootloader2). In der Datei \hardware\MiniCore\avr\boards.txt steht:

[sup]# Bootloader select
8.menu.bootloader.true=[color=blue]Yes[/color]
8.menu.bootloader.true.upload.maximum_size=[color=blue]7680[/color]
8.menu.bootloader.true.upload.protocol=arduino
8.menu.bootloader.true.bootloader.bootrst_bit=0
8.menu.bootloader.true.bootloader.file=optiboot_flash/{build.mcu}/{build.f_cpu}/optiboot_flash_{build.mcu}_{upload.port}_{upload.speed}_{build.f_cpu}.hex

8.menu.bootloader.false=[color=blue]No[/color]
8.menu.bootloader.false.upload.maximum_size=[color=blue]8192[/color]
8.menu.bootloader.false.bootloader.bootrst_bit=1
8.menu.bootloader.false.bootloader.file=empty/empty.hex [/sup]

Ohne Bootloader stehen Dir ein paar mehr Bytes für Dein Programm zur Verfügung.

Dr-Mbogo:
Er braucht nur einmal aufgespielt werden.

Ja, aber auch immer dann, wenn Du mit der IDE die Fuses ändern mußt, weil Du beispielsweise einen anderen Takt verwenden möchtest.

Dr-Mbogo:
... muss ich davon ausgehen, dass ab Werk schon einer auch dem Chip war, oder?

Das gibt es sowohl als auch, wobei die mit Bootloader eventuell teurer sind.

Dr-Mbogo:
Kann es sein, dass die IDE den Bootloader - wenn nicht vorhanden - automatisch aufspielt?

Nein.

Dr-Mbogo:
Oder braucht man den Bootloader doch nicht?

Nach Reset fragt der Bootloader an der seriellen Schnittstelle, ob ein neues Programm geladen werden soll. Das ist eine Komfortfunktion, um Programmiergeräte überflüssig zu machen. Bei UNOs/Nanos/ProMinis/Teensys/ESP32 nutze ich die immer, bei ATtiny85/45/4313 wegen Speicherknappheit nie.

Anm.:

  1. Ich verwende MiniCore.
  2. Man könnte auch formulieren, es gibt immer einen Bootloader, nur mal hat er eine Funktion und mal ist er leer.
14

Der interne Oszillator scheint zuverlässiger zu sein, als allgemein behauptet...

Bedenke:
Manche Annahmen sind so dermaßen falsch, dass noch nicht einmal das Gegenteil richtig ist.

15

Inzwischen habe ich nochmal ganz von vorne angefangen und bin nun verwirrter als jemals zuvor. Vielleicht könnt ihr mir ja ein bisschen helfen?

Wenn ich das richtig verstanden habe, dann kann man die Fuses eines µC innerhalb der Arduino Welt nur mit dem aufspielen des Bootloaders ändern - richtig? Das habe ich gemacht. Für Experimentalzwecke habe ich den Atmega8 mit einem 16Mhz Quarz ausgestattet und das Standard Blinkprogramm über einen Arduino Uno als ISP Programmer aufgespielt. Die LED leuchtet nun permanent. In einem weiteren Schritt habe ich den internen Oszillator 1Mhz aktiviert. Hier blinkt die LED nun so wie sie soll. Warum blinkt die LED nicht, wenn ich den 16Mhz Quarzoszillator aktiviere? Kann ein Quarz kaputtgehen? Kann man das irgendwie testen?

16

Wenn du die Fuses auf den Betrieb mit Quarz eingestellt hast, der Quarz aber kaputt ist, dann kommst du da per ISP Programmierung, oder Bootloader, nicht mehr dran. Nicht ohne zusätzliche Klimmzüge.

Klarer:
Deine Problembeschreibung ist unvollständig, bis falsch.

17

combie:
Wenn du die Fuses auf den Betrieb mit Quarz eingestellt hast, der Quarz aber kaputt ist, dann kommst du da per ISP Programmierung, oder Bootloader, nicht mehr dran. Nicht ohne zusätzliche Klimmzüge.

Wenn ich die Fuses mittels Bootloader auf den internen Oszillator setze, dann blinkt die LED. Wenn ich die Fuses für den externen Quarz aktiviere, dann blinkt es nicht. Sobald ich wieder den internen Oszillator aktiviere, blinkt es wieder. Was meinst du mit "da kommst du per ISP Programmierung, oder Bootloader nicht mehr dran"? Wo komme ich nicht mehr dran? An die Programmierung? Das geht! Sonst könnte ich den Blink Sketch ja nicht aufspielen.
Warum ist meine Problembeschreibung falsch? Das ist meine Sicht der Dinge; so wie ich das Bauteil erlebe und mit meinen begrenzten Kenntnissen zu beschreiben versuche.

18

Für die die ISP Programmierung benötigt ein jeder Atmel AVR einen Takt.
Wenn also die ISP Programmierung funktioniert, dann ist der Takt da.
Wenn du also die Fuses auf auf Quarz eingestellt hast und ISP noch funktioniert, dann ist dein Quarz am schwingen.

Das ist eine Kausalkette, die du dir zu Herzen nehmen solltest.
Jeder Versuch was anderes anzunehmen führt schnurstracks ins Versagen, in den Irrtum.
So ist es auch im Datenblatt, klipp und klar, aufgeführt.

Warum ist meine Problembeschreibung falsch?

Weil sie nicht mit der eben genannten Kausalkette in Übereinstimmung zu bringen ist.

Das ist meine Sicht der Dinge; so wie ich das Bauteil erlebe und mit meinen begrenzten Kenntnissen zu beschreiben versuche.

Ich befürchte, du wirst deine Sicht auf die Dinge modifizieren müssen, um die wahren Probleme zu finden.

Leider kann ich dir dabei nicht helfen.
Denn der Schaltplan ist geheim und auch deine Fuses Einstellungen.
Selbst, was du in der IDE auswählst, ist mir unbekannt.

Außerdem wurde in diesem Thread, zum Takt, schon so ziemlich alles gesagt

19

Danke für deine Ausführungen Combie,

inzwischen ist mir die Sache klar geworden. Es lag einfach nur am Quarz, der vermutlich etwas zu viel Wärme beim Einlöten abbekommen hat. Nachdem ich ihn nun getauscht habe, läuft alles wieder bestens.

Besten Dank und viele Grüße

20

Fein!
Auch wenn ich es noch nicht verstehen kann.
Denn die Kausalkette hat weiterhin ihre Gültigkeit.