Can Kosar

Author: solocan (page 1 of 8)

Software-Struktur eines Effektblocks

Bei der Audioverarbeitung hat objektorientierte Programmierung große Vorteile. Dazu zählen:

  • Mehrmalige Instanzierung der Sub-Blöcke in anderen Blöcken
  • Mehr Speicherverwaltungsmöglichkeiten
  • Übersichtlichere und verständlichere Programmstruktur

Besonders die Möglichkeit der mehrmaligen Instanzierung der Sub-Blöcke in anderen Blöcken ist ein entscheidendes Argument für die Wahl einer objektorientierten Sprache. Aus dem Grund wurde z.B. das Projekt Flex 500 mit C++ programmiert. Dabei ist jeder Effektblock als eine Klasse realisiert (,die ggf. andere Klassen instanzieren kann).

Die Grundelemente einer Klasse sehen folgendermaßen aus:

Standardinhalt einer Klasse beinhaltet folgende Methoden bzw. Attributen:

  • init() : Hier werden der Block, Subblöcke und Initialparameter initialisiert.
  • start(): Diese Methode wird ausgeführt, wenn ein Block gestartet wird.
  • stop(): Diese Methode wird ausgeführt, wenn ein Block gestoppt wird. (z.B. reset() triggern)
  • set_parameter_xyz(): Mit diesen Methoden, werden die Parameter, die vom Controller mitgeteilt werden verarbeitet und die Klassenparameter aktualisiert.
  • status: Das ist der Flag, ob der Block aktiv oder inaktiv ist.

Simulationsumgebung für DSP-FX

Die Effekte und die Algorithmen auf dem Target zu testen, ist aufwändig. Aus dem Grund ist eine Simulationsumgebung entstanden, um die Algorithmen in Windows Umgebung effizient zu testen.

Das Programm kann als ein Wrapper für die Hauptroutine vorgestellt werden. Es wird hauptsächlich eine Audio-Datei eingelesen und serialisiert. Dann wird der Inhalt der Audio-Datei serialisiert und in die DSP-Hauptroutine gespeist. Das Ergebnis wird dann wiederum deserialisiert und als eine Ergebnisdatei abgelegt.

 

Main-Routine

Der Ablauf der Main-Routine ist im oberen Diagramm gezeigt. Die Implementierung ist folgendermaßen:

Der Rest ist gleich wie im Target code.

Konfiguration / Updates

Auf dem Target werden die Benutzerinteraktionen interpretiert, um die DSP-Einstellungen zu aktualisieren. Bei der Simulation gibt es keine Echtzeit Interaktionen. Daher werden die Module mit erwünschten Einstellungen „initialisiert„. Dann laufen die Module mit diesen festen Einstellungen.

Ausnahme hierzu ist die Aktivierung der Module. Auf dem Target wird ein Wort gesendet, wo jedes Bit auf den Status eines Moduls hinweist. Hierbei muss dieser Hash aktuell manuell modifiziert werden, um die Module zu aktivieren:

Ressourcen

Der Code samt Eclipse-Projekt ist auf Github verfügbar:

Die DSP-Simulation Quellcode vom   herunterladen.

 

 

STM32 SAI Konfiguration

STM32 besitzt je nach Chipvariante eine serielle Audio-Schnittstelle SAI. Durch diese Schnittstelle kann über übliche Protokolle mit Audio-Codecs kommuniziert werden.

Audio-Clocks

Das Codec und die SAI-Schnittstelle müssen synchronisiert werden. Dabei gibt es konkrete Vorgaben bzw. Randbedingungen seitens Codecs.

  • Audio-Abtastfrequenz F_s wählen.
  • Den Multiplikator k_{MCLK} (Codecs haben oft Multiplikatortabellen z.B. 256 oder 512 bei 48kHz) wählen.
  • Daraus die erforderliche Master-Clock-Frequenz berechnen. (Oft F_{MCLK}F_s \cdot k_{MCLK})
  • Master-Clock-Quelle konfigurieren (Externer Quarz bzw. interne Clockquellen)

Übertragung

Unter dem Aspekt gibt es (wie für viele andere Hardwarekomponenten) hauptsächlich drei Möglichkeiten eine Codec-Schnittstelle zu steuern bzw. auszulesen:

  1. Normaler Modus (Blockierend)
  2. Interrupt-Modus (Nicht-blockierend)
  3. Per DMA auslesen (Nicht-blockierend)

Bei einer echtzeitkritischen Audio-DSP-Anwendung kommt nur DMA-Schnittstelle in Frage. Die Konfiguration der Software und Hardware ist hier beschrieben.

