Anfrage wegen SPI auf Arduino Due

Oftmals verwendet man für CS ganz normale GPIOs, weil das CS Hardware Timing nicht zu den Anforderungen des Slaves passt.

Bei vielen Chips muss man aber mit HF Problemen bei hohen SPi Taktraten rechnen, denn die Busleitungen werden lang und komplex im Layout.

Ich habe daher auch schon mal µCs benutzt die einen SPI Bus an verschiedenen Sätzen Pins ausgeben können (und dann neben den CS auch die Pin config umgeschaltet). Das waren aber mehrere ADCs mit 8x 24-Bit Kanälen.

Atmel hat da eine - wie ich meine - sehr pfiffige Dual-Lösung eingebaut.

Zum einen kann man vier Chip Selects dezidiert verwenden und der SPI Maschine überlassen wie sie diese aktiviert. Man kann aber in einem Konfigurationsregister das Verhalten so ein- stellen dass die vier Chip Select Bits einen 1 aus 16 (oder 1 aus 8) Selector steuern mit dem man dann mehr Slaves bedienen kann ohne unnötig CS-Ausgänge zu verschwenden.

Einfach mal im Datenblatt nachlesen, steht alles drin. Nur lesen und verstehen muss man es halt. Und Leute aus der Arduino-Welt die über den Tellerrand nicht hinausschauen können oder wollen wird dieser Weg sowohl verborgen als auch verschlossen bleiben.

Hallo Jim M.

danke für die Info.

Jim M. schrieb:

Oftmals verwendet man für CS ganz normale GPIOs, weil das CS Hardware Timing nicht zu den Anforderungen des Slaves passt.

Bei vielen Chips muss man aber mit HF Problemen bei hohen SPi Taktraten rechnen, denn die Busleitungen werden lang und komplex im Layout.

Gruß bastler2022

Hallo Loocee L.

Loocee L. schrieb:

Atmel hat da eine - wie ich meine - sehr pfiffige Dual-Lösung eingebaut.

Zum einen kann man vier Chip Selects dezidiert verwenden und der SPI Maschine überlassen wie sie diese aktiviert. Man kann aber in einem Konfigurationsregister das Verhalten so ein- stellen dass die vier Chip Select Bits einen 1 aus 16 (oder 1 aus 8) Selector steuern mit dem man dann mehr Slaves bedienen kann

ist soweit ja alles richtig was Du hier schreibst. Wenn man sich auf den Prozessor und sein Datenblatt bezieht.

Loocee L. schrieb:

Einfach mal im Datenblatt nachlesen, steht alles drin. Nur lesen und verstehen muss man es halt.

Kennst Du das Datenblatt des Arduino Due und auch die Problematik mit den nicht belegten Pin ( Pins ) ?

Wir sprechen hier aber über den Arduino Due und hier hast dann nur noch 3 Chip Select zur Verfügung. Das man das Multiplexen kann hatte ich oben ja auch schon geschrieben. Selbst mit einen einfachen BCD Decoder Chip wäre das machbar aber sicher nicht die beste Variante. Deshalb hatte ich nach einer IC Empfehlung gefragt gehabt.

Loocee L. schrieb:

ohne unnötig CS-Ausgänge zu verschwenden.

Hier reden wir über 2 zusätzliche CS Pins die benötigt werden. Von der erweiterten API die ich nutze und die Bestandteil der IDE ist werden nur 3 CS Pins bereitgestellt. Hast dazu eine Idee, dann könnte ich mir das mit dem Multiplexen sparen.

Loocee L. schrieb:

Einfach mal im Datenblatt nachlesen, steht alles drin. Nur lesen und verstehen muss man es halt. Und Leute aus der Arduino-Welt die über den Tellerrand nicht hinausschauen können oder wollen wird dieser Weg sowohl verborgen als auch verschlossen bleiben.

Das lasse ich mal unkommentiert.

Allen noch ein schönes Wochenende Gruß bastler2022

Hallo zusammen,

das Problem beim Due ist, dass der verwendete MC SAM3X8E zwar viel kann, aber die üblichen Arduino-Bibliotheken das nicht unterstützen.

Verwendet man die Arduino-Biblioithek ist man selbst in der erweiterten SPI-Bibliothek auf die softwaremäßige Ansteuerung der CS-Leitungen durch die Bibliothek beschränkt.

Wenn man die hardwaremäßigen Chipselect-Fähigkeiten des SAM nutzen möchte, muss man die SPI-Interfacefunktionen des SAM benutzen, kann dann aber nicht mehr die SPI-Bibliothek verwenden.

Da ja die meisten Ardunio-Bibliotheken für die Busteilnehmer davon ausgehen, dass man die Arduino-SPI-Bibliothek verwendet, muss man auch auf diese verzichten. Das ist ziemlich ärgerlich.

Die Beschränkung, dass auf dem Arduino Due Board nur drei von vier Chipselect Pins herausgeführt wurden, ist gar nicht mal so schlimm. Die Bibliothelken sind das Problem.

Es wäre wünschenswert, wenn sich mal jemand die Mühe macht die Arduino-SPI-Bibliothek so umzuschreiben, dass sie nicht bloss softwaremäßig die Chipselectleitungen steuert, sondern dass man die Hardwarefähigkeiten des SAM konfigurieren kann.

Gruß

Jörg

Jörg schrieb:

Es wäre wünschenswert, wenn sich mal jemand die Mühe macht die Arduino-SPI-Bibliothek so umzuschreiben, ...

DU könntest dieser Jemand sein. Arduino lebt davon, dass jemand irgendwelche Bibliotheken schreibt.