Hallo,
mein m328p verhält sich ziemlich komisch, jetzt frag ich mich ob ich
grad aufm Schlauch stehe oder mein AVR kaputt ist. Bevor da paar
rumnörgeln, dass ein AVR ja nur 2€ kostet .. das ist der AVR im Arduino
und es ist die SMD-Version, bei der ich den Controller net wechseln
kann..
1
.include "m328Pdef.inc"
2
3
4
.def tmp0 = r16
5
.def tmp1 = r17
6
7
8
9
start: sbi DDRB, 5
10
11
ldi tmp0, 288
12
ldi tmp1, 128
13
14
cp tmp0, tmp1
15
brge dt3 ; egal ob hier brge oder brlo steht, die LED ist immer an
16
17
cbi PORTB, 5
18
rjmp dt2
19
20
dt3: sbi PORTB, 5
21
dt2:
22
23
yzf: rjmp yzf
Also AVR defekt oder steh ich aufm Schlauch?
Danke schon mal^^
Wie passt denn eine 288 in ein 8-Bit-Register? Davon ab wird die LED
vielleicht durch Setzen des Pins auf LOW angeschaltet? Der ist initial
nämlich low.
Natürlich ist sie das. Die 288 war ja auch nicht die Ursache. Aus dem
Kopf heraus würde ich sagen, dass eine 32 im Register stand. Ist die LED
an, wenn der Pin auf LOW liegt? Ist das so schwer zu beantworten? Ändere
doch dein cbi in sbi zum Testen
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
Wenn du nun in tmp0 einen Wert 128 oder größer einträgst (in genau dem
oben aufgeführten Programm), dann geht deine LED ziemlich sicher aus.
Und du solltest den Stackpointer noch beim Prozessorstart
initialisieren. Könnte sonst später ein schöner Fehler werden.
Der Sprung aus der Vektortabelle zum zum Programm wird ja ganz vorne im
Flash als Sprungziel angegeben. Das fehlt hier auch, oder nicht? Ist bei
meinen Progs jedenfalls immer so...
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.
In meinem Programm funktioniert cp. Ich habe allerdings Register
unterhalb R16 benutzt. Ich glaubs zwar nicht, aber versuchen könntest du
das auch nochmal. Also tmp0 = r10, tmp1 = r11
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
Das ist extrem selten. Ich hatte einmal einen AVR, bei dem war der
ori-Befehl hinüber.
Wie geschrieben versuche nochmal, die Register unterhalb von r16 mit dem
cp zu nutzen. Ich glaube nicht an einen Befehls-Defekt
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 find ich nicht so schlimm. Du verstehst ja unter "Scheiße" und
"Kacke" auch keine verschiedenen Dinge. Ich finds gut, daß dem
Programmierer da ein größerer Freiraum angeboten wird, sein Programm so
zu schreiben, wie IHM das gefällt.
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 ..
Jonathan K. schrieb:> ldi tmp0, 288> ldi tmp1, 128>> cp tmp0, tmp1> brge dt3 ; egal ob hier brge oder brlo steht, die LED ist> immer an
BRGE, BRLO vergleichen signed, also von -128 .. +127.
D.h. weder 288 noch 128 sind gültige Werte, vielleicht erzeugt Dein
Assembler deshalb Mumpitz.
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.
Thread beobachten
Seitenaufteilung abschalten