Moin Experten habe ein Problem mit der Auslesung der Tabele und zwar wird nur der erste Eintrag gelesen und weiter komm er nicht.Das Programm hängt da irgen wo. Nun meine Frage was muss ich tun damit die gesammte Tabelle gellesen wird. Das Programm ist im Anhang. Erst mal DANKE für Euer bemühen. coluna.
Vermutlich tritt in der Tabelle ein Überlauf bei der add-Funktion auf. Du solltest also den Beginn der Tabelle auf eine 256-Byte Grenze legen oder bei der Berechnung des Zeigers auf deine Tabelle auch das Highbyte des PCL (PCLATH) mit berücksichtigen. Und schreib mehr Kommentare. Du wirst nach vier Wochen Probleme bekommen dein eigenes Assemblerprogramm noch lesen zu können. Gruß Sven
Moin Sven, Anfänger Problem!! wie macht man das mit PCL (PCLATH) ? Damit kein Überlauf stattfindet? hab da zwar ein Buch aber richtig erklärt wird das dort auch nicht.
coluna schrieb: > Anfänger Problem!! wie macht man das mit PCL (PCLATH) ? Microchip beschreibt dies in der Application Note 556. > Damit kein Überlauf stattfindet? Die Tabelle mit ORG auf den Anfang eines 256 Word Bereichs legen: org 0x100 table addwf PCL,f retlw h'3F' retlw h'06' ... tableend Oder mit Makros ermitteln, ob die Tabelle eine 256 Word-Grenze überschreitet. Das Makro sorgt dafür, dass beim Assemblieren in dem Fall eine Fehlermeldung erscheint. #if ( (table & 0xFF00) != ((tableEnd-1) & 0xFF00) ) ERROR "Table crosses 256 word block boundary" #endif #if ( (table & 0xFF00) != 0 ) ERROR "Table not in first 256 bytes of page" #endif
Ich schau mal heute Abend, wie ich das immer gemacht habe. Kann im Moment nicht auf meine Quellen zugreifen.
stepp64 schrieb: > Vermutlich tritt in der Tabelle ein Überlauf bei der add-Funktion auf. Ich habe das Programm mal durch dem Assembler laufen lassen. Ein PCL-Überlauf tritt dabei nicht auf. Das Programm ist kürzer als 256 byte. Wie stepp64 schrieb, besteht allerdings die Gefahr, dass bei der ADD-Funktion ein Sprung entsteht, der außerhalb der Tabelle landet. Ich hatte vor einiger Zeit aber das gleiche Problem mit eben diesem PIC. Das Programm stürzte beim Aufruf der Tabelle ab, die Ursache konnte ich nicht finden. Das richtig merkwürdige an dieser Sache war jedoch, dass das Programm mit einem anderen PIC-Typ (16F84) bisher ohne Probleme lief. Es wurden lediglich die Registeradressen geändert. Vielleicht gibt es da ein Hardwareproblem ... Ich habe das dann auf die harte Tour gelöst, indem ich den Tabellenzeiger mittels subwf abgefragt und den Rückgabewert mit movlw zugewiesen habe.
Hallo, wenn ich das Programm Simuliere erhalte ich diese Meldung:CORE-E0001: Stack over flow error occurred from instruction at 0x000039 Was bedeutet das?
>table addwf PCL,f > movwf PORTB > movf PCLATH,f > movwf PORTA > retlw h'3F';ohne org 800 > retlw h'06' > retlw h'5B' So gehht das nicht. Das "addwf PCL" muss natürlich DIREKT vor der Tabelle stehen. Im Datasheet zum PIC muss eigentlich ein Beispiel sein.
Wie versprochen hier mal meine Routine, welche ich seit einiger Zeit so benutze. Sie ist unabhängig von den 256-Byte-Speichergrenzen. Hier als Beispiel in einer Uhrenanwendung
1 | ;Anzahl Tage je Monat ermitteln |
2 | Offset_Uhr |
3 | movwf tmp1 ;W sichern |
4 | movlw High (Tabelle_Uhr) ;High Tabellen Vektor holen |
5 | movwf PCLATH ;Vektor nach PCLATH schreiben |
6 | movlw Low (Tabelle_Uhr) ;Low Tabellen Vektor holen |
7 | addwf tmp1,w ;Low Vektor hinzu addieren |
8 | btfsc STATUS,C ;Gab es einen Übertrag? |
9 | incf PCLATH,f ;ja, PCLATH incrementieren |
10 | movwf PCL ;und springen |
11 | Tabelle_Uhr |
12 | retlw .0 ;Dummy |
13 | retlw .32 ;Januar |
14 | retlw .29 ;Februar |
15 | retlw .32 ;März |
16 | retlw .31 ;April |
17 | retlw .32 ;Mai |
18 | retlw .31 ;Juni |
19 | retlw .32 ;Juli |
20 | retlw .32 ;August |
21 | retlw .31 ;September |
22 | retlw .32 ;Oktober |
23 | retlw .31 ;November |
24 | retlw .32 ;Dezember |
Hoffe es nützt was.
Hallo Sven, nee läuft auch noch nicht . Irgend etwas ist hier faul. Muss doch nochmal das Programm überarbeiten. Aber erstmal vielen DANK für Eure bemühen. coluna.
> list p=16F876 ; Baustein > ... > __CONFIG 0x3F72 ; konfigurationsort 16F876 Diese beiden Zeilen meckert mein Assembler an. Außerdem ist der Code schwer zu lesen, mal werden Werte binär übergeben, mal hex und dann wieder dezimal. Unklare Calls und Sprünge. Es ist kaum etwas dokumentiert, so weißt du in 4 Wochen nicht mehr, was das ganze Programm soll. Von einem Außenstehenden ganz zu schweigen. Was soll das Programm machen? Eine LED-Anzeige ansteuern? Dann teste das Programm doch erstmal ohne die Tabelle. Übergebe einen dir passenden Rückgabewert und springe zurück, z.B. so: table retlw 05BH Wenn das zur Zufriedenheit läuft, kannst du dich der Tabelle widmen.
Jens das war ein guter Tip! Ohne Tabelle läuft es durch. Ich werde mmich jetzt Stück für Stück heran tasten bis es durch läüft. Übriigens habe ich das Programm auf der suche nach einer LCD-Anzeige im Internet gefunden und war neugierig was es wohl machte. war wohl nix!! coluna.
coluna schrieb: > Ohne Tabelle läuft es durch. Na das ist doch schon mal was. Vielleicht kannst du das Programm (mit Tabelle) mal auf einem anderen PIC testen. Ich hatte mit dem 16F876 ebenfalls Probleme bei einer Tabelle. Das komische dabei ist, das Programm lief vorher auf einen 16F84 anstandslos mit der Tabelle. Ich will keine Gerüchte in die Welt setzen, aber hier tendiere ich mittlerweile zu einem Bug im PIC.
Was ich gerade sah: Du rufst in der Routine display diese erneut mit einem call display auf. Das kann nicht funktionieren, da der Stack nach 8 Durchläufen überläuft. Eventuell steckt da ja schon der Fehler. Sven
coluna schrieb: > Hallo, > wenn ich das Programm Simuliere erhalte ich diese Meldung:CORE-E0001: > Stack over flow error occurred from instruction at 0x000039 > Was bedeutet das? Genau das: stepp64 schrieb: > Was ich gerade sah: Du rufst in der Routine display diese erneut mit > einem call display auf. Das kann nicht funktionieren, da der Stack nach > 8 Durchläufen überläuft. Eventuell steckt da ja schon der Fehler. > > Sven Du hattest den Grund ja schon gefunden. Und der arme PIC ist wohl nicht buggy.
ich bin der Sache schon halb auf der Spur, mache solange weiter ,bis es läuft. Das bin ich meinem EGO schuldig. Am Configurations_Hader glaube ich muss ich auch was tun " __CONFIG _PWRTE_ON & _WDT_OFF & _HS_OSC & _BODEN_OFF & _LVP_OFF" hier meldet er mir nähmlich ERROR.
Also dein Configwort ist nicht falsch, jedenfalls nicht das was du hier geschrieben hast. Genauso verwende ich es auch für einen 16F877. Aber ich habe weitere Fehler gefunden: 1. ONE hat die selbe RAM-Adresse wie AMOUNT 2. PORTA ist nicht auf digital Output initialisiert, deshalb keine Ausgaben auf PORTA 3. Wie schon geschrieben ruft sich die Routine display selbst auf. Das führt zum Absturz (nimm einfach das call display in der Routine raus) Die Tabelle funktioniert im Simulator ordnungsgemäß. Stelle mal die o.g. Fehler ab, und dann schau weiter. Und kommentiere das Programm etwas. Sven
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.