PIC16F1783 - Problem mit Delayfunktion

[Michael F. (osiris2442)]

Hallo,

Ich programmiere seit längerem PIC Mikrocontroller und seit kurzem auch 
den Typ 16F1783.

Ich habe nun folgendes Problem.
Das Programm sollte nur ein Rechtecksignal an PortB ausgeben,
und dafür habe ich eine kleine Delayfunktion geschrieben:

#include <pic14/pic16f1783.h>

unsigned int __at (_CONFIG1) __CONFIG1 = _FOSC_INTOSC & _WDTE_OFF & _MCLRE_OFF & _CP_OFF & _CLKOUTEN_OFF;
unsigned int __at (_CONFIG2) __CONFIG2 = _PLLEN_ON & _LVP_OFF;

void delay(void)
{
    __asm

    cblock
    d1
    d2
    endc

    //ca 8000 Zyklen:
    movlw 0x3F
    movwf d1
    movlw 0x07
    movwf d2

    decfsz d1,1
    goto $+2
    decfsz d2,1
    goto $-3

    __endasm;
}

void main(void)
{
    OSCCON=0xF8; // INTOSC

    TRISB=0x00;
    LATB=0x00;

    while(1)
    {
        LATB=~LATB;
        delay();
    }
}

Wenn ich das Programm jedoch in den PIC brenne, ist PORTB auf 0xFF und 
es ändert sich nichts. Es scheint als würde das Programm in der 
Delayfunktion hängen bleiben.
Wenn ich jedoch das Programm geringfügig ändere und die zweite Schleife 
in ASM entferne:

#include <pic14/pic16f1783.h>

unsigned int __at (_CONFIG1) __CONFIG1 = _FOSC_INTOSC & _WDTE_OFF & _MCLRE_OFF & _CP_OFF & _CLKOUTEN_OFF;
unsigned int __at (_CONFIG2) __CONFIG2 = _PLLEN_ON & _LVP_OFF;

void delay(void)
{
    __asm

    cblock
    d1
    d2
    endc

    movlw 0x3F
    movwf d1
    movlw 0x07
    movwf d2

    decfsz d1,1
    goto $-1

    __endasm;
}

void main(void)
{
    OSCCON=0xF8; // INTOSC

    TRISB=0x00;
    LATB=0x00;

    while(1)
    {
        LATB=~LATB;
        delay();
    }
}

funktioniert das Programm problemlos und es entsteht eine 
Rechteckfrequenz an PORTB. (Weiters kann ich auch sicherstellen dass der 
uC mit dem internen Oszillator von 32MHz läuft)

Ich weiss jedoch nicht wo der Fehler in der Delayfunktion liegt, da 
dieselbe Funktion problemlos bei anderen Typen funktioniert.
Weiters habe ich das Programm an mehreren 16F1783 getestet, und 
dasgleiche Ergebnis bekommen.
Hoffe ihr könnt mir helfen.

Zur Info:
Compiler: sdcc v3.2
Brennter: sprut Brenner8 v0.17

mfg

[Route_66 (Gast)]

Michael Fraller schrieb:
> goto $+2

Geht dieser Sprung nicht in die falsche Richtung?

[Michael F. (osiris2442)]

decfsz d1,1
goto $+2
decfsz d2,1
goto $-3

naja er springt dann zu

goto $-3

und anschliessend ist er wieder am Anfang.
Dieser Sprung dient nur dazu dass man die Anzahl der Zyklen
einfacher abschätzen kann.

Hab den ASM Code eig von einem Code-Generator für Delay-Routinen.

http://www.piclist.com/techref/piclist/codegen/delay.htm

[Teo D. (teoderix)]

Michael Fraller schrieb:
> __asm
>
>     cblock
>     d1
>     d2
>     endc

Funst das überhaupt bei inline assembler Code?

[Michael F. (osiris2442)]

hm, hatte bis jetzt eig keine Probleme damit...

Habe jedoch als Versuch die 2 Programme in ASM geschrieben und
mit MPLAB compiliert und kam zum gleichen Ergebnis.

Aber vielen Dank für deine Antwort ;)

mfg

Edit:
Könnte vl jemand der ebenfals den uC-Typ programmiert
das Programm compilieren/testen und das HEX-File vl uploadn?
Könnte nämlich sein das beim Brennen was schief geht.
Wäre echt dankbar.

[Teo (Gast)]

Michael Fraller schrieb:
> Habe jedoch als Versuch die 2 Programme in ASM geschrieben und
> mit MPLAB compiliert und kam zum gleichen Ergebnis.

Jo, ich frag mich nur ob der C-compiler die Speicherbelegung auch 
wirklich sieht?!

Michael Fraller schrieb:
> goto $+2

Auch wenn ich da keinen Fehler sehe, mach mal Labels. Is zumindest 
leserlicher und wer weiß :)

[Michael F. (osiris2442)]

Problem gelöst!

Es ist wie Teo anfangs vermutet hat, dass cblock Probleme macht.
cblock funktioniert anscheinend weder in C noch in ASM.
Hab nun die Variablen anders deklariert und es gab keine Probleme.

Vielen Dank für eure Hilfe, ganz besonders Teo :)

mfg

[Teo (Gast)]

In ASM sollte es aber eigentlich keine Probleme machen?!


    cblock 0x20

was ich noch übersehen hatte, alles vorher is reserviert! (Datenblatt! 
kenn Deinen Typ nich wirklich)