Hardware Guide und kollaborative Anleitung auf GitHub

Liebe Community,

dem Aufruf auf der Webseite folgend,

Feedback geben, Bugs suchen, andere auf das Projekt aufmerksam machen
Am Quellcode weiterentwickeln

habe ich meine Erfahrungen beim Bau des ersten TonUINO genutzt, um die existierende, großartige Unterstützung (die offizielle Webseite, dieses Forum, Videos, …) aus meiner Sicht zu verbessern (das mag subjektiv sein und viele sind mit dem Status Quo bestimmt und zu recht sehr zufrieden).

Unter GitHub - AlexanderWillner/TonUINO: Die DIY Musikbox (nicht nur) für Kinder gibt es eine Anleitung, die auf diesen Quellen basieren, die gerne über Pull Requests verbessert werden kann. Wie auf der Seite beschrieben, ist das Ziel, dass das Ergebnis in die offizielle Dokumentation einfließt. Am Anfang habe ich duzende Forenbeiträge gelesen, bis ich die Informationen zusammen hatte, die mir wichtig waren. Ich möchte den Einstieg anderen erleichtern, die ggf. ähnlich wie ich „ticken“.

Zur Sicherheit nochmals: Das Repository ist als Angebot zu betrachten, kollaborativ über GitHub einen Schnelleinstieg zu erarbeiten und ist keine Kritik am aktuellen Stand der Dokumentation. Ich bin sehr dankbar für das Projekt und die Arbeit und möchte lediglich etwas zurück geben.

Viele Grüße, Alex

11 „Gefällt mir“

Hallo @alexander.willner,

vielen Dank für das Angebot - ich bin dabei. Die nächsten PRs werde ich in Deinem Repo einstellen - in der Hoffnung, dass wir dieses ausgezeichnete Projekt dort weiter voranbringen werden. Im Origin-Repo scheint es ja seit einiger Zeit eher konservativ zuzugehen und der Bedarf an Erweiterungen am Code eher gering zu sein - was ich hinsichtlich des Open-Source-Gedankens sehr bedauere.

Ich hätte auch gleich einen Vorschlag: Was hältst Du davon, wenn wir für die reinen Anwender die Firmware direkt als Binärfile anbieten - inkl. einer Anleitung, wie sie dieses File mittels Arduino IDE auf Ihre Geräte flashen können?

Viele Grüße
Thomas

Wenn ihr da den original Code debugged, für IDEs habt, Features mit Switches einbaut, etc, das wäre super.

Prima. Ich denke, es gibt einiges was verbessert werden kann und das Ziel sollte es sein, dass das Ergebnis wieder in das offiziellen einfließt. Kann dir auch einfach Schreibzugriff geben.

Alles was es für Anwender einfacher macht, ist denke ich willkommen. Bauchgefühl: Binaries zu installieren ist auch nicht einfacher/schwerer als den Quellcode kompiliert hochzuladen.

Ich denke, das sollte eines der Ziele sein.

Doch genau das hatte ich schonmal überlegt. Es geht über einen Menüpunkt in der IDE ganz einfach. Ob es aber soooo viel einfacher wird als die 5 Schritte in der Anleitung zu befolgen glaube ich nicht.

Ich hatte ursprünglich an einen Upload direkt mittels avrdude gedacht:

"avrdude -CC:avrdude.conf -v -patmega328p -carduino -PCOMxx -b115200 -D -Uflash:w:firmware.hex:i

Aber vermutlich ist das auch komplizierter als der Weg über die IDE.
Schade, dass diese Lösung hier scheinbar nicht mehr existiert: http://www.hobbytronics.co.uk/arduino-xloader

Ist im Makefile umgesetzt:

Denke eine GUI-basierte Installation sollte der Schwerpunkt sein.

@DerTomm: Wie könnte denn der Upload noch einfacher gestaltet werden, als in dem Video zu sehen ist, das unter TonUINO/README.md at DEV · AlexanderWillner/TonUINO · GitHub eingebettet ist?

Mit „einfacher“ war gemeint, den Anwender überhaupt nicht mit Dingen wie IDEs, Bibliotheken und Quellcode konfrontieren zu müssen, sondern einfach sagen zu können: Lade Dir dieses Archiv runter, führe diesen „Installer“ aus und schon hast Du die Firmware auf Deinem Gerät.

Allerdings muss man natürlich sagen: Für diejenigen, die sich einen Tonuino selber bauen, dürfte das „bisschen Arduino“ dann auch kein Problem mehr sein. Insofern: Das passt schon - und die Variante mit dem Makefile ist dann natürlich noch umso besser :slight_smile:

