Anregungen zur Projekt-Pflege

Software
1

1 . Code-Aufteilung in thematische Projektdateien
Das Projekt wächst und wächst (Yay! :star_struck:), aber gleichzeitig wird der Code immer unübersichtlicher. Ich möchte daher vorschlagen, den Code sinnvoll aufzuteilen:

Tonuino.ino              //Zentraler Code, der die eigentliche TonUINO-Funktionalität ausmacht und die folgenden Dateien einbindet
Tonuino_Config.ino       //Konfigurationsmöglichkeit für den normalen Anwender (ButtonMode, Lautstärke Min/Max/Start, ...)
Tonuino_Admin.ino        //Alles, was das Admin-Menü betrifft
Tonuino_Modes.ino        //Alle Modifier-Klassen mit ausführlichen Erläuterungen (!), was diese jeweils genau tun
Tonuino_Rfid.ino         //Karten lesen und schreiben
Tonuino_Declarations.ino //Für alle structs, vars, etc.

Ein normaler Anwender sollte dann nur die (gut kommentierte) Config-Datei bearbeiten, worauf in der Readme hingewiesen wird.
Die Rfid- und Declarations-Dateien werden von den meisten nicht angerührt werden.
Funktionale Anpassungen werden dann in den restlichen Dateien durchgeführt.