SAI und DMA Konfiguration

Beim Flex 500 ist feste 48kHz Abtastrate gewählt. Bei CS4272 kann der Multiplikator 256 oder 512 gewählt werden. Um auch zukünftig 96kHz zu unterstützen wurde hierbei 512 gewählt. Zu Stabilitätszwecken wurde für einen externen Quarz entschieden. Die Frequenz des Quarzes berechnet sich also als

(1)   \begin{equation*} F_{MCLK}=F_S \cdot k_{MCLK} = 48000 \cdot 512 = 24,576 MHz \end{equation*}

In dem Fall ist der Codec der Master und generiert den Bitclock. Der DSP ist Slave und erhält den Bitclock und dazugehörige Streams.

Die Konfiguration sieht folgendermaßen aus:

Low level Treiber: (*_hal_msp.c)

SAI Konfiguration

Starten vom Treiber

DMA Interrupts setzen die Flags. Die Software Architektur ist hier beschrieben.

Die CODEC-Treiber sind hier beschrieben:

CS4272 CODEC-Schnittstelle für Nucleo H743

WM8731 CODEC-Schnittstelle für Nucleo H743

Ressourcen

Der vollständige Code vom Communication Stack befindet sich auf den Repositories vom Controller und DSP unter den Ordnern „hw„.

DSP – Targetcode vom herunterladen

Controller- Targetcode vom   herunterladen

STM32 ADC: Expression-Pedal Steuerung

STM32 hat je nach Chipvariante einen oder mehrere Analog-Digital-Wandler (ADC).

Der ADC konvertiert die am analogen Eingang anliegende Spannung in einen binären Wert. Dafür braucht er allerdings ein Paar Zyklen- je nach Einstellung aber mindestens um die 3 Zyklen. Zudem läuft ADC mit niedrigerer Frequenz als der Cortex-Kern. Man muss also wissen, dass eine Konvertierung einige Prozessorzyklen lang dauert.

Unter dem Aspekt gibt es (wie für viele andere Hardwarekomponenten) hauptsächlich drei Möglichkeiten einen Analog-Digital-Wandler zu steuern bzw. auszulesen:

  1. Normaler Modus (Blockierend)
  2. Interrupt-Modus (Nicht-blockierend)
  3. Per DMA auslesen (Nicht-blockierend)
Normaler Modus

In diesem Modus läuft das Sampling im Hauptprogramm. Das heisst, man triggert das Sampling an, wartet(!) darauf, dass das Sampling fertig ist und macht weiter im Hauptprogramm. Das bedeutet viele verlorene Zyklen und darf nur in Ausnahmefällen bzw. in nicht leistungskritischen Applikationen eingesetzt werden.

Interrupt Modus

Im Interrupt-Modus stößt das Hauptprogramm das Sampling an und macht weiter mit seinen Aufgaben. Wenn das Sampling fertig ist, löst die ADC-Hardware einen Interrupt aus. Mit Hilfe dieses Interrupts kann dann dem Hauptprogramm mitgeteilt werden, dass nun das Register den neuen Digitalwert beinhaltet.

DMA MODUS

Im DMA-Modus schaufelt die DMA-Hardware im Hintergrund die ADC-Werte. Dabei wird die ADC-Hardware in den kontinuierlichen Modus gesetzt. Das heißt, sie fängt gleich mit dem nächsten Sampling an, wenn sie mit einem fertig ist. Das ist oft der effizienteste Modus.

 

Beim Projekt Flex 500 wird z. B. das Expression-Pedal mit einem ADC interrupt-gesteuert gelesen. Der Grund dafür ist, dass man die Frequenz mit einem Timer einstellen möchte.  Die ADC-Hardware ist folgendermaßen konfiguriert. Das

Nach jedem Lesezyklus triggert man dabei das nächste Sampling. Das Interrupt wird dabei allerdings nicht benutzt, da der Zyklus kurz ist und das Interrupt sonst das Hauptprogramm unnötig oft unterbrechen würde.

Andere Möglichkeit wäre eben per DMA, dass man dabei die Hardware nur starten und stoppen muss:

Die Konfiguration des Timers ist folgendermaßen. Bei einer CPU-Frequenz von 216MHz ergibt sich eine Timerfrequenz von:

(1)   \begin{equation*} f_{TIM3}= \frac{216\cdot 10^6}{(1600+1)*(10000+1)} \approx 13.5Hz \end{equation*}

Ressourcen

