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.
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
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:> 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.
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.
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
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.
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.
