Senden von ADC-Messungen mit UART

Ich möchte das Signal messen ADCund Messungen an den PC senden, um Diagramme zu erstellen.

Mein Code:

ADC_SoftwareStartConv(ADC3);
while(1)
{
    ADC3ConvertedVoltage = ADC3ConvertedValue * 3300/0xFFF;
    ADCresultsTab[i] = ADC3ConvertedVoltage;
    sprintf(str,"%u",ADC3ConvertedVoltage);
    USART2_SendText(str);
    USART2_SendText(";");
}

Das Problem ist, dass ich das Signal so schnell wie möglich abtasten möchte. Hier verwende ich baud rate = 256000(nur Windows). Was ist die Möglichkeit, Signale schneller abzutasten? Was ist ein optimalerer Code für die Proben- und Sendemessung?

Ich sehe, dass das Problem dort UARTdie Übertragung ist.

Und meine zusätzlichen Fragen sind: Ist es Echtzeitmessung mit diesem Code? Wie sollte es gemacht werden, wenn ich eine Echtzeitmessung möchte?

Anzeige. so schnell wie möglich: Überprüfen Sie das Datenblatt (also fügen Sie einen Link dazu hinzu), wie schnell der ADC tatsächlich ist. Anzeige. Zusatzfrage: Definieren Sie zunächst Ihre Anforderung an „Echtzeit“.
Aber da ist auch das Problem mit dem uart Senden von Daten. Ich weiß, dass die Begrenzung die ADC-Geschwindigkeit ist, aber im fraglichen Code wird sie durch das UART-Senden von Daten verlangsamt. Meine Frage ist, wie man es effizient implementiert, um die Messgeschwindigkeit nicht zu begrenzen. Ich verstehe den zweiten Teil der Frage nicht, ich dachte, dass es eine "Echtzeit" -Definition gibt?
Unterbricht. Der ADC kann eine Konvertierung durchführen, während die Daten durch UART verschoben werden. Während der Konvertierung tut die CPU nichts und Sie können diese Zeit nutzen, um den UART-Puffer mit Daten zu füllen.
Oder DMA, obwohl Sie wahrscheinlich zwei DMA-Streams einrichten müssten (DAC zu Speicher, Speicher zu UART).
Erledigen Sie die harte Arbeit (Division und Multiplikation) auf dem PC. Wenn Sie DMA-Fähigkeiten auf der MCU haben, verwenden Sie sie.
Wenn der Zweck der Übertragung auf den PC darin besteht, Echtzeit-Diagramme zu erstellen, nehmen Sie sich einen Moment Zeit, um darüber nachzudenken, wie diese Daten auf der Benutzerseite verwendet und interpretiert werden können. Das Zeichnen von Daten mit 8 Millionen Abtastwerten/Sekunde in Echtzeit ist für die Visualisierung einfach nutzlos. Auch das "so schnell wie möglich" ist etwas rückständig. Beginnen Sie mit „so schnell, wie ich es zum Arbeiten brauche“, setzen Sie eine Zahl darauf und streben Sie danach, es zu erreichen.

Antworten (2)

Während ein ausgefeilterer Interrupt- oder DMA-basierter Code erforderlich wäre, um die beste Leistung zu erzielen, würden relativ geringfügige Verbesserungen an Ihrem Code die Situation bereits verbessern. Ich würde damit beginnen, Samples in Binärform statt in Text zu übertragen. Dies erfordert etwas mehr Arbeit auf der Empfängerseite, reduziert jedoch die erforderliche UART-Bandbreite um mindestens das 2-3-fache (2 Bytes pro Abtastung gegenüber bis zu 6 in Text mit Trennzeichen). Sie können die Baudrate auch problemlos auf zB 921,6 kbps erhöhen, was Standard ist und auf der Empfängerseite gut unterstützt werden sollte. Unter der Annahme einer Standard-STM32F2-Architektur könnten Sie bis zu 7,5 Mbit / s erreichen, aber Sie müssten die Unterstützung dafür auf der Empfängerseite überprüfen.

Bei 2 Bytes pro Sample und 921.6kbps ergäbe sich ein Durchsatz von ca. 46'000 Samples/s. Bei 7,5 Mbit/s erhalten Sie 370.000 Samples/s. Wenn Ihre Anwendung dies zulässt, können Sie die Auflösung auf 8 Bit reduzieren und somit ein einzelnes Byte pro Sample verwenden, wodurch sich der Durchsatz in Samples/s effektiv verdoppelt.

Während 370 kSamples/s nicht schlecht sind, sind sie immer noch ziemlich weit von den theoretischen 6 Msamples/s entfernt (unter der Annahme von STM32F2, 12-Bit-Konvertierung und Verwendung des 3 ADC im Triple-Interleaved-Modus). Dies entspricht 12 MB/s an Daten, die von der MCU auf den Computer übertragen werden müssen, was keine unbedeutende Menge ist. UART geht nicht. SPI mit maximal 30 Mbit / s (2-3 MB / s) reicht auch nicht aus. Das Schreiben auf eine microSD-Karte per SDIO käme dem nahe. USB 2.0 würde es tun, ist aber softwaremäßig viel komplizierter und erfordert externe Komponenten für den PHY. ETH würde auch gut funktionieren, würde aber zusätzliche Komponenten und einen Netzwerk-Stack erfordern, der auf der MCU implementiert werden müsste. Diese Komplexität erklärt, warum in den meisten Anwendungen die Samples im Speicher gepuffert und asynchron übertragen werden.

Erwähnenswert ist, dass STM32 USART eine theoretische Spitze von 4 Mbit / s hat und realistisch zu einem PC über einen FTDI-Dongle vielleicht maximal 3 Mbit / s. Einige spezifische RS485-Setups könnten vielleicht etwas höher gehen.

Es ist wahrscheinlich auch erwähnenswert, dass der sprintfAufruf wahrscheinlich ziemlich langsam ist und (wenn Sie ihn nur einmal verwenden) eine Menge Bibliothekscode einzieht. Selbst wenn Sie für Menschen lesbares ASCII beibehalten möchten, könnten Sie die Nummer wahrscheinlich viel schneller selbst serialisieren als sprintf. Wenn Sie schon dabei sind, könnten Sie das Semikolon in die Zeichenfolge einfügen und nur einen Aufruf an USART2_SendText.