www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik PIC16F876 Problem mit Tabelle


Autor: coluna (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Andreas Riegebauer (blackpuma)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nix im Anhang.

Autor: coluna (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
ich hoffe das er sich jetzt im Anhang befindet.

Autor: schwups... (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bischen Kommentar im Programm wäre hilfreich.

Autor: stepp64 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: coluna (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Severino R. (severino)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: stepp64 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich schau mal heute Abend, wie ich das immer gemacht habe. Kann im 
Moment nicht auf meine Quellen zugreifen.

Autor: Jens PICler (picler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: coluna (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
ich hab mal das Programm geändert seh es Euch mal an.

Autor: coluna (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
wenn ich das Programm Simuliere erhalte ich diese Meldung:CORE-E0001: 
Stack over flow error occurred from instruction at 0x000039
Was bedeutet das?

Autor: ich (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Sven Stefan (stepp64) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
;Anzahl Tage je Monat ermitteln  
Offset_Uhr
  movwf  tmp1        ;W sichern
  movlw  High (Tabelle_Uhr)  ;High Tabellen Vektor holen
  movwf  PCLATH        ;Vektor nach PCLATH schreiben
  movlw  Low (Tabelle_Uhr)  ;Low Tabellen Vektor holen
  addwf  tmp1,w        ;Low Vektor hinzu addieren
  btfsc  STATUS,C      ;Gab es einen Übertrag?
  incf   PCLATH,f      ;ja, PCLATH incrementieren
  movwf  PCL        ;und springen
Tabelle_Uhr
  retlw  .0        ;Dummy  
  retlw  .32        ;Januar
  retlw  .29        ;Februar
  retlw  .32        ;März
  retlw  .31        ;April
  retlw  .32        ;Mai
  retlw  .31        ;Juni
  retlw  .32        ;Juli
  retlw  .32        ;August
  retlw  .31        ;September
  retlw  .32        ;Oktober
  retlw  .31        ;November
  retlw  .32        ;Dezember

Hoffe es nützt was.

Autor: coluna (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jens PICler (picler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: coluna (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jens PICler (picler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: stepp64 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Severino R. (severino)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: coluna (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Sven Stefan (stepp64) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.