Der vollständige Code vom Communication Stack befindet sich auf den Repositories vom Controller und DSP unter den Ordnern „hw„.

DSP – Targetcode vom herunterladen

Controller- Targetcode vom   herunterladen

DSP<->Controller Kommunikation

Die Hardwarearchitektur vom Flex 500 ist hier beschrieben. Die Kommunikation zwischen DSP und Controller läuft über eine SPI-Schnittstelle. Auf der Controller-Seite werden Mitteilungen interrupt-gesteuert gesendet, da die Mitteilungen von mehreren Instanzen aus geschickt werden können und DMA zu ständigen Unterbrechungen auf der DSP Seite führen würde.

Auf der DSP-Seite wird die Mitteilung, die über SPI-Schnittstelle erhalten werden, mit DMA an den Programmspeicher kopiert. Danach wird ein Interrupt ausgelöst, wonach der DSP den Befehl verarbeiten kann.

Die Struktur der Mitteilung

Die Struktur der Mitteilung ist im folgenden dargestellt.

  • Bank Id: Die ID der Effekt-Bank.
  • Type: Der UI-Controller type, der sich geändert hat: Encoder oder Button
  • Id: Der ID des UI-Controllers (Button number oder Encoder number)
  • Data: Data in (Float, 32bit, 16bit, 8bit mit oder ohne Vorzeichen)

Die Übertragung der Mitteilung

Die Mitteilung liegt im Programm im Typ „union“, der die Typen

  • Float
  • 32bit unsigned
  • 16bit unsigned
  • 8bit unsigned

beinhaltet.

Daten dieses Typs müssen über SPI übertragen werden. Dabei wird der Vorteil genutzt, dass sowohl Sender als auch der Empfänger gleiche Endianness benutzt. (Beide Cortex-M7) Das heißt, wir können einfach den Speicherbereich, wo die Mitteilung liegt, schicken. Dann castet der Empfänger auf dieselbe Union zurück und die Daten liegen in der erwünschten Struktur beim Empfänger an.

Code vom Sender

wobei ctrl_tx des Typs „Unions“ ist.

Code vom Empfänger

Ressourcen

Der vollständige Code vom Communication Stack befindet sich auf den Repositories vom Controller und DSP unter den Ordnern „com„.

DSP – Targetcode vom herunterladen

Controller- Targetcode vom   herunterladen

Hardware Architektur – Verteiltes System

Übliche Systemarchitektur eines Audioprozessorsystems wie das vom Flex 500 ist ein verteiltes System. Die Aufgaben werden dabei auf mehrere Prozessoren verteilt. Bei einer leistungs- und echtzeitkritischen Anwendung wie ein Audio-Prozessor ist das oft unverzichtbar.

Hardware-Architektur

Die Hardware-Architektur vom Flex 500 ist im folgenden Bild gezeigt:

Audio-DSP

Spezialisierte Audio-DSP-Chips

Der Kern eines typischen Audio-Prozessors ist ein DSP-Chip. Lange Zeit wurden dafür ausschließlich dafür konzipierte Audio-DSPs, wie z.B. die von Texas Instruments und Analog devices eingesetzt. Die Audio-DSPs haben Befehlsätze, die für Audiodatenverarbeitung typisch sind und eine effiziente hardwaregestütze Verarbeitung der Daten ermöglichen. Dazu gehören viele spezialisierte SIMD-Befehle. (Single Instruction Multiple data) wie MACs (Multiplier+Accumulator). Diese ermöglichen schnelle Verarbeitung von z.B. Biquad-Filtern, ein sehr verbreitetes digitales Filter oder aber auch viele andere Algorithmen, wo sequentielle Multiplikation und Addition-Folgen größerer Daten nötig ist.

MehrZweck-Mikroprozessoren (General purpose Microprocessors)

Mittlerweile sind die Leistung und die Befehlssätze der Mikroprozessoren rasant gestiegen. Heutzutage sind viele Prozessoren mehrere Hundert Megahertz schnell getaktet und bieten u. a. DSP-Einheiten für SIMDs und Gleitkommazahl-Einheiten (FPUs). Aufgrund ihrer breiten Verfügbarkeit und vielseitiger Einsatzmöglichkeiten jenseits der Audio-Verarbeitung, sind die Mehrzweck-Mikroprozessoren zu einer echten Alternative gegenüber der herkömmlichen Audio-DSPs geworden.

