Forum: Mikrocontroller und Digitale Elektronik PIC16F877 Einschalt-Begrenzung deaktivieren


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Bernd M. (bernte_one)


Lesenswert?

Hallöchen,

für einen Metalldetektor den ich die Tage bauen will, hab ich den 
Hexcode vorliegen. Leider ist das eine Probierversion bei der die Anzahl 
der Einschaltvorgänge registriert wird und nach 200mal Einschalten muss 
man den Controller neu flashen.

Das Projekt ist schon etliche Jahre alt und der Autor sitzt / saß 
irgendwo im mittleren Osten und kann von mir nicht mehr erreicht werden. 
Hab es schon über ein Jahr sporadisch probiert, laut Foren in den ich 
recherchiert habe ist der wohl Hopps gegangen. Gut kommt vor dort unten, 
wer weiß was der noch so gebastlet hat.

So jetzt jetzt mein Anliegen: kann man irgendwie die Einschalbegrenzung 
umgehen? Ich würde sehr ungern alle paar Wochen das ganze Gerät 
aufmachen um den Controler neu zu beschreiben.

Ist es über die MPLab IDE irgendwie möchlich einen Schreibschutz zu 
setzten damit der Einschaltvorgang einfach nicht vermerkt wird?

Es handelt sich um den PIC16F877. Eine andere Möglichkeit kommt mir 
erstmal nicht in den Sinn.

Wäre schön wenn ich das mal zum Abschluss bringen kann, es kommt immer 
mal wieder hoch auf meiner "to do Liste".

Leider hab ich sowas nicht studiert....

Danke vorab

von devzero (Gast)


Lesenswert?

Wer weiss wie das umgesetzt ist, evtl. wird der Zaehler im EEPROM 
gespeichert. Das sollte man im Disassembly finden. Stell das Projekt 
oder wenigstens das HEX File doch mal hier rein.

von Thomas E. (picalic)


Lesenswert?

Die Menge der möglichen Befehlssequenzen, um ins Flash oder EEPROM zu 
schreiben, sind bei diesen Controllern begrenzt. Der entsprechende Code 
sollte sich also relativ leicht im Hex-File lokalisieren lassen. Wenn 
der Programmierer schlau war, hat er aber vielleicht noch irgendwelche 
Sicherungen (Prüfsumme, CRC o.ä.) eingebaut, um ggf. Code-Manipulationen 
zu erkennen. Kann also auch sein, daß man doch etwas mehr analysieren 
muß. Aber mehr als 8K Befehle können es ja nicht sein...

von bernte (Gast)


Lesenswert?

Danke für deine Antwort. Ich werde morgen Mal die hexfiles hochladen 
(eines für 4x20 LCD das andere für 1602 Display) und die Beschaltung 
direkt um den Controller als Ausschnitt ich denke das hilft.

von Carsten S. (dg3ycs)


Lesenswert?

bernte schrieb:
> Danke für deine Antwort. Ich werde morgen Mal die hexfiles hochladen
> (eines für 4x20 LCD das andere für 1602 Display) und die Beschaltung
> direkt um den Controller als Ausschnitt ich denke das hilft.

Was auch helfen kann ist wenn du den Controller einmal frisch 
programmierst und anschließend mehrmals einschaltest um den dann erneut 
auszulesen.
Allerdings beim Auslesen FLASH und EEProminhalt abspeichern!

Der Pic 16F877 hat einen EEPROM als dedizierten Datenspeicher, kann aber 
auch in seinen eigenen Programmspeicher (Flash) schreiben.
Was relativ klar ist, das ist die Tatsache das der PIC irgendwo seinen 
Zählerstand ablegt. Wenn ein einfaches Neubeschreiben reicht kann man 
einen externen Datenspeicher in der Schaltung ausschließen.
Wenn der Zählerstand beim Abklemmen der Batterie erhalten bleibt 
(ausprobiert?) kommt auch der Ram nicht in Frage. Somit bleiben nur 
EEPROM oder FLASH als einzig verbleibende Möglichkeiten übrig.

Zwar würde man in einem solchen Fall, insbesondere bei älteren Typen, 
häufig ändernde Werte im EEPROM ablegen. Da es sich aber laut deiner 
Aussage um eine DemoFirmware handelt würde ich das ablegen im Flash 
dennoch nicht ausschließen wollen.
(EEPROM wg. Abnutzung Flashzellen, bei älteren Typen ist die Zahl der 
GARANTIERTEN Schreibzyklen im Flash vor einem MÖGLICHEN Funktionsverlust 
ja noch nicht so hoch. Bei neueren ist das erheblich besser, da wird oft 
ja schon auf einen "echten" EEPROM verzichtet und der Flash ist explizit 
auch für häufige Schreibvorgänge vorgesehen. -Ganz oder zumindest in 
speziellen Bereichen-)

