mikrocontroller.net

Forum: Compiler & IDEs Hää?


Autor: Marcel Block (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

warum funktioniert das nicht:

#include <avr/io.h>

void delay(unsigned int p)
{
  unsigned int i;
  for(i=0; i<p; i++) { asm volatile ("nop"); }
}

void main(void)
{
  DDRB = 0xFF;
  while(1) {
    PORTB = 0x00;
    delay(0xFFFF);
    PORTB = 0x01;
    delay(0xFFFF);
  }
}

wenn ich allerdings die zwei aufrufe der delay funktion in der main() 
durch zwei for-schleifen ersetze dann funzts das ganze...
also es scheint irgendwie an der funktion zu liegen...
könnte auch sein das mein makefile schrott ist -> könnte mir jemand ein 
gescheites "standart-makefile" schicken?

MFG Marcel

Autor: Joerg Wunsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nun, vielleicht hättest Du ja statt des ,,Hää'' ja lieber mal
beschreiben sollen, was denn bei Dir nicht funktioniert.

Ich bekomme jedenfalls in der Simulation einwandfrei einen
Rechteck mit einer Periodendauer von ca. 115 ms (@ 8 MHz CPU)
an PB0.

Autor: Marcel Block (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hmm nunja wenn ich das ganze kompiliere und auf nen AT90S4433 schreibe 
dann tut sich garnix

wenn ich es allerdings so mache:

#include <avr/io.h>

void main(void)
{
  unsigned int i;
  DDRB = 0xFF;
  while(1) {
    PORTB = 0;
    for(i=0; i<0xFFFF; i++) { asm volatile ("nop"); }
    PORTB = 1;
    for(i=0; i<0xFFFF; i++) { asm volatile ("nop"); }
  }
}

und dies dann kompiliere und auf meinen AT90S4433 schreibe funktioniert 
es

also wieso funktioniert das oben nicht aber das hier funzt?

MFG Marcel

Autor: Joerg Wunsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie geschrieben: bei mir funktioniert die Version, die bei Dir
nicht tut, sehr wohl.  (OK, in der Simulation, einen Chip zum
Testen habe ich jetzt hier nicht zur Hand.)

Aber ich habe da so einen Verdacht... Du hast -mmcu=$(MCU) in
Deiner Linker-Kommandozeile vergessen (also in dem Aufruf von
avr-gcc, der das Linken vornimmt).  Dadurch wird für den
falschen AVR gelinkt, was zur Folge hat, daß der Stack im
Nirvana landet.  Stört keinen bis zu dem Moment, da Du die erste
Funktion aufrufen willst...

Ein Standard-Makefile-Template ist bei WinAVR wohl dabei.  Das
solltest Du als Basis für Dein eigenes Makefile benutzen.

Autor: Marcel Block (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ok danke ich werds mal versuchen...

wie genau und womit simulierst du denn deine programme?

MFG Marcel

Autor: Joerg Wunsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mit VMLAB, siehe http://www.amctools.com/ -- man verzeihe mir
die Schleichwerbung.  Ist Payware, hat aber eine deutlich
bessere Peripherie-Simulation als AVR Studio und für mich vor
allem den Vorteil, daß es auf meinem FreeBSD mit dem Wine
Windows-Emulator läuft.

Alternativ habe ich avr-gdb + simulavr zum Simulieren.  Vorteil
ist, daß es Freeware ist und der GDB als Debugger an Features
von keinem noch so ausgefeilten GUI wirklich zu schlagen ist,
außerdem kann man auf die vollen Debug-Informationen der ELF-Datei
zurückgreifen.  Nachteil ist, daß simulavr praktisch nur zum
Simulieren reiner Algorithmen geeignet ist und nur rudimentäre
IO-Fähigkeiten besitzt.  Ohne avr-gdb und simulavr hätte aber
das avr-libc Projekt weder ein malloc() noch eine komplette
printf() und scanf() Familie, zumindest nicht aus meiner Feder
(bei printf() nur teilweise, die Basis unseres printf() ist
von Alexander Popov geschrieben worden, von dem ich leider
seither nichts mehr gehört habe).

Autor: Werner (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oder wird die Delay schleife vom Compiler wegoptimiert?

Werner

Autor: Joerg Wunsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nein, warum sollte sie denn?  Erstens gäbe es keinen Grund,
warum der Compiler sie innerhalb einer Funktion wegoptimieren
sollte und innerhalb von main() nicht (Marcel schrob ja, daß
es beim direkten Einfügen in main() tut), zweitens hat Marcel
im Body der Schleife ordentlich ein »asm volatile("nop")«
stehen, der Compiler darf das also gar nicht wegoptimieren,
drittens kann man sich den generierten Assemblercode ja ruhig
ansehen, und schließlich habe ich nicht umsonst die sich
ergebende Ausgangsfrequenz meiner Simulation mit gepostet, der
man ebenfalls entnehmen kann, daß es sich um ein deutliches
Delay handelt.

Autor: Marcel Block (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hi ich bins nochmal,

also joerg hatte recht, ich hatte als mmcu einen falschen AVR gesezt -> 
autsch :D

danke für eure hilfe...

MFG Marcel

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.