Es wird ja öfter mal darüber diskutiert, dass Bugs in den verschiedenen Libraries sind, die nicht gefixt werden oder dass man gerne noch das ein oder andere Feature mehr hätte. Deshalb wollte ich mal hören ob bei Euch ggf. Interesse an einem Community-Fork sowohl für die Libs als auch für die IDE besteht, den wir gemeinsam weiterentwickeln könnten.
Natürlich müsste so ein Projekt international aufgestellt sein ... aber wir können ja hier im deutschen Teil schon mal über Sinn oder Unsinn diskutieren. Ich würde mich deshalb sehr über Eure Meinung zu einem Community-Lib/IDE-Projekt freuen.
Problem wird sein, immer und überall entsprechende Rechte anzufordern, die weiter zu verbreiten. Wenn eine Lib seit mehreren Jahren nicht aktualisiert wurde, dann vermutlich aus dem Grund, dass der Programmierer keinerlei Interesse mehr hat, ggf. Bugs auszumärzen.
Das Problem, was ich hier sehe, ist die geringe Anzahl an Leuten, die sich mit dem sauberen erstellen von Libarys auskennen. Habe selber inzwischen einige Libs erstellt, jedoch nicht für den Arduino selber sondern für AVR GCC für einzelne Controller. Sind defentiv nicht immer perfekt.
Sollte eine bestehende LIB nicht unter einer öffentlichen Lizenz stehen, die die Anpassung erlaubt, muss man sie zur Not halt neu implementieren. Grundsätzlich besteht zwar ein Urheber-Recht am spezifischen Code. Ein Schutz der Art und Weise der Implementierung ist aber nur sehr sehr schwer durchzusetzen. Dazu müßte nach meinem Wissen die Einmaligkeit des Ansatzes dargelegt werden und die Versuchen scheitern meines Wissens regelmäßig.
Damit kann ein Entwickler zwar grundsätzlich die Verwendung seines Source-Codes durch Copy/Paste ggf. verbieten, aber nicht das "Nachprogrammieren" seines Codes. Gleiches gilt meines Wissens für die API-Schnittstellen. Ich meine mich erinnern zu können, dass diese grundsätzlich nicht schützbar sind ... da gibt es wohl auch irgendwo ein Musterurteil.
Damit kann ich grundsätzlich die Funktionalität jeder Lib nachbauen ohne das ursprüngliche Urheber-Recht zu tangieren, wenn ich den Code wirklich selbst neu schreibe. Da kann sicher ein Anwalt mehr dazu sagen, aber zumindest sollte es also nach meinem laienhaften Verständnis kein Problem sein, einen solchen Fork zu machen.
Das es unheimlich schwer ist, fehlerfreie Libs zu schreiben ist vollkommen klar. Aber gerade das ist aus meiner Sicht ein Punkt FÜR das Community-Projekt. Natürlich werden wir dort nicht lauter Experten haben, die alle fehlerfreie Libs schreiben können (btw: ich programmiere seit über 20 Jahren hauptberuflich und mache deshalb heute nicht weniger Fehler als zu Beginn ) aber durch eine breitere Tester-Basis werden diese schneller identifiziert und mit genügend Entwicklern lassen die sich auch zügig fixen ... selbst wenn nicht lauter Experten am Werk sind
ich finde die Idee, gemeinschaftlich einen Softwarepool auf die Beine zu stellen gar nicht so dumm. Allerdings weiß ich nicht genau, ob es Spaß machen würde, an bereits bestehenden Libs herum zu schrauben. Aber etwas neu programmieren ist sicherlich schon interessant. Ob ich dann mitmachen würde, weiß ich noch nicht genau - mir ist noch nicht ganz klar, was Du wie machen willst. Vielleicht kannst Du noch ein paar genauere Angaben machen, was Du Dir wie vorstellst. Welche Projekte Du angehen willst und wie Du - in groben Zügen - gedenkst sie zu lösen. Wie würde das Vorhaben technisch realisiert? Also wie und ggfls. auf welchem Server würden die Libs veröffentlicht, wie kämen die Dokumentationen für die User zustande usw. usf.?
Ich habe einen Uno, einen Mega und div. selbst gebaute Arduinos. Libs müssten aber auf einer breiteren Anzahl von Geräten getestet werden (Leonardo, Esplora, Due usw.). Wie würde das gehandelt?
Hallo,
ach, ist ja alles ganz toll! Dafür mußt Du aber auch die Leute finden.
Keine Idioten- die auch noch ihre Freizeit opfern.
Wie schleppend das geht kannst Du gut an den letzten beiden Versionen der IDE
erkennen. Und da sitzen nicht nur 3 Leute dran.
Neue Lib´s für den Arduino schreiben, könnte man auf den Weg bringen.
Dazu brauchst Du aber einen genauen Marktüberblick über die Hardware,
bestehende wie auch neue.
Du kannst es versuchen, alte Lib´s zu verbessern- oder deren Fehler zu
eleminieren, aber wer braucht es?
Womit man noch einen Start machen könnte, wäre alte Lib´s für den Due,
oder dessen Nachfolger umzuschreiben.
Warum soll man das Rad neu erfinden?
Gruß und Spaß
Andreas
Zum testen würde ich mich anbieten, habe folgende orginal Arduinos:
Arduino Uno (SMD, 328P)
Arduino Uno (DIP, 328P)
Arduino Pro Mini (5V, 16MHz, 328P)
Arduino Pro Mini (3.3V, 8Hz, 328P)
Arduino Leonardo (32U4)
Arduino Mega (2560)
Arduino Due (SAM3X8E)
Arduino YUN (32U4)
Wobei es hier nicht darum geht, alle zu testen. Denn es kommt hier lediglich auf die MCU Variante an. Lediglich für den 328P müsste F_CPU anders defeniert werden. Aber, ich denke ich bin nicht dabei. Mache das für mich selber lieber für AVR GCC
in vielen anderen Projekten läuft es so, dass die Dateien zum Beispiel bei SourceForge abgelegt werden. Zusätzlich setzt man noch ein Bug-Tracking System wie zum Beispiel Bugzilla ein. Im letzteren werden Defects aber auch Anregungen für neue Features / Libs gesammelt. Über den Inhalt von neuen Releasen könnte zum Beispiel mit einer einfachen Online-Umfrage demokratisch entschieden werden.
Entwickler für Source-Code - aber auch Texter für Dokus, Übersetzer und nicht zuletzt Tester können sich einfach registrieren und entscheiden eigenständig, an welchen Punkten der aktuellen Taskliste sie mitwirken wollen.
Im ersten Schritt sollten wir vielleicht versuchen, im SourceForge Projekt die unterschiedlichsten Libs zu sammeln um überhaupt mal ein zentrales Repository zu haben. Dann machen wir uns im zweiten Schritt daran, diese so weit erforderlich noch zu dokumentieren und indentifizierte Defects zu beheben sowie die unterschiedlichen Versionen in zu konsolidieren, so dass am Ende im Idealfall nur jeweils eine Version übrig bleibt, die möglichst auf allen Boards eingesetzt werden kann. Wenn das geschafft ist, können wir gemeinschaftlich über zusätzliche Funktionen / neue Libs nachdenken.
Edit: SourceForge soll hier natürlich nur als Synonym gelten ... genauso gut könnte man auch GitHub dafür nutzen.
SkobyMobil:
HDu kannst es versuchen, alte Lib´s zu verbessern- oder deren Fehler zu
eleminieren, aber wer braucht es?
Womit man noch einen Start machen könnte, wäre alte Lib´s für den Due,
oder dessen Nachfolger umzuschreiben.
Warum soll man das Rad neu erfinden?
Gruß und Spaß
Andreas
Den Bedarf an funktionierenden Libs sehe ich durchaus. Wie oft lese ich "probier doch statt Deiner LiquitCrystal_I2C.h doch mal diese oder jene ..."
Vor langer Zeit (in EDV-Maßstäben) wurde auch mal gefragt: "Wer braucht schon einen anderen Browser?" heute ist Firefox nicht mehr wegzudenken!
Mit dem "Rad neu erfinden" gebe ich Dir allerdings vollkommen Recht. Es wäre auch nicht clever, das versuchen zu wollen. Deshalb würde ich persönlich auch auf bekanntem/bewährtem aufbauen wo immer es geht und nur dort wo zum Beispiel tatsächlich einmal Urheber-Rechte im Weg stehen "nochmal über das Rad nachdenken"
Vielleicht sollte hier mal einer Anfangen, aufzulisten, welche Libarys doch recht stark verbuggt sind. Jedoch wird es auch Libarys geben, die es nicht lohnt, in die Repos zu holen. Das wäre zB die FastLed Libary. Man kann höchstens Fragen, ob man die Final v2 hosten darf. Alles andere ist zu kurzlebig.
Sinnvoller wäre es einen Pinned -Beitrag zu erstellen, in dem alles Ordentlich aufgelistet wird.
Wenn ich ein I2C LCD nehmen möchte, dann brauche ich die x -lib etc.
also von irgendwelchen Forks halte ich nichts. Sieht man schön bei Linux, jeder kocht sein eigenen Süppchen. Welcher Einsteiger soll dann noch durchsehen wenn es verschiedene IDEs gibts und jede hat ihre Vor- und Nachteile. Man müßte dem Arduino Team als Forum sagen können was noch rein könnte in die IDE und dennoch einfach bleibt. Ich möchte keine IDE haben die dann so aussieht und aufgeblasen ist wie Atmel Studio. Vorallen, wer testet die IDE auf Herz und Nieren.
Librarys. Da existieren zu viele. Wenn die Arduino eigenen nicht funktionieren, sollte man das melden können. Wenn fremde nicht funktionieren, sollte man dem jenigen eine Mail schreiben. Am Ende landen sonst wieder tausende Versionen einer Library im Netz und keiner weis welche nun aktuell ist.
Der Gedanke ist schön von Dir. Ist aber sehr schwer umzusetzen. Denn dann müßten mehrere Leute ständig über Jahre hinweg am Ball bleiben und die Daten pflegen und das unbezahlt in der Freizeit. Wer soll das durchhalten? Für sehr viele Dinge reichen auch Funktionen. Die Hilfe dafür bekommt im Forum. Fremde Librarys zu pflegen wird wie gesagt sehr schwer werden. Zudem das auch nur Leute machen können, die wirklich von Programmierung Ahnung haben. Da fallen viele schon raus, mich eingeschlossen. Ich werde Euch jedoch nicht aufhalten. Habe nur meine Gedanken geäußert.
An der IDE Verbesserungen vorzuschlagen wurde schon oft gemacht und es hat sich sehr wenig getan. Man will es anscheinend nicht. In der aktuellen Version gibt es endlich Zeilennummern. Das ist da schon das höchste der Gefühle an Komfort.
Ein Feature dass ich mir wünschen würde wäre vollen Zugang zu den Compiler und Linker Switches (die sind im Moment hard coded). Dann könnte man z.B. je nach Bedarf printf() entweder in einer Minimal Version haben (was für viele Sachen reichen würde und Speicher spart) oder mit Float Unterstützung. Aber das wurde wahrscheinlich auch schon oft gefordert.
Serenifly:
An der IDE Verbesserungen vorzuschlagen wurde schon oft gemacht und es hat sich sehr wenig getan. Man will es anscheinend nicht. In der aktuellen Version gibt es endlich Zeilennummern. Das ist da schon das höchste der Gefühle an Komfort.
Ein Feature dass ich mir wünschen würde wäre vollen Zugang zu den Compiler und Linker Switches (die sind im Moment hard coded). Dann könnte man z.B. je nach Bedarf printf() entweder in einer Minimal Version haben (was für viele Sachen reichen würde und Speicher spart) oder mit Float Unterstützung. Aber das wurde wahrscheinlich auch schon oft gefordert.
Ich kann mich nicht beklagen. Bis auf das Autosave wurde bisher alles umgesetzt, was ich vorgeschlagen hatte.
Liegen die Compiler Schalter nicht in der platform.txt?
Zum Thema: Kann ich gleich aus Erfahrung sagen, daß wird nix. Aus dne unterschiedlichsten Gründen. Wenn eine Lib nciht funktioniert oder Buggy ist, dann repariere ich Sie oder nehm einfach eine andere. Code geb ich natürlich an den Autor weiter.
Von einem Fork halte ich ebenso wenig.
Wie schon in früheren Posts erwähnt, ist es mehr als schwierig diesen zu Pflegen.
Ganz zu schweigen von einer weiteren Zersplitterung von Libs oder IDEs ...
Viel sinnvoller wäre es, als Team an den bestehenden Quellen mit zu arbeiten und diese dem Entwicklerteam der IDE und/oder den Library-Entwicklern zukommen zu lassen. Github-Rep forken -> (sinnvolle und brauchbare) Änderungen machen -> Pull-Request senden.
Um längen effektiver als einen komplett eigenen Fork aufzustellen.
Bzgl. den Rechten die IDE zu verändern: GPLv2 / Creative Commons 3.0 BY-SA
Solang die gemachten Änderungen der Allegmeinheit zur Verfügung gestellt werden ist alles im grünen Bereich.
Nichts desto trotz wäre ich unter bestimmten (oben genannten) Voraussetzungen dabei. Auch wenn sich meine Low-Level-Progammierkenntnisse gen null bewegen, kann ich ja Doku schreiben/übersetzen, testen oder andere anfallende Sachen machen.
Grundsätzlich gebe ich Dir da natürlich vollkommen Recht ... aber
Mein persönlicher Eindruck ist, dass dem offiziellen Projekt daran wenig liegt. Zumindest werden alle Versuche von 3rd Party Anbietern abgeblockt, Nicht-Adafruit Boards in die GUI zu integrieren. Daran, dass Fehler schon lange reported aber nie gefixt wurden zeigt sich zudem, dass es auch wenig Interesse gibt, die Qualität zu verbessern.
Auf der anderen Seite würde aber natürlich niemand die Kollegen vom offiziellen Projekt daran hindern, durch die Community gefixte, erweiterte, verbesserte oder neu geschriebene Libs in die IDE mit aufzunehmen.
Serenifly:
An der IDE Verbesserungen vorzuschlagen wurde schon oft gemacht und es hat sich sehr wenig getan. Man will es anscheinend nicht. In der aktuellen Version gibt es endlich Zeilennummern. Das ist da schon das höchste der Gefühle an Komfort.
Es muss sich halt auch jemand hinsetzen und die gewünschten Änderungen programmieren. Ich weiß nicht, ob diese Leute ehrenamtlich arbeiten oder Gehalt bekommen? Wenn ehrenamtlich, muss ja auch jemand erst mal bereit sein, da Stunden um Stunden zu investieren.
Serenifly:
Ein Feature dass ich mir wünschen würde wäre vollen Zugang zu den Compiler und Linker Switches (die sind im Moment hard coded). Dann könnte man z.B. je nach Bedarf printf() entweder in einer Minimal Version haben (was für viele Sachen reichen würde und Speicher spart) oder mit Float Unterstützung. Aber das wurde wahrscheinlich auch schon oft gefordert.
Ich habe das schon mal in dem einen oder anderen Thread erwähnt, mit Code::Blocks für Arduino kannst Du Compiler- und Linker-Optionen einstellen und vieles mehr machen, was die original IDE nicht kann.
Generell zum Thema: Ich denke an bestehenden Libs Veränderungen vornehmen ist nicht der richtige Weg. Da blickt dann sicherlich irgendwann keiner mehr durch welche Version einer Lib gerade aktuell ist. Vielleicht wäre eine Herangehensweise: Ein bestimmtes Bauteil nehmen, sagen wir (jetzt nur als Beispiel) einen DHT21-Sensor. Die Lib schreiben, die dann auf möglichst allen erreichbaren Arduinos läuft. Betatestphase - Fehler beseitigen. Brauchbare Dokumentation erstellen. Im Netz unter einem eigenen Namen als eigenständige Lib veröffentlichen. Falls noch Fehlerrückmeldungen kommen, diese bearbeiten und Fehler beseitigen.
willie1968:
Liegen die Compiler Schalter nicht in der platform.txt?
Ich habs mir mal genauer angesehen. Und ab 1.5.x sind sie wohl nicht mehr hardcoded :o
Hier geht es genaugenommen um den Linker. Nicht den Compiler:
Since the full implementation of all the mentioned features becomes fairly large, three different flavours of vfprintf() can be selected using linker options. The default vfprintf() implements all the mentioned functionality except floating point conversions. A minimized version of vfprintf() is available that only implements the very basic integer and string conversion facilities, but only the # additional option can be specified using conversion flags (these flags are parsed correctly from the format specification, but then simply ignored). This version can be requested using the following compiler options:
-Wl,-u,vfprintf -lprintf_min
If the full functionality including the floating point conversions is required, the following options should be used:
-Wl,-u,vfprintf -lprintf_flt -lm
Ich bringe es aber irgendwie nicht hin. In dieser Zeile schien es am vernünftigsten:
compiler.c.elf.flags=-w -Os -Wl,--gc-sections
Ändert aber nichts an der Code Größe und druckt auch nur "?"
) aber durch eine breitere Tester-Basis werden diese schneller identifiziert und mit genügend Entwicklern lassen die sich auch zügig fixen ... selbst wenn nicht lauter Experten am Werk sind 
