Hallo zusammen,
ich habe in der Vergangenheit die meiste Zeit in C gearbeitet, musste jetzt durch ein etwas komplexeres Projekt aber auf C++ umsteigen.
Hierbei hab ich unteranderem eine Arduino Library, welche Strings nutzt, als Grundlage verwendet. Allerdings will das Programm einfach nicht kompilieren. String, string, std::string sind alle keine gültigen Datentypen, obwohl ich
1
#include<string.h>
nutze. Ich sitze schon etwas länger an dem Fehler und habe in der Zwischenzeit recht viel aus anderen Foren und Threads probiert. Auch
1
#include<string>
funktioniert nicht. Die Library wird nicht gefunden, was ich erst einmal komisch finde, da string.h ja eigentlich eine c Library ist. Ich habe die alte toolchain auch schon durch die von meiner Arduino Installation ersetzt, welche ja eigentlich in der Lage ist, die Strings zu kompilieren. Aber das ganze war ebenfalls ohne Erfolg.
Man muss dazu sagen, dass ich von toolchains und den tiefen von C++ generell wenig Erfahrung habe und einfach mal vermute, dass ich hier etwas ganz banales übersehe. Kann mir hier jemand weiterhelfen?
Danke für den Tipp, ich habe zwar schonmal angefangen es damit zu probieren, aber dann war ich ja immerhin auf der richtigen Fährte.
Ich habe es jetzt nochmal Probiert zu Implementieren, bekomme aber seeehr viele Fehlermeldungen, obwohl ich es nach der Anleitung gemacht habe. Ich vermute mal, dass ich immer noch eine neuere toolchain Version brauche, da AS bei mir den angegebenen flag:
1
-std=c++20
nicht erkennt.
Aber dann weiß ich ja jetzt, wo ich es weiter probieren muss.
Danke für den link, es scheint soweit fast zu funktionieren. Ein paar Fehler, mit denen ich nichts anfangen kann, kommen aber noch.
Zur Übersichtlichkeit habe ich sie als Screenshot angehangen. Ich vermute mal, dass ich die Toolchain nicht korrekt eingebunden habe, aber ich bin da leider überfragt. Der angegebene Pfad ist: "\avr-gcc-13.2.0-x64-windows\avr\bin", ist das korrekt so?
Edit: Falscher Screenshot, 41407 ist der richtige.
Der angegebene Pfad ist:
"\avr-gcc-13.2.0-x64-windows\avr\bin", ist das korrekt so?
Anscheinend nicht, man sieht doch, dass Atmel Studio versucht, etwas in diesem Verzeichnis, allerdings unterhalb des Atmel-Studio-Verzeichnisses, auszuführen.
Hast Du in der Konfiguration das C: davor vergessen?
Anscheinend nicht, man sieht doch, dass Atmel Studio versucht, etwas in
diesem Verzeichnis, allerdings unterhalb des
Atmel-Studio-Verzeichnisses, auszuführen.
Das ist richtig, da hatte ich den Ordner abgespeichert. Der Fehler ist aber glaube ich, dass ich "\avr\bin" und nicht "\bin" angegeben habe.
Nach der Änderung kam ein Fehler, der mich darauf schließen lässt, dass mein Attiny1627 nicht unterstützt wird, da AS die specs Datei nicht finden kann (sie existiert auch nicht). Ich habe dann den Chip auf einen Attiny1617 umgestellt, welcher ein specs file hat.
Jetzt kommt der nächste Fehler:
1
avr-g++.exe(0,0): error: cannot execute 'as': CreateProcess: No such file or directory
In anderen Threads mit ähnlichen Fehlern, war Teilweise die Rede von Zugriffsproblemen, weswegen ich alles, was ich in den Atmel Programm Ordner getan hatte, in einen normalen Ordner (außerhalb von Programme(x86)) verschoben habe. Ich habe auch keinen Virenscanner, die scheinen da ja auch schonmal was zu blockieren. Am Fehler hat sich aber leider nichts verändert.
Include-Pfad für GCC Compiler sollten keine Leerstellen enthalten. Auch das Atmel/Microchip Studio kann ausserhalb der Windows Systemverzeichnisse installiert werden.
Ob dies ursächlich für die Problme ist kann ich nicht beurteilen.
Eventuell müssen specs Dateien manuell in avr-gcc-13.2.0-x64-windows eingepflegt werden.
Es scheint so, als mein relativ neuer Attiny1627 sowieso noch nicht von der neuen toolchain unterstützt wird, weswegen ich nun einfach die Arduino Library Abgeändert habe, sodass sie mit der Originalen toolchain funktioniert. War zwar ne menge Arbeit, da diese nicht gerade klein war, ging unterm Strich aber schneller als mich weiterhin mit dem Compiler herumzuärgern.
Core avrxmega3 wird erst seit v8 unterstützt; allerdings gibt es auch Back-Ports, etwa beim Ubuntu gcc-avr Paket das avr-gcc-v5.4 enthält. Falls man eine Toolchain ohne avrxmega3 hat, dann muss man avrxmega2 für ATtiny1627 verwenden.
Benutze MicrochipStudio 7.0.2594:
attiny pack 2.0.368 ist unter C:\Microchip\7.0\packs\atmel\ATtiny_DFP\2.0.368 verfügbar
attiny pack 3.1.260 ist unter
C:\Microchip\7.0\packs\Microchip\ATtiny_DFP als .atpack verfügbar, aber warum auch immer nicht entpackt !
Include path $(PackRepoDir)\Atmel\ATtiny_DFP\2.0.368\include ist unter project | properties | toolchain | directories automatisch und korrekt eingetragen als $(PackRepoDir)\Atmel\ATtiny_DFP\2.0.368\include\ und wird auch mit
-I"C:\Microchip\7.0\Packs\Atmel\ATtiny_DFP\2.0.368\include" korrekt eingebunden.
Die drei in meinem Post aufgeführten Dateien werden im eingetragenen pack-pfad aber nicht gefunden. Händisch direkt in die Toolchain kopiert sind sie verfügbar. Offensichtlich ein pack-pfad Problem. War immer so, mit allen neuen ATtiny und ATmega-Typen. Werde bei Gelegenheit versuchen, das Problem genauer zu analysieren.
