Mit welchem Programm/Tool arduino software/Hardware projekte verwalten?

Hallo,

mit welchem Tool kann mann seine ersten 'größer' und unübersichtlicher werdenden Software Projekte verwalten (hinsichtlich Versionsverwaltung ToDo's Bugs Unter/Funktionen Dokumentieren ect)?

Gerne für Ubuntu oder auch Android. Vielen Dank

Hintergrund: Für verschiedene, meist Datenlogger oder Steuerungs Projekte bastele ich mir (auch aus Lernanzwecken) einen eigenen TaskScheduler mit weiteren Hilfsfunkrionen und 'Features' wie zB. LowPowerSleep in den Pausen, SerialDebugging und Parsing, PCI Interrupts, LCD Menü, Drehencoder, SD Card, Web Server, Zahl2String (mit führenden 0/_), RAM/CPU_load (%), RTC, PWM,433MHz Funkmodul mit CRC, ADC, Callibrstion, Oversampling & averaging, EEPROM, ... usw. Was man/ich halt alles des öfteren wieder gebrauchen kann (oder in Teilen davon) als eine Art Grundgerüst. Das ganze funktioniert in teilen bzw. als Spagetticode schon, ist aber kaum wieder verwertbar bzw. handelbar und wird gerade versucht von mir übersichtlicher und modulare zu gestalten (diesbezüglich könnten mir auch noch Literatur/Tutorial/Website Tips zugute kommen).

Mit Git z.B.

Schritt 1 ist deinen Code ordentlich aufzubauen. Schritt 2 ist ein Tool zur Versionskontrolle. Eine einfache Version wäre z.B. https://de.wikipedia.org/wiki/Mercurial (im Wiki Artikel gibt es auch Links zu graphischen Benutzeroberflächen). Das halte ich für den Heimgebrauch für ausreichend. Aber da gib es noch viele Alternativen.

Das ganze funktioniert in teilen bzw. als Spagetticode schon, ist aber kaum wieder verwertbar bzw. handelbar und wird gerade versucht von mir übersichtlicher und modulare zu gestalten (diesbezüglich könnten mir auch noch Literatur/Tutorial/Website Tips zugute kommen).

https://www.arduino.cc/en/Hacking/LibraryTutorial https://www.arduino.cc/en/Reference/APIStyleGuide

Dande80:
Schritt 1 ist deinen Code ordentlich aufzubauen.

Das ist ein guter Punkt, denn genau da fängt (meine Unwissenheit) schon an. Gibt es da eine Empfehung (Literatur/Website/Totorial/ gute Beispiele)? Was ich so mitbekommen habe bisher: (Reihenfolge zufällig)

  1. möglichst keine globlen variablen (außer für ISRs, dor nur ein Bit setzen, max die Zeit speichern)
  2. alle “logisch zusammenhängenden”, wiederkehrenden Aufgaben in eine Funktion schreiben
  3. Funktionen bekommen alle benötigten Werte übergeben (am besten Call by Reference, ggf. auch bei mehreren Rückgabewerten )
  4. Code nicht über 1, max 2 A4 Seiten, alles weitere in (modulare) Unterfunktionen “verstecken”
  5. defines in GROSSBUCHSTABEN
  6. variablen möglichst mit Kennung des Typs und nicht zu stark Abkürzen und neueWortTeileMiGrossbuchstabenBeginnen1 oder_untersrich_verwenden_2
  7. Kapselung (also OOP Classes, mit getter und setter)
  8. …das wars auch schn, was mir spontan so einfällt, ach // ausgiebig Kommentieren

Gibt es da eine gute Liste/Zusammenfassung?

combie:
Arduino - LibraryTutorial
Arduino - APIStyleGuide

Ja, definitiv (mal wieder) einen Blick wert. Hatte dort vor längerer Zeit mal meine erste Lib entsprechend des Beispiel gebastelt. Jetzt versteht man schon mehr, wenn man’s noch mal liest.

Aber viel mehr frage ich mich, ab wann macht man eine neue Class auf oder wie untergliedert man den Code sinnig (modular, schönes Wort, aber was genau bedeutet das für die Codeaufteilung) und wie ist das mit den Zugriffsmöglichkeiten, z:b. wenn man in einer selbst erstellten Lib mit PCI Interrupts arbeiten möchte.

Wie kombiniere ich meine versch. Libs dann z.B. eine ADC-Lib (mit oversampling und avaeraging), eine LCD-Menü-Lib, eine Rotary-Switch-Lib, so mit meinem TaskScheduler dass es mal mit ADC bzw. mal mit LCD oder auch ohne geht.

Da habe ich noch viele Fragezeichen in meinem Kopf :slight_smile:

PS: static habe ich leider erst vor kurzen kennen gelernt, eine sehr schöne Sache um nicht (ständig) mit globalen variablen zu arbeiten.

jim_beam: 6. variablen möglichst mit Kennung des Typs

Du beziehst dich da wahrscheinlich auf die ungarische Notation. Da war eigentlich mal so gedacht, dass man den Kontext der Variable angibt. Also für was sie verwendet wird. Bei Microsoft hat dass dann jemand falsch verstanden und da wortwörtlich den Typ in den Variablen-Namen aufgenommen. Das ist doppelt gemoppelt und bringt nichts. Das war vielleicht mal in der Computer-Steinzeit hilfreich, aber mit einer modernen IDE sieht man den Variablen Typ wenn man mit der Maus darüber geht. Bei generischer Programmierung oder überladenen Methoden (wo die Methode auf der Basis des Datentyps ausgewählt wird) wird es dann endgültig abstrus.

PS: static habe ich leider erst vor kurzen kennen gelernt, eine sehr schöne Sache um nicht (ständig) mit globalen variablen zu arbeiten.

Static halte ich fast schon für ein Antipattern. OK, manchmal ist es hilfreich, so wie goto.

Man sollte sich den Einsatz gut überlegen. Und immer dabei bedenken:

Wer einmal begriffen hat, wie ein Hammer funktioniert, für den sieht jedes Problem wie ein Nagel aus.

Static halte ich fast schon für ein Antipattern. OK, manchmal ist es hilfreich, so wie goto.

static find ich gut ;)

Speziell in unserer loop - orientierten Programmierung sollte man die Eigenschaften: - überall sichtbar - Wert bleibt zum nächsten Aufruf erhalten trennen.

static im Zusammenhang mit Objekten und Klassen ist ein etwas anderes Thema, aber auch dort nachdenkenswert.

Ich nutze static Variablen haufenweise in meinen Methoden. Meist wenn ich Methoden mache, die in einem bestimmten Intervall irgendwas machen sollen (static zum speichern der millis) oder die bis zum nächsten Aufruf einen Zustand oder Wert mitnehmen sollen (zum toggeln oder glätten). Natürlich kann man da extra Klassen anlegen (in Java würd ich das z.B. sofort machen), aber wenn ich doch sowieso nix wiederverwende, sondern lediglich meinen prozeduralen Code damit strukturiere und lesbarer mache, dann habe ich einfach keine Notwendigkeit für eine Klasse und nutze die statischen variablen.

Was die Organisation angeht: Eclipse IDE nehmen und eigene Projekte machen. Aus den Projekten dann Libs erzeugen (so kannst du deine Libs auch gut pflegen).

Was den Code selbst angeht: http://blog.goyello.com/2013/01/21/top-9-principles-clean-code/