www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Wie funktioniert die Segmentierung beim PIC?


Autor: jmoney (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tach,
ich habe eine Tabelle im PIC implementiert. Jetzt bin ich auf die
Segmentierung der PICs gestoßen, von der man des öfteren in
irgendwelchen µC-Vergleichen hört. Für mich macht das ganze aber keinen
Sinn, da die Segmente irgendwie an willkürlichen Adressen anzufangen
scheinen. Im Datenblatt steht dazu komischerweise nichts (oder ich bin
zu blöd, um es zu finden. Dort lassen sie sich nur über die Pages aus.
Weiß hier jemand, wie das genau funktioniert oder wo man sich darüber
informieren kann?
Ich wär euch echt dankbar für jeden Tipp.

Autor: Gerhard Gunzelmann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo jmoney

das steht schon im Datenblatt. Grundsätzlich ist nur das RAM von der
Segmentierung betroffen. Da werden 2 Bits im Status Register
gesetzt/zurüchgesetzt um die Bänke umzuschalten. Genau wie bei den
Intelprozessoren hat das alle historische Gründe. Wenn du das umgehen
willst, dann nimm PIC-18 Typen, da gibts den Müll nicht mehr.


Gruß
Gerhard

Autor: jmoney (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Genau das meinte ich NICHT. Mein Programm liegt komplett in der ersten
page/Bank. Wenn ich den Anfangspunkt der Tabelle auf 0x0320 lege
funktioniert auch alles. Wenn ich sie allerdings zB auf 0x0310 lege,
bleibt das Programm nach 0x031F hängen. Das hat definitiv nichts mit
den pages zu tun. Ich habe allerdings schon ein paar mal gelesen, dass
man aufgrund der veralteten internen Busstruktur nur auf jedes zweite
Segment zugreifen kann oder so ähnlich. Ich weiß leider nicht mehr wo.
Außerdem hat da IIRC keine Erklärung dafür dabeigestanden.
Das Programm basiert auf einer Application Note von Microchip also denk
ich mal das sollte richtig sein.

Autor: Manfred Glahe (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
@jmoney

habe Dein Problem nicht richtig verstanden, aber im Anhang mal ein
Prog. mit Tabelle zur Einsicht.

MfG  Manfred Glahe

Autor: Steffen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das Problem liegt zum einen darin, dass der PIC ja nach Kern 12,14 oder
16 Bit Befehlsbreite hat, in denen der Befehl (z.B. Sprung) und auch
die Adresse codiert ist. Daher ist auch der Programmspeicher in mehrere
Bänke aufgeteilt. Bei den 14-Bit Derivaten sind das 2k. Sprünge von
einer Bank in eine andere sind möglich, es müssen aber vorher die
entsprechenden Bits in PCLATH gesetzt werden.

Zum zweiten kann es Probleme geben, wenn zu PCL ein Offset addiert
wird. Tritt dabei ein Überlauf ein, dann geht der Sprung ins Nirvana.
Wenn die Tabelle also länger wird ist es sinnvoll vorher zu testen ob
ein Überlauf auftritt und wenn ja PCLATH zu erhöhen.

Beispiel: Die Tabelle fängt bei 0x00f0 an und es soll auf das 20-igste
Element zugegriffen werden. Addiere ich den Offsett zu PCL bekomme ich
0xf0 + 0x14 = 0x04 + Überlauf. Wird vorher nicht PCLATH erhöht geht der
Sprung auf Adresse 0x0004 und das Programm macht das, was es eigentlich
nicht soll.

Dein Problem kann ich allerdings auch nicht ganz nachvollziehen. Was
meinst Du mit "Ich habe allerdings schon ein paar mal gelesen, dass
man aufgrund der veralteten internen Busstruktur nur auf jedes zweite
Segment zugreifen kann oder so ähnlich."?

Steffen

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

Bewertung
0 lesenswert
nicht lesenswert
So, ich hab den Fehler im Programm gefunden. Ich hatte schon mal eine
funktionierende Routine und komischerweise den gleichen Fehler. Dann
hab ich beim dran rumbasteln den code bis zur Unkenntlichkeit
zerstückelt und einfach wieder neu angefangen. Diesmal hab ich mich -zu
nah- an ein code-Beispiel aus Microchip's AN556 gehalten. Ich habe den
code mal angefügt und meine Änderungen druntergeschrieben.
Wäre nett, wenn sich das mal jemand anschauen und mir erklären könnte.
Ich verstehe nämlich immer noch nicht, warum es mit der Tabelle an
Adresse 0x0320 ging und sonstwo nicht.
Danke schonmal für die Tipps bisher!

Autor: Steffen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Code sollte eigentlich unabhängig von der Position der Tabelle
funktionieren. Lass das ganze doch einfach mal durch den Simulator
laufen. Dann siehst Du genau wo er hinspringt.

Steffen

Autor: jmoney (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der code mit den Anderungen geht auch, nur der ursprüngliche nicht. Mit
dem Simulator komme ich überhaupt nicht klar, der springt immer an ganz
komische Stellen. Statt zu Show_Screen zu springen, geht er wo ganz
anders hin.

Autor: Steffen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der geäderte Code sollte aber eigentlich absolut das gleiche bewirken
wie der Originalcode (Vorausgesetzt Du lädst AdrH mit high Table). Ich
kann jedenfalls nichts erkennen, was eine andere Reaktion zur Folge
hätte. Wenn Der Simulator schon nicht funktioniert, dann ist irgend
etwas oberfaul. Wenn er irgendwohin springt, wo er nicht hin soll, dann
steht in PCLATH evtl Müll drin.
Unter View/Special Function Registers kannst Du dir übrigens alle SFRs
anzeigen lassen und kannst den Programmablauf kontrollieren.

Steffen

Autor: Manfred Glahe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@jmoney,

das wollte ich Dir auch raten, die watch windows sind ideal um Fehler
aufzufinden. Allerdings ist der erfolgreiche Durchlauf in der
Simulation noch keine Garantie dafür, daß das Prog. im PIC auch richtig
funktioniert! Im Moment suche ich nämlich ebenfalls einen Fehler,
obwohl die Simulation erfolgreich beendent wurde. Das exact selbe Prog.
steckt bereits in einem PIC16F84 und arbeitet einwandfrei, übertragen
mit der alten MPL Software. Seit ich die neue Version unter WIN98
laufen lasse habe ich diverse Probleme zu verzeichnen die ich im Moment
jedenfalls absolut nicht verstehe. Der Verdacht liegt nun so, daß ich
vermute, unfreiwillig (mit RB6/RB7 auf 0) in den Prog. Modus zu geraten
was auf der Platine selbst zu suchen währe. Habe wohl noch einen
mühsamen Tag vor mir.

MfG  Manfred Glahe

Autor: Steffen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Manfred

Ich hatte letztens ein ähnliches Problem. Ich bin von einem PIC16XXX
auf den PIC16XXXA umgestiegen. Nach der Neucompilierung und der
Prozessorumstellung funktionierte nur noch ein Teil des Programmes
allerdings mit dem ICE2000. Ursache war, das MPLAB bei der
Prozessorumstellung die Fuse-Bits zurücksetzt, wenn diese nicht direkt
mit im Programm stehen. Blöder Fehler von mir aber ich habe mir einen
Wolf gesucht.

Steffen

Autor: jmoney (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Simulator funktioniert beim FUNKTIONIERENDEN code nicht. Und er
macht gar nicht erst den call auf die Show_Screen Routine, also hat das
mit AdrH wohl eher nichts zu tun. Wenn ich im ursprünglichen code AdrH
mit high Table lade, lädt er es doch später eh wieder neu oder? Deshalb
funktioniert das wohl auch immer nur 256 Instruktionen lang..

Autor: Manfred Glahe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

mein Problem habe ich nun lösen können. Der PIC16F84 war nur ein 4MHZ
Type  (der einzige in meiner Schachtel)und die Beschriftung ist
besch... zu lesen! Von mir nur mit Lupe und Zusatzbeleuchtung. Der
Oszillator arbeitete jedenfalls mit ausreichender Amplitude, allerdings
habe ich nicht die Frequenz gemessen und mir gestern damit den ganzen
Tag versaut.
Wenn MPLAB schon nach dem speziellen PIC Type fragt, dann währe die
Frage nach der Taktrate auch sinnvoll gewesen denn dann hätte ich nicht
so lange suchen müssen. Jeder Sch... wird abgefragt, aber solche Sachen
muß man selbst rausfinden! Wenn wenigstens die Beschriftung klar zu
lesen währe! Aber in jedem Falle mein Fehler.

@jmoney,

da kann Dir aus der Ferne so schnell wohl niemand helfen, das ist wohl
nur an Deinem Platz zu lösen. Mir fällt dazu jedenfalls nichts ein.

MfG  Manfred Glahe

Autor: jmoney (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hm naja das Programm läuft ja soweit.. Mit dem Simulator muss ich mich
dann wann anders mal nochmal beschäftigen, wenn ich mal vieel Zeit
habe..
Danke für eure Hilfe Jungs!

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

Bewertung
0 lesenswert
nicht lesenswert
Das ist doch zum verrückt werden. Ich dachte, es ginge alles und wollte
im Programm weiter machen. Jetzt hat sich rausgestellt, dass es nur bis
zum 108. Zeichen funktioniert, dann resetet der PIC. Die 108 Zeichen
sind unabhängig davon, ob in der Tabelle noch was hinten dran steht und
auch unabhängig davon, an welche Stelle im Programmspeicher ich die
Tabelle schreibe. Das lässt sich schön feststellen, indem man mal 5
Zeichen weglöscht, dann geht er 5 Zeichen weiter. Ich hab mal (wieder)
alles, was ich für relevant halte, im Anhang. Immerhin macht der
Simulator mittlerweile das gleiche wie der PIC, nämlich nach 108
Zeichen resetten. Watchdog ist aus. Ich werde noch wahnsinnig..

Autor: Steffen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was heißt der PIC macht einen Reset? Wenn Du das Ganze im Simulator
verfolgst (Schritt für Schritt), dann siehst Du doch welche Werte in
PCL und PCLATH geladen werden und wo er hinspringt. Reset würde ja
bedeuten, dass er auf 0x0000 springt. Bist Du dir sicher, dass der
Watchdog aus ist?

Wenn Du bei MPLAB unter View/Programm Memory auswählst, dann kanst Du
übrigens genau verfolgen wo er gerade im Programm steht, was bei der
ASM-Ansicht nicht unbedingt der Fall ist.

Steffen

Autor: Manfred Glahe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@jmoney,

in dem von mir geposteten Prog. habe ich noch die Sprungmarken von GOTO
nach z.B. folgendermaßen (im alten MPLAB) geschrieben:

AMP2:  bsf  PORTB,6  ; Digpot 2 rückwärtszählen PosFlanke
  bcf  PORTB,6  ; Digpot 2 rückwärtszählen NegFlanke
  GOTO  AMP1

AMP2:
  bsf  PORTB,6  ; Digpot 2 rückwärtszählen PosFlanke
  bcf  PORTB,6  ; Digpot 2 rückwärtszählen NegFlanke
  GOTO  AMP1

Ich habe unter langem SUCHEN (denn planmäßiges vorgehen kann ich das
nicht mehr nennen) folgendes festgestellt: Wenn die Einsprungmarke in
der selben Zeile steht wie der erste Befehl, dann hängt das Prog. dort
fest. In dem Prog. gibt es viele solcher GOTO'S und das schlimmste
ist, das funktionierte bei den allermeisten Sprüngen. Eben nur bei
einigen nicht! Ich habe Programmierer befragt die mehr Erfahrung mit
dem MPLAB hatten als ich und denen ist (nachdem sie meine Angaben erst
einmal ausgiebig belächelt hatten) auch keine Erklärung dafür
eingefallen. Deshalb habe ich profilaktisch in allen meinen
Nachfolgeprogrammen diese Zeile eingerückt und erst in der nächsten
Zeile den ersten Befehl placiert.
Im MPASM USER'S GUIDE ist im "absolut code" weder der Doppelpunkt
vorgesehen noch ist die zeile eingerückt.
Meine Programme laufen nun aber unter allen Bedingungen (denen ich sie
bis jetzt ausgesetzt habe) und deshalb bleibe ich bei dieser
schreibweise. Mit der von MPLAB ging es jedenfalls NICHT richtig, egal
auch warum.
Der finale Test, wenn ich meine das Prog. läuft, ist bei mir der Blick
auf meinen Oszischirm und nicht mehr "succesfull" von MPLAB.

MfG  Manfred Glahe

Autor: Steffen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Manfred,

so ein Fehler ist mir bisher noch nie aufgefallen. Hängt dann nur der
Simulator? Das die Ausführung im PIC nicht funktioniert ist ja eher
unwahrscheinlich. Hast Du da evtl. noch ein Beispiel, wo man das mal
testen kann?

Für die meisten Prozessoren habe ich das entsprechende Prozessormodul
für das ICE2000 und verwende den Simulator daher eher weniger aber in
der nächsten Zeit wird das etwas mehr werden, da ich nicht immer für
jeden Prozessor ein Modul für 500,-€ kaufen kann.

Steffen

Autor: Manfred Glahe (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
@Steffen,

da hängt dann nur der Simulator fest. Das Programmieren des PIC
funktioniert und der PIC tut auf dem Oszi auch was er soll.

Was meinst Du mit "Hast Du da evtl. noch ein Beispiel, wo man das mal
testen kann?", ältere Programme? Das Programm oben ist genau jenes,
welches zum erstenmal mit solchem Fehler im SIM aufmuckte.

Desweiteren ist mir immer noch nicht klar warum (wie oben geschildert)
der 4MHZ PIC das Prog. mit einem 4.19 MHZ (PIC schwingt mit der
Oszifrequenz) nicht ausführt, sondern völlig  chaotisch reagiert. Ein
20MHZ Type macht exact das was er soll. Allerdings weiß ich nicht wie
der 4MHZ überhaupt in meine Kiste gelangte, ich habe jedenfalls immer
nur den 20MHZ Type bestellt (kontrolliere natürlich nicht jeden
einzelnen besch... zu lesenden Aufdruck).
Im Anhang mal das Prog. um welches hier geht, arbeite gerade daran
(deswegen herrauskommentierte Stellen)um das Auslesen über PC, direkt
aus dem externen FRAM zu bewerkstelligen.
Übrigens beim 68HC11 ist mir soetwas nie passiert! Den PIC habe ich
eingeführt um einen kleinen stromsparenden Käfer fürs Gelände zu
haben.

MfG  Manfred Glahe

Autor: Steffen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Manfred

Ich meinte ein Programm, wo definitiv der Fehler auftritt. Na ja, ich
bin auf jeden Fall gewarnt, falls die aktuelle version immer noch
solche Fehler machen sollte.
Der PIC wird wahrscheinlich gerade so noch mit 4MHz funktionieren oder
ist evtl. gar schon defekt. Mit dem 84-igern arbeite ich schon lange
nicht mehr. Wenn dann setze ich die F62x ein. Sind günstiger, können
mehr und sind zuverlässig.

Steffen

Autor: jmoney (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bitte beiß mich einer in den Hintern. Es lag daran, dass der DT-Befehl
keine unendlich lange Zeile interpretieren kann. Danke vielmals für den
Tipp mit Program Memory anschauen. Da hab ich nämlich gesehen, dass er
das vorletzte retlw 0xff auf retlw 0xf verkürzt und dann nur noch addlw
0xff als Platzhalter schreibt. Also ist er den Rest des Programms
durch, nämlich immer addlw 0xff und hat dann wieder von vorne
angefangen, ohne jemals einen return gemacht zu haben.
Wenn ich einfach mehrere DT-Befehle hintereinander schreibe, erzeugt er
genau den gewünschten code und es funktioniert. Da muss man nur mal
drauf kommen..
Hoffentlich zum letzten mal für diesen thread danke Leute!!

Autor: Mifare (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Na und ich wollte nicht meckern, das man eigentlich keine so langen
Zeilen schreibt. Hätte ich doch mal :-).

Steffen

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Es lag daran, dass der DT-Befehl
keine unendlich lange Zeile interpretieren kann."

Hast Du schon einen Bugreport an Microchip gesendet ?

Der Assembler sollte dann wenigstens eine Fehlermeldung ausgeben, daß
die Zeile zu lang ist.

Einfach nur falschen Code zu erzeugen, ist dagegen ein schwerer Bug.

Insbesondere, da ja die Tabellenzugriffe ohne das RETLW komplett
abstürzen.
Bei allen anderen µC-Architekturen erfolgen Tabellenzugriffe über
Pointer, d.h. der Programmfluß gerät nicht komplett aus den Fugen.


Peter

Autor: jmoney (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Juhu, ich hab einen schweren Bug entdeckt ;)
Jetzt muss ich nur noch rausfinden, welcher bug in MPLAB es mir nicht
erlaubt, Daten ins EEPROM zu schreiben und wieder zu lesen.. ;)

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.