AVR als Schieberegister

Hallo Peter,

Peter schrieb:
> Ich habe nach einem Schieberegister gesucht, was wenn einmal Daten über
> SPI erhalten hat, eine eigenständige PWM durchläuft für insgesamt 3
> Kanäle. Ich brauche hierbei eine PWM Freq von ~15kHz.

Gibt es ein Schaltbild für dein Vorhaben?
Was bedeutet es, "eine eigenständige PWM" zu "durchlaufen"? Soll das der 
AVR tun?

> Nun habe ich es noch nicht sinnvoll hinbekommen, dass der Master die
> Daten an die Slaves schickt. Das erste Register soll 3*256 Bits abrufen.
> Solange SS den Zustand nicht gewechselt halt, soll er die nächsten Bits
> an die nächsten Slaves weiterleiten. Erst wenn sich der Status von SS
> ändert, sollen die Werte an die PWMs weitergeleitet werden.

Wer ändert den Status von SS? Ist das ein Eingang des AVR oder ein 
Ausgang?

> Doch den part bekomme ich nicht hin

Würde ich auch nicht... ich hab ihn nicht verstanden. ;-)

Peter schrieb:
> 127, 0, 0,
> Nun wird abgewartet bis der SS wieder HIGH ist. Dann werden die Daten
> übernommen werden. Nun macht der Slave dauerhaft auf dem roten Kanal
> eine PWM mit 50%.

Wer wartet? Das AVR-basierte Schieberegister, das du verwenden willst?
SS = Slave Select, oder?

> Wenn ich nun aber 255,127,0,0,55,125 schicke, sollen die ersten 3 Bytes
> direkt an den nächsten Slave weitergeleitet werden.

Wenn ich es richtig verstehe, soll ein 768 bit langer Bitstrom 
aufgesplittet werden in Portionen von 24 bit. Jede dieser Portion soll 
an einen anderen Ausgang gehen...?

Oder wird der Strom sowieso an alle 841 gleichzeitig gesendet, und du 
willst nur die SS-Eingänge der 841 alle 24 bit umschalten

Kann aber gut sein, dass meine grauen Zellen schon etwas langsam 
rotieren um diese Uhrzeit. :-)

Wie stellst du dir die CLK-Leitung vor?
Wenn du die auf alle Chips verteils, woher soll ein µC dann wissen an 
welcher Position es sitzt? Soll da dann jeweils noch eine SS-Leitung von 
Chip zu Chip, die jeweils vom Vorgänger aktiviert wird, sobald der seine 
3 Bytes hat?

Dann hast du ein kleines Problem mit dem SPI-Moduls. Selbiges erlaubt 
dir ja immer erst nach dem vollständigen Empfangen eins Bytes Zugriff 
auf das Byte, welches du ja gerade schon weiter schicken willst. Du 
müsstest also schon vorher wissen was du empfangen wirst um das auch im 
richtigen Moment weiter schicken zu können. Folglich kannst das 1.Byte 
für den 2. Slave erst mit dem 4. vom Master gesendeten Byte aus dem 
SPI-Modul des 1.Slave getaktet werden. Das führt dazu, dass dir am Ende 
Takte fehlen (Jeder Slaver verzögert die Daten ja um 1 Byte). Der Master 
müsste also für jeden gesendeten 3-Byte-Block ganz am ende ein weiteres 
Dummy-Byte senden damit die Daten für das letzt Slave auch bei diesem 
ankommen können.
Alternativ musst jeder Slave nach dem 3.Byte das SPI deaktivieren und 
per Software die Datenleitung "überbrücken". Das führt natürlich zu 
einer Latenz und kann nach ein paar µCs schon zu Fehlern führen.

Leo B. schrieb:
> Selbiges erlaubt
> dir ja immer erst nach dem vollständigen Empfangen eins Bytes Zugriff
> auf das Byte, welches du ja gerade schon weiter schicken willst.

