www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik ATMega Testcode


Autor: Re To (toobatch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
#define __AVR_ATmega2561__

#include <avr/io.h>
#include <avr/wdt.h>
#include <avr/interrupt.h>

int i,f,k;

int main()

{
cli();      // IRQs verbieten
wdt_disable(); // WD abschalten
DDRA = 0xFF;
DDRB = 0xFF;
DDRC = 0xFF;
DDRD = 0xFF;
DDRE = 0xFF;
DDRF = 0xFF;
DDRG = 0xFF;
for (i = 0;; i++)
{  
  PORTA^=0xFF;
  PORTB^=0xFF;
  PORTC^=0xFF;
  PORTD^=0xFF;
  PORTE^=0xFF;
  PORTF^=0xFF;
  PORTG^=0xFF;

        f=i*3;
        k=i+f-k; 
}

  return(0);

} 

also es geht darum grundsätzlich zu testen ob ein ATMega, im jetztigen 
Falle ein ATMEGA 2561, code abarbeitet. wär das ein annehmbarer code 
oben ?
oder gibt es bessere  ideen?  der Code läuft nämlich nicht, flashen geht 
erfolgreich, Tackt ist da, Fuses stimmen .

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was läuft nicht? Bist Du sicher, dass Diu in der "for" Schlaufe keine 
Abbruchbedingung brauchst?

Autor: Re To (toobatch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
na warum ..  der soll einfach nur laufen in der schleife.  will dann an 
den pins mit oszi messen.

wo soll er denn hinlaufen wenn ich ne abbruchbedingung reinbaue?

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wozu brauchst Du denn k und f?
Schreib doch anstatt
for (i = 0;; i++)
{  
einfach mal
 while (1)
{

Autor: Re To (toobatch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ja ok ,  schon klar ... aber die For -schleife geht doch auch so.

f,k hab ich nur so das es noch was rechnet ... könnte ich auch 
auskommentieren .

der code läuft auf atmega128  , hab ich gerade herausgefunden.
im simulator mit Atmega2561 läuft er auch , aber nicht auf dem realen uC 
ATmegaa2561.

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sind die Fuses richtig gesetzt?

Autor: Re To (toobatch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
sollten sie:
programmiert (0) sind:
BrownOuDetection @1.8V
JTAG ENable
Preverse EEPROM from chipErase
Bootflash section size =4096 words/ start @$1F000
Ext. Crystal Osc.  f>8Mhz / startuptime 16k ck + 65ms

programmierung via JTAG, Quarz beschaltet  (läuft auch)

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Re To wrote:

> #define __AVR_ATmega2561__

Bereits in der ersten Zeile falsch.  Das Setzen dieses Symbols ist
nicht dein Geschäft, das macht der Compiler.  Da du es dennoch
setzt, vermute ich, dass du einfach mal die -mmcu-Option beim
Compilieren und/oder beim Linken vergessen hast zu setzen.

Autor: Re To (toobatch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
äh .. ja ist doch eig. egal wie ich es mache, ich kanns auch 
auskommentieren und dann -mmcu..  schreiben.

es ändert sich nix

Autor: Re To (toobatch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ok. kann mir mal jmd sagen wie ich manuell von. der *.c   zum *.hex 
komme ?

hatte das mit sonem makefile gemacht...

avr-gcc -o <name> <name>.c -mmcu=atmega2561

oder so ...  und dann weiter ??

hab da keine ahnung richtig, auch mit diesem makefile editieren nicht

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Re To wrote:
> äh .. ja ist doch eig. egal wie ich es mache, ...

Nein, ist es nicht.  Wenn du keine Ahnung hast, dann lass dir
wenigstens raten.

Autor: Re To (toobatch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ja nun wie ??

wie komm ich von dem *.c ins *.hex ...  manuell ohne scheiß-make

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mit dem Ton kannste selbst sehen, wie du deinen Krams gebacken bekommst.

Autor: Re To (toobatch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
oh sorry,  hab nur ein bissl Wut ... komm nicht vorwärts :(

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dann fang doch nicht an, an Stellen rumzubohren, von denen bekannt
ist, dass sie gut funktionieren.  Bau dir ein Makefile mit mfile
oder mit AVR Studio, von dem klar ist, dass erst einmal die
äußeren Bedingungen stimmen, wie der Compiler und Linker gerufen
werden.

Nichts dagegen, dass du die Interna von make & Co. verstehen lernen
willst, aber du kannst dich jetzt zwischen dieser Aufgabe entscheiden
oder der, erst einmal relativ schnell zu funktionierendem Code zu
gelangen.

Autor: Re To (toobatch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hmm ...

ja der code müsste richtig sein, im simulator läuft er.
und wie gesagt auf dem 128er läuft er  in real auf dem uC im gleichen 
board/umgebung.

hatte ein makefile  eines projekts benutzt und im c-code alles erstmal 
unwichtige auskommentiert und in die main() das obige reinkopiert.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das wdt_disable() ist übrigens nutzlos.  Entweder befindest du dich
nach einem power-on reset, dann ist der Wachhund sowieso abgeschaltet.
Oder aber, eine frühere Firmware hat dir den Wachhund noch vererbt,
dann wirst du ihn auf diese einfache Weise nicht los.  Du musst zu
allererst das WDRF-Bit löschen.  Sowohl das Datenblatt als auch die
Doku zu <avr/wdt.h> gehen ausführlich darauf ein.

Das cli() ist genauso überflüssig, nach einem Reset sind die
Interrupts immer gesperrt.

Die Variablen i, j, k und f kann der Compiler wegoptimieren, da sie
offensichtlich nicht genutzt werden.

Autor: Re To (toobatch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ja OK ,  danke für die infos.

bin jetzt erstmal froh das was geht. mal mit assembler was geschrieben 
und das funktioniert :)

aber wieso geht der c-code nicht?
du meinst mfile benutzen, na dann werd ichs mal probieren.


beim simulieren ist mir auch aufgefallen das der code ab adresse 0x1F000 
losgeht. weiß nicht wie das mit dem bootloader ist, wenn ich diesen Boot 
Vektor reset nicht programmiert hab (fusebit=1) dann startet der uC  an 
der adresse wo das bootFlash section eingestellt ist , oder ? also der 
bootloader wird dann komplett ignoriert oder nicht?

Autor: Teplotaxl X. (t3plot4x1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mit diesen Skript kompiliere ich seit lange meinen Code
#!/bin/sh
avr-gcc -mmcu=atmega8 -Os -o /tmp/avrgccout $1
avr-objcopy -j .data -j .text -O ihex /tmp/avrgccout $2
rm /tmp/avrgccout

Und es funktioniert :)

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Häng mal für alle Fälle noch ein »-lm« an die AVR-GCC-Kommandozeile
mit dran.

Autor: Re To (toobatch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
aha, ok , danke .

das irgendwie zu verstehen is schon nicht leicht
die hilfeprints  mit --help bzw. -v --help   mit  allen möglichen 
schalteroptionen  sprengen ja jeden bildschirm.

Autor: Re To (toobatch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So. hab was entdeckt:
-Ttext=0x1F000

das stand im makefile und verschiebt den code an diese Adresse nach 
hinten im hexFile also auch im Flash.

komisch ist nur das das ganze auf dem ATMega128 mit dem Wert 0xF000 
ging, der compiler merkerte da der 128er ja nicht soviel Flash hat, da 
hab ich das geändert und er  erzeugte alles für den 128er und der code 
lief darauf.

Jemand ne Antwort darauf ?

was macht der uC denn wenn er auf die Anweisung FFFF stößt ?

schönen Tag ...

Autor: egberto (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
mal eine ganz blöde Frage - hast du für deine Makefiles einen 
Ghostwriter oder so was, das du nicht weist was drin steht??

Wenn du keinen Bock hast, dich mit makefiles rumzuärgern (so wie ich 
meistens), trag doch die Optionen im Projekt beim AVR-Studio ein, dann 
wird das im Makefile richtig gesetzt.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Re To wrote:

> Jemand ne Antwort darauf ?

Jemand deutsch hier?

Die Atmel-Tools wissen nicht, ob sie den Flash nun in 16-bit-
Adressierung (für Codezugriffe) oder in 8-bit-Adressierung (für
Datenzugriffe => LPM) anzeigen wollen.  Daher tun sie meist
ersteres.

Die GNU-Tools haben einen größeren Horizont und laufen auf
Maschinen mit 8, 16, 32 oder 64 bit Wortbreite.  Da die Anpassung
der Adressierung für jede Maschine zu ziemlicher Verwirrung führen
würde, benutzen sie immer Byteadressen.

0x1F000 (Byteadressierung) = 0xF800 (16-bit-Adressierung)

Warum das aber bei 0xF000 rauskommen soll, bleibt mir rätselhaft.

Autor: Re To (toobatch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg Wunsch wrote:

> Warum das aber bei 0xF000 rauskommen soll, bleibt mir rätselhaft.

wahrscheinlich hast du mich falsch verstanden: in dem MAkefile stand die 
0x1F000 (-tText0x1F000), und ich hatte Sie manuell in eine 0xF000 
geändert. Da der Compiler error sagte und ich mir dachte, klar - für was 
auch immer die angabe steht: der Atmega128 hat nicht solch einen großen 
Flashspeicher.
dann lief der Code auf dem ATMEGA128 aber auf dem 2561 immer noch nicht 
!!

erst nachdem ich die Option  -tText<> gelöscht hatte ging es dann auch 
auf dem 2561er.

mir stellte sich dann nur die frage warum das mit dem nach hinten 
verschoben code auf dem einen ging und auf dem anderen nicht.

hatte ja auch im simulator (avrStudio) diese FFFF- "Anweisungen" gesehen 
vor und hinter dem richtigen Code gesehen, der simulator ist mit 
"ungülter code" einfach weitergelaufen bis er zum eig. Code kam.

Autor: Guile Lampert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du hast das Makefile für einen Bootloader erwischt.
Deshalb wird der Code auch nach hinten ins Flash geschrieben.

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.