Hiho AVR-Chiefs! ich habe hier leider ein kleines logisches problem, bei dem ich ums verrecken nicht weiter komme. Grober Überblick: es geht um eine Datenkonvertierung für ein uraltes Gerät, dessen Drucker seit der Steinzeit nicht mehr hergestellt wird und der vorhandene gestorben ist. Der "alte" Drucker druckte im Grafikmodus 280x8 pixel pro Zeile. genau das gleiche macht der neue Drucker auch, aber erwartet PCL5: 0..7 = 1. Byte a..h = 2. Byte A..H = 280. Byte Druckbild: 0a...A 1b...B 2c...C 3d...D 4e...E 5f...F 6g...G 7h...H Datenstrom zum alten Drucker: 01234567abcdefghABCDEFGH Neuer Drucker: 0aA1bB2cC3dD4dD5fF6gG7hH Alles klar? Jo, dachte ich mir auch und habe folgende Konverterroutine gebaut. und sie funktioniert nicht. Bevor ihr fragt: der Stack pointer wird beim init gesetzt. Die routine funktioniert für die ersten 2-3 Ausgabebytes in allen 8 Zeilen und danach kommt nur noch schrott zum Drucker. Bitte schaut mal durch, kann es sein, dass ich die Probleme durch das LSL bekomme? Vielen Dank für Eure Hilfe!!!
Hi nochmal! Ich habe mir die Routine nochmals durchgeschaut und kann echt keinen Fehler finden. Kann es sein, dass der Z-Pointer mit dem mehrmaligen LD r16, Z+ Probleme bereitet? Buf_IN: .BYTE 280 ist halt schon relativ gross... Ich habe so langsam das Gefühl als ob Z+ nur das ZL inkrementiert und das ZH vergisst. kann das sein? Oder wird der Speicher für Buf_IN: .BYTE 280 nicht am Stück belegt? (das kann ich mir nicht vorstellen) Habt Ihr da echt keine Idee warum diese Routine nicht funktioniert? Das bricht mir dann demnächst echt noch das Genick ;)
ich hab so auf anhieb auch nichts gefunden, aber auch nur mal überflogen und nicht im studio simuliert. Z+ erhöht zl und zh der speicher des buffers ist ziemlich sicher auch zusammenhängend wenn ich raten sollte würde ich sagen du baust die bytes in der falschen reihenfolge (LSB/MSB) auf. dem würde natürlich entgegensprechen das die ersten bytes richtig sein sollen. Bei 0a..A ist die 0 bei dir im lsb. pcl5 kenne ich allerdings nicht, vielleicht ist das ja auch richtig so. Peter
Okay... das mit dem Z+ wars also nicht. Was passiert eigentlich mit dem Carry bit im SREG wenn ich wie im obigen Programm die ganze Zeit immer mit LSL die bits rumschiebe? Mich persönlich interessiert das Carry ja nicht, da ich keinen Übertrag brauche, aber macht der AVR vielleicht probleme, wenn ich das Carry nicht manuell lösche? Kann ich mir eigentlich nicht vorstellen.. Ne andere Möglichkeit wäre der Speicherbereich... Wenn als einzigste Definition Buf_IN: .BYTE 280 steht, fängt der Buffer dann auch wirklich am Anfang des SRAM an (0x0060) oder legt er diesen Pointer wahllos irgendwo hin? Ich werde mal probieren, den pointer mittels .EQU Buf_IN = 0x0060 zu setzen. Mal sehn, ob es das ist...
Also die Routine läuft (habe anstatt dem LD temp, Z+ ein LDI temp, 0b10111101 eingebaut und die routine hat mir dann anstatt senkrechte linien nach der konvertierung waagrechte ausgedruckt. das lief perfekt. aber was mich jetzt arg beunruhigt ist: irgendwas mache ich mit dem ST und LD falsch... liegt es etwa an der deklaration im DSEG? ich blick es nicht mehr. also es geht alles, bis auf das ablegen der daten im sram und das anschliessende mehrmalige auslesen!
Hi! Jo das könnte Ärger machen. Lasse das Prog doch mal im Simul.laufen. Auf was läd er denn ZL/ZH. Persöhnlich hätte ich vermutlich Start und Ende direkt angegeben .equ Buffstart=$60 .equ Buffend = Buffstart +280 . . ldi Zl,Buffstart clr Zh Bei Buffend aber dann Zh mit laden. MFG Uwe
Hat sich erledigt... vorhin hatte ich mir unmengen coke und kippen reingezogen bis ich mal auf die idee gekommen bin, mir die veraenderung der Register ZL und ZH einfach mal ausdrucken zu lassen. Folgendes Szenario passiert da: in der Loop habe ich LD temp, Z+ toll... ZH ist bei allen 280 (!) durchläufen = 0 und ZL springt in einem bestimmten Muster immer auf die gleichen 8 Speicheradressen... Klar dass da nur müll bei rauskommt. das gleiche gilt für ST Z+, temp Habe den scheinbaren hardware-bug jetzt mit RCALL INC_Z nach jedem LD oder ST gelöst und das Programm läuft einwandfrei. INC_Z inkrementiert ZL und bei einem Überlauf auch ZH, mehr nicht. Naja, vielleicht hilft diese Erkenntnis auch ein paar anderen :) Trotzdem bleibt es mir ein Rätsel wieso und warum ;-)
zumindest im AVR-Studio Simulator ist das nicht der fall, hab ich jetzt extra mal ausprobiert. da läuft zl/zh genau wie ich das erwartet habe. vielleicht hast du ja bei deiner zh/zl ausgabe an den registern rumgepfuscht?!? ansonsten hoffe ich mal, daß das kein allgemeiner hardwarebug ist, sondern dein prozessor einfach nur defekt ist. Peter (letztes doppelposting muß wohl durch seite vor und zurück entstanden sein :-() Peter
Ja, hoffe ich auch. Ich werde bei Gelegenheit mal ein paar neue 8515er kaufen und genau das selbe Programm nochmal testen... Kann sein, dass ich ne geschrottete Serie erwischt habe. Mir ist jedenfalls aufgefallen dass bei allen 3 uC's die ich ausprobiert habe, jeweils eine Handvoll EEPROM Speicherzellen im Eimer sind... Falls es mit künftigen Serien immer noch nicht klappt sag ich Euch hier bescheid!
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.