da bin ich 100% einverstanden! Nur sehen das halt viele anders... Ich werde jedenfalls weiterhin die 'richtige' Technologie am richtigen Ort einsetzen und habe auch schon mit Vergnügen z.B. bei meinem KW-Transceiver im Jahr 1992 Röhren- und Microcontrollertechnik miteinander verheiratet.
!!!
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.
BernhardWGF: Als meine Boards vor einigen Tagen ankamen, habe ich zunächst die sehr gute Doku zu den Boards gelesen und geschaut was für Dreingabe der Hersteller gemacht hat (digital Micro, Gyro, Beschleunigungssensor, Audio DACs ....), dann die Datenblätter runtergeladen und die Treiber von Null auf selbst programmiert. Klar, ich hätte auch einfach die Demos von STMicroelectronics drauf flashen können, aber für meine Hobby-Experimente habe ich höhere Ziele gesteckt, als nur den Umgang mit dem ST-Link zu lernen!
ich habe zu den von Bernhard vorgestellten Boards auch ein bisschen gegoogelt. Ich finde das gerade diese Dreingabe für den Start sehr wichtig ist. Das hat mir an meinem Starterkit sehr gut gefallen. Diese im Kasten vorhandene Hard- und Software ist ähnlich einem Elektronikexperimentierbaukasten aufgebaut. Die Experimentiervorschläge haben mir einen relativ schnellen Überblick gegeben. Das führte von Anfang an dazu, die einzelnen Codes abzuändern und zusätzliche Funktionen zu schreiben und einzubringen. Gerade für völlig unbeleckte Interessenten finde ich das wichtig. Man kann mit einfachen Schaltungen viel Spaß und Erfolgserlebnisse haben, da die Steuerung über eigene Codes zu einem echten Aha- Erlebnis wird. Ich weiß nicht genau wie das beim STM32F4 ist. Es gibt aus meiner Sicht dort für den Einstieg nicht so viel beigelegte kleinteilige Peripherie. Das Board hat schon einen sehr professionellen Charakter und die technischen Daten sprechen für sich. Plattform STM32 Waveshare Open407V-D Development Board STM32 Cortex M4 STM32F407V mit STM32F4DISCO Pack B wäre für mich später mal interessant. Googelt mal bei Eckstein.....aber der Preis steigt schon enorm.
A: Discoveryboard mit STM32F407VG: 1-Mbyte Flash memory, 192-Kbyte RAM, als Dreingabe: LIS3DSH ST MEMS 3-axis accelerometer, MP45DT02 ST-MEMS audio sensor omni-directional digital microphone, CS43L22 audio DAC
und
B: Discoveryboard mit STM32F429: 2 Mbytes of Flash memory, 256 Kbytes of RAM, zusätzlich 64-Mbit SDRAM,2.4" QVGA TFT LCD Touchscreen, L3GD20, ST-MEMS motion sensor 3-axis digital output gyroscope
Vorweg, ich habe beide genommen.
Auf A habe ich angefangen mich erstmalig mit dem STM32 Cortex M4 zu beschäftigen, die vielen kleinen Zusatzchips sind für den Einstieg super geeignet, besonders das PDM-Micro und der CS43L22 auf dem Board sind reizvoll für den Einstieg in die digitale Signalverarbeitung im NF-Bereich. Auch wollte ich mit diesem Board meine selbstgeschriebenen MP3/AAC - Codecs weiter testen und optimieren. Das geht mit A ohne zusätzliche Hardware und Strippen auf dem Schreibtisch, nur USB Programmier und Debugkabel liegt rum. Leider fehlt ein schönes Display um mal eine FFT sichtbar zu machen, aber man kann damit leben.
Bei B hingegen war das zusätzliche 2.4" Touchscreen und die zusätzlichen 64-MBit SDRAM ausschlaggebend für den Kauf. Ein solches Display kostet bei Amazon auch schon 13-15 EURO und dann hat man einen haufen Strippen (ist ja kein SPI) zu ziehen, bei B alles wunderbar aufgelötet und inklusive. Man kann auch mal eine FFT oder Wasserfall zeichnen und schöne GUIs selbst programmieren. Auch eine kleine 3D Grafikengine ist eine tolle Beschäftigung. Auf die 64MBit zusätzlichen RAM-Speicher habe ich geschielt, weil man damit genügend Speicher für umfangreiche Signalverarbeitungsroutinen hat. Man kann auch mal eine FFT und Wasserfall zeichnen ohne groß auf den Speicher achten zu müssen, zudem viel Platz für Daten im SDR-Bereich. Auch möchte ich später etwas im Bereich DVB und Videocodecs experimentieren. Ich habe dafür ja auch noch ein STM32F7-Board gekauft.
Für mich als Bastler ist B somit eine tolle Fortführung von A und keine Konkurrenz. Für spätere Projekte und Einzelgeräte kann ich dann immer noch ein Breakoutboard mit dem Prozessor kaufen und sämtliche Zusatzperipherie per Flachbandkabel anstecken. Zum Experimentieren auf dem Schreibtisch sind A und B jedenfalls super geeignet.
Und die Möglichkeit die Dinger mit Eclipse und GCC programmieren zu können war für mich als Hobby-Mann zusätzlich ausschlaggebend, ich muß keine hunderte oder tausende an EURO für eine Entwicklungsumgebung ausgeben.
Jetzt könnte die Frage kommen, warum nehme ich nicht für alles einen Raspberry oder Odroid? Habe ich schon gemacht, auch habe ich mit solchen 4-Kernern schon Radios neu gebaut und modernisiert. Jetzt will ich mal alles ohne ein Linux und mit viel weniger RAM und CPU-Rechenkraft machen. Task und Speicherverwaltung ohne einen Pinguin im Rücken erledigen. Ich möchte erkunden welche Aufgaben auf kleiner "Hardware" noch machbar sind und mal die Grenzen solcher MCUs und von DSPs kennenlernen.
Und Hemmungen einen Prozessor mit Röhrentechnik zu kombinieren habe ich auch nicht wie man sehen kann.
ich hatte mir ja gleich ein 2.8" Touchscreen (TP28017) + SDCard zum Starterkit mitbestellt und schon vor einiger Zeit die Demos getestet. Das ist natürlich ein echtes Highlight. Hier zeigte sich aber schnell ein Nachteil bei der Arduino Plattform mit Mega2560. Es werden ein Teil der Kommunikationspins und vier Analogpins beim direktem Aufstecken verdeckt und werden unbenutzbar. Außerdem braucht dieses komfortable Display halt fünf PWM- Ausgänge mehr und da ich sehr viele Versuche kombiniert auf meinem Experimentierboard zusammengestellt habe, wollte ich nicht abspecken und habe das LCD 1602 wieder eingesetzt. Ich bau jetzt wieder um, da nun meine Konfiguration für die nächste Zeit klar ist. Sechs analoge und alle digitalen In/Out + 1x TX, Rx, SDA, SCL verbleiben. Hier ein Bild des TFT (noch mit Schutzfolie) auf meinem Prototype Expansion Board aus dem Starterkit. Die unzugänglichen Pins könnte ich zur Not auch herausführen....sprich löten. Das Zusatzboard wird direkt auf den 2560 aufgesteckt. Leider ist die extra Resettaste nur noch mit Aufwand zu betätigen, da ebenfalls verdeckt. (seitlich unter der Backplane oben rechts)
Beim B- Pack mit STM32 fand ich das Open407V-D Development Board besonders gelungen. Es kommt wie ein Motherboard daher. Der STM32 wird in der Mitte aufgesteckt. Alle Abgänge frei zugänglich....richtig gut gelöst!
Gruß
Joerg
Arduino Expansion Board oder auch Mega 2560 werden vom 2,8" Display in großen Teilen verdeckt. Aber auch hier kein Gebamsel mit extra zugeführten Verbindungen wie mit LCD 1602 durch direktes Aufstecken.
PS... Anhangbezeichnung falsch...nicht 2.4" sondern 2.8" ist richtig.
Das Buch ist auch als ebook über Universitätsbibliotheken kostenlos verfügbar. Wie das geht? Man benötigt einen Leseausweis einer Universitätsbibliothek in seiner Nähe. Die Mitgliedschaft ist in der Regel kostenlos, da Universitätsbibliotheken öffentliche Bibliotheken sind. Hat man den Leseausweis und seine Zugangsdaten erhalten, geht man über den OPAC-Katalog der jeweiligen Bibliothek zum Buchtitel.
Es können übrigens alle Bücher, welche online verfügbar sind (und welche über ein solches Symbol verfügen) kostenlos als eBook bezogen werden. Das sind tausende Fachbücher oder Magazine.
Durch Auswahl des Titels kommt man zur Onlineseite des entsprechenden Anbieters (Springer, Elsevier,...) und kann dort das Buch kostenlos zur wissenschaftlichen Nutzung downloaden.
Lesen lässt sich so ein Buch dann am Besten über einen dieser Ebookreader oder Tablet PC. Ich benutze gern einen Amazon Kindle Fire auf dem ich mittlerweile meine ganze Fachbibliothek (auch alte Titel) aufgespielt habe.
weiter oben (http://www.wumpus-gollum-forum.de/forum/...n-58_323_8.html) hatte ich mir ja einige Entwicklerboards von STM mit den Cortex M4 und M7-Rechenwerken gekauft. Da diese Boards vom Hersteller als "DSP-tauglich" beworben werden, wollte ich diesen Werbespruch im Rahmen eines SDR-Projekts überprüfen.
Zunächste habe ich die "kleineren" Prozessoren der Serie (den F407 und F411) auf dem DISCOVERY-Evalboard benutzt um ein komplettes Radio in "Software" zu Definieren. Eine wertvolle Hilfe war dabei das Simulieren der verwendeten Algorithmen in Matlab bzw. Octave im Vorfeld der Umsetzung.
Die HF wird von einer Aktivantenne (MiniWhip außerhalb des Hauses) eingefangen. Nach anschließender Selektion und Signalkonditionierung gelangt das Antennensignal an den AD-Wandler des Prozessors. Hier erfolgt eine hochfrequente Abstastung und somit eine Digitalisierung der Antennenspannung für den weiteren Bearbeitungsprozess. Im nachfolgenden Digital-Down-Converter (DDC) gelangt die digitalisierte HF über einen in Software umgesetzten Mischer/LO (via CORDIC https://de.wikipedia.org/wiki/CORDIC) auf einen Tiefpassfilter mit anschließender Unterabtastung. Das so dezimierte Signal wird in den Algorithmen der Basisbandverarbeitung demoduliert, erneut gefiltert und in einen PCM-Datenstrom umgewandelt. Der PCM-Datenstrom gelangt über das I2S-Protokoll an den auf dem DISCOVERY-Board verbauten Audiocodec (CS43L22). Hier erfolgt die Analogisierung des demodulierten Signals und anschließende Verstärkung auf Kopfhörer-/Lautsprecherniveau.
Bedingt durch die Abtastraten des AD-Wandlers des Prozessors von bis zu 2.4 MHz und 7.2 MHz im Interleave-Mode, ist es möglich mit dem Discovery-Board den Frequenzbereich von wenigen kHz (VLF), über die Langwelle (LW) bis an die Ränder des unteren Mittelwellenbandes direkt und ohne weiteren Mischer zu empfangen.
Ein solcher kleiner SDR lässt sich durch Einschleifen in die ZF eines Radios auch für höhere Frequenzbereiche einsetzen. Durch die flexible Softwarefilterung und Softwaredemodulation könnte so ein "normales" Radio auch zu einen Amateurfunk- oder DRM-Empfänger umgerüstet werden.
etwa so habe ich meinen DCF77-Empfänger aufgebaut, allerdings mit einem ARM7-Controller, für 77.5kHz reicht das. Deine Variante ist bei mir in der Pipeline, ich setze mich momentan mit den Datenblättern des Cortex M4 auseinander, um abzuschätzen, was hier drinliegt. Kosten tut das ja nichts mehr...
Für den Down-Konverter muss man nicht unbedingt mit CORDIC-Algorithmen arbeiten, da der Cortex M4 Single-Cycle-Multiplikationen beherrscht und auch viel Flash-Speicher hat. Daher habe ich eine Sinustabelle mit 256 Werten (16 Bit) abgelegt und zwischen den Tabellenwerten linear interpoliert. Das ergibt eine Genauigkelit von fast 16 Bit, was bei einem 12bit-A/D-Wandler ausreicht. Auch der ARM7 schafft das locker, trotz des wesentlich langsameren Multiplizierers. Beim Cortex kann man sogar weiter optimieren und den Cosinus und Sinus parallel rechnen, wenn man die SIMD-Arithmetik nutzt, was aber zwingend Assemblercode bedeutet. Die 'normale' Variante geht auch in C.
Zur Zeit benutze ich noch verschiedene FIR/CIC Implementierungen (neben eigener Codierung - man will ja was lernen - die CMSIS DSP-Libs, sowie BLOBs der DSP Bibliotheken von Robinson Labs). Die Umschaltung kann während der Laufzeit über Softwareschalter erfolgen, so hat man den direkten Vergleich. Was die Codeoptimierung in Asm für den M4 angeht, da bin ich ehrlich gesagt aufgeschmissen und voll vom GCC abhängig. Ich habe zwar einiges an Literatur zur ASM-Programmierung der Kerne, aber ich glaube den GCC mit seinen Optimierungsstufen werde ich als Anfänger auf dieser Plattform noch lange nicht erreichen können. Aber auch mit C kommt man bei diesen Prozessoren gut klar. Ich tüftle auf jeden Fall weiter an der Sache...
PS: Läuft das Video bei Euch? Bei mir wird es nicht im Browser eingebunden / angezeigt.
vermutlich ist eine Kombination von CIC- und IIR-Filter für den Tiefpass am besten, da IIR-Filter bei gegebenem Rechenaufwand die besten Filterkurven geben (elliptische Filter sind da extrem gut, kannst du mit Matlab simulieren, so bekommst du auch gleich die Parameter). Das CIC-Filter ist bei der hohen Samplingfrequenz vor der Dezimation angesagt, das es kaum Rechenaufwand braucht (ein vierstufiges Filter kommt mit 4 Additionen auf der schnellen Seite aus).
Die Bibliotheken sollten optimiert sein, da verlierst du nur noch die Zeit durch den Overhead, der für einen C-Funktionsaufruf notwendig ist, und der ist recht klein. 'Normale' Funktionen kann GCC sehr gut optimieren, aber die SIMD-Befehle (also parallele Operationen) kann er nicht, da hier in C die Sprachmittel fehlen. Auch 'gesättigte' Arithmetik (also Begrenzung der Resultate auf +/-MaxInt statt Overflow) geht in C nicht, da die Sprachmittel fehlen. Allerdings kann man bei 32 Bit Auflösung häufig die Skalierungen so wählen, dass gar kein Overflow auftreten kann, da die effektive Genauigkeit ja nicht so gross sein muss, 16 Bits sind mehr als genug für die meisten Fälle. Aber auch konventionell kommt man recht weit, mein ARM7 hat ja noch keine DSP-Befehle und auch keine SIMD-Instruktionen und nur 50MHz Taktfrequenz. Somit bist du schon ganz gut dran.
Der ARM-Assembler ist gar nicht so schwer und im Vergleich zu anderen Architekturen (insbesondere von TI) recht logisch, wenn auch bei den Cortex gewisse Abstriche gemacht wurden. Aber es braucht Einarbeitungszeit, und wenn C reicht, geht es natürlich auch so. Für alle, die noch nie Assemblercode gesehen haben, ist hier als Beispiel der Assemblercode für die Sinus- unc Cosinusberechnung aus Tabelle und Interpolation (die Tabelle habe ich weggelassen, Code ist für ARM9, aber der ist fast identisch zum Cortex M4):
ldr r12, = SinTab @ Pointer auf die Tabelle and r3, r0, #0xFF00 @ H-Byte extrahieren, wird Tabellenindex add r12, r12, r3, lsr #7 @ Sinus-Adresse = SinTab + 2 * Highbyte(Winkel) @ Sinus ldrsh r4, [r12] @ r4 = Tabellenwert[Highbyte(Winkel)] ldrsh r5, [r12, #2] @ r5 = nächster Tabellenwert für Interpolation and r6, r0, #255 @ r6 = Lowbyte Winkel sub r5, r5, r4 @ r5 = Sin[n+1] - Sin[n] smulbb r5, r5, r6 @ r5 = (Sin[n+1] - Sin[n]) * Lowbyte(Winkel) (16bit * 16bit, jeweils die unteren Halbwöerter) add r2, r4, r5, asr #8 @ r2 = Sin[n] + (Sin[n+1] - Sin[n]) * Lowbyte(Winkel) = Sin(Winkel) @ Cosinus: cos(x) = sin(x+90) -> 90° vom Winkel subtrahieren, nur Tabellenindex ändert, Offset bleibt @ Tabelle hat 256 Werte für 360° -> für 90° muss 64 Werte vorwärts gesprungen werden, was 128 Bytes entspricht add r12, r12, #128 ldr r0, = SinCos - 4 @ Adresse des Tabellenendes cmp r12, r0 @ Adresse > Tabellenende (Wraparound)? subge r12, r12, #512 @ falls ja, Tabellenlänge (256 Words zu 16 Bit) subtrahieren ldrsh r4, [r12] @ r4 = Tabellenwert[Highbyte(Winkel)] ldrsh r5, [r12, #2] @ r5 = nächster Tabellenwert für Interpolation sub r5, r5, r4 @ r5 = Sin[n+1] - Sin[n] smulbb r5, r5, r6 @ r5 = (Sin[n+1] - Sin[n]) * Lowbyte(Winkel) (16bit * 16bit, jeweils die unteren Halbwöerter) add r1, r4, r5, asr #8 @ r1 = Cos(Winkel)
Das hinter den @ ist Kommentar. Ist doch schön kurz... und der Cortex M4 bietet noch etwas Vereinfachung mit neuen Befehlen.
Anmelden
Einzelleistung!