verfolge seit einem Jahr das Projekt und habe nun meinen ersten hektisch blinkenden Prototyp auf dem Tisch liegen. Der Einstieg hat Spaß gemacht. Bestellen - Zusammenbauen - Software reinladen - Läuft. Vielen Dank für dieses Frust-freie Projekt.
Nun möchte ich gerne eigene Ergänzungen testen und Umsetzen und habe mich gefragte, auf welchen GitHub Fork man am Besten aufsetzt.
Habe schon einige der über 250 Forks gesichtet und bin mir zunehmend unsicher auf welches Pferd man für eigene Erweiterungen setzten soll.
Es gibt Forks mit…
sauber aufgeräumten und konsequent umgesetzten #defines
Einem klar strukturierten Konfigurationsbereich
Request zur besseren Strukturierung / Lesbarkeit des Codes
Option für Lautstärke über ein Analog Poti
Option für Lautstärke über Encoder
Menüauswahl über einen Drehschalter
Tasteninvertierungen
Alternativen Tastenbelegungen
Echtzeituhr Unterstützung
Wecker und / oder Adventskalender
Pause wenn Karte weg
Autoabschaltung und Tiefschlafmodus
Debug-Ausgabe über #defines gesteuert
IR Remote Unterstützung
LED’s und Displays
…
Vieles spannende Features, von denen auch einige dem Original ganz gut tun würden, es aber leider nicht rein geschafft haben.
Seisfeld hat unheimlich aufgeräumt, schön mit Prototypen, ENUMs für diverse Stati eingeführt, einen klaren Konfigurationsbereich im Code deklariert und auch sonst viel implementiert. Gefällt mir. Fast mein Favorit. Nur leider den Ansatz von Thorsten mit dem Modifier Object gegen verschachtelte CASE Anweisungen getauscht. Somit wieder ein komplett entkoppeltes Ding. Schade eigentlich. @stephan:
Gibt es einen Grund, warum du die #defines gegen consts getauscht hast?
Aus welcher Not hast du die Modifier Class geopfert? Schien mir ein klar strukturierter und transparenter Ansatz.
Jetzt suche ich das Repro, das viele Funktionen übernommen hat und gut gepflegt ist, damit man sich seinen individuellen Mix nicht erst zusammen suchen muss.
Vielleicht verstehst du dann besser, warum viele Features nicht in das Original übernommen werden.
Marco’s Affenbox Fork und die Always Queue-Variante von @Thomas-Lehnert (der gerade erst mit Git anfängt, trotzdem der Vollständigkeit halber sein Fork) sind 2 ziemlich umfangreiche Forks. Beide kämpfen aber auch schon mit dem auf dem Nano verfügbaren Speicher. Beide haben ihren Fork auch schon optional an die neue AiO-Platine angepasst.
danke, vor dem zeitlichen Verlauf ergibt sich dann ein ganz anderes Bild. Würdest du das mit den const heute auch noch so machen? Ich hatte den Eindruck, dass die #defines für solche Festlegungen weiter verbreitet sind. Hat das mit den const einen signifikanten Vorteil, oder ist das auch der zeitlichen Entwicklung geschuldet?
Wenn du eigene Erweiterungen einbauen willst, warum nimmst du dann nicht das Original?
Das Grundproblem der Software, ist die Unübersichtlichkeit und die vielen Abhängikeiten der Methoden voneinader, sowie sehr viele globale Variablen. Das erfordert einiges an Einarbeitung.
Das Problem in meinem Fork ist meine Zeit dafür.
Deshalb gehe ich meist den schnelleren Weg und versuche es halbwegs übersichtlich zu halten.
Hat zur Folge, das ich oft Funktionen aus anderen Forks kopiere und hier und da der Programmierstiel nicht einheitlich ist.
Platzprobleme habe ich auch, wenn die seriellen Ausgaben aktiv sind. Sonst eigentlich nicht.
Spoiler Alarm: ich habe nun wieder etwas mehr Zeit für die Software und strebe einen komplett anderen Ansatz an.
Alles soll Modular werden, dadurch sollen eigenen Änderungen wie z.B. ein komplett einender Wiedergabemodus, LEDs, Displays, … einfach eingebaut werden können.
Allerdings wird es auch für Einsteiger schwieriger und es wird schon etwas mehr C++ Know How vorausgesetzt (Interfaces, pure virtual functions, Oberserver Pattern, …)
Der Vorteil von Defines ist halt, dass man sie auch ausserhalb des Codes (z.B. in einem Makefile) setzen kann. Sprich wenn wir in Zukunft binäre Firmware anbieten (dank dem Mega Webuploader den Stephan ins Leben gerufen hat!) können auf einmal alle Varianten der Firmware gebaut werden, jeweils mit den nötigen Defines.
Ich will mich hier nicht streiten was besser is. Zum Code Path Switching machen defines natürlich absolut Sinn wie Thorsten richtig schreibt. Für Konstanten nutze ich lieber const.
@Gute_Laune:
Diese „halte es einfach“ Philosophie hinter der Box finde ich super. Mit der App von Marco und dem FW Download über den Browser ist es genial und einem breiten Publikum zugänglich. Daher macht die eierlegende Wollmilchsau als Hauptversion gewiss keinen Sinn. Ich hatte gehofft, dass es irgendwo eine Tüftlerversion mit allen Extras gibt. Marcos Version war bisher mein Favorit, aber ich muss zugeben, die von Thomas sieht auch spannend aus. Danke für den Tipp.
Weil dein Fork schon verdammt nah dran ist, an dem was ich brauche. Den habe ich aktuell im Einsatz. Weil flexibel. Sowohl funktional, als auch im Hinblick auf Namenskonventionen ;o). Ich kam nicht umhin es zu bemerken. Habe zunächst auf Persönlichkeitsspaltung getippt. Aber der Faktor Zeit ist ein Argument.
@stephan Werde ich mir mal anschauen. Weil Marco es mit dem Copy & Paste Problem gerade angesprochen hat. Gibt es unter Arduino Nutzern eine anerkannte Konvention, wie man const, defs, ENUMS usw. schreibt. Habt Ihr euch hier in der Community eine auferlegt? Kam beim Sichten der Forks immer wieder ins Schlingern, weil es gefühlt jeder anders macht.
@Thorsten: Klingt viel versprechend. Welche Entwicklungsumgebung nutzt du da?
Vielen Dank in die Runde, für die schnellen und aufschlussreichen Antworten und gute Nacht.
Meinst du Thorsten’s Spoiler?
Richtige IDE ist ja auch relativ.
Die Arduino IDE ist eigentlich keine gute Entwicklungsumgebung.
Eher ein schlechter Texteditor mit Kompiler und Seriellem Monitor.
@Nick-Spick
Was Thorsten da nutzt ist PlatformIO, eine Erweiterung für Microsoft VSCode.
Nein ist komplett frei.
Linux Version müsstest du schauen. Ich finde das ganze Ding aber alles andere als überschaubar.
Ich als Autodidakt tue mir mit dem Ding scheiß schwer.
Ich hab mir platformio auch installiert, muss mich da aber auch erst mal reinwurschteln. Aber schon allein die Darstellung des Codes ist um längen besser als in der Arduino IDE. Der Code wird schon textmäßig viel übersichtlicher formatiert. zB. durch das setzen der Tabs für die einrückungen, so dass man zB. auch schön sehen kann welche Klammerpaare zusammengehören.