2 . Unterschiedliche Bautypen
Aktuell gibt es eine Compiler-Direktive, um zwischen 3 und 5 Knöpfen zu unterscheiden (#define FIVEBUTTONS). Ich finde das nicht so gut lesbar und außerdem gibt es noch andere Bautypen. Diese sollten in einem Enum definiert werden und anschließend im Code mit case oder if/else unterschiedlich behandelt werden.

enum ButtonMode {
  THREE_BUTTONS,          //Play, Next Track / Volume Up, Previous Track / Volume Down
  FIVE_BUTTONS,           //Play, Next Track, Previous Track, Volume Up, Volume Down
  THREE_BUTTONS_REVERSE,  //Play, Volume Up / Next Track, Volume Down / Previous Track
  THREE_BUTTONS_WITH_POTI //Play, Next Track, Previous Track, Volume by Potentiometer
};

In der Tonuino_Config.ino kann der Anwender dann mit einer Zuweisung festlegen, wie sein TonUINO gebaut wurde.

3 . Sprache der Kommentare und Logs
Aktuell sind Kommentare und Logs teilweise auf Englisch und teilweise auf Deutsch. Ich handhabe es normalerweise so, dass sämtliche Kommentare auf Englisch sind, selbst wenn es aktuell nur ich selbst oder deutsche Programmierer lesen - man weiß ja nie, was in der Zukunft kommt.
Ich kann mir gut vorstellen, dass der TonUINO ab einem gewissen Reifegrad auch international Bekanntheit erlangt. Da sollte der Code schon von allen lesbar sein.

2

Du schreibst so viel darüber, dann mach mal das aus dem aktuellen DEV und stell es zur Verfügung, damit wir es probieren und uns das anschauen konnen.

Danke

3

Das wurde gemacht um Speicherplatz zu sparen. Durch die ifdef abfrage wird alles was nicht gebraucht wird schon durch den Precompiler gefiltert.

4

Ganz genau. Und wir können auch nicht jeden Bautyp offiziell supporten. Wo fängt man an, wo hört man auf…

5

Also ich finde die Idee im Grunde nicht so schlecht.

Andererseits finde ich den Code noch nicht so komplex und riesig, das es schon unbedingt Sinn machen würde.

Es haben schon einige Laien es hinbekommen, die noch nie was mit einem Arduino oder löten zu tun hatten, deswegen finde ich man muss man nicht für Alle alles auf dem Silbertablett servieren.
Ein wenige Eigeninitiative, wenn man was abseites der Norm bauen möchte, sollte dann schon drin sein.

Es würde auch noch schwerer werden hier support zu geben, wenn man nicht alle Parameter schon serviert bekommt…

hmm schwierig.

6

Die ButtonMode-Geschichte kann ich gerne machen, wenn denn absehbar wäre, dass das auch ins Projekt übernommen wird. Sonst macht der Aufwand ja keinen Sinn.
Und wenn ich das Projekt ungefragt komplett neu strukturieren würde, wäre Thorsten sicherlich sehr erfreut beim Riesenpullrequest. :wink:
Nichts für ungut, aber manche Sachen gehören vorher besprochen und abgestimmt. :slight_smile:

Ich verstehe die Funktionsweise von Compiler-Direktiven, aber ich hätte nicht gedacht, dass ein paar Befehle eine relevante Datengröße ausmachen. Ich habe zugegebenermaßen keinerlei Arduino-Erfahrungen und kann die Größenverhältnisse daher nicht wirklich abschätzen. Ich weiß nur, dass der Code mit Compiler-Direktiven schwerer lesbar ist und es hier nur um sehr wenig unterschiedlichen Code geht. Aber wenn es dennoch wichtig ist, könnte man die unterschiedlichen ButtonModes natürlich auch so lösen.

Es geht ja nicht um hunderte Bauvarianten, sondern nur um die gängigsten Steuerungen. Ich glaube, die vier Varianten decken das gut ab. 3 und 5 Buttons sind ja sowieso schon vorhanden und wenn man sich die Projekte der Nutzer hier so anschaut, ist doch immer wieder ein Drehknauf zur Lautstärkesteuerung zu sehen (siehe auch Lautstärke über Drehregler mit 95 Beiträgen von 31 Nutzern). Warum sollte man diese offensichtliche Lautstärkeregelung nicht offiziell unterstützen? Klar, jeder kann die entsprechenden Stellen selbst anpassen (ist in dem Fall ja hauptsächlich Code auskommentieren), aber warum nicht einfach als offizielle Variante mit einer Einstellung verfügbar machen?

7

Letztendlich kann man vermutlich nur testen, ob das einen relevanten Unterschied macht oder nicht. Generell ist der Code natürlich kürzer, wenn keine Branches entstehen, indem diese durch den Präprozessor vermieden werden.

Ein weiterer Versuch wäre, dass du die entsprechenden Config-Variablen als konstant definierst (werden ja im Code nicht noch mal geändert). Ich weiß gerade nicht welche Optimierungsstufe in der Arduino-Umgebung eingestellt ist, ich hoffe aber mal, dass es auf Platz-Optimierung ausgelegt ist. Im Regelfall sollte der Compiler if mit konstanten Abfragen wegoptimieren, sodass im Grunde ein äquivalenter statischer Code wie mit Präprozessorabfragen entstehen sollte.
Wie gesagt, alles Theorie, letztendlich entscheiden kann man es vermutlich nur durch ausprobieren und vergleichen.

8

Bei den 3 Zeilen für die ollen 5 Buttons macht es ein paar byte aus. Aber ein paar byte hier ein paar byte da und ruck zuck is der kleine Flash voll. Ich habe in meinem Fork (eigentlich rewrite) alle extra Funktionen über Compiler Direktiven ausschaltbar gemacht. Zum einen weil ich selber bestimmte Funktionen gar nicht gut finde (5 Buttons z.B.) und zum anderen weil es echt Platz spart (s.u.).

// uncomment the below line to enable five button support
// #define FIVEBUTTONS

// uncomment the below line to enable ir remote support
// #define IRREMOTE

// uncomment the below line to enable pin code support
// #define PINCODE

// uncomment the below line to enable status led support
// #define STATUSLED

// uncomment the below line to enable low voltage shutdown support
// #define LOWVOLTAGE

Bei IRREMOTE lassen sich so z.B. 20% Codegröße einsparen. Das ist viel. Bei den anderen Funktionen natürlich weniger. Aber so kann jeder bestimmte Optionen deaktivieren und den freien Flash für eigene Sachen verwenden. Es ist einfach illusorisch eine FW zu stricken die alles kann. Dafür sind die 32kb (minus Bootloader) einfach zu wenig.

Obwohl ich sehr tief drin Stecke, kann ich nicht für Thorsten sprechen. Aber in der Regel kann ich aus Erfahrung sagen, werden solche Riesenumbauten nicht gemerged. Würde ich bei mir im übrigen auch nicht machen.

Stimme ich zu. Habe bei mir konsequent im Code alles auf Englisch weil ich es so auch gewohnt bin. Doku dann zweisprachig. Aber da kommen wir sicher irgendwann hin.

1 „Gefällt mir“
9

Macht es so viel Aufwand? Ich weiß es nicht, daher frage ich.
Wenn die ‘Macher’ oder ein Teil dieser, des TonUINO schon degegen sind, aus welchen Gründen auch immer, kannst du es nur für dich machen.

Aber mich hätte das schon interressiert wie groß oder klein das Image dadurch geworden wäre.
Aber auch dein Beitrag hat wieder in die Denkweise der ‘Macher’ etwas Licht gebracht.
Danke

10

Es ist halt alles eine Frage von Zeit. Leider habe ich da viel zu wenig von. Ich bin schon sehr froh jetzt endlich die neue Version so gut wie fertig zu haben. Als nächstes würde dann ein kompletter Rewrite anstehen. Die aktuelle Codebase ist - wie sagt man so schön - “historisch gewachsen”.

11

So schlimm ist es ja zum Glück noch nicht:

kyle_blog_pic
kyle_blog_pic.png1048×797 327 KB

(Von bonkersworld.net)

:wink: Aber im Ernst, hier sind Leute im discourse, die dir sehr gerne dabei behilflich sind. Ich für meinen Teil würde auch codetechnisch was beisteuern. Habe aber genauso wie OP die gleichen Hemmungen viel Zeit und Energie aufzuwenden, die dann aber vergeblich sind, weil es mit deiner Arbeit kollidiert oder ähnliches…