Moin Forum!
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
Fred F. schrieb:> 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.
Harald K. schrieb:> https://de.wikipedia.org/wiki/Git
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.😆
Frank O. schrieb:> Allerdings will ich so was> nicht öffentlich machen.
Musst Du auch nicht. Git läuft komplett lokal auf Deinem Rechner, nichts
zwingt Dich dazu, Deine "commits" auch irgendwohin zu "pushen".
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.
Frank O. schrieb:> Ist das nur ein blöder Zufall, dass das jetzt aufgetreten ist oder> handhabt Arduino die Dateienverwaltung nun anders?
War schon immer so. Projektname = Verzeichnis = Dateiname
(ohne Suffix, DAU Windows Nutzer sehen die Dateiendungen nicht)
Alexander schrieb:>> 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ß.
Manfred P. schrieb:> 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.
Hallo,
nur für das Protokoll, denn hier wird etwas beschrieben was so wie
dargestellt nicht stimmen kann.
Frank O. schrieb:> 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.
Manfred P. schrieb:> Alexander schrieb:>>> 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.
Veit D. schrieb:> Wo er recht hat, hat er recht.
Mag alles stimmen, aber vorher hatte ich noch nicht bemerkt dadurch
Probleme zu haben.
Veit D. schrieb:> 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.
Manfred P. schrieb:> Verzeichnis von ...\Arduino_IDE\Programme\OLED_i2C_Test
Da Backslash im Pfad vorhanden: dann doch wenigstens
OLED_i2C_Test.ino_20200515.txt
Manfred P. schrieb:> 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.
Aber Danke für deinen Tipp!
Frank O. schrieb:> 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.
Harald K. schrieb:> 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. Und zum Anschauen der Historie genügt mir das
mitgelieferte gitk.
Hans W. schrieb:> 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.
Harald K. schrieb:> 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.
Frank O. schrieb:> 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.
Jörg W. schrieb:> Allerdings könnte es sein, dass Microsoft deinen Code zum Füttern von> irgendwelchen LLMs benutzt,
An dieser Stelle verweise ich noch mal auf den Konkurrenten GitLab.
Frank O. schrieb:> 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?).
Harald K. schrieb:> 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.
Harald K. schrieb:> 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. :-)
Jörg W. schrieb:> 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.
Harald K. schrieb:> 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.
Jörg W. schrieb:> 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.
Norbert schrieb:> Block copy
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.
Frank O. schrieb:> ... jedenfalls konnte ich sonst immer> "Timer.ino;Timer1.ino; Timer2.ino ..." alle im selben Ordner speichern,> ohne, dass es Fehler gab.
Es git auch ohne Git ;-) Veit und Fred haben ihr praktisches Vorgehen ja
schon aufgezeigt. Ich mache es ähnlich:
C:\Timer\
... Timer.ino
... Timer01_ino
... Timer02_ino usw.
StefanK schrieb:> Es git auch ohne Git
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.
Harald K. schrieb:> Ja, das ist dann aber umständlicher und potentiell fehlerträchtiger> Handbetrieb.
Ja, diese Arbeitsweise finde ich auch schon lange sehr fehlerträchtig.
Harald K. schrieb:> 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.
Harald K. schrieb:> 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.
StefanK schrieb:> bin ich vermutlich schon bei timer_100_ino oder ...
Wenn man es immer weiter vor sich herschiebt, schiebt man es immer
weiter vor sich her.
"Was Du morgen kannst verschieben, lass' übermorgen auch noch liegen"
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.
Alexander schrieb:> Ich denke auch Harald K. (kirnbichler) hat die psychologische> Einstiegshürde zu hoch gelegt.
Was?!
> Fang mit GitHub an.
Das ist doch himmelschreiender Unfug. Statt git lokal zu verwenden,
gleich den Kram auf einen Git-Server schieben und zu veröffentlichen ...
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.
…in weniger als 111 Zeilen.
Für die GUI Benutzer:
Einfach ›git gui‹ und ›gitk‹ nutzen und die Kommandos gegen:
›Click‹,›Click‹,›Click‹,›Click‹,›Click‹,›Click‹,›Click‹,›Click‹,›Click‹,
›Click‹,›Click‹,›Click‹,›Click‹,›Click‹,›Click‹,›Click‹
tauschen…
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.
Thread beobachten
Seitenaufteilung abschalten