Hallo, ich sehe es immer häufiger, dass bei manchen SPI Slaves (z. B. bei einigen ethernetbasierten Protokollchips) nach jedem Byte auf der SPI erwarten, dass man den CS setzt/rücksetzt. Ist gerade beim Senden von vielen Daten nervig, da man das ganze quasi als ineffiziente for-Loop aufziehen muss. Dass es gemacht werden muss, weil der Hersteller es vorschreibt und es sonst nicht funktioniert ist klar. Aber weiß jemand, warum das aus Sicht des Herstellers notwendig ist?
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.
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.
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: > Beispielsweise der netX90. Aha, "Kleinster Multiprotokoll SoC"… Das ist kein SoC, sondern ein µC. Und das "Datenblatt" hat drei Seiten und ist eigentlich ein Werbe-Prospekt. Wo findet man denn da etwas, das man auch wirklich als Datenblatt bezeichnen kann?
Milton schrieb: > 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. Das ist Unsinn. Der netX90 ist kein "Netzwerkcontroller" sondern ein SoC für industrielle Kommunikationsanwendungen. Die Kernaufgabe ist nicht das Versenden von Netzwerktelegrammen. (Kann er auch, aber dafür wohl etwas überdimensioniert) Das SPI Interface ist nicht optimal, aber mitnichten muss man nach jedem Byte das CS Signal loslassen, sondern genau das Gegenteil ist der Fall. Ich zitiere mal aus dem Ref-Manual: | ... The chip-select signal must permanently remain active during | an access sequence (an inactive chip-select will terminate a transfer). Das übliche Interface zu dem Chip ist auch nicht SPI. Normalerweise implementiert man seine Applikation auf dem im netX90 integrierten Cortex-M4. (Er hat zwei, einen für die Applikation, einen für die Protokollfirmware - die kommt von uns) Der Chip hat übrigens nicht nur zwei Cortex-M4 sondern noch 10 weitere Cores und zwei integrierte Ethernet Phys ich würde also nicht unbedingt von einem "µC" sprechen. Um genau zu sein ist es ein Software-Defined Switch mit für Industrieaufgaben ausgesuchten Peripherien. Rolf M. schrieb: > und ist eigentlich ein Werbe-Prospekt. Wo findet man denn da etwas, das > man auch wirklich als Datenblatt bezeichnen kann? https://kb.hilscher.com/pages/viewpage.action?pageId=112430702
:
Bearbeitet durch User
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.
Andreas M. schrieb: > Rolf M. schrieb: >> und ist eigentlich ein Werbe-Prospekt. Wo findet man denn da etwas, das >> man auch wirklich als Datenblatt bezeichnen kann? > > https://kb.hilscher.com/pages/viewpage.action?pageId=112430702 Danke.
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.
Hängt oft vom Slave ab. Manche Slaves latchen mit der steigenden Flanke von /SS die Daten intern in die Register.
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.