Hallo,
ich befasse mich erst seit kurzem mit Mikrocontrollern, und habe bis
jetzt nur das tutorial durgearbeitet. Jetzt hab ich mein erstes Programm
geschrieben.
An Port B sind 8 LEDs, die durchlaufen (Stichwort Knight Rider).
Allerdings werden noch die zwei letzten leds mit software-pwm gedimmt,
um ein "Nachglühen" zu simulieren. Zusätzlich wird ein Poti mit dem ADC
eingelesen, um die Geschwindigkeit der LEDs zu verändern.
ADC ist beschaltet wie im tutorial beschrieben mit interner
referenzspannung und kondensator.
die 8 LEDs sind an Port B mit gem. Masse, d.h. eine 1 am Ausgang lässt
die LED leuchten.
Das Programm läuft in der Simulation so wie es soll, aber auf dem µC
sieht der Schritt 7 so
oooo----
anstatt
-ooo----
aus. Das ist in der Simulation nicht so!
Ist da ein Programmierfehler oder ist es etwas anderes??
Danke im voraus für eure Bemühungen und Antworten!
MFG
Mixer
P.S. Wenn ich in der Endlosschleife kein "sei" steht, hat ein interrupt
bei einem timer overflow keine wirkung!!
>P.S. Wenn ich in der Endlosschleife kein "sei" steht, hat ein interrupt>bei einem timer overflow keine wirkung!!
Interrupthandler verläßt man ja normalerweise auch mit "reti" statt
"ret", damit eben das I-Bit im SREG wieder gesetzt wird.
Hallo,
Ja genau, AVR Studio 4.13. und dazu noch n hapsim von der
Linksammlung
Nein, hab noch nichts herausgefunden. Aber bei der Simulation läuft das
ohne Probleme, und es gibt ja auch keinen Schritt, wo die 4 Ausgänge 1
haben.
MFG Mixer
Ich würde einfach den Schritt (1 bis 14) rauszufinden versuchen, der für
die falsche Ausgabe verantwortlich ist, und dann die Instruktionen dort
genau durchchecken.
Ah, sorry, Du hast ja geschrieben, dass es Schritt 7 ist. Was pasiert,
wenn Du alle 14 Schritte durch Modifikation der Sprungtabelle auf
Schritt 7 lenkst?
AVRFan wrote:
> Was pasiert,> wenn Du alle 14 Schritte durch Modifikation der Sprungtabelle auf> Schritt 7 lenkst?
Hallo,
genau das, was im bild ist. Die simulation zeigt jedoch das, was
passieren sollte:
-ooo----
Allerdings kann ich im Schritt 7 nichts finden, dass da noch ein anderer
Schritt aktiviert wird. Hab ich da was übersehen?
MFG Mixer
Hallo,
weis niemand, woran das liegen kann? Ist der µC defekt, oder läuft die
Simulation im AVR-Studio falsch?
Danke im Vorraus für eure Antworten
MFG Mixer
Um ehrlich zu sein, ist mir dein Programm zu konfus mit all den
vielen Jumps um das jetzt in Gedanken durchzugehen und zu überlegen,
was das Problem sein könnte.
Ich würde: alles wegschmeissen und noch mal neu anfangen.
Allerdings nicht alles in einem Zug implementieren sondern
Schritt für Schritt immer mehr Features hinzufügen. Ganz
wichtig: zwischendurch immer wieder testen.
Wenn du Pech hast, taucht derselbe Effekt wieder auf. Aber
dann weist du, durch welche Änderung der Effekt hineingekommen
ist und kannst gezielt überlegen, was das Problem mit dieser
einen, kleinen, Änderung ist.
Mixer S. wrote:
> Aber hald nur auf dem Mega8 und in der Simulation nicht!!
Wie jetzt, ich dachte, es läuft in der Simulation, aber nicht auf dem
µC? Jetzt plötzlich umgekehrt?
Du weißt auch, dass PB7 als Anschluss für einen externen Quarz dient,
wenn die CKSEL-Fuses entsprechend gesetzt sind, und dass dieser Pin dann
nicht als Ausgang zur Verfügung steht?
Der PB7 schaltet auf dem Mega8 und in der Simulation nicht. Schalten
soll er aber nicht. Erst im nächsten Schritt. Und der läuft richtig!
Hab einen internen Takt von 4 MHz in den fuses eingestellt!!
MFG Mixer
spess53 wrote:
> Hi>> Interruptroutinen, wie 'timer_overflow' müssen mit 'reti' nicht mit> 'ret' beendet werden.
:-)
Den hab ich auch gesehen. Und er wahrscheinlich selber
auch.
Aber schau mal in die main Schleife
loop: sei
rjmp loop
:-)
Hallo,
das habe ich bereits verbessert, siehe oben!!
Allerdings für die falsche Ausgabe der LEDs hab ich noch keine
vernünftige Antwort bekommen!!
MFG Mixer
Bist du sicher, dass du für die Simulation genau den Controller
eingestellt hast, den du auch in der Praxis mit dem Code fütterst?
Ich teste den Code jetzt mal mit ATMega8
... laaaaaaaaaange Pause und dann zurück nach oben
Ich habe den Code gerade mal bis 1 s Realzeit durchsimuliert und bekomme
nur die Patterns:
01110000
01100000
01000000
welche alle in Zeile 213 gesetzt werden. Alle anderen Out-Befehle werden
wegen deiner Modifikation nicht ausgeführt, das oberste Bit (PB7) wird
nie gesetzt. Also Bestätigung von meiner Seite.
Hast du mal versucht die LEDs einzeln anzusteuern? Also einmal alle aus,
nur PB7, nur PB6, etc... ?
1
ldi r16, 0b00000000
2
out PORTB
3
loop: rjmp loop
1
ldi r16, 0b10000000
2
out PORTB
3
loop: rjmp loop
1
ldi r16, 0b01000000
2
out PORTB
3
loop: rjmp loop
etc.
- Ist Stufe 7 die einzige oder nur die erste die nicht funktioniert?
- Was passiert, wenn du die Masken in Stufe 7 alle auf 0 setzt?
- reduzier mal den Code so lange, bis das Problem verschwindet - gerade
jetzt wo nur Stufe 7 angesprungen wird kannst du die anderen mal
rausnehmen.
- Ist das richtig, dass Stufe 2 nicht wie die anderen Stufen formuliert
ist?
- Lass mal testhalber den ADC raus.
- habe var gessen, was ich gerade wollte... ach ja: die linke LED wirkt
auf dem Foto dunkler als einige anderen. Hast du die mal mit 'nem Oszi
durchgemessen, was da für ein Signal im Vergleich zu den anderen
anliegt? Alternativ nach Möglichkeit die Timer so langsam machen, dass
man die LEDs beim Schalten beobachten kann.
- Wenn der Vergleich in Zeile 15 fehlschlägt, bricht der zu "rjmp LED1"
durch. Bitte dokumentieren, dass das nicht passieren darf. Besser wäre
hier eine Fehlerbehandlung oder ein unbedingter Sprung -> potenzielle
Fehlerquelle.
und wo ich eh gerade an deinem Code am rumnörgeln bin: Assembler ist
eigentlich eine wunderschöne Sprache - bitte bring etwas Ordunng in
deinen Code, insbesondere, wenn er nicht rund läuft. Wie Mister
Buchegger schon erwähnt hat steigt dadurch auch die Lust, dir zu helfen,
und es zeigt, dass du dir Mühe gegeben hast.
Geschwindigkeitsoptimierungen zu Lasten der Lesbarkeit kann man immer
noch später einbauen, wenn notwendig. Nutze die Makro-Fähigkeiten des
Assemblers - ist besser zu dokumentieren. du hattest ja geschrieben,
dass du Neuling bist - nimm's also als Verbesserungsvorschlag auf.
Einige deiner Code-Snippets sind etwas merkwürdig:
1
in ADCin, ADCL
2
clr ADCin
3
in ADCin, ADCH
warum clearst zu den Register, wenn du ihn direkt danach mit einem neuen
Wert überschreibst? Warum wird ADCL überhaupt ausgelesen, wenn es eh
nicht verwendet wird?
"If the result is left adjusted and no more than 8-bit precision is
required, it is sufficient to read ADCH." - Seite 198 im Datenblatt
Du kannst ADCH ganz normal auslesen.
Ich empfehle immer alle Interrupt-Vektoren zu definieren und die
ungenutzen auf ein iret oder eine Fehlerbehandlung umzuleiten. Wenn
versehentlich Interrupts ausgelöst werden, die du nicht möchtest,
verursacht das keine sporadischen Resets oder andere schwer
diagnostizierbare Verhalten. Beispielcode findest du auf Seite 47.
Schöne Grüße
Kai
Blöde Frage:
Da ich jetzt nicht mitgekommen bin, was jetzt in der Simu passiert und
was am realoen Mega...
Ist vielleicht nur die LED kaputt, kalte Lötstelle ?
Gruß ka-long
Hallo,
Habe jetzt das Programm ohne die Software-PWM ausprobiert und einen
ähnlichen Fehler festgestellt! Dann hab ich mir mal meine
Streifenraster-Platine von unten angeschaut, und festgestellt, dass da
eine Leiterbahn-Unterbrechung nicht ganz in Ordnung ist. Habe diese mit
m Skalpell ein bisschen nachbearbeitet und schon funktioniert alles ohne
Probleme!!
Danke nochmal für eure Bemühungen!!
MFG Mixer
Am Sonntag vor dem Mittagessen
kann man gut den Kurzschluß messen.
Dagegen: Bei Fehlersuche nachts um Eins
macht oftmals sich zum Heinz!
(alte Volksweisheit)
;-))
Paul
