Bascom SPI-Kommunikation ATTiny45 --> ATTiny45 ?

T

The SphereX

Neues Mitglied
03. Jan. 2014
27
0
0
Sprachen
Hi Leute !!!

Ich möchte gern eine Funkstrecke zwischen zwei ATTiny45 mittels zweier nRF24L01+ Module aufbauen, welche über SPI angesprochen werden. Da ich allerdings mit diesem Interface noch nicht gearbeitet habe, wollte ich die SPI-Kommunikation zunächst einmal nur zwischen den direkt miteinander verbundenen µCs testen.

Dabei sendet der Master abwechselnd im Abstand von 20 Sekunden jeweils den Wert "1" und "2". Empfängt der Slave eine "1", schaltet er eine LED an, empfängt er eine "2", wieder aus. Als Sendesignal blinkt am Master eine LED kurz. Das Ganze sollte dementsprechend also folgendermaßen ablaufen:

> Master-LED blinkt --> Wert "1" wird gesendet --> Slave empfängt "1" --> LED am Slave leuchtet
> 20 Sekunden warten
> Master-LED blinkt --> Wert "2" wird gesendet --> Slave empfängt "2" --> LED am Slave aus
> 20 Sekunden warten

usw. .....

Leider tut sich am Slave nichts, d. h. die LED bleibt aus.

------------------------------------------------------------------------
' MASTER

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

Dim Datatosend As Byte

' USCK ----> SCK (Slave)
Config Portb.2 = Output

' DO ----> SDI (Slave)
Config Portb.1 = Output

' DI ----> SDO (Slave)
Config Portb.0 = Input
Portb.0 = 1

' Sende-LED
Config Portb.4 = Output
Portb.4 = 0

Usicr = Bits(usiwm0 , Usics1 , Usiclk , Usitc)

Do

Datatosend = 1
Gosub Transmission
Wait 20
Datatosend = 2
Gosub Transmission
Wait 20

Loop

End

Transmission:

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

' USIOIF löschen und USI-Zähler auf 0
Usisr = Bits(usioif)

' Datenregister beschreiben
Usidr = Datatosend

' 8 Takte warten bis Byte übertragen
While Usisr.usioif = 0 : Set Usicr.usitc : Wend

Return

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

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

Dim Empfangsbyte As Byte
Dim Usi_data_ready As Bit

' USCK ----> SCK (Slave)
Config Portb.2 = Output

' DO ----> SDI (Slave)
Config Portb.1 = Output

' DI ----> SDO (Slave)
Config Portb.0 = Input
Portb.0 = 1

' Signal-LED
Config Portb.4 = Output

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

'Reset Overflow Flag and reset 4-Bit USI counter
Usisr = &B01_000000

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) des Master messbar sein, oder liege ich da falsch? Denn dort messe ich konstant 0 V.

Grüße,
The SphereX
 