Hallo Leo, berechtigter Einwand.
Das Problem tritt aber nicht auf, wenn SPI per Software abgewickelt 
wird. Dann kann man quasi sofort Bit für Bit reagieren.

Bringt mich aber wieder zu Frage 1: ein (zumindest grob skizzierter) 
Schaltplan wär nicht verkehrt. :-)

Markus Weber schrieb:
> Hallo Leo, berechtigter Einwand.
> Das Problem tritt aber nicht auf, wenn SPI per Software abgewickelt
> wird. Dann kann man quasi sofort Bit für Bit reagieren.

Dann schreib 2 software-SPI-Module, sonst wird die Datenleitung über die 
Chips zu arg verzögert gegenüber dem CLK-Signal.


Aber mir kam ein anderer Gedanke:
Slave n empfängt 3 Byte, legt dann das 1.Byte zum Senden ins 
SPI-Datenregister und aktiviert SS von Slave n+1. Möglicherweise kommen 
jetzt wieder 3 Byte vom Master/Slave n-1. Diese überschreiben dann die 
vorherigen, wobei die vorherigen jeweils an Slave n+1 übertragen werden. 
Das wiederholt sich immer und immer wieder bis SS vom Master/Slave n-1 
deaktiviert wird. Dann wird auch SS für Slave n+1 deaktiviert und die 
jetzt im Speicher befindlichen Daten werden verwendet.

Das würde zwar die ersten 3-Byte zum letzen Chip durch schieben und 
nicht wie bei den WSxxx-Chips im 1.Chip behalten aber die Reihenfolge 
kann der Master ja auch umdrehen. Tut ja nicht weh.

Peter schrieb:
> So wie halt ein HC595 oder ähnliches.

Ganz genau so macht es das AVR-SPI.
Das SPI ist ein 8Bit-SRG, einfach MISO des einen mit MOSI des nächsten 
verbinden.
Du sendest 3 Byte, dann hat der erste das letzte, der 2. das mittlere 
und der letzte das erste Byte empfangen.

Peter schrieb:
> Wenn ich nun aber 255,127,0,0,55,125 schicke, sollen die ersten 3 Bytes
> direkt an den nächsten Slave weitergeleitet werden.

Das geht natürlich nicht. Das SRG ist immer 8Bit lang.

Du könntest 3 Pakete a 2 Byte draus machen, also 2 Byte, Pause, 2 Byte, 
Pause usw. Ein Timerinterrupt erkennt dann die Pause und übernimmt das 
Byte.

Eine Weitere Möglichkeit wäre wohl, Daten und Takt vom Master parallel 
an alle Slaves zu schicken und nur das SS durch zu schleifen. Jedes 
Slave empfängt 3 Byte und aktiviert dann den SS des nächsten Slave. 
Damit das zuverlässig funktioniert sollte der Master vielleicht eine 
kleine Pause nach jedem 3er-Block einlegen, damit ein Slave zeit hat 
seinen Nachfolger zu aktivieren, und der dann auch die Daten so empfängt 
wie gewünscht und nicht evtl. um ein paar Bit verschoben.

Möglichkeiten über Möglichkeiten... Der TO sollte sich vielleicht auch 
mal ein paar Gedanken machen und einfach ausprobieren. Learning by 
doing...

Hier noch eine Möglichkeit:

   Beitrag "Equinox-Uhr mit 60 ATtinys"

Immerhin schafft jeder ATtiny damit 3 x 12 Bit PWMs und ist damit jeder 
WS2812-LED haushoch überlegen.

Wo ist das Problem?

Man kann doch problemlos die SPI-Slavas kaskadieren, auch mit der 
Hardware-SPI der AVRs.


In der ISR muss nur das letzte empfangende Byte sofort wieder ins 
Senderegister schreiben und die letzten 3 Bytes speichern.

volatile uint8_t spi1;
volatile uint8_t spi2;
volatile uint8_t spi3;

