PIC C18 und Microchip C18 Toolsuite

Gast #607826
Lesenswert?

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
#607848
Lesenswert?

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
#607856
Lesenswert?

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
#607884
Lesenswert?

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

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren