Antizipieren von Verarbeitungsverzögerungen in eingebetteten Systemen

Hintergrund:

Ich habe mit dem STM32F3 Discovery Board gearbeitet und versuche, einige Signalverarbeitungsalgorithmen von Grund auf zu implementieren. Mein Problem ist unten in der Grafik dargestellt. Je mehr Abgriffe ich einem FIR-Filter hinzufüge, desto länger ist die Verzögerung zwischen dem Eingangssignal und dem DAC-Ausgangssignal. Bei den von mir verwendeten Audiosignalen führt eine Verzögerung von über 40 us zu einer hörbaren Verzerrung, die meine Filterfähigkeiten einschränkt. Es macht es auch schwierig, das Filter zu entwerfen, da die Abtastrate durch die Rechenzeit begrenzt ist (die nächste Eingabe kann nicht verarbeitet werden, bis die vorherige an die Ausgabe gesendet wird).

Ein schneller Test der Zeitverzögerung zwischen einem Eingangssignal und dem uC DAC-Ausgang

Fragen:

Gibt es Hardware- oder Softwarestrukturen, die ich verwenden sollte, um die Leistung zu verbessern?

Wenn ich die Leistung nicht verbessern kann, sollte ich meinen Filter mit einer Abtastrate entwerfen, die die Anzahl der Vorgänge berücksichtigt, die ich zwischen den Abtastungen durchführen muss, und die Vorgangszeit aus dem Datenblatt?

Ich habe die CMSIS-Bibliotheken nicht ausprobiert, da ich ein besseres Gefühl für die tatsächlichen Algorithmen bekommen wollte, aber würden diese Bibliotheken die Leistung verbessern?

Codeschnipsel: (Verallgemeinert für IIR-Filter)

while (1)
{
    dreadADC();
    FilteredValue=filter(ADC1ConvertedValue);
    DAC_SetChannel2Data(DAC_Align_12b_R, FilteredValue);
}
uint16_t filter(__IO uint16_t nValue)
{

    for(i=(Taps-1);i>0;i--)
    {
        x[i]=x[i-1];
        y[i]=y[i-1];
    }
    x[0]=nValue;
    y[0]=0;
    for(j=1;j<Taps;j++)
    {
         y[0]= y[0]+(b[j]*x[j])-(a[j]*y[j]);
    }
    y[0]=y[0]+(b[0]*x[0]);
    return y[0]+1024;
}

ADC-Timing-Setup

ADC_RegularChannelConfig(ADC1, ADC_Channel_7, 1, ADC_SampleTime_1Cycles5);

DAC-Timing-Setup

TIM_TimeBaseStructure.TIM_Period = 2-1 ;          
TIM_TimeBaseStructure.TIM_Prescaler = 1-1;       
TIM_TimeBaseStructure.TIM_ClockDivision = 1-1; 

Danke für deine Zeit und ich würde mich über jede Anleitung freuen!

Ihre Anforderung von weniger als 40 us Verzögerung ist für "Audio" ziemlich verdächtig und wird (Theorie, unabhängig von der Implementierung) für alle außer der trivialsten Filterung unerreichbar sein.
Ich habe 40 us als Schwellenwert für eine Abtastfrequenz von 25 kHz eingestellt, was dem oberen Bereich des menschlichen Gehörs entspricht. Idealerweise möchte ich auch hier mehr als einen Abtastpunkt pro Periode zur Signalrekonstruktion. Ich dachte, dass der STM32F3, der mit einem 72-MHz-Takt läuft, der Aufgabe gewachsen wäre. Wenn dies nicht erreichbar ist, wie würde man vorgehen, um einen digitalen Filter für Hochfrequenzsignale zu implementieren?
Das Problem ist theoretisch: Unabhängig von der Rechengeschwindigkeit hat jeder nützliche diskrete Zeitfilter eine Verzögerung von mehreren Abtastperioden, da verzögerte Versionen des Signals im Filterausdruck erscheinen (explizit für ein FIR, implizit und normalerweise auch explizit für ein IIR). Nur wenn Sie jeden anderen Pfad, zu dem Sie die Verzögerung messen, vergleichbar verzögern können, können Sie weniger erreichen.
Was ich sagen will, ist, dass Ihre Berechnung zwar mit Ihrer Datenrate Schritt halten muss, der Großteil Ihrer Verzögerung (mehrere Abtastperioden) jedoch darauf zurückzuführen ist, dass Sie auf die erforderlichen Eingabeabtastungen warten, um eine Ausgabe zu berechnen (plus eventuell verwendetes Pipelining).

Antworten (1)

Suchen Sie eine Bibliothek, die FIR-Filter in Assembly implementiert. Ich bin mir zu 100% sicher, dass es eine DSP-Bibliothek für STM32 gibt.

Schreiben Sie alternativ Ihren eigenen Code, der erweiterte Funktionen im Kern verwendet.

Das könnte die Rechengeschwindigkeit verbessern, erlaubt aber immer noch nicht den Entwurf von antikausalen Filtern. Es gibt eine minimale durchschnittliche Verzögerung in Samples für einen bestimmten Filter, unabhängig davon, wie Sie die Berechnung implementieren.