ISR( SPI_STC_vect ) {
spi3 = spi2;
spi2 = spi1
spi1 = SPDR;
SPDR = SPDR;
}

Der Master sollte dann aber nach jedem Byte die CLK Leitung kurz ruhen 
lassen, damit die Slaves ihre ISR ausführen können.
Eventuell geht das sogar automatisch da der Master ja selbst in einer 
ISR steckt, um das nächste Byte zu laden.


EDIT:
Zusätzlich zur SS Leitung am besten noch eine weitere Leitung benutzen, 
die dann besagt das die Übertragung abgeschlossen ist.
Ähnlich wie der RCK-Pin eines 74xx595. Auch wenn die SS-Leitung die 
ganze Zeit Low ist und am Ende wieder auf HI geht, kannst du das schwer 
in der Software auswerten.

Theoretisch geht es auch mit einer Leitung wenn du sie zusätzlich auf 
einen weiteren Pin legst der Interrupt fähig ist.
Manche AVRs haben auch PIN-Change-Interrupt für jede Ports, darüber kann 
man dann auch den SS-Pin nochmal abfragen.

c-hater schrieb:
> Beim Hardware-SPI bin ich mir nicht ganz sicher, ob der Schreibvorgang
> nach SPDR eventuell nötig ist, um die SPI-Logik wieder "freizugeben".
> Müßte man glatt mal ausprobieren, ob es auch ohne geht. Ich würde fast
> vermuten, daß es prinizipiell genauso wie beim USI garnicht nötig ist.

Du könntest recht haben, das die Zeile
SPDR = SPDR;
unnötig ist. Eine Daisy Chain hab ich mit AVR-SPI-Slaves noch nicht 
gemacht. Einfach mal ausprobieren.

asdfasd schrieb:
> Vorgehensweise auf allen Modulen:
>
>   - Der Counter-Overflow-Irq macht folgendes: Input-Register lesen und
> Daten in buf[i] abspeichern, i incrementieren (modulo n), buf[i] ins
> Output-Register schreiben.
>
>   - Der Pin-Change-Irq von SS macht folgendes: Daten aus dem Buffer zur
> PWM-Routine übergeben, CLK-Counter und Index resetten.

Das ist die richtige Antwort.

Die SS-Leitung würde ich aber umtaufen zu RCK um mit der einschlägigen 
Literatur und üblichen Bezeichnungen dieser Leitung konform zu gehen.

Christian K. schrieb:
> In der ISR muss nur das letzte empfangende Byte sofort wieder ins
> Senderegister schreiben und die letzten 3 Bytes speichern.

Nein, er muss sie verzögern, er braucht einen 2 Byte grossen FIFO-Puffer 
in jedem Device denn wenn der RCK kommt "gehören" jedem Device genau die 
3 Byte die es zuletzt bekommen hat (das was noch im Register steht und 
die anderen zwei aus dem FIFO), und die gehören dem jeweiligen Device 
alleine, es soll ja keine Überlappungen geben.

> Zusätzlich zur SS Leitung am besten noch

Er braucht gar keine SS denn es gibt ja nichts zum selecten, es gibt ja 
nur einen einzigen (sehr langen) Slave, der ist immer aktiv. Er braucht 
nur

MOSI->MOSI, MISO->MOSI,... ,
SCK (parallel an alle) und
RCK (parallel an alle).

Doch SS wird benötigt, da die Slaves sonst nicht wissen wann das erste 
Bit los geht, würde SS Hard auf LOW verdrahtet sein, könnten sie aus den 
Tritt geraten.

Aber man kann das gleiche Signal für SS und RCK nehmen.

Er hat geschrieben das er ATTiny841 benutzt.

Da würde ich den PCINT0 verwenden und diesen nur auf PORTA7 Triggern, 
das ist der SS-Pin.
In der PCINT0-ISR abfragen ob PA7 HI ist, und dann die Variablen SPI1,2 
und 3 auswerten.