Kurzum: was muss ich im Code ändern um sagen wir mal 2 Geräte am SPI zu betreiben? Sorry ich habe dazu aber nicht wirklich etwas gefunden. Ich habe am XIAO ESP32-S3
Ich schließe beide Geräte am SPI parallel an, und jedes Gerät bekommt einen eigenen CS Pin. Aber ich weiß nicht, wie ich das im Code ändern muss. Das Display läuft die ganze Zeit und der MCP2515 sendet Daten in Echtzeit in oftmals 10-25ms.
Vielen Dank im voraus, für Eure Hilfe.
Dort wo du den CS Pin der Geräte im Code definierst, gibst du einfach deinen tatsächlich verwendeten CS Pin an, fertig.
das meine ich nicht...wenn ich am selben SPI mehrere Geräte habe muss ich dann nicht im code CS auf low ziehen wenn ich das gerät verwende ? ich meine ich habe sowas irgendwo gelesen... das meine ich.
das sollte eigentlich die jeweilige Library machen. Daher musst du den CS Pin auch dem Objekt bei der Anlage übergeben.
Das Display läuft für sich, muß nur Änderungen mitgeteilt bekommen.
Was bedeutet "sendet in Echtzeit"? Der kann doch nur senden wenn er angesprochen wird.
Genau das, wenn es nicht die zum Gerät gehörende Bibliothek macht.
Hi,
das könnte schwierig werden.
Ich kann Dir zwar nichts zu deinen eingesetzten Geräten sagen, aber an einem SPI-Bus kann nur ein Gerät zu einem Zeitpunkt aktiv sein. Ein Beispiel (was bei mir auf dem Tisch liegt): Ich empfange Daten von nRF24 Transmittern und speichere auf SD-Card. Meine nRF24 senden in regelmäßige Abständen, ich weiß also wenn der nRF24 Empfänger eingeschaltet sein muss, schmeiße die Daten in ein Array, und speichere auf SD-Card wenn das Array voll ist, wenn der nRF24 schläft (und den Bus frei gibt). Die SD-Card muss ich mit SD.begin() starten und nach dem Schreiben mit SD.end() vom SPI-Bus nehmen.
Gruß André
SPI Slaves, die den Bus beanspruchen?
Sowas gibts in der SPI Welt nicht.
Leider doch, aber zum Glück nur sehr selten.
Die genannte nRF24 Nebelkerze tut das definitiv nicht.
Nenne mir bitte ein Beispiel, nur ein einziges....
Auswendig nicht, aber genau dieses Problem wurde schon einmal hier im Forum erörtert. AFAIR habe ich damals sogar die Ursache des Problems gefunden. Erst nur als plausible Vermutung, wurde dann aber von anderen bestätigt.
Schade!
Wirklich schade!
Jetzt haben wir hier eine (aus meiner Sicht falsche) Behauptung, von 2 Leuten vorgebracht, und es gibt keine Belege.
Nein SPI ist keine demokratische Angelegenheit.
Eher eine physikalische
Einfache Frage:
Wie sollte überhaupt ein SPI Slave den Bus blockieren?
Wie?
Oder meinst du den einen falsch gebauten SD Adapter, den es mal aus Chinaland gab, wo der Levelshifter Miso dauerhaft gezogen hat.
Nee, den kannst du nicht meinen, denn der hat die Leitung NIE losgelassen.
Da hat der Boardentwickler Bockmist gebaut.
Und der Mist ist kein grundsätzlich dem SPI innewohnendes Problem.
Alle mir bekannten SPI Slave geben die Miso Leitung frei, sobald CS auf High geht.
Alle. Das ist Pflicht für alle.
(nur der eine kranke SD Adapter weigert sich)
Und ja Miso ist die einzige Leitung, an der der Slave überhaupt wackeln darf.
Indem er MISO nicht vorschriftsmäßig abschaltet.
Dann ist das SPI Gerät kaputt, bzw. falsch konstruiert.
SD, NRF24, kaputte SPI Geräte... Hat alles nix mit den Problemen des TO zu tun.
Alles Nebelkerzen
Durch die Bank.
okay ich wollte hier keinen Streit auslösen. SPI Slave ? sowas gibt nicht, wenn man weiß wie der SPI funktioniert...
Aso macht das die Bibliothek.. muss ich die Tage mal ausprobieren... herzlichen Dank für Eure Mühe. Und bitte nicht streiten.
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.