Programm von Pic16F628 für Pic16F88 ändern

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ß

...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ß

...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ß

...hoppla, Schaltplan vergessen...

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ß

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....

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ß

@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ß

...steht Dein Angebot noch?

Gruß

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ß