ATmega328P defekt?

Felix A. schrieb:
> Wie passt denn eine 288 in ein 8-Bit-Register?

Hast recht .. hab ma 28 reingeschrieben aber selbes Ergebnis .. LED ist 
immer an

Jonathan K. schrieb:
> Also AVR defekt oder steh ich aufm Schlauch?

Bring uns erstmal auf den Stand.
Bevor hier die große Wochenendraterunde einsetzt, verrate doch einfach 
mal, wie deine LED überhaupt angeschlossen ist.

Felix A. schrieb:
> Ändere
> doch dein cbi in sbi zum Testen

Habs auch andersherum ausprobiert, dann war die LED immer aus ..


Flip B. schrieb:
> Bleibt die Led während des reset an ?

nein

Felix A. schrieb:
> ann geht deine LED ziemlich sicher aus.

nein, tut sie nicht

Felix A. schrieb:
> Fehlt vielleicht einfach nur .cseg ?

Nein wenn mans weglässt ist man automatisch im Code Segment.

Initialisation vom SP hatte ich auch mal drin, gleiches Ergebnis, habs 
für den Test rausgemacht, da unrelevant.

magic s. schrieb:
> Nur den Port konfiguieren und den PortPin entsprechend setzen.
> Ich vermute der IC ist okay.

Ja das geht, auch wenn ich ein Register per tst auf null prüfe und das 
die LED anzeigen lasse klappt es, nur beim Vergleich nicht ...

Felix A. schrieb:
> Der Sprung aus der Vektortabelle zum  zum Programm wird ja ganz vorne im
> Flash als Sprungziel angegeben. Das fehlt hier auch, oder nicht?

Interrupts sind ja nicht aktiv, dann braucht man das nicht.

Hab jetzt cp durch sub ersetzt .. ist ja das selbe nur dass das Ergebnis 
bei cp verworfen wird. Und siehe da mit sub klappt alles .. da hat wohl 
der AVR nen Knacks

Jonathan K. schrieb:
> Hab jetzt cp durch sub ersetzt .. ist ja das selbe nur dass das Ergebnis
> bei cp verworfen wird. Und siehe da mit sub klappt alles .. da hat wohl
> der AVR nen Knacks

Ne anscheinend doch net ..
Wenn ich brlo benutzte und
tmp0 = 150
tmp1 = 128
dann ist die LED aus
bei brge und den werten ist die LED an, bei
tmp0 = 50
tmp1 = 128
ist die LED immer an, egal ob brlo/brge

Felix A. schrieb:
> Wie geschrieben versuche nochmal, die Register unterhalb von r16 mit dem
> cp zu nutzen. Ich glaube nicht an einen Befehls-Defekt

Gibt genauso krumme Ergebnisse wie ich eben im Post drüber beschrieben 
hab, da scheint wohl doch der AVR kaputt zu sein ...

Aber wie kommt sowas?

Hatte eben vorher was mim ADC und UART rumprobiert und zuerst überall
sts ADMUX+0x20, tmp0
usw. stehen gehabt, weil ich da was falsch im Kopf hatte ..

D.h. ich habe die Register 0x79+0x20=0x99 bis 0x7e+0x20=0x9e und 
0xc0+0x20=0xe0 bis 0xc6+0x20=0xc6 beschrieben, welche beim m328p alle 
keinem Register zugeordnet sind ... geht der AVR etwa kaputt wenn man 
nicht zugeordnete Register beschreibt ... !?? Oder muss es was anderes 
gewesen sein ?

magic s. schrieb:
> Wurde beachtet, daß BRGE für vorzeichenbehaftete Vergleiche gedacht ist?

Oh stimmt das hab ich ganz übersehen .... hatte das mir irgendwie mal 
falsch gemerkt
Und mit brcc/brcs klappts auch .. danke! :D
Dass mir das bis jetzt noch nie aufgefallen ist ...

Jonathan K. schrieb:

> Also AVR defekt oder steh ich aufm Schlauch?

Du stehst auf'm Schlauch, es mangelt dir an Kenntnissen zur Maschine.

Der Atmel-Assembler ist nämlich kein Assembler im ganz klassischen 
Sinne, Atmel hat hier ein wenig getrickst, wohl um die Zahl der 
"verfügbaren" Instruktionen künstlich hochzujubeln. Höhere Zahlen lesen 
sich in Werbeblättchen einfach fluffiger...

Einfachstes Beispiel: Die Instruktion "sbr" z.B. gibt es nicht wirklich, 
tatsächlich macht sie exakt das gleiche wie "ori", erzeugt also auch den 
gleichen Opcode.

Etwas schwieriger zu verstehen: "cbr". Auch diese Instruktion existiert 
nicht wirklich, tatsächlich erzeugt sie den Opcode für "andi". Damit die 
Sache trotzdem wie erwartet funktioniert, invertiert der Assembler 
einfach still und leise beim Übersetzen den immediate-Operanden. Das 
haben die Programmierer des Atmel-Assemblers gerade noch so 
hinbekommen...

Aber, und jetzt komme ich zu deinem Problem, Atmel hat auch 
Instruktionen erfunden, bei denen sich die Tatsache, dass sie garnicht 
wirklich existieren, nicht ganz so leicht verstecken lässt. Insbesondere 
sind des etliche Verzweigungsbefehle. In der "Instruction set reference" 
findest du unter dem Gliederungspunkt "Conditional branch summary" die 
betreffenden Instruktionen. Sie sind dort mit "(1)" gekennzeichnet.

Und wenn du dann den Kram zu (1) unter der Tabelle liest, die 
Konsequenzen daraus durchdenkst und mit deinem Code vergleichst, wirst 
du wissen, dass nicht der AVR kaputt ist...

Das mit sbr und cbr weiß ich, und so schlecht find ich es gar net, dass 
die existieren, da mein AVR-Assembler nicht mit "~" klar kommt und ich 
dann lieber cbr benutzte, damits einheitlich ist nehme ich dann passend 
dazu auch sbr.

c-hater schrieb:
> Und wenn du dann den Kram zu (1) unter der Tabelle liest, die
> Konsequenzen daraus durchdenkst und mit deinem Code vergleichst, wirst
> du wissen, dass nicht der AVR kaputt ist...

Jaa jetzt seh ichs .. die Branches sind doch komplizierter als ich es 
dachte ..

Hi

>da mein AVR-Assembler nicht mit "~" klar kommt ...

Und welchen benutzt du?

MfG Spess

spess53 schrieb:
> Und welchen benutzt du?

avra

Peter D. schrieb:
> BRGE, BRLO vergleichen signed, also von -128 .. +127.
> D.h. weder 288 noch 128 sind gültige Werte, vielleicht erzeugt Dein
> Assembler deshalb Mumpitz.

Ja das haben wir mittlerweile auch schon rausgefunden ;)
BRLO vergleicht aber unsigned, nur BRGE vergleicht signed.

Also unsigned: BRLO/BRSH
und signed: BRLT/BRGE

Peter D. schrieb:

> BRGE, BRLO vergleichen signed, also von -128 .. +127.
> D.h. weder 288 noch 128 sind gültige Werte, vielleicht erzeugt Dein
> Assembler deshalb Mumpitz.

OMG, du hast nichtmal das Problem begriffen.

Der TO stolperte hier keinesfalls über irgendwelche signed vs. 
unsigned-Geschichten, sondern darüber, dass er, meiner Meinung nach 
durchaus zu Recht, erwartet hat, dass (formal) komplementäre 
Verzweigungs-Instruktionen sich auch tatsächlich komplementär verhalten.

Und genau das tun sie eben beim AVR-Assembler nicht immer.