Hallo, Forum, ich habe ein in Assembler für den PIC16F873 geschriebenes Programm, das auf der zugehörigen Hardware einwandfrei funktioniert. Ich möchte das Programm gern erweitern und dazu auf den PIC16F876A umsteigen. Zunächst habe ich zum Testen das selbe Programm, im CONFIG für PIC16F876A konfiguriert, in den PIC16F876A geladen und erprobt, aber ohne Erfolg: Die Hardware scheint zu spinnen. Ich gehe davon aus, dass der einzige Unterschied der beiden Controller die Größe des Programmspeichers ist. Liege ich da falsch? Danke für die Hilfe Dieter
Dieter Kohtz schrieb: > Ich gehe davon aus, dass der einzige Unterschied der beiden Controller > die Größe des Programmspeichers ist. Liege ich da falsch? Eher nicht aber das "A" des 876 könnte auf Unterschiede zum 873 ohne A hinweisen.
Die ueblichen Verdaechtigen sind AD-Wandler und Komparatoren die es aus- bzw. einzuschalten gilt. Keine Ahnung warum die immer per Default an sein muessen. Das DB weiss da mehr. Und die Konfiguration des Taktes sollte natuerlich auch passen.
hi, hier der unterschied zum a-type, daraus folgt dein problem NICHT! http://ww1.microchip.com/downloads/en/DeviceDoc/39591a.pdf mt
:
Bearbeitet durch User
Hallo, Rollo, weder ADC noch Comparatoren sind aktiviert. Takt: 4 MHz, nix Besonderes. Gruß, Dieter
@ majortom Danke für die Unterlagen. Nach meinen bisherigen Erfahrungen fand ich - jedenfalls beim 873 keine Unterschiede zum A-Typ. dk
Dieter Kohtz schrieb: > Ich gehe davon aus, dass der einzige Unterschied der beiden Controller > die Größe des Programmspeichers ist. Liege ich da falsch? Das ist eine doppelt blöde Frage. Weil: 1) > umsteigen. Zunächst habe ich zum Testen das selbe Programm, im CONFIG > für PIC16F876A konfiguriert, in den PIC16F876A geladen und erprobt, aber > ohne Erfolg: Die Hardware scheint zu spinnen. D.h.: die normative Kraft des Faktischen zeigt doch sehr deutlich, dass du einfach falsch liegen MUSST. 2) Kannst du die beiden DBs vergleichen, zumindest eins davon solltest du ja bereits aus dem FF kennen. Also einfach das zweite lesen, dann sollten dir (nach 1) offensichtlich vorhandene) Unterschiede eigentlich irgendwann auffallen... Du musst dann nur noch rauskriegen, welcher dieser Unterschiede das abweichende Verhalten am ehesten erklären könnte. Reine Fleißarbeit, die dir niemand abnehmen wird, denn dazu müßte man das Programm kennen, was du aber offensichtlich nicht veröffentlichen möchtest... Also: mach's dir doch einfach selbst!
Wenn alle Stricke reißen hab ich hier noch einen ICE2000 Emulator und sowohl für 16F873/76 als auch für die A-Typen den passenden POD. Rechner mit altem MPLAB und LPT-Schnittstelle gips auch noch.
Dieter Kohtz schrieb: > Ich gehe davon aus, dass der einzige Unterschied der beiden Controller > die Größe des Programmspeichers ist. Liege ich da falsch? Ich hab mir mal die Datenblaetter angesehen und die Unterschiede zusammenkopiert. Eigentlich sollte dein Programm funktionieren.Ich wuerde aufjedenfall das Setup der eingesetzten Pic-Peripherie nochmal genau durchgehen.Solltest Du Interrupts einsetzen: der 876a hat einen mehr - muss eventuell deaktiviert werden
@Toxic Apollo M. schrieb: > http://ww1.microchip.com/downloads/en/DeviceDoc/39591a.pdf Besten Dank für Deine Mühe. Danach und nach dem, was Apollo M. mir schickte, sollen die A-Typen "pin- und funktionskompatibel" mit den A-losen sein. Demnach müsste mein Programm eigentlich funktionieren, zumal von der PIC-Peripherie weder ADC, CCPMW, MSSP noch Interrupts eingesetzt sind. dk
Einige config-bits unterscheiden sich, besonders bei der memory protection. Mit entsprechendem Programm kann das für Ärger sorgen.
Dieter Kohtz schrieb: > Ich gehe davon aus, dass der einzige Unterschied der beiden Controller > die Größe des Programmspeichers ist. Hast du dir mal die Speicherverwaltung (RAM) angesehen? Es gibt da zwei gravierende Unterschiede.
Dieter Kohtz schrieb: > Besten Dank für Deine Mühe. Danach und nach dem, was Apollo M. mir > schickte, sollen die A-Typen "pin- und funktionskompatibel" mit den > A-losen sein. In dem Vergleich sind zusätzliche Komparatoren. Die sind per default eingeschaltet (d.h. analoge Eingänge der Grund ist m.W. Latchup Gefahr bei Reset). Die musst du erst mal abschalten. Heisse Kandidaten sind auch die Clock sources / settings und die Config Register. Evtl mal nach migrate 16f873 googlen
John schrieb: > Hast du dir mal die Speicherverwaltung (RAM) angesehen? > Es gibt da zwei gravierende Unterschiede. X4U schrieb: > Die sind per default > eingeschaltet Danke, Ich verwende 70 RAM-Adressen, sehe im DB keine Unterschiede der Verwaltung. Nach DB sind die Komparatoren bei reset ausgeschaltet. Ich habe zusätzlich CCP1CON = Null gesetzt. So sieht CONFIG aus __CONFIG _XT_OSC & _CP_OFF & _WDT_ON & _LVP_OFF & _PWRTE_ON & _BODEN_ON Was könnte daran falsch sein??? dk
Dieter Kohtz schrieb: > __CONFIG _XT_OSC & _CP_OFF & _WDT_ON & _LVP_OFF & _PWRTE_ON & _BODEN_ON > > Was könnte daran falsch sein??? Verwendest Du den Watchdog Timer? Wenn nicht, unbedingt deaktivieren....WDT_OFF
Dieter Kohtz schrieb: > Nach DB sind die Komparatoren bei reset ausgeschaltet. Bei POR aber nicht bei Reset > Ich habe zusätzlich CCP1CON = Null gesetzt. CMCON 0:3 auf 111 wäre mein Vorschlag. Der Teil ist sehr kryptisch geschrieben, da fällt man schnell drauf rein. Im übrigen gibt es immer die Möglichkeit das sich ein Programm von irgendwo einen Wert holt wo jetzt halt was anderes steht (z.B EEPROM oder größerer Flash). Aber erst mal die Hausaufgaben: > __CONFIG _XT_OSC & _CP_OFF & _WDT_ON & _LVP_OFF & _PWRTE_ON & _BODEN_ON > Was könnte daran falsch sein??? WDT BODEN PWRTE erstmal aus. Dann wenn möglich den Oscillator rauslegen und nachmessen ob gleiche Frequenz. Wenn das nicht hilft den Code strippen und nach der init nen Port oder Lampe blinken lassen. Wenn das funzt würde ich das ganze neu schreiben (aber ich mach auch C wo das kein Problem ist).
Dieter Kohtz schrieb: > Ich verwende 70 RAM-Adressen, sehe im DB keine Unterschiede der > Verwaltung. Da wir dein Programm nicht kennen, und nicht wissen von welcher Bank du auf welche Adressen zugreifst, können wir nicht beurteilen in wie weit sich diese Unterschiede auf die Ausführung deines Programms auswirken.
X4U schrieb: > CMCON 0:3 auf 111 wäre mein Vorschlag. X4U schrieb: > BODEN PWRTE erstmal aus. John schrieb: > Da wir dein Programm nicht kennen, und nicht wissen von welcher Bank du > auf welche Adressen zugreifst, können wir nicht beurteilen in wie weit > sich diese Unterschiede auf die Ausführung deines Programms auswirken. Hallo, Ich habe die obigen Vorschläge übernommen, habe am Pin 10 4 MHz gemessen und benutze nur das RAM von Bank0, aber das Programm spinnt nach wie vor, obwohl dasselbe Programm mit dem 873A einwandfrei läuft. Ich habe bisher nie Unterschiede zwischen 873 und 873A festgestellt. Jetzt stehe ich auf dem Schlauch, da ich die Einflüsse der obigen Faktoren auf das Programm nicht nachvollziehen kann. Es handelt sich bei dem Projekt um einen Temperaturregler, der seine Messdaten von einem externen 16-bit-ADC über eine Software-I2C-Verbindung erhält, intern mit dem über Tasten einstellbaren Sollwert vergleicht und entsprechende Schaltbefehle ausgibt. Die gemessene Temperatur wird mit einer dreistelligen 7-Segment-LED-Anzeige angezeigt. Für das Regelverhalten sind per Tastenbedienung unterschiedliche Modi wählbar. Messfühler ist z.Zt. ein Thermoelement Typ K, Messbereich 999°C. Erweiterung auf Typ J und Pt100 ist geplant. dk
D.h. Du hast den Assemblercode vorliegen und nicht nur ein HEX-File? Einfach ein 873er in einen 876 laden funktioniert nicht, da z.B. die config-Adressen woanders liegen. Dann mach also ein neues Projekt mit dem PIC16F876A als µC und lade dein altes ASM-File als main-file rein. Die include directive musst Du dann natürlich auf den 876A anpassen. Und dann compiliere das für den 876A. Dann sollte die gröbsten Schnitzer weg sein.
John schrieb: > Verwendest du das interne EEPROM? @ John Ja, den ersten Teil, bis Adr. 30h Gibt es da auch Komplikationen? dk
Dieter Kohtz schrieb: > Ja, den ersten Teil, bis Adr. 30h Nur so ne Idee: Um auf die EEPROM Register zuzugreifen musst du auf Bank 2 umschalten. Beim PIC16F873 kannst du in Bank 2 auf alle 96 Byte GPR von Bank 0 zugreifen. Beim PIC16F876A nur auf die unteren 16 Byte von Bank 0, der Rest ist zusätzlicher Speicher. (siehe Bild weiter oben) Hast du dein Programm diesbezüglich geprüft?
Dieter Kohtz schrieb: > Ich habe die obigen Vorschläge übernommen, habe am Pin 10 4 MHz gemessen Auch beim alten? Dieter Kohtz schrieb: > John schrieb: >> Verwendest du das interne EEPROM? > > @ John > Ja, den ersten Teil, bis Adr. 30h Du kannst duch die Inhalte einfach mal vergleichen. Alles über 30h muss dann leer sein. BTW: Hast du eigentlich das errata gelesen?
John schrieb: > Beim PIC16F873 kannst du in Bank 2 auf alle 96 Byte GPR von Bank 0 > zugreifen. Beim PIC16F876A nur auf die unteren 16 Byte von Bank 0, der > Rest ist zusätzlicher Speicher. (siehe Bild weiter oben) X4U schrieb: > Auch beim alten? X4U schrieb: > Hast du eigentlich das errata gelesen? @John Was du schreibst, irritiert mich sehr. Bezüglich des EEPROMs habe ich mich noch nie um eine Bank kümmern müssen. Der 876A hat 256 Bytes, die ich z.B. im PICKit2-Programmer beliebig beschreiben kann. Das obige Bild bezieht sich auf RAM-Speicher. @X4U Ja, auch beim 873 habe ich 4 MHz gemessen. Das Errata habe ich auch gelesen. Es enthält nichts, was ich nicht schon berücksichtigt hatte. Kastanie schrieb: > da z.B. die > config-Adressen woanders liegen. @Kastanie Das Configurationword hat bei beiden die Adresse 2007h. Die Inhalte sind etwas verschieden, daran arbeite ich. Ansonsten meine ich, genau das getan zu haben, was du vorschlägst: Ich habe die include-Direktive #include <p16f876A.inc> dem Programm vorangestellt, es ohne Meckern compiliert und in den PIC geschrieben. Nur läuft es leider nicht fehlerfrei. Euch allen besten Dank dk
Dieter Kohtz schrieb: > Was du schreibst, irritiert mich sehr. Bezüglich des EEPROMs habe ich > mich noch nie um eine Bank kümmern müssen. Da wird genau das Problem liegen! Die Bank muss beim 16F873 nicht umgeschaltet werden, wenn nach Zugriff auf EEPROM-Register wieder RAM in Bank 0 angesprochen werden soll, da das RAM von Bank 0 in Bank 2 gespiegelt ist. Der '876 hat mehr RAM, deshalb liegt hier "echtes" RAM in Bank 2, nicht die gespiegelte Bank 0 wie beim '873. Nach Zugriff auf EEPROM muss also immer erst auf Bank 0 umgeschaltet werden, um mit den "richtigen" RAM-Daten der Bank 0 zu arbeiten. Leider ist es bei der Programmierung der 8-Bit PICs in Assembler zwingend notwendig, sich um die Bank zu kümmern!
... ich würde das program endlich mal im mplapx simulator durchspielen und nicht immer nebelös sagen läuft irgendwie nicht. wenn du das nicht kannst, dann lade das program hier hoch und wir machen das. oder soll das hin und her raten hier noch tage so weiter gehen?! mt
Der PIC16F876A hat einige kleinere Eigenarten bei der Config im Gegensatz zu anderen/alteren PICs, für den und die Nachfolger z.b. 887A gibt es auch ein extra DB wo die Eigenarten beschrieben werden bei der Portierung von Programmen. Da sind recht fiese fallen drinnen.
Apollo M. schrieb: > ich würde das program endlich mal im mplapx simulator durchspielen Warum nicht mit dem PICkit2 im Debug-Mode?
:
Bearbeitet durch User
Beitrag #5490622 wurde vom Autor gelöscht.
Ich hätte schon längst mal alle Configs raus geschmissen und das mittels "Pic Memorie Views/Configurations Bits" eingestellt und neu generieren lassen.
Thomas E. schrieb: > Nach Zugriff auf EEPROM muss also > immer erst auf Bank 0 umgeschaltet werden, um mit den "richtigen" > RAM-Daten der Bank 0 zu arbeiten. Habe ich(zwar aus anderem Grund) gemacht: ohne Ergebnis Apollo M. schrieb: > ich würde das program endlich mal im mplapx simulator durchspielen Scheint mir wegen der zugehörigen Hardware nicht sehr zielführend. Außerdem weiß ich, dass das Programm mit dem '873A läuft. K. J. schrieb: > für den und die Nachfolger z.b. 887A > gibt es auch ein extra DB wo die Eigenarten beschrieben werden Könntest du dieses Extra-DB näher beschreiben? Volker S. schrieb: > Warum nicht mit dem PICkit2 im Debug-Mode? RB6/7 sind vergeben Teo D. schrieb: > "Pic Memorie Views/Configurations Bits" Das will ich mal versuchen. Besten Dank für Eure Beiträge dk
Dieter Kohtz schrieb: > Volker S. schrieb: >> Warum nicht mit dem PICkit2 im Debug-Mode? > > RB6/7 sind vergeben Mist ;-) Ich nehme an, es ist auch nicht möglich zum Testen vorübergehend auf die Funktion der Pins zu verzichten?
Dieter Kohtz schrieb: > Apollo M. schrieb: >> ich würde das program endlich mal im mplapx simulator durchspielen > > Scheint mir wegen der zugehörigen Hardware nicht sehr zielführend. > Außerdem weiß ich, dass das Programm mit dem '873A läuft. Beim PIC16F873A gibt es auch nicht den Unterschied in der RAM-Belegung. Das ist bestimmt ein anderer Dieter Kohtz.
K. J. schrieb: > Da sind recht fiese fallen drinnen. Ich halte die Vorschläge fürs Simulieren bzw. Debuggen deshalb nicht für erfolgversprechend, weil ich ja das im '873A laufende Programm intensiv sowohl durch Simulation als auch mit der Hardware getestet habe. Der Programmcode müsste eigentlich fehlerfrei sein. Ich suche noch nach den oben zitierten "fiesen Fallen", obwohl ich mir gar nicht vorstellen kann, wie CONFIG -abgesehen von den gewollten Einstellungen- auf den Programmablauf wirkt. @Apollo M. Ich stehe nicht unter Zeitdruck. dk
John schrieb: > Das ist bestimmt ein anderer Dieter Kohtz. Nein, der bin ich noch immer. Freut mich, dass Du meine Bücher hast. dk
Dieter Kohtz schrieb: > K. J. schrieb: >> für den und die Nachfolger z.b. 887A >> gibt es auch ein extra DB wo die Eigenarten beschrieben werden > > Könntest du dieses Extra-DB näher beschreiben? Hier gibt es unter [Documents] -> [Migration Documents] zwei PDFs. https://www.microchip.com/wwwproducts/en/PIC16F876A Vielleicht hilft das weiter.
Dieter Kohtz schrieb: > Ich halte die Vorschläge fürs Simulieren bzw. Debuggen deshalb nicht für > erfolgversprechend, weil ich ja das im '873A laufende Programm intensiv > sowohl durch Simulation als auch mit der Hardware getestet habe. Der > Programmcode müsste eigentlich fehlerfrei sein. Ich suche noch nach den > oben zitierten "fiesen Fallen", obwohl ich mir gar nicht vorstellen > kann, wie CONFIG -abgesehen von den gewollten Einstellungen- auf den > Programmablauf wirkt. aber, ... im sinne von popper (falsifikation) ist das program "falsch", da hilft es dir nicht weiter immerzu zu denken es wäre ok! deine ziel hw ist jetzt 16f876A und nicht mehr 16f873. sinn macht: - das program abzuspecken, um herauszufinden, welcher teil der funktionalität das problem macht - den "auffälligen" programteil weiter vereinfachen, um einzugrenzen wo es hackt - ich würde auch im simulator intensive rumspielen und schauen, ob alles so läuft wie ich es erwarten würde und auch input stimulies verwenden - dein program kann auch ein problem besitzen, das sich bis jetzt nur nicht gezeigt hat, und jetzt mit einem veränderten pic timing, current consumption, ... oder was auch immmer zu schlägt. ich könnte tagelang über erlebte fehler berichten, die viele noch nie gehört haben. ich denke, das problem liegt nicht primär im pic16f876a, weil ich kenne die unterschiede alle und sehe kein problem - auch kein signifikantes in der pic configuration. daher glaube ich an ein problem im zusammenspiel mit deiner peripheren hw und einem eben nicht "robusten" program. sprich, deine denke ist verkehrt rum, der 16f876A ist nicht das problem, aber dein "fehlerfrei gewünschtes" program sehr wohl. nimm auch einen oszi in die hand und schau dir alles genau an! daher zuerst klären was geht nicht UND dann warum! (dein warum? war der 16f876a! und da sehe ich das problem nicht) John schrieb: > Vielleicht hilft das weiter. das hilft NULL weiter und ist nur weiteres gerate, wie alle ideen davor. weil, das eine dokument war bereits bekannt und das andere passt hier nicht. again, ich würde verifizieren welche funktionen sind in der geänderten hw/pic ok und welche nicht. ... und erst dann kommt die erleuchtung - hoffentlich :-)! mt
Dieter Kohtz schrieb: > Ich halte die Vorschläge fürs Simulieren bzw. Debuggen deshalb nicht für > erfolgversprechend, weil ich ja das im '873A laufende Programm intensiv > sowohl durch Simulation als auch mit der Hardware getestet habe. Der > Programmcode müsste eigentlich fehlerfrei sein. Ich suche noch nach den > oben zitierten "fiesen Fallen", obwohl ich mir gar nicht vorstellen > kann, wie CONFIG -abgesehen von den gewollten Einstellungen- auf den > Programmablauf wirkt. Ich finde Fehler/Probleme immer wesentlich schneller indem ich mit dem Debugger nachschaue was eigentlich genau abgeht. Dieter Kohtz schrieb: > Ich stehe nicht unter Zeitdruck. Zeitdruck hin oder her, soviel Geduld habe ich einfach nicht;-)
Dieter Kohtz schrieb: > Der Programmcode müsste eigentlich fehlerfrei sein. Reicht da nicht ein Konjunktiv? ;-) > Ich finde Fehler/Probleme immer wesentlich schneller indem ich mit dem > Debugger nachschaue was eigentlich genau abgeht. Welchen Debugger nimmst du denn wenn du keinen anschließen kannst?
X4U schrieb: > Welchen Debugger nimmst du denn wenn du keinen anschließen kannst? Diesen Fall vermeide ich <edit> WENN MÖGLICH </edit>. Anschließen kann man ihn wohl schon, nur wird dann wohl ein Teil der Funktionalität fehlen. Dieter Kohtz schrieb: > Der 876A hat 256 Bytes, die > ich z.B. im PICKit2-Programmer beliebig beschreiben kann.
:
Bearbeitet durch User
Apollo M. schrieb: > sinn macht: > - das program abzuspecken, um herauszufinden, welcher teil der > funktionalität das problem macht > > - den "auffälligen" programteil weiter vereinfachen, um einzugrenzen wo > es hackt > > - ich würde auch im simulator intensive rumspielen und schauen, ob alles > so läuft wie ich es erwarten würde und auch input stimulies verwenden > > - dein program kann auch ein problem besitzen, das sich bis jetzt nur > nicht gezeigt hat, und jetzt mit einem veränderten pic timing, current > consumption, ... oder was auch immmer zu schlägt. Dieser Empfehlung werde ich folgen. Das kann ein Weilchen dauern. Ich betrachte den thread deshalb als beendet. Nochmals Dank an alle Einsender! dk
Dieter Kohtz schrieb: > ich habe ein in Assembler für den PIC16F873 geschriebenes Programm, Am Anfang meiner beruflichen Kariere habe ich über viele Jahre erfolgreich im Assembler programmiert. Aber es kam auch Zeitpunkt wo ich auf „C“ umgestiegen bin. Den Assembler vermisse ich nicht. Warum tust du dich so etwas wie: memory bank... Verlorene Zeit die du anderswo nutzen könntest.
Bitte 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.