Datenschutz / Privacy Policy

für die App „Spielblock“ / for the app „simple score sheet“

English

No personal data are acquired by the app. All data entered by the user  (game results) are stored on the device only. All data are deleted by uninstalling the app. There app does not transfer any data. The app does not need any permissions.

Deutsch

Es werden keine persönlichen Daten erfasst. Alle vom Benutzer eingegebenen Daten (Spielergebnisse) werden nur auf dem Gerät gespeichert. Diese werden gelöscht, wenn die App deinstalliert wird. Ein Datentransfer findet nicht statt. Die App benötigt keine Berechtigungen.

Veröffentlicht unter Allgemein | Hinterlasse einen Kommentar

MIDI für Kirchenorgel – 6

Debugging

Obwohl die Entwicklung gut vorwärts ging, ergaben sich durch die zunehmende Komplexität einige hartnäckige Probleme. Die Anbindung der Manuale an die Midi-In- und Midi-Out-Anschlüsse funktionierte zuverlässig, auch die Wiedergabe komplexer Midi-Dateien auf der Orgel lief störungsfrei, jedoch gab es dabei Fehlermeldungen, dass der MIDI-Out-, teilweise auch der In-Buffer überlief. Dies war sehr irritierend, da man keine fehlenden Töne oder Latenzen hörte; eine Vergrößerung des Puffers auf 256 Byte brachte nichts. Zunächst vermutete ich einen Fehler in der Puffer-Verwaltung.

MIDI-Buffer

