Kombinieren der Ausgänge mehrerer SPI-Geräte

Ich habe ein Projekt mit einer Reihe digitaler Mikrofone, an deren Ausgang ich mit einem leistungsstarken ARM-Mikroprozessor eine ausgefallene Signalverarbeitung durchführen möchte.

Ich mag die Idee, digitale Mikrofone zu verwenden, weil ich mich nicht mit Vorverstärkern herumschlagen muss. Wie auch immer, jedes digitale Mikrofon ist mit einem dedizierten Mikrocontroller verbunden, der die PDM-Ausgabe in PCM umwandelt.

Ich muss in der Lage sein, die Daten jedes Mikrofons auf meinen ARM-Mikroprozessor zu übertragen. Nehmen wir an dieser Stelle an, dass alles synchronisiert ist, um den Anschein eines gleichzeitigen N-Kanal-Sample-and-Hold-ADC zu erwecken. Meine derzeitigen Gedanken sind, dass jeder an ein Mikrofon angeschlossene Mikrocontroller seine Daten bis zu einem gewissen Grad puffern und über SPI spülen würde, wenn seine Slave-Auswahl vom Master wackelt. Der Meister würde einfach nacheinander mit jedem Sklaven sprechen.

Meine Frage ist, gibt es eine elegantere Möglichkeit, dies zu implementieren?

Dies wäre wahrscheinlich ein perfekter Job für einen FPGA, aber das übersteigt im Moment ein wenig mein Können.

Sind Sie sicher, dass die SPI-Datenrate für diesen Job ausreicht? Wie auch immer, Slaves mit Chipselect-Eingängen reichen aus.
Ausgezeichnete Frage. Einige anfängliche Tests führten zu einer Geschwindigkeit von bis zu 10 MHz. Der Durchsatz wird natürlich etwas geringer sein. Gibt es ein schnelleres Kommunikationsprotokoll, das ich verwenden könnte?
Für Multimedia gibt es etwas namens I2S (nicht I2C). Ich habe es nie benutzt oder darüber gelesen, aber vielleicht solltest du es tun :)
I2S würde perfekt passen. Wenn Sie Fragen dazu haben, verwende ich es ziemlich regelmäßig in meinen eigenen Projekten, damit ich helfen kann
I2S ist auf vielen ARM-Familien implementiert, zB Cortex-M-Teile wie STM32F2/3/4. In ihrem Fall ist es als Erweiterung von SPI implementiert und unterstützt normalerweise 16-, 24- und 32-Bit-Übertragungen. AFAIK, seine Hauptfunktion besteht darin, „richtige“ Audiodaten zu verschieben, wobei es wichtig ist, das Sampling mit einem sehr stabilen Takt zu synchronisieren, um Jitter zu minimieren, der angeblich bei CD-ähnlichen Abtastraten hörbar ist. Zu diesem Zweck kann der Takt eine viel höhere Frequenz als die tatsächliche Abtastrate haben. Sie werden also möglicherweise mehrere Male schneller als SPI, müssten aber an beiden Enden der Übertragung I2S-fähige Geräte verwenden.
Es sei darauf hingewiesen, dass das, was @gbulmer sagt, zwar wahr ist, aber wahrscheinlich nur für die uC-zu-ADC/DAC-Kommunikation gilt, bei der die Uhren eng mit den Abtastraten verknüpft sind. SPI-Hardware verwendet typischerweise eine Anordnung von Puffern und Schieberegistern, um die Abhängigkeit von der Uhr des Hosts (im Fall eines Slaves) zu entkoppeln. Daher ist die uC-zu-uC-Kommunikation in dieser Hinsicht flexibler, wenn SPI verwendet wird.
Nun, wenn die dedizierte MCU, die mit dem Mikrofon verbunden ist, das I2S-Protokoll unterstützt, sehe ich keinen Grund, warum Sie es nicht uC-zu-uC verwenden könnten. Es ist kein super kompliziertes Protokoll. Aus Neugier, was ist der wichtigste ARM-Controller, den Sie verwenden möchten?
STM32F7, es unterstützt I2S als Erweiterung des SPI-Protokolls :)
Erwägen Sie auch SPI- unabhängige und Daisy-Chain- Optionen, abhängig von den genauen Timing-Anforderungen. Für unabhängige und wenn keine Pins mehr vorhanden sind, könnte einer vom STM als "Slave-Inkrement" für einen anderen uC verwendet werden, der sich als Slave-Select-Treiber verhält. Wieder je nach Timing-Bedürfnissen.

Antworten (1)

Slaves mit Chipselect-Eingängen sind keine schlechte Idee. Dieser Weg kostet viele Ports Ihrer MCU, aber wenn Sie diese Ressourcen haben, empfehle ich, bei dieser Idee zu bleiben. Wenn Sie mit RTOS vertraut sind (freertos.org ist eine kostenlose gute Option), können Sie Code wie einen SPI-Treiber implementieren, um die Kommunikation zwischen allen Slaves zu teilen und zu schalten. Ich habe dies in einigen meiner Projekte getan. Ich habe meinen Treiber "SPIShared" genannt.

Durch die Verwendung eines RTOS-Mutex schützen Sie jeden Slave, um eine vollständige Transaktion mit Ihrem Master durchzuführen. Danach wird der Mutex freigegeben, um eine neue Kommunikation zu ermöglichen.

Beobachtung: Sie können eine gemeinsam genutzte SPI erstellen, obwohl jede einen anderen Slave-Standard hat. Vor jeder Transaktion müssen Sie Ihr SPI-Peripheriegerät mit dem Slave-Kommunikationsstandard neu initialisieren.

Kombinieren der Ausgänge mehrerer SPI-Geräte
AntwortenHierDatenschutz-Bestimmungen1y, 0v