PP-SS20-01/Fazit: Unterschied zwischen den Versionen

Aus Verteilte Systeme - Wiki
Zur Navigation springen Zur Suche springen
Zeile 21: Zeile 21:
 
= Probleme und offene Punkte =
 
= Probleme und offene Punkte =
   
Von der ursprünglichen Aufgabestellung sind keine Punkte übrig aber um den Sequencer wirklich produktiv einsetzen zu können wären noch einige Features mehr hilfreich.
+
Von der ursprünglichen Aufgabestellung sind keine Punkte übrig aber um den Sequencer wirklich produktiv einsetzen zu können wären noch einige Features hilfreich.
   
 
Beispiel für diese Features sind unter [https://wwwvs.cs.hs-rm.de/vs-wiki/index.php/PP-SS20-01/M%C3%B6gliche_Erweiterungen mögliche Erweiterungen] aufgeführt.
 
Beispiel für diese Features sind unter [https://wwwvs.cs.hs-rm.de/vs-wiki/index.php/PP-SS20-01/M%C3%B6gliche_Erweiterungen mögliche Erweiterungen] aufgeführt.
  +
  +
== Probleme ==
   
 
* Auf dem Developmentboard nRF52840 MDK ist es mir nicht gelungen auf den QSPI flash zuzugreifen, entsprechend ist es nur möglich sehr wenig auf dem Controller zu speichern. Damit ist Anzahl der Sequenzen und Steps für jede Sequenz recht beschränkt (8x255) und weitere Implementierungen bzw. Features die auf Speicher angewiesen sind nicht möglich zu implementieren (Polyphonie). Eine Lösung dafür sollte mit dem SDCard-Leser welcher per SPI angesprochen werden kann schon vorhanden sein, implementiert ist diese aber noch nicht.
 
* Auf dem Developmentboard nRF52840 MDK ist es mir nicht gelungen auf den QSPI flash zuzugreifen, entsprechend ist es nur möglich sehr wenig auf dem Controller zu speichern. Damit ist Anzahl der Sequenzen und Steps für jede Sequenz recht beschränkt (8x255) und weitere Implementierungen bzw. Features die auf Speicher angewiesen sind nicht möglich zu implementieren (Polyphonie). Eine Lösung dafür sollte mit dem SDCard-Leser welcher per SPI angesprochen werden kann schon vorhanden sein, implementiert ist diese aber noch nicht.

Version vom 31. Mai 2020, 15:38 Uhr

Fazit

Das Projekt ist in Hinblick auf die ursprüngliche Aufgabestellung erfolgreich abgeschlossen. Es gibt noch einige Punkte an denen in Zukunft weiter gearbeitet werden kann, das "Produkt" ist also noch nicht an seinem Entwicklungsende angekommen und hat viel Potential für Erweiterungen. Mit der Implementierung von Erweiterungen wurde im Anschluss an die fertig implementierten Ziele der anfänglichen Aufgabenstellung begonnen, unter anderem das Aufnehmen von MIDI-Eingaben über die MIDI-DIN Implementierung an 3.5mm TRS (Tip Ring Sleeve, auch als Stereo Klinke bekannt) sind schon ursprünglich nicht vorgesehene Funktionen.

Das Arbeiten an diesem Projekt war sehr angenehm, da ich weitestgehend freie Hand hatte und das Ziel von Anfang an klar war, und der Weg zum Ziel in diesem Fall ziemlich selbsterklärend ist. Aufgrund der Planung einer kleinen Schaltung für die Eingaben und der Umsetzung dieser auf ein PCB konnte ich gute Einblicke in die Erstellung von PCB's gewinnen, von der ersten Idee über die vielen Versionen bis eine endgültige (fürs erste) Platine dabei zum Vorschein kommt. Wobei insbesondere die vielen Stunden die in ein mehr oder weniger hübsches Routing von Leiterbahnen fließen anstrengend sind, besonders wenn man das Design anschließend fünf mal ändert und jedes mal alles neu Routen darf. Dabei durfte ich auch feststellen das die mir bekannten freien Autorouter ziemlich langsam für ungewöhnlich miserable Ergebnisse sind, das könnte aber auch an Einstellungsfehlern meinerseits liegen. Umso glücklicher war ich als es mir möglich war das fertige Produkt in den Händen zu halten und zumindest die Hardware ohne Probleme funktionierte, die Software nach ein paar Anpassungen aber auch.

Da ZephyrOS nicht direkt neu für mich war konnte ich mich recht zeitnah mit der eigentlichen Aufgabe beschäftigen, statt mich erst mit dem System vertraut machen zu müssen. Der einzige Moment an dem ich etwas weniger begeistert war ist als ein ursprünglich gelöstes Problem wieder auftauchte (Bytes auf dem TX Pin, siehe MIDI over BLE Projekt).

Auch aus diesem Projekt nehme ich mit dass viel mehr Zeit in die Vorbereitung fließen sollte besonders was die Planung von einzelnen Teilaspekten der Software angeht und deren Zusammenspiel. Das ist mir besonders beim erstellen der Bedienung aufgefallen, trotz einer erst einmal solide wirkenden Grundidee musste ich im Anschluss feststellen das mit etwas mehr Bedenkzeit so manches nicht drei mal hätte überarbeitet werden müssen.

Und das wichtigste was ich mitnehme ist einen festen Tag für das Dokumentieren und einfach noch mal über den aktuellen Stand, wie dieser zur ursprünglichen Planung steht und was sich geändert hat, einführen um einen besseren Überblick über das Projekt zu behalten und dessen Entwicklung. Somit kann ich mir beim nächsten mal eventuell die extra Tage sparen die effektiv nur in das Aufräumen von Code und Gedanken geflossen sind.

Probleme und offene Punkte

Von der ursprünglichen Aufgabestellung sind keine Punkte übrig aber um den Sequencer wirklich produktiv einsetzen zu können wären noch einige Features hilfreich.

Beispiel für diese Features sind unter mögliche Erweiterungen aufgeführt.

Probleme

  • Auf dem Developmentboard nRF52840 MDK ist es mir nicht gelungen auf den QSPI flash zuzugreifen, entsprechend ist es nur möglich sehr wenig auf dem Controller zu speichern. Damit ist Anzahl der Sequenzen und Steps für jede Sequenz recht beschränkt (8x255) und weitere Implementierungen bzw. Features die auf Speicher angewiesen sind nicht möglich zu implementieren (Polyphonie). Eine Lösung dafür sollte mit dem SDCard-Leser welcher per SPI angesprochen werden kann schon vorhanden sein, implementiert ist diese aber noch nicht.
  • Die ursprünglich geplanten Potentiometer haben sich als nicht optimal für die Bedienung herausgestellt, stattdessen werden aktuell Drehimpulsgeber genutzt. Diese haben bei der aktuellen Implementierung zwar noch minimale Probleme (gelegentlich mehr als ein Schritt erkannt) aber die Bedienung ist insgesamt angenehmer geworden.
  • Ungewollte Bytes auf dem UART Tx Pin aufgrund von BLE. Die Lösung dafür war die Nutzung des zweiten UART und UART1 auf ungenutzt Pins umzulegen, andere Möglichkeiten um das Problem zu beheben müssten weiter recherchiert werden.