Chip Select nach jedem Byte

CS nach irgendwann einmal loszulassen, zum Beispiel nach einem ganzen 
Datenpaket, ist sinnvoll. Damit werden die Transceiver neu 
synchronisiert. Falls der Empfänger zum Beispiel eine Taktflanke durch 
eine Störung nicht mitbekommen hat.

Dies nach jedem Byte zu tun, ist allerdings sehr ungewöhnlich.

Peter D. schrieb:
> Milton schrieb:
>
>> Aber weiß jemand, warum das aus Sicht
>> des Herstellers notwendig ist?
>
> Da Du den Chip nicht nennst, mußt Du den Hersteller fragen.
> Die Hellseher sind grad in Urlaub.

Beispielsweise der netX90.

Milton schrieb:
> Beispielsweise der netX90.

Hast Du auch ein Beispiel, wo ein Datenblatt Deine These untermauert? 
Vielleicht sogar mit einem Link? Ich sehe das bei dem netX90 nicht.

Milton schrieb:
> Ist gerade beim Senden von vielen Daten nervig, da man das ganze quasi
> als ineffiziente for-Loop aufziehen muss.

Hast Du denn schon mit einem solchen Chip gearbeitet? Oder war das eine 
rein theoretische Frage. Oder nimmst Du so einen Chip gerade in Betrieb.

Milton schrieb:
> Aber weiß jemand, warum das aus Sicht
> des Herstellers notwendig ist?

Damit es auch mit 8 bit CPU/µC funktioniert?! SPI stammt aus dem Jahre 
1987.

>Ist gerade beim Senden von vielen Daten nervig, da man das ganze quasi
>als ineffiziente for-Loop aufziehen muss.

Aus Sicht eines Hardware-Entwicklers ist das beschriebene bit-banging an 
sich ineffektiv (aber flexibel). Besser ist es, dedizierte 
SPI-Master-Hardware zu verwenden, die das ganze auch noch per DMA an der 
CPU vorbei transferiert.

https://de.wikipedia.org/wiki/Bit-Banging


> https://kb.hilscher.com/pages/viewpage.action?pageId=112430702
Auf seite 139 hat es ein timing diagramm für transfers ohne CS-wackler.

Fpgakuechle K. schrieb:
> Damit es auch mit 8 bit CPU/µC funktioniert?! SPI stammt aus dem Jahre
> 1987.

Vielleicht der Begriff. SPI als Protokoll ist mindestens seit den 60ern, 
zumindest seit es Schieberegister gibt. Und schon damals war es ohne 
CS-toggle.

Matthias S. schrieb:
> Hängt oft vom Slave ab. Manche Slaves latchen mit der steigenden Flanke
> von /SS die Daten intern in die Register.

Ja. Aber genau da spielt man ja alle Daten erstmal ein und Deselect 
dann.

Ein Device, dass jedes Byte mit einem Deselect abschließt, braucht 
filigrane andere Mechanismen zur Kompensation um z.B. Steuerkommandos 
und Daten zu unterscheiden, mehr als 8-Bit-Werte zu übertragen oder 
überhaupt gezielt daten zu lesen.

Mit durchgehendem CS können die ersten 1,2 oder mehr Bytes als 
Steuerkommandos, Leseadresse oder was immer interpretiert werden. Bei 
dauerndem CS gibt es kein erstes, zweites, ... Byte.