Hallo, wir haben ca. 20 Jahre alte Geräte, in denen ein PIC16C711-20/P enthalten ist. Die Entwicklungsumgebung (Emulator) existiert schon lange nicht mehr. Die Programme wurden damals mit Assembler geschrieben. Der Einkauf hat nun den Vorschlag bekommen, den PIC16F716-I/P als preisliche Alternative zu verwenden. Ich habe seit damals nie mehr mit PIC´s gearbeitet. Ich befürchte so einfach ist es nicht, man wird das alte HEX-File nicht einfach in den Ersatztyp brennen können. Oder sind die neuem Prozessoren Code-kompatibel zu den alten? Gruß Martin
Warum schaust du nicht is Dabla??? Trotzdem hier meine Prognose (ich schau sicher nicht, für dich ins Dabla!), das wir funzen.
Wenn das Gerät noch läuft und die Bauteile noch verfügbar sind, macht es eigentlich nur ein einem einzigen Fall Sinn, über einen billigeren Erstz zu diskutieren: Ihr verkauft von den Dinger mehr als 1000 Stück pro Jahr. Beide PIC sind zB. bei Farnell noch zu kaufen: PIC16C711-20/P: 2,14 @ 100Stk PIC16F716-I/P: 0,866 @ 100Stk Problematisch finde bei den beiden hier, dass Sie noch unterschiedliche Technolohie sind EEPROM / FLASH Den C711 wirdst Du nur mit einem echten Programmer (von damals oder evtl Galep) programmiert bekommen, den F716 dagegen per ISP.
Jürgen G. schrieb: > Ihr verkauft von den Dinger mehr als 1000 Stück pro Jahr. wir verkaufen ca. 3.000 bis 5.000 Stück pro Jahr
Martin M. schrieb: > Oder sind > die neuem Prozessoren Code-kompatibel zu den alten? Code kompatibel könnten sie sein, aber es gibt wesentlich mehr Special Function Register, und die auch auf Adressen, die beim 711 RAM sind. Ohne das Programm anzupassen geht es nicht. MfG Klaus
Geht eigentlich problemlos, Timer1 OSC wurde verändert, BOR-PWRT entkoppelt beim C->F . Wenn ein paar Byte im code frei sind, geht die Migration des 711 auf 716 problemlos auch ohne Sourcen, PWM ist dazugekommen, und ADC Register haben die Adressen geändert, sofern nicht indirect auf ADC zugegriffen wird, was eher unüblich ist.
Schon mal geprüft, ob nicht auch ein PIC18F geht? Notfalls mit adapterleiterplatte. Mit MPLAB und neuem Programmet zeitgemäßer.
Hi, Martin M. schrieb: > Ich befürchte so einfach ist es nicht, man wird das > alte HEX-File nicht einfach in den Ersatztyp brennen können. Oder sind > die neuem Prozessoren Code-kompatibel zu den alten? Das HEX file einfach so wie es ist weiterzuverwenden wird mit großer Wahrscheinlichkeit nicht gehen. Das Problem ist hier die Lage der SFR. HAt Klaus ja schon weiter oben geschrieben. Das Speichermodell des 16F716 ist eine weiterführung des 16C715. Neben den zusätzlichen SFR ist hier vor allem die unterschiedliche Lage der ADCON register sowie reservierte Adressen die beim 711 noch GPR waren das Problem. Es liegt aber letztendlich am derzeit vorhandenem Programm selbst ob es evtl. gehen würde. Sind die Register unterhalb 20h nicht verwendet und auch der AD Wandler ist nicht benötigt könnte es schon reichen das Abschalten der AD Wandler mit der richtigen Adresse hineinzupatchen. Aber wenn eine der beiden Bedingungen nicht zutrifft wird es schon sehr schwierig... (Das "Hineinpatchen" des "ADCON = 0" direkt im Binärfile habe ich z.b. bei der Portierung eines 16C84 Programmen auf 16F628 gemacht wo ich keinen Zugriff auf den Quellcode hatte. - hätte natürlich auch die 16F84 nachkaufen können. Aber es war Samstag NAchmittag,ich war ungeduldig und von den 628 waren genug vorhanden...) Eine Möglichkeit wäre sonst vielleicht noch das Programm durch einen Disassembler zu jagen, die Adressen zu ändern und ein neues Hex File zu erzeugen. Ist aber auch nicht ganz so trivial. Liegt wieder sehr stark am Programm ob das viel oder wenig Aufwand ist. Vor allem ist interessant ob im ROM Datentabellen liegen oder nur Programmcode. Aber grundsätzlich sollte klar sein das bei einem Controllerwechsel alle Versuche auf basis des alten Hex Files sich das "neue" Programmierfile zusammenzubasteln nur ein allerletzter Ausweg sein sollten. Martin M. schrieb: > Die Entwicklungsumgebung (Emulator) existiert schon lange > nicht mehr. Die Programme wurden damals mit Assembler geschrieben. Du schreibst das die Hardware nicht mehr vorhanden ist... Wie schaut es denn mit den Quellcodes (*.ASM) selber aus? Das sind ja ganz triviale Textdateien... Sind die noch Auffindbar? Wenn ja, dann seit ihr richtig gut raus. Wenn der ursprüngliche Programmierer auch nur halbwegs ordentlich gearbeitet hat, dann sollte sich eine Modifikation auf Basis der Quelldateien ganz einfach bewerkstelligen lassen. Das reine editieren des Codes dürfte nur wenige Minuten in Anspruch nehmen. Mit dem gründlichen Studium und vergleich der beiden Datenblätter sowie einer grundsätzlichen Kontrolle lass es für jemanden der diese beiden Controller nicht in den letzten Tagen noch bearbeitet hat einen Arbeitstag sein. (Die Produkttests am fertigen Gerät kommen naürlich noch dazu...) An HArdware braucht es nicht viel. Ein Pickit3 für ~20-40 Euro reicht aus. (Was ich nicht aus dem Kopf weiß ist wie es mit dem Debugen aussieht. Also ob der F716 Debughardware on Board hat, man einen Debug Header (~30 Euro) benötigt oder ar keine günstige Möglichkeit gibt. Allerdings denke ich das bei einer reinen Anpassung der Adresse im funktionierenden Quellcode es auch sehr gut ohne Debugmöglichkeit geht. Daher wäre es jetzt das erste was ich tun würde die Verfügbarkeit der ASM Quellen abzuklären. Gruß Carsten
Daniel E. schrieb: > Schon mal geprüft, ob nicht auch ein PIC18F geht? Notfalls mit > adapterleiterplatte. Mit MPLAB und neuem Programmet zeitgemäßer. Um Zeitgemäß zu sein braucht es nicht unbedingt einen PIC18. Auch bei den PIC16 hat Microchip in letzter Zeit einige wirklich nette Varianten auf dem MArkt gebracht. Teilweise deutlich leistungsfähiger als ältere PIC18. Nach dem auch beide Varianten vom gleichen Compiler unterstützt werden und die meisten neuen PIC16 dassselbe Schema beim Pinning haben wie die PIC18 sind die Grenzen zwischen dne beiden Familien ziemlich verwischt. Allerdings wäre ein Umstieg auf PIC18 deutlich aufwendiger als der von 16C711 auf 16F716. Immerhin gibt es ja schon ein laufendes Programm. Und ich denke dem TO geht es darum den Aufwand beim Umstieg so klein wie möglich zu halten! Zudem geht es ja um eine Kommerzielle Anwendung. Und da geht es einzig um die Frage ob der µC für die Aufgabe geeignet ist, ob die Verfügbarkeit gesichert ist und vor allem was der Kostet. Solche Dinge wie "Zeitgemäß" sind da absolute Nebensächlichkeiten. Insbesondere bei bestehenden Produktlinien. Wenn überhaupt, dann spielt es maximal bei der Neuentwicklung von Produkten eine Rolle. Aber auch nur soweit es Einfluss auf die Verfügbarkeit, den Preis oder den Entwicklungsaufwand hat. Gruß Carsten
Quellcode ist noch vorhanden. Habe das Ganze auch mal mit MPLAB compiliert. Auch mit dem anderen Prozessortyp kommt das identische HEX-File am Ende raus. Scheint also diesbezüglich kein Problem zu sein. Nun müßte ich mal nach einem neuen preiswerten PIC-Programmer schauen, der einen DIP-Schnellspannsockel hat. Der von Microchip vorgeschlagene DV007004 (Programmer) und AC164301 (Adapter für DIP-Sockel) ist ja ziemlich teuer...
Habe mal etwas gegoogelt: taugt das Microchip Technology Entwicklungsboard AC162049-2 was? http://www.voelkner.de/products/532297/Microchip-Technology-Entwicklungsboard-AC162049-2.html?ref=43&products_model=D76421&gclid=CNjV1NGp8s0CFcrjGwodxmYA_A Kostet ca. 104 €, also um Faktor 10 weniger als der DV007004 (Programmer) + AC164301 (Adapter für DIP-Sockel). Klar, dafür hat es auch kein Gehäuse dran.
:
Bearbeitet durch User
Kauf Dir doch ein Pickit 3 und den passenden Sokel dazu Dann biste um die 30 Euro
Bei microchip Gibt es den Programmier service. Könnte sich für euch eventuell lohnen. Als production Programmer TPG100002 .
:
Bearbeitet durch User
Martin M. schrieb: > Quellcode ist noch vorhanden. Habe das Ganze auch mal mit MPLAB > compiliert. Auch mit dem anderen Prozessortyp kommt das identische > HEX-File am Ende raus. Scheint also diesbezüglich kein Problem zu sein. HHHMM, Wirklich exakt dasselbe HEX file? Würde jetzt zwar nicht viel Geld darauf verwetten das auf jeden Fall ein Unterschied da sein müsste, aber etwas Merkwürdig finde ich das schon. Da kommt mir ein Verdacht... HAst du GENAU DASSELBE ASM File genommen und einfach nur in MPLAB unter Devices den Controller umgestellt? Dann ist das natürlich kein Wunder das die HEX file gleich sind. Oder hast du das ASM File vorher doch schon an den neuen Controller angepasst? WEnn ersteres: ASM, gerade wenne s für die Verwendung mit den älteren Umgebungen wie MPLAB LAANGE vor 8.xx, geschweige den MLABX geschrieben wurde, ist nicht C. Da nimmt der Assembler keine Automatischen Anpassungen am Code vor. Mit der Einstellung des Devices legt man NUR die Einstellungen für den Brennvorgang fest. (Erwartete ID, Spannung und ggf. Algorithmus) Aber es hat normalerweise zumindest bei älteren Quellcode keinen Einfluss auf die tatsächliche Zielhardware! Gerade in den frühen Jahren war es zwingend notwendig im Quellcode selbst den Controllertyp und das jeweilige Prozessorspezifische Include im Code selbst einzutragen. Am Anfang des Programms steht dann soetwas wie: list p=16f711 include "p16f711.inc" Und DIESE BEIDEN Einträge bestimmen in erster Linie ob das Hex File dann auf dem Zielcontroller funktioniert oder nicht. Heute ist es IMHO auch bei PIC ASM nicht mehr zwingend notwendig das Anzugeben. Wenn die Einträge fehlen sucht die IDE m.W. wie bei C auch selbst die richtigen Includes für den in der IDE eingestellten Controller heraus. Wenn diese Einträge aber vorhanden sind, dann werden diese auf jeden Fall auch beachtet! (Ganz sicher bin ich mir wegen der Automatik nicht, da ich aus Gewohnheit in den gelegentlichen Fällen in denen ich noch ganz neuen Code in ASM schreibe auch weiterhin wie ehedem im Quellcode selbst die Angaben machen) Falls sich diese Zeilen also bei dir im Quellcode finden und du es nicht schon gemacht hast musst du diese auf jeden Fall anpassen. Ausserdem musst du bei ASM ZWINGEND auch im Quellcode selbst überprüfen ob nicht evtl. Register benutzt werden die beim neuen Typ entwerde als SFR vorgesehen sind oder gar nicht mehr vorhanden sind da im Bereich mitten zwischen den SFR gelegen. Einen Eintrag wie : MeineVariable equ 0x1f ... ... ... decfsz MeineVariable, 1 Der auf dem 711 absolut zulässig ist wird auf dem 716 ebenfalls "gebaut", Spätestens beim DECFSZ aber haut es dir wie bei jedem anderen schreibenden Zugriff auf dieses Register die AD-Wandler Einstellungen auseinander. Einfach weil eben genau an dieser Adresse die ADCON Register liegen. Daher müssen diese Fallstricke Manuell gesucht und entschärft werden. Wenn der ursprüngliche Programmierer aber auch nur halbwegs sauber gearbeitet hat, so dürfte das aber kein Problem sein. Dann hat er -beispielsweise mit "equ"- alle Register schön am Anfag des Quellcodes benannt und verwendet im Programm nur noch die Namen... Dann reicht es aus kur zu schauen ob kritische Adressen verwendet werden und diese dann schnell abzuändern. ISt nicht völlig ohne Arbeit, aber insgesamt ist de rAufwand wenn die Quellcodes vorhanden sind absolut überschaubar. Je nach Programm liegt der Aufwand irgendwo zwischen 5 Minuten und einem Nachmittag. Kritisch wird es allerdings wenn der Ursprüngliche Programmierer im Programm selbst nicht mit Namen/Labels gearbeitet hat, sondern die Adressen direkt verwendet hat. Wenn also z.B. statt "decfsz MeineVariable, 1" ständig "decfsz 0x1f, 1" im Code steht. -> Dann muss man leider zwingend das gesamte Programm Zeile für Zeile von Hand durchforsten. > Nun müßte ich mal nach einem neuen preiswerten PIC-Programmer schauen, > der einen DIP-Schnellspannsockel hat. Der von Microchip vorgeschlagene > DV007004 (Programmer) und AC164301 (Adapter für DIP-Sockel) ist ja > ziemlich teuer... Wenn es nur um die Grundsätzliche Programmierung geht würde ich einfach nur einen PicKit3 und einen "textool" Adapter nehmen. Etwas in dieser Art: http://www.ebay.de/itm/PIC-ICD2-PICKIT-3-2-Programmier-Adapter-PICKIT2-PICKIT3-Universal-Programmer-/252117924313?hash=item3ab36639d9:g:k0MAAOSw5dNWql8T Bei Versand aus DL gerade mal 6 Euro, direkt aus China würde man den sogar für 3 Euro inkl. Versand bekommen... Wenn man es Mechanisch richtig Toll haben will kann man sich den Adaper natürlich auch selber Bauen wie man möchte. Es ist eine rein elektrische Verbindung zum PK3 (PK2, ICD oder was auch immer...) ohne eigene Elektronik. Für Produktionszwecke im tausenderbereich würde ich schon einen sehr hochwertigen Socken auf einer festen Platte montieren. Aber selbst da ist man noch locker unter 50 Euro, auch bei Original "Textool" Oder man schaut ob man einen Universalprogrammer wie einen GALEP IV günstig gebraucht bekommt. die Vierer bekommt man so ab 100 Euro einigermaßen regelmäßig... Entscheident für die Wahl des tatsächlichen Programmierinterfaces wäre für mich allerdings die tatsächlich Menge an zu programmierenden PICs. Für eine Handvoll am Tag und vor allem für gelegentliche Entwicklung reicht ein PK3 locker aus. (Ist im Verlgeich beim Programmieren eher Langsam) Sind es aber mehrere hundert Controller Pro Tag, an mehreren Tagen die Woche und das fast jede Woche im Jahr würde ich definitiv einen deutlich schnelleren Programmieradapter wählen. Da sind die "Production Programmer" von Microchip schon nicht schlecht. Die ICD liegen Geschwindigkeitsmäßig irgendwo in der Mitte. Wie die Galep IV im Vergleich liegen kann ich gerade nicht einmal sicher sagen. Benutze meine beiden (IV &V ) im Pic bereich nur für die alten C typen. Kann bei Interesse aber gerne mal den Geschwindigkeitsvergleich zwischen PK3 <> ICD3 <> GALEP IV <> GALEP V machen. (Wobei ich aber ohne Not den GalepV nur für die PIC Progammierung nicht empfehlen würde, der IV ist solider und erheblich billiger gebraucht zu haben...) Gruß Carsten
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.