Hallo!
Ich habe heute versucht eine Programmierumgebung unter Linux
einzurichten. Programmieren wollte ich mein STK500.
Ich habe mich also nach entsprechenden Anleitungen umgesehen und alles
aus den Paketquellen installiert. Leider klappte es mit dem kompilieren
nicht zufriedenstellend. Ich entschied mich also dafür alles zu
deinstallieren und aktuelle Versionen von Hand zu installieren.
Was habe ich genau gemacht?
1. AVR Toolchain direkt von Atmel heruntergeladen und in
/home/max/Programming/ entpackt
2. avrdude 6.0.1 heruntergeladen und manuell installiert
3. eclipse-cdt aus den Paketquellen installiert (da ziemlich aktuelle
Version)
4. das eclipse-avr Plugin über eclipse installiert
5. Unter eclipse Einstellungen AVR / Paths die Pfade überprüft
6. Die AVR Header Files wurden (natürlich) nicht gefunden. Ich habe den
entsprechenden Pfad
"/home/max/Programming/avr8-gnu-toolchain-linux_x86_64/avr/include"
vergeben
Nun ist es leider so, dass keine der eingebundenen Bibliotheken gefunden
wird. Der Pfad ist richtig und die Bibliotheken sind auch alle
vorhanden. Wie soll ich diesem Fehler auf die Schliche kommen?!
Ich freue mich auf eure Hilfe!
Gruß Max
edit: Ich nutze Ubuntu 13.10 64bit
Hallo,
ich habe die avr tools unter /usr/local/avr also:
/usr/local/avr/avr8-gnu-toolchain-linux_x86
(für gcc tool chain download von atmel)
und
/usr/local/avr/bin
(für avrdude, avarice, avr-gdb)
Bei mir wurden die Pfade automatisch gefunden:
Window -> Preferences -> AVR -> Paths:
/usr/local/avr/avr8-gnu-toolchain-linux_x86/bin
/usr/local/avr/avr8-gnu-toolchain-linux_x86/avr/include
(die Source ist bei mir auf "System")
Mit einer Installation unter Home habe ich leider keine Erfahrung.
(Ubuntu 12.04, 32 bit :-) )
Hallo!
Habe die Toolchain nun auch mal unter /usr/local/avr gepackt. Nun findet
eclipse den Pfad auch von alleine.
Die Bibliotheken werden trotzdem nicht eingebunden. Das Einbinden unter
Verwendung des ganzen Pfades funktioniert augenscheinlich (es gibt aber
noch mehr Probleme - dazu später, sonst gibt es hier ein Durcheinander).
Die Source steht bei mir ebenfalls auf "System". Die weiteren Pfade:
AVR-GCC: /usr/bin
GNU make: /usr/bin
AVRDude: /usb/local/bin
Eigentlich wollte ich drum herum kommen mit dem Atmel Studio in der
virtuellen Maschine arbeiten zu müssen :(
Gruß Max
Ein Build wirft erst einmal folgende Fehlermeldungen aus:
1
make: *** [main.o] Error 1 C/C++ Problem
2
make: *** [test.elf] Error 1 C/C++ Problem
3
Symbol 'PortA' could not be resolved main.c /KondiTester line 65 Semantic Error
4
Symbol 'DDRA' could not be resolved main.c /KondiTester line 53 Semantic Error
Und die Konsolenausgabe ist ganz traurig:
1
**** Build of configuration Release for project KondiTester ****
2
3
Nothing to build for project KondiTester
Das sind Fehlermeldungen, die ich mit meiner ersten Installation auch
schon hatte. Weil ich diese mit googeln nicht lösen konnte, oft aber den
Hinweis gefunden habe die Paketquellen hierfür nicht zu nutzen, habe ich
alles per Hand noch einmal gemacht.
Programmieren möchte ich den ATMega 8.
Gruß Max
#include <avr/io.h>
#include <avr/interrupt.h>
#include <stdlib.h>
#include <inttypes.h>
sind aber Header, keine libs :-).
OK, hast Du ein C Projekt für "AVR Cross Target" erzeugt (project type)?
Oder ein "normales"?
P.S.: zum Test habe ich gerade mal die scanf_min library hinzugelinkt.
Invoking: AVR C Linker
avr-gcc -Wl,-Map,StepUp.map -mmcu=attiny261a -o "test.elf" ./main.o
-lscanf_min
Finished building target: test.elf
Sollte also tun.
Haha das war das Wort, welches ich gesucht hatte! :) Beim Schreiben bin
ich in mich gegangen aber dann bei meiner ENtscheidung geblieben. Danke
für die Korrektur!
Das Projekt habe ich als "C Project" und "AVR Cross Target Application"
angelegt.
Gruß Max
Such mal nach meinem nick einen post vom 31.12.13 :-)bin grad unterwegs,
aber in dem post gibt es eine anleitung zum thema. Problem koennte die
uebernahme des device sein, dazu musst du manuell ein paar settings
nachziehen.
//hufnala
Lösch mal das Symbol und versuche mit Project -> Properties -> AVR ->
Target Hardware den MCU Type einzustellen. Wieso man da die Symbole
manuell einstellen soll, ist mir schleierhaft.
Was gibt ein Build auf deiner Console aus?
Hallo,
Auslesen klappt wunderbar! Die Kommunikation mit dem STK500 klappt also.
Die Ausgabe ist sehr dürftig.
1
**** Build of configuration Release for project KondiTester ****
2
3
Nothing to build for project KondiTester
Ich habe nun mal ein Standard C Projekt erstellt und den Code dorthin
kopiert. Dem Projekt habe ich dann noch den Pfad für die Bibliotheken
mitgegeben. Diese werden damit gefunden.
Folgende Fehler bekomme ich:
1
Symbol 'DDRA' could not be resolved main.c /Konditester line 53 Semantic Error
2
Symbol 'PortA' could not be resolved main.c /Konditester line 65 Semantic Error
3
make: *** [test.elf] Error 1 C/C++ Problem
4
make: *** [main.o] Error 1 C/C++ Problem
5
make: *** [main.o] Error 1 Konditester C/C++ Problem
6
‘DDRA’ undeclared (first use in this function) main.c /Konditester line 53 C/C++ Problem
7
‘PortA’ undeclared (first use in this function) main.c /Konditester line 65 C/C++ Problem
Dafür gibt die Konsole mehr aus:
1
20:08:33 **** Incremental Build of configuration Debug for project Konditester ****
Bei mir kommt
"Invoking: AVR Compiler"
bei Dir nicht ;-).
Wenn Du den GNU C für Dein x86 Linux benutzt, wird da kein AVR Exec raus
kommen. Bitte den richtigen C-Projekt Typ nehmen,
Das mit den Editor Problemen nach einem MCU Type wechsel habe ich
inzwischen auch verstanden. Wenn man zuerst in "Project -> Properties ->
AVR -> Target Hardware" auf "Restore Defaults" auswählt und applied und
anschließend den Prozessor Typ auswählt, verschwinden meine roten
Kreuze.
Compilieren tat aber auch mit den roten Dingern.
Wenn Du also ein AVR Cross Target Application Projekt nimmst, den
Prozessor Type auf ATMega8 einstellst, dann sollten andere Meldungen bei
einem Build kommen.
Das liegt daran, dass ich testweise gerade auch ein C Projekt angelegt
habe. Aus diesem stammt die Konsolenausgabe, daher der C Kompiler.
Habe erst im Anschluss überlegt dass das Quatsch war.
Gruß Max
Achim K. schrieb:> Lösch mal das Symbol und versuche mit Project -> Properties -> AVR ->> Target Hardware den MCU Type einzustellen. Wieso man da die Symbole> manuell einstellen soll, ist mir schleierhaft.>
Ja, den Beitrag meinte ich. Warum es so ist weiss ich nicht, aber meine
Umgebung (Hatte es beim tiny2313 jetzt wieder)akzeptiert kein manuelles
setzen oder auslesen ueber avrdude fuer ein device das vom Standard bei
Generierung des Projects angegeben ist. Gilt auch bei einem neuen
Projekt, bei mir zieht es immer den mega8 der irgendwo als init fuer ein
neues Projekt hinterlegt ist.
Was sagt <f2> auf den portnamen, kommt das richtige device.h durch die
io.h oder nicht?
Bei mir kommt die iom8.h und die ist ggf. falsch. Sseltsam ist
allerdings ein device ohne porta keine ahnung ob es so eine ioxxx..h
gaebe.
//hufnala
Ich befürchte, dass hier erst einmal der richtige Projekt Typ ausgewählt
werden muss. Dann der MCU Typ. Und ob dann die roten Kreuze kommen wird
man sehen.
Ein ATmega 8 hat kein PORTA, zumindest steht das so in der Doku. Daher
gibt es den PORTA auch nicht in den zugehörigen Headern.
Achim K. schrieb:>> Ein ATmega 8 hat kein PORTA, zumindest steht das so in der Doku. Daher> gibt es den PORTA auch nicht in den zugehörigen Headern.
Hm, gut das ich immer das datenblatt daneben liegen habe, auswendig
merke ich mir das nicht :-)) war ja ein perfektes beispiel...
//hufnala
Oh mein Gott! Wie peinlich! Ich hatte einfach blind port A verwendet,
bzw. verwenden wollen...
Werde ich später mal testen.
Das löst allerdings nicht das Problem mit den header Dateien!
Gruß Max
Ich habe gerade ein neues C-Project "AVR Cross Target Application"
"Empty Project" angelegt. Bei "weiter" kann man im letzten Dialog den
"MCU Type" auf "ATmega8" setzen. Danach habe ich ein "main.c" mit
folgendem Inhalt erzeugt:
#include <avr/io.h>
#include <avr/interrupt.h>
#include <stdlib.h>
#include <inttypes.h>
int main()
{
PORTB = 0;
}
Das Compiliert ohne Fehlermeldungen.
make all
Building file: ../main.c
Invoking: AVR Compiler
avr-gcc -Wall -g2 -gstabs -O0 -fpack-struct -fshort-enums
-ffunction-sections -fdata-sections -std=gnu99 -funsigned-char
-funsigned-bitfields -mmcu=atmega8 -DF_CPU=1000000UL -MMD -MP
-MF"main.d" -MT"main.d" -c -o "main.o" "../main.c"
Finished building: ../main.c
Building target: test.elf
Invoking: AVR C Linker
avr-gcc -Wl,-Map,test.map -mmcu=atmega8 -o "test.elf" ./main.o
Finished building target: test.elf
Invoking: AVR Create Extended Listing
avr-objdump -h -S test.elf >"test.lss"
Finished building: test.lss
Invoking: Print Size
avr-size --format=avr --mcu=atmega8 test.elf
AVR Memory Usage
----------------
Device: atmega8
Program: 86 bytes (1.0% Full)
(.text + .data + .bootloader)
Data: 0 bytes (0.0% Full)
(.data + .bss + .noinit)
Finished building: sizedummy
08:08:25 Build Finished (took 619ms)
Es gibt auch keine roten Kreuze.
Ich benutze
----------------------------------
Eclipse IDE for C/C++ Developers
Version: Kepler Service Release 1
Build id: 20130919-0819
----------------------------------
AVR Eclipse Plugin 2.4.1
------------------------------
avr8-gnu-toolchain-3.4.3.1072-linux.any.x86.tar.gz
----------------------------------
Wenn das in Deiner Eclipse / AVR Plugin Installation nicht tut, wäre es
gut, die Fehlermeldungen zu haben. Leider habe ich keine Möglichkeit,
"kurz mal die 64Bit Version zu testen".
Na dann kann Max jetzt ja an drei Fronten kämpfen ;-).
Mit roten Kreuzen, die man aber nur vielleicht bekommt,
mit Arduino (komplett veraltete Tool Chain und deren
Installationsanleitung),
und mit PORTs, die sein Chip nicht hat :-).
Also Max, Du darfst jeden Unsinn machen. Wenn Du aber unter Verwendung
der richtigen Tool Chain (AVR Cross Target Application) und der passend
MCU (ATmega8) weiter Probleme hast, dann bitte mit nur den
Fehlermeldungen :-).
>Mit roten Kreuzen, die man aber nur vielleicht bekommt,>mit Arduino (komplett veraltete Tool Chain und deren>Installationsanleitung),
Also ich habe die Arduino IDE installiert, danach wie in der
Installationsanleitung die Eclipse Plugins. Funktioniert wunderbar.
Was interessiert mich da, ob die Toolchain veraltet ist?
Dem C-Programm ist es egal.
Und ich habe einfach die Atmel GNU-AVR toolchain, AVRdude, Eclipse
Kepler CDT und das AVR Plugin installiert. Und es tat auch, wenn man es
richtig bedient (eben AVR Cross Toolchain Projekt, MCU Type).
Wenn man aber die konkreten Fehlermeldungen oben sieht (falsche Tool
Chain (x86 statt AVR) und falsche PORTs), dann hat das wohl eher nichts
damit zu tun, ob man die Arduino Dinge benutzt oder nicht.
Und welche Fehler aktuell "übrig" geblieben sind hat Max bis jetzt noch
nicht geschrieben. Wir werden ja sehen, ob der Ansatz "teste
unterschiedliche Toolchains aus, bis ein tut" oder "arbeite dich durch
die Fehlermeldungen durch" zur Lösung führt.
Wie aber Arduino nicht vorhandene PORTs oder die Verwendung der x86 Tool
Chain behebt, weiß ich nicht.
Hallo!
Ich freue mich über die vielen Hilfestellungen!
Nun noch einmal ganz strukturiert:
1. Ich habe die 64 bit Toolchain mal gegen die "normale" 32 bit
Toolchain getauscht. Nicht, dass es nur deswegen Probleme gibt. Eclipse
hat direkt den richtigen Pfad
(/usr/local/avr/avr8-gnu-toolchain-linux_x86/avr/include) für die Header
Dateien gefunden
2. Neues C Projekt "AVR Cross Target Application" "Empty Project"
angelegt. (als Toolchain wird hier "AVR-GCC Toolchain angezeigt!)
3. Im letzten Schritt wurde "ATmega8" als "MCU Type" eingestellt.
4. "main.c" mit dem selben Inhalt, wie aks erstellt:
1
#include <avr/io.h>
2
#include <avr/interrupt.h>
3
#include <stdlib.h>
4
#include <inttypes.h>
5
6
int main()
7
{
8
PORTB = 0;
9
}
5. Gelbe Fragezeichen bei den include's. Fehlermeldungen nach dem Muster
"Unresolved inclusion: <avr/io.h>".
6. Meldung bei PortB "Symbol 'PORTB' could not be resolved."
@ hufnala: Bei <f2> auf den Portnamen passiert gar nichts.
7. Trotzdem versucht zu bauen
8. Folgende Fehlermeldungen:
1
make: *** [test.elf] Error 1 C/C++ Problem
2
make: *** [main.o] Error 1 C/C++ Problem
3
Symbol 'PORTB' could not be resolved main.c /einrichtungTest line 8 Semantic Error
4
fatal error: avr/io.h: No such file or directory main.c /einrichtungTest line 1 C/C++ Problem
9. Konsolenausgabe:
1
11:48:44 **** Build of configuration Debug for project einrichtungTest ****
../main.c:1:20: fatal error: avr/io.h: No such file or directory
7
compilation terminated.
8
make: *** [main.o] Error 1
9
10
11:48:44 Build Finished (took 61ms)
So, wie ich das sehe, wird wegen der fehlenden io.h abgebrochen.
Wenn ich nun den ganzen Pfad bei den includes angebe, werden die Header
Dateien gefunden. PORTB bleibt weiterhin unbekannt. Fehlermeldungen:
1
make: *** [test.elf] Error 1 C/C++ Problem
2
make: *** [main.o] Error 1 C/C++ Problem
3
Symbol 'PORTB' could not be resolved main.c /einrichtungTest line 8 Semantic Error
4
fatal error: avr/sfr_defs.h: No such file or directory einrichtungTest line 99, external location: /usr/local/avr/avr8-gnu-toolchain-linux_x86/avr/include/avr/io.h C/C++ Problem
Konsolenausgabe:
1
11:50:56 **** Incremental Build of configuration Debug for project einrichtungTest ****
/usr/local/avr/avr8-gnu-toolchain-linux_x86/avr/include/avr/io.h:99:26: fatal error: avr/sfr_defs.h: No such file or directory
8
compilation terminated.
9
make: *** [main.o] Error 1
10
11
11:50:56 Build Finished (took 60ms)
Es gibt also weiterhin offene Fragen:
1. Warum wird der eingestellte Pfad nicht genutzt, um dort nach den
Header Dateien zu suchen?
2. Was ist das Problem bzgl. avr/sfr_defs.h?
3. Das PORTB Problem.
Gruß Max
In meinen avr includes steht die "sfr_defs.h" im Verzeichnis
"include/avr" neben der/ genauso wie die "io.h".
Stehen bei dir auch beide Dateien dort? Hast Du lese Berechtigungen?
Bei mir wird diese Datei gefunden, ohne dass ich die include
Verzeichnisse ändere. Was hast Du den für die include Verzeichnisse
genommen?
Bei mir ist es (project -> preferences -> C/C++ General -> Paths and
Symbols -> includes -> GNU C)
... /lib/gcc/avr/4.8.1/include
... /lib/gcc/avr/4.8.1/include-fixed
... /avr/include
Was steht bei Dir und was hast Du ergänzt?
Hallo,
"sfr_defs.h" befindet sich im selben Verzeichnis wie auch io.h.
Leseberechtigungen sind vorhanden.
Unter project -> properties -> C/C++ General -> Paths and
Symbols -> includes -> GNU C standen offensichtlich noch Pfade aus der
alten Installation:
1
/usr/lib/gcc/avr/4.7.2/include
2
/usr/lib/gcc/avr/4.7.2/include-fixed
Folgende Eingetragen habe ich ergänzt (die vorhandenen kann ich nicht
entfernen?!):
Die "crtm8.o" zcheint das Problem zu sein. Ich habe mein System
durchsucht und finde sie an zwei Orten:
1. /home/max/Downloads/avr8-gnu-toolchain-linux_x86/avr/lib/avr4 (hier
habe ich den Download entpackt, das eclipse diese Datei nicht findet ist
klar)
2. /usr/local/avr/avr8-gnu-toolchain-linux_x86/avr/lib/avr4 (das ist
wohl der Pfad, der eigentlich zum Ziel führen sollte) - Warum sucht
eclipse nicht selbstständig tiefer?
Gruß Max
Ohne auf ein spezielles Problem einzugehen hier mal mein Vorgehen, mit
dem ich meine Entwicklungsumgebung unter Debian-basierenden Systemen
jetzt schon mehrfach ohne Verrenkungen eingerichtet habe:
1. Eclipse IDE for C/C++ Developers von eclipse.org runterladen und
entpacken, OpenJDK per Paketverwaltung installieren (openjdk-7-jdk)
2. GCC, AVR-Libs und avrdude installieren (gcc-avr avr-libc avrdude)
3. Eclipse starten, http://avr-eclipse.sourceforge.net/updatesite zu den
Quellen hinzufügen und Plugin installieren, Eclipse neustarten
4. Projekt anlegen (New Project > C Project > AVR Cross Target
Application), MCU und Taktfrequenz auswählen.
So purzeln schonmal funktionierende Hexfiles raus. Vor dem Flashen aus
Eclipse muss noch eine avrdude-Konfiguration angelegt werden, beim
ersten Versuch kommt ein Hinweis darauf, wie man das macht.
Je nach Programmer müssen evtl. noch die Berechtigungen auf das Device
angepasst werden.
Hallo cyprius,
danke für deinen Beitrag!
Das hilft mir allerdings leider nicht weiter. Vielleicht hilft es einem
anderen bei der Suche nach einem möglichen Vorgehen.
Gruß Max
Nunja, es sieht ein bisschen so aus, als würdest du dich da in Details
verrennen. Das dürfte inzwischen auch so speziell sein, dass da niemand
mehr per Erfahrung aushelfen kann.
Hast du mal versucht, in einer virtuellen Maschine einen frischen,
geordneten Installationsprozess durchzuführen? Wenn du auf die extern
beschafften Libraries bestehst, würde es auch Sinn machen, den ganzen
Vorgang zu dokumentieren. Dann kannst du das auf "deinem" System
jederzeit wieder reproduzieren.
Nein, an Installationen gab es bisher die über Paketquellen und aufgrund
der vielen Warnhinweise eine manuelle.
Dokumentieren macht sicherlich Sinn, nur würde ich gerne etwas
funktionierendes aufschreiben :)
Gruß Max
"/usr/lib/gcc/avr/4.7.2/../../../avr/bin/ld"
und
"/usr/local/avr/avr8-gnu-toolchain-linux_x86/avr/lib/avr4"
Ich denke, jetzt weiß ich, was der Unterschied ist. Du hast die
debian/ubuntu Pakete installiert (siehe oben "alles aus den
Paketquellen) und dann die Tool Chain von Atmel. Jetzt hast Du zwei :-).
Entferne mal die überflüssigen Pakete!
Lasse das AVR Plugin die Pfade neu suchen (Window -> Preferences -> AVR
-> Paths), sollten dann alle auf
"/usr/local/avr/avr8-gnu-toolchain-linux_x86/..." zeigen. Dann neues
C-Projekt ..., c-file kopieren und nach weiteren Fehlern Ausschau halten
:-).
Hallo,
habe gcc-avr etc. gelöscht (aus den Paketquellen).
Nun findet eclipse AVR-GCC auch unter dem selben Pfad, wie die Header
Dateien. Hier alle Pfade:
Source ist jeweils SYstem.
GNU make und AVRDude haben sich nicht geändert!
Bei den Projekteigenschaften wurden nun auch die Pfade
1
/usr/lib/gcc/x86_64-linux-gnu/4.8/include
2
/usr/lib/gcc/x86_64-linux-gnu/4.8/include-fixed
durch das System hinzugefügt. Ich konnte meine Eintragungen entfernen,
da sie nun doppelt waren.
Ausgabe der Fehler:
1
make: *** [test.elf] Error 1 C/C++ Problem
2
make: *** [main.o] Error 1 C/C++ Problem
3
make: *** [einrichtungTest.elf] Error 1 C/C++ Problem
Zwei Warnungen besagen, dass die nicht löschbaren Einträge aus den
Projekteigenschaften auf die GCC Version 4.7.2 nicht zu finden sind
(wurde ja auch gelößcht):
1
Invalid project path: Include path not found (/usr/lib/gcc/avr/4.7.2/include-fixed). einrichtungTest pathentry Path Entry Problem
2
Invalid project path: Include path not found (/usr/lib/gcc/avr/4.7.2/include). einrichtungTest pathentry Path Entry Problem
Konsolenausgabe sieht gut aus:
1
13:42:42 **** Incremental Build of configuration Debug for project einrichtungTest ****
Aber ein .elf file wird erzeugt. Und avrdude sollte in 6.01 mit den
entsprechende configure switches compiliert .elf direkt lesen können.
Dazu muss man dann "${CWD}/${BuildArtifactFileName}" unter "Project ->
Properties -> AVR -> AVR Dude -> Flash / EEPROM -> from flash memory
image file" "${CWD}/${BuildArtifactFileName}" eingeben.
Es gibt sicher auch Alternativen, die hex aus elf files erzeugen
(avrdude älter oder ohne elf Unterstützung compiliert), aber da habe ich
leider keine Erfahrung.
Es läuft!!!
Tausend Dank Achim! Für deine sehr kompetente Hilfe und dafür, dass du
nicht aufgegeben hast ;-)
Jetzt kann ich mich endlich mal wieder der Entwicklung widmen. Toll!
Gruß Max
Gern geschehen!
Ich habe erst vor ein paar Wochen auch auf Eclipse gewechselt, da in AS
6.1 die debugWire und AVRDragon Unterstützung für den ATTiny861A sehr
problematisch war. Bei mir dauerte es 3 Tage, bis ich endlich den
AVRDragon mit debugWire einsetzen konnte. Aber immerhin noch besser wie
beim AS 6.1; da habe ich nach 2 Monaten aufgegeben. Für andere
Prozessoren soll es aber gehen.
Gruß
Achim
Thread beobachten
Seitenaufteilung abschalten