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.
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
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.
@jmoney habe Dein Problem nicht richtig verstanden, aber im Anhang mal ein Prog. mit Tabelle zur Einsicht. MfG Manfred Glahe
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
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!
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
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.
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
@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
@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
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..
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
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!
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..
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
@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
@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
@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
@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
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!!
Na und ich wollte nicht meckern, das man eigentlich keine so langen Zeilen schreibt. Hätte ich doch mal :-). Steffen
"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
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.. ;)
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.