Hallo Forengemeinde,
habe ein "kleines" Problem.
Wir haben die Aufgabe, ein bestehendes, funktionierendes Programm für
den 16F628 so zu ändern, dass es auf dem 16F88 läuft.
Das meiste läuft schon, lediglich mit den Daten im EEPROM hab ich noch
ein Problem.
Zum einen gibt es beim 16F88 mehr Register für die Adressierung etc.,
zum anderen sind diese auch noch auf zwei Bänke verteilt.
Die entsprechenden Code-Ausschnitte sehen wie folgt aus:
.
.
.
ORG 0x2100 ; Start off EEPROM
de "Test"
de 0x00
.
.
.
PrintDisp
call ClearDisplay ; clear display content
bsf STATUS, RP0 ; Bank1
clrf EEADR ; start of EE-memory
movlw 0xE4 ; Start for first char a 7 o'clock
movwf FSR ;
movlw .14 ; 14 char to display
movwf Scratch3 ;
pdisp_1
bsf EECON1, RD ; read character from EEProm
incf EEADR,f ; inc address for next read
movf EEDATA,w ;
bsf STATUS,RP1 ; goto Bank2
bcf STATUS,RP0 ;
call CharOffset ; call character data
pdisp_2
call LoadChrData ; load pixel data from CharGen
movwf INDF ; store char pixel data in display memory
incf FSR,w ; increment FSR
call CheckIncrement ;
movwf FSR ;
decfsz ch_dot_index,f ; 6 dot's in one character, all displayed
?
goto pdisp_2 ;
bcf STATUS,RP1 ; leave bank 2, back to bank1
bsf STATUS,RP0 ;
decfsz Scratch3,f ;
goto pdisp_1
bcf STATUS,RP0 ; go back to bank 0
return
;--------
ScrollText
bsf STATUS,RP1 ; goto Bank2
bcf STATUS,RP0 ;
movf ch_dot_index,w ;
btfss STATUS,Z ; dot_index == 0 ?
goto Scroll_0
movf ch_blanking,w ;
btfsc STATUS,Z ;
goto Scroll_read_ee ;
decfsz ch_blanking,f ;
goto Scroll_2 ; insert one more " "
btfss fDemo ; in demo mode?
goto Scroll_read_ee ; re-read char
bcf STATUS,RP1 ; to bank 0
call TextON_OFF ; at end of line, turn text off!
return ; stop scrolling
Scroll_read_ee
bcf STATUS,RP1 ; leave bank 2, to bank1 ;
bsf STATUS,RP0 ;
bsf EECON1, RD ; read character from EEProm
incf EEADR,f ; inc address for next read
bcf EEADR,7 ; roll over after 0x80 => 0x00
movf EEDATA,w ;
btfsc STATUS,Z ; Chr$(0) indicates end of line
clrf EEADR ; start of EE-memory
bsf STATUS,RP1 ; go back to Bank2
bcf STATUS,RP0 ;
btfss STATUS,Z ; if Z was 1, it wil still be 1 here
goto Scroll_1 ;
movlw 0x0F ; insert 15 " " at end of string to clear display
movwf ch_blanking ;
.
.
.
Könnt ihr mir evtl. helfen?
Gruß
PICerer schrieb: > Wir haben die Aufgabe, ein bestehendes, funktionierendes Programm für > den 16F628 so zu ändern, dass es auf dem 16F88 läuft. Du schreibst "wir", also bist du nicht alleine. Wieso suchst du hier jemanden, der eure Aufgabe übernimmt? Zu Faul? PICerer schrieb: > Die entsprechenden Code-Ausschnitte sehen wie folgt aus: Der Code, den du da gepostet hast, ist ja wohl unvollständig. Es zeugt auch nicht gerade von großem Verständnis der Materie, dass du Programmcode einfach ins EEPROM-Segment kopierst. PICerer schrieb: > Könnt ihr mir evtl. helfen? Klar, aber ich werde es erst tun wenn du selbst ein wenig Einsatz zeigst. Hier einfach ein paar Zeilen Code rein zu kopieren und zu warten bis jemand eure Aufgabe löst - daraus wird nichts. Gruß, Edson
Ja, WIR sind zwei. Zwei Anfänger, was die Materie betrifft, möchte ich dazu sagen. Deshalb vermögen wir auch nicht einzuschätzen, was von großem Verständnis zeugt, und was nicht. Zum unserem "Einsatz": es wäre uns auch lieber, wenn wir keine Hilfe benötigen würden, und ganz "faul" waren wir nicht: wir haben die Datenblätter der beiden Controller miteinander verglichen und festgestellt, dass die entsprechenden Register (EEADR, EECON1) im 16F88 auf anderen Bänken und somit Adresen sind als beim 16F628. Wohl auch, weil der 16F88 so einiges mehr an SFR's mitbringt, mehr Flash und ein doppelt so großes EEPROM hat, usw. Die entsprechende Bankwechsel haben wir also im code mit integriert, das Problem blieb aber bestehen. Und jetzt stehen wir ein wenig auf dem Schlauch... Bekommen wir nun einen Tip?
PICerer schrieb: > Bekommen wir nun einen Tip? Ja, von mir. Ich habe mir zwar den Code nicht genau angeschaut, aber: der Leseaufruf: bsf EECON1, RD ; read character from EEProm erfolgt bei Euch von Bank 1 aus. Die EECON Register liegen aber in Bank 3 ! und direkt vor dieser Zeile fehlt z.B. die Auswahl des Datenspeichers: bcf EECON1,EEPGD bei einem 16F690er sieht das z.B. so aus (Auslesen der ersten EE-Zelle): EElesen bcf STATUS,RP0 bsf STATUS,RP1 ; Bank 2 ; adressieren movlw 0x00 ; EEprom Zelle 0x00 auswählen movwf EEADR ; ins EE Adress Register schreiben ; auslesen bsf STATUS,RP0 ; Bank 3 bcf EECON1,EEPGD ; Lesezugriff auf den Datenspeicher bsf EECON1,RD ; Leseprozess starten bcf STATUS,RP0 ; Bank 2 movf EEDATA,0 ; gelesenes Byte ins w-Register bcf STATUS,RP1 ; Bank 0 return
Danke für den Tip.
Soweit waren wir aber schon. Der oben stehende Code war der "Ur"-Code,
deshalb war das dort noch nicht implementiert.
Was wir bereits versucht haben sieht so aus:
(wie Meister Eder schon richtig angemerkt hat ist das aber bei weitem
nicht der vollständige code...)
.
.
.
PrintDisp
call ClearDisplay ; clear display content
; bsf STATUS, RP0 ; Bank1
banksel EEADR ; !!! necessary for PIC16F88 !!!
clrf EEADR ; start of EE-memory
movlw 0xE4 ; Start for first char a 7 o'clock
movwf FSR ;
movlw .14 ; 14 char to display
movwf Scratch3 ;
pdisp_1
banksel EECON1 ; !!! necessary for PIC16F88 !!!
bcf EECON1,EEPGD ; !!! necessary for PIC16F88 !!!
bsf EECON1, RD ; read character from EEProm
banksel EEADR ; !!! necessary for PIC16F88 !!!
incf EEADR,f ; inc address for next read
movf EEDATA,w ;
bsf STATUS,RP1 ; goto Bank2
bcf STATUS,RP0 ;
call CharOffset ; call character data
pdisp_2
call LoadChrData ; load pixel data from CharGen
movwf INDF ; store char pixel data in display memory
incf FSR,w ; increment FSR
call CheckIncrement ;
movwf FSR ;
decfsz ch_dot_index,f ; 6 dot's in one character, all displayed?
goto pdisp_2 ;
bcf STATUS,RP1 ; leave bank 2, back to bank1
bsf STATUS,RP0 ;
decfsz Scratch3,f ;
goto pdisp_1
bcf STATUS,RP0 ; go back to bank 0
return
;--------
ScrollText
bsf STATUS,RP1 ; goto Bank2
bcf STATUS,RP0 ;
movf ch_dot_index,w ;
btfss STATUS,Z ; dot_index == 0 ?
goto Scroll_0
movf ch_blanking,w ;
btfsc STATUS,Z ;
goto Scroll_read_ee ;
decfsz ch_blanking,f ;
goto Scroll_2 ; insert one more " "
btfss fDemo ; in demo mode?
goto Scroll_read_ee ; re-read char
bcf STATUS,RP1 ; to bank 0
call TextON_OFF ; at end of line, turn text off!
return ; stop scrolling
Scroll_read_ee
; bcf STATUS,RP1 ; !!! comment for PIC16F88 !!!; else: leave
bank 2, to bank1 ;
; bsf STATUS,RP0 ; !!! comment for PIC16F88 !!!
banksel EECON1 ; !!! necessary for PIC16F88 !!!
bcf EECON1, EEPGD ; !!! necessary for PIC16F88 !!!
bsf EECON1, RD ; read character from EEProm
banksel EEADR ; !!! necessary for PIC16F88 !!!
incf EEADR,f ; inc address for next read
bcf EEADR,7 ; roll over after 0x80 => 0x00
movf EEDATA,w ;
btfsc STATUS,Z ; Chr$(0) indicates end of line
clrf EEADR ; start of EE-memory
bsf STATUS,RP1 ; go back to Bank2
bcf STATUS,RP0 ;
btfss STATUS,Z ; if Z was 1, it wil still be 1 here
goto Scroll_1 ;
movlw 0x0F ; insert 15 " " at end of string to clear display
movwf ch_blanking ;
.
.
.
MPLAB straft uns aber leider mit der Meldung:
The following memory regions failed to program correctly:
EEData Memory
Address: 00000000 Expected Value: 00000020 Received Value: 00000000
Programming failed
Noch eine Idee, wo wir mal nachsehen könnten?
GRuß
PICerer schrieb: > Noch eine Idee, wo wir mal nachsehen könnten? Kannst du nicht den vollständigen Code in einen Anhang packen? Dann könnte man leichter nachvollziehen, wo es hakt. Gruß, Edson
...das sind an die 2000 Zeilen Code... aber o.k.... ;-) Gruß
PICerer schrieb: > Danke für den Tip. > > Soweit waren wir aber schon. Der oben stehende Code war der "Ur"-Code da macht das Helfen doch richtig Spass. Naja, ihr seid ja wenigstens halbwegs auf dem richtigen Weg. Viel Vergnügen noch bei den weiteren Fallen :-)
Ein klassisches Beispiel, warum man besser C als Programmiersprache verwenden sollte: Die Lesbarkeit Die Übertragbarkeit (Portierbarkeit) von einem uC zum anderen Bei Pic: Kein kümmerern um dämliche Bankregister
...hilft nur nichts, weil wir wegen der Prüfungsrelevanz Assembler lernen müssen und nicht C... Gruß
Neue Erkenntnisse! Bin nur nicht sicher, ob ich darüber wirklich glücklich bin... Weil wir nicht mehr weiter wußten haben wir mal folgendes versucht: - neues Projekt in MPLAB angelegt - Template für den 16F88 eingefügt und außer den Config-bits für unsere Anforderungen NICHTS daran geändert - build all -> succeeded - program Pic und siehe da: auch da bekommen wir eine Fehlermeldung: The following memory regions failed to program correctly: EEData Memory Address: 00000000 Expected Value: 0000004d Received Value: 00000000 Programming failed Und das, obwohl wir im Template am Beispiel-Code für das EEPROM überhaupt NICHTS geändert haben... ??? Zusatzinfo: wir nutzen PicKit 3 Hat jemand eine Idee, warum das auch nicht funktioniert? Müssen wir in MPLAB / beim PicKit 3 irgendwas besonderes einstellen? Gruß
PICerer schrieb: > The following memory regions failed to program correctly diesen Satz in Google eingegeben führt zu etlichen Antworten, die zur Lösung führen könnten. Da wir aber nicht wissen, wie eure Hardware aussieht, vor Allem die Beschaltung von MCLR und der Programmierschnittstelle, lässt sich kaum sagen, welches Problem hier vorliegt. Außer dass der PIKKit 3 garnicht mit dem PIC kommuniziert. Kommt z.B. bei der Auswahl des PICKits die Meldung dass er einen 16F88 gefunden hat? Wird vor der Programmierung der Speicher gelöscht? Ist LVP aktiv? und falls ja, wird der Pin PGM dann richtig benutz? usw...
also,... Controller wird über ICSP-Schnittstelle programmiert. Config-Bits (config1 passt hier leider nicht in eine Zeile): __CONFIG _CONFIG1, _CP_OFF & _CCP1_RB0 & _DEBUG_OFF & _WRT_PROTECT_OFF & _CPD_OFF & _LVP_OFF & _BODEN_OFF & _MCLR_OFF & _PWRTE_ON & _WDT_OFF & _HS_OSC __CONFIG _CONFIG2, _IESO_OFF & _FCMEN_OFF LVP ist also off, genau so wie MCLR. Bei MCLR ist trotzdem noch ein 22k Pullup + Schottky-Diode (wegen Trennung zu VDD während des Programmierens)verschalten. Überhaupt ist die ICSP-Beschaltung so, wie im ICSP-Guide von Microchip beschrieben. PicKit und Target werden in MPLAB einwandfrei erkannt. Sobald wir im code die ganze EEPROM-Geschichte auskommentieren läßt sich der PIC problemlos programmieren und funktioniert einwandfrei (natürlich mit Ausnahme des Parts, wo das EEPROM genutzt würde...). Daher denke ich, dass wir kein Kommunikationsproblem haben, lass' mich da ber gern eines besseren belehren.. Gruß
Die Frage ist, muß der EEPROM überhaupt vorbelegt werden? Bei meinen Anwendungen mache ich das nicht. Die Anwendung prüft, ob im EEPROM gültige Daten sind, z.B. durch ein Magic an einer bestimmten Adresse und durch eine CRC. Und wenn sie feststellt, die Daten sind ungültig, dann lädt sie die default Daten hinein. Damit ist auch abgesichert, wenn die Daten anderweitig zerstört werden. Z.B. wenn gerade beim Schreiben der Strom ausfällt und der EEPROM einen Teil neue und alte Daten enthält. Peter
...leider ja, weil dort ein Text steht, der als Laufschrift ausgegeben werden soll (was beim 16F628 auch funzt). Ich füge mal den wesentlichen Teil des Schaltplans an. PortB geht auf LEDs, außer RB6 und RB7. Diese Pins gehen über R22 und R23 auf je auf ein Gate eines MOSFETs. Was "grundsätzlich" falsches finde ich in dem Plan aber nicht... Mehrere Controller und einen weiteren "Brenner" haben wir auch schon versucht,.... leider alles ohne Erfolg. Sobald diese Zeilen code
1 | DATAEE
|
2 | ORG 0x2100 |
3 | DE "MCHP" ; Place 'M' 'C' 'H' 'P' at address 0,1,2,3 |
nicht auskommentiert sind, bekommen wir die Fehlermeldung...:-/ Gruß
und was passiert, wenn ihr nur die erste Zelle vordefiniert? org H'2100' de 0x00
...keine Fehlermeldung! Mit mehreren "de 0x00" hintereinander kann ich auch problemlos mehrere Zellen des EEPROMs "betanken", aber sobald ich was anderes als 0h hineinschreiben möchte, bekomme ich wieder die Fehlermeldung... :-/ Gruß
Habe jetzt mal das Template für den F88 genommen und mit MPLAB 8.83
assembliert. Läuft ohne Fehlermeldung durch und das Listfile zeigt
korrekt die erzeugten Werte an
00097 ;
00098
;-----------------------------------------------------------------------
-------
00099
2100 00100 DATAEE ORG 0x2100
2100 004D 0043 0048 00101 DE "MCHP" ; Place 'M' 'C' 'H' 'P' at
address 0,1,2,3
0050
2104 0088 00F8 0097 00102 DE 0x88, 0xF8, 0x97
nutze ebenfalls MPLAB 8.83.
Beim Assemblieren bekomme ich auch keine Fehlermeldung, erst, wenn ich
das Programm auf den Controller "überspielen" möchte...
Wenn ich das "jungfräuliche" Template nehme sieht mein Listfile so aus:
00097 ;
00098
;-----------------------------------------------------------------------
-------
00099
2100 00100 DATAEE ORG 0x2100
2100 004D 0043 0048 00101 DE "MCHP" ; Place 'M' 'C' 'H' 'P' at
address 0,1,2,3
0050
00102
00103
;-----------------------------------------------------------------------
-------
Geringfügig anders als bei Ihnen, aber die Daten scheinen schon an der
richtigen Stelle zu sein...
Sehr suspekt, das Alles....
PICerer schrieb: > ...das sind an die 2000 Zeilen Code... > aber o.k.... ;-) Ok, was ist daran so ungewöhnlich? Bei Assembler-Programmen mache ich mir frühestens im 5-stelligen Bereich sorgen über das Ausmaß. Peter Dannegger schrieb: > Die Frage ist, muß der EEPROM überhaupt vorbelegt werden? Sorry, aber das ist nicht die Frage in diesem Thread. Die beiden TE haben sich dieses Programm wohl nicht ausgesucht, also bringt es nichts jetzt eine weitere Baustelle aufzureissen. Der Code lässt sich fehlerfrei übersetzen und die IDE wirft eine Fehlermeldung: PICerer schrieb: > The following memory regions failed to program correctly: > EEData Memory > Address: 00000000 Expected Value: 0000004d Received Value: 00000000 > Programming failed @PICerer Schau mal nach, ob unter Programmer>Settings>Program Options der Haken bei "Preserve EEPROM on Program" gesetzt ist. Ansonsten würde ich das Problem bei der Hardware vermuten. Die Fehlermeldung entsteht ja aus einem fehlerhaften Vergleich des EEPROM mit dem Hex-File (oder dem Ort, wo MPLAB die 'expected value' holt). Gruß, Edson
o.k., zumindest eine Hürde ist genommen! Der Haken bei "Preserve EEPROM" sorgt zumindest schon mal dafür, dass die Fehlermeldung ausbleibt. VIELEN DANK für diesen Tip. Die Ausgabe der Daten auf unserem "Display" funktioniert aber leider noch nicht, obwohl ich (denke ich) die ganze Bank-hin-und-her-Schalterei angepasst habe... Zum Code-Umfang: auch wenn es "nur" 2000 Zeilen Assembler sind hatte ich doch einige Hemmungen, das hier zu posten. Ist ja nicht selbstverständlich, dass sich jemand diese Menge Text "freiwillig" antut, um jemand fremden zu helfen... BTW: der Brenner8 von Sprut bringt nach wie vor die Meldung "Start write EEPROM## 4 error(s)", wenn ich das hex-file übertragen möchte...(?) Gruß
PICerer schrieb: > Ist ja nicht selbstverständlich, dass sich jemand diese Menge Text > "freiwillig" antut, > um jemand fremden zu helfen... Wow, danke für diese Einsicht. Ich möchte mich für meinen provokanten ersten Beitrag bei dir entschuldigen. Ich habe aber kaum etwas vom Quelltext gelesen. Es hilft schon sehr viel wenn man den Übersetzungs-Vorgang selbst nachvollziehen, also den Assembler mit vollständigen Daten füttern, kann. PICerer schrieb: > Die Ausgabe der Daten auf unserem "Display" funktioniert aber leider > noch nicht, obwohl ich (denke ich) die ganze Bank-hin-und-her-Schalterei > angepasst habe... Gut, dann lohnt es sich jetzt das Programm genauer unter die Lupe zu nehmen. Gruß, Edson
PICerer schrieb: > ...leider ja, weil dort ein Text steht, der als Laufschrift ausgegeben > werden soll (was beim 16F628 auch funzt). Dann wäre noch eine Frage, ob dieser Text zur Laufzeit geändert werden muß oder konstant ist. Konstanten Text legt man üblicher Weise im Flash ab, nicht im EEPROM. Bei den einfachen PIC geht das mittels DT, welches RETLW-Anweisungen erzeugt. Ist zwar etwas umständlich (PCLATH berechnen), aber man findet reichlich Beispiele dazu. Das hat auch den Vorteil, daß der Flash deutlich größer ist als der EEPROM. Es paßt also mehr Text rein. Man kann aber auch beides machen. Ist der EEPROM leer (0xFF), wird der Text aus dem Flash gelesen. Ansonsten aus dem EEPROM. Peter
@Meister Eder Kein Problem, so wie ich in meiner Verzweiflung schnell, schnell den Eröffnungsthread formuliert habe, hat man schon auf die Idee kommen können. Ich war aber trotzdem fast ein wenig beleidigt, weil ich mich schon zu den Tüftlern zähle, die nicht so schnell aufgeben... ;-) Allerdings ist mein Gebiet zugegebenermaßen eher die Hardware... @Peter Dannegger Text bleibt über die ganze Zeit konstant. DT und PCLATH berechnen ist mir bekannt. Wird in dem von mir geposteten Programm sogar an andere Stelle angewendet. Vielleicht noch folgende Info: Das ganze basiert auf einer "Propeller-Uhr", die um die Möglichkeit einer Laufschrift erweitert wurde. Uhr funzt wunderbar, die Laufschrift bisher leider nur beim 628er... Gruß
Erich schrieb: > Ein klassisches Beispiel, > warum man besser C als Programmiersprache verwenden sollte: > > Die Lesbarkeit > Die Übertragbarkeit (Portierbarkeit) von einem uC zum anderen > Bei Pic: Kein kümmerern um dämliche Bankregister Eben nicht! Wer nicht lernt, in Assembler gut strukturiert zu schreiben, der lernt es auch in C oder sonst einer Sprache auch bloß nicht. Aber ich bin ja nett, also hier ein Ausschnitt aus einer meiner Quellen: (war ein 16F871) ; eingebauter EEPROM ; ================== ReadNextEE: INCF FSR,F ; ein Byte vom EEPROM[FSR] lesen ReadEE: MOVF FSR,W BSF RP1 BCF RP0 MOVWF EEADR BSF RP0 BCF EE_PGD BSF EE_RD BCF RP0 MOVF EEDATA,W BCF RP1 RETURN WriteNextEE: INCF FSR,F ; EEPROM[FSR] schreiben, Daten in Hudl WriteEE: BSF RP0 BCF EEIE BCF RP0 BCF EEIF BSF rgie SKIP GIE BCF rgie MOVF FSR,W BSF RP1 BCF RP0 MOVWF EEADR BCF RP1 MOVF Hudl,W BSF RP1 MOVWF EEDATA BSF RP0 BCF EE_PGD BSF EE_WREN BCF GIE CLRWDT MOVLW 55h MOVWF EECON2 MOVLW 0AAh MOVWF EECON2 BSF EE_WR SKIP NOT rgie BSF GIE BCF EE_WREN BCF RP0 BCF RP1 _eew: SKIP EEIF GOTO _eew RETURN ; Text aus EEPROM auf senden, Position in W TextOutEE: MOVWF EEpos _toz: MOVF EEpos,W MOVWF FSR CALL ReadEE SKIP NZ RETURN CALL SayIt INCF EEpos,F GOTO _toz Dieser Ausschnitt verwendet einige Rettungszellen, um z.B. den Zustand von GIE zu retten. Ach ja: bei mir sind die Bitbezeichnungen mit den zugehörigen Registern verknüpft, deswegen braucht es z.B. nur ein BSF RP1 und nicht BSF STATUS,RP1 W.S.
W.S. schrieb: > Ach ja: bei mir sind die Bitbezeichnungen mit den > > zugehörigen Registern verknüpft, deswegen braucht es z.B. nur ein BSF > > RP1 und nicht BSF STATUS,RP1 Ja, hab ich mir schon gedacht, weil z.B. das Bit EEPGD ja "normalerweise" ohne Unterstrich geschrieben wird...
...nachdem ich nun auf keinen grünen Zweig mehr komme, bin ich kurz davor aufzugeben (was mein Kollege bereits gestern schon tat). Ich sollte wohl auch zukünftig lieber auf der Hardwareschiene bleiben... :-/ So wie es aussieht ist aus irgendeinem Grund mein EEPROM komplett mit "00" gefüllt. Ganz egal was ich mache. Ich übertrage mein Programm auf den Pic, es kommt keine Fehlermeldung. Lese ich jetzt den PIC aus und gehe auf View->EEPROM steht wieder/immer noch in jedem Byte "00". Probiert habe ich das ganze jetzt mit fünf (!) Controllern, weshalb ich das Problem jetzt mal nicht auf einen defekten Controller schiebe. Lese ich das EEPROM beim 628er aus, sehe ich dort tatsächlich das, was ich hinein geschrieben habe. In den nicht benutzten Bytes steht "FF", nicht wie beim 88er "00". Ganz schön frustrierend... :-( Gibt es evtl. in MPLAB noch irgendeinen Haken den ich setzen/entfernen muss, oder irgendeine Option, die ich aktivieren/deaktivieren muss, um mit dem EEPROM zu arbeiten? Gruß
Ich werde mal versuchen, deinen Code per PICKit3 in einen 16F88 zu bekommen und dann prüfen, was im EEProm steht. Kann ich aber erst Anfang nächste Woche machen. Ach ja, die 0815 Antworten im Microchip Forum kannst du vergessen. Die lesen noch nichtmal durch was für ein Problem vorliegt sondern antworten gleich mit Standard Phrasen wie: "benutze den Code wie im Datenblatt..." :-)
...ja, hab ich gemerkt... Danke für deine Unterstützung. Bin gespannt, was bei dir rauskommt. Gruß
Angehängte Dateien:
-
Adapter_Anschluss.jpg
42 KB -
EE_Inhalt_vorher.jpg
82 KB -
EE_Inhalt_nachher.jpg
98 KB
Nicht so ungeduldig, bin gerade eben erst dazu gekommen. Den 16F88 (18pin DIP) habe ich einfach auf dem Steckbrett mit den 5 Pins des PICKit3 verbunden (Vpp 5V Gnd Dat Clk) Beim Auslesen des EE Inhalts des jungfräulichen Chips bekomme ich lauter Nullen. Nachdem ich deinen Code (siehe oben) hineingeschrieben habe, lese ich den gewünschten Inhalt aus dem EEProm ! D.h. es funktioniert. Vielleicht ist deine Beschaltung mit den diversen passiven Bauteilen um den PIC herum die Ursache des Problems.
Danke für deinen Versuch! Wollte bestimmt nicht ungeduldig erscheinen, nur das Thema nicht in Vergessenheit geraten lassen. Jedenfalls: EEPROM beschreiben und auslesen klappt jetzt auch bei mir. Offensichtlich hat der PicKit 3 ein Problem, wenn er mit einer Kapazität von 24pF belastet wird. Diesen Umstand habe ich beseitigt. Das Dumme jedoch: irgendwo habe ich noch einen Bug im Code. Angezeigt wird mir der Inhalt des EEPROMs nämlich leider noch nicht... :-( Das werde ich jetzt mal unter die Lupe nehmen. Gut möglich, dass ich euch hier dann noch mal um Hilfe bitten muss... Bis dahin aber noch mal vielen Dank an alle, die mir bis hierher geholfen haben. Gruß
räusper Hab den Rest jetzt hingekriegt :-) Danke noch mal für Eure Hilfe! Gruß
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.