PIC: Falsche Bank ausgewählt - Anfängerproblem

[sx31fg (Gast)]

Hallo, ich versuche gerade den Einstieg in die PIC Programmierung mit 
Assembler und habe mir das PICKit 2 mit Testplatine gekauft. Nun wollte 
ich mein erstes Program ausprobieren und erhalte einen Fehler, für den 
ich keinen Grund finden kann. Ich möchte eine Leuchtdiode am Pin RC1 zum 
Leuchten bringen.

--

  LIST P=16F690
  __config 0x3B04
w   EQU 0
f   EQU 1
STATUS  EQU 0x003
RP0  EQU 5
PORTC  EQU 0x007
TRISC  EQU 0x087
;
  ORG 0
  goto start
start  bsf STATUS, RP0    ; Bank 1 auswählen
  movlw 0xFD    ; Kopiere b11111101 nach W (0 = Ausgang)
  movwf TRISC    ; Kopiere Inhalt von W nach TRISC <- Hier enteht der Fehler
  bcf STATUS, RP0    ; Setze Bit 0 in RP0 um Bank 0 auszuwählen
;
  bsf PORTC, 1    ; Setze Bit 1 in PORT C auf 1
  END

--

Wenn ich das Programm nun in HexCode umwandeln lassen will, erhalte ich 
für die Zeile mit dem Befehl "movwf TRISC" die

Message[302]: Register in operand not in bank 0.  Ensure that bank bits 
are correct.

Ich habe doch aber zwei Zeilen zuvor die Bank 1 ausgewählt, da TRISC ja 
in Bank 1 liegt und dürfte doch gar nicht in Bank 0 sein. Könnte mir 
bitte jemand erklären, was ich falsch gemacht habe?

Vielen Dank
Sven

[Meister E. (edson)]

>Könnte mir bitte jemand erklären, was ich falsch gemacht habe?

Gar nix. Das ist nur eine Warnung, kein Fehler. Wenn du alle 
Bankselektionen geprüft hast, kannst du die Meldung per

errorlevel -302

unterbinden.

Grüße,
Edson

[Sven M. (sx31fg)]

Vielen Dank für die schnelle Antwort. Die Leuchtdiode leuchtet nun... ;)

Gruß
Sven

[Peter D. (peda)]

RAM-Banking und Code-Paging ist aber ne Spezialität der PICs, um den 
Programmierern das Leben schwer zu machen.

Benutzer anderer MCs kennen ne Bank nur zum Sitzen oder Geld abheben. 
Sie sind es gewohnt, mindestens 64kB Code oder Daten am Stück 
adressieren zu können. Macht einfach mehr Spaß und man kann sich aufs 
eigentliche Programmieren konzentrieren.
Das erklärt wohl auch, warum die AVRs so schnell Fuß gefaßt haben, 
obwohl sie ja wesentlich jünger (1997) als die PICs sind.


Peter

[Sven S. (stepp64)]

Ist bei den 16F wirklich recht umständlich gelöst und ist immer wieder 
die Quelle von Fehlern im Programm und stundenlanger Suche danach.

Bei den 18F ist das um einiges besser gelöst, wobei man auch dort nicht 
völlig frei vom Banking ist. Allerdings sind dort die RAM-Bänke 256 
Bytes groß und alle Specialregister liegen zusammen mit 128-Byte 
User-RAM im ACCESS-RAM, sodass man nicht umschalten muss, solange man 
mit diesen 128 Bytes auskommt. Codepaging gibt es bei den 18F aber nicht 
mehr. Ist schon mal ein Fortschritt.

Du solltest aber deinem Programm eine Hauptroutine gönnen (in deinem 
Fall eine Endlosschleife vor dem END), da dein PIC sonst mit dem Befehl 
weiter macht, der im Flash nach deinem letzten Befehl steht. 
Wahrscheinlich wird dein PIC ständig reseten, was du natürlich nicht 
siehst, da es viel zu schnell geht.

[K. J. (Gast)]

Hi warum wird eigentlich noch "bsf STATUS, RP0" genutzt des geht doch 
wesentlich einfacher mit "banksel <Reg.>".

Jedenfals brauch man sich keine sorgen mehr machen ob man in der 
richtigen Bank ist

[Sven S. (stepp64)]

Ist schon richtig. Der einzige Grund, der mir einfällt ist, das banksel 
eigentlich 2 Befehle sind (RP1 wird hier auch immer mit geschaltet) und 
"bsf STATUS, RP0" nur einer. Eventuell hat hier sprut auch zuviel 
Einfluss...

[gast (Gast)]

Weil Banksel reg zwei Befehle sind, und je nach MPLAB version, auch
den Inhalt von W zerstört.

[Sven S. (stepp64)]

Im Ernst? Das wusste ich noch nicht. Ich dachte banksel setzt mittels 
Bitsetzbefehle die Bits RP0 und RP1 im STATUS-Register. Dabei dürften 
sich W und auch die Flags nicht verändern. Welche MPLAB Versionen sind 
denn das, welche W zerstören? Trifft das auch auf pagesel zu?