Ich weiß jetzt nicht ob, und wieviel Bascom Dir hier abnimmt, aber USI taktet die Clock nicht selbst. Das mußt Du machen (entweder über das PORT-Register (Pin Register??) oder über USITC in USICR.
Schau mal ins Datenblatt (ab Seite 111).

Den Rest hab ich noch nicht angesehen...
Nachtrag:

vorweg: USI ist kein SPI. USI ist auch kein TWI. USI kann aber beides mit relativ geringem Softwaraufwand nachbilden (weniger als reine Software). Mehr oder weniger gut.
zu den CS-Leitungen: Die teilen weniger den Begin der Übertragung mit, sondern wählen den Busteilnehmer (Slave) aus. ChipSelect. Es können ja mehrere Slaves am Bus hängen. Beim echten SPI reagiert die Slave-Hardware darauf, wird der Slave nicht selektiert, ignoriert er den Bus (ist ja nicht für seine Ohren bestimmt). Ob der Master den Pin jetzt auf Gnd legt, oder ob Du den Slave dauerhaft fest auf Gnd verdrahtest, ist egal. Beim Master kommts dann sogar darauf an, ob dessen CS ein Ausgang oder ein Eingang ist - bei einem Eingang kann der Master durch einen low-Pegel selbst in den Slave-Mode gezwungen werden (also wenn man ein Multi-Master-Bus will zB)

Du hast mit deinen Tinies aber nur USI, ohne jegliche Chip Selection. Begin und Ende des Bytes werden ja durch die Clock (und die Anzahl der Bits) bestimmt - wenn Du also noch 'ne Chip Selection brauchst, mußt Du das über 'nen weiteren Pin (ggf mit'nem Interrupt beim Slave (der das USI dann erst scharf macht)) in Software implementieren.

P.S.: im von Dir verlinkten Beispiel aus der Bascom-Hilfe wird in einer For-To-Schleife übrigens sechzehnmal der Clk getoggelt (bzw 8mal gesetzt und 8mal gelöscht - wie ich oben schon mit USITC in USICR andeutete)
 
" ... USI taktet die Clock nicht selbst. Das mußt Du machen ... oder über USITC in USICR. ... "

Aber genau das sollte ja eigentlich an dieser Stelle

' 8 Takte warten bis Byte übertragen
While Usisr.usioif = 0 : Set Usicr.usitc : Wend

passieren?! Solange das USI-Overflow-Interupt-Flag nicht gesetzt und damit die Datenübertragung noch nicht beendet ist, wird im Kontrollregister USITC = 1 gesetzt und damit der Takt generiert. Aber wie gesagt, wenn 0 V am USCK-Pin bedeuten, daß sich dort nichts tut, scheint es mit dem Taktsignal wohl doch irgendein Problem zu geben (?).

Grüße,
The SphereX
 
Ups... Deine While übersehen...

Aber geh mal noch mal die Beine und deren DDR und PORT durch - beim Slave paßt da mMn was nicht (können zB nicht beide die CLK als Ausgang haben)...

P.S.: Im Datenblatt scheint diesbezüglich ein Fehler zu sein - außerdem wird beim Master-Code dort R16 in der Schleife doppelt verwendet (USIOIF pollen und USITC-Strobes erzeugen)
 
Hi,

LotadaC schrieb:
P.S.: Im Datenblatt scheint diesbezüglich ein Fehler zu sein - außerdem wird beim Master-Code dort R16 in der Schleife doppelt verwendet (USIOIF pollen und USITC-Strobes erzeugen)
Zum Vergrößern anklicken....

bin ich auch schonmal drauf gestoßen. War glaube ich nen Mega168. Da waren die falschen Configregisternamen drin. Die machen bei Atmel ab und zu etwas zu viel Copy/Paste und kopieren dabei den Beispielcode ohne Anpassung von nem anderen Prozessor in das Datenblatt. Da muß man aufpassen was wirklich drinsteht.

Gruß
Dino
 
Hier siehts nach C&P von der Master- zur Slave-Beschreibung aus. Beim Master steht:
The code is size optimized using only eight instructions (plus return). The code example assumes that the DO and USCK pins have been enabled as outputs in DDRB. The value stored in register r16 prior to the function is called is transferred to the slave device, and when the transfer is completed the data received from the slave is stored back into the register r16.
Zum Vergrößern anklicken....
Beim Slave:
The code is size optimized using only eight instructions (plus return). The code example assumes that the DO and USCK pins have been enabled as outputs in DDRB. The value stored in register r16 prior to the function is called is transferred to the master device, and when the transfer is completed the data received from the master is stored back into the register r16.
Zum Vergrößern anklicken....
Beide Seiten als Ausgang???

Andere Frage:
Warum soll jeweils der Pullup vom DI aktiviert werden (ist auch im Bascom-Beispiel so)? Beim USI-Wiremode[1..0]=0b01 wird für den DO-Pin das PortValueOverrideEnable gesetzt - PortValueOverrideValue ist dann DO. Wenn der DO Pin also Ausgang ist, liegt der entsprechende Pegel auf der je anderen Seite am DI an. Da DI von keinen Overrides betroffen ist (Datenblatt S.120 Table 15-1, oder S.64 unten, oder auch S.65 Table 10-5 rechte Spalte), muß der Programmierer sicherstellen, daß DI Eingang ist. Aber warum mit aktiviertem Pullup, und nicht Tristate?

P.S.: Seitenangaben da oben bezogen sich auf die N-Revision des Datenblattes. Aktuell ist die Q-Revision. Auch laut der soll auf beiden Seiten USCK Ausgang sein (???) und im Master Code wird vor der Schleife die Bitmaske zum USITC-toggeln in R16 abgelegt und auch in der Schleife genutzt - in der Schleife aber USISR zwecks USIOIF-Polling nach R16 geladen; danach stimmt also beim 2ten Durchlauf die Maske fürs USITC nicht mehr.

Hat also diesbezüglich keine Datenblatt-Korrekturen gegeben (wie man auch schnell der "Datasheet Revision History" entnehmen kann. Naja, sind ja noch ein paar Buchstaben im Alphabet übrig...

P.P.S.: Habe mal ins Datenblatt des Tiny26 gelesen (K-Revision). Dort soll beim Slave USCK Eingang sein (was ja logisch ist). Außerdem wird dort das USIOF im USISR direkt gepollt (mit SBIS). Klar, USISR hat beim 26 I/O-Registeradresse 0x0E, und ist somit direct Bit accessible. Aber jetzt kommts: beim Tiny25 ist USISR auch auf 0x0E...
Von wo die den falschen Codeschnipsel übernommen haben, ist mir noch nicht ganz klar.
(falsch im doppelten Sinne: geht nicht wegen R16-Doppelnutzung und unsinnig wegen Verzicht des "direct bit accessible"-Pollings)
 
Alles bestens !!!

Hi Leute !!!

Also es scheint hier wohl tatsächlich so zu sein, daß Atmel und auch die Bascom-Hilfe für etwas Verwirrung sorgen, da ganz offensichtlich Fehler in den entsprechenden Dokumenten enthalten sind. Insbesondere die Beschaltung des USCK-Pins auch beim Slave als Output macht ja eigentlich überhaupt keinen Sinn. Danke also schon mal für den Hinweis.

Ich habe die Port-Konfiguration jetzt entsprechend geändert:

SLAVE

' USCK ----> USCK (Slave)
Config Portb.2 = Input

' DO ----> SDI (Slave)
Config Portb.1 = Input

Den DI am Master und DO am Slave habe ich dabei einfach mal komplett rausgenommen, also sowohl aus dem Programmcode, als auch aus der Schaltung, da die Kommunikation in meinem Fall ja sowieso nur unidirektional ist, so daß das Ganze jetzt folgendermaßen aussieht:

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

Und siehe da: ES FUNKTIONIERT !!! :cool:

Die Pullups habe ich übrigens auch weggelassen. Scheint nicht geschadet zu haben :wink:.

Jetzt hätte ich nur noch eine Frage zur Konfiguration der "Clock Source" und "4 Bit Counter Clock Source". In meinem Beispiel lautet diese ja:

External, positive edge / External, both edges

Nun habe ich einen Bascom-Code gefunden (Siehe Anhang!), der mit einem ATTiny84 ebenfalls über USI ein nRF24L01+ Modul ansteuert, also genau meine eigentliche Zielanwendung. Nur lautet die Konfiguration hier:

External, positive edge / Software clock strobe (USITC)

Wo liegt da genau der Unterschied, und woher weiß ich, welche Konfiguration ich wählen muß? Da werde ich aus dem Datenblatt irgendwie nicht so richtig schlau. Muß ich hier etwa im Datenblatt des jeweiligen Slave (in meinem Fall nRF24L01+) nachschauen, welche Taktung dieser erfordert?

Grüße,
The SphereX
 

Anhänge

  • ATTiny84 -- nRF24L01+.bas
    3 KB · Aufrufe: 24
Ok, Datenblatt lesen, und Hirn einschalten...

Das USI wird über 4 I/O-Register bedient:
  • USIDR - USI Data Register
    ist das eigentliche 8bit-Schieberegister
  • USIBR - USI Buffer Register
    jedesmal nach einem kompletten Transfer wird der Inhalt des USIDR hierher kopiert, kann also von hier gelesen werden während das USIDR bereits das nöchste Byte schiebt/eingeschoben bekommt
  • USISR - USI Status Register
    enthält 4 Statusflags und einen 4bit-Counter, ich fange mal von hinten an:
    • USICNT[3:0] - 4bit counter
      Zähler, der 4bit weit zählen kann, 16 Schritte. Kann durch unterschiedliche Quellen inkrementiert werden (Timer Compare Match, Flanken am USCK-Pin, USITC-Strobes). Da wir SPI emulieren wollen, soll der Timer nach 8 bit überlaufen, also bei jeder SCK-Flanke (entweder selbst erzeugt - Master, oder am USCK-Pin registriert - Slave) inkrementieren. Mit 2 Flanken pro bit läuft er dann nach einem Byte über
    • USIDC - USI Data Output Collision Flag
      Dient der Master-Arbitrierung im 2Wire-Mode (TWI). Erkennt die Hardware auf der Datenleitung ein Low obwohl der Transmitter eigentlich ein High drauflegt, verliert der Master die Arbitrierung, und soll selbst zum Slave werden. Eine 1 im USIDC signalisiert diese Abweichung.
    • USIPF - USI Stop Condition Flag
      Wird im 2wire-Mode gesetzt, wenn eine Stop-Condition erkannt wurde
    • USIOIF - USI Counter Overflow Interrupt Flag
      Überlauf-Flag des 4bit-Counters. Kann einen IRQ generieren. Kann verwendet werden um den vollständigen Transfer zu erkennen (16 Flanken).
    • USISIF - USI Start Condition Interrupt Flag
      Wird im 2wire-Mode nach einer erkannten Start-Condition gesetzt, im 3wire-Mode bei jeder USCK-Flanke. Kann einen IRQ generieren. Kann den Controller aus dem Sleep wecken.
  • USICR - USI Control Register
    • USISIE - USI Start Condition Interrupt Enable
      Befähigungsbit des USI Start Condition Interruptes, wird durch Bascom mit "On Interruptname ISRAdresse" oder so ähnlich verwltet/gesetzt.
    • USIOIE - USI Counter Overflow Interrupt Enable
      Dito Überlaufinterrupt des 4bit-Counters (quasi ein Transfer Complete Interrupt)
    • USIWM[1:0] - USI Wire Mode
      Diese beiden Bits legen fest, was das USI emulieren soll. Du willst SPI bzw den 3wire-Mode, also sind die Bits 0b01
    • USICS[1:0] - USI Clock Source Select
      legt fest, wodurch der 4bit-Counter inkrementiert wird, und wann das Schieberegister geschoben wird. USICS1=1 bedeutet, daß bei einer Flanke am USCK-Bein das Schieberegister geschoben wird. Bei welcher Flanke legt USCS0 fest.
    • USICLK - USI Clock Strobe
      Mit USICS1=0 wäre dieses Bit ein Clock Strobe für den Zähler und das Register, Aber Du hast ja USICS1=1, also legt dieses Bit jetzt fest ob der Timer bei einer (jeder) Flanke am USCK inkrementiert (USICLK=0=Slave), oder bei einem Software-Strobe (USICLK=1=Master)
    • USITC - USI Toggle Clock Port Pin
      Bit fungiert als Strobe, jedesmal wenn eine 1 geschrieben wird, toggelt der USCK-Pin, wodurch ggf die Schieberegister geschoben werden (siehe USICS[1:0]). Wenn USICLK und USICS1 gesetzt sind, wird außerdem der Counter inkrementiert.

Den neuen IC und dessen Bascom-Code hab ich mir jetzt noch nicht angesehen, man könnte als Master auch auf die Verwendung des Counters verzichten (also auch auf das USIOIF-pollen), und dann mit USICS[1:0]=0b00 (Table15-2) einfach zu Fuß 16 mal toggeln (USITC) und dabei 8 mal schieben (USICLK).
Also achtmal erst USIWM0+USITC nach USICR schreiben (toggelt den USCK-Ausgang),
danach USIWM+USITC+USICLK nach USICR schreiben (toggelt zurück, und schiebt das USIDR).
(geht natürlich auch andersrum - im Datenblatt wird dieser Weg auch angedeutet, als schnellstmögliche Kommunikation (eben nur die 16 OUTs die man für das USITC-Toggeln mindestens braucht - wird also irgendwo zusätzlich ein Flag gepollt, und/oder gesprungen, dauerts zwangsläufig länger))

P.S.: hast Du irgendwo'n Datenblatt zu diesem Chip?
The SphereX schrieb:
...
Jetzt hätte ich nur noch eine Frage zur Konfiguration der "Clock Source" und "4 Bit Counter Clock Source". In meinem Beispiel lautet diese ja:

External, positive edge / External, both edges...
Zum Vergrößern anklicken....
Bei Deinem Slave Code, ja...
The SphereX schrieb:
...
Nun habe ich einen Bascom-Code gefunden (Siehe Anhang!), der mit einem ATTiny84 ebenfalls über USI ein nRF24L01+ Modul ansteuert, also genau meine eigentliche Zielanwendung. Nur lautet die Konfiguration hier:

External, positive edge / Software clock strobe (USITC)
...
Zum Vergrößern anklicken....
Dieser Tiny ist aber ein Master, der nRF... ist der Slave. der Code ist also Master-Code, und die Einstellungen entsprechen auch Deinem zuerst vorgestelltem Master-Code;)

Zu den Pullups - man kann sich auch'n Brett ans Knie nageln. Gibt auf alle Fälle Schmerz, wahrscheinlich kann man trotzdem Laufen...
Normalerweise legt beim SPI eine Seite den Pegel fest, und die andere liest ihn (und ist selbst Tristate). Wird dort jetzt der Pullup eingeschaltet, fließt halt Strom, wenn die erste 'nen Low-Pegel anlegt. Über den Pullup wenig Strom, aber eben sinnlos. Der Master muß halt immer gegen den Pullup arbeiten - hat man viele Slaves am Bus (und viele Pullups parallel), bekommt der Master die Clock eventuell nicht mehr runter...
 
Danke für die Übersicht bzw. Erläuterungen.

Ich habe mich zwischenzeitlich noch mal bemüht, das "SPI-Timing" (besser) zu verstehen und dazu auch HIER (Protokollablauf und Einstellmöglichkeiten) nachgelesen. Soweit denke ich auch, daß ich die 4 Modi, die sich aus den verschiedenen CPOL- u. CPHA-Kombinationen ergeben, verstanden habe. Warum man hier allerdings nicht einfach bei einem Modus (z. B. CPOL = 0, CPHA = 0) bleibt, erschließt sich mir noch nicht. Dafür steht in dem Artikel aber auch:

" ... Das Serial Peripheral Interface (kurz SPI) ist ein von Motorola entwickeltes Bus-System mit einem „lockeren“ Standard ... "

sowie

" ... Ein Protokoll für die Datenübertragung wurde von Motorola zwar nicht festgelegt, doch haben sich in der Praxis vier verschiedene „Modi“ durchgesetzt. ... "

Man muß dann halt logischerweise im Datenblatt des Slaves nachschauen, welchen der 4 Modi dieser nutzt. So, und wenn ich dementsprechend das Kapitel "8.3.2. SPI timing" vom nRF24L01+ Transceiver richtig interpretiere, müßte dieser den Modus 0 (CPOL = 0, CPHA = 0) nutzen (?). Ob es nun davon abhängt, welche USI-Taktung (USICS, USICLK, Tabell 15.2 ATTiny Datenblatt) ich am Master einstellen muß, oder nicht, habe ich leider immer noch nicht so richtig verstanden. Ich weiß jetzt zwar, was ich hier einstellen kann, also die unterschiedlichen Quellen für das Schieben des Datenregisters und das Inkrementieren des 4-Bit Zählers, aber welche der 6 Varianten ich letztlich nehmen muß, evtl. eben auch in Abhängigkeit vom SPI-Timing des jeweiligen Slaves, kann ich noch nicht erklären.

HIER wird übrigens das Thema "nRF24L01 and AVR" sehr ausführlich behandelt. Ist zwar alles in C, aber die grundsätzliche Vorgehensweise habe ich schon verstanden. Und auch hier wird für den Master

---> USICS1 = 1, USICS0 = 0, USICLK = 1, also "extern, positive Flanke / Software (USITC)"

eingestellt.

Könnte ich hier prinzipiell auch eine andere Konfiguration wählen, z. B.

---> USICS1 = 1, USICS0 = 0, USICLK = 0, also "extern, positive Flanke / extern, beide Flanken"

wie bei meinem Test ATTiny45 ---> ATTiny45 ???

LotadaC schrieb:
Zu den Pullups ... Der Master muß halt immer gegen den Pullup arbeiten - hat man viele Slaves am Bus (und viele Pullups parallel), bekommt der Master die Clock eventuell nicht mehr runter...
Zum Vergrößern anklicken....

Na dann paßt es ja, wenn ich die Pullups einfach weglasse.


Grüße,
The SphereX
 
Irgendwie werd ich nicht so recht schlau, WAS Du nun konkret willst. Zwei Tinies über, durch USI emulierten SPI miteinander kommunizieren lassen, oder einen Tiny mit dem nRF..., oder was?

Wenn 2 Tinies, muß einer Master und einer Slave sein, und beide denselben SPI-Mode nutzen/emulieren.
Wenn Tiny und nRF... (habe das auf den ersten Blick(!)) so interbpretiert, daß der nRF... immer Slave ist), muß der Tiny Master sein, und sich an den, vom nRF... verwendeten Mode halten.

Als Slave muß der Tiny auf 'ne externe Clock am USCK reagieren, der 4bit Timer soll nach 8bits mit je 2 Flanken überlaufen, also muß er bei "both edges" inkrementieren; das Schieberegister muß aber nur bei einer Flanke geschoben werden - positive oder negative.
Als Master muß er das Schieberegister auch nur bei einer Flanke schieben, aber zusätzlich muß die Software den USCK toggeln (16mal), und zwar mit USITC-Strobes. Ist USICLK dabei gesetzt, wird gleichzeitig der Counter inkrementiert.

Wenn das USOIF als Transfer Complete Flag genutzt werden soll, ist bei der SPI-Emulation USICS1 zu setzen. CPHA wird dann quasi mit USICS0 festgelegt, CPOL durch den vom Master vorher festgelegten Pegel auf der USCK (beim Transfer toggelt die ja nur). Ob der Tiny Master oder Slave ist, bestimmt USICLK (und die nötigen USITC-Strobes).
 
LotadaC schrieb:
Irgendwie werd ich nicht so recht schlau, WAS Du nun konkret willst.
Zum Vergrößern anklicken....

Die eigentliche Zielanwendung ist nach wie vor eine Funkstrecke zwischen zwei ATTiny45 mittels zweier nRF24L01+ Transceiver. Da ich allerdings SPI/USI noch nie benutzt habe, wollte ich mich quasi zum Kennenlernen des Interfaces zunächst an einer Direktkommunikation ATTiny45 ---> ATTiny45 versuchen, denn wenn ich diese "einfache" Form nicht hinbekomme, würde es wohl mit den Tranceivern erst recht nichts werden. So sah meine Vorüberlegung aus.

So, das Thema "ATTiny45 --- USI ---> ATTiny45" ist ja nun mittlerweile erfolgreich erledigt, so daß ich mich jetzt an die eigentliche Anwendung

ATTiny45 (MASTER) --- USI ---> nRF24L01+ (SLAVE) -------> nRF24L01+ (SLAVE) --- USI ---> ATTiny45 (MASTER)

heranwagen kann.

Als Hilfe und Orientierung hatte ich mir dafür eben den bereits geposteten Bascom-Code sowie die Seite "nRF24L01 and AVR" herausgesucht. Beim Studium des Materials sind dann natürlich noch einige Frage aufgekommen, die Du mir aber mittlerweile schon größtenteils z. B. wie nachfolgend beantwortet hast :).

