komme bei den warnungen nicht weiter

hallo

habe mal die datei compeliert und es funktioniert ohne Fehlermeldung.
aber sone meldung hatte ich auch schon mal weiß aber nicht mehr in 
welchen zusammenhang diese meldung aufgetreten ist.

habe in AvrStudio einfach eine neues Projekt angelegt und den Code 
hineinkopiert dann compeliert.

gruß gast

danke, werde das mal probieren, und auch auf dem avr selbst, liegt wohl 
an dem AVR-Studio

Funktioniert,  bie mir nicht so, habe den code in ein neues projekt 
kopiert, aber die Meldungne kommen beim Debuggen immer noch.

Ich weiß gerade nicht, wie das bei Assembler ist, aber kannn es sein, 
dass das daran liegt, dass low, high, sph und spl klein geschrieben 
sind? Also bei C könnte es daran liegen;)

Hi

Läuft bei mir problemlos
Hast du im Simulator den richtigen AVR ausgewählt?

MfG Spess

Hallo,

ich kann nur die Beobachtung von Spess bestätigen, dass dieser "Stack 
Pointer Fehler" vom AVR-Studio genau dann ausgegeben wird, wenn man man 
nicht in allen Einstellungen den selben AVR auswählt.

Gruß

  risu

habe high und low bei der initialisierung groß geschrieben und es kommen 
keine meldungen mehr. vorerst, habe das schon mal gehabt und am nächsten 
tag kamen wieder neue stackpointer meldungen.

immer wenn ich den simulator neu starte kommen diese meldungen obwohl 
ich den code geändert habe.

Hi

>habe high und low bei der initialisierung groß geschrieben und es kommen
>keine meldungen mehr. vorerst, habe das schon mal gehabt und am nächsten
>tag kamen wieder neue stackpointer meldungen.

Den AVR-Assembler interessiert Groß/Kleinschreibung überhaupt nicht. 
Also noch mal: Welcher Controller ist bei 'Debug->Select Platform and 
Device' eingetragen?

MfG Spess

atmega8535

und als debug platform avr simulator

außerdem ist es komisch, dass ständig andere addressen im programm als 
AVR Simulator: Uninitialized stack pointer used at 0x0061 angezeigt 
werden

Hi

Das irritiert mich. Ich habe dein File kopiert. Ein Projekt erzeugt und 
das File als Entry File deklariert. Assembliert und 'Start Debugging' 
angeklickt. No Problem.

MfG Spess

habe da mal einen breakpoint gemacht und gemerkt, dass die 
fehlermeldungen erst kommen, wenn ich das programm einige zeit laufen 
habe. selbst bei run und ohne breakpoint.

jetzt kommt AVR Simulator: Uninitialized stack pointer used at 0x004b
AVR Simulator: Invalid opcode 0xffff at address 0x008888

wo kann man den denn noch einstellenl, außer bei project settings, mal 
abgesehen davn, läuft der auch nicht richtig auf dem richtigen avr, aber 
wenn ich alles durchrechne, komme ich auf keinen fehler. Entweder ich 
übersehe etwas oder das ist kein fehler meinerseits, sondern ein bug im 
avr studio.

Hallo,

der von Dir beobachtete Fehler ist bei mir reproduzierbar (AVRStudio 
4.14 Build 589). Mal sehen, ob ich etwas finde.

Gruß

 risu

Hallo Christoph,

ich habe zum Testen ein ".org 0" eingebaut -- trotzdem tritt der Fehler 
auf. Der "Assembler 1" gibt viele, viele Fehlermeldungen; vielleicht 
kommt man dadurch weiter.

Gruß
  risu

Hallo,

Deine Daten im Codesegment habe ich mit entsprechenden .orgs auf gerade 
Adressen gelegt, aber auch das ändert nichts. Die Hamming-Tabelle ist 
129 Einträge lang - ist das korrekt?

Hat nichts mit dem von Dir geschilderten Problem zu tun:

kurzen4:
  clr r19
  ldi r19,2
Wenn ich nichts übersehen habe, ist "clr r19" redundant.

Aber das eigentliche Problem bleibt ungelöst. Ich hatte zunächst 
gedacht, dass Deine .db Tabellen eine zu große Zeilenlänge haben (weiß 
nicht, was für den "Assembler 2" die Obergrenze ist), aber auch das hat 
sich nicht bestätigt.

Ich habe den ATmega8535 noch nie selbst verwendet; vielleicht ist etwas 
in den zugehörigen Definitions-Dateien nicht in Ordnung? Rätselhaft.

