Gerade wollte ich doch mal wieder was mit Programmierung machen und lud einen älteren Sketch.
Da kam eine Fehlermeldung. Nun bin ich schon wieder länger raus und dachte mir, da frag ich mal die KI. Mach ich sonst nicht - versprochen.
Sehr witzig, die KI hatte eine Antwort womit ich nicht gerechnet habe.
1
Das Problem ist, dass sich im selben Ordner (Timer) zwei .ino-Dateien befinden: Timer.ino und Timer_Kopie.ino.
2
Die Arduino IDE versucht, alle .ino-Dateien in einem Ordner zu einem einzigen Programm zusammenzufassen. Da beide Dateien den exakt gleichen Code enthalten, beschwert sich der Compiler über "Redefinitions" – er sieht Variablen wie sleep_flag und Funktionen wie setup() doppelt.
Bisher hatte ich solche Probleme nie. Ich habe natürlich immer die neuen Versionen der Arduino IDE installiert.
Ist das nur ein blöder Zufall, dass das jetzt aufgetreten ist oder handhabt Arduino die Dateienverwaltung nun anders?
Das passiert auch, wenn du eine .ino in einem anderen Ordner anklickst.
Dann fragt er dich, ob er sie nach /Arduino kopieren soll.
Er legt auch automatisch einen neuen Ordner an, wenn du eine .ino speichern willst und sie Timer nennst. Dann hast du einen Ordner Timer und eine Timer.ino in /Arduino
Dann hast du einen Ordner Timer
und eine Timer.ino in /Arduino
Zumindest weiß ich jetzt wieso ich dieses Verhalten nicht mehr unterbinden sollte.
Macht Arduino erst seit einiger Zeit und nervte mich immer. Gerade weil ich die Änderungen immer in einer neuen Datei zusammen in einem Ordner haben wollte. Bisher gab es sicher auch deshalb Fehler, die mir aber nicht so klar waren.
Ach Git, ja klar!
Danke für den Link! Hatte ich damals schon einmal mit angefangen.
Ich denke da ich jetzt mit der Abwicklung der Arbeit fertig bin und wenn es mir weiterhin ziemlich gut geht, ist das sicher etwas, was ich mir (dank deinem Hinweis) wieder ansehen werde. Allerdings will ich so was nicht öffentlich machen. Nicht, dass ich was zu verheimlichen hätte, aber meine Programme sind sicher für viele Menschen augenschädlich.😆
So als Tipp:
man kann mit git auch ein Repo auf eine USB Festplatte "pushen".
Dann hat man gleich ein Backup aller Änderungen auf einem zweiten Speicher.
Mach ich mit vielen kleinen Projekten so an denen nur ich arbeite.
Wenn man einen Heimserver hat (und da reicht ein dockerfähiges NAS aus), kann man auf diesem einen lokalen Git-Server laufen lassen. Gitea ist da eine recht nette Möglichkeit.
Fürs reine Backup aber genügt es, das Quellverzeihnis inklusive aller enthaltenen versteckten Dateien zu sichern. Im versteckten Verzeichnis .git liegt die "Magie" von git.
handhabt Arduino die Dateienverwaltung nun anders?
War schon immer so. Projektname = Verzeichnis = Dateiname
Meine ersten Gehversuche mit Arduino waren 2015 mit 1.7.4, da wurde aus einer .ino automatisch ein gleichnamiges Verzeichnis angelegt und die in dieses verschoben. Wenn im Ordner zwei oder mehr .ino liegen, fliegt die Compilierung ab - also keinesfalls neu.
Was ich noch nicht probiert habe, ob '#includes' ersetzbar sind, indem man die Files in den Ordner packt. Die Struktur mit den libraries finde ich etwas undurchsichtig und vor allem ärgernisträchtig, wenn man eine aktualisiert und später ein altes Projekt nochmal anfassen muß.
Wenn im Ordner zwei oder mehr .ino liegen, fliegt die
Compilierung ab - also keinesfalls neu.
Ab wann weiß ich nicht mehr, jedenfalls konnte ich sonst immer "Timer.ino;Timer1.ino; Timer2.ino ..." alle im selben Ordner speichern, ohne, dass es Fehler gab.
Das Problem ist, dass sich im selben Ordner (Timer) zwei .ino-Dateien
befinden: Timer.ino und Timer_Kopie.ino.
Die IDE erstellt automatisch keine Kopie. Die Timer_Kopie.ino. hast du selbst erstellt. Da beißt die Maus keinen Faden ab. Das passiert wenn man mit der Maus im Dateiexplorer eine Datei in den gleichen Ordner kopiert bzw. eine Kopie erstellt. Vermutlich ausversehen passiert, aber von dir und nicht von der IDE.
Ab wann weiß ich nicht mehr, jedenfalls konnte ich sonst immer
"Timer.ino;Timer1.ino; Timer2.ino ..." alle im selben Ordner speichern,
ohne, dass es Fehler gab.
Wenn in allen das "Gleiche" drin steht inkl. setup() und loop() und es als Backup dienen soll, dann ist das natürlich quatsch. Denn alle .ino Dateien im Ordner Timer werden "zusammengestellt/zusammenkopiert" bevor die eigentliche Kompilierung beginnt. Wenn es dann mehrere gleichnamige Funktionen, Variablen etc. gibt knallt es natürlich. War vorher so und ist jetzt so. Lege einen Unterordner Backup an und schiebe sie dort rein. Das mach ich bspw. so mit Datumskürzel im Dateinamen. Ist simpel und reicht für meine Zwecke aus.
Was man machen kann ist mit Tabs arbeiten, wenn der Sketch/Code größer wird, wenn man den Code nicht in eigene Libs auslagern möchte, wenn der Code zur Wiederverwendung nicht geeignet ist. Dein Ordner heißt Timer und es gibt eine Timer.ino. Damit ist das die Haupt .ino Datei mit setup() und loop(). Alle anderen .ino Dateien sind in den Tabs wenn du diesen Sketch öffnest und befinden sich auch im Ordner Timer. Das mit den Tabs dient zum Code auslagern, da kann man Funktionen reinschieben o.ä. Selten gibt es Probleme damit, dann muss man mit Funktionsprototypen nachhelfen.
handhabt Arduino die Dateienverwaltung nun anders?
War schon immer so. Projektname = Verzeichnis = Dateiname
Wo er recht hat, hat er recht.
Was ich noch nicht probiert habe, ob '#includes' ersetzbar sind, indem
man die Files in den Ordner packt. Die Struktur mit den libraries finde
ich etwas undurchsichtig und vor allem ärgernisträchtig, wenn man eine
aktualisiert und später ein altes Projekt nochmal anfassen muß.
Ich habe das noch nicht speziell genau dafür probiert. Aber Prinzip wie eigens erstelle Libs. Ordnernamen, Dateinamen und die library.properties anpassen. Alles im Pfad ...\sketchbook\libraries. Bei anderen Libs kann man sich das anschauen. Dann wird die ältere Version auch von der IDE gefunden und aufgelistet und liegt dann nicht versteckt irgendwo rum. Wenn man mehrere Lib Versionen testen möchte, muss man dann nur seine #include Zeile ändern und nicht tief im System rumfummeln. Bspw. würde sich anbieten #include "xyzLib_v0.0.1" oder "xyzLib_v0.0.2".
Für jede Version gibt einen Ordner im Pfad ...\sketchbook\libraries und alle Versionen sind sauber getrennt.
Man kann das sicherlich auch mir #defines ausbauen wenn spezifisch kompiliert werden soll, ich denke da sind der Fantasie keine Grenzen gesetzt.
Die IDE erstellt automatisch keine Kopie. Die Timer_Kopie.ino. hast du
selbst erstellt. Da beißt die Maus keinen Faden ab. Das passiert wenn
man mit der Maus im Dateiexplorer eine Datei in den gleichen Ordner
kopiert bzw. eine Kopie erstellt. Vermutlich ausversehen passiert, aber
von dir und nicht von der IDE.
Ja klar habe ich das /extra/ gemacht.
Aber jetzt bin ich im Bilde und mir schwarmt, dass ich wohl auch schon vorher Fehler dadurch hatte, die ich nur leider so nicht erkannt hatte.
Im Nachhinein eine war das eine blöde Idee, weil das eigentlich aus anderen IDEs bekannt war.
Manchmal ist man einfach bescheuert.
Jedenfalls weiß ich es jetzt und werde die selbstverständlich in verschiedenen Unterordner speichern.
Und Git schaue ich mir auch wieder an.
Ich hänge das Datum an und belasse die Dateien in ihren Ordner. Das mache ich auch mit Software und habe mir dafür ein mausbedienbares Programm geschrieben.
Ich hänge das Datum an und belasse die Dateien in ihren Ordner.
Auch eine Idee. Aber ich habe gerade erstmal gesehen, dass ich nur noch schwer durchblicke. Das letzte Projekt war die elektrische Bremse beim Gabelstapler. Eigentlich müsste ich jeden Schritt noch im Kopf haben. Früher war das so, aber seit Richard tot ist und ich danach einen Gedächnisverlust hatte, funktioniert mein Kopf leider nicht mehr so gut, dass ich mir alles über jahrzehnte merken kann und dann kam auch noch der neue Tumor.
Kurz um, ich muss das sowieso alles neu ordnen und vor allem dokumentieren.
Ob nun Git oder was anderes kommt, ist noch offen.
Ob nun Git oder was anderes kommt, ist noch offen.
Git macht (u.a.) dasselbe, was die von Hand angelegten Dateien machen sollen, kann aber auch gleich die Unterschiede zwischen verschiedenen Versionen ("Commits") anzeigen.
Und die von Git angelegten "Kopien" bringen nicht die Entwicklungsumgebung durcheinander, sondern die liegen versteckt in einem Unterverzeichnis (.git)
In vielen neueren IDEs gibt es eine Git-Integration, man kann das aber auch im Kommandozeilenfenster bedienen.
Die paar Kommandos, die man regelmäßig braucht, hat man schnell
auswendig gelernt.
Gewiss, nur ist eine brauchbare Anzeige eines diffs, bei dem man nicht eintippseln muss, welche Commits man vergleichen möchte, sondern diese z.B. aus 'ner Dropdown-Liste aussuchen kann, meist komfortabler.
Git macht (u.a.) dasselbe, was die von Hand angelegten Dateien machen
sollen, kann aber auch gleich die Unterschiede zwischen verschiedenen
Versionen ("Commits") anzeigen.
Schaue mir gerade ein Tutorial an und gerade zeigt er, dass du das "Privat" stellen kannst. Darunter, das hat er (noch) nicht gesagt, steht sofort "Add a Readme file". Genau das brauche ich.
Allerdings muss ich das nochmal schauen, da ich gerade schon weggesegelt bin. Bin seit 5:30 Uhr auf den Beinen. Training, Haushalt und alle anderen, möglichen Sachen. Jetzt kommt die Müdigkeit.
Schaue mir gerade ein Tutorial an und gerade zeigt er, dass du das
"Privat" stellen kannst.
Da vermischst du gerade Git und Github.
Github kann man benutzen, dann hast du gewissermaßen einen Cloud-Backup. ;-) Allerdings könnte es sein, dass Microsoft deinen Code zum Füttern von irgendwelchen LLMs benutzt, wenn du als nicht zahlender Kunde private Repositories machst, da habe ich noch nicht so genau hingesehen. Alle meine Github-Repos sind eh öffentlich. ;-)
Git selbst braucht kein Github, wurde dir ja aber schon geschrieben. Es braucht auch keine verteilten Repositories, wenngleich man das natürlich als eine simple Art Backup machen kann. Wenn du allein dran arbeitest und nur eins der Repositories zum Arbeiten benutzt (das / die andere(n) nur als Backup), musst du dich auch nicht um potenzielle Konflikte zwischen Dateiversionen sorgen.
Bash ist auf jeden Fall wieder wie Dos (so ähnlich).
Braucht man dafür nicht. Das ist nur Hipsterkram, die meinen, alles müsse so sein wie ihr geliebtes Linux. Man kann git unter Windows auch ohne bash, cygwin, wsl und all' diese Nachbildungen verwenden.
Und man braucht weder gitlab noch github.
Die sind wunderbar, wenn man seine Ergebnisse /anderen/ zur Verfügung stellen möchte, aber nur, um seinen eigenen Krempel zu versionieren, komplett überflüssig.
Und wenn einem die "commits" auf dem eigenen Rechner nicht reichen - ein lokal betriebener git-Server löst das Problem (ich hatte bereits gitea erwähnt, oder?).
Und wenn einem die "commits" auf dem eigenen Rechner nicht reichen - ein
lokal betriebener git-Server löst das Problem (ich hatte bereits gitea
erwähnt, oder?).
Bin noch beim Lesen und Videos schauen.
Da ich Office 365 habe, ist auch sowieso alles nochmal auf OneDrive gespeichert.
Nein, ich brauche wirklich nur eine Versionskontrolle und muss einfach deutlich kommentieren.
Man kann git unter Windows auch ohne bash, cygwin, wsl und all' diese
Nachbildungen verwenden.
Andererseits kann man die Gitbash unter Windows auch ganz ohne Git verwenden und hat dann den gewohnten Komfort, von dem cmd.exe weit entfernt ist. :-)
Ah, wir könnten einen Religionskrieg anzetteln ... Es ist /anders/.
Und wer mit der bash arbeiten will, macht das doch eh' am besten unter einem unixoiden Betriebssystem, denn die shell alleine macht ja den Kohl nicht fett.
Ah, wir könnten einen Religionskrieg anzetteln ... Es ist /anders/.
Es ist besser als command.com, aber ansonsten fehlt ihm noch sehr viel dessen, was den Komfort modernerer Unix-Shells ausmacht.
Und wer mit der bash arbeiten will, macht das doch eh' am besten unter
einem unixoiden Betriebssystem
Ging mir ja eher darum, dass die Git-Bash einem halt das Leben unter Windows leichter machen kann, wenn man denn aus irgendwelchen Gründen selbiges benutzen muss. ;) Allein copy&paste mit der mittleren Maustaste ist schon eine große Hilfe.
Also ich finde immer noch einige wenige Befehle, wie zu Dos-Zeiten, besser als das ewige zusammen klicken. Und braucht man öfter das gleiche, war es sehr hilfreich das als batch Datei zu speichern.
Und das alles aus dem Betriebssystem, ohne womöglich mehrere extra Software zu installieren.
Allein copy&paste mit der mittleren Maustaste
ist schon eine große Hilfe.
Geht in der Windows-Kommandozeile auch, nur anders.
Copy: Markieren und Return drücken
Paste: Rechte Maustaste drücken
Seit geraumer Zeit funktionieren aber auch die guten alten Wordstar-Tastenkürzel Ctrl-C und Ctrl-V, und um den Textcursor zum Markieren zu bewegen, Ctrl-M drücken, dann mit den Cursortasten bewegen. Mit Shift- und Cursortasten wird dann markiert. Man kann also auch auf das Mausschubsen verzichten.
Windows kann auch sehr viel, nur macht es das halt anders.
Ist ja auch praktisch. Kann die Windows-"Eingabeaufforderung" aber auch. Früher war das beim Markieren mit der Maus sogar das Standardverhalten, jetzt muss man die Alt-Taste gedrückt halten, um ein Rechteck zu markieren.
Ja, das ist dann aber umständlicher und potentiell fehlerträchtiger Handbetrieb. Nicht nur, daß man dran denken muss, immer mal wieder 'ne neue Kopie anzulegen, man muss auch konsistent bei der Namensvergabe sein.
Und wenn ein Projekt nicht trivial ist, dann besteht es aus einer Vielzahl von Dateien, die man auch alle entsprechend behandeln muss.
So haben die meisten von uns früher auch mal gearbeitet.
"moooment, hauptfunktion_123 vewendet seriell_45, oder war das doch schon seriell_47? Und was ist mit konfigurationsverwalter_69? Geht der mit seriell_47, oder war da noch ein Fehler?"
Das ist etwas, was einem git halt auch sehr schön und zuverlässig abnehmen kann.
Nicht nur, daß man dran denken muss, immer mal wieder 'ne
neue Kopie anzulegen
Das muss man aber bei einem beliebigen Versionierungstool auch. Entweder branches oder wenigstens commits zwischendurch. Aber sehr viel übersichtlicher wird es mit commits oder branches. Da halten lokale Kopien einfach nicht mit.
Oder man verlässt sich halt in VS Code auf die Timeline oder in Eclipse auf die lokale History verlassen. Aber die sind schon wieder zu granular für meinen Geschmack.
Aber das beste Werkzeug ist oft das, womit man sich auskennt ;)
Ich vermute dass das größte Hindernis die falsche Einschätzung von git als übermächtigem Werkzeug ist.
Denn man kann es tatsächlich völlig eigenständig, ohne Server, ohne Inet, ohne alles betreiben.
Einfach nur ein leeres Projekt-Verzeichnis anlegen und loslegen.
Dann entweder die schnellen Konsolenkommandos bzw. einen kleinen Teil derer nutzen,
ODER ›git gui‹ starten und alles per GUI machen.
Repository anlegen, Konfiguration ändern, Datein einchecken und committen, usw. Später dann noch eine zweite GUI-Applikation ›gitk‹ für den größeren Überblick.
Man kann das auch ohne zu Programmieren einfach nur mal Testen und kleine Textdateien dazu benutzen. Dann muss man keine Angst haben etwas kaputt zu machen.
Wenn man dann etwas beim herum probieren versaubeutelt hat, im schlimmsten Fall das Verzeichnis löschen und nochmal neu anfangen.
Und wer wirklich Angst hat, das geht natürlich auch im /tmp/xxx Verzeichnis.
Add: Eines noch…
Wer mit Linux arbeitet, dem würde ich empfehlen die GUI Programme mit:
LC_ALL=C gitk & disown
LC_ALL=C git gui & disown
zu starten um sie mit englischen Bezeichnungen zu benutzen. Die deutschen Übersetzungen mögen vielleicht richtig sein, hilfreich zum Verständnis sind sie gewiss nicht.
Für Windows wird sicherlich jemand die passenden Aufrufe liefern können.
wenn ein Projekt nicht trivial ist, dann besteht es aus einer Vielzahl
von Dateien,
Da hast Du natürlich Recht. Ich schreib mir Git mal auf die todo Liste. Aber bis ich das alles installiert, am Laufen und kapiert habe, bin ich vermutlich schon bei timer_100_ino oder schon längst bei was anderem interessanten.
Ich denke auch Harald K. (kirnbichler) hat die psychologische Einstiegshürde zu hoch gelegt. Fang mit GitHub an. Bei einer einzelnen Datei kannst Du den Dateiinhalt auch online bearbeiten und die Änderungen direkt abspeichern. Das ist so einfach wie hier ein Post zu editieren.
Ich nutze die Git Bash unter Windows auch nur, weil man da mehrere Dateien in einen Commit packen kann. Bei einer einzelnen Timer.ino braucht es gar nichts, nur einen beliebigen Webbrowser.
Mittlerweile habe ich mich schon etwas mit Git auseinander gesetzt und auch dort muss man schon einiges tun, damit alles unter Kontrolle bleibt.
Der wesentliche Unterschied ist, dass die eigentliche Verwaltung dann aber durch Git funktioniert und du halt auch einen Kommentar eingeben musst.
Man muss auch dort konzentriert sein.
Dennoch ist das deutlich besser, als eine ungeplante eigene Kontrolle.
Wobei der wirkliche Vorteil von Git für mich natürlich nicht in Erscheinung treten wird. Das ist die Zusammenarbeit mit anderen.
Trotzdem bin ich euch dankbar, dass ihr mich wieder drauf gebracht habt.
Heute ist das Kochfeld gekommen und jetzt habe ich wieder Zeit mich weiter einzuarbeiten.
Zwischendurch habe ich schon so einige Sachen versucht und muss die erstmal zurück setzen und dann mit einem richtigen Projekt, das dann auch von der Größe dem Sinn von Git entspricht, neu anfangen.
Dazu werde ich mit meinem EFSB nochmal anfangen. Auch wenn es am Ende vielleicht nicht zum realen Bremsentester wird (weil mir dazu die 80V Staplerbatterie fehlt), so ist es aber das erste komplexe Projekt. Und wenn schon groß, dann halt noch ein bisschen mehr durch Git.
Ich denke auch Harald K. (kirnbichler) hat die psychologische
Einstiegshürde zu hoch gelegt. Fang mit GitHub an. Bei einer einzelnen
Datei kannst Du den Dateiinhalt auch online bearbeiten und die
Änderungen direkt abspeichern. Das ist so einfach wie hier ein Post zu
editieren.
Dazu braucht man aber keinen Online-Dienst. Das geht komplett lokal genauso gut.
