Es geht auch richtig los. zuerts leuchten die roten LED.
Es wird aber Port B2, B1, B5 ausgelassen. Keine Ahnung warum. Dann
warter er eine Weile und fängt wieder bei von vorn an.
Was ist da los???
Warum geht er nicht im Programm wieter und warum werden die LEDs
ausgelassen.
Die LEDs sidn aber nicht defekt.
Bitte um Hilfe
Heiner
Heiner H. wrote:
> Es geht auch richtig los. zuerts leuchten die roten LED.> Es wird aber Port B2, B1, B5 ausgelassen. Keine Ahnung warum. Dann> warter er eine Weile und fängt wieder bei von vorn an.> Was ist da los???
Er warte eine Weile. Was ist eine Weile? 64ms?
Dann klingt das nach Watchdog-Auslösung. Ist Watchdog auf immer aktiv
geschaltet?
Heiner H. wrote:
> Es geht auch richtig los. zuerts leuchten die roten LED.> Es wird aber Port B2, B1, B5 ausgelassen. Keine Ahnung warum. Dann> warter er eine Weile und fängt wieder bei von vorn an.> Was ist da los???
Sagte ich schon mal, dass du dich mit deinem Debugger beschäftigen
sollst?
Du brauchst das Ding!
Also beschäftige dich damit, wie man das Teil bedient!
Damit kannst du dein Programm in Einzelschritten durchgehen
und nachsehen, welche Register sich wie verändern.
Du kannst einen Breakpoint setzen und das Programm
simulieren lassen, bis die Programmausführung einen
bestimmten Befehl erreicht. Dort kannst du dann wieder
nachsehen, welche Register welchen Wert haben etc.
Beschäftige dich damit! Du brauchst den Simulator.
ja im Simulator habe ich schon alles ausprobiert. DAs ist ja das
komische. Dort funktioniert alles.
Wie ist das mit der Watchdog? Ist die von allein angeschaltet?
Und as passiert dann?
Heiner H. wrote:
> ja im Simulator habe ich schon alles ausprobiert. DAs ist ja das> komische. Dort funktioniert alles.
Wenn auch nur zufällig. Aber du hast recht, es funktioniert.
> Wie ist das mit der Watchdog? Ist die von allein angeschaltet?
Nein. Hast du an den Fusebits rumgespielt?
> Und as passiert dann?
dann macht der µC einen Reset und fängt wieder von vorne an.
Hallo Heiner,
schau Dir mal den Befehl ROL in der AVR-Dokumentation an.
Vielleicht klärt sich dann, wie aus
LDI schieb, 0b00000000
über
ROL schieb
eine Abfrage
CPI schieb, 0b11111111
sinnig oder unsinnig wird.
Stichwort carry-bit...
Gast wrote:
> Hallo Heiner,> schau Dir mal den Befehl ROL in der AVR-Dokumentation an.> Vielleicht klärt sich dann, wie aus> LDI schieb, 0b00000000> über> ROL schieb> eine Abfrage> CPI schieb, 0b11111111> sinnig oder unsinnig wird.> Stichwort carry-bit...
Drum sagte ich auch, dass es Zufall ist, dass sein Programm
funktioniert. Die 'warten' Subroutines setzen das
Carry Flag.
Ich brenn das ganze jetzt mal in einen Mega16.
Eine Frage noch: Wie sind die LED angeschlossen?
Direkt ueber einen Widerstand oder ist da noch was
dazwischen?
Hallo Karl Heinz,
>Drum sagte ich auch, dass es Zufall ist, dass sein Programm>funktioniert. Die 'warten' Subroutines setzen das>Carry Flag.
Nein, tun sie nicht.
DEC beeinflusst kein Carry-Bit.
Dafür gibt es SUBI.
Nachtrag zu oben...
Nicht, dass ich SUBI in den Warte-Unterprogrammen
empfehlen würde. ;-)
So war das nicht gemeint.
Es wäre extrem schlechter Programmierstil, ein gesetztes
Carry-Bit aus einer Warteschleife heraus zu nutzen.
Wenn es denn so sein soll, bitte die Anweisung
SEC
vor dem
ROL
einfügen.
Kostet nichts und schafft klare Verhältnisse.
Karl heinz Buchegger wrote:
> Ich brenn das ganze jetzt mal in einen Mega16.
Gesagt, getan.
Sieht eigentlich gut aus. Das Programm setzt eine LED
nach der anderen, so wie es programmiert ist.
Wenn es das bei dir nicht tut, dann liegt die Ursache
irgendwo anders in einem Bereich, den wir nicht einsehen
können.
Gast wrote:
> Hallo Karl Heinz,>>>Drum sagte ich auch, dass es Zufall ist, dass sein Programm>>funktioniert. Die 'warten' Subroutines setzen das>>Carry Flag.>> Nein, tun sie nicht.> DEC beeinflusst kein Carry-Bit.> Dafür gibt es SUBI.
OK.
Dann ist es der CPI der das Carry setzt.
(Ist auch logisch, x - FF setzt immer das Carry
es sein denn x sei gleich FF, dann endet aber die
Schleife sowieso. Ich denke trotzdem immer noch nicht,
dass das so beabsichtigt war :-)
Wie auch immer, beim 2.ten und folgendem Durchlauf durch die
Schleife wird definitiv eine 1 aus dem Carry hereinrotiert.
Gast wrote:
> Genau ;-)> Das ist ein ziemlich tückischer Fehler.
Yep.
Ich hab mich auch gewundert als im ersten Schleifendurchlauf
(klarerweise nichts passierte), aber im nächsten Durchlauf
tauchte dann plötzlich die 1 auf. Hab nicht weiter nachgedacht
wo die herkommt und habs mal fälschlicherweise auf die warten
geschoben.
> Ich empfehle, mit> SEC> ROL schiebe> für klare Verhältnisse zu sorgen.
Das ist sicher ein guter Rat. Dadurch ist alles klar.
Aber das erklärt noch nicht, warum bei ihm PB1, PB2 und PB5
nicht mitspielen. An PB5 hängt noch MOSI, d.h. da ist die
ISP Schnittstelle dran. Das liefert aber keine Erklärung für
PB1 und PB2.
Und für die restlichen beiden Ports sowieso nicht.
Was ich mir vorstellen könnte:
Alle 32 LED sind auf ca. 20 mA eingestellt. Dadurch wird
die maximale Stromabgabe überschritten oder das Netzteil
geht soweit in die Knie, dass die Versorgungsspannung
zusammenbricht. Irgendsowas in der Art.
Software ist i.O..
Ist deine Energieversorgung auch i.O.?
Wenn du viele LEDs an hast wird auch viel Strom gezogen. Schafft das
deine Stromversorgung? Mit Oszi überprüfen ob Einbrüche vorhanden. Würde
Resetverhalten erklähren.
Einzelne Bits werden ausgelassen -> Hardware überprüfen. Schiebe doch
einfach mal nur ein Bit durch. Dann wird nur eine LED je Port
ausgegeben. Kurzschlüsse zwischen den Pins lassen sich so leicht finden.
Auch braucht nur eine LED viel weniger Strom.
Karl heinz Buchegger wrote:
>> Ich empfehle, mit>> SEC>> ROL schiebe>> für klare Verhältnisse zu sorgen.
Der Vergleich sorgt für Carry. SEC ist nicht nötig.
warten erzeugt kein Carry sondern Zero.
>Karl heinz Buchegger wrote:>>> Ich empfehle, mit>>> SEC>>> ROL schiebe>>> für klare Verhältnisse zu sorgen.>Der Vergleich sorgt für Carry. SEC ist nicht nötig.>warten erzeugt kein Carry sondern Zero.
Karl kann nichts dafür - der Vorschlag wuchs auf meinem
Mist.
Der erste Rotiervorgang bei mainX wird mit Carry = 0
ausgeführt. Erst die weiteren nach dem Vergleich (CPI)
dann mit Carry = 1.
Ich kann mir nicht vorstellen, dass das bewusst so
vorgesehen war. Wenn doch, dann war es extrem pfiffig
ausgedacht. Dazu passt aber der ganze Programmierstil
nicht so recht. :-)
Wie auch immer - schön (in den Augen eines AVR-Assembler-
Anwenders) ist es nicht.
Auch wenn es vermeintlich überflüssig scheint, das
eingefügte SEC trägt zur Transparenz bei.
Es sind genau solche Optimierungen, die einem bei
komplexeren Projekten dann eine Menge Zeit für
Debugging stehlen.
Ich bin ja auch blutiger Anfänger in AVRasm, aber was erhoffst du dir
von dem Timer0 Overflow Interrupt? Oder hab ich was übersehen?
Gut, mal abgesehen davon das du gar keinen timer verwendest sondern
knallhart die Zyklen abwartest. Ich hab mir mal sagen lassen das es NIE
ein Fehler ist die Interruptvektoren vollständig einzubauen.
Das kann hier zwar nicht zu einem Fehler füren, weil der Interrupt ja
nie kommt, aber schön ist das nicht. -wiebel
Hallo Michael,
das ".org OVF0addr" ist in der Tat entbehrlich.
Es schadet nicht und es nützt nicht.
Im schlimmsten Falle kann es verwirren.
Allerdings würde ich ".cseg" noch vor ".org 0x0000"
setzen. Der Ordnung halber.
Das sind typische Anfängerfehler. Mit ein wenig
mehr Routine wird das schon. :-)
Also ich habe jetzt erstmal noch alle LEDs getestet. Defekt ist
ausgeschlossen.
Alles richtig gepolt und angeschlossen. Ich habe alle LEDs über ein
Transisor Array angeschlossen (UDN2981A).
Das komische ist ja aber auch, das das Programm dann einfach von vorne
anfängt. Vielleicht hat ja noch jemand irgendwelche Tips, bitte...
mfg
> Das komische ist ja aber auch, das das Programm> dann einfach von vorne anfängt.
stellt sich die Frage nach der Spannungsversorgung - wie sieht die denn
aus ?
Gruss Otto
Also habe es jetzt auch mit dem SEC probiert, ändert auch nichts.
Bei den Pins hatte ich mich verschrieben. denn es sind die Pin B0,1,2
und 5.
Wie gesagt, LEDs gehen auf jeden Fall alle.
Das komische ist aber auch, das ieder von vorne angefangen wirde, wenn
er mit dem roten fertig ist.
Was ist da blos los???
Kann jemand helfen?
mfg
Heiner
achso, hatte ich ganz vergessen. Ihr habt recht, die stößt an ihre
Grenzen. das NT geht bis 1A, die LEDs ziehen alleine schon 980mA. Aber
warum fängt er dann immer wieder von vorne an, bei rot,wenn er mit dem
roten Aufbau fertig ist.
Wie ist das bei einem ComputerNT, kann ich das da ranhängen? Wie viel
Strom kann man da pro Molex ziehen? und komisch ist ja auch, das ein
paar ausgelassen werden.
Die Spannung bricht ein, "Brown out" spricht an, Reset und von vorne.
NEIN - nimm kein Computernetzteil - das braucht eine Mindestlast und
wenn die (kurz) nicht mehr da ist, bekommst Du wieder einen "Reset"
Gruss Otto
Naja - funktionieren wird es, Du solltest nur den Strompfad zu Deiner
Schaltung seperat absichern (z.B. mit 2A), denn ein Computernetzteil hat
"richtig" Power.....
Otto
