Hi, ich habe hier diesen Quellcode aus einem PIC. Kann mir jemand sagen ob es überhaupt ein "brauchbares" Programm ist? Es stammt aus einem PIC16C66-04/SF. Ist mir schon klar, das man natürlich nicht sagen kann ob es lauffähig ist, aber ob überhaupt eine Logik dahintesteckt, also Variablen, Reset Vektor ect...Ich suche eine Wertetabelle mit einer Kurve für eine Temperaturlinearisierung eines PT100 o.ä. darin. Ich habe nicht so den Plan von PICs. Thorsten PS.: nein es ist keine Schulaufgabe oder Studienaufgabe. Es ist eher Gerätenachbau.
...ich habe das übrigens mal durch einen disassembler gejagt, bin mir nur nicht sicher ob ich alles richtig gemacht habe... T.
Hast du auch richtigen Quellcode oder nur das vom Disassembler? Daraus bestimmte Dinge rauszulesen ist teilweise nicht ohne und ich bezweifel, dass sich hier jemand die Nacht über hinsetzt um da durchzublicken... Ich denke da bist du schneller wenn du die Linearisierung selber überlegst statt die da rauszufischen.
Du könntest dir z.B. mit einem C-Compiler für ebendiesen Controllertyp ein Hexfile erzeugen, wo z.B. nur der Mainloop vorhanden ist. Dann in einem Hexeditor die ersten paar Bytes vergleichen. Oder du siehst dir die Speicherbelegung dieses Prozessors an, insbesondere was das setzen des Stackpointers sowie Programcounters angeht (meist ganz am Anfang) und die Sprung-Vektortabelle der Interrupts. mfg mf
Nach Hex2Bin und dann im Hexeditor angesehen hat sich zumindest keiner in der Software "verewigt". Man findet ja immer wieder mal kleine Späße oder zumindest einen eingebetteten Copyright-Hinweis. Ich nehme an, dass das Gerät nach außen nur über Schnittstellen kommuniziert, die keine festen "String"konstanten benötigen. HD44780 Display, Serielle Schnittstelle etc. gehören auch dazu. ( glaskugelpolier anhauch hust wischkratzquietsch ) Schreib doch mal bisschen was über das Gerät, Thorsten. mfg mf PS: Argh, immer dieses Bankswitching...
Muß in C geschrieben worden sein. Nur sehr wenige würden so starten:
1 | CLRF 0x3 |
2 | MOVLW 0x8 |
3 | MOVWF 0xa |
4 | GOTO 0 |
Das setzt PCLATH auf 8, womit das GOTO bei 0x800 landet. Dann wird bei 0x814 erst mal Speicher ab 0x20 gelöscht, und, und, und... Sieht brauchbar aus. Den Rest kannste selber rausfriemeln ;) Viel Spaß ;)
Das Programm ist in C geschrieben, solche Massen von Bank und Page Umschaltungen macht kein ASM Programmierer. Außer einer kurzen Liste von Konstanten (retlw xx) bei 1800h hab ich nix Tabellenähnliches gefunden, und das ist definitv keine Linearisierung.
> Was ist Quellcode? Schön blöd, wenn der dumme Kommentar nach hinten losgeht ^^ > Unter dem Begriff Quelltext, auch Quellcode (engl. source code) oder >unscharf Programmcode genannt
Hi, es ist eine Temperaturregelung mit LED Anzeige. Danke für die Rückmeldungen bis jetzt. Ich gehe mal davon aus das die Umrechnung dann mit Hilfe einer Formel in C implementiert wurde. Es muss irgendwo ein ADC Wert eingelesen und umgerechnet werden... Kein LCD, keine serielle Schnittstelle. Hier schaue ich mich gerade um: LADR_0x0800 MOVLW 0x20 ; b'00100000' d'032' " " LADR_0x0801 MOVWF FSR MOVLW 0x6A ; b'01101010' d'106' "j" CALL LADR_0x0014 ; !!Bank!! 0x0014 - 0x0814 MOVLW 0xA0 ; b'10100000' d'160' MOVWF FSR MOVLW 0xF0 ; b'11110000' d'240' CALL LADR_0x0014 ; !!Bank!! 0x0014 - 0x0814 MOVLW 0x10 ; b'00010000' d'016' MOVWF FSR MOVLW 0x52 ; b'01010010' d'082' "R" BSF STATUS,IRP CALL LADR_0x0014 ; !!Bank!! 0x0014 - 0x0814 CLRF STATUS BCF PCLATH,4 ; !!Bank Program-Page-Select LADR_0x080F BCF PCLATH,3 ; !!Bank Program-Page-Select GOTO LADR_0x01B6 ; !!Bank!! 0x01B6 - 0x09B6 das sieht nach Portregister Einstellungen aus... werde ich mal am Datenblatt nachprüfen. Ich habe das: LADR_0x0814 XORWF FSR,W BTFSS STATUS,Z GOTO LADR_0x0011 ; !!Bank!! 0x0011 - 0x0811 RETLW 0x00 ; b'00000000' d'000' bei 814 stehen... Was mich etwas wundert, dass mitten im Code leerspeicher ist: LADR_0x18CE ADDLW 0xFF ; b'11111111' d'255' ADDLW 0xFF ; b'11111111' d'255' ADDLW 0xFF ; b'11111111' d'255' ADDLW 0xFF ; b'11111111' d'255' ADDLW 0xFF ; b'11111111' d'255' LADR_0x18D3 ADDLW 0xFF ; b'11111111' d'255' ADDLW 0xFF ; b'11111111' d'255' ADDLW 0xFF ; b'11111111' d'255' LADR_0x18D6 ADDLW 0xFF ; b'11111111' d'255' LADR_0x18D7 ADDLW 0xFF ; b'11111111' d'255' LADR_0x18D8 ADDLW 0xFF ; b'11111111' d'255' ADDLW 0xFF ; b'11111111' d'255' ADDLW 0xFF ; b'11111111' d'255' ADDLW 0xFF ; b'11111111' d'255' ADDLW 0xFF ; b'11111111' d'255' ADDLW 0xFF ; b'11111111' d'255' ADDLW 0xFF ; b'11111111' d'255' (hängt sicher mit dem Paging zusammen) und warum der Disassembler dort auch noch Label gesetzt hat... Gruß, Thorsten
@Mini Float
> PS: Argh, immer dieses Bankswitching...
heist heutzutage das Wechseln der Bank so ? ;-)
> und warum der Disassembler dort auch noch Label gesetzt hat...
Die Label wurden gesetzt, weil diese Stellen von anderen Teilen des
Programms angesprungen werden (goto, call). Da aber hier kein
Programmcode steht, dürfte es sich bei den aufrufenden "Programmteilen"
um disassemblierte Daten handeln.
Wie werden Daten (Datenfelder) in C gespeichert?
Gruß
John
Thorsten S. schrieb: > Ich gehe mal davon aus das die Umrechnung dann mit Hilfe einer Formel in > C implementiert wurde. > > Es muss irgendwo ein ADC Wert eingelesen und umgerechnet werden... Kommt auf die Schaltung an. Es gibt Sensoren, die direkt °C ausgeben (I2C, 1-Wire). Peter
Peter Dannegger schrieb: > Kommt auf die Schaltung an. > Es gibt Sensoren, die direkt °C ausgeben (I2C, 1-Wire). Thorsten hat in seinem ersten Beitrag geschrieben, dass es ein PT100 oder etwas ähnliches sei. Er könnte mal einen Link zur Schaltung posten, wenn es irgendwo online ist. Oder ein Foto machen, wenn er das Gerät hat, das er nachbauen will. Gruß John
Hi, es handelt sich um einen PT100 ähnlichen Sensor. Schaltplan habe ich leider noch nicht "disassembliert"... >>dürfte es sich bei den aufrufenden "Programmteilen"<< >>um disassemblierte Daten handeln.<< Dann können Daten als Befehle interpretiert werden? Aber der uc muss das doch auch irgendwie auseinanderhalten, oder liegt es evtl. daran dass ich beim disassemblen etwas falsch gemacht habe. Ich kannte das früher mal so das Festwerte mit retlw + literal gebildet wurden... Gruß, Thorsten
Thorsten S. schrieb: >>>dürfte es sich bei den aufrufenden "Programmteilen"<< >>>um disassemblierte Daten handeln.<< > > Dann können Daten als Befehle interpretiert werden? Beim disassemblieren: Ja > Aber der uc muss das > doch auch irgendwie auseinanderhalten, dem ist das Wurscht. Der holt sich das nächste Byte aus dem Speicher und interpretiert es als Befehl. Immer Aber ein Diassembler tut das nicht. Wenn der Programmcode einen Befehl enthält über ein paar Bytes drüberzuspringen und in diesen paar Bytes hat sich der Programmierer ein paar Daten abgelegt, dann weiß das der Disassembler nicht. Der versucht in die Daten nach wie vor Befehle zu erkennen. > oder liegt es evtl. daran dass > ich beim disassemblen etwas falsch gemacht habe. Ich denke du machst das zu kompliziert. Die Umrechnung von PT100 auf Temperatur wird meistens sowieso mit einer Formel gemacht. Welche das ist, hängt auch von der Beschaltung des PT100 ab. In der Zeit, die du hier mit Disassemblieren vertrödelt hast, hättest du dir schon längst aus dem Datenblatt des PT100, zusammen mit der Hardwarebeschaltung die für dich gültige Formel zusammengestellt und implementiert. Manchmal ist es einfacher, selber eine Lagerung für das Rad zu erfinden als erst lange beim Nachbar zu studieren, wie er das gemacht hat.
Thorsten S. schrieb: > ich habe hier diesen Quellcode aus einem PIC. Kann mir jemand sagen ob > es überhaupt ein "brauchbares" Programm ist? Es stammt aus einem > PIC16C66-04/SF. Der PIC16C66 besitzt keinen A/D-Wandler, was das Einlesen eines PT100 Temperatursensors etwas schwierig gestaltet. Wird ein externer A/D-Wander versendet oder ist es ein anderer Controller? Der im Disassembler-Listing angegebene PIC16F88 scheint es nicht zu sein. Im Code wird mehrfach auf das Register 0x07 zugegriffen, das beim PIC16F88 nicht existiert.
1 | BTFSC SFR_0x07,0 ; !!Warning: SFR_0x07 is Unimplemented |
Um welchen Controller handelt es sich tatsächlich? Noch was zu den Labels: die Befehle GOTO und CALL unterstützen nur 11 von den 13 Adressbits (8k). Die oberen zwei bits müssen manuell gesetzt werden. Der Disassembler wertet nur die 11 niederwertigsten bits aus. Die GOTO- bzw. CALL-Befehle verweisen immer auf Bank0. z.B.: GOTO LADR_0x0359 Die Labels werden aber für alle möglichen Adressen gesetzt. Adresse Bank0/ +0x800/+0x1000/+0x1800 das sind dann: LADR_0x0359 LADR_0x0B59 LADR_0x1359 LADR_0x1B59 Dadurch kann das Disassembler-Listing bis zu vier mal so viel Labels enthalten, als tatsächlich benötigt werden. Gruß John
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.