SPI-Kommunikation ATTiny45 --> ATTiny45?

In Bascom mach ich selber nichts. Aber solltest du nicht Bei dem Slave 
die Ausgänge als Eingänge un die Eingänge als Ausgänge machen? Du hast 
es doch sogar als Kommentar hinten gemacht.

The SphereX schrieb:
> Config Portb.2 = Output                     ' USCK ----> SCK (Slave)
> Config Portb.1 = Output                     ' DO   ----> SDI (Slave)
> Config Portb.0 = Input                      ' DI   ----> SDO (Slave)

@ m-obi

" ... Aber solltest du nicht Bei dem Slave die Ausgänge als Eingänge un 
die Eingänge als Ausgänge machen? ... "

Ich habe mich an der Bascom-Hilfe zum Thema "Universal Serial Interface" 
orientiert. Dort ist die Port-Konfiguration für den Slave so vorgegeben.

http://avrhelp.mcselec.com/index.html?using_usi_universal_serial_int.htm

@ Lothar Miller

" ... Es ist keine gute Idee, zum Kennenlernen der SPI Schnittstelle 
einen Master und einen Slave selber zu machen. Besser nimmt man einen 
funktionierden Slave und spricht den an. ... "

Ich dachte eigentlich gerade, daß meine Vorgehensweise logischer ist, 
als gleich mit dem in der späteren Anwendung vorgesehenen nRF24L01+ als 
Slave zu experiementieren. Denn wenn ich schon eine "einfache" µC --> µC 
Kommunikation nicht hinbekomme, wird das für mich als Anfänger ungleich 
kompliziertere Ansprechen des Funkmoduls natürlich erst recht nicht 
funktionieren. Hier kommen nämlich noch zahlreiche weitere Fehlerquellen 
hinzu, weshalb ich zunächst mal sicherstellen wollte, daß ich SPI (USI 
bei ATTinys) verstanden habe und dieses ordentlich läuft.

Tja, und genau das tut es leider nach wie vor nicht :-( !!!

Ich habe den Slave entsprechend der Bascom-Hilfe nochmals modifiziert, 
ohne Erfolg.

----------------------------------------------------------------------
' SLAVE

$regfile = "attiny45.dat"
$crystal = 128000
$hwstack = 36
$swstack = 8
$framesize = 24

Dim Empfangsbyte As Byte
Dim Usi_data_ready As Bit

Config Portb.2 = Output               ' USCK ----> SCK (Slave)
Config Portb.1 = Output               ' DO   ----> SDI (Slave)
Config Portb.0 = Input                ' DI   ----> SDO (Slave)
Portb.0 = 1
Config Portb.4 = Output

Portb.4 = 1
Waitms 200
Portb.4 = 0

Usicr = Bits(usiwm0 , Usics1 , Usioie)

On Usi_ovf Usi_overflow_int
Enable Usi_ovf
Enable Interrupts

Do

  If Usi_data_ready = 1 Then
    Reset Usi_data_ready
    If Empfangsbyte = 1 Then Portb.4 = 1
    If Empfangsbyte = 2 Then Portb.4 = 0
  End If

Loop

End

Usi_overflow_int:

Set Usi_data_ready
Empfangsbyte = Usidr
Usisr = &B01_000000     'Reset Overflow Flag and reset 4-Bit USI counter

Return

------------------------------------------------------------------------

Dann ist auch immer die Rede von "Slave Select" als Leitung, über die 
der Master dem Slave den Beginn einer Übertragung signalisiert. Diese 
Funktion ist bei dem USI der Tinys aber gar nicht vorgesehen und kann 
laut Hilfe offensichtlich in diesem Fall auch weggelassen werden: "... 
We do not use Slave Select in this example ... ". Das verwirrt mich 
etwas. Ist es nun notwendig, den Übertragungsstart zu signalisieren, 
oder nicht?

Außerdem verstehe ich nicht so ganz, wie es sich mit der 
Clock-Einstellung verhält. Im Bascom-Beispiel wird diese für den Master 
überhaupt nicht definiert, für den Slave dann allerdings schon: " ... 
Clock Source: External, positive edge ; External, both edges ... " ?

Naja, und dann sollte nach meinem Verständnis während der Übertragung 
doch eigentlich ein Pegel am USCK-Pin (Clock) messbar sein, oder liege 
ich da falsch? Denn dort messe ich konstant 0 V.

Grüße,
The SphereX

Da hast Du absolut recht! Logisch betrachtet macht diese Konfiguration 
keinen Sinn. Dann gehe ich mal davon aus, daß es sich bei dem 
Bascom-Beispiel um einen Schreibfehler handelt.

Allerdings habe ich es mittlerweile natürlich auch schon mit der logisch 
korrekten Beschaltung probiert. Aber auch da funktioniert die 
Datenübertragung nicht. Wenn die 0 V am USCK-Pin des Master während der 
Übertragung aber wie gesagt tatsächlich bedeuten, daß kein 
Synchronisationstakt generiert wird, kann's ja auch nicht funktionieren. 
Nur warum erzeugt der Master den Takt nicht mit:

While Usisr.usioif = 0 : Set Usicr.usitc : Wend

nach dem Befüllen des Datenregisters?


Grüße,
The SphereX

Ich hab's trotzdem erst mal mit den zwei Tinys durchgezogen ;-). Und 
nachdem ich die Port-Konfiguration nachmals geändert und auch die 
Verkabelung unidirektional ausgelegt habe

> MASTER USCK (Out) ---> SLAVE USCK (In)
> MASTER DO (MISO) ---> SLAVE DI (MOSI)

funktioniert's jetzt auch :-). Danke für Eure Hinweise!

Grüße,
The SphereX

Nee, nee, ich glaube, da liegst Du falsch ;-) !