LotadaC schrieb:
Wenn Tiny und nRF... (habe das auf den ersten Blick(!)) so interbpretiert, daß der nRF... immer Slave ist), muß der Tiny Master sein, und sich an den, vom nRF... verwendeten Mode halten.

Wenn das USOIF als Transfer Complete Flag genutzt werden soll, ist bei der SPI-Emulation USICS1 zu setzen. CPHA wird dann quasi mit USICS0 festgelegt, CPOL durch den vom Master vorher festgelegten Pegel auf der USCK (beim Transfer toggelt die ja nur). Ob der Tiny Master oder Slave ist, bestimmt USICLK (und die nötigen USITC-Strobes).
Zum Vergrößern anklicken....

Dann fasse ich also nochmal zusammen: Laut Datenblatt nutzt der nRF24L01+ Modus 0 (CPOL = 0, CPHA = 0). Entsprechend muß USICS0 = 0 sein. Meine Tinys sind jeweils die Master, CPOL = 0 und ich nutze USIOIF als "Transfer Complete Flag", also ist USICS1 = 1 und USICLK = 1. Wenn Du das so als richtig bestätigen kannst, dann habe ich's glaube ich verstanden :yes4:.

Grüße,
The SphereX
 
Du musst dich einloggen oder registrieren, um hier zu antworten.