Ein Spitzenreiter unter denen ist die Prozessoren auf Basis von ARM Cortex-M7. Diese Prozessoren sind bis zu 600MHz getaktet, besitzen DSP und FPU Einheiten. Ein Vergleich von Cortex-basierten Prozessoren gegenüber der herkömmlichen, verbreiteten Produkte von Texas Instruments und Analog devices ist im folgenden Artikel detailliert aufgeführt:

Choosing the best processor for your DSP application

DSP capabilities of Cortex Processors

In diesen Studien ist sichtbar, dass die High-End Spezialprozessoren für manche spezialisierte Tasks wie MAC-Leistung immer noch die Nase vorne haben. Allerdings sind die Cortex Prozessoren auch sehr leistungsfähig und können ihre Stärken bei allgemeineren Tasks spielen, wofür die Spezialprozessoren keine HW-Unterstützung anbieten.

Aus den genannten Aspekten wurde für den Flex 500 ein STM32H743 mit 400MHz Taktrate, DSP und FPU-Einheiten gewählt.

Controller-Chip

Ein Controller-Chip übernimmt oft alle sonstigen Aufgaben wie die allgemeinen Verwaltungsaufgaben, GUI-Steuerung, Anzeige etc. Die Echtzeitansprüche an den Controller-Chip ist niedrig, dafür muss er viele Tasks abarbeiten. DSP und Controller-Chips unterscheiden sich voneinander vor allem in deren Softwarearchitektur.

Der DSP-Chip muss mehrere Tasks schedulen und abarbeiten. Eine Middleware wie FreeRTOS ist dafür sehr gut geeignet, wenn die Komplexität und die Tasks steigt. Man kann auch „Bare-metal“ programmieren und eigenen Scheduler schreiben.

Je nach benötigter Leistung und Peripherien kann man einen Mikroprozessor wählen, der diese Aufgaben erledigt. Auch hierbei  ist ARM Cortex-M sehr gut geeignet und verbreitet.

Beim Flex 500 muss der Mikrocontroller

  • GUI Inputs und Outpus managen
  • Eine kleine Grafikbibliothek treiben
  • Kommunikation zum DSP aufbauen.
  • Expression-Pedal und Fußschalter treiben
  • Sonstige HW steuern (Leistungsstufe etc.)

Als Controller von Flex 500 ist der STM32F767 von ST gewählt, der mit 216MHz Taktfrequenz und zahlreiche Schnittstellen all diese Aufgaben erledigen kann. Für diesen Zweck ist vermutlich auch ein kleinerer Cortex-M4 vollständig ausreichend.

Display-Treiber

Der Controller-Chip ist von der Prozessorleistung her sehr stark und besitzt  auch ein Display-Treiber. Allerdings ist die verfügbare interne RAM mit 512 sehr knapp für Grafikanwendungen. Um die interne RAM für sonstige Aufgaben freizuhalten, ist ein externer Display-Treiber gewählt.

Die Lösung für Display hängt stark von Anforderungen an. Eine sehr gute Übersicht ist im folgenden Paper von ST verfügbar:

LCD-TFT display controller (LTDC) on STM32 MCUs

Beim Flex 500 ist ein Display mit integriertem Chip ILI9341 eingesetzt.

 

Flex 150 – Analoger Bassgitarrenverstärker

Flex 150 ist ein Experimentierprojekt für die Umsetzung eines analogen 150W-Class-AB-Bassgitarrenverstärkers.

 

Unter dem Bastelgehäuse stecken:

  • 150W-Class-AB-Verstärker
  • Kleinsignalstufe mit EQ und Compressor
  • 200W lineares Netzteil für die Leistungsstufe
  • 30W lineares Netzteil für die Kleinsignalstufe

Ressourcen

Die Design- und Simulationsressourcen von diesem Projekt können hier heruntergeladen werden:

Flex150 Leistungsverstärker LTSPice Simulationsdateien herunterladen.

Flex 150 KiCAD-Designdateien herunterladen.

150W Class-AB Verstärker-Design

Das Design eines 150W-Mono-Class-AB-Verstärkers ist im folgenden dokumentiert. Dieser Verstärker ist im Bassgitarrenverstärker-Projekt Flex 150 eingebaut.

Architektur

Open-Loop vs. Closed-Loop Architektur

Die ersten Verstärker hatten eine „open-loop“-Architektur, d.h. sie waren offene Steurung, die aus einer Spannungsverstärker- (Voltage amplifier stage) und einer Stromverstärkerstufe bestand.

