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?
Nils K. schrieb:> obwohl ich>> #include <string.h>>> nutze.
string.h hat auch nichts mit C++ zu tun.
Nils K. schrieb:> Auch>> #include <string>>> funktioniert nicht.
Eine präzisere Fehlerbeschreibung (Compiler-Fehlermeldungen) wäre
hilfreich.
Hmmm schrieb:> Eine präzisere Fehlerbeschreibung (Compiler-Fehlermeldungen) wäre> hilfreich.
Nicht nötig. Zum Lieferumfang des avr-gcc gehört keine C++ stdlib. Damit
gibts da kein std::..., und auch sonst nichts, egal, was auch immer.
Arduino hat ein paar eigene C++-Datentypen, z.B. strings, die aber
nichts mit Standard-C++ zu tun haben.
Abhilfe gibts auf github, z.B.:
https://github.com/modm-io/avr-libstdcpp
Oliver
Oliver S. schrieb:> Abhilfe gibts auf github, z.B.:> https://github.com/modm-io/avr-libstdcpp
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.
Nils K. schrieb:> 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?
Hmmm schrieb:> 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.
Nils K. schrieb:> -I"C:\Program Files (x86)\Atmel\Studio\7.0\Packs\Atmel\.."> -I"C:\Program Files (x86)\Atmel\Studio\avr-libstdcpp\include"
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.
Beitrag "cannot read spec file 'device-specs/specs-atmega4808'" und speziell
Beitrag "Re: cannot read spec file 'device-specs/specs-atmega4808'" zeigt wie.
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.
Trotzdem Danke für die Hilfen!
"attiny1627" in die toolchain avr-gcc-13.1.0-x64-windows einpflegen:
Die specs Dateien herunterladen und wie zip entpacken:
https://packs.download.microchip.com
aus dem pack:
/Microchip.ATtiny_DFP.3.1.260.atpack_FILES/gcc/dev/attiny1627/avrxmega3/
die Dateien: crtattiny1627.o und libattiny1627.a
nach toolchain:
C:\Atmel-Toolchain\AVR8\avr-gcc-13.1.0-x64-windows\lib\gcc\avr\13.0.1\av
rxmega3\
kopieren.
und aus pack:
/Microchip.ATtiny_DFP.3.1.260.atpack_FILES/gcc/dev/attiny1627/device-spe
cs/
die Datei: specs-attiny1627
nach toolchain:
C:\Atmel-Toolchain\AVR8\avr-gcc-13.1.0-x64-windows\lib\gcc\avr\13.0.1\de
vice-specs\
kopieren
A. B. schrieb:> "attiny1627" in die toolchain avr-gcc-13.1.0-x64-windows einpflegen:
Man braucht überhaupt nichts "einzupflegen":
1) atpack Datei entZIPpen. Der Dateibaum hat folgende Struktur:
3) Ebenfalls gibt man den Pfad zum "device-spces" Order an:
1
avr-g++ ... -B <atpack/gcc/dev/<mcu>
4) Und man gibt noch den Pfad <mdir> zu den Multilibs an falls sich
dieser von 3) unterscheidet (was bei der obigen atpack-Struktur nicht
der Fall ist).
Für einen ATtiny1627 sieht der Aufruf dann so aus:
GCC ordnet ATtiny1626 unter avrxmega3 ein:
https://gcc.gnu.org/onlinedocs/gcc/AVR-Options.html#avrxmega3
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.
@Johann L. (gjlayde)
Danke für den Hinweis.
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.
A. B. schrieb:> und wird auch mit> -I"C:\Microchip\7.0\Packs\Atmel\ATtiny_DFP\2.0.368\include" korrekt> eingebunden.
Das sollte "-isystem ..." sein, nicht -I weil es sich um ein
System-Include handelt.
> Die drei in meinem Post aufgeführten Dateien werden im eingetragenen> pack-pfad aber nicht gefunden.
Welche drei Dateien?
../ one thread before yours
>"attiny1627" in die toolchain avr-gcc-13.1.0-x64-windows einpflegen:
die Dateien: crtattiny1627.o und libattiny1627.a
...
die Datei: specs-attiny1627
>Das sollte "-isystem ..." sein, nicht -I weil es sich um ein>System-Include handelt.
Das includiert MicrochipStudio dann offenbar falsch ..
A. B. schrieb:> die Datei: specs-attiny1627
In -B muss der Order angegeben werden, der den Ordner "device-specs"
enthält, nicht device-specs selbst.
Und natürlich geht das nur mit ausgepackten / unzippten atpack.