Probleme hex-File zu erstellen von PIC16F1527(1827)

Du hast 16F1827 eingestellt, aber einen 16F1527 verwendet. Ist das so 
richtig?

Nein, anders. Ich habe physisch einen 1527. Include-Datei gibt es, habe 
mein eigenes ASM-File anfänglich erstellt und kam zu keinem fehlerfreien 
hex-File.

Dann laß ich, dass es für alle PICs ein von Microchip vorgefertigtes 
ASM-File gibt. Also das suchen, nehmen und schauen, ob das geht und was 
ich anders machen muss in meinem eigenen. Mist, include gibt es, aber 
das TEMPLATE.ASM für 1527 gibt es nicht. Also, denke ich, nimm einen 
ähnlichen zum Test -> 1827, da gibt es sowohl TEMPLATE als auch 
include-File, also das getestet. Geht auch kein hex-File zu erstellen, 
die gleichen Fehler wie 1527. Folglich muss mir irgendein Softwarestand 
fehlen.

Michael schrieb:
> MPASM v4.02

So weit ich weiß unterstützt diese Version noch keine PIC16F mit 
4-stelligen Nummern (PIC16Fxxxx).

Wenn du MPLAB X nicht verwenden möchtest, könntest du es mal die letzte 
Version von MAPLB 8 versuchen (116 MB):
http://ww1.microchip.com/downloads/en/DeviceDoc/MPLAB_IDE_8_92.zip

Also jetzt bin ich einen Schritt weiter, daher erstmal vielen Dank für 
eure Hilfe!
Jetzt geht schon mal ein hex-File raus obwohl noch mit Fehlern, die aber 
sicher im Code-Detail zu beheben sind. Ich kann nicht versprechen, mich 
hier nie wieder zu zeigen, aber ich versuch's. ;-)

Was mich noch wundert, dass auch jetzt noch kein Template-File für den 
1527 in der Liste steckt, include-File sehr wohl .... was sie sich dabei 
wohl gedenkt haben ...

Gruß Micha

> zwar enorm gross

Fuer einen 16F1527 wuerde es schon reichen die richtigen Header
zu benutzen. Und nicht die von einem der nur so aehnlich klingt.

Ist doch eigentlich logisch. Selbst eine intelligente Amoebe
wuerde das hinkriegen.

Hallo an alle! Ich habe das grundsätzliche hinbekommen mit der richtigen 
MPLAB-Version.
(Zu Dir "AUWEIA":
Deine süffisante Kritik passt nicht ganz, denn ich habe ja zu diesem 
Zeitpunkt nur das HEX-File erstellt, und da ging es nur um den Ersatztyp 
1827. Aber egal, inhaltsreiche Antworten gibts ja hier auch.)

Jetzt hab ich ein reines Programmier- oder Einstellungsproblem, 
folgendes:

Ich möchte beispielsweise von PortB, der momentan so aussieht: 11100011
einfach das Pin 3 auch einschalten. Das geht auch mit BSF PORTB,3. 
Jedoch gehen dabei alle anderen, also der gesamt PortB gleich mit aus. 
Den Effekt kenne ich nicht. Was ist hier anders als bei früheren PIC's?

Ich dachte erst, dass der PIC-Simulator das falsch macht, aber in echt 
siehts genau so aus.
Irgendwie lässt sich kein Pin ein- oder ausschalten, ohne alle anderen 
Pins des betreffenden Ports auszuschalten.

Danke falls mir einer helfen kann! Micha

Nach weiteren nervigen Tests und Recherchen habe ich erkannt, dass es 
wohl das read modify write problem sein müsste, was dafür verantwortlich 
ist. mit anderen worten, früher (16F877 ...) war alles besser, denn da 
ging das problemlos mit dem Setzen einzelner Port-Pins sowie auch mit 
dem Lesen der Port-Pins bzw. des gesamten Ports. Hier bei dem 16F1527 
kann ich noch nicht mal den Port lesen, wenn er als Ausgang fungiert. 
Ich bewege LATB oder PORTB ins W und nichts kommt rein ins W, daran wird 
das liegen, wenn ich ein Pin einschalte, aber alle anderen dabei 
ausgehen, weil er den Port zwar ausliest, es aber eigentlich gar nicht 
tut und somit alle anderen außer dem gesetzten als AUS sieht. Gibt es da 
einen Haken, den ich noch nicht erkannt habe?