Ich würde vorschlagen den Pic nach 1x, 10x und 15x Einschalten 
auszulesen und  die Hex Files dann zu Vergleichen.
Also:
Pic Beschreiben, einmal Einschalten, danach Auslesen.

Dann weitere 9 x Ein- und Ausschalten, danach erneut Auslesen
Anschließend nochmals 5x Ein- und Ausschalten um einen weiteren 
Zählerstand zum Vergleich zu haben.

Falls im Programm weitere Einstellungen möglich sind die beim 
Ausschalten erhalten bleiben (dinge wie Lautstärke, Helligkeit der LCD 
Hintergrundbeleuchtung oder was auch immer, kenne die Schaltung nicht) 
KEINESFALLS irgendwelche Änderungen vornehmen. Immer dieselben 
Einstellungen belassen.

Mit dem Auslesen nach dem ersten Power Zyklus stellt man fest ob ggf. 
eine Erstinitialisierung des EEPROM Speichers oder eines Bereiches im 
Flash stattfindet.

Mit dem Auslesen nach 10 und 15 Power Zyklen erhält man dann 
Vergleichswerte um festzustellen welche Speicherzellen sich wie ändern.
Vielleicht reicht das schon aus um mittels Byteweisen Vergleich 
(automatisiert) ein klares Schema zu erkennen.

Wenn man weiß wo genau der Zählerstand abgespeichert wird kann das 
helfen die fragliche Codestelle zum schreiben (und/oder lesen) des 
Zählerstands schneller aufzufinden und zu editieren.
(Z.b. Ersatz des Schreibbefehls durch NOP wenn möglich. Oder 
Hardcodierter Rückgabewert beim Lesen )

Unter Umständen kann es aber auch einfacher sein in einem freien Bereich 
des Programmspeichers einen Patch unterzubringen der beispielsweise beim 
Einschalten des Gerätes den entsprechenden Speicherbereich jedesmal  auf 
einen Zählerstand von '1' oder '10' zurücksetzt. So könnte man wenn 
nötig auch umfangreichere Dinge unterbringen wie z.b. eine Neuberechnung 
eines CRC Wertes. Oder das nur Neugeschrieben wird wenn die 
Speicherstelle einen bestimmten Zählerstand erreicht hat usw.
Dazu fügt man am Anfang des Programms an geeigneter Stelle einen Sprung 
zum Beginn des "Patch-Codes" ein, am Ende des Patches wird dann zu 
dieser Stelle zurückgesprungen. Wenn man Glück hat beginnt das Programm 
schon mit einer Sprungsequenz am Resetvector. (Sobald auch nur ein 
Interrupt zur Anwendung kommt bei dieser µC serie so gut wie zwingend. 
Ausnahme nur wenn das sofortige Durchlaufen der Interruptroutine 
unmittelbar nach Start vorgesehen ist)
Dann ändert man die Adresse einfach ab und springt am ende der eigenen 
Programmsequenz an die ursprünglich in der Startsequenz vorgesehene 
Adresse.

Auch wenn es kompliziert klingt, in der Praktischen Ausführung KANN dies 
manchmal erheblich schneller und unkomplizierter sein als das 
Identifizieren und Ändern der Relevanten Stellen mitten IM 
ursprünglichen Programmcode selbst. Liegt ganz dran WIE die Erfassung 
des Zählerstands im Programm realisiert ist und ob evtl. Fallstricke 
vorhanden sind.
Gerade auch wenn die Erfahrung gering ist.
Kommt aber auf den Einzelfall, die Speicheraufteilung und vor allem auf 
den Platz an.
Aber ohne die grundsätzliche Kenntnis der PIC16 ASM Befehle geht es auch 
hier nicht.

Gruß
Carsten

: Bearbeitet durch User
von Teo D. (teoderix)


Lesenswert?

Carsten S. schrieb:
> Auch wenn es kompliziert klingt....

Erinnert mich an alte Amiga Zeiten.
Da gabs HW-Module die einen da prächtig unterstützten - Natürlich nur 
zum Debuggen.
Ich habe niemals nicht, auch nur irgend etwas Gecrackt, ich schwör!


PS: Klingt wesentlich komplizierter, als es letztendlich ist!