Über uns

  • Makerconnect ist ein Forum, welches wir ausschließlich für einen Gedankenaustausch und als Diskussionsplattform für Interessierte bereitstellen, welche sich privat, durch das Studium oder beruflich mit Mikrocontroller- und Kleinstrechnersystemen beschäftigen wollen oder müssen ;-)
    • Dirk
  • Du bist noch kein Mitglied in unserer freundlichen Community? Werde Teil von uns und registriere dich in unserem Forum.
    •  Registriere dich

User Menu

Anmelden

 Kaffeezeit

  • Wir arbeiten hart daran sicherzustellen, dass unser Forum permanent online und schnell erreichbar ist, unsere Forensoftware auf dem aktuellsten Stand ist und der Server regelmäßig gewartet wird. Auch die Themen Datensicherheit und Datenschutz sind uns wichtig und hier sind wir auch ständig aktiv. Alles in allem, sorgen wir uns darum, dass alles Drumherum stimmt :-)

    Dir gefällt das Forum und unsere Arbeit und du möchtest uns unterstützen? Unterstütze uns durch deine Premium-Mitgliedschaft!
    Wir freuen uns auch über eine Spende für unsere Kaffeekasse :-)
    Vielen Dank! :ciao:


     Spende uns! (Paypal)

Oben Unten
Zurück