zublöd für Hardware SPI?

[Christian P. (peterfrosta)]

Hallo,


es kann eigentlich nur ein ziemlich doofer Fehler sein aber ich habe 
keine Ahnung.
Hatte bisher immer Soft-SPI verwendet. Für das Arbeiten mit einer 
SD-Karte ist mir das aber zu langsam.

Also Hardware SPI. Leider kommt nichts auf dem Bus an. Habe nun mit den 
wenigen, nötigen Codezeilen experimentiert. Ohne Erfolg. Die 
Verbindungen sind Ok, da die SOft-SPI mit dieser Hardware problemlos 
funktioniert.

bei:  SPDR = XXXX;   bleibt das Programm stehen?!

Mit dem Logikanalyser sieht man, dass lediglich Chipselect/Slaveselect 
auf LOW geht. Mehr passiert nicht.

PS: der angehängte Code ist vermutlich nicht sauber formatiert. Habe zig 
Beispiele versucht und aufräumen wollte ich dann erst, wenn endlich der 
Bus "fährt"

vielen dank für alle Mühen

[Fred (Gast)]

The AVR’s SPI module is designed so that if the SS pin is an input and 
it reads low (0 V), then the SPI module will automatically go in to 
slave mode (the MSTR bit in SPCR will become zero) and all SPI 
transmission functions in this library will return a result of zero. 
Therefore, it is recommended to make SS an output before doing SPI 
master communication. If SS is an input, then the SPI initialization 
routine in this library will enable the pull-up resistor on that line.

quelle: http://www.pololu.com/docs/0J18/12

[(prx) A. K. (prx)]

Welcher Controller? Die Pins von SPI stimmen? Bei den mir bekannten 
Typen mit PORTH liegen die nämlich woanders.

[Kaj (Gast)]

Christian P. schrieb:
> Habe zig
> Beispiele versucht
Hast du auch mal das Beispiel aus dem Datenblatt deines Controllers 
probiert? Bei den Atmel Controllern sind immer Code-Beispiele dabei, 
sowohl in ASM als auch in C, und die Funktionieren auch!

A. K. schrieb:
> Bei den mir bekannten
> Typen mit PORTH liegen die nämlich woanders
Stimmt. Hab auch grade mal geschaut: Beim Mega2560 z.B. hat PortH nichts 
mit SPI zu tun. Da liegen die SPI-Pins auf PortB(PB0 - PB3)

void SPI_MasterInit(void) {

  DDRB = (1<<PB4)|(1<<PB5)|(1<<PB7);      // set PB4(SS), PB5 (MOSI) and PB7 (SCK) output, all others input
  
  PORTB |= (1 << PB7)|(1 << PB4);
  
  DDRH = (1<<PH5)|(1<<PH6);
  PORTH &= ~(1<<PH5);
  PORTH |=(1<<PH6);
  
  SPCR = 0x52;           // enable SPI, Master, set clock rate fck/16
}

Warum auch immer was mit PortB und PortH gemacht wird...
Die Verwendung von PB4 bis PB7 als SPI-Pins passt besser auf einen 
Mega1284P (und die anderen Controller die da im Datenblatt noch stehen) 
oder einen Mega32, diese haben aber wiederum kein PortH.

void transmit(unsigned char addr, char data) {
  
  SPDR = addr;
  ...

Versteh ich auch nicht so ganz. SPI hat nichts, aber auch gar nichts mit 
Adressen zu tun...

Also irgendwie passen Code und Hardware nicht so ganz zusammen.

Fred schrieb:
> quelle: http://www.pololu.com/docs/0J18/12
Da brauch man nur mal in das Datenblatt des Controllers zu schauen. Da 
steht alles drin. ;)

[(prx) A. K. (prx)]

Kaj schrieb:
> Stimmt. Hab auch grade mal geschaut: Beim Mega2560 z.B. hat PortH nichts
> mit SPI zu tun.

Muss er auch nicht. CS vom SPI-Slave muss nicht an SS hängen.

> Versteh ich auch nicht so ganz. SPI hat nichts, aber auch gar nichts mit
> Adressen zu tun...

Das dürfte mit dem Protokoll vom SPI-Slave zusammenhängen. Das erste 
Byte der SPI-Daten ist nicht selten eine Registeradresse im Slave.

Er hat vermutlich ein Beispiel vom Mega16&Co genommen und ohne Prüfung 
auf einem anderen Controller verwendet. Dumm gelaufen. Wenn die Platine 
schon fertig ist, dann wirds nun wohl wieder Software-SPI. ;-)

[Christian P. (peterfrosta)]

so hallo zusammen,

hatte leider die Emailbenachrichtigung nicht aktiviert :-/

Also zu den fragen:

Ich nutze PH5 als schalter für den SD Karten Strom ( über transistor.)
PH6 ist mein das !SS für die SD Karte.
Habe auf dem Board noch weitere SPI Geräte, daher hat jeder einen 
eigenen !SS und die SD karte hat halt PH6.
Aber das hatte A.K. ja richtig bemerkt.

Ich wollte erwähnt haben, dass ich verschiedene Projekte ausm netzt 
schon kopiert hab, da keins lief.
 Natürlich habe ich per Defines  meine SPI Ports angegben.
MOSI, MISO, und CLK sind auch die vom Atmega vorgesehenen und wie im 
Code auch definiert.... und da ist schon mal ein Fehler.

Genau bei diesem, euch geposteten Code ist es nämlich nicht richtig 
definiert (PB0,PB1,PB2)!! ich idiot Es war wohl zu spät morgens.

ich werde später erst dies korrigieren und hoffe dass es dann 
funktioniert.
Ich werde berichten.

Danke schon mal!


hinzugefügt:

ABER... überschreibt der Atemga nicht die benötigten PortPins wenn man 
im SPCR, SPE auf 1 setzt (Spi Enable)??

[(prx) A. K. (prx)]

Christian P. schrieb:
> ABER... überschreibt der Atemga nicht die benötigten PortPins wenn man
> im SPCR, SPE auf 1 setzt (Spi Enable)??

Nicht SS. Und wenn das auf Input steht, weil die Portdefinition die 
falschen Pins kontrolliert, dann greift das von Fred zitierte Problem 
für SS=0.

Ausserdem musst du natürlich schon die richtigen Pins verdrahten. ;-)

[Christian P. (peterfrosta)]

Freds kommentar hatte ich irgendwie übersehen...
gut dass du das noch einmal erwähntest!

im eigentlich projekt, waren die Ports nämlich stets richtig und zig mal 
kontrolliert.

Es war der !SS-Pin der Hardware SPI....
Nach dem diser als Ausgang initialisiert wurde, kam auch der Bus :-)

Als Info: Am PB0 (!SS) hängt der !Reset eines I/Expanders (MCP23S08) 
warum diser !SS auf LOW ziehen sollte, ist mir nicht klar. Wie dem auch 
sei...

Danke vielmals :-)

[(prx) A. K. (prx)]

Christian P. schrieb:
> Als Info: Am PB0 (!SS) hängt der !Reset eines I/Expanders (MCP23S08)
> warum diser !SS auf LOW ziehen sollte, ist mir nicht klar. Wie dem auch
> sei...

Am floatendem Pin - weil Input auf Input - ist alles drin.

[Kaj (Gast)]

A. K. schrieb:
>> Versteh ich auch nicht so ganz. SPI hat nichts, aber auch gar nichts mit
>> Adressen zu tun...
>
> Das dürfte mit dem Protokoll vom SPI-Slave zusammenhängen. Das erste
> Byte der SPI-Daten ist nicht selten eine Registeradresse im Slave.
Ok, Asche auf mein Haupt. Ich hatte bisher nur Schieberegister als 
SPI-Slaves :D

A. K. schrieb:
> Kaj schrieb:
>> Stimmt. Hab auch grade mal geschaut: Beim Mega2560 z.B. hat PortH nichts
>> mit SPI zu tun.
>
> Muss er auch nicht. CS vom SPI-Slave muss nicht an SS hängen.
Dat stimmt schon, macht aber (meiner Meinung nach) Sinn, den CS an SS zu 
haengen, wenn man Hardware-SPI verwendet :P

[Peter D. (peda)]

Wenns schnell sein soll, nimmt man besser eine der UARTs als SPI-Master. 
Die sind gepuffert, d.h. es entfallen die Pausen zwischen den Bytes.

[Christian P. (peterfrosta)]

Kaj schrieb:
> Dat stimmt schon, macht aber (meiner Meinung nach) Sinn, den CS an SS zu
> haengen, wenn man Hardware-SPI verwendet :P

Christian P. schrieb:
> Habe auf dem Board noch weitere SPI Geräte...

davon nutzt eines natürlich auch den atmega hardware !SS ;)

Peter Dannegger schrieb:
> Wenns schnell sein soll, nimmt man besser eine der UARTs als SPI-Master.
> Die sind gepuffert, d.h. es entfallen die Pausen zwischen den Bytes.

interessant!

A. K. schrieb:
> Am floatendem Pin - weil Input auf Input - ist alles drin.

Danke!

[MCUA (Gast)]

>> Wenns schnell sein soll, nimmt man besser eine der UARTs als SPI-Master.
>> Die sind gepuffert, d.h. es entfallen die Pausen zwischen den Bytes.
>interessant!
aber nur im MasterMode, nicht im Slave-Mode.