von bernte (Gast)


Lesenswert?

noch eine andere Idee, falls das sperren des speicherns nicht möglich 
ist
so könnte man ja wohl irgendwie den Grundwert von 200 ermittlen
und betreffenden wert durch die höchst mögliche anzahl ersetzen zb 
56tausend einschaltvorgänge oder so ähnlich?

von fop (Gast)


Lesenswert?

Wenn die Software sich nicht gegen Änderungen schützt, ist es am 
einfachsten ein wenig Code zu schreiben, dass immer vor der eigentlichen 
Software ausgeführt wird und das den Zähler z.B. auf 42 setzt.

Dadurch fällt der Zähler immer auf den Werten 42 und 43 'rum, was auf 
jeden Fall kleiner als die 200 ist.

von devzero (Gast)


Lesenswert?

Jedes mal neu schreiben ist ja auch doof - einfach den Block (sofern es 
ihn gibt) vom Schreiben ins EEPROM ausbauen (was man tun muss, um in das 
EEPROM zu schreiben ist ein festgelegter Ablauf der im Datenblatt zu 
finden ist und so charakteristisch ist, dass man ihn leicht aufspueren 
kann. Den Check kann man ja drin lassen und den Wert einmalig - beim 
Flashen - ins EEPROM schreiben.

Aber erstmal abwarten, bis der Fragesteller sich wieder mit Details 
meldet.

von K. J. (Gast)


Lesenswert?

Brauch er nicht umbedinkt, er müsste nur immer den gleichen wert 
schreiben, das ist nur 1 befehle um das W reg. im passenden Moment zu 
überschreiben direkt bevor in das EEPROM/Flash geschrieben wird, dann 
kann er den Rest so lassen wie es ist, wehre die einfachste Möglichkeit.

von bernte (Gast)


Lesenswert?

anscheinend gibt es ja einige Möglichkeiten, das noch irgendwie 
hinzubekommen.

heute abend gibt es hexcode für alle

danke Euch erstmal das ihr Euch dazu geäußert habt, das gibt mir 
Hoffnung
wäre ein schöner Abschluss für die Winter Bastelzeit

von K. J. (Gast)


Lesenswert?

Am besten wie oben schon geschrieben wehren einmal das Org. Hex und 
einmal eins was du nach einigen malen ein und ausschalten wieder 
ausliest inkl. den EEPROM Dump.

Wobei man das sicher auch in ner Emu machen kann für den Pic16f877 gibt 
es da genug

von Bernd M. (bernte_one)


Angehängte Dateien:

Lesenswert?

ok grade nochmal nachgeforscht in mein ordner liegt noch eine ***.asm 
datei

wäre doch besser als als hex code? ;-)
hoffe es ist nicht die falsche datei

hab mal mit atmel studio reingeschaut, sieht aus wie ein disassembler 
der aus dem vorherigen hex mit der einschalbegrenzung erzeugt wurde

dann hatte ich da schon mal irgendwann was begonnen

würde es helfen dann lade ich die mal hoch?

: Bearbeitet durch User
von Werner H. (pic16)


Lesenswert?

Poste einfach mal die hex Datei, dann kann ich das mal durchtesten. 
Keine ausgelesene Datei, nur die Originale!

: Bearbeitet durch User
von Bernd M. (bernte_one)


Angehängte Dateien:

Lesenswert?

so die entsprechnde hex datei anbei

danke für die Mühe

von Werner H. (pic16)


Angehängte Dateien:

Lesenswert?

Hier das Resultat, "Code Protect"! Da ist leider nix zu machen.

von devzero (Gast)


Lesenswert?

WAS soll codeprotected sein? Das HEX File hat er ja - natuerlich kann 
man dort auch die Fuseconfig hinterlegen, aber die kann man nun auch 
einfach ueberschreiben beim flashen...

von K. J. (Gast)


Angehängte Dateien:

Lesenswert?

NAja das ist bei ner HEX Datei ehr nebensächlich, CP ist auch nicht 
wirklich an sondern Invalid, also nen Falscher wert, der passt ehr zum 
PIC16F877A vielleicht kann sich der TO nochmal dazu melden ob es nicht 
der A typ ist.

Im Anhang mal der vergleich beim PIC16F877 ist nen Fehler beim Ab typ 
passt es, die ICs sind zwar ziemlich gleich haben aber minimale 
unterschide also nicht zu 100% Kompatibel

von Werner H. (pic16)


Angehängte Dateien:

Lesenswert?