Michael schrieb:
> Ich bewege LATB oder PORTB ins W und nichts kommt rein ins W,

Was bedeutet "nichts"? Ich dachte immer ein Bit ist entweder 0 oder 1, 
"nichts" kommt da nicht vor.

MfG Klaus

Bei dem wenigem Code bleibt es bei einer Raterunde.

ANSELB gelöscht?

Und nach lesen des Dabla weißt du, r-m-w geht nur auf LATB ordentlich. 
Lass die Versuche mit PORTB gleich sein.

Programmierst du eigentlich mit einem Pickit oder exotisch?

Hallo!
Es funktioniert nur so (hier schalte ich der Riehe nach alle Pins von 
PortB ein):

  CLRF  SHADOWPORTB
  MOVFW  SHADOWPORTB
  MOVWF  LATB
  CALL  WARTE
  CALL  WARTE
  CALL  WARTE
  MOVLW  D'1'
  IORWF  SHADOWPORTB,F
  MOVFW  SHADOWPORTB
  MOVWF  LATB
  CALL  WARTE
  CALL  WARTE
  CALL  WARTE
  MOVLW  D'2'
  IORWF  SHADOWPORTB,F
  MOVFW  SHADOWPORTB
  MOVWF  LATB
  CALL  WARTE
  CALL  WARTE
  CALL  WARTE
  MOVLW  D'4'
  IORWF  SHADOWPORTB,F
  MOVFW  SHADOWPORTB
  MOVWF  LATB
  CALL  WARTE
  CALL  WARTE
  CALL  WARTE
  MOVLW  D'8'
  IORWF  SHADOWPORTB,F
  MOVFW  SHADOWPORTB
  MOVWF  LATB
  CALL  WARTE
  CALL  WARTE
  CALL  WARTE
  MOVLW  D'16'
  IORWF  SHADOWPORTB,F
  MOVFW  SHADOWPORTB
  MOVWF  LATB
  CALL  WARTE
  CALL  WARTE
  CALL  WARTE
  MOVLW  D'32'
  IORWF  SHADOWPORTB,F
  MOVFW  SHADOWPORTB
  MOVWF  LATB
  CALL  WARTE
  CALL  WARTE
  CALL  WARTE
  MOVFW  SHADOWPORTB
  CALL  WARTE
  CALL  WARTE
  CALL  WARTE

Ohne dieses "Schattenregister" geht es einfach nicht, da geht immer der 
zu setzende Eingang an aber die anderen alle aus am selben Port.
ANSELB war 0, ich habe auch nur das LATB versucht zu setzen, und den 
PORT zu lesen vorher statt des Schattenregisters, alles hat nichts 
gebracht. Da frag ich mich, was dieser Schwachsinn soll, wenn er solche 
Probleme macht??

Gleich ein neues Problem mit dem 1527, gleich vorher, es ist ein 
PIC16F1527 und nicht LF.
Über 3,5V bleibt er einfach stehen und lässt sich auch nicht 
programmieren, obwohl er lt. Datenblatt bis 5,5V verträgt und auch mit 
5V laufen müsste. Gitb es da etwa eine 
Konfigurationspflicht/möglichkeit, dass er mit 5V laufen soll??

Ach so, ich programmier das Ding mit PICKit3

neuer PIC Freund schrieb im Beitrag #6170559:
> Bei dem wenigem Code bleibt es bei einer Raterunde.

Zeig doch mal den kompletten Code, inklusive der Initialisierung.
Und ein Bild vom Aufbau wäre auch nicht schlecht.

Sonst können wir, wie neuer PIC Freund schon geschrieben hat, nur raten.

Gruß
John

Michael schrieb:
> ich habe auch nur das LATB versucht zu setzen

