Hallo, Aktuell bastel ich gerade an einer Schaltung mit einem AMC3306 ADC, mein erster Kontakt zu einem Sigma-Delta ADC. Mein Problem ist das ich keinen blassen Schimmer von VHDL, FPGA und dem nötigen Filter habe. Mit hilfe der Bilder Sinc3.png (https://www.ti.com/lit/an/sbaa094/sbaa094.pdf, Seite 14, VHDL Code auf Seite 17) und sinc3.jpg (https://www.dsprelated.com/showarticle/1171.php) meine ich nun zu wissen das es sich hier um einen CIC Decimation Filter handelt. Die ALU mit den zwei + an a und b habe ich als Addierer interpretiert (?) und die ALU mit + und - habe ich mit Bild sinc3.jpg als Addierer mit vor B geschaltetem Not interpretiert (?). Daraus ist die Schaltung "Filter_mit_ALU.png" entstanden. Die Verwendung des Not statt des D Inverse beruht auf der Idee das ganze mal mit zwei Hex D Flip-Flop aufzubauen. Da ich nicht identifizieren konnte wie der Carry genutzt wird ging ich davon aus das er gar nicht genutzt wird und dachte mir das ich das ganze dann ja auch einfach als XOR umsetzen kann "Filter_mit_XOR.png". Bei einer ersten Simulation verhielten sich beide identisch "waveform.png". Meine Frage ist jetzt ob ich da jetzt völlig auf dem Holzweg bin oder das richtig umgesetzt habe? Einen FPGA nur für den einen Filter zu verwenden erscheint mir wenig sinnvoll daher noch die Frage nach einer allgemeinen Einschätzung ob bei fClkin von 10MHz in den ACM3306 eine einfach Schaltung mit 74er nicht auch ausreicht? Da ich noch einen Core auf dem MCU habe der mit seinen 240 MHz nicht sonderlich viel zu tun hat werde ich wohl erstmal versuchen das ganze auf diesem umzusetzen sollte meine Umsetzung des Sinc3 denn richtig sein. Danke vorab für alle die sich das hier durchlesen und ich bitte um Verzeihung wenn ich das ganze hier etwas umständlich ausgedrückt haben sollte. Gruß Marc
Angehängte Dateien:
-
Sinc3.png
10 KB -
sinc3.jpg
18 KB -
Filter_mit_ALU.png
6,4 KB -
Filter_mit_XOR.png
17 KB -
waveform.png
7,7 KB
https://www.ti.com/lit/an/sbaa094/sbaa094.pdf (Da ist auch VHDL Code mit dabei.) Beitrag "Delta-Sigma-Modulator und SINC3 Filter" Für den Anfang kannst du auch mal einen gleitenden Mittelwert bauen. Z. B. ein langes Schieberegister und einen Zähler. Zum Zählerstand addierst du immer den Wert der ins Schieberegister rein geht und subtrahierst den Wert der aus dem Register hinten rausfällt. Der Zählerstand ist dann quasi dein Analogsignal. Und das kannst du noch mit einem Tiefpass filtern. FPGA halte ich da auch überzogen, das sollte ein uC schon schaffen.
-gb- schrieb: > Für den Anfang kannst du auch mal einen gleitenden Mittelwert bauen. Z. > B. ein langes Schieberegister und einen Zähler. Zum Zählerstand addierst > du immer den Wert der ins Schieberegister rein geht und subtrahierst den > Wert der aus dem Register hinten rausfällt. .. und das Ganze dann 3x hintereinander und man hat den Integrator des SINC-Filters. Dann das Ganze rückwärts und man hat den Differentiator und damit den kompletten SINC.
Moin, Marc schrieb: > Meine Frage ist jetzt ob ich da jetzt völlig auf dem Holzweg bin oder > das richtig umgesetzt habe? Ich wuerd' mal nicht handisch versuchen durch Inverter oder sowas einen Subtrahierer zu basteln. Das kann VHDL schon alleine. > Einen FPGA nur für den einen Filter zu verwenden erscheint mir wenig > sinnvoll daher noch die Frage nach einer allgemeinen Einschätzung ob bei > fClkin von 10MHz in den ACM3306 eine einfach Schaltung mit 74er nicht > auch ausreicht? In deinen Bildern fehlt eine wichtige Groesse: Die Breite der Busse. Das wird dir bei 74er Implementierungen den Hals brechen. Auch mit Addierern/Subtrahierern siehts 74maessig eher mau aus. Wuerd' ich nicht machen. > Da ich noch einen Core auf dem MCU habe der mit seinen > 240 MHz nicht sonderlich viel zu tun hat werde ich wohl erstmal > versuchen das ganze auf diesem umzusetzen sollte meine Umsetzung des > Sinc3 denn richtig sein. Aufm Prozessor kanns gut sein, dass du mit einer anderen Filterstruktur besser faehrst als mit CIC. Je nach Prozessor tun Multiplikationen nicht so weh' und man muss sie evtl. nicht unbedingt vermeiden. Gruss WK
Genau, Du hast dass alles noch nicht ausprobiert, verdrahtest aber Deinen Entwurf dann fest mit 74'ern und es funktioniert auf Anhieb? Bei FPGA programmierst Du neu, bei 74'er braucht es schnell ein neues Design...
Dazu muss man eben wieder so bauen, wie man das in den 80ern gemacht hat: Denken, malen und den Kollegen drüberschauen lassen. Dann kommt die Platine. Wer das nicht konnte, baute Lochraster. Heute würde man das sicher mit in einem FPGA "prototypen".
SINC-Filter kann man aber auch sehr effizient auf einer MCU implementieren. (Addieren, Substrahieren) Wenn die Datenrate nicht zu hoch ist, wäre das sicherlich der beste Weg. In der Standardbeschaltung des AMC3306 wird ja auch eine MCU verwendet.
Hallo und vielen Dank für die ganzen Antworten! Mir wird erschreckend bewusst das ich null Ahnung von digitalen Filtern und eine Menge Mathematikdefiziete habe. Ich werde mir wohl erstmal etwas Lektüre zulegen und mich mit der digitalen Signalverarbeitung beschäftigen aber dafür bin ich hier dann im falschen Forum. Für Interessierte: Als Mikrocontroller kommt ein ESP32-S3 zu Einsatz. Dieser soll mit einer DSP Library auch einige Filter zur Verfügung stellen daher werde ich mich damit auseinander setzen. (https://github.com/espressif/esp-dsp) -gb- schrieb: > Für den Anfang kannst du auch mal einen gleitenden Mittelwert bauen. Danke für den Vorschlag ich werde mich mal mit dem gleitenden Mittelwert beschäftigen! Dergute W. schrieb: > In deinen Bildern fehlt eine wichtige Groesse: Die Breite der Busse. Da ich am ADC nur einen digitalen Pin als Datenausgang und einen Clockeingang habe nehme ich an das es sich um eine Busbreite von einem 1 Bit handelt!? Dergute W. schrieb: > Aufm Prozessor kanns gut sein, dass du mit einer anderen Filterstruktur > besser faehrst als mit CIC. Je nach Prozessor tun Multiplikationen nicht > so weh' und man muss sie evtl. nicht unbedingt vermeiden. Werde ich im Hinterkopf behalten vielen Dank! Uwe B. schrieb: > Genau, Du hast dass alles noch nicht ausprobiert, verdrahtest aber > Deinen Entwurf dann fest mit 74'ern und es funktioniert auf Anhieb? Die Fragestellung war ja in erster Linie ob ich den Schaltplan mit den ALU richtig gedeutet habe und die Umsetzung in "reine" Logik so richtig ist. Die Wahl das ins VHDL Forum zu posten begründete sich darauf das zu dem Schalt auch die Implementierung in VHDL mit in der PDF stand. Da ich aber noch keinen Schimmer von VHDL habe nutzt mir dieser noch nicht all zu viel. Platinen mache ich hier in unter einer Stunde mit Laserdrucker, Laminiergerät und Eisen3 fertig und aus Faulheit zu bohren hau ich da SMD Bauteile drauf und dann wird mal geguckt was dabei raus kommt. M. W. schrieb: > Dazu muss man eben wieder so bauen, wie man das in den 80ern gemacht > hat: Denken, malen und den Kollegen drüberschauen lassen. Dann kommt die > Platine. Wer das nicht konnte, baute Lochraster. Leider fehlt mir der Kollege der drüberschauen kann aber ansonsten ist das meine Vorgehensweise. Kleine Sachen werden auf die schnelle in SprintLayout zusammen geknüppelt und komplexere Sachen in KiCad, da das Auge mit lötet scheue ich Lochrasterplatinen und mach lieber auf die schnelle ein passende Platine fertig. Tim . schrieb: > SINC-Filter kann man aber auch sehr effizient auf einer MCU > implementieren. (Addieren, Substrahieren) Die Aussage macht mir Mut, ich werd mein bestes geben mir das nötige Wissen anzueignen! Tim . schrieb: > Wenn die Datenrate nicht zu hoch ist, wäre das sicherlich der beste Weg. > In der Standardbeschaltung des AMC3306 wird ja auch eine MCU verwendet. Interessant wäre für mich alles unterhalb von 5kHz, nach meiner Rechnung wären bei einem Takt von 20MHz, Oversampling von 64 und 16 Bits per Sample eine Samplerate von ~19500 Samples pro Sekunde drin. Halbe Abtastfrequenz nach Nyquist-Shannon sind dann noch 9,750kHz also sollte ich mit meinen 5kHz locker hinkommen. Danke nochmal an alle für ihre Beiträge, meine Idee da auf die schnelle etwas hinzuschludern werde ich nun begraben und mir die nötige Zeit zum lernen nehmen.
Moin, Jetzt wuerd' ich mal mutmassen, dass das mit der Filterei dann wohl erst interessant wird, wenn klar ist, wie du deinen Bitstrom aus dem ADC mit dann z.b. 20MBit/sec irgendwie in den Bereich der CPU schaufeln kannst... Gibts da irgendwelche HW-Unterstuetzung? Gruss WK
Marc schrieb: > Tim . schrieb: >> Wenn die Datenrate nicht zu hoch ist, wäre das sicherlich der beste Weg. >> In der Standardbeschaltung des AMC3306 wird ja auch eine MCU verwendet. > Interessant wäre für mich alles unterhalb von 5kHz, nach meiner Rechnung > wären bei einem Takt von 20MHz, Oversampling von 64 und 16 Bits per > Sample eine Samplerate von ~19500 Samples pro Sekunde drin. Halbe > Abtastfrequenz nach Nyquist-Shannon sind dann noch 9,750kHz also sollte > ich mit meinen 5kHz locker hinkommen. Wenn das ein single level quantizer ist, dann kommt nur ein bit pro sample heraus. Hast Du Dir den Filter-Berechner auf der TI-website zum AMC3306 mal angeschaut? Ein ESP32 hat mehr als Genug Rechenleistung. Da kannst Du einen SINC-Filter auch einfach im FIR-Ansatz implementieren: Ein SINC1 ist einfach ein Mittelwertsfilter. Daher für die Länge n summierst Du die n letzten Eingangswerter und teilst sie durch n. Für einen SINC2 Filter machst Du das zweimal sequentiell (Ausgang der ersten Stufe ist Eingang der zweiten). Für SINC3 dreimal. Alternativ berechnet man sich die Filtercoeffizienten vorher und faltet diese einach mal dem Bitstream. Da der nur aus einsen und nullen besteht, geht das auch ohne Multiplikation. Wenn Du etwas darüber nachdenkst, wie man das Optimiert, kommt man recht schnell beim CIC heraus. Den kann man sich auf viele Arten herleiten. https://de.wikipedia.org/wiki/Cascaded-Integrator-Comb-Filter
:
Bearbeitet durch User
Tim . schrieb: > SINC-Filter kann man aber auch sehr effizient auf einer MCU > implementieren. (Addieren, Substrahieren) Nur, wenn man SINC mit CIC gleichsetzt.
Dergute W. schrieb: > Gibts da irgendwelche HW-Unterstuetzung? Das steht noch nicht zu 100% aber ich werde wohl die auf die LEDC (LED Control) Funktion des ESP32 setzen um ein PWM mit 50% und bis zu 40 MHz zu erzeugen. (https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/peripherals/ledc.html#supported-range-of-frequency-and-duty-resolutions) Ich habe den ESP32-S3 leider noch nicht auf dem Tisch aber das sollte den saubersten Takt ergeben. Sobald er hier ist werd ich das mit dem Oszi testen. Ich bin noch nicht sicher ob ich mit LEDC auch einen internen Interrupt triggern kann, ansonsten würde ich die CLK für den AMC3306 auch auf einen anderen PIN legen um so den Interrupt über den Pin zu triggern. Der hat dann 12 Takte Zeit den Pin Status auszulesen und im RAM abzulegen Hier mal eine Beschreibung was ich da überhaupt vor habe: Die Hauptaufgabe des AMC3306 ist die Strommessung über einen Shunt. Aktuell erfolgt das ganze über ein Drehspulinstrument mit 250uA und einem LC Filter davor (ein Klotz mit 2k Henry und 1uF) um Störungen größer 5Hz zu filtern. Da es sich um ein mobiles Gerät handelt bereiten mir die Drehspulinstrumente regelmäßig Sorgen, da sie sich durch ihren filigranen Aufbau nicht gut für den mobilen Einsatz eignen. Zu dem ganzen kommen nun noch Qualitätsprobleme. Statt der bezahlten +/-1% Tolleranz bekommen wir Instrumente mit bis zu 15% Abweichung. Das machbare Ziel: Drehspulinstrument durch Shunt, ADC und TFT zu ersetzen. Meine Träumerei: Den LC Filter durch digitale Filterung ersetzen oder wenigstens die Grenzfrequenz anheben zu können um von der teuer angefertigen 2k Henry Spule auf eine standartisierte Spule wechseln zu können. Eine "grobe" Anzeige des Frequenzspektrums um für den Bediener einen Mehrwert bei der Störungssuche zu bieten. Das ganze wird ein Proof of Concept, da mir definitiv die Expertise fehlt ein sicheres Endkundengerät zu entwickeln. Tim . schrieb: > Hast Du Dir den Filter-Berechner auf der TI-website zum > AMC3306 mal angeschaut? Zu meiner Schande muss ich gestehen das ich von dem gar keine notiz genommen habe. Er ist jetzt aber runtergeladen und ich werde ihn mir anschauen. Danke für den Hinweis und für die anschauliche Erklärung zu den Sinc Filtern! Jetzt habe ich im Ansatz verstanden wohin die Reise bei den Sinc Filtern geht. Tim . schrieb: > Alternativ berechnet man sich die Filtercoeffizienten vorher und faltet > diese einach mal dem Bitstream. Da hört es bei mir dann leider schon wieder auf. Der AMC3306 bekommt jetzt erstmal ein Testboard und dann Teste ich mit dem "normalen" ESP32 was ich da unter kontrollierten Bedingungen an Werten erhalte.
Moin, Marc schrieb: > Ich bin noch nicht sicher ob ich mit LEDC auch einen > internen Interrupt triggern kann, ansonsten würde ich die CLK für den > AMC3306 auch auf einen anderen PIN legen um so den Interrupt über den > Pin zu triggern. > Der hat dann 12 Takte Zeit den Pin Status auszulesen und im RAM > abzulegen Hm - ich bin mir ziemlich sicher, dass du mit 40e6 Interrupts pro Sekunde nicht gluecklich wirst. Also braeuchtest du irgendeine Hardwareunterstuetzung an deinem ESP, damit du nicht jedes Bit vom ADC einzeln per Software reinbitten musst. Also irgendsowas wie ein I2S/SPI/USART Hardwareinterface, was sich entsprechend zurechtbiegen laesst. Vorher musst du dir ueber Filteranforderungen und -realisierung ueberhaupt keinen Kopf machen. Hast du den AMC3306 schon in echt bei dir rumfliegen? "Not available" bzw. "out of stock" waere jetzt fuer mich kein Ansporn sowas einzudesignen... Gruss WK
Dergute W. schrieb: > Hm - ich bin mir ziemlich sicher, dass du mit 40e6 Interrupts pro > Sekunde nicht gluecklich wirst. Also braeuchtest du irgendeine > Hardwareunterstuetzung an deinem ESP, damit du nicht jedes Bit vom ADC > einzeln per Software reinbitten musst. Also irgendsowas wie ein > I2S/SPI/USART Hardwareinterface, was sich entsprechend zurechtbiegen > laesst. Vorher musst du dir ueber Filteranforderungen und -realisierung > ueberhaupt keinen Kopf machen. Ja da ist viel wahres dran danke für den Denkanstoß! Das I2S wird bereits vom LCD in Beschlag genommen aber das SPI ist noch frei. Mit bis zu 80MHz ist es auch schnell genug. Ich muss mich nochmal durchs Datenblatt und die online Dokumentation graben um es zu verifizieren aber das SPI sollte auch DMA beherrschen. Dergute W. schrieb: > Hast du den AMC3306 schon in echt bei dir rumfliegen? "Not available" > bzw. "out of stock" waere jetzt fuer mich kein Ansporn sowas > einzudesignen... Ja, ich habe bereits im Juli jeweils zwei mal den AMC3306M25 und den AMC3336 geordert als sie noch am Lager waren. Die Isolierten AMC ADCs mit integriertem DC/DC Wandler sind noch nicht lange auf dem Markt und daher hoffe ich das sie noch eine Weile zu haben sind.
Dergute W. schrieb: > Also braeuchtest du irgendeine > Hardwareunterstuetzung an deinem ESP, damit du nicht jedes Bit vom ADC > einzeln per Software reinbitten musst. Richtig, aber sein ESP hat ja echt viele IOs. Da reicht es vielleicht schon den seriellen Datenstrom nach parallel zu wandeln. Dafür gibt es seriell zu parallel Schieberegister die die man gleich auch mit dem 20 MHz Takt füttern kann. Wenn man dann ein z. B. 16 Bit Schieberegister nimnmt muss man den Takt auch noch durch 16 Teilen (das geht mit ein paar FFs) und mit diesem niedrigeren Takt wird dann das Ausgangsregister der Schieberegister gelatcht und gleichzeitig im ESP die Daten gelesen/Interrupt ausgelöst/...
Moin, -gb- schrieb: > Richtig, aber sein ESP hat ja echt viele IOs. Da reicht es vielleicht > schon den seriellen Datenstrom nach parallel zu wandeln. Jepp, waere auch eine Moeglichkeit; braucht halt extra HW,etc. Kann aber wahrscheinlich auch keine Wunder wirken, es sei denn, man koennte da auch per DMA Puffer fuellen. Marc schrieb: > Das I2S wird bereits vom LCD in Beschlag genommen aber das SPI ist noch > frei. I2S != I2C > Mit bis zu 80MHz ist es auch schnell genug. Ich muss mich nochmal durchs > Datenblatt und die online Dokumentation graben um es zu verifizieren > aber das SPI sollte auch DMA beherrschen. Ja, guck' mal. Schick waer's wenn der Takt dann auch permanent rauskaeme. Und eben moeglichst grosse Mengen an Daten an der CPU vorbei (also z.b. per DMA) in irgendwelchen Buffern (RAM) landen koennten. Je seltener die "ich hab' Daten, mach Downsampling"-IRQs auftreten und je groesser dann die zu verarbeitende Menge an Daten ist, desto guenstiger fuer Software. Gruss WK
Marc schrieb: > Das I2S wird bereits vom LCD in Beschlag genommen aber das SPI ist noch > frei. Meinst du I2S oder I2C? I2S ließe sich in der Tat gut zweckentfremden, wenn man die Takte mit dem Controller hinbekommt. Dergute W. schrieb: > I2S/SPI/USART Hardwareinterface, oder habt ihr das jetzt beide verwechselt? Wenn keine schnellen Eingänge da sind, dann vlt ein PLD vorschalten?
Beitrag #6903053 wurde von einem Moderator gelöscht.
Angehängte Dateien:
-
20mhz2_5mhz.bmp
150 KB
-gb- schrieb: > Richtig, aber sein ESP hat ja echt viele IOs. Da reicht es vielleicht > schon den seriellen Datenstrom nach parallel zu wandeln. Dafür gibt es > seriell zu parallel Schieberegister die die man gleich auch mit dem 20 > MHz Takt füttern kann. Wenn man dann ein z. B. 16 Bit Schieberegister > nimnmt muss man den Takt auch noch durch 16 Teilen (das geht mit ein > paar FFs) und mit diesem niedrigeren Takt wird dann das Ausgangsregister > der Schieberegister gelatcht und gleichzeitig im ESP die Daten > gelesen/Interrupt ausgelöst/... Die Idee mit dem Schieberegister ist gut, das würde den Core mehr Zeit geben. Dergute W. schrieb: > I2S != I2C Jürgen S. schrieb: > Meinst du I2S oder I2C? Ich meine I2S, wobei sich da wohl etwas getan hat vom ESP32 zum ESP32-S3. Beim ESP32 war das LCD Interface noch mit dem I2S verknüpft nun scheinen der S2 und der S3 aber ein eigenständiges Interface zu besitzen. Das muss ich noch weiter ergründen. Damit ist I2S aber wieder im rennen. Dergute W. schrieb: > Schick waer's wenn der Takt dann auch permanent rauskaeme. Im angehängten Bild sind die mit LEDC erzeugten Takte zusehen, das Ergebnis bei 20MHz ist etwas entäuschend aber das sollte sich mit nem flotten Schmitt-Trigger richten lassen. Bei SPI und I2S ist mir noch kein Weg bekannt einen permanenten Takt zu generieren aber ich bleibe dran. Dergute W. schrieb: > Je seltener die "ich hab' Daten, mach Downsampling"-IRQs auftreten und > je groesser dann die zu verarbeitende Menge an Daten ist, desto > guenstiger fuer Software. Das ist gerade für die Batterie/Akkulaufzeit ein wichtiges Argument. Je länger ich den Kern schlafen schicken kann desto besser. Ich werde da dran bleiben. Jürgen S. schrieb: > I2S ließe sich in der Tat gut zweckentfremden, wenn man die Takte mit > dem Controller hinbekommt. Warum eignet sich i2s gut? hinbekommen bzgl. der Geschwindigkeit der Takte oder diesen permanent zu erzeugen?
Moin, Marc schrieb: > Das ist gerade für die Batterie/Akkulaufzeit ein wichtiges Argument. Je > länger ich den Kern schlafen schicken kann desto besser. Deinen Optimismus moecht' ich auch mal haben :-) Du kannst froh sein, wenn du mit deiner Filterei hinterherkommst. Kann mir noch nicht so recht vorstellen, dass du da lange schlafen kannst. Marc schrieb: > Warum eignet sich i2s gut? > hinbekommen bzgl. der Geschwindigkeit der Takte oder diesen permanent zu > erzeugen? Beides. Bei I2S haste auch ein Schieberegister mit 32..64 bit Tiefe; und der Takt laeuft im Gegensatz zu I2C und SPI durch. Gruss WK
Dergute W. schrieb: > Deinen Optimismus moecht' ich auch mal haben :-) Tja das Ergebnis einer Ansammlung von Unkenntnis. Erstmal träumen und dann mit Fakten drauf knüppeln und gucken was übrig bleibt. Erstmal möchte ich mich hier aber mal für eure geduldigen und ausführlichen Antworten bedanken. Ist noch viel zu tun aber ich bin und bleib optimistisch gestimmt. Die Boards ESP32-S3-DevKitC-1-N8R2 und ESP32-S3-DevKitC-1-N8R8 liegen jetzt hier auf dem Tisch und ein frischer Liter Eisen3 ist auch angekommen. Als erstes bekommt der AMC jetzt ein Testboard. Dergute W. schrieb: > Beides. Bei I2S haste auch ein Schieberegister mit 32..64 bit Tiefe; und > der Takt laeuft im Gegensatz zu I2C und SPI durch Und wieder etwas gelernt sobald das Board läuft schaue ich mir an wie ich die Daten per I2S in den RAM bekomme. Im TRM des ESP32-S3 bin ich noch auf etwas gestoßen. Der S3 besitzt einen Pulse Count Controller mit vier Einheiten, jeweils zwei Kanäle wovon jeder einen Pulse und einen Control Eingang besitzt. (https://www.espressif.com/sites/default/files/documentation/esp32-s3_technical_reference_manual_en.pdf#section.24) Die primitivste art den Sigma-Delta ADC auszulesen ist ja das zählen der "1er". Das kann der Pulse Count ohne Probleme und ein Sinc1 Filter ließe sich so auch problemlos umsetzen. Bei 64fachem Oversampling und 16bit je Sample ergibt das 1024bit. Wenn ich die Anzahl der "1er" dann durch 64 teile ergibt das den Mittelwert der 64 Sample. Nach 1024 Takten triggert der Counter dann einen Interrupt und der Wert aus dem Register wird in den RAM geschoben. Leider fehlen in der TRM noch das LCD und das Camera Interface. Das Camera Interface könnte in Verbindung mit dem Schieberegister eine Möglichkeit bieten 16 Pins per DMA in den RAM zu bekommen. Vorrausgesetzt LCD und Camera Interface lassen sich parallel nutzen.
Moin, Marc schrieb: > Der S3 besitzt einen Pulse Count Controller mit vier Einheiten, jeweils > zwei Kanäle wovon jeder einen Pulse und einen Control Eingang besitzt. Das hoert sich vielversprechend an. Marc schrieb: > Die primitivste art den Sigma-Delta ADC auszulesen ist ja das zählen der > "1er". Das kann der Pulse Count ohne Probleme und ein Sinc1 Filter ließe > sich so auch problemlos umsetzen. Yep, seh' ich auch so. Wahrscheinlich wird man's auch hinkriegen, dann per Software die beiden anderen Integratoren nachzubilden, obwohl man ja dann im Gegensatz zur reinen CIC-Lehre schon nach dem ersten Integrator die Samplerate dezimiert hat. Bin mir so ad. hoc. nicht sicher, koennte aber schon klappen. Marc schrieb: > Das Camera Interface könnte in Verbindung mit dem Schieberegister eine > Möglichkeit bieten 16 Pins per DMA in den RAM zu bekommen. Da wuerd' ich jetzt weniger Hoffnung draufsetzen. Als Camera Interface ist wohl MIPI-CSI bei SoCs gaengig - das laesst sich nicht mit vernuenftigem Aufwand missbrauchen. Gruss WK
Marc schrieb: > Kleine Sachen werden auf die schnelle in > SprintLayout zusammen geknüppelt Ah ... das klingt wirklich nach einer sehr koordinierten und stabilen Entwicklung. Arbeitst du zufällig bei einem Zulieferer?
Dergute W. schrieb: > Das hoert sich vielversprechend an. Habe bei Mouser jetzt noch das offizielle Devboard AMC3306EVM geordert damit ich meinen Selbstbau gegen das "Original" antreten lassen kann. So sollte ich das Risiko vermindern können mir auf diesem Wege zusätzliche Fehler an Land zu ziehen. Dergute W. schrieb: > Yep, seh' ich auch so. Wahrscheinlich wird man's auch hinkriegen, dann > per Software die beiden anderen Integratoren nachzubilden, obwohl man ja > dann im Gegensatz zur reinen CIC-Lehre schon nach dem ersten Integrator > die Samplerate dezimiert hat. Bin mir so ad. hoc. nicht sicher, koennte > aber schon klappen. Na das freut mich ja schon mal das ich da nicht ganz auf dem Holzweg bin. Ich bin gerade drauf und dran mich von der "Echtzeit" Verarbeitung der Daten zu verabschieden. Die ESP32-S3 Module gibt es mit 8/16MB PSRAM angebunden per Octal SPI, die 8MB Variante habe ich hier auf dem DevBoard. Ich denke es wäre sinnvoller die Samples erstmal im PSRAM abzulegen und nach der Messung zu verarbeiten. M. W. schrieb: > Ah ... das klingt wirklich nach einer sehr koordinierten und stabilen > Entwicklung. Arbeitst du zufällig bei einem Zulieferer? Die Aussage gilt für meine privaten Projekte. Arbeiten tue ich als ausgebildeter Industriemechnaniker in der Firma und helfe ab und an im Bereich der Elektrotechnik aus. Die Elektrotechnik ist seit 12 Jahren ein Hobby das ich immer weiter ausbaue und mich an Dingen versuche die mich interessieren.
Dergute W. schrieb: > Marc schrieb: >> Die primitivste art den Sigma-Delta ADC auszulesen ist ja das zählen der >> "1er". Das kann der Pulse Count ohne Probleme und ein Sinc1 Filter ließe >> sich so auch problemlos umsetzen. > > Yep, seh' ich auch so. Die Nullen müssen aber schon auch mitgezählt werden und dass dieses "Sinc1"-Filter übelste Oberwellen hat, ist sicher auch bekannt. > Wahrscheinlich wird man's auch hinkriegen, dann > per Software die beiden anderen Integratoren nachzubilden, obwohl man ja > dann im Gegensatz zur reinen CIC-Lehre schon nach dem ersten Integrator > die Samplerate dezimiert hat. Wenn er die einmal dezimierte Datenmenge mit einem kleinen FIR bearbeitet, kommt er sicher weiter, als mit dem armseeligen CIC3. Gerade in einem Microcontroller sind Koeffizientenmultiplikationen doch kein Problem. Wenn es an der Performance fehlt, eben ein biquad-IIR.
Moin, HF-Techniker schrieb: > Die Nullen müssen aber schon auch mitgezählt werden und dass dieses > "Sinc1"-Filter übelste Oberwellen hat, ist sicher auch bekannt. Das Nullenzaehlen kann man sich sparen, wenn der "Einser"-Zaehler regelmaessig zb. alle 65536 Takte zurueckgesetzt wird. Dann sind die Anzahl der Nullen eben 65536-Einser-Zaehlerstand. Klar ist ein sinc() kein rect(), der waere natuerlich besser fuer den Frequenzverlauf eines idealen Tiefpassfilters. Aber: Lebben is nix Ponyhof. HF-Techniker schrieb: > Wenn er die einmal dezimierte Datenmenge mit einem kleinen FIR > bearbeitet, kommt er sicher weiter, als mit dem armseeligen CIC3. Wenns erstmal dezimiert ist, muss man's nicht mehr filtern. Ist wie beim Baeren - die Reihenfolge ist wichtig: Immer 1.) erlegen und dann 2.) Fell verteilen. Nicht umgekehrt. Genauso beim Dezimieren: Immer 1.) Tiefpassfiltern und dann 2.) dezimieren. Nicht umgekehrt. Wie der Tiefpass konkret realisiert wird: ob fir,iir, gedoens ist prinzipiell voellig wurscht. Nur muss der halt mit der hohen Eingangssamplerate zurechtkommen...(Und man kann bei manchen Topologien ausnutzen, dass man durch's Dezimieren eh' viele der Ausgangswerte des Tiefpasses nicht braucht. Sprich: Evtl. ggf. auch nicht ausrechnen muss). Und dass das Filter zwar hurtig sein muss, aber die Eingangssamples nur 1bit breit sind... Gruss WK
Angehängte Dateien:
-
CIC.jpg
80 KB
Dergute W. schrieb: > Ist wie beim > Baeren - die Reihenfolge ist wichtig: Immer 1.) erlegen und dann 2.) > Fell verteilen. Nicht umgekehrt. Hihi. Der Vergleich war nett. Aber mal im Ernst: Es gibt tausende von Beiträge zu Hogenauers CIC im Internet, aber wenn man die ersten drei Dutzend gelesen hat, dann merkt man, daß die alle nur voneinander abgeschrieben haben und auch das berüchtigte Bild (siehe Anhang) voneinander abgekupfert haben - ohne daß auch nur einer den eigentlichen Dezimier-Algorithmus wirklich verstanden hat. Ist immer nur die gleiche Gebetsmühle. Auch ich kann dazu nur mir meine eigenen Gedanken machen, ohne wirklich zu wissen, ob Hogenauer sich das eben genau SO gedacht hat. W.S.
Wenn man sich das in einer Simulation mal ansieht, was da passiert, ist es eigentlich einleuchtend: Es erfolgt eine lineare Interpolation zweier Punkte mit einer Geraden, deren Steigung nach jeder Aktualisierung des Eingangs neu nachgeregelt wird. Nur ist die Gerade mit der Zahl der Stufen skaliert und daher nicht direkt durch draufgucken ablesbar. Die Skalierung wird aber die gleiche Anzahl von Stufen wieder zurückgedreht. Man muss eben die Interpolation und Dezimation verstanden haben und im Hinterkopf behalten, dass jede Form von Subtraktion oder Addition den Endwert um eine Differentiationstufe verschiebt. Daher braucht man immer dieselbe Anzahl von Kaskaden-Stufen, also eben z.B. 3:3 - es sei denn, es wird irgendwo wirklich ein Differenzial gebraucht. Anders sieht es bei den Tastverhältnissen aus: Ich verwende z.B. einen 8:4:4 zu 5:5:5 - Filter um von DVD auf 49152 zu übersetzen. Da kommt dann ein zu hoher Faktor raus, der korrigiert werden muss. Die Differenzialstufe stimmt natürlich. Wo man aufpassen muss, ist die Handhabung der Überläufe: Ein komplett binär formulierter CIC kann ohne Überlaufbehandlung auskommen, wenn man es richtig macht. Bei 5ern geht das natürlich nicht. Was eben von der Theorie interessant ist, ist die Betrachung warum es eben ein 3stufiger Filter sein muss und nicht etwa einer mit 2 Kaskaden. (Oder einer mit 4en?)
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschalten
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.