SPI Schnittstelle, Problem mit Datenausgabe

[Martin (Gast)]

Hallo
ich hätte eine Frage zu der SPI Schnittstelle. Das Problem ist, dass auf 
der Datenleitung nur die letzten 8bit ausgegeben werden, d.h. bei 0xffff 
gibt er nur 0x00ff aus. Obwohl ich die 16bit eingestellt habe.
Bei dem Bild ist die blaue Spur der CLK, die rote Spur ist das 
gewünschte Signal und die grüne Spur ist das Signal, dass ich 
tatsächlich erhalte.

Ich verwende den dsPIC33FJ256MC710A, den PCD Compailer con CCS, und das 
dsPICDEM MCLV Board.

#include <33FJ256MC710A.h>
#include <stdio.h>
#include <stdlib.h>
#fuses XT,PR_PLL, NOWDT
#use delay (crystal=8M,clock=80M)
#use SPI(DI=PIN_F7, DO=PIN_F8,CLK=PIN_F6,bits=16)

void main()
{
    set_tris_f(0);
    set_tris_e(0);
    setup_spi(SPI_MASTER |SPI_MODE_16B| SPI_CLK_DIV_7 |SPI_L_TO_H);
    while(1)
    {
        spi_write(0xffff);
        delay_us(3);
    }
}

mfg

[Kris M. (kristijan_m)]

Schreib das 0xffff mal in eine uint16 variable und schreib dann



spi_write(variable);

[Martin (Gast)]

PS: den Code den ich ausgebe ist nicht 0xffff, sondern 0xaaaa.


@Kris M.
Daran liegt es nicht, ist das gleiche Signal wie zuvor.

[Kris M. (kristijan_m)]

Was passiert wenn du nur 8 bit ausgibst? Probier mal bitte aus. Ich 
denke derweil nach :D

[Martin (Gast)]

Ich habe es gerade auprobiert und es gibt mir wieder nur die letzten 
8bit aus.

[Kris M. (kristijan_m)]

ah ok ich denke ich hab da was gefunden.

Ich kenn mich mit PIC nicht so gut aus, aber das sollte allgemein gültig 
sein.


versuch mal sowas hier (ich achte mal nicht auf syntex^^)

#include <33FJ256MC710A.h>
#include <stdio.h>
#include <stdlib.h>
#fuses XT,PR_PLL, NOWDT
#use delay (crystal=8M,clock=80M)
#use SPI(DI=PIN_F7, DO=PIN_F8,CLK=PIN_F6,bits=16)


main()
{
spi(uint16_t byte)
}//main ende

uint16_t spi(uint16_t byte)
{
byte= 0xaaaa

set_tris_f(0);
    set_tris_e(0);
    setup_spi(SPI_MASTER |SPI_MODE_16B| SPI_CLK_DIV_7 |SPI_L_TO_H);
    while(1)
    {
        spi_write(byte);
        delay_us(3);
    }
}//spi ende

[Chris B. (dekatz)]

Setze nach der Initialisierung mit "setup_spi(SPI_MASTER |SPI_MODE_16B| 
SPI_CLK_DIV_7 |SPI_L_TO_H);" nochmal die SPI-Schnittstelle auf 16 Bit 
mit: SPI1CON1.MODE16 = 1; (oder wie das beim CCS gemacht wird).
(wäre ja nicht die erste fehlerhaft Lib eines Compilers)

[Rufus Τ. F. (rufus)]

Wie sieht denn der Prototyp der Funktion spi_write aus?

[Martin (Gast)]

Das mit dem SPIxCON1 Register setzten funktioniert auch nicht...

[Kris M. (kristijan_m)]

Rufus Τ. Firefly schrieb:
> Wie sieht denn der Prototyp der Funktion spi_write aus?

jo also wenn das geschriebene bis jetzt nicht funktioniert hat, würde 
ich auch mal in der funktion spi_write() nachschauen...

wenn da ne 8bit variable irgendwo übergeben wird, kannst du vorher 
modelieren was du willst

[Kris M. (kristijan_m)]

Stehen bei deinem Compiler irgendwelche Warnungen?
Viele Leute reagieren nur bei Fehlern auf Compiler Meldungen ;)

Auch die Warnungen bedeuten was...

Ps. du kannst deinen Compiler auf empfindlich stellen. Somit bringt er 
dir mehr Warnungen. Ist oftmals die beste Lösung bei nicht 100% 
funktionierendem Code

[Chris B. (dekatz)]

Also der dsPIC33 ist ein 16-Bit Kontroller und dessen FSR sind alle 16 
Bit Breit - da will ich doch hoffen das da keine 8-Bit-"Dinger" 
übergeben werden. Wenn doch, dann Compiler in die Tonne!

[Karl H. (kbuchegg)]

Aus der Doku

spi_write( ) spi_write2( )
Syntax: spi_write([wait],value);
       spi_write2([wait],value);

Parameters: value is an 8 bit int
            wait- an optional parameter specifying whether the
           function will wait for the SPI transfer to complete
           before exiting. Default is TRUE if not specified.

Returns: Nothing

Function: Sends a byte out the SPI interface. This will cause 8
         clocks to be generated. This function will write the value

....


Also See: spi_read(), spi_data_is_in(), SPI Overview,
          spi_write_16(), spi_read_16()

manchmal ist es eben doch nicht verkehrt, mal einen Blick in die Doku zu 
werfen und nicht einfach irgendwas anzunehmen

https://www.ccsinfo.com/downloads/PCDReferenceManual.pdf

[Kris M. (kristijan_m)]

;)

[Justus S. (jussa)]

Chris B. schrieb:
> Also der dsPIC33 ist ein 16-Bit Kontroller und dessen FSR sind alle 16
> Bit Breit -

und alle möglichen an SPI anschliessbaren "Gegenstücke" arbeiten 
natürlich auch auf 16-Bit-Basis...

[Chris B. (dekatz)]

Justus Skorps schrieb:
> Chris B. schrieb:
>> Also der dsPIC33 ist ein 16-Bit Kontroller und dessen FSR sind alle 16
>> Bit Breit -
>
> und alle möglichen an SPI anschliessbaren "Gegenstücke" arbeiten
> natürlich auch auf 16-Bit-Basis...

Nein, aber wenn ich schon auf 16-Bit-Mode stelle dann wird das 
hoffenlich auch einen Grund haben - oder etwa nicht?

[Karl H. (kbuchegg)]

Chris B. schrieb:
> Justus Skorps schrieb:
>> Chris B. schrieb:
>>> Also der dsPIC33 ist ein 16-Bit Kontroller und dessen FSR sind alle 16
>>> Bit Breit -
>>
>> und alle möglichen an SPI anschliessbaren "Gegenstücke" arbeiten
>> natürlich auch auf 16-Bit-Basis...
>
> Nein, aber wenn ich schon auf 16-Bit-Mode stelle dann wird das
> hoffenlich auch einen Grund haben - oder etwa nicht?

Schon.
Es hat aber auch einen Grund, warum die spi_write Funktion das einen 
feuchten Kehrricht interessiert.
Schliesslich benutzt man einen DSPic um einen auf Speed zu machen. Dem 
widersprucht es ein bischen, wenn spi_write jedesmal wieder neu 
analysiert, ob du den SPI auf 16 Bit geschaltet hast. Soweit kann man 
das einem Entwickler schon zumuten, dass er in so einem Fall dann eben 
nicht spi_write sondern spi_write_16 benutzt.