Machen wir mal weiter in dieser fröhlichen Raterunde:

Die Port-Regiser und die Latch-Register befinden sich in 
unterschiedlichen Speicherbänken.
Um auf die Latch-Register zuzugreifen muss vorher die entsprechende 
Speicherbank gewählt werden.

So werden die Pins von Port B der Reihe nach eingeschaltet:

1

    BANKSEL LATB        ;Bank 2 wählen

2

    BSF     LATB, 0

3

    CALL    WARTE

4

    BSF     LATB, 1

5

    CALL    WARTE

6

    BSF     LATB, 2

7

    CALL    WARTE

8

    BSF     LATB, 3

9

    CALL    WARTE

10

    BSF     LATB, 4

11

    CALL    WARTE

12

    BSF     LATB, 5

13

    CALL    WARTE

Gruß
John

> Ich dachte erst, dass der PIC-Simulator das falsch macht, aber in echt siehts 
genau so aus.

Das ist doch ein gutes Zeichen.

> Es funktioniert nur so

Und so

1

#include <stdint.h>

2

3

#include <xc.h>

4

5

void main(void) {

6

7

    ANSELB = 0;

8

    TRISB = 0;

9

    WPUB = 0;

10

11

    while (true)

12

    {

13

        uint_fast8_t i = 1;

14

        LATB = 0;

15

        while (i)

16

        {

17

            LATB |= i;

18

            _delay(5);

19

20

            i = (i << 1) & 0xFF;

21

        }

22

    }

23

24

    return;

25

}

Der compiler macht sogar das mit dem BANKSEL immer richtig. Die 
Befürchtung das selbiges auf 0 steht, habe ich auch.

Wenn du ein Pickit benutzt, warum dann nicht einfach mal Break und die 
Pins im IO-View toggeln?

Ratebeitrag:

CALL WARTE hat Seiteneffekte.

Genau so wie John es schreibt, selbstvertändlich sind PORTB und LATB 
nicht nicht in derselben Bank. Wenn man mit Assembler arbeitet, sollte 
das eigentlich klar sein.
Auch der 877 hatte verschiedene Banken für die SFR's.

Hallo an alle!
Danke für den Tipp mit den Banken hinsichtlich der LATB-Register, die ja 
in Bank 2 sind (DAS HÄTTE MIR NICHT PASSIEREN DÜRFEN), ich schäme mich, 
bin überlastet. :-) Das Problem sei geklärt. Weiteres (zum VCAP 
3,3/5V-Problem) evtl. später .... Nochmal vielen Dank!

So liebe Leute, ich bins mal wieder - leider :(
Gecheckt ist jetzt die 3,3V-Problematik, sie gabs gar nicht, PIC blieb 
stehen wegen Programmfehler - und der hält mich jetzt schon tagelang 
auf:

Vielleicht weiß da einer einen Rat. Es geht um I2C, so wie es bisher mit 
einem PIC16F877 und einem EEPROM immer funzte, hie rsoll aber ein 
PIC16F1527 als Master mit einem 877 als Slave reden. Leider geht noc 
nicht mal ein kleinster Anfang. Frage dazu:

Warum wird das SSP1IF-Flag nicht gesetzt (Deswegen bleibt er bei dieser 
Abfrage hängen). Ich habe alles mögliche probiert und gelesen, weiß nu 
echt nicht mehr weiter. Mann was für ein Drama mit diesen englishcen 
Beschreibungen. :)

Hier bleibt er hängen:
WAITMSSP        ; Warte bis SSPIF gesetzt ist
  BANKSEL  BANK2
  BSF  LATB,2
  BANKSEL  BANK0

  BANKSEL  BANK0
  BTFSS  PIR1,SSP1IF
  GOTO  $-1
  BCF  PIR1,SSP1IF
  RETURN

Code hängt mit an, paar LED-(Port)-Befehle zum erkennen, dass überhaupt 
was läuft, PWM's hier Nebensache, die gehen immerhin. :)

Danke für Eure Hilfe, wenn möglich!!