Als Ring-Puffer dient ein Byte-Array midiTxBuffer[] mit den Indizes midiTxInIndex (zeigt auf nächste Position zum Schreiben in den Puffer) und midiTxOutIndex (zeigt auf die nächste aus dem Puffer auszugebende Byte. Anfangs sind beide Indizes Null; gleicher Wert für beide zeigt, dass nichts auszugeben ist.

Das Schreiben erfolgt in serial1MIDISend(). Der Index midiTxInIndex wird nach dem Schreiben erhöht. Durch die Und-Verknüpfung mit MIDI_TX_BUFFER_MASK wird der umlaufende Index immer im Rahmen der Arraygröße (die ergo eine 2er-Potenz sein muss) gehalten. Erreicht dieser Schreib-Index jedoch den Ausgabe-Index midiTxOutIndex sozusagen „von hinten“, so liegt ein Überlauf vor. In dem Fall wird der Index nicht erhöht, da sonst der komplette Puffer-Inhalt „gelöscht“ wäre. Falls danach noch ein Byte mit serial1MIDISend() gesendet würde, würde dies das vorige überschreiben (d.h. der Überlauf wird signalisiert, wenn er nur droht, ein Byte „Reserve“ gibt es noch.

void serial1MIDISend(uint8_t data) {
...
midiTxBuffer[midiTxInIndex] = data; 
uint8_t newIndex = (midiTxInIndex+1) & MIDI_TX_BUFFER_MASK; 
if (newIndex == midiTxOutIndex){
    // notify overflow to main by global var
    ...
} else {
    // no overflow
    midiTxInIndex = newIndex;
}
UCSR1B |= (1 << UDRIE1); // Interrupt einschalten für "Senderegister leer"
}

Mit dem Schreiben von UCSR1B wird der Interrupt freigegeben, der ausgelöst wird, wenn das Senderegister leer ist, d. h. nach einem erfolgreichen Sendevorgang. Ist das Senderegister jetzt bereits leer, so wird der Interrupt sofort ausgelöst, falls noch ein Sendevorgang läuft, dann eben etwas später. Die eigentliche Interrupt-Senderoutine sieht dann so aus:

ISR(USART1_UDRE_vect) {
    if (MIDI_TX_BUFFER_NONEMPTY){
        // there ist a byte to sent 
        UDR1 = midiTxBuffer[midiTxOutIndex];
        midiTxOutIndex = (midiTxOutIndex+1) & MIDI_TX_BUFFER_MASK;
        ...
    } else {
        // nothing to send
        UCSR1B &= ~(1 << UDRIE1);
        // Interrupt abschalten - wird in serial1MIDISend wieder gesetzt
    }
}

War in diesem selbst entworfenen Konzept, das ohne jedes Warten in while-Schleifen auskommt, fehlerhaft. Ich konnte bei der Analyse keinen Fehler finden und wandte mich einer anderen Möglichkeit zu.

LCD-Interface

Bereits bei der Entwicklung war mir die aus dem Internet übernommen Routine zur Ansteuerung des LCDs nicht sehr sympathisch. Zur Realisierung des Timings der recht langsamen Schnittstelle zum HD44780-kompatiblen Controller werden vielfach wait()-prozeduren verwendet, die zwar die Interrupt-Verarbeitung nicht blockieren, aber alles was im Hauptprogramm läuft, also v. A. die Verarbeitung des Midi-Eingangs und die Reaktion auf Tastendrücke etc. Allerdings dauert das Schreiben eines Zeichens nur ca. 0,1 ms – das schien ein zu vernachlässigender Wert zu sein. Allerdings wird wegen jeder empfangenen und gesendeten Noten-Information das Display aktualisiert, bei komplexen Stücken könnte das dann doch etwas mehr sein.

Leider erlaubt das einfache Debugging per JTAG keine Echtzeit-Analyse, oder eine Art Profiler, wie lang die CPU in bestimmten Prozeduren läuft. Zur Analyse nutzte ich daher (typisch für solche Mikrocontroller) einige der zahlreichen unbenutzen Port-Pins. Diese werden in bestimmten Routinen auf 1 gesetzt und danach wieder auf 0. Die gelbe Linie gibt die Zeit in der LCD-Routine wieder, blau ist die MIDI-Verarbeitung in main()

Die Sache schien also klar: die CPU ist zu sehr mit der Ausgabe auf dem LCD beschäftigt. Im Log zeigten sich dann massiv Fehlermeldungen, teilweise mehrmals pro Sekunde:

Oben Statuszeile: links: empfangene Note, Mitte: Betriebszeit (und „E“ für Fehler), rechts: gesendete Note
2. Zeile: Menü, 3. Zeile: Text zum Menüpunkte (hier Logeintrag), 4. Zeile: Bedeutung der 4 Softkeys.

Also reduzierte ich die Häufigkeit der Aktualisierung der empfangen bzw. gesendeten Noten in der Statuszeile auf 0,7 Sekunden. Damit waren fast alle Overflows verschwunden – aber nicht alle!

Exakt im Sekundentakt, aber erst nach ca. einer halben Minute erschien weiter ein Overflow, offensichtlich wenn die Uhr aktualisiert wird. Dies dauert nach Messung mit dem Oszilloskop ein paar Millisekunden. In der Zeit müsste ein 256 Byte großer Puffer bei einer 31250-Baud-Schnittstelle (ca 3 Bytes pro Millisekunde) aber locker ausreichen! Im Normalfall sollte der Puffer ja kaum gefüllt sein, da pro Sekunde selbst in schnellen Stücken maximal 70 Note-On/Off Befehle à 3 Byte empfangen bzw. gesendet werden, und das dauert nur 21ms.

Also überprüfte ich zunächst die Verarbeitung einzelner Midi-Befehle und musste überrascht feststellen, dass durch eine falsche Einstellung in der Midi-Konfiguration jeder Befehl 3-fach ausgegeben wurde. Das erklärte eine hohe überflüssige Last, aber nicht den Überlauf.

Die Lösung lag in einer unscheinbaren Einstellung der Midi-Player-Software beim Testen:

Ich hatte versehentlich (dank Software, die nicht mit HDPI umgehen kann) einmal eine Schleife Midi-In-Out in der Software aktiviert. Da aber in meiner Schaltung/Software empfangene Midi-Befehle an die Manuale ausgegeben und dann aber sofort als Tastendrücke registriert werden, wird jedes eingegangener Note-On/Off-Befehl wieder an Midi-Out ausgegeben (sofern der Midi-Ausgang aktiviert ist). Ergebnis ist eine Endlosschleife, die tatsächlich erst durch den Puffer-Überlauf unterbrochen wird! Nachdem ich den Menüpunkt im Player deaktiviert hatte, lief alles ohne Overflow!

Sicherheitshalber richtete ich noch eine Variable ein, in der die maximale Auslastung des Sende- und Empfangspuffers abgefragt werden kann. Sie liegt unter 5 Byte.

Veröffentlicht unter Allgemein, Mikrocontroller/Arduino | Hinterlasse einen Kommentar

MIDI für Kirchenorgel – 5

Einbau in die Orgel

So viele Platinen unterzubringen ist selbst in einen relativen „leeren“ Orgeltisch nicht ganz einfach. Wegen der besseren Zugänglichkeit bei Fehlersuche und Reparaturen entschied ich mich gegen ein Rack-Gehäuse zugunsten einer flachen aber ausladenden Anordnung fast direkt unter der rückwärtigen Wartungstüre.

Oben links ganz klein: Die Arduino-Mega-CPU mit aufgesetztem Expansion-Shield, rechts daneben der I/O-Verteiler zu den MOSFET-Platinen. Die lange Flachbandkabel führen von dort zu den Buchsenleisten, wo die Leitungen zur Orgel eingesteckt sind.
Weiterlesen
Veröffentlicht unter Allgemein | Hinterlasse einen Kommentar

MIDI für Kirchenorgel – 4

Meine erste „richtige“ Platine

Angesichts des hohen Verdrahtungsaufwands und der geringeren Zuverlässigkeit von Handverdrahtung auf Lochrasterplatinen war die Fertigung von Platinen unumgänglich. Weder hatte ich mich bisher ernsthaft mit Platinenentflechtung beschäftigt, noch hatte ich je welche fertigen lassen.

Weiterlesen
Veröffentlicht unter Basteln, Mikrocontroller/Arduino | Verschlagwortet mit , , , | 2 Kommentare

MIDI für Kirchenorgel – 3

Mikrocontroller und Systemarchitektur

Schon seit vielen Jahren arbeite ich in meiner Freizeit mit den CPUs von ATMEL (inzwischen übernommen von Microchip). Die Entwicklungswerkzeuge sind mir halbwegs vertraut, für üblichen Steuerungsaufgaben reicht die inzwischen angestaubte 8-bit-Architektur mit bis zu 20 MHz aus.

ATMEL CPUs, oben in der der bastelfreundlichen DIP-Ausführung, unten SMD
Von Springob – Eigenes Werk, CC BY 3.0, https://commons.wikimedia.org/w/index.php?curid=5054949

Warum ATMEL?

Ich habe in meiner Bastelkiste auch STM32, ESP8266, ESP32-Boards herumliegen. Diese sind viel leistungsfähiger, und teilweise mit WLAN besser an fortschrittliche Bedienung mit Smartphone und Tabletts anzupassen. Aber: sie haben zu wenige Ports (s.u.) und sind für mich bis auf einige „Hello World“-Projekte Neuland. Mit dieser Hypothek wollte ich so ein Großprojekt nicht zusätzlich belasten.

Weiterlesen
Veröffentlicht unter Basteln, Mikrocontroller/Arduino | Verschlagwortet mit , | Hinterlasse einen Kommentar

MIDI für Kirchenorgel – 2

Ansteuerung und Abfrage der Pfeifenmagnete

Für die Kirchenorgel sind 2 Ergänzungen der Funktionsweisen machbar. Ansteuerung der Pfeifen durch die Elektronik (z B. zur Realisierung eines MIDI-Eingangs) und Abfrage des Zustands der Tasten am Spieltisch (u. A. zur Weiterführung an den MIDI-Ausgang). Geschaltet und „gelesen“ werden müssen dabei die 12V, mit denen die Magnetventile gesteuert werden:

Schalten der 12V

Das Schalten der 12V könnte durch PNP-Tranistoren oder P-Kanal-Mosfets erfolgen (1)(2):

Weiterlesen
Veröffentlicht unter Basteln, Mikrocontroller/Arduino | Verschlagwortet mit , | Hinterlasse einen Kommentar

MIDI für Kirchenorgel – 1

Bei der Renovierung der Steinmeyer-Orgel meiner Kirchengemeinde hatte ich erstmals näheren Kontakt mit der Technik dieses Instruments. Anders als die historischen Kirchenorgeln (1), bei der Tastendrücke über mechanische Elemente die Ventile der Pfeifen betätigen, arbeitet dieses Instrument aus den 1950er Jahren mit elektrischen Schaltkontakten.

Weiterlesen
Veröffentlicht unter Basteln, Mikrocontroller/Arduino | Verschlagwortet mit , | Hinterlasse einen Kommentar

Resilio Sync auf dem Raspberry – 1: Software

Schon vor einigen Jahren habe ich dieses Programm auf dem Raspberry eingerichtet. Damals hieß es noch BTSYNC (abgeleitet vom verwendeten Bittorrent-Protokoll) und lief auf einem RP2 mit einer 64 GB-SD-Karte. Dieser Speicher wurde nun knapp. Da ich vor geraumer Zeit eine USB-HDD WD-RP-Drive mit 314GB gekauft habe, wollte ich diese nun einsetzen. Weil es einfacher und sicherer ist, wollte ich das System auf neuer Hardware neu aufsetzten, natürlich jetzt auf einem RP3

Ich suchte nach aktualisierten Anleitungen und musste leider feststellen, dass die Installation ein komplizierter Weg war, als ich erwartet hatte.

Der Anfang war noch einfach: RP3 mit Debian einrichten, SSH einschalten (damit man am PC arbeiten kann, wo auch Google verfügbar ist Zwinkerndes Smiley) Weiterlesen

Veröffentlicht unter Rasperry Pi | Hinterlasse einen Kommentar

Bei Kabeldeutschland arbeiten Idioten – nicht nur, aber zu viele!

Mein Kabel-Deutschland Problem war im Februar leider keineswegs behoben. Nach eine Router-Neustart war das Problem (DNS-Auflösung und/oder Routing mit 5-10 Sekunden viel zu langsam) oft kurzfristig gelindert, aber niemals beseitigt. Der Schweregrad schwankte zischen “lästig” und “unzumutbar”, so dass eine Fehlerdiagnose schwierig war, zumal wenn man ein Problem hat, dass aus dem Raster fällt. Dem entsprechend war es für die Mitarbeiter der Hotline kaum möglich, das Problem richtig in ihre Software einzugeben, geschweige denn dass eine Abhilfe möglich war.

Weiterlesen

Veröffentlicht unter Allgemein | Hinterlasse einen Kommentar

Neulich in der Autowerkstatt

Terminvergabe

Seit vielen Jahren bin ich Kunde einer Autowerkstatt eines großen lokalen Vertragshändlers. Nicht immer mit Zufriedenheit, aber wegen persönlicher Beziehungen und der räumlichen Nähe (500m) zu meiner Arbeitsstätte.

Da ich im Jahr zuvor bei der telefonischen Terminvereinbarung minutenlang in Warteschleifen hing und hin- und her vermittelt wurde, habe ich diesmal den Kontakt per Kontaktformular auf der Webseite hergestellt. Hier konnte man tatsächlich alles wichtige eingeben, also Kennzeichen, Fahrzeugtyp und Art des Termins, etc. Bei “Terminwunsch” habe ich die für mich passenden Wochentage und Bring- und Abholtermine angegeben.

Da man eine Telefonnummer (bei mir war das meine geschäftliche Nummer) angeben musste, war ich wenig überrascht aber doch nicht erfreut, dass ich dann einige Stunden später angerufen wurde – was mich dann eben oft aus einer wichtigen Arbeit reißt:

Weiterlesen

Veröffentlicht unter Allgemein | Verschlagwortet mit , | Hinterlasse einen Kommentar