AVR Programm Zeitschleifenproblem

Igel · Anmeldungsdatum: 18.03.2005 Beiträge: 20

Hi Leute,

ich hab zur Zeit ein Problem bei einem AVR-Mikrocontroller Programm, und zwar möchte ich eine Ampel steuern. Zu diesem Zweck habe ich div. Zeitschleifen verschachtelt. Jedoch stimmt die Zeit die ich ausgerechnet habe nie mit der Realzeit überein, allerdings bestätigt die Simulation des AVR-Studios meine Berechnung genau!!!! LOL Hammer

So und jetzt des Problem: grübelnd

Normalerweise sollte es an der Hardware liegen, jedoch habe ich es auch mit einer anderen Hardware getestet die !sicher!funktioniert.(Sprich Quarz AVR usw KÖNNEN es nicht sein)!

Please Help Gott

.include "4433def.inc"
.org 0x000
rjmp boot

.def temp = r16
.def led = r17
.def time1 = r18
.def time2 = r19
.def time3 = r20
.def time4 = r21
.def taster = r22

boot:
ldi temp, ramend
out sp, temp
ser temp
out ddrd, temp
clr temp
out ddrb, temp

main:
ldi led, 0b00010001
out portd, led

loop:
in temp, pinb
com temp
ldi taster, 0b11000000
sub taster, temp
tst taster
breq loop

zeit1:
rcall time
inc time4
cpi time4, 10
brne zeit1
clr time4

ldi led, 0b00001001
out portd, led

zeit2:
rcall time
inc time4
cpi time4, 5
brne zeit2
clr time4

ldi led, 0b00000101
out portd, led

;usw...

rjmp main

time:
inc time1
tst time1
brne time
inc time2
tst time2
brne time
inc time3
cpi time3, 20
brne time
clr time3
ret

Gast

Ich denke das ist gelinde gesagt auch Müll was du da programmiert hast. Wenn der Chip eingebaute frei verfügbare Timer hat dann solltest diese benutzen. Das ist zwar etwas schwieriger zu realisieren, kommt dann aber auch treffender hin.

Wie hast du die Zeit bei deiner Version berechnet ??
Hast auch beachtet dass der Chip evtl. nebenbei noch diverse Interruptfunktionen ausübt, die Zeiten berücksichtigt die er für die einzelnen Befehle in deiner Zeitschleife benötigt usw.. Der zählt dein time1 Register nicht im Systemtakt hoch!!

hier gehört noch ein >clr time4< hin

clr time4
zeit1:
...
...

und zur Sicherheit (wer weiß was sonst noch so alles läuft innerhalb des Prgs) auch

clr time1
clr time2
clr time3
clr time4
zeit1:
...

clr time1
clr time2
clr time3
clr time4
zeit2:
...

ob sich das mit dem Rest des Prgs verträgt musst du entscheiden.

Die Zeitdifferenzen dürften aber nicht darauf, sondern auf das oben beschriebene zurückgehen

dachdecker2

Assembler ist ja gut und schön, wenn man schwierige bzw. zeitkritische Sachen lieber "selbermachen" will. Warum verwendest du nicht C und schreibst nur den in Assembler benötigten Teil in Assembler? Der Vorteil wäre, dass das ganze um längen übersichtlicher wird. Du könntest einen der Timer (unbegrenzt viele sinds nicht, je nach Controllertyp 2 oder 3) verwenden, um den Takt zu steuern. So würest du auch die störanfälligkeit gegenüber anderen Interrupts verringern.

Du sagst, dass du das Prog schon auf anderer Hardware laufen hattest. Wie kannst du dann ausschließen, dass die Hardware die Probleme verursacht? Bist du sicher das der Oszillator ordentlich läuft? Bist du sicher, dass die Fuses richtig gesetzt sind? Wenn die Software geht, kann meiner meinung nach nur Die Hardware schuld sein (was denn sonst?).

Igel · Anmeldungsdatum: 18.03.2005 Beiträge: 20

Ich selber würde es auch mit Timern machen, da ich selber besser AVR programmieren kann, der Fehler trat bei nem
Klassenkollegen auf, aus dem Grund wollte ich sein Programm nicht verändern. Habe auserdem mit Assembler schon nen gut funktionierenden DDS-Generator gebaut der sicher und stabil lief auf der Hardware! D.h. Die Hardware ist i.O. und mit dieser guten Hardware habe ich das Prog. getestet und es funktionierte auch nicht!
Es würde mich einfach interessieren warum des nett passt mit der Zeit?

MFG Igel

PS: @ Dachdecker REAL Programmers code in binary LOL Hammer

PS: @ Gast Ich weis dass er time1 nicht im Prozessortakt hochzählt und
wenn du in dem Programm nen Interrupt findest bist du gut!

dachdecker2

Gast

zum Interrupt, nun du hast ja nur einen Teil des Programms gepostet ...

aber an der Menge NORMAL üblicher Interrupts sollte es dennoch nicht liegen(bei versehentlich hochgeschraubter Interruptfrequenz schon eher)

woran es liegt ist nicht zu beantworten solange du nicht wenigstens
DEINE Zeitberechnung hier vorstellst.

Was Assembler angeht, so stehe ich da nicht hinter dachdeckers Position, ich finde Assembler nachwievor höchst interessant für solche elementaren Dinge. Was anderes ist es wenn der Chip z.B. sowas komplexes wie eine
harte Ver-und Entschlüsselung oder ähnlich komplexe Dinge auszuführen hat, dann wirds schrecklich unübersichtlich und fehlerbeladen, schon im Handumdrehen