SPI mit Atmega32

[Markus (Gast)]

Hallo

Ich möchte mich mal ans SPI Modul des Atmega32 wagen (den Magnet Encoder 
AS5040 auslesen), hab dazu aber noch Unklarheiten.

- Gemäss Atmel Datenblatt ist das SPI Modul full-duplex, was bedeutet, 
dass ich auf einen Slave gleichzeitig (über die MOSI Leitung) schreiben 
und davon (über die MISO Leitung) lesen kann. Auslesen des SPI Data 
Register – SPDR ".. causes the Shift Register Receive buffer to be 
read". Wenn ich das richtig verstehe, aktiviert also ein Lesezugriff auf 
das SPDR den SPI Clock. Aber dann würde zum Zeitpunkt des SPDR-Zugriffs 
(Auslösung des SPI Clocks) die Daten ja erst übertragen. Muss ich daher 
zwei Mal auf das SPDR zugreifen um die gewünschten Daten zu erhalten?

- Zudem verstehe ich den Code-Schnipsel (in diesem Beispiel ist der uC 
jedoch als Slave konfiguriert) aus dem Datenblatt von Atmel 
(http://www.atmel.com/images/atmel-8155-8-bit-microcontroller-avr-atmega32a_datasheet.pdf, 
S. 183) nicht:

void SPI_SlaveInit(void)
{
   /* Set MISO output, all others input */
   DDR_SPI = (1<<DD_MISO);
   /* Enable SPI */
   SPCR = (1<<SPE);
}
char SPI_SlaveReceive(void)
{
   /* Wait for reception complete */
   while(!(SPSR & (1<<SPIF)))
      ;
   /* Return Data Register */
   return SPDR;
}

Mit SPI_SlaveReceive() setze ich meinen uC doch in eine Endlosschleife, 
wenn er nichts empfängt!?!

- Des Weitern sehe ich ein Problem mit dem Timing des AS5040 (ist 
angehängt) bzw. der Clock Phase des uC. Nachdem ich den ChipSelect 
aktiviere (activ low) möchte ich doch eigentlich mein erstes Bit (D9) 
bei der 2. fallenden und nicht schon bei der 1. steigenden Clock Flanke 
auslesen, da mein Slave noch min T_Do_valid Zeit braucht um das Bit 
korrekt herauszugeben. Slave-Bit 1 bei 2. Clock gäbe doch ein völliges 
Durcheinander und ist mit Hilfe von Clock Phase und Clock Polarity auch 
nicht zu erreichen.

Danke für die Hilfe!

[Helfer (Gast)]

Markus schrieb:
> Wenn ich das richtig verstehe, aktiviert also ein Lesezugriff auf
> das SPDR den SPI Clock.

nein, sondern ein Schreibzugriff auf das SPDR des Masters

Markus schrieb:
> Mit SPI_SlaveReceive() setze ich meinen uC doch in eine Endlosschleife,
> wenn er nichts empfängt!?!

ja, so ist es.


http://www.koervernet.de/component/phocadownload/file/5-as5040-library-fuer-atmega

[Peter (mesosce)]

Hallo,

ich versuche schon mehrere Tage, eine Porterweiterung mit einemMCP23S17 
zu machen. Die Ausgabe auf Port A klappt, nur das Einlesen bekomme ich 
nicht hin. Ich habe schon alle möglichen Unterlagen durchgesehen, komme 
aber nicht weiter. In der angehängten Datei ist oben die eigentliche 
serielle AUS-/Eingabe, darunter die Initialisierung des MCP. Zum Schluss 
zuerst die Ausgabe an Port A, dort klappt das Rücklesen auch nicht. 
Darunter ein Versuch mit nur zwei Byte am Port B, da kommt auch nichts 
raus. Egal ob ich OP-code $40 oder $41 verwende. Das DB des MCP ist da 
auch nicht sehr hilfreich.
Ich würde mich über Hinweise sehr freuen.

