dsPIC33E SPI Probleme und Verständnis

[Florian T. (florian_t91)]

Morgen,

Nach einigem Lesen, Nachdenken und Ausprobieren, frag ich jetzt doch 
direkt nach. Hoffentlich kann mir einer helfen.

Es geht um einen dsPIC33EP 512MU810, der über SPI mit einem Sensor 
kommunizieren soll. Also Befehl senden und warten bis Daten empfangen 
(11bit).

Irgendwie klappt das nicht.

Meinen Code zur Initialisierung und der Anfrage hab ich angehängt, 
außerdem einen Ausschnitt aus dem Datenblatt des Sensors.

Dazu kommt noch, dass ich mir nicht sicher bin ob meine Taktfrequenz so 
stimmt:

PLLFBD = 38;
CLKDIVbits.PLLPOST = 0;
CLKDIVbits.PLLPRE = 0;
OSCTUN = 0;
RCONbits.SWDTEN = 0;
  
__builtin_write_OSCCONH( 0x03 );
__builtin_write_OSCCONL( 0x01 );

while( OSCCONbits.COSC != 0x03 );
while( OSCCONbits.LOCK != 1 );

Das sollte bei einer Quarzfrequenz von 8MHz zu einem FCY = 40MHz führen.
Mit den Prescalerwerten des SPI komm ich dann auf 500kHz.
Stimmt das, oder vertue ich mich?

Mit bitte um Hilfe
Flo

[Bronco (Gast)]

Wegen dem SPI:
Beim dsPIC33F war es so, daß das MSTEN-Bit als erstes gesetzt werden 
mußte, und erst danach durften die restlichen Konfigbits gesetzt werden.

SPI2CON1bits.MSTEN = 1;

Wegen Deinem Takt:
Du kannst ihn überprüfen, indem Du ihn mit einem Zähler in den 
1Hz-Bereich herunterteilst und eine LED blinken läßt. Alternativ mit dem 
Oszi, wenn Du eines hast ;)

[Florian T. (florian_t91)]

Ok danke schonmal, das Master enable versetzen hat leider nichts 
geändert.

Sitzt momentan mit dem Oszi dran. Lass mir Takt und MOSI anzeigen. Sieht 
eigentlich gut aus.
Nur die Taktfrequenz. So wie oben eingestellt kommt ein Takt von 5,7MHz 
raus ... also viel zu viel. Das verkraftet der Sensor nicht (max 
500kHz).

Wenn ich

SPI2CONbits.SPRE = 0b00;
SPI3Conbits.PPRE = 0b100;

setze sind es laut Datenblattrechnung 20kHz, laut Oszi 78kHz. 
Komischerweiße für

SPI2CONbits.SPRE = 0b00;
SPI3Conbits.PPRE = 0b000;

genauso 78kHz statt 80kHz. (OK passt fast).

Also liegt der erste Fehler irgendwo da.

Außerdem wird

LATGbits.LATG14 = 1;

nicht erreicht und SS bleibt auf '0'.

Daher vermute ich, das die while Schleife nicht verlassen wird.

Hab ein "Screenshot" des Oszi drangehängt. Gesendet werden soll: 0x11
Passt also. AUserdem sind es insgesamt 24 Taktflanken, was ja zu den 3 
Sendebytes passen würde.

[Florian T. (florian_t91)]

Hier noch ein MISO (oben) / MOSI (unten) Screenshot. Es kommen also auch 
Daten an.
Nur wird die while Schleife nicht verlassen.

[Hermann U. (Firma: www.pcb-devboards.de) (gera82)]

Florian T. schrieb:
> Hier noch ein MISO (oben) / MOSI (unten) Screenshot. Es kommen also auch
> Daten an.
> Nur wird die while Schleife nicht verlassen.

du erwartest doch die Daten von Sensor, oder nicht

ändere:
while( !SPI2STATbits.SPITBF );

in:
while( !SPI2STATbits.SPIRBF );

Gruß
Hermann

[Florian T. (florian_t91)]

Hm, dachte ich muss warten bis alle 3 Bytes gesendet wurden.

Bzw was ist der Unterschied Senden/Empfangen wenns doch nur 
Schieberegister sind.

Brachte jedenfalls leider nicht den gewünschten Erfolg, trotzdem danke.

Noch ein andere Frage:
Lässt sich aus dieser Schleife:

while( true ) {
  LATBbits.LATB2 = 1;
  LATBbits.LATB2 = 0;
}

und dem Wissen (Oszi), dass dafür 200ns gebraucht werden auf den 
Systemtakt (FCY) schliesen?

Flo

[Peter (Gast)]

Florian T. schrieb:
> Noch ein andere Frage:
> Lässt sich aus dieser Schleife:while( true ) {
>   LATBbits.LATB2 = 1;
>   LATBbits.LATB2 = 0;
> }
> und dem Wissen (Oszi), dass dafür 200ns gebraucht werden auf den
> Systemtakt (FCY) schliesen?

Nein aber aus dem Assembly bzw. Disassembly kann man es rauslesen.

[Maik W. (werner01)]

Was issn eig. mit dem Stackpointerlimitregister. Also in 
"ASM-programming" mußte man es vorher setzen damit der loslegen kann 
!?....

[Bronco (Gast)]

Florian T. schrieb:
> und dem Wissen (Oszi), dass dafür 200ns gebraucht werden auf den
> Systemtakt (FCY) schliesen?

Den Systemtakt bekommst Du raus, indem Du einen Timer laufen läßt und in 
der ISR einen PIN toggeln oder eine LED blinken läßt.

[Florian T. (florian_t91)]

Ja hatte ich mittlerweile so gemacht. Rechnerische Timerlaufzeit und 
gemessene stimmen überein. Also Systemtakt stimmt.


Maik Werner schrieb:
> Was issn eig. mit dem Stackpointerlimitregister. Also in
> "ASM-programming" mußte man es vorher setzen damit der loslegen kann
> !?....

Versteh ich nicht was du mir damit sagen willst. Hab von Assembler nicht 
viel Ahnung.

Leider hängt er sich immernoch auf, also vermutlich in der while 
Schleife.
Andere Möglichkeit das zu umgehen? Per Interrupt den Receive abwarten?

Flo