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 .
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?
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.
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.
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
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.
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.
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.
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?
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 :)
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.
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 ...
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.
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.
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.
Thread beobachten
Seitenaufteilung abschalten