devzero schrieb:
> WAS soll codeprotected sein? Das HEX File hat er ja

Was im Hexfile steht, siehe oben.

von devzero (Gast)


Lesenswert?

Also, im Disassembly vom TO gibt es 2 Stellen, wo in das EEPROM 
geschrieben wird.
Das erfolgt durch einen call von h_0fe8 - da wird dann geschrieben, was 
zu der Zeit in 0x71 steht.

In h_06b3 wird der Wert an 0x64 dekrementiert und dann ins EEPROM 
geschrieben. Also ein Zaehler der runterzaehlt. Womoeglich muss man nur 
diesen call ausbauen, das muss man aber mal naeher untersuchen.

von devzero (Gast)


Lesenswert?

Werner H. schrieb:
> devzero schrieb:
>> WAS soll codeprotected sein? Das HEX File hat er ja
>
> Was im Hexfile steht, siehe oben.


Das ist doch nur das Configword, also die Fuses... also voellig egal. 
Das muss man ja nicht so schreiben.

von K. J. (Gast)


Lesenswert?

Ja sehe ich auch so, warst um einiges schneller, an dem Punkt könnte man 
0x64 einfach überschreiben, wenn es nirgend gegengeschenkt wird müsste 
das klappen.

Edit: oder einfach die Zeile rausnehmen aber dann müsste im EEPROM schon 
ein wert stehen.

von Werner H. (pic16)


Lesenswert?

devzero schrieb:
> also die Fuses... also voellig egal.
> Das muss man ja nicht so schreiben.

Das solltest du dem Programmierer sagen, der hat in der hex nämlich die 
"schweinerei" eingebaut.

> wird der Wert an 0x64 dekrementiert und dann ins EEPROM
> geschrieben.

Das EEprom ist leer.

K. J. schrieb:
> passt ehr zum
> PIC16F877A

Habe 877 und 877A probiert, kommt aufs Gleiche raus.

von devzero (Gast)


Lesenswert?

devzero schrieb:
> Also, im Disassembly vom TO gibt es 2 Stellen, wo in das EEPROM
> geschrieben wird.
> Das erfolgt durch einen call von h_0fe8 - da wird dann geschrieben, was
> zu der Zeit in 0x71 steht.
>
> In h_06b3 wird der Wert an 0x64 dekrementiert und dann ins EEPROM
> geschrieben. Also ein Zaehler der runterzaehlt. Womoeglich muss man nur
> diesen call ausbauen, das muss man aber mal naeher untersuchen.

In h_0689 wird der Wert durch call von h_0e7c ausgelesen, und auf 0 
geprueft.
1
 movwf   0x64                                    ;0690 00e4
2
 movf    0x64,f                                  ;0691 08e4
3
 btfss   status,z

Wenn der Wert 0 ist wird h_05ff aufgerufen - was auch immer genau da 
passiert. Wenn dieser Wert UNGLEICH 0 ist, wird wieder dekrementiert und 
geschrieben. Das ist mit grosser Wahrscheinlichkeit eine moegliche 
Stelle.

von K. J. (Gast)


Lesenswert?

Ok, bei mir ging es nur Fehler frei beim PIC16F877A aber eigentlich sind 
die bis auf Kleinigkeiten bei ADC kompatibel, hatte mich schon 
gewundert.

ich würde einfach das   "decf  0x64, f" entfernen dann bleibt der wert 
im GPR erhalten und wird nicht verändert, das könnte Funktionieren die 
näste zwei befehle holen den wert aus dem GPR und verarbeiten ihn 
weiter.

von Werner H. (pic16)


Lesenswert?

devzero schrieb:
> Also, im Disassembly vom TO gibt es 2 Stellen, wo in das EEPROM
> geschrieben wird.

Darauf kann man sich nicht verlassen und nach mehrmaligen starten des 
Controllers bleibt das EEprom leer?

von K. J. (Gast)


Lesenswert?

@ devzero das könnte auch für die Erststart Bedingungen sein, über das 
HEX wird ja nix im EEPROM abgelegt

von devzero (Gast)


Lesenswert?

Werner H. schrieb:
> devzero schrieb:
>> also die Fuses... also voellig egal.
>> Das muss man ja nicht so schreiben.
>
> Das solltest du dem Programmierer sagen, der hat in der hex nämlich die
> "schweinerei" eingebaut.


Sorry, aber das ist doch Schwachsinn.
Man kann das HEX nicht codeprotecten. Man kann (muss aber auch nicht) 
das Configword da mit ablegen und da kann man natuerlich auch CP setzen, 
aber das muss nicht geschrieben werden. Ist ohnehin egal, selbst wenn es 
gesetzt ist. Das HEX File ist ja nun mal da und muss nicht ausgelesen 
werden.

Aktives CP bedeutet allein, dass man den PIC am Ende nicht mehr auslesen 
kann.

>
>> wird der Wert an 0x64 dekrementiert und dann ins EEPROM
>> geschrieben.
>
> Das EEprom ist leer.
>
> K. J. schrieb:
>> passt ehr zum
>> PIC16F877A
>
> Habe 877 und 877A probiert, kommt aufs Gleiche raus.

Kann ja sein, dass das EEPROM leer ist. Es gibt im Code ja 2 Stellen wo 
ins EEPROM geschrieben wird, vielleicht wird an einer Stelle davon 
initial geschrieben.. muss man sich naeher ansehen - am einfachsten geht 
es, wenn der Aufbau existiert.

von Werner H. (pic16)


Lesenswert?

K. J. schrieb:
> Ok, bei mir ging es nur Fehler frei beim PIC16F877A

Schon beim nur einlesen der Datei: Configuration 1BBA, Code Protect.
Also ist da irgendwas im Hexfile.

von devzero (Gast)


Lesenswert?

Werner H. schrieb:
> K. J. schrieb:
>> Ok, bei mir ging es nur Fehler frei beim PIC16F877A
>
> Schon beim nur einlesen der Datei: Configuration 1BBA, Code Protect.
> Also ist da irgendwas im Hexfile.


Ja, wohl CP im Configword. Und nochmal, das aendert genau was?
Du hast sogar ein Disassembly vorliegen.

von bernte (Gast)


Lesenswert?

wow danke, Ihr wisst echt worauf es ankommt

den Aufbau kann ich demnächst fertig stellen, Layout der Platine hab ich 
soweit, Ätzen ist schnell erledigt

bin bloß die kommende Woche arbeitsmäßig sehr eingespannt

aber Eure Äußerungen ermutigen mich da weiter zu machen

von devzero (Gast)


Lesenswert?

Und speziell fuer Werner H. etwas Nachhilfe:

http://ww1.microchip.com/downloads/en/DeviceDoc/31027a.pdf

KLICK 27.2 Configuration Word Bits

Note 2: Microchip recommends that the desired configuration bit states 
be embedded in to
the application source code. This is easily done in the MPASM assembler 
by the use
of the CONFIG directive. See Subsection 27.2.1 “MPASM’s CONFIG 
Directive.”
KLICK


Vermutlich steht im Assemblerfile vom Author (wenn es dann in ASM war, 
die Compiler koennen das aber natuerlich auch) was a la

__CONFIG  .... & _CP_ON (oder ALL) & ...

Siehe Tabelle 27-1 in dem PDF.


Dann taucht CP im Configword auf - das kann man einfach so brennen. Oder 
es eben wieder wegnehmen. Hat aber mit dem Problem vom TO genau gar 
nichts zu tun.


Lesen, wirken lassen und verstehen. Und dann nochmal ernsthaft die 
Frage: Was hast Du fuer ein Problem mit CP?

von Werner H. (pic16)


Lesenswert?

devzero schrieb:
> Ja, wohl CP im Configword

Mit dem Pickit lässt sich ja das Configword normalerweise editieren, 
geht aber bei diesem Hex nicht.

> Du hast sogar ein Disassembly vorliegen.

Aus dem ausgelesenen Pic, villeicht schon mal gestartet, einem 877 oder 
877a, mit welchem disassembler... dem würde ich nicht so einfach trauen.

> Was hast Du fuer ein Problem mit CP?

Keins, der TO hat eins und wir suchen eine Lösung die ihm helfen könnte.

> das kann man einfach so brennen.

Aber nicht mehr korrekt auslesen um den Counter oä nach starten des 
Programms zu finden.

: Bearbeitet durch User
von Carsten S. (dg3ycs)


Angehängte Dateien:

Lesenswert?

Hi,

K. J. schrieb:
> Ok, bei mir ging es nur Fehler frei beim PIC16F877A aber eigentlich sind
> die bis auf Kleinigkeiten bei ADC kompatibel, hatte mich schon
> gewundert.
>
> ich würde einfach das   "decf  0x64, f" entfernen dann bleibt der wert
> im GPR erhalten und wird nicht verändert, das könnte Funktionieren die
> näste zwei befehle holen den wert aus dem GPR und verarbeiten ihn
> weiter.

