ATMega Testcode

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.

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)

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.

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

es ändert sich nix

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

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.

ja nun wie ??

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

Mit dem Ton kannste selbst sehen, wie du deinen Krams gebacken bekommst.

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

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 :)

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

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.

So. hab was entdeckt:

1

-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 ...

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.