PIC C18 und Microchip C18 Toolsuite

[Roland (Gast)]

Hallo zusammen,

Ich  programmiere schon ne Zeit lang 8051 Controller und das klappt 
alles soweit ganz gut. Aus gegebenen Anlass soll ich nun aber fuer ein 
Projekt auf der Arbeit einen PIC18 Controller programmieren.

PIC18F2680,  PICDEM 2 PLUS Demo Board, MPLAP ICD2, MPLAB IDE v7.6 und 
die Microchip C18 Toolsuite stehen mir zu Verfuegung. Hab mich die 
letzten beiden Tage da mal ein reingelesen und hab wieder ganz von vorne 
anfangen. Hab erstmal das Tutorial MPLAB C18 getting strated 
durchgearbeitet, hat auch alles trotz anderem Controller geklappt.

Nun zu meinem Problem, wenn ich ganz einfach ne einzelnen Port (LED) 
ansprechen will, dann weise ich den Ports doch wie folgt Variablen zu, 
oder?

#define power    PORTBbits.RB0
#define status    PORTBbits.RB1

#pragma config WDT = OFF

Wenn ich nun als erstes den Ausgang RB0 anspreche und darauf den Ausgang 
RB1, dann erlischt bei mir immer die LED an RB0, woran liegt das? Ich 
schreibe doch nur auf den einen Ausgang und nicht auf den ganzen Port, 
oder?

Beispiel:

void main (void)
{
TRISB = 0x00;              //PORTB als Output setzen
power=1;                   //LED0 ON RB0

while (1)
    {
    status=1;              //LED1 ON RB1
    }
}


Gruss Roland

[Peter D. (peda)]

Im Unterschied zum 8051 erfolgen die Read-Modify-Write Befehle beim PIC 
nicht in einem Zyklus, sondern überlappend.

Ehe also der erste RMW-Befehl das Byte zurück geschrieben hat, kann der 
nächste noch den alten Zustand lesen und damit geht der erste Befehl 
flöten.

Zwischen 2 RMW-Befehlen auf das selbe Byte muß daher immer noch ein NOP 
gesetzt werden.


Peter

[Willivonbienemaya .. (willivonbienemaya)]

> #define power    PORTBbits.RB0
> #define status    PORTBbits.RB1
>

änder das mal in:
#define power    LATBbits.LATB0
#define status    LATBbits.LATB1

und versuchs noch mal.

[Severino R. (severino)]

Peter Dannegger wrote:
> Im Unterschied zum 8051 erfolgen die Read-Modify-Write Befehle beim PIC
> nicht in einem Zyklus, sondern überlappend.
>
> Ehe also der erste RMW-Befehl das Byte zurück geschrieben hat, kann der
> nächste noch den alten Zustand lesen und damit geht der erste Befehl
> flöten.
>
> Zwischen 2 RMW-Befehlen auf das selbe Byte muß daher immer noch ein NOP
> gesetzt werden.
>
>
> Peter

Hääää?

Meines Wissens ist es so, dass ein Port am Anfang des Befehlszyklus 
gelesen, aber am Ende des Zyklus geschrieben wird.
Somit ist u.U. der Ausgangspegel noch gar nicht stabil anliegend, wenn 
in der nächsten Instruktion das Port gelesen wird.

Aber es geschieht nichts überlappend.

Hingegen liegt ein Problem darin, dass bei einem RMW-Zugriff auf ein 
PORT nicht das Output-Latch gelesen wird, sondern die Pins.
In den PIC18 wurde das behoben durch die LAT-Register. Diese lesen das 
Latch.

@Roland:

Willivonbienemaya liegt richtig.

Warum, kannst Du hier nachlesen:
http://www.sprut.de/electronic/pic/fallen/fallen.html#inout

Severino

[Peter D. (peda)]

Severino R. wrote:

> In den PIC18 wurde das behoben durch die LAT-Register. Diese lesen das
> Latch.

Ich kenne mich da nicht so aus, welcher Bug nun in welchem PIC present 
oder behoben ist.
Ein NOP hilft jedenfalls immer.


Peter

[Severino R. (severino)]

Peter Dannegger wrote:
> Severino R. wrote:
>
>> In den PIC18 wurde das behoben durch die LAT-Register. Diese lesen das
>> Latch.
>
> Ich kenne mich da nicht so aus, welcher Bug nun in welchem PIC present
> oder behoben ist.
> Ein NOP hilft jedenfalls immer.
>
>
> Peter

Es handelt sich um eine Design-Eigenschaft, nicht um einen Bug. Deshalb 
wurde der "Bug" in den PIC16 auch nie behoben, weils eben keiner ist. 
Das Ding verhält sich halt so, dass ein Port lesen immer vom Input-Pin 
liest, und nicht vom Output-Latch.

Ob in diesem Fall ein NOP hilft, müsste Roland ausprobieren.
Schaden wird's sicher nicht.

Severino

[Willivonbienemaya .. (willivonbienemaya)]

Doch es schadet. Es verbrät unnötig Zeit.
Macht man es einfach richtig, mit der Benutzung der LAT Register bei 
Ausgaben, ist alles ok.

[Uwe (Gast)]

>Es handelt sich um eine Design-Eigenschaft, nicht um einen Bug.

LOL einigen wir uns auf ein blödsinniges Feature.

[Roland (Gast)]

Boah, soviel antworten...

Danke, hab aber schon Feierabend, hab nämlich +6 Stunden 
Zeitverschiebung, werd es dann morgen früh direkt ausprobieren...

Danke!

[Roland (Gast)]

Es klappt, mit:

#define power    LATBbits.LATB0
#define status    LATBbits.LATB1


DANKE!!