Atmel Studio 7 keine Strings??

[Nils K. (flying_nils)]

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

#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

#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?

[Hmmm (hmmm)]

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.

[Nils K. (flying_nils)]

Da es in dem eigentlichen Projekt noch mehr Fehler gab, habe ein neuen 
Projekt erstellt, welches wie folgt aussieht:

#include <avr/io.h>
#include <string>
string test = "";
String test2 = "";
std::string test3 = "";

int main(void)
{
    /* Replace with your application code */
    while (1) 
    {
    }
}

Der Output ist:

C:\Users\nilsk\Documents\GitHub\BS2_Drehzahl\Flash 1627\NandWriter2\NandWriter2\main.cpp(9,10): error: string: No such file or directory
#include <string>

Ich denke mal, dass ein Include path fehlt, bisher ist nur der standard 
Pfad angegeben:

 $(PackRepoDir)\Atmel\ATtiny_DFP\2.0.368\include\

[Hmmm (hmmm)]

Klingt für mich danach, dass Du eine reine C-Toolchain benutzt und 
dementsprechend keine libstdc++ dabei ist.

[Oliver S. (oliverso)]

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

[Nils K. (flying_nils)]

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:

-std=c++20

 nicht erkennt.

Aber dann weiß ich ja jetzt, wo ich es weiter probieren muss.

[Oliver S. (oliverso)]

Die lib braucht offziell mindestens einen 11er gcc, aber der 10er tut es 
nach deren eigenen Angaben auch.

https://blog.zakkemble.net/avr-gcc-builds/

Oliver

[Nils K. (flying_nils)]

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.

[Hmmm (hmmm)]

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?

[Nils K. (flying_nils)]

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:

avr-g++.exe(0,0): error: cannot execute 'as': CreateProcess: No such file or directory
    compilation terminated.
    make: *** [hashtable_c++0x.o] Error 1
    "C:\AVR\avr-gcc-13.2.0-x64-windows\bin\avr-g++.exe" -funsigned-char -funsigned-bitfields -DDEBUG -DF_CPU  -I"C:\Program Files (x86)\Atmel\Studio\7.0\Packs\Atmel\ATtiny_DFP\2.0.368\include" -I"C:\Program Files (x86)\Atmel\Studio\avr-libstdcpp\include"  -Og -ffunction-sections -fdata-sections -fpack-struct -fshort-enums -g2 -Wall  -mmcu=attiny1617  -c -std=c++20 -flto -Wno-volatile -MD -MP -MF "hashtable_c++0x.d" -MT"hashtable_c++0x.d" -MT"hashtable_c++0x.o"   -o "hashtable_c++0x.o" ".././hashtable_c++0x.cc"

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.

[A. B. (Firma: ab) (bus_eng)]

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.

[Nils K. (flying_nils)]

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!

[A. B. (Firma: ab) (bus_eng)]

"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

[Johann L. (gjlayde)]

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:

<atpack>
|--include
|  +--avr
|     +--io*.h
+--gcc
   +--dev
      +--<mcu>
         |--device-specs
         |  +--specs-<mcu>
         +--<mdir>
            |--lib<mcu>.a
            +--crt<mcu>.o

Siehe https://gcc.gnu.org/wiki/avr-gcc#atpack

2) Bei den Compileraufrufen gibt man den Pfad zu den System-Headern an:

avr-g++ ... -isystem <atpack>/include

3) Ebenfalls gibt man den Pfad zum "device-spces" Order an:

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:

avr-g++ -mmcu=attiny1627 -B <atpack>/gcc/dev/attiny1627 -isystem <atpack>/include ...

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.

[A. B. (Firma: ab) (bus_eng)]

@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.

[Johann L. (gjlayde)]

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?

[A. B. (Firma: ab) (bus_eng)]

../ 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 ..

[Johann L. (gjlayde)]

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.

[A. B. (Firma: ab) (bus_eng)]

einige Zeit später ...

Meine Microchip Studios includieren die __-B specs pfade__ mit den 
aktuellen GCC-AVR8-Toolchains nicht automatisch!

<atpack>
|--include
|  +--avr
|     +--io*.h
+--gcc
   +--dev
      +--<mcu>                     !!
         |--device-specs           !!
         |  +--specs-<mcu>         !!
         +--<mdir>                 !!
            |--lib<mcu>.a          !!
            +--crt<mcu>.o          !!

Manuell eintragen erforderlich:

> -B "C:\Microchip\7.0\packs\atmel\ATtiny_DFP\2.0.368\gcc\dev\ <mcu>"

Eintragen in

project | properties | toolchain | c compiler | miscellaneous | other 
flags

project | properties | toolchain | c++compiler | miscellaneous | other
 flags

project | properties | toolchain | linker | miscellaneous | other
 linker flags

Der <mcu> im Eintrag im Pfad ist erforderlich.

Getestet mit  avr-gcc-10.1.0, avr-gcc-11.1.0, avr-gcc-12.1.0 und 
avr-gcc-13.1.0 auf native MS|Win11 und Mint|Oracle-VM|Win7