Habe ich auch erst gedacht...
Die Frage ist nur ob EEPROM Inhalt Initialisiert wird und das mehr als 
nur den Counter betrifft.
Da müsste man sich die andere Stelle Anschauen wo ins EEProm geschrieben 
wird.

Die Stelle mit der eigentlichen Prüfung die devzero weiter oben erwähnt 
hat habe ich auch "vom Bauchgefühl" als die richtige Gefunden. Nur er 
war schneller.
Ganz sicher ist man aber nur wenn man das Programm komplett zerlegt oder 
sich die Dumps nach einigen Powerzyklen anschaut.

Wenn die Prüfung 0 ergibt wird ja der Goto Befehl übersprungen, es 
folgen dann noch einige Call Befehle wobei die meisten nur 
Bankumschaltung usw. sind. An einer Stelle wird aber noch was mit den 
EEPROM Werten gemacht.
Im weiteren Verlauf des Calls von h_05ff wird der EEPROM Wert noch einem 
XOR Vergleich mit 0xff unterzogen womit ggf, eine leere 
(nichtinitialisierte) Speicherzelle festgestellt wird. Da müsste man das 
Programm noch weiter Analysieren.

Am ende der langen Reihe, wenn nicht vorher im weiteren Verlauf des 
Calls von h_05ff herausgesprungen wird, endet das Programm in einer 
leeren Endlosschleife was ja nichts anderes ist als ein faktischer 
Programmstopp. ISt halt die Frage ob das Teil des geplanten 
Programmaufbaus ist und  diese Schleife durch Interrupt verlassen wird 
oder ob es tatsächlich das Einfrieren des Programms bei Zählerstand null 
ist.

Auf Verdacht würde ich jetzt an der Prüfung selbst ansetzen.
Das BTFSS entfernen und einfach einen harten Sprung ausprobieren.
Im angehängten File habe ich einfach mal BTFSS und das goto von der 
Position vertauscht. Dadurch wird der Programmcode hinter dem Goto 
niemals erreciht. Im Ergebnis genau so wie wenn die Prüfung auf "Null" 
dann "unwahr" ergibt.

Wenn ich jetzt das Ding bauen wollte würde ich das so jetzt erst einmal 
ausprobieren bevor ich das Programm unnötig totanalysiere.
Es kann natürlich sein das die Funktion so überhaupt nicht mehr korrekt 
ist, aber das sieht man ja dann.
Arbeitet das Gerät hingegen aber normal, ist die Wahrscheinlichkeit groß 
das es das auch dauerhaft tun wird. Wenn gleich man da erst nach 200 
(bzw. vielleicht auch 256) Powerzyklen sicher sein kann.

Gruß
Carsten

BTW: Alles vorrausgesetzt das das Dissamssemblierte Listing überhaupt 
korrekt ist. Es sieht soweit ja erst einmal gut aus und bei PIC ist das 
meist auch unproblematisch. Aber garantiert ist das nicht!

: Bearbeitet durch User
von Carsten S. (dg3ycs)


Lesenswert?

Werner H. schrieb:
> devzero schrieb:
>> Ja, wohl CP im Configword
>
> Mit dem Pickit lässt sich ja das Configword normalerweise editieren,
> geht aber bei diesem Hex nicht.

Klar kann man die Configfuses im Pic mit dem pickit nur so lange 
editieren wie die CP fuse NICHT gesetzt ist. Sonst wäre die CP Fuse ja 
witzlos.

Aber hier liegt ja schon das Hex File vor.
Und wenn ich das Hex File habe, dann kann ich problemlos die Fuse 
Settings im File selbst verändern. Das geht mit dem Hex editor direkt 
oder für Einsteiger in dem ich das Programm mit MPLAB 8.xx einspiele, 
vor dem Einspielen in MPLAB aber auswähle das die Fuse Settings im Code 
ignoriert werden sollen und statt dessen im Fuse Menü von MPLAB die CP 
Einstellungen selbst wählen.

DAS ist nun wirklich das allerkleinste Problem.

Gruß
Carsten

: Bearbeitet durch User
von K. J. (Gast)


Lesenswert?

Ja stimmt, für mich wehre grade nen Schaltplan recht brauchbar vom 
Gerät, ich simuliere grade mit GPSIM, allerdinks hängt es etwas weil da 
einige Taster/Schalter fehlen die ich manuell umstellen muss, das ist 
recht nerfig

von bernte (Gast)


Lesenswert?

Schaltplan lad ich heut Abend mal hoch.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.