Frage: kann man einen PIC HEX code wieder in eine verständliche Sprache (C ?) bringen und umschreiben? Ich hab hier ein Modul mit vertauschten LCD Pins und wollte die softwaremässig ausdrehen, wenn's geht....
Gast
#3533887
jan bader schrieb: > Frage: kann man einen PIC HEX code wieder in eine verständliche Sprache > (C ?) bringen und umschreiben? wenn du es schaffst aus vielen Hamburgern wieder eine Kuh zu machen dann ja.
@innerand Das sind viele tote Links. Peter II schrieb: > wenn du es schaffst aus vielen Hamburgern wieder eine Kuh zu machen dann > ja. So was Ähnliches dachte ich mir. Bei Arduino kommt das Thema ja gelegentlich auf. Der PIC ist übrigens PIC18F84J90 - aber wenn's nicht geht dann ist's natürlich egal. Ich denke mal die Frage ist dann wohl beantwortet, leider.
jan bader schrieb: > @innerand > Das sind viele tote Links. > Tja, dann geben S' halt selbst mal PIC disassembler bei Google ein.
Sofern du Assembler als ausreichend verständlich erachtest, http://www.break-ic.com/Disassembler_software_mcu_reverse_engineer.htm
Gast
#3533959
jan bader schrieb: > kann man einen PIC HEX code wieder in eine verständliche Sprache > (C ?) bringen und umschreiben? Wenn du längere Zeit nix anderes zu tun hast... Was ev. noch im tragbaren Rahmen ist: du disassemblierst und suchst nach Ausgabebefehlen für das betroffene Port (geht auch in HEX). Wenn du Glück hast, sind das wenige, idealerweise nur einer, und da flickst du manuelle Patches ein nach dem Muster Jump - Bits vertauschen - Output - Jump Back. Gruss Reinhard
Gast
#3534878
jan bader schrieb: > Frage: kann man einen PIC HEX code wieder in eine verständliche Sprache > (C ?) bringen und umschreiben? Du hältst C für eine verständliche Sprache? Aber mal im Ernst: Schreib dir einen Reassembler, es sind ja nur wenige einfach zu verstehende Maschinenbefehle, und reassembliere dir das Programm. Dann kannst du damit machen was du willst. Die bessere Alternative wäre, die hardware in Ordnung zubringen. W.S.
Hier ein Disassembler: http://www.hagi-online.org/picmicro/picdisasm.html Ich habe ihn getestet, funktioniert ganz gut, ersetzt auch die Adressen der SFR durch die Namen und für die GPR erstell er dir Labels. Wenn er deinen PIC unterstützt, bist du mit dem gut beraten. Wenn du ASM als unverständliche Sprache siehst, wird dir nur das übrig bleiben: W.S. schrieb: > Die bessere Alternative wäre, die hardware in Ordnung zubringen.
Peter II schrieb: > wenn du es schaffst aus vielen Hamburgern wieder eine Kuh zu machen dann > ja. Das hat mich neugierig gemacht, ich hab's jetzt mal versucht. Allerdings kamen 2 Fohlen dabei raus. Seltsam, hat mir aber Mut gemacht mit dem PIC weiterzumachen. Ich hab also den PIC18F84J90 auf dem Modul. Da ist ein 5-Pin Header, ich komme also an die Programmierung ran. Ok. In der Zwischenzeit hab ich den Sourcecode! C finde ich nun nicht so schwer (kann etwas PHP). Was brauch in denn jetzt noch? Stimmt die Liste? MPLab (kostenlos) C Compiler (60 Tage kostenlos) Pickit 2 http://www.ebay.com/itm/330401309282 Pickit 3 http://www.ebay.de/itm/271407931474 Reicht der PICKit2? Den hab ich billig an der Hand... Fehlt sonst noch etwas?
jan bader schrieb: > MPLab (kostenlos) > C Compiler (60 Tage kostenlos) Der XC8 Compiler ist, wenn du auf Teile der Optimierung verzichten kannst, kostenlos, auch für kommerzielle Projekte. > Reicht der PICKit2? Den hab ich billig an der Hand... Wenn du wir hast, dich weiter mit PICs zu beschäftigen würde ich das Pk3 empfehlen, denn viele neue PICs erden vom Pk2 nicht mehr unterstützt. Für den PIC18F84J90 reicht das Pk2 aus.
Gast
#3565185
Im Grunde genommen gibt es keinen PIC-HEX Code. Der Hex-Code hat ein ganz bestimmtes, adress- und typbezogenes Format. Darüber hinaus, wird/wurde er für die Familie Intel, Atmel, PIC und andere verwendet. Hat aber nur indirekt etwas mit dem Zielprozessor zutun.
Danke! Kann der PICKit 3 noch was zusätzlich? Eigentlich plane ich nicht da gross weiterzumachen. Egal, hab den 3er gekauft für knapp EUR 15..... 2er ist nur minimal billiger. http://item.taobao.com/item.htm?id=35751694401
Den Hex-Code zurück zu Assembler zu verwandeln sollte nicht schwer sein. Wenns nicht zu viel ist gehts sogar von Hand im Editor. Assembler der Zielplattform sollte für den Entwickler (auch wenn er C nutzt) keine Hürde sein. Schwieriger wirds dann, den Code an die richtigen Adressen zu zu "setzen", um zB ISRs zu identifizieren.
Der PICKit 3 ist angekommen! Erst nochmal eine Frage zum allgemeinen Verständnis: Was sind das denn alles für Dateien im Sourcecode? Ich hab Textdateien: 18f84j90.lkr *.mcp *.map *.tagsrc *.mptags *.mcs *.o (in C) *.h (in C) *.c (in C) Dann hab ich nicht lesbar: *.o (schon kompiliert?) *.mcw *.cof Und einmal: *.hex Ich wollte 4 IC Pins tauschen. Wo finde ich diese denn? Sind die in einer der C Dateien?
In *.c und/oder *.h Alllerdings müssen nicht nur die Portzugriffe via PORTx und LATx Register geändert werden, sondern auch die Datenrichtung in den entsprechenden TRISx Registern sowie die Umschaltung Digital/Analog im entsprechenden ANSEL, ANSELH (oder wie diese beim 18F84J90 heissen)!
Chris B. schrieb: > In *.c und/oder *.h > Alllerdings müssen nicht nur die Portzugriffe via PORTx und LATx > Register geändert werden, sondern auch die Datenrichtung in den > entsprechenden TRISx Registern sowie die Umschaltung Digital/Analog im > entsprechenden ANSEL, ANSELH (oder wie diese beim 18F84J90 heissen)! Ich denke die es müssen nur die 4 Pins ausgedreht werden. Wenn ich das auf dem PCB mache dann geht es. Es ist nur kein Platz dort. Gibt es jemanden hier der mir die 4 Pins im Sourcecode ausdrehen kann? Ich spende auch eine Currywurst! Wenn jemand es versuchen möchte dann bitte per Message melden! http://www.mikrocontroller.net/user/show/fernostler
Zeige mal den Sourcecode. Abhängig davon was die PINs machen, könnte es gar nicht möglich sein. Wenn z.B. SPI, I2C, CCP,... verwendet wird.
jan bader schrieb: > Verständnis: Was sind das denn alles für Dateien im Sourcecode? > > Ich hab Textdateien: > 1x 18f84j90.lkr > 1x *.mcp > 1x *.map > 1x *.tagsrc > 1x *.mptags > 1x *.mcs > > 4x *.o (in C) > 6x *.h (in C) > 4x *.c (in C) > > 1x *.mcw > 1x *.cof > 1x *.hex So, ich versuche es nun mal selber und brauch dazu ein paar Tipps. Hab noch nie mit PIC was gemacht. Kenne Arduino, aber das ist doch ganz anders. Installiert ist jetzt: MPLAB C IDE MPLAB XC8 Compiler Programmer ist PICKit 3, aber soweit sind wir ja noch nicht. Die Source die ich zur Hand hat 23 Dateien, wie oben. Wie geht es nun weiter? Ich mach in MPLABX eine neues Projekt mit meinem PIC18F... auf. In 'Header' lege ich dann alle *.h Dateien, und in 'Source' alle *.c Dateien. Was passiert nun mit den anderen Dateien?
jan bader schrieb: > 1x *.mcp Das lässt daraif schließen, dass du ein fertiges MPLAB IDE (ohne X) hast. Wenn du es mit MPLAB öffnest, kannst du unter "Project"-->"Select Language Toolsuite..." herausfinden, welcher Compiler benutzt wurde.
Max H. schrieb: > welcher Compiler benutzt wurde. Da ich jetzt den Source Code hab muss ich an den alten HEX ja gar nicht ran, oder?
jan bader schrieb: > Da ich jetzt den Source Code hab muss ich an den alten HEX ja gar nicht > ran, oder? Nein, aber es gibt ein paar feine unterschieden zwischen den C-Compilern für PIC18. Wenn deine *.c und *.h z.B. für den C18 geschrieben wurden, könnte es sein, dass sie sich mit einem anderen Compiler nicht Kompilieren lassen.
Gast
#3622003
Max H. schrieb: > Wenn deine *.c und *.h z.B. für den C18 geschrieben wurden, > könnte es sein, dass sie sich mit einem anderen Compiler nicht > Kompilieren lassen. C ist schließlich eine standardisierte Programmiersprache. Da kommt soetwas schon mal vor, weil C einem fast beliebige Freiheit gibt, nicht portablen Code zu schreiben. Die Sprache stammt schließlich vom Anfang der 70er Jahre des vorigen Jahrhunderts.
Bastler schrieb: > Max H. schrieb: >> Wenn deine *.c und *.h z.B. für den C18 geschrieben wurden, >> könnte es sein, dass sie sich mit einem anderen Compiler nicht >> Kompilieren lassen. > > C ist schließlich eine standardisierte Programmiersprache. > > Da kommt soetwas schon mal vor, weil C einem fast beliebige Freiheit > gibt, nicht portablen Code zu schreiben. Die Sprache stammt schließlich > vom Anfang der 70er Jahre des vorigen Jahrhunderts. Das hat damit nichts zu tun. Tatsache ist aber, dass in C einige Dinge nicht standardisiert sind, um den Compilerbauern die Freiheit zu lassen, die Fähigkeiten ihrer Plattform möglichst gut auszunutzen. Ergänzend kommt noch dazu, dass es auf µC-Ebene Aufgabenstellungen gibt, die sich nur ganz schlecht standardisieren lassen und die man auch nicht standardisieren möchte. Sie wurden nie standardisiert, so dass die Compilerhersteller da ihr eigenes Süppchen kochten. Natürlich jeder für sich ein anderes. Hier ist man dann eben das erste mal in einer Welt, die nicht nur aus PCs, iPhones und Android Geräten besteht und die in ihrer jeweiligen Familie im Grunde im Aufbau alle gleich sind. Als C entstand und in den Jahren danach, war die Mainstream-Computer-Typenvielfalt noch wesentlich bunter als heute. > Die Sprache stammt schließlich vom Anfang der 70er Jahre des > vorigen Jahrhunderts. Das Ur-C aus dieser Zeit, hat mit dem heutigen C nur noch sehr wenig zu tun. Wenn überhaupt, dann könnte man höchtens sagen, dass das was heute unter C verstanden wird, seinen Grundstock in der Version von 1989 hat.
Max H. schrieb: > jan bader schrieb: >> 1x *.mcp > Das lässt daraif schließen, dass du ein fertiges MPLAB IDE (ohne X) > hast. > Wenn du es mit MPLAB öffnest, kannst du unter "Project"-->"Select > Language Toolsuite..." herausfinden, welcher Compiler benutzt wurde. Super Tipp! Danke! Mit *.mcp wurde scheinbar alles installiert. Morgen gehe ich dann mal an den Code ran.
XC8/C18: So schnell fällt mit auf, dass gewisse #pragma und inline ASM anders sind. Wenn man sich das Leben nicht unnötig schwer machen will, findet man heraus, welchen Compiler verwendet wurde und verwendet diesen.
Max H. schrieb: > XC8/C18: So schnell fällt mit auf, dass gewisse #pragma und inline ASM > anders sind. Wenn man sich das Leben nicht unnötig schwer machen will, > findet man heraus, welchen Compiler verwendet wurde und verwendet > diesen. Im *.mcp steht: dir_inc=D:\Microchip\c18_v3_30\c18\h;C:\Programme\c18\h dir_lib=D:\Microchip\c18_v3_30\c18\lib;C:\Programme\c18\lib Sieht nach C18 aus, oder?
jan bader schrieb: > Sieht nach C18 aus, oder? Sieht so aus. Mit sicherheit kann ich dir nicht dagen, dass es auch so ist. Max H. schrieb: > enn du es mit MPLAB öffnest, kannst du unter "Project"-->"Select > Language Toolsuite..." herausfinden, welcher Compiler benutzt wurde.
Gast
#3622142
Was macht denn der Code? Was macht er an den Pins, die du wo anders haben möchtest bzw. was hängt da dran? Nur Schalter/LEDs oder was anderes?
Robert schrieb: > Was macht denn der Code? Was macht er an den Pins, > die du wo anders haben möchtest bzw. was hängt da dran? > Nur Schalter/LEDs oder was anderes? COM0 bis COM3 sind verdreht. Das sind am PIC Pins 74-77 C18 ? Ich seh hier C16 - oder mix ich da was durcheinander? https://www.microchip.com/pagehandler/en-us/family/mplabx/ OK, hab da was gefunden..... http://www.microchip.com/Microchip.WWW.SecureSoftwareList/secsoftwaredownload.aspx?device=en010014&lang=en&ReturnURL=http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en010014# > "Project"-->"Select > Language Toolsuite..." herausfinden, welcher Compiler benutzt wurde. Das sieht bei MPLAB® X IDE v2.05 anders aus....
Angehängte Dateien:
-
Screenshot_2014-04-18_22.22.48.png
(190 KB)
jan bader schrieb: > C18 ? Ich seh hier C16 - oder mix ich da was durcheinander? C18 ist der "alte" C-Compiler für PIC18. Er wurde abgelöst vom XC8 für alle 8bit PIC. XC16 ist der C-Compiler für 16bit PICs (PIC24, dsPIC30 und dsPIC33) > Screenshot_2014-04-18_22.22.48.png "None found" heißt, du musst ihn noch runterladen. Als erstes würde ich dann Testen, ob sich der Code mit dem C18 Compilieren lässt.
Der Screenshot sollte gehen. Ich hab nun C18_V3.47 als 'Evaluation' installiert. Kann ich eigentlich den HEX aus dem PIC wieder auslesen? Mit dem MPLAB IPE hab ich zwar ein 'Read' - aber dann kommt nur ein 'fertiggelesen', aber nicht was gelesen wurde.
Angehängte Dateien:
-
mplab_ipe.jpg
(170 KB)
Eine Frage hinterher: Ich kann den HEX nicht generieren wegen Fehler. Es ist möglich das 'string.h' fehlt. Im *.mcp steht ja: file_010=D:\Microchip\c18_v3_30\c18\h\string.h Ist das nun ein Teil vom C18 Compiler, oder gehört 'string.h' zur Source? In dem Fall ist dann hier erstmal Schluss weil ich die Datei nicht hab.
string.h kommt beim installieren schon mit. Einfach mal mit dem Explorer im Installationsverzeichnis suchen.
Gast
#3622900
Schon mal geschaut, was in dem Verzeichnis D:\Microchip\c18_v3_30\c18\h so alles drin ist? Gibt es dort ein string.h? Gibt es irgendwo im Microchip-Verzeichnis ein string.h?
String.h ist ein Teil des C18 Compilers. Du musst den Pfad aktualisieren, da du vermutlich eine neuere Version des C18 Compilers verwendest und somit in den Projekteinstellungen erst noch den Pfad auf den C18 Compiler setzen musst. Ich selbst habe noch nichts mit der neuen X IDE gemacht. Da du auch nicht den XC18 Compiler verwendest, sondern den älteren C18, der noch zusammen mit der Mplab IDE (ohne X) entwickelt wurde, und es auch scheint, als ob das Projekt mit der IDE ohne X erstellt wurde, würde ich dir einfach raten die X IDE zu deinstallieren, und einfach nur Mplab IDE http://www.microchip.com/pagehandler/en-us/devtools/dev-tools-parts.html bspw. Version 8.92 zu installieren: http://ww1.microchip.com/downloads/en/DeviceDoc/MPLAB_IDE_8_92.zip Mit dieser kannst du dann das gesamte Projekt Öffnen, wirst aber auch den Pfad zu dem Compiler aktualisieren müssen, da du ihn eben an einen anderen Ort installiert hast, als der Urheber des Projekts.
Danke, ich hab's gefunden! Ich bin am testen. Kann den PIC löschen und die alten Daten wieder aufspielen. Ich dekne von der Hardwareseite geht alles.
Ich komme da nicht weiter. Ich vermute die Änderung muss im p18f84j90.h gemacht werden. Reine COM0 - COM3 hab ich keine, hab aber RE3 - RE6. Wenn ich die ausdrehe passiert nichts wirklich brauchbares. Das simple 4 Pins ausdrehen ist doch sehr viel komplexer als gedacht.
Im File p18f84j90.h machst du besser gar nichts, da das nichts direkt mit dem Quellcode zu tun hat. Insgesamt habe ich aber wenig Hoffnung, dass du da etwas per Software verändern kannst, da der verwendete PIC das Display über ein internes Hardware-Modul anspricht, wodruch das Display unabhängig von der Software angesteuert werden kann. (d.h. auch im Sleep Mode etwas angezeigt wird). Schau dir mal das Datenblatt an: http://ww1.microchip.com/downloads/en/DeviceDoc/39770c.pdf Auf Seite 25 (und S. 127) ist die Pinbelegung des PIC18f84J90. Wie du siehst ist die Belegung von COM0 bis COM3 fix, ebenso wie die Segment-Pins. Ab S.163 wird die Konfiguration des LCD Moduls beschrieben, welche durch setzen der jeweiligen Bits in den Registern erfolgt. Im Register LCDCON kannst du bspw. du das Modul mit Bit 7 (genannt: LCDEN) einschalten, Bit 6 (SLPEN) im Sleep mode eingeschaltet lassen und mit Bit 0 und 1 (LMUX) die Anzahl der COM Leitungen/Displaygröße festlegen. Jedoch kannst du die COM Leitungen nicht vertauschen. Auch in den anderen Registern die das LCD Module konfigurieren, bspw. LCDPS, LCDSE0, LCDSE1, ... kannst du die COM Leitungen nicht vertauschen. Diese sind durch das in der PIC Hardware integrierte LCD Modul festgelegt. Auf Seite 167 siehst du die Register LCDDATAx in die du die Daten, die das im PIC integrierte LCD Modul an das LCD senden soll, hinterlegen kannst. Table 16-2 zeigt dir dabei wie der Inhalt strukturiert werden muss. D.h. je nachdem wie der vor dir liegende Sourcecode aufgebaut ist und die LCD Ausgabe realisiert ist, kannst du vielleicht die Daten in einer anderen Reihenfolge/anders struktuiert in die Register schreiben um dadurch Rücksicht auf die geänderte COM Belegung zu nehmen. D.h. in LCDDATA0 schreibst du den Inhalt von LCDDATA6, LCDDATA1 kommt der Inhalt von LCDDATA7, ... Also einfach um 6 Register versetzt schreiben ggf. so wie bei dir die COM Leitungen eben sind.
Ich habe mit dem "LIQUID CRYSTAL DISPLAY (LCD) DRIVER MODULE" noch nie gearbeitet. Bei einem Blick ins Datenblatt habe ich festgestellt, dass es möglich sein müsste die COM<0:3> zu vertauschen, wenn man die "LCDDATA0x" Register im gesamten Programm vertauscht. Siehe Datenblatt TABLE 16-2 (S. 167)/Anhang: LCDDATA0 <--> LCDDATA18, LCDDATA6 <--> LCDDATA12, LCDDATA1 <--> LCDDATA19, LCDDATA7 <--> LCDDATA13, ... jan bader schrieb: > Das simple 4 Pins ausdrehen ist doch sehr viel komplexer als gedacht. Weil es nicht irgendwelche IOs sind, sondern die Pins eines Hardware Moduls...
Angehängte Dateien:
-
COM.png
(45 KB)
Max & Frank - Danke! Ich teste es mal ausgiebig aus. Ein erster Test brachte zumindest eine Änderung. Mal schauen wie weit ich komme. Ich bereite mich auch langsam auf Plan B vor - es auf der Leiterplatte auszukreuzen, da geht es auf jeden Fall.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.