gesucht: eine preisgünstige, anpassbare Ethernet-Oszi-Lösung, die fest verbaut werden kann. gefunden - uralt, aber gut: Beitrag "100MHz DSO Selbstbau ohne FPGA mit STM32?" Kontext mein aktuelles Projekt: resonanter DC-DC Gegentaktwandler 3... 5 kW, 48 <-> 570 V, um meine Gabelstapler-Akkus nach v2g ("vehicle-to-grid")-Manier in meine PV-Stromspeicherung einzubinden. Vorlage u.a. TI Design Guide: TIDM-02002 (s. Bild) Challenge: tuning von Bauteilen und Taktung für ZVS / ZCS (zero-voltage - zero-current switching) Wunschzettel für eine inline-Diagnose: - 6 Signale: je DC-Spannung und Strom sowie Brückenstrom primär und sekundär - 4 galvanische level - 100 ... 200 ... 500 kHz Betriebsfrequenz - Auflösung 50 samples / Vollzyklus minimal, 200 wäre schön - oszis in der Brücke fest verbaut - Triggern und Abfrage letztendlich über LAN Inspiration1: xprotolab - das kann aber nur 100 kHz Inspiration2: DSO203 - auch noch zu teuer, falsches Bedienerinterface Aber die Schaltung des DSO203 kann als Vorlage dienen: - OPA354 zur Signalaufbereitung - AD9288 dual AD 8 bit - 40 Ms (gibts auch mit 80 oder 100 Ms) - "ICE65L04F_VQ100" - dürfte ein FPGA sein - STM32F103VCT6 Den STM32 gibts als "Bluepill" für ca 2€ bei aliexpress, AD9288 dito. Die Lernkurve eines FPGA schreckt mich. Andere Leute empfehlen an der Stelle AL422 FIFO (384k, 8 bit, 20 ns). Ist zwar EOL, aber bei Ali für 1€ noch zu haben. Also laß ich vom Konzept des DSO203 alles weg was stört und Geld kostet: Gehäuse, Akku, Meßbereichswahl, Display, Knöpfe, USB. Stattdessen nehm ich so was als "Boilerplate": https://github.com/AlexPuts/Modbus-TCP-for-stm32-blue-pill/blob/master/ModbusIP_ENC28J60_STM32/examples/modbus_IP_STM_example/modbus_IP_STM_example.ino Modbus-TCP - perfekt und immer wieder mal zu gebrauchen. Die erste Überlegung war, die ADC des STM32 zu verwenden. Die sind zwar 12 bit, aber max 1 MHz. Da krieg ich bei der Resonanzfrequenz meines Konverters von 200 k grad 5 Punkte pro Vollzyklus - zu wenig. Zumindest für den Brückenstrom, von dem ich das Überschwingverhalten sehen möchte. Also ist ein Highspeed-AD wie der AD9288 irgendwie im Boot. Aber wie ansteuern? Es gibt für ca 5€ Clones von "Saleae 24MHz 8-ch Logic analyzers". Die sind sicher gut für einen Testaufbau. Aber inline macht deren USB mehr Ärger als Freude, auch wenn sie wohl unter sigrok an einer Linux-Kiste ansprechbar wären. Der STM kann wohl per DMA parallele Datenflüsse direkt in 16 bit Breite von GPIO lesen. ST AN4666 "Parallel synchronous transmission using GPIO and DMA" betreibt das bis zu 10 MHz. Ich denke, der STM32 sollte dazu die Timing-Signale für den ADC mit generieren können. Das wären 50 Samples pro Voll- oder 25 pro Halbzyklus in Resonanz - knapp, aber besser als gar nix. Im überresonanten Betrieb - da wo eigentlich der Stromverlauf interessant wird - hab ich noch 10 Samples/Halbzyklus. Das ist schon arg wenig. Wenn ich jetzt pro AD-Channel einen 8-bit fifo dazwischen häng, braucht der STM32 dem AD nur mehr Takt, Start und Rest senden. Das Auslesen des FIFO kann dann ja durchaus noch per DMA oder auch einfachem asynchronen polling erfolgen. Wenn ich das Datenblatt richtig verstehe, dann kann ich über die PLL den externen Takt HSE von 8MHz auf 4MHz runter teilen, per PLL auf 40 MHz hoch skalieren und an einem GPIO als MCO ausgeben. Könnte natürlich sein, daß ich zwischen AD und FIFO eine Phasenverschiebung brauche, damit die stabil kommunizieren. Krieg ich das auch noch über den STM hin? Oder einfach Gatterlaufzeiten eines 74HC? Klingt das jetzt alles machbar? Hat das schon mal jemand gemacht? Wenn ich es nirgends im Detail beschrieben seh' - ist das, weil es nicht klappt, oder weil es so straightforward ist, oder es noch einfacher geht?
So sieht der erwartete Stromverlauf im unterresonanten Betrieb aus. In Resonanz (200 kHz) gibts nur mehr kleine Rippel auf dem Sinus. Im Überresonanten Betrieb sehen die Rippel anders aus und sind feiner. Meßtechnisch gesehen ist das also die höhere Anforderung. In der ST AN4031 bin ich auf folgenden Satz gestoßen "This example is applicable to products STM32F2, STM32F405/415, STM32F407/417, STM32F427/437 and STM32F429/439 lines. The ADC is configured in _continuous triple Interleaved mode_ In this mode, it converts continuously one analog input channel __at the maximum ADC speed (36 MHz).__ The ADC prescaler is set to 2, the sampling time is set to 1.5 cycles, and the delay between two consecutive ADC samples of the Interleaved mode is set to 5 cycles." Diesen continuous triple Interleaved mode muß ich wohl ergooglen..... Der Bluepill hat einen STM32F103C8T6 verbaut, fällt also nicht in diese Liste. Andereseits - wenn der Aufbau einfacher wird, kann ich auch ein paar € mehr für das Board ausgeben.
Wolfgang R. schrieb: > Diesen continuous triple Interleaved mode muß ich wohl ergooglen..... > Der Bluepill hat einen STM32F103C8T6 verbaut, fällt also nicht in diese > Liste. > Andereseits - wenn der Aufbau einfacher wird, kann ich auch ein paar € > mehr für das Board ausgeben. Für 8-9€ bekommst Du schon eines dieser STM32F407-Chinaboards. Die haben dann auch schon zusätzlichen Flash-Speicher und SD-Kartenleser mit auf dem Board. Und im Gegensatz zur Bluepill sind die nicht größtenteils mit "Fake-"Controllern bestückt.
OK, wenn ich das mit dem "interleaved mode" richtig verstanden hab, dann werden einfach zwei (oder mehr) ADC parallel um einen halben Zyklus versetzt und die Ergebnisse ineineinander reißverschlußmäßig verquickt. Hier etwas Theorie dazu https://www.analog.com/en/analog-dialogue/articles/interleaving-adcs.html https://tutcris.tut.fi/portal/files/7836689/Singh_1398.pdf Das bringt bei 2 ADC des Bluepill also max 2 MHz. Vielleicht kann ich noch etwas höher gehen, wenn ich die Auflösung zurück fahr? Limitierend scheint der ADC-Takt vom max 14 MHz zu sein. Also schätz ich mal je einen Takt für jedes der 12 bit und 2 extra als "overhead". Dann käm ich bei 8 bit auf 10 Takte , 1.4 MHz sampling rate, 2,8 MHz dual interleaved? Hab' aber das Problem von extra Störsignalen durch ADC mismatch. Vielleicht passt das ja bei einer anderen Anwendung - mir ist es noch zu langsam. Falls jemand den Faden nochmal aufnehmen möchte: STM32... ref manual "11.9.3 Fast interleaved mode"
Da würde ich eher die 25€ für ein Nucleo Board mit STM32H743Zi ausgeben. Der hat 3 16bit ADC mit je 3,6 Msps, die sich auch im triple Mode betreiben lassen. Dann kommst du auf 10,5 Msps und Ethernet ist auch mit auf dem Board . Siehe: https://www.st.com/resource/en/application_note/dm00628458-getting-started-with-the-stm32h7-series-mcu-16bit-adc-stmicroelectronics.pdf
Danke - klingt auf den ersten Blick gar nicht schlecht. Hast Du praktsiche Erfahrung mit den "interleaving spurs"? Ein 12-bit AD sollte ja gegenüber 8 bit um den Faktor 16 genauer sein - auch relativ zueinander. Wenn mir also die 8 bit reichen, sind dann die interleaving spurs gar kein Thema? Und könnte ich die ADC dann auch schneller betreiben, d.h. gleicher Takt, weniger Zyklen? Dann wär ich schon bei 15 MHz, also 37 Samples im resonanten Halbzyklus.
Wolfgang R. schrieb: > Danke - klingt auf den ersten Blick gar nicht schlecht. > > Hast Du praktsiche Erfahrung mit den "interleaving spurs"? Ein 12-bit AD > sollte ja gegenüber 8 bit um den Faktor 16 genauer sein - auch relativ > zueinander. Wenn mir also die 8 bit reichen, sind dann die interleaving > spurs gar kein Thema? > > Und könnte ich die ADC dann auch schneller betreiben, d.h. gleicher > Takt, weniger Zyklen? Dann wär ich schon bei 15 MHz, also 37 Samples im > resonanten Halbzyklus. Ich habe so ein Board für andere Zwecke und den ADC noch nicht benutzt. Sehe gerade die max Sample Rate gilt auch nur für das BGA Gehäuse, verbaut ist aber ein TQFP.
Wolfgang R. schrieb: > Das bringt bei 2 ADC des Bluepill also max 2 MHz. > > Vielleicht kann ich noch etwas höher gehen, wenn ich die Auflösung > zurück fahr? > Limitierend scheint der ADC-Takt vom max 14 MHz zu sein. > Also schätz ich mal je einen Takt für jedes der 12 bit und 2 extra als > "overhead". Es gab mal einen Artikel, wo gezeigt wurde, wie weit man den ADC des stm32 übertakten kann, und da wurde viel mehr rausgeholt. Hast Du mal diesen Mega-Thread '10$ Scope revisited' gelesen? Da wurden doch etlich Varianten diskutiert.
Danke für den Tip. Nachdem sich Google sträubt, und ich trotz aussagefähiger Begriffe eine viertel Stunde gebraucht hab, hier für die Nachwelt ein Link: https://sparklogic.ru/projects/10-o-scope-revisited.html "$10 O-Scope revisited" isses das?
OK, so weit man das beim Querlesen beurteilen kann, haben sich die da richtig rein gestresst. Wenns richtig an's bauen geht, werd' ich da vielleicht noch mal den einen oder anderen Tip suchen, grad was timer und dma angeht. Die haben mit interleaving aus dem Blupill 2 Msamples rausgeholt, allerding mit deutlichen interleaving spurs. Das hilft mir wenig, denn genau in diesem Frequenzbereich vermute ich die parastären Schwingungen, wenn das Timing meiner Brücke nicht stimmt. Die glatten Rechtecke schienen alle von deutlich langsameren Messungen zu sein - oder von der Ausmittelung benachbarter Punkte. Was aber dann die Bandbreite wieder halbiert, wegen der man ja vorher das Interleaving gemacht hat... Entweder ich hab's überlesen, oder die Überlegung, einen externen schnelleren ADC zu verwenden, kommt in dem Thread nicht vor. Aber vllt geh ich mit meiner Überlegung ja in den thread..?
Wenn man schnelle ADs ohne Gehampel braucht, und nicht gleich einen 2 Kerner von NXP verbauen will, gibt es von TI seit einigen Jahren schon den TMS320F2809. Dessen ADC ist mit 12.5 MSPS spezifiziert, und der Rest vom Controller kann mit den Daten auch noch umgehen. Ist fuer dich vielleicht eine Herausforderung, weil man dafuer eben keine Billigteile vom Chinamann bekommt.
>TMS320F2809
Gibt's dafür den mittlerweile einen freien Compiler, das ist doch ein
DSP, wenn ich mich recht erinnere?
> einen freien Compiler
Ob der nun ganz frei ist, weiss ich nicht.
Wenn es etwas aelter sein darf: C2000 Code Composer Studio v3.3.
Das letzte Release (CC338319) findet man TI.
Das hat die "Unart" seine Konfiguation in seinem eigenen
Installationsverzeichnis speichern zu wollen, und laeuft damit
nur als Admin. Dann aber auch unter Win10 ohne Probleme.
Oder als normaler Benutzer, der kann die Konfiguration dann
wenigstens nicht versaubeuteln.
Aber man kann auch problemlos eine der neueren Versionen nehmen.
Die sind dann Eclipse-basiert. Ob man fuer die eine Lizenz braucht,
verraet die TI-Webseite.
Bislang war TI fuer den privaten Gebrauch immer sehr kulant bei
der Vergabe von Lizenzen.
Das man "keine" Lizenz zur Nutzung braucht, ist den politisch
Engstirnigen ja aber oft nicht "frei" genug...
Eigentlich spring ich ja nur ungern über dieses Stöckchen, weil der Thread sonst rettungslos abdriftet. Aber ich hab' ja mit einer Schaltung der Texaner begonnen. Diese App-Note besteht zu einem Viertel aus Abriss des Brückenverhaltens (gut und knackig) und zu zwei Drittel aus "klicke hier ... trage 'foo' ins Menü 'bar' " der DSP-Entwicklungsumgebung ein. Die ganze App-Note besteht nur aus Sirenengesängen für TI DSP. Weil die ihren DSP verkaufen wollen. Dürfen sie ja. Darf ich aber auch nicht kaufen wollen. Weil ich nicht mag. Das ist ein Hobby-Projekt. Da ist bereits die Entscheidung, es anzugehen, rational nicht zu begründen. Aber ich glaub, ich versteh' jetzt, wie das in der App Note eigentlich läuft. Ich hab' immer nach dem Oszi gesucht, aber nicht gefunden. Offensichtlich läuft das wirklich so, daß der DSP sowohl die Regelung als auch die Datenerfassung macht und man das über die Entwicklungsumgebung dann auslesen kann? Schon geil, irgendwie. Virtuelles Oszi, quasi? Aber es scheint mir wie eine Black Box: wenn die Hex-Hex-Kiste nicht mehr tut was ich will? Beim rumgoogeln bin ich immer wieder auf kafkaeske Support-Anfragen bei TI gestoßen: Die stehen vor der großen Burg und finden nicht mal das Tor. Beim STM32 bin ich jetzt so weit, daß ich mit ein paar halbseidenen Forumseinträgen mir den richtigen Suchbegriff zusammen klaube, um mich durch 1134 Seiten Datasheet zu greppen. Und denke, es zu verstehen. Ich will den zu meiner eierlegenden IoT Wollmilchsau machen, nachdem ich mit dem ESP8266 ungewollt in der WLAN-Ecke stecken geblieben bin. Und diese Entcheidung nicht revidieren, weil ein einzlenes Problem knackig wird. Was meinen Brückencontroller angeht: Ich bin da etwas altmodisch und hätte gerne für die Regelung und für die Überwachung jeweils ein eigenenes "Kästchen", also getrennter redundante Systeme. Also auch extra Oszi.
Zurück zum Eingemachten. Nach den Datenblättern sollten sich die Komponenten µC, FIFO und ADC recht gut vertragen. Läuft alles unter 3,3 V. Ich denke, die Busse kann man direkt verbinden. Der FIFO verfügt über einen Tri-State-Ausgang. Das würde auch einfaches Multiplexing ohne extra Komponenten erlauben. Kanäle bis zum Abwinken.... ;-) Ich könnte auch überlegen, beide Kanäle mit jeweils 8 bit Breite separat einzulesen. Der FIFO verlangt, daß sowohl eingangs- als auch ausgansseitig permanent ein clock-Signal zwischen 1 und 50 MHz anliegt. Das könnte asynchrones Pollen der Daten zum Glücksspiel werden lassen. Das einfachste wird wohl sein, die Daten im Burst in einem Zug über DMA abzurufen (zumimdest so weit der Speicher des µC reicht). Dazu würde ich den Out-Clock des FIFO mit einem Timer auf 1 MHz laufen lassen und mit dem selben Timer dann die DMA passend getimed triggern. Ggf könnte man da auch schneller gehen, aber die Daten müssen ja dann auch noch übers Netz verschickt werden. Vom GPIO-A-Bus sind 2 Pins für die Bootloader-Schnittstelle belegt, vom B-Bus einer für "boot2". Ich denke, das sollte im Betrieb kein Problem sein. Also hab' ich noch freie Auswahl, auch wenn ich mit 16 bit Breite aus 2 FIFO parallel lesen will. Die Steuersignale von AD und FIFO sind überschaubar. Ich denke, es sollten noch genug GPIO übrig sein, um die direkt zu bedienen. Das exakte Timing des Aufzeichnungsstartes könnte knifflig werden, aber ich denke, das kann man getrost ignorieren und den Beginn der validen Daten später bei der Auswertung fest legen. Einzig die synchrone Taktung von AD und FIFO-in erscheint etwas anspruchsvoller. Ich krieg wohl 40 MHz aus dem STM32 raus, aber nicht zwei in definierter Phasenlage mit ns-genauem Versatz. So was werd' ich aber wohl nach den Timing-Diagrammen brauchen: - der AD löscht die "alten" Daten ca 2 ns nach clock rise und stellt 6 ns nach clock rise die neune Daten bereit (rote Kurve, high="data valid"). - der FIFO lädt Daten bei clock rise , die dazu 6 ns vorher schon anstehen müssen und noch 2 ns gehalten. (blaue Kurve) - wenn ich dem AD ein gegenüber dem FIFO um ca 7 ns verzögertes clock-Signal gebe, liegt das Lesefenster des FIFO ziemlich mittig im data-valid-Fenster des AD - Die 74HC-Serie wird bei 3,3 V schon recht langsam. 10 ns delay sind bei 25 ns Zyklus ein no-go. Die Simulation zeigt nur mehr Dreiecks- statt Rechtecksignale. - Ich denke, die Serie LVC ist hier angesagt. Die Schmitt-Trigger sind mit 2,1 ns bei 3,3 V ausgewiesen. Die angegebene Verzögerung mit RC-Glied hat in der LTspice-Simulation die gezeichneten Kurvenverläufe produziert. - ... wenn ich mich denn auf die Modelle verlassen kann... Der Eingang des Schmitt-Triggers ist mit 2 pF im Datenblatt angegeben, aber beim Variieren des RC-Gliedes scheinen mir im Modell eher 5 pF hinterlegt. - letztlich werd ich das wohl irgendwie messen müssen. Ich denke, die Schaltung kann man auch zum Frequenzgenerator rückkoppeln. Ich hab mir ein paar Gatter, Flip-Flops. Zähler etc für die Bastelkiste bestellt und hoffe, daß ich dann mit meinem Logic-Analyser auf die Frequenz und damit auf die Verzögerungsdauer rückschließen kann. Der Analogteil des DSO203 scheint wegen der weiten Meßbereichsauswahl viel komplizierter als ich brauche. Ich denke, für Inline-Diagnose kann ich im Wesentlichen auf vorberechnete Gains zurückgreifen.
> zu zwei Drittel aus "klicke hier ... trage 'foo' > ins Menü 'bar' " der DSP-Entwicklungsumgebung ein Damit ist wohl die Konfiguration des RT-BIOS gemeint. Das liegt leider nicht als Quelle vor, und die Konfiguration ist, wenn man es benutzt, schon etwas umfaenglich. > Darf ich aber auch nicht kaufen wollen. Meine TMS320Fwxyz die ich hier hobbymaessig verbaue, sind ueberwiegend Samples von TI. Aber so exklusiv sind die Preise auch nicht, als das man sie nicht kaufen koennte. > Offensichtlich läuft das wirklich so, daß der DSP sowohl die Regelung > als auch die Datenerfassung macht und man das über die > Entwicklungsumgebung dann auslesen kann? Richtig. Es gibt neben der JTAG-Verbindung noch eine RTDX-Verbindung. Und das RT-Betriebssystem DSP-BIOS hat dann noch eine RTA-Verbindung. Da ein TMS320F2809 es auf insgesamt 16 AD Channels bringt, kann man neben den eigentlichen Regelgroessen damit auch noch andere Teile der Schaltung monitoren (wenn man will). Und man sieht natuerlich genau die Signale die der Regelalgorithmus verarbeitet/verarbeiten soll. Ein Oszi waere da nur zweite Wahl. All das funktioniert parallel zu einem in Echtzeit laufenden Regler. Wenn man das benutzen will, braucht man zwingend allerdings einen "richtigen" Emulationsadapter (z.B. XDS-560). Die kleinen XDS-100 FTDI-Adapter koennen das nicht. Hat man den nicht, kann man aber immer noch z.B. mit einem Cypress FX2LP die (AD-)Oszidaten per USB ausleiten. So koennte die Messschnittstelle immer noch in der selben "Schachtel" wie der Rest sein zu Hause finden. Der Mehraufwand in Hard- und Software haelt sich da in engen Grenzen. Ich bin allerdings auch jahrelang ohne diese zusaetzlichen Moeglichkeiten ausgekommen, und erst vor kurzer Zeit an einen gebrauchten BH-560m gekommen. Trotzdem viel Erfolg bei deinem Vorhaben!
Ja, das mit den TI-DSP hört sich alles durchaus interessant an. Vielleicht überschätze ich da auch manche Hürde, wie etwa die Frage, wie ich so ein Teil auf eine grobmotorikfähige Platine kriege. Mein limiterender Faktor ist halt die Zeit, in mehrere Plattformen einzusteigen. Ich hab bestimmt ein Dutzend Anwendugnen im Kopf, wo ich netzwerkgebundene µC verbauen möchte. Die sind alle wesentlich einfacher gestrickt. Da ist ein STM32 meist overkill, aber was solls. Ich würd halt gern die noch aufzubauende Erfahrung recyclen können. Mit einem 40 MHz Oszi kommt ein STM 32 vielleicht auch an seine Grenzen. Wenn ich das nicht im DSO gefunden hätte, wär ich auch gar nicht drauf gekommen.
> wie ich so ein Teil auf eine grobmotorikfähige Platine kriege. Die gibt es auch in QFN. Mein "erster" TMS320C5502 (300 MHz) sitzt auf einem QFN-Adapter. Das ist mittlerweile elf Jahre her. Der Debugadapter war "Made by Olimex" eigentlich ein MSP430-JTAG mit einer angepassten DLL fuer den Code Composter V3.3. Zum "Reinschnuppern" gibt es relativ guenstige Startangebote fuer die Piccolo-Serie von Controllern. Das ist quasi der kleinere Ableger der TMS320F28er Serie. Da muss man dann also selber erstmal gar nichts bauen. Manche, z.B. das 28027-Launchpad haben sogar den Luxus eines isolierenden JTAG-Adapters (allerdings ohne RTDX). Was davon aktuell noch verfuegbar ist, weiss ich allerdings nicht. Mein erster TI DSP mit dem ich experimentiert habe, war uebrigens ein TMS320C15 im 40 pol. DIL-Gehaeuse. (Noch laenger her.) > wo ich netzwerkgebundene µC verbauen möchte Da kommen/kamen bei mir STM32F107VC, LPC1768, LM3S9B96 und TM4C1294 zum Einsatz. Die beiden letzteren haben die PHY schon integriert, was den Aufbau vereinfacht. Wenn dir vor dem Loeten bange ist, dann waere wohl ein Nucleoboard mit Ethernet und einigermassen schnellen AD-Wandlern die erste Wahl. Man muss sich nur im klaren sein, dass ein M7-ARM auch sehr komplex ist, und eben trotzdem nicht die beste Loesung was Peripherie und Entwicklung angeht, ist. In der Industrie die ich so kenne (Entwicklung und Fertigung medizinischer Geraete) kommen immer noch TI-Controller ergaenzt um FPGAs zum Einsatz.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.