viele Grüße

Peter

[Paul B. (paule201)]

Das Thema ist 8 Jahre alt, mach ein Neues auf.

Kleinere Codestücke bindest du direkt ein, wie es unter "Formatierung" 
ein paar Zeilen weiten oben beschreiben ist.

 
int test = 42;

Größere Codeabschnitte kannst du direkt anhängen, ohne ihn vorher ins 
Word zu kopieren.

Dann schreib bitte noch dazu welchen Controller du hast, welche IDE und 
im Idealfall noch einen Schaltplan und ein Bild vom Aufbau. Dann ist 
dieses Standard Problem sicher in 20min gelöst.

[Wastl (hartundweichware)]

Peter schrieb:
> SPI_Test_mit_MCP23S17.rtf (2 KB)

Peter schrieb:
> Ich würde mich über Hinweise sehr freuen.

Sende deine Anhänge im richtigen Format. In deinem Fall
wären das *.c Files.

[Roland F. (rhf)]

Hallo,
Wastl schrieb:
> In deinem Fall wären das *.c Files.

Ich kann ich ja irren, aber die rtf-Datei sieht mir jetzt mehr wie ein 
Pascal-Quelltext aus.

rhf

[Wastl (hartundweichware)]

Roland F. schrieb:
> Ich kann ich ja irren, aber die rtf-Datei sieht mir jetzt mehr wie ein
> Pascal-Quelltext aus.

Stimmt! So genau habe ich gar nicht hingeschaut.

Seltsamerweise zeigt sein Code-Schnipsel C-Code.

[Wastl (hartundweichware)]

Roland F. schrieb:
> die rtf-Datei sieht mir jetzt mehr wie ein Pascal-Quelltext aus.

*.rtf wird für einen Pascal-Compiler auch nicht sehr passend sein.

[Falk B. (falk)]

Wastl schrieb:
>> Ich kann ich ja irren, aber die rtf-Datei sieht mir jetzt mehr wie ein
>> Pascal-Quelltext aus.
>
> Stimmt! So genau habe ich gar nicht hingeschaut.
>
> Seltsamerweise zeigt sein Code-Schnipsel C-Code.

Ist doch klar, in Pascal steckt auch ein kleines c! ;-)

[S. L. (sldt)]

Die Funktionsweise von SPI scheint nicht verstanden zu sein - 
"Einleseversuch" mit " len:=2;" kann nicht funktionieren.

Aus dem Datenblatt:
1.3.3.2 SPI Read Operation
The SPI read operation is started by lowering CS. The SPI read command 
(slave address with R/W bit set) is then clocked into the device. The 
opcode is followed by an address, with at least one data byte being 
clocked out of the device.

Das Einlesen von B vereinfacht formuliert:

SPI_out:= $41
SPI_out:= $13
SPI_out:= irgendetwas
B_Wert:= SPDR

PS:
zum Verständnis: 'clocked' kann ja nur vom uC erfolgen, er liefert den 
Takt.

[Rainer W. (rawi)]

Peter schrieb:
> Zum Schluss zuerst die Ausgabe an Port A, dort klappt das Rücklesen
> auch nicht.

Bei SPI tauschen Master und Slave Bytes aus, d.h. während der Master 
über MOSI sendet, empfängt er über MISO. Nimm dir einen Logikanalysator 
und guck dir die Signale auf dem Bus an (inkl. Decoder).
Erst die Software entscheidet, was mit den ausgetauschten Bytes 
passiert, aber auf dem Bus gibt es keine Trennung zwischen schreiben und 
lesen.

[Peter (mesosce)]

Hallo,

der Hinweis auf das Dummy-Byte war sehr hilfreich. Die eigentliche 
Ursache war aber, dass ich zwischen den einzelnen 3-Byte Ausgaben das 
/CS nicht jeweils kurz auf H gelegt habe.
Ich bedanke mich noch einmal für die Hilfe.

Grüße
Peter