Forum: Mikrocontroller und Digitale Elektronik Übertragen Programm von PIC16F873 nach PIC16F876A


von Dieter Kohtz (Gast)


Lesenswert?

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

von Dieter W. (dds5)


Lesenswert?

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.

von Rollkugelfüller (Gast)


Lesenswert?

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.

von Rollkugelfüller (Gast)


Lesenswert?

P.S. Ein kurzer Blick in die PIC-Datenbank:

Der 876A hat 2 Komparatoren. Der 873 nicht.

von Apollo M. (Firma: @home) (majortom)


Lesenswert?

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
von Dieter Kohtz (Gast)


Lesenswert?

Hallo, Rollo,

weder ADC noch Comparatoren sind aktiviert. Takt: 4 MHz, nix Besonderes.

Gruß, Dieter

von Dieter Kohtz (Gast)


Lesenswert?

@ majortom

Danke für die Unterlagen. Nach meinen bisherigen Erfahrungen fand ich - 
jedenfalls beim 873 keine Unterschiede zum A-Typ.

dk

von c-hater (Gast)


Lesenswert?

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!

von Dieter W. (dds5)


Lesenswert?

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.

von Toxic (Gast)


Angehängte Dateien:

Lesenswert?

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

von Dieter Kohtz (Gast)


Lesenswert?

@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

von Dieter W. (dds5)


Lesenswert?

Einige config-bits unterscheiden sich, besonders bei der memory 
protection. Mit entsprechendem Programm kann das für Ärger sorgen.

von John (Gast)


Lesenswert?

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.

von X4U (Gast)


Lesenswert?

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

von Dieter Kohtz (Gast)


Lesenswert?

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

von Toxic (Gast)


Lesenswert?

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

von X4U (Gast)


Lesenswert?

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

von X4U (Gast)


Lesenswert?

bbDie Erratas würde ich auch vergleichen.

von John (Gast)


Angehängte Dateien:

Lesenswert?

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.

von Dieter Kohtz (Gast)


Lesenswert?

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

von Kastanie (Gast)


Lesenswert?

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.

von John (Gast)


Lesenswert?

Verwendest du das interne EEPROM?

von Dieter Kohtz (Gast)


Lesenswert?

John schrieb:
> Verwendest du das interne EEPROM?

@ John
Ja, den ersten Teil, bis Adr. 30h

Gibt es da auch Komplikationen?

dk

von John (Gast)


Lesenswert?

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?

von X4U (Gast)


Lesenswert?

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?

von Dieter Kohtz (Gast)


Lesenswert?

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

von Thomas E. (picalic)


Lesenswert?

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!

von Apollo M. (Firma: @home) (majortom)


Lesenswert?

...

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

von K. J. (Gast)


Lesenswert?

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.

von Volker S. (vloki)


Lesenswert?

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.
von Teo D. (teoderix)


Lesenswert?

Ich hätte schon längst mal alle Configs raus geschmissen und das mittels 
"Pic Memorie Views/Configurations Bits" eingestellt und neu generieren 
lassen.

von Dieter Kohtz (Gast)


Lesenswert?

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

von Volker S. (vloki)


Lesenswert?

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?

von John (Gast)


Angehängte Dateien:

Lesenswert?

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.

von Dieter Kohtz (Gast)


Lesenswert?

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

von Dieter Kohtz (Gast)


Lesenswert?

John schrieb:
> Das ist bestimmt ein anderer Dieter Kohtz.

Nein, der bin ich noch immer. Freut mich, dass Du meine Bücher hast.

dk

von John (Gast)


Lesenswert?

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.

von Apollo M. (Firma: @home) (majortom)


Lesenswert?

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

von Volker S. (vloki)


Lesenswert?

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;-)

von X4U (Gast)


Lesenswert?

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?

von Volker S. (vloki)


Lesenswert?

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
von Dieter Kohtz (Gast)


Lesenswert?

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

von skorpionx (Gast)


Lesenswert?

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
Noch kein Account? Hier anmelden.