MISO = DO
MOSI = DI


Grüße,
The SphereX

Ja, ist schon klar, und vom Logischen her hast Du ja recht. Aber ich 
beziehe mich hier auf die PIN-Beschriftung laut Atmel, für mein Beispiel 
speziell die des ATTiny45. Danach ist beim "Universal Serial Interface" 
der Tinys eben:

> PB1 (MASTER) = DO (Data Out) = MISO

und

> PB0 (SLAVE) = DI (Data In) = MOSI

Folglich ist die Verbindung MASTER ---> SLAVE hier nun mal MISO ---> 
MOSI, auch wenn's logisch keinen Sinn macht.

Um Verwirrungen zu vermeiden hätte Atmel im Datenblatt vielleicht 
konsequenterweise die Begriffe MISO und MOSI komplett weglassen müssen, 
wenn man bei USI sowieso andere Bezeichnungen (DO, DI) gewählt hat.

Folgende Seite:

http://gizmosnack.blogspot.de/2013/04/tutorial-nrf24l01-and-avr.html

beschäftigt sich z. B. sehr ausführlich mit dem Thema "nRF24L01 und AVR 
µC". Auch hier wird extra noch mal hervorgehoben, daß man entgegen der 
logischen Vorgehensweise, MISO vom µC mit MOSI vom nRF24L01 Funkmodul 
verbinden muß, damit die Datenübertragung funktioniert.

" ... To get the USI to SPI up and running I found out that I had to 
connect the MOSI pin from the nRF to the MISO pin on the AVR and set it 
as output. Atmega88: PB3, ATtiny26: PB1, ATtiny85: PB1 ... "

Grüße,
The SphereX

Von den 6 ist der IRQ allerdings optional, d. h. für die 
Datenübertragung nicht erforderlich. Da waren's nur noch 5. Aber selbst 
wenn: Wofür gibt es denn Deinen super Fastboot ;-) :-) .... Reset-Pin 
als I/O konfiguriert, und fertig is'.

Grüße,
The SphereX