Gruß

  risu

Hi,

vielleicht gibt es ein Problem mit der Datei "ATmega8535.xml"? In diesem 
Forum gibt es einige Experten dafür (hallo Jörg Wunsch und andere!).

Gruß
  risu

ich glaub, dass ich den code mal für mega 8 modifizieren werde um zu 
sehen, was los ist. den atmega8535 hatte ich hier zu hause und wollte 
das mal ausprobieren. Danke für die vielen antworten

anbei nochmal den code wie er jetzt von mir benutzt wird

Hi

Ich hatte gestern Abend das Programm nur ein Stück mit 'F11' geteste. 
Deshalb ist der Fehler nicht aufgetreten. Heute ist mir folgendes 
aufgefallen:

stufex:          ld a1,X+        ;X+1
                 add r26,punkte      ;zweiten wert laden
                 adc r27,punkte2      ;X+n/2-1
                 ld a2,X
                 rcall takeahalf      ;Werte halbieren da sonst die 
Register überlaufen
                 mov r18,a2
                 sub a2,a1
                 mov cos,a2
->               st X,a2
                 sub r26,punkte
                 sbc r27,punkte2      ;X-n/2-1
                 sbiw X,1        ;X-1
                 add a1,r18
                 st X+,a1        ;X+1

An der Stelle mit dem Pfeil ist plötzlich X=$000A. Diese Adresse ist 
r10. Damit wird e2 überschrieben. Das ist also ein Programmfehler.

MfG Spess

HI

>anbei nochmal den code wie er jetzt von mir benutzt wird

Kommen bei dir keine Warnungen beim Assemblieren?

MfG Spess

nur bei den lookuptables

der fehler von spess53 konnte ich nicht beobachten.

Hi

Und weisst du auch, was das heisst: Der Assembler hängt an jede 
.db-Zeile eine 0 an. Damit ist deine Tabelle hinfällig.
In solchen Zeilen muss die Anzahl der Bytes geradzahlig sein!!!!!!!!!!!!

MfG Spess

wusste ich nicht, habe das erste mal mit lookup tables gearbeitet

Hi

Man sollte auch Warnungen beachten. Trotzdem bekomme ich auch bei deinem 
neuen Programm  bei Befehlen wie 'st X,r17' X-Werte, die nicht im RAM 
liegen (X<$0060).
vermutlich wird irgendwo der Stackpointer zerschossen. Ich hoffe, dir 
ist bewusst, daß du mit X,Y,Z den gesamten RAM inclusive r0..r31 und 
IO-Register adressieren kannst.

MfG Spess

Hallo Spess und Fred,

bei meinen Tests habe ich die Tabellen auf gerade Adressen gelegt und 
eine geradzahlige Anzahl von Elementen benutzt - der Fehler trat 
trotzdem auf.

Gruß

 risu

ich glaube, dass der fehler zu dumm war. ich habe nämlich vergessen, den 
X-pointer vor dem speichern des realteils nach der komplexen 
multiplikation um n/2-1 zu erhöhen

        add r28,punkte
  adc r29,punkte2

  st Y,r17
  sub r28,punkte
  sbc r29,punkte2

  mov r16,r18
  mov r17,sin

  rcall mult        ;b0*b1

  mov r17,raus1
  sub r17,r16        ;a0a1-b0b1

      ->add r26,punkte      ;X+n/2-1
      ->adc r27,punkte2
  st X,r17
  sub r26,punkte
  sbc r27,punkte2

so wie ich dass beim Y-pointer gemacht habe.
jetzt kommen auch keine fehler mehr, da der X-pointer nicht auf 
addressen außerhalb des ram's zeigt.

HI

@risu  Da .db-Anweisunge immer an einer Word-Adresse liege ergibt sich 
automatisch eine gerade Byteadresse.
Wie ich schon geschrieben hatte bekomme ich beim Simulieren, speziell 
bei RAM-Zugriffen über X, Adressen <$60. Das passiert immer dann, die 
StackFehler-Meldungen kommen.

MfG Spess

der code funktioniert dank der behebung des fehlers jetzt einwandfrei. 
muss diese teil mal gelöscht haben, weil ich eigentlich vor hatte die 
ganze sache mit 16bit zu machen.

Hi

Zum Test setzt einfach einen Data-Breakpoint auf X. Da wird das Programm 
angehalten, wenn auf X zugegriffen wird. Im Processor-Tab kann der Wert 
von X überprüft werden.

MfG Spess