Hallo,
ich habe mir eine kleine FFT gebastelt und lasse die werte auf einem LCD
ausgeben, allerdings hat sich irgendwo ein fehler eingeschlichen, den
ich aber nicht erblicke. Dieser äußert sich so, dass nach ein paar
sekunden, die Werte auf dem Display nicht mehr aktualisiert werden.
Meine Vermutung lag bezüglich dem Code für die Anzeige, allerdings
funktioniert dieser einwandfrei bei anderen sachen. Jetzt muss das
irgendwie mit dem code für die tranfsormation zusammenhängen, allerdings
bin ich im avr Studio dem fehler nicht auf die schliche gekommen und bin
immer noch dabei, vielleicht hängt das aber nur mit einem oder zwei
registern zusammen, die ab einem bestimmten wert aus ADC mist bauen,
oder der ADC läuft nicht korrekt.
Iczh bin für jede Hilfe dankbar, zumal ich das projekt vor meinem
Studium angefangen habe und es nun endlich korrekt zum laufen bringen
möchte.
Jo danke, werde es gleich mal ausprobieren, der push und pop ist sowieso
überflüssig gewesen, ich denke, dass ich über weihnachten dann mal den
code entmüllen werde.
Da Du keine Interrupts verwendest, wo man gerne mal ein Register
vergisst, wird es an diesen liegen - ausmisten schadet nie und achte
darauf, für jedes "push" unbedingt (im wahrsten Sinne des Wortes !)
immer ein "pop" zu verwenden.
Gruss Otto
Hi
Bei deiner sehr minimalistischen Verwendung von 'push' und 'pop' in
Unterprogrammen würde es mich nicht wundern wenn du irgendwelche
relevante Register überschreibst.
MfG Spess
Ist wohl ein Stackproblem (igitt) und ein Berechnungsproblem (übel) und
man kann beides im AVR Studio simulieren (yammi).
Der Ersatzcode für "ADC Werte" ist z.B.
messen:
; START ERSATZ
nop ; hier BREAKPOINT
ldi r16, 0x00
ldi r17, 0x01 ; oder 0x03 oder 0x12 oder 0x00
ret
; ENDE ERSATZ
sbi ADCSRA,6 ;Starte Konversation
messen2:
sbic ADCSRA,ADSC ;Springe wenn Konversation beendet
rjmp messen2
in r16,adcl
in r17,adch
ret
Dann die IO-View Processor aufmachen und laufend F5 (RUN).
Der Stackpointer ist beim ersten Break 0x25D und sinkt dann alle 8. Mal
beim drücken von F5 um eins. Irgendwann häckselt der Stackpointer dann
im IO-Bereich rum. Beim 7. => 8. Mal vergeht eine längere Zeit in der
Simulation, scheint eine Berechnung zu sein.
Verwendet man anderen Ersatzcode (andere ADC Werte) z.B.
messen:
; START ERSATZ
nop ; hier BREAKPOINT
ldi r16, 0x00
ldi r17, 0x02
ret
; ENDE ERSATZ
vergeht beim 7. => 8. Mal sehr viel Zeit in der Simulation. Wenn man
dort break macht, steckt die Simulation in der Berechnung einer
Wurzel.
wurzeldiv: ;a/xn
sub r16,r7
sbc r17,r8
sbc r18,r9
sbc r19,r10
sbrc r19,7
rjmp wurzeldivend ; <== wird nicht ausgeführt
inc r20
rjmp wurzeldiv
und kommt nicht mehr raus (r10 und r19 sind 0x00). Man kann die
Endlosschleife mit dem "falschen" ADC-Wert 0x02 nach r17 auslösen.
Das mit dem durch null dividieren ist selbst aufgefallen, allerdings ist
mir das mit dem stackpointer etwas suspekt. Warum sollte der immer
sinken, was er auch tut. Liegt das daran das ich da irgendwo mit den
push und pop´s durcheinander komme??? Die aufrufe der unterprogramme
sind alle korrekt, soweit ich das sehe.
Mir ist das mit dem Stackpointer auch suspekt, sehr suspekt. Deswegen
hatte ich es dir beschrieben. Damit du dort nachschaust. Kannst du das
Problem an sich sehen oder tritt das Problem bei dir nicht auf?
ADD: Ende gut alles gut.
Hallo Fred!
Hast du zufällig ein Video von der laufenden FFT?
Gibts zu dieser FFT evtl auch einen Pseudo Code oder eine nähere
Beschreibung?
Möchte sie gerne für den 8051 umsetzen..
Danke und Lg, Mike
Bin jetzt auch mal hier angemeldet. Die FFT ist einfach ein radix2
algorithmus, bei google einfach radix2 eingeben und dann bei den bildern
oder links schauen. Wie ich das jetzt umgesetzt habe, kann ich noch mal
ausführlicher posten. Das einzig "tricky" an der ganzen Sache ist, die
Zählregister zu Verwalten, die auch die Werte für die Sprünge bei den
Ram Addressen liefern sollen, dann braucht man die Daten nur noch am
ende zu sotieren, was ich aber noch nicht geschrieben habe.