Hallo zusammen,

auch ich habe meinen ersten TonUINO gebaut. Ich bin leider fast „zu spät“ auf dieses tolle Projekt aufmerksam geworden, denn unsere Tochter ist schon 5 und hat eigene Ideen und Wünsche. Beim Versuch mich in den Code einzuarbeiten und vielleicht den einen oder anderen ihrer Wünsche umzusetzen habe ich zu allem Überfluss jetzt auch noch eigene Ideen und Wünsche an das Projekt entwickelt. :crazy_face:

Das Projekt ist großartig und ich begrüße die Entscheidung der Macher trotz einer neuen aio-Platine offen, frei und kompatibel zu allen Selbstbauvarianten zu bleiben. Danke für das tolle Projekt, das tolle Mindset und alles! :muscle: :sunglasses: :+1:

Jetzt zu meiner (hoffentlich konstruktiven) Kritik:

  1. Bitte die Änderungen von https://github.com/AlexanderWillner/TonUINO übernehmen. Hier wurde bereits an der Unterstützung von PlatformIO gearbeitet.
  2. PlatformIO ist ein reines Komandozeilentool, hat sich aber dicht an VSCode/Codium gehängt und bietet damit eine deutlich bessere Entwicklungsumgebung als die ArduinoIDE. Es wäre super, wenn diese IDE vom Projekt direkt unterstützt würde. Bitte nicht falsch verstehen: Je einfacher sich ein TonUINO ohne jede IDE nachbauen lässt, um so besser. Aber auf der anderen Seite sollte auch eine einfache Mitentwicklung am Source Code mittels PlatformIO und VSCode/Codium-IDE unterstützt werden.
  3. Mir fällt es nicht leicht mich in den aktuellen Code einzuarbeiten. Leider merkt man dem Code an, dass er über einige Zeit gewachsen ist. Der Fork unter https://github.com/seisfeld/TonUINO ist in dieser Hinsicht einladender aber leider um etliche Commits hinter der offiziellen Version. Es wäre schön, wenn die ino-Datei eine deutlichere Struktur und viel mehr Kommentare bekommen würde.
    Vorschlag für eine Struktur:
  • Großer einleitender Kommentarblock, der alle Optionen erklärt. (Vergleichbar zu seisfeld)
  • Direkt im Anschluss alle #define, die eine Konfigurationsoption bieten.
  • dann alle #include (am liebsten inklusive Arduino.h, weil dies außerhalb der ArduinoIDE leichter ist und sich die ArduinoIDE davon nicht stören lässt)
  • dann alle typedef,
  • dann alle enum,
  • dann alle struct,
  • dann alle const,
  • dann alle …
  • und zum Schluss alle globalen Variablen sofern sie denn unbedingt nötig sind (globale Variablen - igitipfui :wink: )
  • dann Funktionsprototypen für jede Funktion (außer setup() und loop())
  • dann erst setup(), dann loop() und danach möglichst thematisch/alphabetisch sortiert die anderen Funktionen. Und vor jede dieser Funktionen sollte ein ausführlicher, mehrzeiliger Kommentar stehen, der den Inhalt und die Übergabeparameter der Funktion beschreibt.
  • Zwischen allen Abschnitten sehr gerne auffällige Trennungen.

Ja, mir ist bewusst: Punkt 3 bedarf einer großen Hauruck-Aktion, die in zeitlich begrenztem Rahmen durchgeführt werden sollte, da sie alle anderen Entwicklungen am Code in dem Moment beeinträchtigen kann. Meiner Meinung nach würde dies das Projekt einen großen Schritt voran bringen.

Ich bin gerne bereit im Rahmen meiner beschränkten Freizeit und bisher beschränktem Wissen über das Projekt an diesen Punkten mitzuhelfen. Aber gerade Punkt 3 würde ich nur dann anfassen, wenn dies im Konsens und in enger Absprache mit den „Verantwortlichen“ geschieht. Schließlich möchte ich ungerne den x-ten Fork des Projektes starten, sondern lieber den Kern unterstützen.

Viele Grüße,
Parsley

Ohne jetzt hier zu sehr ins Detail über das warum zu gehen: Mein Fork implementiert absichtlich und auch aus historischen Gründen andere Funktionen (und lässt auch absichtlich Sachen weg). Ob man das jetzt als etliche Commits hinterher beschreibt, naja. Ist halt anders. :wink: