Forum: Compiler & IDEs Anfänger in C Grundlagenfragen


von Karl-alfred R. (karl-alfred_roemer)


Lesenswert?

Hallo zusammen,

ich habe bisher ein wenig Assembler/ATMEGA8/AVR-Studio gemacht.
Einige kleinere Projekte wurden erfolgreich beendet. Aber ich habe
festgestellt, dass mit zunehmender Programmgröße die Programme doch
schnell unübersichtlich wurden. Insbesondere die Benennung von Vari-
ablen und Labels und dass die Register schnell "verbraucht" waren.

Deshalb versuche ich nun auf GCC umzusteigen. Habe winAVR installiert
und das erste Beispiel-Programm des GCC-Tutorials compiliert und in
den Kontroller geladen. Funktioniert alles prächtig.
Anschließend habe ich mir die Dateien angeschaut, die dabei erzeugt
wurden. Für die Paar Zeilen sind das eine ganze Menge, was die
Angelegenheit für mich als Anfänger sehr unübersichtlich macht.
Während es in Assembler nur die Dateien *.asm und die entsprechenden
Hex-Dateien gibt, finde ich nach compilierung des C-Programmes:
*.aps, *.aws, *.c, Makefile, *.eep, *.elf, *.hex, *.lss, *.map, *.o,
und *.o.d

Die Dateien mit den Endungen *.c und *.hex sind klar.
APS ist glaube ich eine Projekt-Datei, die irgendwie Informationen
über das gesamte Projekt enthält. Habe die Datei mal in Notepad
geöffnet und irgendwie erschließt sich mir der Sinn der Datei
nicht richtig. Hier stehen auch die ganzen Register r1-r32 drin.
Was haben die in der Projekt-Datei verloren?
Die AWS-Datei sagt mir nicht viel. Scheinen  irgendwie Projekt-
Dateien zu sein.
eep, elf, lss, map und o.d. sagen mir rein garnichts.
In der map-Datei scheinen irgendwelche Adressen drin zu stehen.
O sind Objektdateien. Wofür braucht ma die überhaupt?
Ich vermute mal, dass ich mit all diesen Dateien normalerweise
nichts zu tun habe.

Das komplizierteste sind aber die Map-Dateien. Habe eben danach
gegoogelt und gefunden, dass hier eine Menge Informationen zwischen
Dateiabhängigkeiten und Informationen wie von welchem Compiler
welche Datei mit welchen Optionen kopiert wird.

Die Make-Datei meines Programmes wurde von irgendwem (AVR-Studio
oder dem avr-gcc? Vermutlich beide) automatische erstellt, anhand
der Angaben bei der Projekterstellung und welche Datei in welcher
anderen Includiert wird.

In Turbo-Pascal ganz früher gab es eine Quellcode-Datei, vielleicht
paar eingebundene Dateien und daraus wurde dann die Exe compiliert.
Irgendwie wusste das System ganz alleine, was wie von wem wie
gemacht wird, und wie was zusammenhängt.

Kommt es in der Praxis vor, dass man die Make-Datei in gcc selbst
bearbeiten muss, oder wird die immer automatisch erstellt? Warum
braucht man in anderen Entwicklungsumgebungen diese ganzen Dateien
nicht?

Danke für Eure Hilfe und VG
Karl

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Karl-alfred Römer schrieb:

> APS ist glaube ich eine Projekt-Datei, die irgendwie Informationen
> über das gesamte Projekt enthält.

Ja, AWS ist ähnlich gelagert.  Kenne mich mit AVR Studio nicht so
aus, ich glaube APS enthält alle Informationen zu deinem Projekt
(daraus wird dann u. a. auch das Makefile generiert), während AWS
so eine Art Statusinformation ist, womit du zuletzt alles gearbeitet
hast.

> Hier stehen auch die ganzen Register r1-r32 drin.
> Was haben die in der Projekt-Datei verloren?

Da musst du wohl die Schöpfer von AVR Studio fragen.

> eep, elf, lss, map und o.d. sagen mir rein garnichts.

ELF ist eigentlich ein Objekt-Dateiformat, damit werden alle
Objektmodule, Archive und auch das fertige Binary (der ausführbare
Code) abgelegt.  Unter Unix (wo GCC her kommt) bekommen ausführbare
Dateien gar keinen Suffix (sie bilden dann direkt den möglichen
Kommandonamen).  Da das gerade mit Windows-Nutzern aber zu morali-
scher Konfusion führt :), hat sich dort für diese Datei halt die
Endung .elf eingebürgert (auch wenn technisch gesehen .a- und .o-
Dateien ebenfalls vom Typ ELF sind).

Die .elf-Datei enthält den gesamten Programmcode sowie die Debug-
informationen und die Symboltabelle.  Aus dieser Datei werden die
anderen dann noch abgeleitet: .hex (Intel-Hex-Repräsentation des
Programmcodes), .eep (Intel-Hex-Datei mit den Intialwerten für
den EEPROM, falls gewünscht).

Die Symboltabelle einer ELF-Datei kann man sich mit dem Tool
avr-nm ansehen.  Dort steht die Zuordnung der Symbole zu den
Speicheradressen.  Da dies sehr häufig gewünscht wird (bei anderen
Compilern nennt sich das eine Map-Datei), wird sie mit dem Suffix
.sym automatisch mit angelegt.  (OK, vielleicht nicht vom AVR
Studio, weiß ich gerade nicht, aber das WinAVR-Makefile-Template
enthält dafür eine Regel.)

.lss ist eine Disassemblierung der .elf-Datei, wobei der Disassembler
versucht, an Hand der Debuginformationen den C-Quellcode zwischen
das Disassemblerlisting reinzustreuen.  Je nach Optimierung klappt
das mehr oder minder schlecht, da die Optimierung halt dazu führt,
dass der ausführbare Code alles andere als ein lineares Abbild des
Quellcodes wird.

> In der map-Datei scheinen irgendwelche Adressen drin zu stehen.

Vergiss diese Datei erstmal.  Meine Meinung: sie taugt für Leute,
die am Linker selbst arbeiten oder Linkerscripts verändern möchten;
für Anfänger ist sie mit ihrer Fülle an Daten völlig unggeignet.

> O sind Objektdateien. Wofür braucht ma die überhaupt?

Die entstehen einfach zwischendrin beim Compilieren.  Es sind
verschiebliche Objektmodule, die dann anschließend vom Linker
zusammen mit den Bibliotheken verarbeitet werden, um den Code
und die Daten auf ihre endgültigen Adressen zu platzieren.  Solch
ein Konzept gibt es auch bei Assemblerprogrammierung schon lange
(damit man mit mehreren Quelldateien arbeiten kann, die separat
assembliert werden), nur halt nicht beim Primitiv-Atmel-Assembler.

> Kommt es in der Praxis vor, dass man die Make-Datei in gcc selbst
> bearbeiten muss, oder wird die immer automatisch erstellt?

Standardmäßig erstellt AVR Studio das Makefile immer wieder neu (aus
den Angaben in der APS-Datei), allerdings kann man damit nur mehr
oder minder Standardaufgaben erledigen.  Wenn man mehr modifizieren
möchte, kann man im AVR-Studio-Projekt sagen, dass man mit einem
eigenen Makefile arbeiten möchte.  Dann kannst du entweder das vom
AVR Studio erzeugte Makefile als Basis fürs Editieren nehmen, oder
das bei WinAVR mitgelieferte Template, oder du lässt dir eine
Initialversion vom Tool Mfile erzeugen.

Aber für den Anfang wirst du das erstmal nicht brauchen.

von Karl-alfred R. (karl-alfred_roemer)


Lesenswert?

Hm. Das ist schon alles sehr starker Tobak. (Für meine Verhältnisse)
Während ich auf Antworten gewartet habe, habe ich schon mal weiter
gesucht nach "Anfänger GCC".

und habe da eine Zip-Datei von Peter Danneger gefunden, die 1wire
implementiert: http://www.mikrocontroller.net/attachment/4550/1wire.zip

Ich habe die Datei herunter geladen und in ein Verzeichnis
extrahiert. c:\1wire

Dann habe ich ein neues Projekt erstellt, alle Source-Files
und alle Headerfiles im Projektfenster kopiert. Das Initial-File
habe ich 1Wire.c genannt und den Inhalt von 1wire.c dort hinein
kopiert und dann einen Built versucht. Mit dem Ergebnis:

Build started 12.8.2009 at 21:25:45
Makefile:51: warning: overriding commands for target `1wire.o'
Makefile:48: warning: ignoring old commands for target `1wire.o'
avr-gcc.exe  -mmcu=atmega8 -Wall -gdwarf-2 -Os -std=gnu99 
-funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -MD -MP 
-MT 1wire.o -MF dep/1wire.o.d  -c  ../../1WIRE.C
cc1plus.exe: warning: command line option "-std=gnu99" is valid for 
C/ObjC but not for C++
In file included from ../../1WIRE.C:9:
../../main.h:11:16: error: io.h: No such file or directory
../../main.h:12:23: error: interrupt.h: No such file or directory
../../main.h:13:20: error: signal.h: No such file or directory
../../1WIRE.C: In function 'unsigned char w1_reset()':
../../1WIRE.C:24: error: 'PORTD' was not declared in this scope
../../1WIRE.C:24: error: 'PD6' was not declared in this scope
../../1WIRE.C:25: error: 'DDRD' was not declared in this scope
../../1WIRE.C:27: error: 'cli' was not declared in this scope
../../1WIRE.C:30: error: 'PIND' was not declared in this scope
../../1WIRE.C:31: error: 'sei' was not declared in this scope
../../1WIRE.C: In function 'unsigned char w1_bit_io(unsigned char)':
../../1WIRE.C:41: error: 'cli' was not declared in this scope
../../1WIRE.C:42: error: 'DDRD' was not declared in this scope
../../1WIRE.C:42: error: 'PD6' was not declared in this scope
../../1WIRE.C:47: error: 'PIND' was not declared in this scope
../../1WIRE.C:51: error: 'sei' was not declared in this scope
make: *** [1wire.o] Error 1
Build failed with 14 errors and 3 warnings...


Und nun frage ich mich, warum die headerfiles nicht gefunden
werden, wo ich die doch extra in den Ordner Sourcefiles und
Headerfiles ganz links in dem Frame von AVR-Studio eingefügt
habe.  (Add existing Source-Files)

Hat jemand ne Idee?

von Stefan E. (sternst)


Lesenswert?

> Hier stehen auch die ganzen Register r1-r32 drin.
> Was haben die in der Projekt-Datei verloren?

Man kann im Simulator im Processor-Fenster den Registern Namen geben. 
Die werden dann in der Projekt-Datei mit abgespeichert. Zumindest 
sollten sie, denn dieses Feature ist wohl ziemlich Buggy. Jedenfalls 
beschwert sich John Samperi auf AVR-freaks regelmäßig darüber, dass es 
immer noch nicht richtig funktioniert ;-)
Beispiel (von gestern):
http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=82642

von Stefan E. (sternst)


Lesenswert?

> Und nun frage ich mich, warum die headerfiles nicht gefunden
> werden, wo ich die doch extra in den Ordner Sourcefiles und
> Headerfiles ganz links in dem Frame von AVR-Studio eingefügt
> habe.  (Add existing Source-Files)

1
#include <io.h>
2
#include <interrupt.h>
3
#include <signal.h>
4
#include <stdlib.h>
5
#include <stdio.h>

Die Sourcen sind wohl schon etwas älter. Bei io.h, signal.h(*) und 
interrupt.h gehört jeweils noch ein avr/ davor.

(*): das solltest du ganz raus schmeißen und die Definitionen der 
Interrupt-Funktionen entsprechend in das aktuelle Schema ändern.

von Karl-alfred R. (karl-alfred_roemer)


Lesenswert?

Ich fürchte, ich kann damit NOCH nicht so viel anfangen.
Das Projekt ist von Peter Danneger und ist tatsächlich schon
zwei, drei Jahre alt. Aber das sollte doch kein Grund sein, dass
es sich nicht mehr komplilieren lässt oder? Haben sich die Pfade
oder die Headerdateien dermaßen geändert?

Ich habe noch mal ganz von vorne angefangen und schreibe
mal der Reihe nach auf, wie ich vorgegangen bin:

1. Zip Datei herunter geladen
2. Zip Datei nach c:\1wire_Dateien entpackt.

3. AVR-Studio 4.14 geöffnet
4. New Project
5. AVR GCC ausgewählt
6. Projektname  1Wire
7. Initial file: 1Wire   .c
8. Location C
9. Debug Plattform  AVR Simulator
10. Device Atmega8

Nun öffnet sich wie von Geisterhand das leere Projekt. Ganz links
der Dateibaum.In der Mitte oben das Fenster der leeren Datei
c:\1wire\1wire.c

11. Dort füge  ich die Dateien aus 1wire_Dateien ein. (Add existing
    Sourcfiles bzw Headerfiles)Wobei die Dateien physisch aber immer
    noch im Ordner c:\1wire_Dateien bleiben. Im von AVR-Studio erzeug-
    ten Ordner c:\1Wire gibt es nur zwei Dateien: 1Wire.aps und die
    leere 1Wire.c

12. Aus der heruntergeladenen Datei 1wire.c habe ich mit Cut&Paste
    den Inhalt heraus kopiert und diesen dann in das leere lwire.c-
    Fenster in AVR-Studio hinein kopiert.
13. Built + bekannte Fehlermeldung.

Mein WinAVR liegt übrigens im Pfad c:\WinAVR-20090313.

von Stefan E. (sternst)


Lesenswert?

Karl-alfred Römer schrieb:

> Aber das sollte doch kein Grund sein, dass
> es sich nicht mehr komplilieren lässt oder?

Die Dinge ändern sich nun mal gelegentlich im Laufe der Zeit. Entweder 
aktualisierst du die Sourcen, oder besorgst dir eine zu den Sourcen 
passende Toolchain.

> Haben sich die Pfade oder die Headerdateien dermaßen geändert?

Was meinst du mit "dermaßen"? Der Compiler kennt keinen "wenn im 
angegebenen Pfad nicht gefunden, dann in der Nähe suchen"-Modus. Schon 
die kleinste Änderung reicht.

von Karl-alfred R. (karl-alfred_roemer)


Lesenswert?

Das spricht einiges für Assembler und gegen das portable C.
Die uralten unveränderten Sources aus dem Assembler-Tutorial
laufen sofort.

Ich werde mich noch paar Tage mit C beschäftigen. Wenns
nicht vorwärts geht, versuche ich es halt mit Bascom.

von Michael U. (amiga)


Lesenswert?

Hallo,

nun mach es nicht schlimmer, als es ist. ;-)
Ich bin auch Assemblerprogrammierer und nutze parallel C aus 2 Gründen:
Source zum Abschauen oder Nachnutzen sind zu 90% in c, bestimmte 
umständliche Rechnereien sind in C schneller mal eingebaut und notfalls 
angepasst als in ASM.

Die Frage, daß WinAVR und damit der GCC etliche Änderungen erfahren hat, 
begeistert mich als Anwender auch nicht unbedingt, allerdings sind z.B. 
solche Probleme wie Deins relativ harmlos und in 5 Minuten behoben.
Da reicht notfalls ein Blich in aktuelle Sourcen zum Vergleich.
Belibt mir oft auch nichts anderes.

Viel schlimmer finden ich, wenn man die #define angepasst hat und nichts 
geht und man nach 3 Tagen hilflosen rumstochern dann endlich die eine 
Stelle in einem File findet, wo der Programmierer vergessen hat, den 
hart gecodeten Hex-Wert durch den Namen zu ersetzen. ;-/

Mit dem Zusammenspiel der Komponenten beim WinAVR habe ich mich bisher 
noch garnicht weiter befasst.

Ich mache es normalerweise wie Du. Lege ein neues Projekt an, kopiere 
die .h und .c in den Projektordner, füge sie im Studio zum Projekt hinzu 
und starte Bulid.
Dann beginnt das Suchen an den Fehlermeldungen.
Unbedingt mit der ersten anfangen und diese beheben.
Dann verschwinden auf Grund der Abhängigkeiten ohnehin meist viele auf 
einmal. :-))

Gruß aus Berlin
Michael

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Karl-alfred Römer schrieb:

> Das spricht einiges für Assembler und gegen das portable C.

Peter ist zwar ein kluger Kopf, aber manche seiner Denkmuster sind
ein wenig, naja, sehr eingefahren.  Während alle Welt der Konvention
folgt, dass die Headerdateien der Systembibliothek in Unterverzeich-
nissen ein wenig strukturiert abgelegt sind, und dass man diese dann
mitsamt ihrem Unterverzeichnisnamen aufruft:
1
#include <stdlib.h>  // Standard-C-Header, hat kein Unterverzeichnis
2
3
#include <avr/io.h>  // AVR-spezifisch, liegt alles in avr/
4
5
#include <util/delay.h> // zusätzliche Hilfsfunktionen in util/
6
7
#include <compat/deprecated.h>  // Rückwärtskompatibilität zur schnellen
8
                                // Adaptierung veralteten Codes

zieht Peter es offenbar vor, die Unterverzeichnisse im Aufruf
wegzulassen und stattdessen alle diese Verzeichnisse explizit per
-I dem Compiler in den Suchpfad zu packen.  Das geht so lange gut,
solange es innerhalb der Verzeichnisse keine Namensdoppelung gibt.

Wenn du halt Code anderer Leute benutzt, dann musst du mit deren
persönlichen Eigenheiten leben lernen, und wenn du dir deren
Eigenheiten nicht selbst zu eigen machen willst, gehst du dahin,
und editierst das stillschweigend so um, dass der Code den üblichen
Konventionen folgt.  Das geht in 3 Minuten, und du sparst dir ja
dann dennoch das aufwändige Implementieren und Debuggen.

von Bernd (Gast)


Lesenswert?

und von der Idee das man C code mal eben portiert kommst Du am besten 
gleich ab :-)

von P. S. (Gast)


Lesenswert?

Karl-alfred Römer schrieb:

> Ich werde mich noch paar Tage mit C beschäftigen. Wenns
> nicht vorwärts geht, versuche ich es halt mit Bascom.

Wenn du meinst, dass eine Sprache von einem Anfaenger in ein paar Tagen 
erlernbar sein muss, ist C ganz sicher die falsche Sprache.

von yalu (Gast)


Lesenswert?

Noch ein Tipp:

In obiger Fehlerausgabe

> avr-gcc.exe  -mmcu=atmega8 -Wall -gdwarf-2 -Os -std=gnu99
> -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -MD -MP
> -MT 1wire.o -MF dep/1wire.o.d  -c  ../../1WIRE.C
> cc1plus.exe: warning: command line option "-std=gnu99" is valid for
> C/ObjC but not for C++
> In file included from ../../1WIRE.C:9:
> ...

labert der Compiler etwas von C++. Warum?

Der GCC stammt ursprünglich aus der unixoiden Welt, wo bei Dateinamen
zwischen Groß- und Kleinschrift unterschieden wird. Dort steht die
Entdung .c standardmäßig für eine C-Quelldatei, während .C (großes C)
für eine C++-Quelldatei steht.

Auch wenn in Windows 1WIRE.C und 1wire.c äquivalente Dateinamen sind,
betrachtet der GCC ersteres als C++- und letzteres als C-Datei.

Da du aber C und nicht C++ kompilieren willst, benennst du am besten
alle C-Dateien mit .C am Ende entsprechend um und baust im AVR-Studio
anschließend das Projekt neu auf. Alternativ kannst du die Namen auch in
der bereits bestehenden Projektdatei ändern, das Problem holt dich aber
spätestens dann wieder ein, wenn du die Dateien mit dem großen C später
in einem anderen Projekt erneut verwenden willst.

von Karl-alfred R. (karl-alfred_roemer)


Lesenswert?

yalu, das mit dem großen und kleinen C ist ein wichtiger Hinweis,
den ich gleich ausprobieren werde.

> Wenn du meinst, dass eine Sprache von einem Anfaenger in ein paar
> Tagen erlernbar sein muss, ist C ganz sicher die falsche Sprache.

Das sehe ich ein. Mein Weg eine Sprache zu lernen, war es, einfache
Programme erst mal zu kopieren, kompilieren und auszuführen, versuchen
zu verstehen, warum es funktioniert und was die einzelnen Zeilen tun.
Und dann langsam die Sachen umbauen. Spielerisch lernen sozusagen.

Ich habe mit AVR-GCC versucht so anzufangen. Habe das erste kleine
Beispiel aus dem GCC-Tutorial erfolgreich laufen gelassen und
einigermaßen verstanden, was da passiert. Alles was danach kommt,
ist unvollständig. (Im Gegensatz zum ASM-Tut, wo alles komplett
direkt funktioniert. FÜr einen Erfahreneren ist das kein Problem,
es so weit zu vervollständigen, dass es funktioniert. Ich hingegen
in meinem momentanen Wissenstand bleibe erst mal hier hängen.

Also habe ich nach anderen Beispielen hier im Forum gesucht.
Und die laufen nicht, weil der Compiler bzw dessen Bibliotheken
umgeändert worden sind.

Für mich als totaler C-Anfänger, wäre es eine große Hilfe,
wenn die Beispiele im Tutorial komplett wären, so dass ich
mit Cut&Paste etwas lauffähiges hätte. Der Rest käme dann
fast von alleine. (

von yalu (Gast)


Lesenswert?

Gerade habe ich noch etwas gefunden:

  Beitrag "Re: DS1820, DS18B20 in C"

Da hat ein netter Mensch (Daniel B.) die angesprochenen Punkte
(Groß-/Kleinschreibung, Includepfade und Interrupts) geändert, so dass
das Programm zu der aktuellen Toolchain passt.

Auf dem Controller testen musst du allerdings selber ;-)

von Karl-alfred R. (karl-alfred_roemer)


Lesenswert?

Habe das Zip von Daniel B. gerade mal herunter geladen und ein
Projekt daraus erstellt.

Built bringt dann folgende Fehlermeldung:
gcc plug-in: Error: Object file not found on expected location 
C:\1Wire\default\1Wire.elf

Selbst wenn ich das Makefile von Daniel B. verwende, klappt es nicht.

Benutze ich das Batchfile von Peter Dannegger in einer DOS-Box, wird
erfolgreich ein Hex daraus erzeugt. Wobei die Hex-Datei 7680 Bytes
groß ist, was geradeso noch in den Atmega8 hinein passen würde.
Ich vermute mal, dass es in Assembler vielleicht 2KB wären.

von Stefan B. (stefan) Benutzerseite


Lesenswert?

Karl-alfred Römer schrieb:

> Wobei die Hex-Datei 7680 Bytes
> groß ist, was geradeso noch in den Atmega8 hinein passen würde.
> Ich vermute mal, dass es in Assembler vielleicht 2KB wären.

Die Größe des HEX-Files ist kein direktes Maß für die Speicherausnutzung 
eines µC. In einem HEX-File sind Binärdaten ASCII kodiert und es sind 
zusätzlich Steuer, Adress- und Prüfsummendaten vorhanden.

http://www.mikrocontroller.net/articles/Speicher#EPROM

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Karl-alfred Römer schrieb:

> Built bringt dann folgende Fehlermeldung:
> gcc plug-in: Error: Object file not found on expected location
> C:\1Wire\default\1Wire.elf

1.) Sieh dir die Compilermeldungen bitte mal an statt der Meldungen
    von AVR Studio.

2.) Eigentlich solltest du diese Meldung gar nicht mehr sehen mit
    einer aktuellen Version von AVR Studio, kann es sein, dass du
    nicht das neueste da benutzt?

p.s.: 1wire ist vielleicht auch nicht gerade das glücklichste
Anfängerprojekt.

von Karl-alfred R. (karl-alfred_roemer)


Lesenswert?

>1.) Sieh dir die Compilermeldungen bitte mal an statt der Meldungen
>    von AVR Studio.

Habe keine Ahnung, wie ich Compilermeldungen von AVR-Studio-Meldungen
unterscheiden kann. Dachte, die kämen alle vom Compiler.

>2.) Eigentlich solltest du diese Meldung gar nicht mehr sehen mit
>    einer aktuellen Version von AVR Studio, kann es sein, dass du
>    nicht das neueste da benutzt?

Das könnte sein. Ich habe die 4.14, die ja schon steinalt ist.
(über ein Jahr)  Aber es ist schon bedenktlich, dass manche
Programme nicht mehr kompiliert werden, weil sich die Entwicklungs-
umgebung geringfügig geändert hat. Dennoch habe ich es über mich
ergehen lassen mich für den Download der 4.17 zu registrieren. ;)

Wie dem auch sei: Ich habe meine Vorgehensweise geändert.
Ich versuche jetzt, die Beispiele aus dem Assembler-Tutorial
stück für stück in C umzusetzen. Evtl mit leichten Modifikationen.
Und das klappt sooooo schlecht eigentlich nicht.
Immerhin läuft schon der erste Zähler von 1- 10 000 000, wobei
bei jedem 10 Millionsten Durchlauf der PORTB hochgezählt wird
und auf den LEDs augegeben wird. Und das ist viel lesbarer
und nachvollziehbarer als in Assembler. Jetzt bin ich wieder
froh:))))

#include <avr/io.h>
#include <stdint.h>

int n = 10000;
int m = 1000;

int main(void)
{
    //B auf Ausgang, D als Eingang
    DDRB = 0xff;
    DDRD = 0;
    PORTB = 0;

   while (1)
   {
       while (n > 0)
     {
        n--;
      while (m > 0)
        {
           m--;
        }
      m=1000;
     }
     n=10000;
  PORTB--;
   }

}

von P. S. (Gast)


Lesenswert?

Karl-alfred Römer schrieb:

> Das sehe ich ein. Mein Weg eine Sprache zu lernen, war es, einfache
> Programme erst mal zu kopieren, kompilieren und auszuführen, versuchen
> zu verstehen, warum es funktioniert und was die einzelnen Zeilen tun.

Das ist der falsche Weg. Nachahmen ist ein sehr natuerlicher 
Lernprozess, aber C lernt man ueber das Studium grundlegender Literatur. 
Am besten ueber ein C-Buch.

> Für mich als totaler C-Anfänger, wäre es eine große Hilfe,
> wenn die Beispiele im Tutorial komplett wären, so dass ich
> mit Cut&Paste etwas lauffähiges hätte. Der Rest käme dann
> fast von alleine. (

Das ist eben ein Irrtum. Und deswegen waere es kontraproduktiv die 
Tutorials so zu gestalten, dass Anfaenger glauben, C verstanden zu 
haben. Nicht umsonst steht es extra im Vorwort, auch wenn es leider 
immer wieder ignoriert wird :-(

von Karl-alfred R. (karl-alfred_roemer)


Lesenswert?

So hat halt jeder seinen Lernstil. Vielleicht ist das auch der
Grund, warum ich nie mit der Objektorientierung froh geworden bin.

von P. S. (Gast)


Lesenswert?

Karl-alfred Römer schrieb:

> So hat halt jeder seinen Lernstil. Vielleicht ist das auch der
> Grund, warum ich nie mit der Objektorientierung froh geworden bin.

Kannst du dir vorstellen, wie oft ich das schon gehoert habe von Leuten 
die meinten, dass sie es besser als der Lehrer wuessten?

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Karl-alfred Römer schrieb:

>>1.) Sieh dir die Compilermeldungen bitte mal an statt der Meldungen
>>    von AVR Studio.

> Habe keine Ahnung, wie ich Compilermeldungen von AVR-Studio-Meldungen
> unterscheiden kann. Dachte, die kämen alle vom Compiler.

Nein, das ist eine vom AVR Studio.  Meiner Erinnerung nach (ich
benutze kein AVR Studio, schon deshalb, weil ich kein Windows
habe) gibt's in dem Bereich mehrere Reiter, einer davon enthält
die Meldungen vom AVR Studio, der andere die des Compilers.

Der Bug in dieser alten AVR-Studio-Version war, dass sie den
Rückkehrstatus des "make" nicht ausgewertet hat, sondern nur
den Text, den Compiler und Linker produziert haben, auf bekannte
Muster wie "Error" analysiert.  Wenn dann in den Meldungen mal
ein unbekannter Fehler drin war, haben sie das nicht gemerkt, und
statt dass der ganze Build-Prozess angehalten worden wäre, um das
Fenster mit den Compilermeldungen zu zeigen, wurde weitergemacht,
bis sich AVR Studio dann irgendwann gewundert hat, dass das ELF-
File zum Debuggen ja gar nicht da ist.

Das ist in 4.17 behoben, dort wird jetzt der Rückkehrstatus von
"make" ordentlich ausgewertet.

> Aber es ist schon bedenktlich, dass manche
> Programme nicht mehr kompiliert werden, weil sich die Entwicklungs-
> umgebung geringfügig geändert hat.

Hör doch mal mit deinem ewigen Lamentieren auf.  Ich habe dir oben
schon dargelegt, dass das überhaupt nichts mit einer Änderung
der Entwicklungsumgebung zu tun hatte, sondern mit einer Eigenheit
des Programmierers, dessen Code du benutzt hast.  Und das andere
war halt ein AVR-Studio-Bug (eher eine schlechte Implementierung),
die nun endlich behoben worden ist.

> Ich versuche jetzt, die Beispiele aus dem Assembler-Tutorial
> stück für stück in C umzusetzen.

Das ist sicher gar nicht so schlecht als Methode.

von CMosSwitcher (Gast)


Lesenswert?

Nochmal zum Thema Make:

Ich bin Softwareentwickler und wir schreiben die Makefiles selbst.
Wir benutzen u.a. den Cosmic Compiler.

Kurz gesagt läuft der Build Prozess so ab:

C-Sourcen schreiben.

Im Makefile werden Regeln angegeben wie aus C-Sourcen / Assembler 
Sourcen Object Files erstellt werden.
Ja, auch aus Assembler Files werden Object Files gebaut.

Im Linker wird dann festgelegt an welche Stelle im Controller Speicher 
(in welches Segment) die Objectfiles gelinkt werden.

Aus dem Linker kommt dann ein Controller spezifisches Targetfile.

Dieses wird dann mittels verschiedener Tools:
in ein ELF File (für den Debugger) in ein S19 Mototola Hex File und ein 
hex - Intel Hex File transformiert.

Das s19 File kann dann auf das Target geflasht werden.
Mas Elf File kannst du in deinen Debugger laden und dann deine Anwendung 
mit Break Points durchsteppen..

AVR Studio ist eine IDE... Integrated development environment... eine 
integrierte Entwicklungsumgebung. Als was ich hier aufgezählt habe, kann 
noch konfiguriert werden (z.B: Compiler Optionen, Linker Optionen), aber 
hier läuft alles automatisiert und du hast nichts mehr damit zu tun. Für 
Anfänger ist sowas ideal.

Meine erste IDE war Borland Delphi. Ich habe da Windows Applikationen in 
Object Pascal programmiert... ohne einen Plan von make, objects, linker 
usw. zu haben.

Achja, und dass du von der Größe des Hexfiles auf die Größe des Binaries 
schließt, das ist ein Fehler der mir am Anfang auch passiert ist.

Aber man muss sich einfach klar machen, dass S19 Files z.b. für Menschen 
lesbar sind.. das bedeutet, ASCII codiert, als JEDES Zeichen ist ein 
Byte... in Wirklichkeit sind 2 "Zeichen" z.b. FF nur ein Byte.. auch 
entfallen die Adressangaben, Zeilennummern, HEaderinformationen, 
Zeilenchecksummen...

Wenn du wissen willst wie groß deine Applikation wirklich ist, musst du 
nicht deinen Explorer fragen, sonder das Map File!

Hier steht zu jedem Segment die belegte Speichergröße.
Wenn deine Applikation im Speicher Segment .text liegt und dahinter eine 
1234, dann weißt du, dass deine Applikation 1234 Byte groß ist.

gruss

von Stefan E. (sternst)


Lesenswert?

Jörg Wunsch schrieb:

> Hör doch mal mit deinem ewigen Lamentieren auf.  Ich habe dir oben
> schon dargelegt, dass das überhaupt nichts mit einer Änderung
> der Entwicklungsumgebung zu tun hatte, sondern mit einer Eigenheit
> des Programmierers, dessen Code du benutzt hast.

Mea culpa. Ich habe diesen Stein ins Rollen gebracht mit meiner 
Vermutung, dass sich die Pfade im Lauf der Geschichte der AVR-Libc 
geändert haben könnten. Ich meinte mich tatsächlich schwach daran 
erinnern zu können, dass z.B. signal.h mal auf der obersten Ebene war.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Stefan Ernst schrieb:

> Ich meinte mich tatsächlich schwach daran
> erinnern zu können, dass z.B. signal.h mal auf der obersten Ebene war.

OK, fast. ;-)  Damals hieß es nämlich noch sig-avr.h.  Die Umstellung
auf das jetzige Layout ist im Juli 2002 erfolgt (hat mir das CVS
verraten :).

Der Zeitpunkt Juli 2002 war übrigens der, zu dem Marek Michalkiewicz
die avr-libc von seinem privaten Desktop-Rechner auf
savannah.nongnu.org transferiert hat.  Davor hat Marek mehr oder
weniger nach eigenem Gutdünken dort operiert, danach wurde es dann
immer mehr eine Gruppenentscheidung.  Zu dieser Zeit war die gesamte
Entwicklung von AVR-GCC und avr-libc gerade mal so um die 2 Jahre
alt, und es ist sicher eher normal, dass man dann auch mal zu dem
Entschluss kommt, dass man dieses oder jenes doch ein wenig anders
strukturieren möchte...

von Stefan E. (sternst)


Lesenswert?

Jörg Wunsch schrieb:
> Stefan Ernst schrieb:
>
>> Ich meinte mich tatsächlich schwach daran
>> erinnern zu können, dass z.B. signal.h mal auf der obersten Ebene war.
>
> OK, fast. ;-)  Damals hieß es nämlich noch sig-avr.h.  Die Umstellung
> auf das jetzige Layout ist im Juli 2002 erfolgt (hat mir das CVS
> verraten :).

Oh gut, dann bin ich ja beruhigt, dass mein Gedächtnis mich nicht völlig 
im Stich gelassen hat, sondern nur größtenteils. :-)

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.