für ein SDR braucht es gar nicht so viel, wenn man effektiv programmiert, für einen AM-/SSB-Empfänger reicht schon ein ARM7, wenn man auf der analogen Seite eine gewisse ZF-Vorfilterung vornimmt. Andererseits täuschen die hohen Taktfrequenzen auch Rechenleistungen vor, die gar nicht vorhanden sind, da die 'schnelleren' CPUs wegen Pipeline-Stalls häufig für die gleiche Befehlssequenz mehr Taktzyklen brauchen als die älteren, 'langsameren'. Auch können die CPUs ihre Geschwindigkeit nur dann nutzen, wenn das Programm im internen RAM ausgeführt wird, externe Speicher oder Flash ist für Taktfrequenzen oberhalb etwa 30MHz zu langsam und bremst den Prozessor aus.
Der GCC-Compiler ist eine gute Wahl, ich benutze diesen auch für verschiedene ARM-Architekturen, und er erzeugt sehr effizienten Code, wenn man die Code-Optimierung entsprechend einstellt, dabei bedeutet schneller auch mehr Speicherverbrauch. Richtig schnell wird der Prozessor aber erst mit Assembler-Programmierung, aber das ist definitiv nicht Jedermanns Sache, und schon gar nicht für 'Neulinge'.
Auf jeden Fall viel Spass beim Weiterbasteln. Für nächsten Winter brauche ich auch noch ein Projekt, nach dem analogen Transistor-Spitzensuper wäre die (teilweise) digitale Variante eine Option...
!!!
Fotos, Grafiken nur über die
Upload-Option des Forums, KEINE FREMD-LINKS auf externe Fotos.
!!! Keine
Komplett-Schaltbilder, keine Fotos, keine Grafiken, auf denen
Urheberrechte Anderer (auch WEB-Seiten oder Foren) liegen! Solche Uploads werden wegen der Rechtslage kommentarlos gelöscht!
Keine Fotos, auf denen Personen erkennbar sind, ohne deren schriftliche Zustimmung.
09.08.17 20:43
BernhardWGF
nicht registriert
09.08.17 20:43
BernhardWGF
nicht registriert
Re: Bernhards Radiobasteleien...
Hallo HB9,
genau dafür habe ich die Boards gekauft. Den HF-Teil werde ich konventionell umsetzen, eine relativ niedrige ZF mit zwei (I/Q) ADCs samplen. Soetwas habe ich schon einmal mit einem Odroid C2 gemacht, aber ich will diesmal sehen ob das auch auf kleineren Systemen funktioniert und die Discovery Kits von STMicroelectronic bieten sich da ja regelrecht an. Assembler habe ich mal vor Jahrzehnten gehabt, heute vertraue ich darauf das der GCC mit seinen Optimierungsstufen halbwegs guten Code übersetzt. Ich denke da habe ich wieder einige Wochen was zu basteln.
es geht auch sehr gut mit nur einem ADC, das I- und Q-Signal kann auch sehr einfach nach dem A/D-Wandler erzeugt werden, wenn man die Samplingfrequenz genau auf das Vierfache der ZF legt. So spart man sich den 2. Wandler und entlastet den Prozessor. Wenn der Jitter vom Samplingzeitpunkt des A/D-Wandlers genügend klein ist, kann man auch eine höhere ZF wählen und bewusst durch Aliasing auf eine niedrige ZF heruntermischen, so gibt es keine Spiegelfrequenzprobleme (z.B. Samplingfrequenz 100kHz, ZF 925kHz, ergibt durch Aliasing in der digitalen Ebene eine ZF von 25kHz). Es muss lediglich sichergestellt sein, dass das Samplingtheorem für die ZF-Bandbreite nicht verletzt wird, im vorherigen Beispiel ist ein ZF-Bereich von 900..950kHz erlaubt, also 50kHz Bandbreite, und das sollte analog gut hinzukrigen sein, und 100kHz Samplingfrequenz schafft ein Cortex locker, zudem kann man nach einer ersten digitalen Filterung die Samplingfreqenz reduzieren.
Bei meinem DCF77-Empfänger habe ich das so gemacht, wegen der tiefen HF von 77.5kHz gab es analog keinen Mischer, die Empfangsfrequenz wurde direkt mit 200kHz abgetastet, mit einem I/Q-Mischer mit numerischem Oszillator auf DC gemischt und das I- und Q-Signal ein erstes Mal gefiltert, Samplingrate auf ca. 6kHz reduziert, ein zweites Mal gefiltert, danach auf 100Hz Samplingrate, hier mit einem sehr steilflankigen FIR-Filter gefiltert, demoduliert und danach in C die Nutzdaten dekodiert. Das Ganze läuft auf einem ARM7 mit 50MHz Takt. Für die Vorfilterung und Reduktion der Samplingrate eignen sich übrigens CIC-Filter sehr gut, da hier nur addiert werden muss.
ich habe die Tage mal einen Vergleich der zuletzt von mir hier vorgestellen Mikrocontrollersysteme vorgenommen. Auf allen Prozessoren wurde das gleiche C-Programm mit unterschiedlichen mathematischen Tests laufen gelassen. Als Compiler kam in allen Fällen der GCC zum Einsatz, mit Optimierungsstufe 3.
Interessant ist ein Wertevergleich von ESP8266 (ohne FPU) bei 160 MHz, STM32F407 (mit FPU) bei 168 MHz und dem ESP32 (mit FPU) ebenfalls bei 160 MHz. Während der ESP8266 sich mit Gleitkommazahlen abmüht - er muß alles in Software rechnen - ist die Gleitkommaarithmetik im Hardwareteil (FPU) der STM32-Systeme und des ESP32 kein Problem. Auch die Ganzzahlmultiplikation, sie ist wichtig bei Aufgaben der Signalverarbeitung zum Beispiel bei digitalen Filtern, bringt die "größeren" Rechenwerke nicht ins Schwitzen. Die beiden Cortex-Kerne der STM32-Chips werden vom Hersteller sogar für die Eignung als Signalprozessor beworben, nicht ganz zu Unrecht.
Auffällig ist auch das der STM32F746 mit niedrigerem Systemtakt nahezu die gleiche Leistung wie ein Kern des ESP32 bei 240MHz hat. Besseres Rechenwerk? Wahrscheinlich nicht. Ein Multicore-Test des ESP32 steht noch aus. Man sollte nicht verschweigen das der ESP8266 und der ESP32 zusätzlich noch etwas Rechenleistung für das (nicht abschaltbare) WLAN bereitstellen muß und das das Benchmarking "nur" mit der Rest-CPU Zeit rechnen konnte. Dennoch die Vorteile einer FPU und eines DSP-Rechenwerks sind offensichtlich.
PS: Der kleine 8-Bit - Arduino/MEGA 2560 mit seinen 16 MHz hatte nie eine Chance gegen die 32-Bitter, dennoch sollen seine Werte nicht verschwiegen werden.
Viele Bastlergrüße und immer ein Bit überbehalten Bernhard
PPS: Das Benchmark-Programm wird von mir weiter entwickelt um Busgeschwindigkeiten, Speicherzugriffszeiten usw. zu bestimmen. Ich werde weiter berichten.
die Grafik ist sehr informativ. Die unterschiedlichen Änderungen der Performance bei verschiedenen Taktfrequenzen deuten darauf hin, dass die Geschwindigkeit der Speicher oder Peripherie bei hohen Taktfrequenzen nicht mehr reicht und den Prozessor des STM ausbremst, so dass die höhere Taktfrequenz nicht mehr sehr viel bringt und so die "Konkurrenz" aufholen kann.
Bei ARM-Prozessoren (STM) hängt die Performance übrigens noch stark von der Programmierung ab. Werden die in einer Funktion benutzten Variablen lokal alloziert (in C heisst das 'automatic') oder in einem Struct zusammengefasst, wird der Code kürzer und schneller als wenn man sie als einzelne globale oder statische Variablen definiert. Der Grund liegt darin, dass der ARM nur indirekt adressieren kann und somit für jeden Variablenzugriff zuerst ein Register mit der Adresse der Variablen laden muss. Bei einem Struct muss er nur einmalig die Anfangsadresse des Structs in ein Register laden und kann danach die einzelnen Elemente mit einem Offset auf die Anfangsadresse adressieren, solange der Offset nicht zu gross wird. Das gilt natürlich auch für Arrays.
Eine weitere Beschleunigungsmöglichkeit bei den ARM6- und ARM7-Architekturen, zu denen der STM gehöhrt, ist die parallele Verarbeitung ('SIMD' = single instruction, multiple data). Der Prozessor kann mit einem Befehl nicht nur 2 32bit-Operanden miteinander addieren, subtrahieren oder multiplizieren, sondern alternativ parallel 2 gleiche Operationen mit 16bit-Operanden machen, wobei jeweils 2 Operanden in demselben 32bit-Register stehen. So wird die Geschwindigkeit bei der Operandenbeschaffung und der Berechnung verdoppelt, allerdings geht das nur, wenn die Variablen so im Speicher stehen, dass mit einem 32bit-Zugriff auch die richtigen beiden 16bit-Operanden in das Register kommen. Weiter muss der Compiler auch merken, dass er hier optimieren kann. Somit dürfte diese Optimierungsmöglichkeit normalerweise Handarbeit bleiben, lohnt sich aber für kleine, rechenintensive Funktionen, die dann in Assembler programmiert werden. Signalverarbeitungs-Bibliotheken nutzen das natürlich auch.
vielen Dank für deine Antwort. So viele Bastler die mit solchen Chips arbeiten scheint es in den (deutschsprachigen) Radioforen ja leider nicht zu geben. Eigentlich schade, denn das Thema SDR findet hier zuwenig Beachtung meiner Meinung nach. Vielleicht kannst Du deinen DCF77 SDR ja mal im Forum vorstellen. Da kann ich sicher viel von lernen und vielleicht inspiriert es doch den einen oder anderen Bastler sich mal mit der neuen Technik zu beschäftigen. Auch bin ich auf dein (Teil-DSP)-Spitzensuper gespannt.
den DCF77 kann ich mal vorstellen, leider ist der Prozessor bereits abgekündigt, aber informativ ist es ja trotzdem, und ein ARM7 ist ja nicht so anders wie ein Cortex... Der C-Code für die Dekodierung der Zeit ist sowieso HW-unabhängig.
BernhardWGF:So viele Bastler die mit solchen Chips arbeiten scheint es in den (deutschsprachigen) Radioforen ja leider nicht zu geben. Eigentlich schade, denn das Thema SDR findet hier zuwenig Beachtung meiner Meinung nach.
ja warum ?
Manches mal sehe ich die Freunde des WGF naserümpfend vor solchen Beiträgen sitzen. Was hat das denn alles mit unserem geliebten alten Radio zu schaffen. Ich denke, eine ganze Menge....aber um hier Leute mitzureißen, muss man die Leser versuchen zu erreichen. Das größte Problem sind diese schrecklichen Fachtermini. Diese sind einerseits nötig um sich klar auszudrücken, führen aber zu schnellem Abschalten bei nicht eingeweihtem Publikum. Ein echtes Problem und daher sind in den Radioforen hier solche Basteleien und Versuche eher unterrepräsentiert. Versucht doch bitte euch nicht mit Fachbegriffen zu übertreffen...und zeigt den digitalen Skeptikern neue und überhaupt nachvollziehbare Wege auf. Erst dann greift die Inspiration, zeigen und erklären in verständlichen Worten. Hinweise dazu geben, Links setzen und anschaulich dokumentieren. Die Hochsprache zurückschrauben, übersetzen und mit einfachen Vergleichen neue Freunde dazugewinnen.....denn es geht hier ja wirklich um Radio! Zu mindestens auf der Bastlerebene!
Zitat. Manches mal sehe ich die Freunde des WGF naserümpfend vor solchen Beiträgen sitzen. Was hat das denn alles mit unserem geliebten alten Radio zu schaffen.
Woher nimmst Du diesen Eindruck? Ich beanspruche ihn zumindest nicht für mich und würde ihn auch anderen Mitgliedern nicht unterstellen wollen. Ich verfolge sehr wohl jeden Beitrag, kann mich aber nicht zu jeden äußern.
Mit vielen Grüßen. Wolle.
Wissen ist der einzige Rohstoff, der sich durch Gebrauch vermehrt.
ja es gab im WGF schon skeptische Äußerungen zu solch einer Thematik!
....und es war erstens so gemeint wie Bernhard es beschrieben hat ( siehe Zitat ) und ich sehe es anhand der Reaktionen im WGF, Nachfragen etc... zu Bernhards grandiosem Beitrag. Echt innovativ.....so empfinde ich "Bernhards Radiobasteleien". Ich sehe es an den Reaktionen, ich sehe, dass über die Simulation des magischen Auges hinaus,....kaum Fragen oder Interesse vorhanden sind. (Eröffnungsthema) Alles wunderbar dokumentiert.... MA.....Internetradio.... SDR....Prozessoren...etc.... ist das noch old radio world? Mein Eindruck... ja!. Daher mein Hinweis an die Freunde der digitalen Verarbeitung den Versuch zu wagen, die Skeptiker mit ins Boot zu holen. Die Verbindung zwischen analoger und digitaler Welt verständlicher zu beschreiben um weitere Interessierte zu finden....... Ursachenforschung inbegriffen! Mehr nicht...
Anmelden
Ich denke, eine ganze Menge....aber um hier Leute mitzureißen, muss man die Leser versuchen zu erreichen. Das größte Problem sind diese schrecklichen Fachtermini. Diese sind einerseits nötig um sich klar auszudrücken, führen aber zu schnellem Abschalten bei nicht eingeweihtem Publikum. Ein echtes Problem und daher sind in den Radioforen hier solche Basteleien und Versuche eher unterrepräsentiert. Versucht doch bitte euch nicht mit Fachbegriffen zu übertreffen...und zeigt den digitalen Skeptikern neue und überhaupt nachvollziehbare Wege auf. Erst dann greift die Inspiration, zeigen und erklären in verständlichen Worten. Hinweise dazu geben, Links setzen und anschaulich dokumentieren. Die Hochsprache zurückschrauben, übersetzen und mit einfachen Vergleichen neue Freunde dazugewinnen.....denn es geht hier ja wirklich um Radio! Zu mindestens auf der Bastlerebene!