Die Spannung wurde durch einfache Transistor (oder Röhren-)schaltungen verstärkt. Das allein bringt sehr bescheidene Ergebnisse. Der wirkliche Durchbruch bei Audio-Verstärkern ist durch die Einführung der „Closed-Loop“-Verstärkern erreicht. Das heißt, der ganze Verstärker war ein Regelkreis. Da die Spannungs- und Stromverstärkerstufen sehr hohe Verzerrungen aufweisen (s. Beitrag zu VAS) ist Ausgangssignal abgezweigt, skaliert und vom Eingangssignal abgezogen. Diese neue Stufe hieß Differenzverstärker und die Architektur sah folgendermaßen aus:

Das heißt, die Fehler, die durch VAS und Puffer entstehen, sind wieder in den Eingang negativ zurückgeführt, dass diese wieder ausgebügelt werden.

Komponenten

Differenzverstärkerstufe

Die Differenzverstärkerstufe ist in diesem Beitrag erklärt und die Dimensionierung berechnet.

Spannungsverstärkerstufe

Die Spannungsverstärkerstufe ist in diesem Beitrag erklärt und die Dimensionierung berechnet.

Stromverstärkerstufe und Rückkopplung

Eine sehr gute Quelle, in der das Leistungsverstärkerdesign ausführlich erklärt wird ist das praktische Standardwerk vom Bob-Cordell: Designing Audio power amplifiers.

150W Class-AB Verstärker

Für die praktische Umsetzung sind die Ressourcen eines hochwertigen 150W-Class-AB Verstärkers verfügbar, der im Projekt Flex 150 eingebaut ist.

Ressourcen

Die Leistungsstufe im Projekt Flex-150 ist ein Class-AB Verstärker entwickelt mit min. 150W Dauerlast. Spitzenlasten liegen weit höher, da das Design auf linearem Netzteil basiert. Die Design- und Simulationsressourcen von diesem Projekt können hier heruntergeladen werden:

Flex 150 Bassgitarrenverstärker

Flex 150 Leistungsverstärker LTSPice Simulationsdateien herunterladen.

Flex 150 KiCAD-Designdateien herunterladen.

Tuner: Darstellung der Noten und Abweichungen

Nachdem die Frequenz ermittelt wurde, muss nun dem Anwender dargestellt werden, welche Soll-Note erkannt wurde und wieviel die berechnete Ist-Note von der Soll-Note abweicht, damit dieser sein Instrument stimmen kann.

Abschätzung der Soll-Note

Dabei wird gesucht, welcher Notenfrequenz, die gemessene Frequenz am nächsten ist. Da die Frequenzskala logarithmisch ist, müssen die Schranken von einzelnen Noten bestimmt werden, die von der Hauptfrequenz +-50 cent entfernt sind.

Berechnung der Schranken

Die Schranken, die 50 cent von der Hauptfrequenz entfernt sind, werden zunächst einmalig berechnet. Wenn sich die Kammertonfrequenz f_{KT} (z.B. A4=440Hz) ändert, müssen die Schranken wieder berechnet werden, aber nicht in jedem Messzyklus.

Die Frequenzen der Hauptnoten berechnen sich als

(1)   \begin{equation*} \begin{aligned} f_{i,50c}&=\frac{f_{KT}}{ 2^{\frac{i}{12}}}\\ i&\in \mathbb{N} \end{aligned} \end{equation*}

Dann können wir die 50 cent verschobene Frequenzen als

(2)   \begin{equation*} \begin{aligned} f_{i,50c}&=\frac{f_{KT}}{ 2^{\frac{i-0.5}{12}}} \\ i\in \mathbb{N} \end{aligned} \end{equation*}

berechnen.

Die Implementierung kann folgendermaßen realisiert werden:

Suche nach den Schranken

Dafür eignet sich der binäre Suchalgorithmus, wenn wir keine Vorschätzung haben. Falls wir eine Vorschätzung haben (ein guter Ansatz ist die letzte gemessene Schranke zu nehmen) eignet sich auch die lineare Suche.

Im folgenden ist die Implementierung mit einem modifizierten binären Suchalgorithmus gezeigt.

Berechnung der Abweichung

Die Abweichung von der Soll-Note kann folgendermaßen berechnet werden.

Für die Zuordnung des Notenindex zur Notenbezeichnung ist ein String-Array hinterlegt.

Der gesamte Ablauf der Notenfindung sieht also folgendermaßen aus.

Ressourcen

Vollständigen Target-Code der Tuner-Anzeige vom Github herunterladen.

ältestenposts

Rechte © 2024 Can Kosar

Mit Unterstützung von Wordpress, QuickLaTeX und Design von Anders NorenSeitenanfang ↑