Zitieren
Ich denke, das ist eher eine persönliche Geschmacksfrage als von technischen Notwendigkeiten abhängig. Zumindest im Hobbybereich.
Hat man eh schon I2C Bausteine, kann man bei I2C bleiben zumal sich Code wiederverwenden lässt und man so vielelicht ein paar Byte einspart.
(Soft-Hardware)SPI hat aber auch Vorteile... z.B. das sich da Geräte eben nicht gegenseitig beeinträchtigen da SPI Slaves meist eigene Hardware-CS Signale haben (wie z.B. Speicherkarten).
Ich seh kein Grund, um die eine oder andere Schnittstelle nen Bogen zu machen oder zu preferieren. RS232 & co ist meist langsamer aber erlaubt größere Leitungslängen... I2C ist ein Bus System.. und SPI irgendwas dazwischen.... und mit allen sind etwa gleiche Speeds möglich - je nach verwendeter Hardware. Man braucht nur eben für jedes Protokoll auch ein eigenen Protokollstack. Das ist aber immer so.. egal ob nu 1-Wire - bis hin zu Ip per Funk oder wlan. Und je aufwändiger die Hardware, um so umfangreicher der Stack. Man kann sogar die I2C oder die SPI mit RS485 Leitungstreibern versehen, Konverter für den CAN bus anbringen oder sonst was frickeln... es gibts so viele serielle Busse.. die eigentlich immer gleich funktionieren... USB und selbst SATA ist nichts anderes, nur sind die eben extrem auf Speed ausgelegt.
Die einzige Überlegung, die für dich relevant ist, dürfte aber sein: Wo bekomme ich einen stabilen Stack her, wie komplex ist der... und passt er noch zusätzlich ins ROM der CPU.
Letztlich läuft auch alles auf ein einheitliches Software Interface hinaus... getchar, putchar... (de)selektieren von Geräten per open und close, Fehlerbehandlung, Ringbuffer für send/receive, Softwarefehlerkorrektur usw... zumindest wenn man es anständig programmiert. Denn auch da lassen sich dann später Synergieen nutzen. Da auf dem RP6 aber eher Lowlevel-Bitgefrickel betrieben wird, dürften so Ansätze aber eher Theorie bleiben... was mich wieder zu meinem Eingangssatz bringt.
Gruß Rolf
Lesezeichen