Google hat mir zumindest nix vergleichbares geliefert... Ich bin diese Woche wieder einmal mit den aktuellen STM32 Datenblättern konfrontiert worden... Folgende Idee ist mir dabei gekommen. Wir haben in der Fa. eine Projektarbeit (FH-bakk) betreut in der ein lustiges DSO nano zum Einsatz kam. So wiederlich die Dinger auch sein mögen, cool ists halt schon sein scope spazieren tragen zu können ;) Jetzt kann man die STM32 Datenblätter nach dem max. FSCM Takt durchsuchen und findet folgendes: Family | RAM | max FSMC-Speed | max FSMC-Width F103 96kByte 36MHz 16-Bit F215 128kByte 60Mhz 16-bit F417 196kByte 60MHz 16-Bit F427 256kByte 84MHz 16-Bit F439 256kByte 90MHz 32-Bit Die DSO-Quad kann 72MSPS bei 8-bit. Jetzt hätte ich mir gedacht, Tust du einen Flash-ADC an die Datenleitungen von einem F4Discovery und lässt den DMA gemütlich von lesen. Etwas übertakten (210Mhz war bei mir am Tisch drinnen beim einem Oszillator-abnormal-test) kommt man also mit einem F417er auf die samplingrate des DSO Quad. die 4k Samplingbuffer ließen sich auch problemlos realisieren... Die Projektidee wäre nun so etws ähnliches zu entwickeln - nur nicht standalone sondern quasi als usb-gadget. Sonst sind die chinesenpreise nicht erreichbar ;) Ich würde in 2 Schritten vorgehen: 1. F4Discovery mit allen 3 ADCs interleaved bei max 7.2MSPS (singlechannel) bzw 2.4MSPS (triplechannel) laufenlassen um das DMA-Zeugs, Triggering, ... zu verifizieren. das Analogzeugs wäre quasi das Mainboard in dem das Discoveryboard sitzt. 2. Wenn das geht neues Mainboard mit ADC am FSMC wenn das dann alles gehen sollte wäre ja noch ein 4fach-interleaved-adc entwickelbar der dann 90*4MSPS single-channel machen könnte ;) Zumindest den Schritt 1 würde ich gerne wagen, da ich zwar im Büro ein nettes Agilent Scope stehen habe, aber daheim doch hin und wieder eins brauchen könnte. Einen buffer für den DAC für Waveform replay bzw arbitrary Wavegen könnte auch ganz nützlich sein... ob der DMA auch bei vollem FSMC-CLOCK die daten ins ram bringt habe ich beim noch nicht gecheckt.. ist ja nur so eine dumme idee... Das Routing am Discovery ist auch nicht überprüft.. kann also gut sein, dass man da die Datenrate nicht vernünftig drüber bringt... Anbindung an den PC per Ethernet oder USB (wär einfacher). Als Gehäuse würde ich ein 3.5" USB-HDD Teil modifizieren. ADC08200CIMT würde 200MSPS können und in TSSOP24 um 11e bei farnell verfügbar sein... THS5641AIDWG4 wäre ein 100MSPS DAC mit ähnlichen Parametern...nur SOIC und 7,50 bei selbiger quelle. Ich sehe den Aufwand realistisch für ein Hobby-Projekt, in etwa bei dem des China-Teils und auch einen gewissen Spassfaktor bei dieschem Projekt. Vorteile sehe ich z.B. beim möglichen Pretrigger (dma spielt dauernd ringbuffer und wenn ein trigger kommt sampelt er halt nurmehr #Buffer-gewünschter Pretriggerbuffer weiter), Anschluss richtiger Probes und vllt auch an der Möglichkeit das teil für DRM nutzen zu können (z.b mit 10MSPS in richtung PC Streamen) Gibt es hier für so ein Vorhaben mitstreiter? 73 PS.: kann sein, dass ich mich nicht sofort melde.. bin übers WE nicht im Land...
Deine Zahlen sehen ja ganz schön kühn aus. Guck aber lieber noch einmal tief ins Datenblatt. Wenn ich mich recht erinnere, brauchen auch die STM32 mehrere Takte für einen Buszugriff, da rutschen deine Zahlen dann ziemlich in den Keller. W.S.
hab mir nur das datenblatt angeschaut... werd mir nach dem WE mal das ref-manual vornehmen wie schnell der DMA da tatsächlich ist... grundsätzlich sollte das aber schon gehen man müsste nur schaun, dass die datenbusse nicht belegt sind... grundsätzlich sehe ich da auch kein problem da dank CCM und dem instruction-fetch-bus eigentlich die restlichen busse ruhig sein sollten... ich postuliere also, dass der F417 tatsächlich die 120MByte/s bewegen kann... ggf müsste man ein kleines fifo dazutun, damit nichts jittert... das wäre aber zu testen... 73
Interessanter Thread. Ich muss mir wohl auch was überlegen, siehe Beitrag "Fehlerbild HAMEG HM204-2 - Hat jemand 'ne Idee?". Zwei STM32F4DISCOVERY habe ich hier rum liegen. Würd' mich freuen, wenn ich mir damit einen Ersatz basteln könnte. Gern auch als "Logic-Analyzer" oder um I²C oder 1wire besser debuggen zu können.
Wasspricht denn gegen einen richtigen ADC mit etwas Schub anstelle einer interleaved loesung.?
Interessant. Viel Interessanter: Was für Analog-Frontend hast du im Sinn? Richtig cool wäre natürlich Opto-Isolated USB und Batteriebetrieb, damit man ganz entspannt isoliert messen kann. Bliebe die Frage nach dem Preis. Ich kenne die STMs nicht, aber hat die DMA-Engine keine Prioritäten für Kanäle? Damit ließe sich ja der Bus frei halten (zumindest Größtenteils).
Hans Wilhelm schrieb: > > ADC08200CIMT würde 200MSPS können und in TSSOP24 um 11e bei farnell > verfügbar sein... > wenn schon eins aus der ADC08200 familie dann ADC08B200 (gibts auch als sample) es hat 1k capture buffer schon drin, den kannst du mit dem STM32 in ruhe auslesen. Die eingebaute PLL ermöglicht entspannten takt, powerdown (PD und PDADC, damit der buffer noch gelesen werden kann) hat es auch was bei tragbaren teil sinn macht (650µA). Für ein USB/PC versuch, allerdings mit viel mehr krach, nimm ADC08D500 und übertakte es auf 2x1GS/s oder 1x2GS/s (wie GW-Instek es in deren neuesten DSOs macht) dazu ein FPGA (es gibt fertiges design von TI, daten gehen per USB zum PC, eine PC app gitbs auch). Der kostet allerdings auch keine 10EUR :\ Den ADC08D502 gibts auch als sample, auch FPGA design und PC app. Übertakten ging aber nicht so weit wie bei dem ADC08D500, auch kein mux, so braucht man 2 stk davon (und takt einmal 180° drehen) für 2 kanal jeder je 1GS/s (ohne übertakten und 1.5GS/s mit).
@thorsten ein einfacher logic analyzer würde quasi als nebenprodukt rausfallen... software gäbe es z.b. hier: https://code.google.com/p/logicdiscovery/ ob das für was taugt müsste man sich anschaun... @Siebzehn oder Fuenfzehn adc kommt später.. zum frontend-software,usb anbindung,... testen tuts auch der interne :) @Hannes W. hab ich mir noch nicht genau überlegt... aber 20-30MHz Analogbandbreite sollten recht gemütlich noch handhabbar sein... irgendwelche current-feedback OPs+TVS+kleinkram damit das halbwegs linear wird sollte schaltungstechnisch glaubich reichen... da wirds eher interessant hochohmig und breitbandig am pcb zu werden... trigger dürfte auch interessant sein.. aber es gibt im netz sicher zig appnotes die da input geben :) optoisolated usb klingt nicht schlecht von der idee her :) @Thomas R. der ADC08B200 klingt interessant... muss mir das datenblatt mal durchschaun FPGA-Design will ich keins machen.. 1. hab ich kein ausreichendes wissen drüber und 2. strebe ich einen 4layer print an... wenn ich mir überlege was da an pins zusammenkommt für sampling buffer, ADCs, interface zum uC sehe ich für 4 layer ziemlich schwarz... und für 1gsps dürfte alles was so an kleinen fpgas herumfliegt unbrauchbar.. also lvds anbindungen zu den adcs mehrere bänke mit 4ns sram,... nein danke.. lieber so, das man das auch tatsächlich fertigstellen kann :) soo werd dann man etwas weiter forschein in richtung analog-frontend, bzw buffer für den DAC :) falls jemand app-notes hat, her damit :) hab auch schon ein paar ideen in richtung placement am pcb ... werd in den nächsten tagen mal etwas zeichnen ... 73
Hi Hans:) Schaue mal mein Projekt an;) Beitrag "CPLD in Design intergrieren, Brauche kleine Beratung:)" UND hier (aktueller zustand) Beitrag "Erste Platine (und das erste Hobbyprojekt) meines Lebens." Ich verwende auch die ADC08200. Die Platinen sind schon bestellt und kommen so am Ende des Monats. Die Firmware für CPLD ist schon fast fertig und nimmt ca. 200 LE an, D.h. man hat noch 370 freie LE für weitere Features:) Die ADC haben 8 Bit Auflösung und individuell einstellbate Vref von 0 bis 3,3 V. D.h wenn dein Signal nur 1 Vpp hat, kannst du Vref eben auf 1V einstellen und somit die Auflösung erhöhen. Die CPLD Versorgt die ADC's mit CLK (frei wählbar zwischen 250MHz,125MHz, 62.5 Mhz,31.25 Mhz.) Mein Hobbyprojekt ist zwar nicht als Oszi gedacht, ehe als eigenständiges "Acquisition Modul" für beliebige Dev. Kits. Aber ich bin sicher an kann es auf ein Oszi erweitern;) (Display, Steuerung, Menu's etc) Der Preis für das Ganze ist relative hoch. Gut die ADC's , DAC's und Fox Oszillator mit 250 Mhz ( Preis ca. 60 Euro!!) habe ich als Samples bekommen.Aber CPLD, diverse passive Elemente +4-Layer PCB habe ich selbst bezahlt. Alles in allem wird es so um 100-120 Euro kosten. Na gut, falls mein Prototyp gute Resonanz bekommt, kann man billigere ADC nehmen (100 Mhz reichen auch), dann noch billigeren OX (eben 100 MHZ) , 2 Lagige Platine und nur einen DAC für Vref. Dann sinkt der Preis auf 50 Euro oder so....:)) PS: Die Firmware hat SPI-ähnliche Kommunikation nach außen, so dass man im Betrieb die Abtastraten/Vref's/PD's leicht ändern kann.
Hans Wilhelm schrieb: > ... aber 20-30MHz Analogbandbreite > sollten recht gemütlich noch handhabbar sein. Dann sollte die Preis-Obergrenze aber aber auch um und bei 130€ sein, sonst lohnt sich das m.E. nicht. Vergleiche das PS 2204 mit 100 MS/s Sample-Rate: http://www.reichelt.de/USB-Oszilloskope/PS-2204/3//index.html?ARTICLE=115719 Hans Wilhelm schrieb: > ein einfacher logic analyzer würde quasi als nebenprodukt rausfallen... > software gäbe es z.b. hier: ... Klingt gut; ich bin weiterhin sehr begeistert von der Idee, das Discovery-Board als Basis für so ein Projekt zu nehmen.
Sorry, hab' noch nicht weiter drüber nachgedacht, nur so als "Brainstorming": Kann man irgendwie das Digital camera interface (DCMI) sinnvoll nutzen, um Analog-Samples schnell einzulesen?
Mit dem Preis sehe ich das auch so. ca. 100e+discovery gesamt sehe ich als schmerzgrenze wo sich das selbstbauen lohnt. auf jedenfall gibts anscheinend interessierte... dann kann ja einmal brainstormen und ics/appnotes zusammentragen. wenns zu teuer werden sollte kann man ja immer noch abbrechen ;) neuer adc vorschlag... passt besser zu den 60Mhz und ist auch günstiger (umd die 7e bei rs): ADS831E input parameter schlage ich einen mix aus den picoscope 2204 und aktuellen specs von agilent vor... 1mV/div vom Agilent dafür nur 100Vrms vom Picosope für die input protection (alles über niederspannung sollte man sowieso mit was dementsprechend getesteten/verifizierten messen). hab übrigends was interessantes gefunden: http://code.google.com/p/opendso da sind sicher design-hints dabei.. bei gelegenheit werde ich das mal sichten. 73
Torsten C. schrieb: > Sorry, hab' noch nicht weiter drüber nachgedacht, nur so als > "Brainstorming": Kann man irgendwie das Digital camera interface (DCMI) > sinnvoll nutzen, um Analog-Samples schnell einzulesen? Hab ich mir auch schon überlegt ;P wenn 2 die selbe idee haben, dürfts nachforschentswert sein ;D Andere idee wäre auch ein framegrabber-frontend sein... falls es sowas gibt in ic-form.. 73
> Mit dem Preis sehe ich das auch so. ca. 100e+discovery gesamt sehe ich > als schmerzgrenze wo sich das selbstbauen lohnt. Bei diesen Einstiegspreis für ein USB-DSO: http://www.reichelt.de/USB-Oszilloskope/PCSU-200/3/index.html?;ACTION=3;LA=2;ARTICLE=131352;GROUPID=4055;artnr=PCSU+200 wird es sich nie lohnen, außer beim Erfahrung sammeln. Grüße Löti
Moins, guggt doch mal hier: http://www.youtube.com/watch?v=JQhHKdDDgM0 STM32F103xxx mit externem ADC dran. gruss, tom.
jaja, im netz gibts alles schon besser, billiger,... @Torsten C. das camera interface hätte einen fifo, aber nur 1x 14bit max bei 54mhz so wie ich das auf die schnelle verstehe. ich glaub am we werde ich mir das discovery mal vornehmen und schaun ob das so geht wie ich das glaube... also r2r DAC am fsmc und per dma rausbursten.. wenn das signal jittert/verzerrt ist braucht man eigentlich in die richtung nicht mehr weiterschaun weil dann das einlesen auch nicht so funktionieren wird wie gewünscht... 73
Hallo, ich habe mir das Datenblatt zum ADC08B200 mal angeschaut. Leider hilft der Capture Buffer nicht sehr viel weiter: "Note that the capture buffer on this chip must be entirely filled to its configured size before reading its contents can begin." Bei einer Größe von 1k kann man gerade mal 5.12e-6s am Stück samplen bevor der Buffer voll ist - will man kontinuierlich einlesen, reicht auch der ADC08200. Einen CPLD/FPGA (muss ja kein 1000-Pin-Monster sein) würde ich so schnell nicht verwerfen. Dieser könnte (falls nötig) glue logic beinhalten, den ADC per MMIO konfigurierbar machen (spart auch CPU-GPIOs, falls das Not tut) oder das Multiplexing der Datenströme übernehmen, wenn die ADCs interleaved laufen sollen. Einen Arbitrary Waveform Generator/Waveform Replay würde ich nicht noch extra einbauen - das ist genug Arbeit für sich alleine. Die CAT I Spec vom opendso finde ich gut. Ich bin mir noch nicht so recht im Klaren, wie man den Trigger/Auswertung am Besten gestaltet. Ich würde die komplette Signalanalyse/Verarbeitung auf dem PC machen. Bei zwei 200MS/s Kanälen mit 8Bit Samplegröße macht das aber 400MByte/s - da braucht man schon wieder USB 3.0 Super Speed, GBit Ethernet, Thunderbolt, eSata …
Hannes W. schrieb: > Einen Arbitrary Waveform Generator/Waveform Replay würde ich nicht noch > extra einbauen Das sehe ich auch so. Hannes W. schrieb: > Ich bin mir noch nicht so recht im Klaren, wie man den > Trigger/Auswertung am Besten gestaltet. Ich habe immer noch mit meinem alten Analog-Oscar gearbeitet. Was haben denn moderne DSOs noch so für Trigger-Möglichkeitenm außer "Auto", "absolut" und "PreTrigger%"? Die o.g. Funktionen stelle ich mir nicht so kompliziert vor. Wie wär's mit einem Comparator-Eingang für den Trigger, also triggern ohne die ADC-Werte zu analysieren? Hannes W. schrieb: > Ich würde die komplette > Signalanalyse/Verarbeitung auf dem PC machen. Das sehe ich auch so. Hannes W. schrieb: > … da braucht man schon > wieder USB 3.0 Super Speed, GBit Ethernet, Thunderbolt, eSata … Bitte nicht!! Erste Idee: Komprimieren. Also Sample-Differenzen mit ±15 übertragen, die Zahl "-15" bedeutet: "Jetzt kommt ein Absolutwert". Damit passen die Samples schon mal fast alle in ein Nibble. Zweite Idee: Bei sich wiederholenden Signalen nur Deltas zu dem vorherigen Frame übertragen. Weiß jemand, wie Kauf-DSOs (picoscope usw.) das machen? Aber mal was anderes: Wie soll der µC die Daten verarbeiten? Für Echtzeit müßte die taktfrequenz des µC doch um ein vielfaches höher sein, als die Sample-Frequez. Also kann der µC doch eh nur "ab und zu mal" einen Frame auswerten. Also muss man doch auch nur "ab und zu mal" einen Frame per USB übertragen.
Ich würde einen analog comperator nehmen für die variable triggerschwelle (PWM /DAC?) und den ausgang an den EXTI pin legen.. damit geht rising, falling und both-edge triggering... eine idee für pretriggering habe ich oben schon beschrieben... ich glaube das sollte man sich mit dem interen ADC anschaun... quasi ein DSO nano mit vernünftigerem sampling-rate/analog bw verhältnis :) die frage ist ob ich schnellgenuge opamps herumliegen hab ... 73
Torsten C. schrieb: > Ich habe immer noch mit meinem alten Analog-Oscar gearbeitet. Was haben > denn moderne DSOs noch so für Trigger-Möglichkeitenm außer "Auto", > "absolut" und "PreTrigger%"? Keine Ahnung. Kombinationen mehrerer Kanäle? Auf Mathefunktionen zwischen zwei Kanälen ( (ChA + ChB) fällt unter 0.3V, etc.)? > > Die o.g. Funktionen stelle ich mir nicht so kompliziert vor. Rauschen? > > Wie wär's mit einem Comparator-Eingang für den Trigger, also triggern > ohne die ADC-Werte zu analysieren? Dann verbaut man sich Protokollanalyse in Software, denke ich. Für simples falling/rising edge triggern ist das aber sicher einfacher. Torsten C. schrieb: > Bitte nicht!! Naja Thunderbolt/eSata waren nicht wirklich ernst gemeint. USB hat den Vorteil, das ein Treiber der mit libusb arbeitet auf Windows, Linux, OS X, BSD, ... lauffähig ist. Ethernet hat diesen Vorteil nicht, ist aber (denke ich) von der PC-Seite aus nicht so wild. Von der µC/DSP/FPGA-Seite mag das anders aussehen. > > Erste Idee: Komprimieren. Hatte ich auch schon überlegt. Mir ist nur nix eingefallen. Die Komprimierung muss die Datenrate ja auch im Worst-Case-Fall zuverlässig unter die Bandbreite der gewählten Schnittstelle drücken können, und das verlustlos. Achja, und die Komprimierung muss schnell auszurechnen sein, denn sonst kann man ja die Analyse auch gleich auf dem Scope machen. > Also Sample-Differenzen mit ±15 übertragen, > die Zahl "-15" bedeutet: "Jetzt kommt ein Absolutwert". Damit passen die > Samples schon mal fast alle in ein Nibble. Und wenn jetzt n Samples kommen, die >15 LSB auseinander liegen hast du jedes Mal 12Bit anstatt nur 8. Ausser du begrenzt die Signalfrequenz durch einen LPF am Eingang. Nehmen wir einen 20MHz Sinus, full-scale und die für deinen Vorschlag beste (d.h. flachste) Stelle. Bei 200MS/s ist delta-t 5e-9s, d.h. 5e-9s nach dem Scheitelwert ist der wert 0.809. Normiert auf 8 Bit entspricht das einem Wert von 206 (0xce), das Delta zum Scheitelwert ist somit 49 LSB, und deine Komprimierung könnte den 20MHz Sinus nicht abbilden (bzw. nur in dem die Datenrate noch erhöht wird). Ich hoffe ich habe keinen Fehler gemacht ;) > > Zweite Idee: Bei sich wiederholenden Signalen nur Deltas zu dem > vorherigen Frame übertragen. Selbes Szenario (20MHz, full scale). Diesmal nehmen wir den Nulldurchgang an. Sei ein Sample 2.5e-9s vor und nach dem Nulldurchgang (±79, 0x4f). Das Delta beträgt 158 (0x9e), braucht 8 Bit und bringt somit keine Ersparnis. Vektorisieren würde mir einfallen, aber das macht man nicht "einfach mal so", glaube ich. > > Weiß jemand, wie Kauf-DSOs (picoscope usw.) das machen? Keine Ahnung. - Verlustbehaftet komprimieren? - Vorverarbeitung on-chip? D.h. Aufnehmen bis Trigger und dann nur alles "sichtbare" um den Triggerpunkt übertragen. > > Aber mal was anderes: Wie soll der µC die Daten verarbeiten? Gar nicht. Ich würde das alles auf dem PC machen. Ansonsten baut man ja gleich wieder ein full-blown DSO. > Für > Echtzeit müßte die taktfrequenz des µC doch um ein vielfaches höher > sein, als die Sample-Frequez. Jaein. Auswertung durch eine Datenflussarchitektur, also im FPGA. Ich weiß nicht, wie das im Detail aussehen kann. > Also kann der µC doch eh nur "ab und zu > mal" einen Frame auswerten. Also muss man doch auch nur "ab und zu mal" > einen Frame per USB übertragen. Ja, aber wer will denn so etwas?
Hans schrieb: > eine idee für pretriggering habe ich oben schon beschrieben... Wie Pre-Trigger funktionieren ist klar, nur ist der mögliche Buffer auf dem PC sehr viel größer als nur ein paar kiB (und damit ist auch eine längere Zeit zwischen dem Ereignis und dem Pre-Trigger möglich. Ein 200MS/s Scope, was nur 20e-6s am Stück samplen kann … ich weiß nicht.
Hans Wilhelm schrieb: > FPGA-Design will ich keins machen … und für 1gsps dürfte alles was > so an kleinen fpgas herumfliegt unbrauchbar.. Hannes W. schrieb: > Einen CPLD/FPGA … würde ich so schnell nicht verwerfen. Hannes W. schrieb: > Auswertung durch eine Datenflussarchitektur, also im FPGA. OK, diese Langsame Entwicklung zum FPGA war bei mir noch nicht angekommen. Hannes W. schrieb: > D.h. Aufnehmen bis Trigger und dann nur alles > "sichtbare" um den Triggerpunkt übertragen. Davon ging ich bisher aus. Du willst also alle Daten (in Worten: "alle") zum PC übertragen, ist das Dein Ernst? Da bin ich aber auf die Lösung gespannt. Hannes W. schrieb: >> Aber mal was anderes: Wie soll der µC die Daten verarbeiten? > Gar nicht. Ich würde das alles auf dem PC machen. Dann frage ich mal anders: Was soll denn das STM32F4DISCOVERY tun? Ein XC7Z010 ist zwar als BGA schwer zu verarbeiten (geht das auch in einer Pfanne mit Sand auf dem Küchenherd?) und kostet ca. 105€, aber ist vielleicht ein tolles Ein-Chip-DSO. Ich frage natürlich nicht, um Dich zu ärgern, sondern um zu Dich besser zu verstehen, also im Sinne eines Sparringspartners.
Torsten C. schrieb: > Hannes W. schrieb: >> Einen CPLD/FPGA … würde ich so schnell nicht verwerfen. > Hannes W. schrieb: >> Auswertung durch eine Datenflussarchitektur, also im FPGA. > > OK, diese Langsame Entwicklung zum FPGA war bei mir noch nicht > angekommen. Also letzteres Zitat ist dann doch etwas aus dem Zusammenhang gerissen. Das war nur als Beispiel gedacht um zu zeigen, dass die Taktfrequenz bei "Echtzeitverarbeitung" nicht unbedingt über der Samplefrequenz liegen muss. Daraus ist nicht zu schließen, dass ich für ein FPGA-basiertes Design bin. Ich würde den FPGA, wie schon geschrieben, als glue logic, Muxer und ggf. I/O-Erweiterung benutzen. Und auch das nur, falls nötig (glue logic kann ja entfallen, wenn die Interfaces µC <-> ADC passen). Torsten C. schrieb: > Hannes W. schrieb: >> D.h. Aufnehmen bis Trigger und dann nur alles >> "sichtbare" um den Triggerpunkt übertragen. > > Davon ging ich bisher aus. Du willst also alle Daten (in Worten: > "alle") zum PC übertragen, ist das Dein Ernst? Ja ;) Auf jeden Fall hätte ich gern ein "großes" (zeitliches) Fenster das ich mit voller Samplerate abtasten kann, also quasi einen großen Samplebuffer. Gängige DSOs (350€-Klasse) haben wohl so um die 1MPoints, bei 8Bit/Sample also 1MByte. Aber irgendwie muss man sich ja abheben ;) > Da bin ich aber auf die Lösung gespannt. Da darfst du gespannt bleiben, denn ich habe keine. Mit SuperSpeed USB oder GBit Ethernet müsste das aber gehen. >>> Aber mal was anderes: Wie soll der µC die Daten verarbeiten? >> Gar nicht. Ich würde das alles auf dem PC machen. > > Dann frage ich mal anders: Was soll denn das STM32F4DISCOVERY tun? Interface spielen. Die Frage ist ja, ob es nebenbei überhaupt noch etwas anderes tun kann - der Flaschenhals USB 2.0 bliebe ja bestehen. Aber ich habe mich im Moment nicht so sehr auf ein STM32 versteift, vielleicht kommt ja noch ein besserer Vorschlag. Mich würde ein Gesamtkonzept freuen, bei dem die einzelnen Komponenten gut aufeinander abgestimmt sind, also ein 200MS/s-ADC nicht von einem µC ausgebremst wird, oder nur 1kiB (ADC08B200) bzw 4kiB Samplebuffer hat. Da weiß ich jetzt schon, dass mir so ein Gerät keine Freude machen wird. Zudem sehe ich da auch wenig Sinn für einen Selbstbau, das Teil sollte ja schon noch mit ein paar Besonderheiten aufwarten können. > > Ein XC7Z010 ist zwar als BGA schwer zu verarbeiten (geht das auch in > einer Pfanne mit Sand auf dem Küchenherd?) und kostet ca. 105€, aber ist > vielleicht ein tolles Ein-Chip-DSO. Naja, das Placing wird schwer. So ganz ohne Placer mit Stereo-Mikroskop? Das Löten an sich wird dann schon gehen. Ich habe gestern auch "nur" 3 Mal einen Chip mit Exposed PAD auf einem umgedrehten Bügeleisen ein- und ausgelötet. Nachdem ich den Fehler im Layout gefunden und korrigiert habe funktioniert das auch ;) (Zu) Teuer ist das Mistding aber trotzdem. > > Ich frage natürlich nicht, um Dich zu ärgern, sondern um zu Dich besser > zu verstehen, also im Sinne eines Sparringspartners. Schon klar. Ich versteh das Gerät in etwa als SDR, nur anstatt ein schmales Band nach der ersten oder zweiten ZF zu samplen, soll das Baseband in 20MHz Bandbreite mit 200MS/s gesampled werden. Dass das nicht ganz einfach ist/wird, ist klar. Auch das vielleicht andere im Thread andere Ziele haben. Aber man kann ja drüber reden. Vielleicht kann mich ein anderes Design ja doch überzeugen.
Torsten C. schrieb: > Dann frage ich mal anders: Was soll denn das STM32F4DISCOVERY tun? Anders gefragt: was soll denn der PC machen? Nur Display-Ersatz?
Mensch. Nimmt einfach mein Acquisition Modul.Verbindet es mit ST discovery, und fertig ist die Sache:)
Böser Kommunist schrieb: > Nimmt einfach mein Acquisition Modul. Bin aus den Threads nicht recht schlau geworden. Ich finde viele Fragen, einige Antworten, aber keine Beschreibung. Böser Kommunist, wie wär's hiermit? http://www.mikrocontroller.net/wikisoftware/index.php?title=Chromosomas_Acquisition_Modul&action=edit Hannes W. schrieb: >> Dann frage ich mal anders: Was soll denn das STM32F4DISCOVERY tun? > Interface spielen. Die Frage ist ja, ob es nebenbei überhaupt noch etwas > anderes tun kann - der Flaschenhals USB 2.0 bliebe ja bestehen. Ich dachte, wir sind schon bei USB3 angekommen, sonst wird das nix. Aber mit 168 MHz 640 MByte/s übertragen? Auf dem STM32F4DISCOVERY ist nur ein 8MHz-Quarz. Hannes W. schrieb: > Anders gefragt: was soll denn der PC machen? Nur Display-Ersatz? Ist schon OK, wenn der PC alles macht. Aber wie kommen die Daten so schnell in den PC?
Ok dann fangen wir mal an kompromisse zu machen und splitten wir jetzt mal das ganze in 4 teile is im raum stehen: 1.) Alles fällt und stirbt mit der Software 2.) die 1/3 channel variante nur mit einem F4Discovery (bzw halt irgend einem dev-board) ist sicher für ziemlich viele elektronik einsteiger, studenten, schüler,... interessant da billig 3.) Discovery mit vergewaltigtem DMA-Sampling ist ein schritt in richtung "richtigem" DSO und könnte (solange usb2 reicht) auch SDR leute anlocken. 4.)CPLD/FPGA Design 1.) und 2.) würde ich parallel machen. Einerseits weil man damit viele mitstreiter finden kann wenn man eine günstige experimentierplattform hat und und anderseits weil nicht allzuviel aufwand. den Trigger könnte man ürigends mit dem Analog-Watchdog-Feature implementieren. Ein einfaches DSO wäre also wirklich mit einem Analogfrontend allein drinnen! Wenn man das in der firmware vorsieht kann man ja auch locker I2C Address-Match Trigger einbaun,... die "hardware-decoder" wären ja im chip :) 3.) sehe ich als sinnvollen schritt, da man das board damit zum aquisition-system hernehmen kann... solangs usb hergibt, bekommt man die daten zum pc.. schon 10msps bei 16bit dürfte sogar vielen SDR-leuten gefallen... müsste man halt im konzept bedenken, dass die anzahl der kanäle variieren kann... 4.) ehrlich gesagt kenn ich mich (leider) damit (zu meiner schande) zuwenig aus... würds aber cool finden über so ein projekt da reinzufinden. auch hier würde ich einfach eine fertige hardware nehmen und max ein analog-frontend dazubaun... wenns so einmal geht kann man eh noch immer eine schönere hardware bauen.. aber 4layer+ kosten einfach zuviel als das es viele nachbauen würden. man findet ja auch günstige pld-boards... z.b. http://at.farnell.com/lattice-semiconductor/lcmxo2280c-b-evn/board-breakout-machxo-2280/dp/2253065 nur cpld+programmer um <25e http://at.farnell.com/terasic-technologies/p0082/entw-bord-de0-nano-fpga-cyclone/dp/2076463 fpga-board um ca 75e http://at.farnell.com/altera/dk-dev-5m570zn/entwicklungskit-max-v-cpld/dp/1862386 hat noch mehr interessantes zeugs drauf gäbe also da sicher auch nettes boards <100e die man misbrauchen könnte.
Schau dir mal den Cypress FX3 an, ist ein USB 3.0 SuperSpeed Controller mit ARM9 Kern, 512kByte RAM und schnellem parallelem Interface. Der kann quasi ohne externe Logik 400MB/s in die internen Speicher bewegen, da kannst du 4 A/D Wandler mit je 8 Bit parallel anschließen und mit 100MS/s auslesen. Da guckt der STM bloß blöd aus der Wäsche. Kostenpunkt etwa 30€, allerdings BGA, müsste man dann ein Demoboard nehmen.
dummerweise wollen die für das demoboard fast 250e :( trotzdem danke für den tipp! das discovery war ja nur wegen dem preis eine idee... immerhin muss es deutlich günstiger sein wie die entry-level dinger um überhaupt eine daseinsberechtigung zu haben... und oft würde ja auch 1-10MHz analogbandbreite reichen... 73
Angehängte Dateien:
-
Prot2.png
59 KB
Na, die WIKI webseite mache ich erst, wenn ich das Protoyp zusammenbaue und teste:) Also, für dich erkläre ich es noch einaml. Ich benutze drei ADC08200 mit max. 200 MHZ. Jeder ADC besitzt eigenen DAC5311. Mit diesen DAC kannst du die Vref für ADC einstellen. D.h. die Spannung von 0 bis Vref wird in 8 Bit aufgelöst. Das ist sehr hilfreich, wenn du weiss, dass dein Signal 1 Vpp hat, kannst du auch diesen 1 Volt mit 256 Stellen auflösen. Die DAC's werden durch die SPI-Schnittschtelle programmiert. Sowohl die ADC'a als auch die DAC sind an CPLD (MAX II 570LE) angeschlossen. Die ganze Konfiguration (CLK-teilung für ADC, Vref- Einstellung, Triggerung etc) erfolgt von hier. Als Haupttakt dient FOX Electronics XO mit 250 MHz (+- 10ppm). Dieser takt wird je nach Einstellung geteilt, und an die ADC geleitet.Somit ist die Samplerate ( und somit auch der Energieverbrauch) variabel. Das Modul Besitzt 3 BNC buchsen, JTAG für CPLD Programmierung, insgesamt 47 GPIO(!!) und 7 LED'S. Alle Bauteile habe ich schon zuhause liegen, und die 4-Layer PCB ist schon bestellt. Außerdem ist die Firmware (in VHDL) für das CPLD fast fertig. Die Firmware erlaubt externe Steuerung des Modules. Das bedeutet du kannst von deinem ST Discovery an das Modul die Befehle senden, und "live" die Abtastrate, Referenzspannung etc. einstellen. Anbei die finale Version des Moduls Falls du Fragen hast=>Frag einfach;)
Hans Wilhelm schrieb: > 4.) ehrlich gesagt kenn ich mich (leider) damit (zu meiner schande) > zuwenig aus... würds aber cool finden über so ein projekt da > reinzufinden. Ich habe vor 20 Jahren in meiner Diplomarbeit eine Xilinx FPGA eingesetzt. Damals war das noch was für Leute, die sich auskennen und Geld für die teure Software hatten. Letztes Jahr habe ich ich mal wieder ein FPGA-Design gemacht, einen MIDI Patcher. Die Tools sind inzwischen kostenlos und sogar was für Oma Emma: Einfach Schieberegister, Flipflops, Multiplexer usw. wie bei Eagle aus 'ner Bibliothek zusammenklicken, Baustein auswählen, auf den Knopf drücken und schauen, ob's rein paßt oder der nächst größere Baustein her muss. Also: **** Die Ausrede zählt nicht! ****
Böser Kommunist schrieb: > Mensch. Nimmt einfach mein Acquisition Modul.Verbindet es mit ST > discovery, und fertig ist die Sache:) Ich habe jetzt noch einmal deinen Schaltplan angesehen. Ich sehe irgendwie dein Analog-Frontend nicht im Schaltplan. Also AC/DC-Kopplung, frequenzkompensierter Spannungsteiler, PGA/VGA, etc. pp. Das ganze in CAT I. Ich fragte ja schon nach einem Analog-Frontend. Also ist nix mit verbinden und fertig, denn dann habe ich ja schonmal mindestens zwei Platinen, die ich fertigen lassen müsste. Böser Kommunist schrieb: > Ich benutze drei ADC08200 mit max. 200 MHZ. Jeder ADC besitzt eigenen > DAC5311. Mit diesen DAC kannst du die Vref für ADC einstellen. > > D.h. die Spannung von 0 bis Vref wird in 8 Bit aufgelöst. Das ist sehr > hilfreich, wenn du weiss, dass dein Signal 1 Vpp hat, kannst du auch > diesen 1 Volt mit 256 Stellen auflösen. Haha. Das ist ja nur die halbe Wahrheit. Vrb liegt bei dir auf GND, d.h. wenn ich ein Signal mit 1 Vpp und einem Offset von 1 V habe, wars das mit den 8 Bit. Torsten C. schrieb: > Ich dachte, wir sind schon bei USB3 angekommen, sonst wird das nix. Ok. Ich war mir nicht sicher, ob du nun so Recht überzeugt warst, alles zu übertragen. Ich habe übrigens keinen Computer mit USB3 ;) Christian R. schrieb: > Der kann > quasi ohne externe Logik 400MB/s in die internen Speicher bewegen, da > kannst du 4 A/D Wandler mit je 8 Bit parallel anschließen und mit > 100MS/s auslesen. 4 Channel, 100MS/s ist sicher auch nicht verkehrt. Hans Wilhelm schrieb: > 1.) Alles fällt und stirbt mit der Software Und der Hardware. Ich habe noch nie ein USB2.0 HighSpeed Hardware Design gemacht, geschweige denn USB3.0 SuperSpeed. Habt ihr da Erfahrungen? > 2.) die 1/3 channel variante nur mit einem F4Discovery (bzw halt irgend > einem dev-board) ist sicher für ziemlich viele elektronik einsteiger, > studenten, schüler,... interessant da billig Ich entwickele ja nicht für andere. > > 3.) Discovery mit vergewaltigtem DMA-Sampling ist ein schritt in > richtung "richtigem" DSO und könnte (solange usb2 reicht) auch SDR leute > anlocken. Dito. > > 4.)CPLD/FPGA Design Naja, Konzept/Blockschaltbild/konkrete Anforderungen wären schon mal nicht schlecht. Es fliegen ja recht viele Ideen durch den Raum. Ich habe noch etwas über Triggerung nach gedacht und weiß nicht recht, wie das gemacht wird, wenn der Trigger im darstellbaren Bereich mehrfach auftritt. Zum Beispiel: - Trigger: fallende Flanke bei 0.25 V - Signal: Sinus 1 Vpp, zentriert um 0 V. Wie triggert man jetzt, wenn man mehrere Perioden darstellt? Jede Periode einzeln? Also man verschiebt das Signal nur um n Samples?
Hannes W. schrieb: > Ok. Ich war mir nicht sicher, ob du nun so Recht überzeugt warst, alles > zu übertragen. Bin ich auch noch nicht. ;-) Entweder ich habe ein Oszilloskop mit sich wiederholenden Mustern oder ich nutze "Single-Shot" oder ich nutze einen LA. In den beiden ersten Fällen reicht es m.E., wenn ich 10 oder 20 mal pro Sekunde ein neues Bild bekomme. Hannes W. schrieb: > Wie triggert man jetzt, wenn man mehrere Perioden darstellt? Jede > Periode einzeln? Also man verschiebt das Signal nur um n Samples? Wenn man das mit den 10 oder 20 Bildern pro Sekunde macht^^, dann triggert man immer nur auf das erste Eintreten des Triggers im Bild. Mein 20 Jahre altes Oscar hat noch eine variable "Hold-Off"-Zeit, falls man z.B. nur jeden vierten Trigger braucht, aber 5 Trigger-Bedingungen auf dem Bild sind. Damit kann man die nächsten 3 überspringen und bekommt in stehendes Bild. Das PC-Programm könnte per Muster-Vergleich (Kreuzkorrelation) ja eine "Hold-Off-Automatik" bieten.
PS: Anders sieht das im FFT-Modus aus. Braucht man FFTs als "Filmchen" mit mehr als 10 Aktualisierungen pro Sekunde? Falls nicht, sollte man m.E. auf dem PC 'ne Eigabemöglichkeit für einen Frequenzbereich haben. Daraus ergibt sich auch das notwendige Messfenster (Zeitraum), die notwendige Sample-Rate und damit die erforderliche Datenmenge. Diese Daten werden dann als "Einmal-Befehl" per USB an das STM32F4DISCOVERY geschickt. Wenn die notwendige Sample-Rate unter der HW-Sample-Rate liegt, kann das STM32F4DISCOVERY per Interpolation downsamplen, damit die Datenmenge nicht unnötig groß ist. Die FFT kann dann im PC gerechnet werden.
naja verilog/vhdl sind eben wieder eine sprach mehr... um ein halbwegs gutes design rauszubekommen dauerts meiner erfahrung halt.. naja sei's wie's sei ;) ich befürchte nur, dass mit einem fpga/pld design die kosten einfach explodieren werden.... 200MSPS würden 2 10ns ram-bänke bedeuten... => 24*2 pins nur für den speicher von 1nem kanal... also zumindest ein tqfp 144 pro kanal => min. 4 layer um vernünftige performance zu bekommen => teuer zum nachbauen... da stellt sich dann die frage der sinnhaftigkeit... alternativ 4ns speicher sind auch verhältnismäßig teuer... naja ich bleib dabei: zuerst bediensoftware machen/anpassen mit günstiger hardware und die option für die anbindung beliebiger anderer hardware vorsehen. damit ist allen am meisten geholfen... hoffe ich :) wenn ich mir die preise und die qualität der entry-level scopes anschaue, würde ich gefühlsmäßig bei der samplingrate niedriger bleiben und dafür mit dem dynamikbereich punkten... 16bit 50-150msps mit 64k samples speicher würden z.b schon einen brauchbaren spektrumanalyzer für viele anwendungen abgeben. vielleicht ist das eh der weg zu einem open-hardware/software scope... man bietet eine plattform (visualisierungs software) die möglichst viele hardware-implementierungen unterstützt und bietet die möglichkeit jedem sein ideales frontend zu bauen. modifizierte soundkarte, das stm32-board, einen arduino für diejenigen mit wenig/keinen anforderungen sowas wie das gepostete cpld/fpga board wenns schneller sein soll oder 625ksps@24bit für audio-freaks zum snr und thd messen... alles zu konträre anforderungen um sie zu vereinen reden wir also einmal über das interface zum pc... eth und usb sind ja eigentlich die einzigen optionen... gibts schon standard-protokolle? VISA kenn ich ... gibts noch andere? 73
Hmhm. Ein "richtiges" DSO der Einsteigerklasse hat ja meist so 1GS/s bei 1Mpoints Speicher, reicht also für ne Millisekunde bei voller Samplingrate. Bei 200MS/s wären das 200kPoints. Mit den 192kiB Speicher des F4, kommt das mit ach und krach hin, schöner wäre natürlich ein Chip mit 256kiB (oder mehr). Nur liegt die FSMC-clock beim F4DISCOVERY bei 60MHz … Gut, dafür könnte man ja wieder auf 4-Channel gehen, aber die Bandbreite (bei 60MS/s) leidet da schon sehr, da bin ich mir nicht sicher, ob sich das lohnt - ich würde bei meinem 5MHz Analog Scope bleiben.
der f407 könnte nur 2 kanalig samplen weil max 16bit datenbus... f437 könnte mehr... ja, ich geb zu es wäre ziemlich eingeschränkt. 1gsps bringst du aber um den rigol-preis nicht hin. ich bezweifle das sogar schon bei 200msps... daher war ja die überlegung das maximum aus dem minimum herauszuholen. und das discovery würde so ein optimum darstellen glaube ich. sonst bleiben noch immer die spezialanwendungen und der lerneffekt. es spricht ja überhaupt nix dagegen z.b auf einen i2c address-match zu triggern und 3x 2.4msps analog zu samplen und 16bit logic... scopes die das können sind meineswissens nicht günstig und anwendung in der art kommen in der realität durchaus vor. ich glaube daher am sinnvollsten (nach der diskussion hier im thread) dürfte ein gemeinsames visualisierungs-tool und übertragungsprotokoll sein mit dem alle diese frontends funktionieren. das aquisition board oben ist sicher auch für einen bestimmten zweck optimiert. gäbe es eine software die mit einfachen mitteln dazu gebracht werden kann daten zu holen würde das ja einen mehrwert für jederman bedeuten. wie gesagt, cplds würden mich auch reizen. nur wirds bei mir beim debuggen von einem 100msps scope schon langsam eng mit den messmittel (hab nur ein 4gsps scope zur hand)... gut ich könnte mir das große R&S oder lecroy scope herholen und einen RF generator, klein anfangen ist aber für mich irgendwie der sympathischere weg. nichts desto trotz sehe ich zumindest beim visualisieren und postprocessen durchaus die möglichkeit zusammenzuarbeiten um was cooles auf die beine zu stellen. 73
Hans schrieb: > ja, ich geb zu es wäre ziemlich eingeschränkt. 1gsps bringst du aber um > den rigol-preis nicht hin. ich bezweifle das sogar schon bei 200msps... Will ich ja gar nicht. Kann ich auch gar nicht. Ein Gigasample-Scope kaufe ich und mit einem Lernprojekt kann man kein kommerzielles Produkt preislich unterbieten. > > es spricht ja überhaupt nix dagegen z.b auf einen i2c address-match zu > triggern und 3x 2.4msps analog zu samplen und 16bit logic... scopes die > das können sind meineswissens nicht günstig und anwendung in der art > kommen in der realität durchaus vor. Dafür würde ich nun wieder meinen 10€-China-"Logic Analyzer" nehmen.
Hannes W. schrieb: > Dafür würde ich nun wieder meinen 10€-China-"Logic Analyzer" nehmen. Oops, habe ich mit 90€ zuviel bezahlt? Ich habe gestern gerade das ebay 121096923360 erhalten.
Was schlägst du also vor? designen wir grundsätzliche building-blocks die ich am stm32 verwende und du am xxxMSPS cpld design? wie gesagt sehe ich den aufwand im software backend damit man was verwendbares rausbekommt. je schneller wir unsere minimalanforderungen umgesetzt haben, dest schneller wird irgendwer anders irgendwelche coolen sachen dazutun die er gerade braucht. wie ich sehe lässt mit gnuradio auch ein scope basteln...für deine SDR anwendung doch perfekt oder? ich nehme an, dass du mit sdr im hinterkopf sowieso andere anforderungen ans frontend haben wirst... 8bit sind halt nicht unbedingt viel dynamik bereich... laut wikipedia gehen im isochronen übertragungsmodus 24mb/s. 2bytes/sample würden 12msps bedeuten bzw bei I/Q sampling 6msps/s wäre ja auch ein gangbarer weg.. 1/2 channel usb-samplingmodul... nicht ganz die 20MHz bandbreite die du dir vorstellst aber doch ein anfang oder??? für gigabit ethernet/usb3 werden die hw-anforderungen eben etwas steigen... 73
upps hab mich verschaut... 24MB/s pro isochronen endpunkt.. also I/Q-Sampling mit 2x12msps wären drinnen... 73
Hans schrieb: > wie gesagt sehe ich den aufwand im software backend damit man was > verwendbares rausbekommt. Also ich habe schon viele Applikationen mit Visual Studio und deren Vorläufern entwickelt. Ich finde, da bekommt man schnell "was verwendbares" hin. Allerdings habe ich nun auch schon ein paar Jahrzehne Erfahrung damit gesammelt. Als Neueinsteiger sieht das vielleicht anders aus.
Torsten C. schrieb: > Oops, habe ich mit 90€ zuviel bezahlt? Ich habe gestern gerade das ebay > 121096923360 erhalten. Ne. Ich hab so ein für-billig-Teil 8-Kanal, 24MS/s mit Cypress FX2. Hans schrieb: > designen wir grundsätzliche building-blocks die ich am stm32 verwende > und du am xxxMSPS cpld design? Ich designe erstmal gar nichts (alleine schon gar nicht - wird ja nie fertig). Mich interessierte halt deine Idee und da habe ich etwas mit diskutiert. Hans schrieb: > wie gesagt sehe ich den aufwand im software backend damit man was > verwendbares rausbekommt. Ja, da hast du wohl recht; gerade wenn es Multi-Plattform wird/werden soll. Ich muss gestehen, mir schwirrt ja immer noch OpenGL im Kopf rum. Damit kann man dann bestimmt auch schickes digital phosphor zeichnen. Es gibt auch einige (rudimentäre) Implementierungen von Oszilloskopanwendungen in OpenGL. Wie das heutzutage mit der Portabilität aussieht, weiß ich nicht. Ich würde wahrscheinlich in Richtung Skriptsprache mit OpenGL-Binding gehen. Python, zum Beispiel. Hans schrieb: > wie ich sehe lässt mit gnuradio auch ein scope basteln...für deine SDR > anwendung doch perfekt oder? Ich habe keine SDR-Anwendung. Das war nur als Hilfe gedacht, um zu erklären wie ich mir so ein System vorstellen könnte. Hans schrieb: > laut wikipedia gehen im isochronen übertragungsmodus 24mb/s. > 2bytes/sample würden 12msps bedeuten bzw bei I/Q sampling 6msps/s Und wenn die Datenrate für den isochronen Transfer nicht zur Verfügung steht? Die 48MiB/s sind ja nahe an der theoretischen Grenze. Bulk-Transfers als alternative und mit weniger Daten leben oder dem Nutzer sagen, dass er jetzt Bitte die Maus und Tastatur abziehen soll ;) > > für gigabit ethernet/usb3 werden die hw-anforderungen eben etwas > steigen... Ja, Software sicherlich auch.
Torsten C. schrieb: > Hans schrieb: >> wie gesagt sehe ich den aufwand im software backend damit man was >> verwendbares rausbekommt. > > Also ich habe schon viele Applikationen mit Visual Studio und deren > Vorläufern entwickelt. Ich finde, da bekommt man schnell "was > verwendbares" hin. Allerdings habe ich nun auch schon ein paar Jahrzehne > Erfahrung damit gesammelt. Als Neueinsteiger sieht das vielleicht anders > aus. Meine Erfahrung ist, dass es problematisch wird, wenn man Low-Level-Graphikprimitive (Punkte) schnell zeichnen möchte. Kann aber auch daran liegen, dass ich es falsch gemacht habe. Ich wollte (musste) den OO-Ansatz gehen, anstatt die Bitmaps selbst zu manipulieren. Wenn man das macht, wird es aber m.E. nach weder einfach noch schnell.
hängt davon ab wie mans macht... für meine dissertation habe ich das problem, das ich 1M-punkte+ an daten bekomme und die dann schnell darstellen will... wenn man sich was überlegt, wie man das so dezimiert, dass man wirklich nur das anzeigt was überhaupt sichtbar ist, dann geht das sehr wohl sehr schnell... 1meg punkte einfach so in ein bitmap zu tun und dann irgendwie zeichnen zu wollen ist da nicht.. auch nicht wenn man hw-beschleunigt agiert... die 480mbit/s beziehen sich beziehen sich normal auf einen port..normalerweise haben aktuelle pc/notebooks mehrere hosts...sollte also schon gehen wenn man das teil an die richtige buchse hängt. naja werd jetzt einmal schaun wie ich zeit für das alles bekomme.. hätte ja noch ein paar andere sachen zu tun nebenbei.. auf jedenfall werd ich über das ganze mal weiter nachdenken... vllt. gibts ja eines tages wirklich was "fertiges" :) 73
Hannes W. schrieb: > Meine Erfahrung ist, dass es problematisch wird, wenn man > Low-Level-Graphikprimitive (Punkte) schnell zeichnen möchte. Kann aber > auch daran liegen, dass ich es falsch gemacht habe. Ich wollte (musste) > den OO-Ansatz gehen, anstatt die Bitmaps selbst zu manipulieren Also ich habe letztens für sowas 'ne Freeware-Bibliothek genutzt, die API ist OO und nutzt "im Hintergrund" unmanaged code. Das geht super fix. Aber das nützt alles nix, falls hier Winzigweich nicht en vogue ist und falls alles Richtung "Multi-Plattform" und "Skriptsprache" geht. Falls "Multi-Plattform", dann bitte Java! Aber dann kann ich nicht helfen.
multiplattform heißt bei mir Qt und C++... oo heißt nicht grundsätzlich "managed" code... das ist eine hirnrissige idee wie man leute davon abhält scheisse zu baun.... naja wurscht... werd mir mal anschaun was sich bei Osqoop getan hat... das war eigentlich schon halbwegs brauchbar und recht einfach zu adaptieren... 73
Hannes W. schrieb: > Meine Erfahrung ist, dass es problematisch wird, wenn man > Low-Level-Graphikprimitive (Punkte) schnell zeichnen möchte. Nö. Das kommt alles auf den Ansatz an. Wenn du mit nem MemDC und TBitmaps arbeitest und dort mit MoveTo und DrawTo (oder war's LineTo?) oder bei WinCE mit PolyLine arbeitest und das Ganze dann per BitBlt ins eigentliche Fester hievst, dann geht das selbst auf nem Pentium1 schneller als du gucken kannst. W.S.
W.S. schrieb: >> Meine Erfahrung ist, dass es problematisch wird, wenn man >> Low-Level-Graphikprimitive (Punkte) schnell zeichnen möchte. > > Nö. > Das kommt alles auf den Ansatz an. Wenn du mit nem MemDC und TBitmaps > arbeitest und dort mit MoveTo und DrawTo (oder war's LineTo?) oder bei > WinCE mit PolyLine arbeitest und das Ganze dann per BitBlt ins > eigentliche Fester hievst, dann geht das selbst auf nem Pentium1 > schneller als du gucken kannst. Ich wollte "ohne Low-Level-Graphikprimitive" schreiben. Ich habe/musste es ja objektorientiert gemacht (war halt 'ne akademische Übungsaufgabe). Schnell genug war das auch, nur hatte ich dann unnötig hohe CPU-Last.
http://www.eevblog.com/forum/projects/opensource-fpga-dev-kit-with-dsologic-analyzer-module/ https://github.com/josko7452/qwave-project
Ich glaube die interface-frage erübrigt sich... laut usb-audio spec ist die höchste mögliche sampling frequenz 8388607Hz... also könnte man das Discoveryboard sich als ein 7.2MHz Mono Mic und 1MHz Stereo Speaker USB dongle ausgeben lassen... => 0 Programmierarbeit und die ganze soundcard osci-programme würde auch funktionieren :) 73
So wie ich dachte. Viel Enthusiasmus, viel Gerede und Fantasie, and am Ende wird es nicht mal angefangen:))
Hans schrieb: > wenn 2 die selbe idee haben, dürfts nachforschentswert sein ;D Hat denn mal jemand geforscht, oder sind alle im Urlaub? Ich bin jetzt jedenfalls erstmal (fast) weg.
könnte gehn, hat aber den pferdefuß mit max 14-bit und max 54mhz dafür ließe sich ein analoger trigger an an h-sync oder v-sync dranhängen und damit das eigentlich sampling starten... bin mir aber nicht ganz sicher was sie mit 54MB/s bei 54Mhz meinen.. sollte doch 14-bit*54MHz sein.. oder es geht bei 14-bit die halbe datenrate flöten damit sich das auf 2 bytes aufsplitten für den fifo... genauer hab ich mir das aber noch nicht angeschaut... job&diss sind grad etwas stressig... 73
Hannes W. schrieb: > Ich wollte "ohne Low-Level-Graphikprimitive" schreiben. Ich habe/musste > es ja objektorientiert gemacht (war halt 'ne akademische Übungsaufgabe). > Schnell genug war das auch, nur hatte ich dann unnötig hohe CPU-Last. Hä? Ich kann deine Worte zwar lesen, aber keinen Sinn sehen. Objektorientiert heißt eben auch, daß du für grafische Aufgaben, die von den vorhandenen Objakten nicht erledigt werden, dir ein eigenes Objekt schreibst - und da kommst du eben nicht drum herum, dich um die Basis der Dinge zu kümmern. Von akademischen Übungsaufgaben, die von ihrer 7. Wolke nicht herunter kommen wollen oder können halte ich nix. Und wie du wohl gesehen hast, erzeugt die unsachgemäße Verwendung von ungeeigneten Objekten eben eine irre Prozessorlast. Versuche zu lernen, wie man es richtig macht und nicht, wie man es irgendwie hinkriegt. ich hatte vor geraumer Zeit hier mal nen Beitrag über Lndkarten auf dem uC gepostet, dort auch nen Viewer für den PC. Bei dem kann man die ganzen Karte lustig mit der Maus in alle Richtungen verschieben - und das mit viel mehr einzeln gesetzten Pixeln als bei deiner Anwendung. Es geht also - aber eben mit einem dem Problem angepaßten Objekt. W.S.
W.S. schrieb: > Ich kann deine Worte zwar lesen, aber keinen Sinn sehen. Das ist doch für dieses Projekt egal. Hannes hat doch nur erzählt, dass er sowas schon mal gemacht hat und dass man es für dieses Prokekt vllt. anders machen würde. Das wird derjenige, der es umsetzt auch sicher so machen, wie Du sagst. Ich würd's in VisualStudio ja auch so machen, wie Du sagst, aber es war ja Plattformunabhängigkeit gefordert …
wars nicht... zumindest nicht von mir... kleine update: das discovery hat leider keinen extra phy für usb... also nur langsames usb. dafür läuft der virtuelle com-port und ein einzelner adc liefert 3.8MSPS@8bit bei mir am tisch... nicht schlecht... 73
Angehängte Dateien:
-
sine.png
17 KB -
spectrum.png
16 KB
sooo das mittagspausen ergebnis... die adcs rennen interleaved bei 12msps@12bit. das ergebnis ist angehängt... plot(20*log10(abs(fft(foo(:,2)-mean(foo(:,2))))+1e-100)) plot((foo(:,2)-mean(foo(:,2)))) scheint sich ganz gut übertakten zu lassen der f4 (240Mhz clock).. hätte ich nicht gedacht. (6bit single channel wären dann 6,7msps) das testsignal kommt von einem dsox3024a 100kHz 2,5Vpp mit 1.5V offset 73
Hans schrieb: > sooo das mittagspausen ergebnis... die adcs rennen interleaved bei > 12msps@12bit. cool. Hans schrieb: > 6bit single channel wären dann 6,7msps Bei der Rechnung komme ich noch gedanklich nicht ganz mit. Welche ADCs hast Du jetzt genommen und wie angeschlossen? Oder hast Du die integrierten ADCs aus dem µC genommen? Ich würde mir auf Lochraster o.ä. auch gern ein Exemplar nachbauen, um es parallel weiter zu entwickeln. Hans schrieb: > also nur langsames usb. 12 Mbit/s sind aber immer noch mehr als 115 Kbit/s mit virtuellem com-port.
240MHz sysclk => /2 => APB2 block /2 => adc-convertion-clk 6bit brauchen 9 clkcs=> 60/9=6.67MSPS 8bit =>5.54 10bit=>4.6 12bit=>4msps beim interleaving dauert es nach dem samplen 2 clks damit der ADC zum convertieren anfängt. daher 3clks sampling+2=5; lässt man das alle 3 hintereinander tun dauert es 15 => es wird drei mal so schnell => 12msps hoffe das ist so verständlich... sonst nachzulesen im ref-man kapitel 11.7 und 11.9.3 ... ADCs habe ich (vorerst) die internen genommen. software ist nur das F4-eval board sample mit dem virtual-com-port vermischt mit dem interleaved adc-sample vom discovery-board. aufpassen das die pll richtig initialisiert ist! bei mir läufts mit dieser pll-config: /* PLL_VCO = (HSE_VALUE or HSI_VALUE / PLL_M) * PLL_N */ #define PLL_M 8 #define PLL_N 240 /* SYSCLK = PLL_VCO / PLL_P */ #define PLL_P 2 /* USB OTG FS, SDIO and RNG Clock = PLL_VCO / PLLQ */ #define PLL_Q 10 73
Übrigends habe ich glaubich eine methode gefunden 8bit 100msps/channel zu bewerkstelligen... der FSMC-Mode C dürfte in komibation mit zwei 60mhz AD9283 funktionieren... der eine bekommt NOE als encode trigger, der 2. NADV mit dem richtigen FSMC-timing sollten dann beide ihre 8bit getrennt an die datenleitungen legen und damit mit 60MHz FSMC-clock theoretisch 120 MSPS ergeben.. die busse müssten nur 30MB/s verschieben da das interface 32bit anfragen automatisch auf 2 16bit transaktionen aufteilt... grau ist alle theorie... ich glaube ich bestell mir demnächst ein paar schnelle ADCs 73
Angehängte Dateien:
-
so_1600.jpg
38 KB -
so_400.jpg
39 KB -
so_200_sinc_2.jpg
43 KB -
so_200.jpg
34 KB -
so_200_sinc_4.jpg
38 KB
Hans schrieb: > hängt davon ab wie mans macht... für meine dissertation habe ich das > problem, das ich 1M-punkte+ an daten bekomme und die dann schnell > darstellen will... Was ist "schnell"? Und mit welchem Abstand musst du das wiederholen? 1 Mpoints "schnell" zu zeichnen ist an sich kein Problem. Torsten C. schrieb: > Aber das nützt alles nix, falls hier Winzigweich nicht en vogue ist und Ist es zumindest bei mir nicht. Und ich kenne nicht Viele, die es nutzen. > falls alles Richtung "Multi-Plattform" und "Skriptsprache" geht. Du willst Windows, ich möchte OS X, der nächste Linux. Was ist wohl der lcd? > Falls "Multi-Plattform", dann bitte Java! Aber dann kann ich nicht > helfen. Warum unbedingt Java? Warum kannst du bei Java nicht helfen? Hans Wilhelm schrieb: > multiplattform heißt bei mir Qt und C++... Das wäre eine Möglichkeit. Es gibt einige Cross-Platform-Projekte die andere Sprachen und Bibliotheken benutzen, z.B. wxWidgets oder GTK. Aber richtig "schön" (im Sinne von: schnell sinnvolle GUIs zu schreiben, die maintainable sind) finde ich keine der Lösungen. Qt hat halt den Vorteil, dass eine Firma dahinter steht, die den Code pflegt. > oo heißt nicht grundsätzlich "managed" code... Hat das jemand behauptet? > das ist eine hirnrissige > idee wie man leute davon abhält scheisse zu baun.... "Managed code" ist erstmal ein Microsoft-Begriff, der nur besagt, dass der Code nicht ohne ein VM-artiges Gebilde ("CLR") läuft. Die Vorteile sind halt das höhere Abstraktionsniveau und besser Sicherheitsgarantien. Warum das hirnrissig sein soll, erschließt sich mir nicht. Torsten C. schrieb: >> Ich kann deine Worte zwar lesen, aber keinen Sinn sehen. > > Hannes hat doch nur erzählt, > dass er sowas schon mal gemacht hat und dass man es für dieses Prokekt > vllt. anders machen würde. Richtig. Nur nicht "vielleicht" sondern definitiv anders. > Das wird derjenige, der es umsetzt auch > sicher so machen, wie Du sagst. Ich habe mal etwas in OpenGL zusammen gehackt. Alles, was keine hardwarebeschleunigten Routinen verwendet, scheint mir ungeeignet zum zeichnen der Waveforms. Auch sonst findet sich nicht viel an Projekten: - xoscope: GTK, Soundkarte, schein seit 2009 nicht weiter entwickelt zu werden - Osqoop: Qt, Software-Rendering, Soundkarten-Schiene, keine commits seit 2011 - glScope, SilleScope: OpenGL Rendering, Soundkarten-Schiene, eher Demos Da ich wissen wollte, welche Performance ich von OpenGL-Rendering erwarten kann, habe ich da mal ein kleines Mockup gemacht. Bei 25 fps bekomme ich ca. 50k wfm/s, bei 1600 Samples/Waveform mit Ach und Krach auf meiner 4 Generationen (?) alten NVIDIA GeForce 320M hin (so_1600). Natürlich mit Alpha-Blending und Multisampling damit das Auge auch was davon hat. Die Signaldaten erzeuge ich immer neu und lasse die Prozessorlast mal für die Datenaufbereitung bei "echten" Daten stehen. Natürlich rechne ich einen kleinen normalverteilten Phasen-Jitter ein, damit das digital phosphor aus etwas zu tun hat. Dann habe ich das Ganze mal auf 400 Samples/Waveform reduziert und das sieht noch verträglich aus (so_400, angepasste intensity). Da sind mir nun die Lücken zu groß, also muss interpoliert werden. Also mal eine kleine sinc-Routine (FFT, zero padding, iFFT) zusammengefummelt (fftw) geschrieben und getestet (so_200_sinc_2). Die "normalen" Daten sind rot und die Interpolierten blau - man sieht schön die interpolierten Werte in den Zwischenräumen der echten Samples. Zum Vergleich (so_200) ohne die Interpolierten Werte. 4-fach Oversampling sieht zwar auch schön aus, aber die Performance geht 5 fps in den Keller (so_200_sinc_4). Ich habe keine Ahnung von Computern, daher nehme ich an, dass sich die sinc-Interpolation effizienter Implementieren lässt als ich das gemacht habe. Z.b. weiß ich jetzt, dass fftw gleichartige FFTs effizienter ausführen kann, wenn man ein bestimmtes memory layout berücksichtigt und fftw anweist mehere FFTs auf einmal zu machen. Auch OpenGL kann von einem besseren memory layout profitieren; ggf. sind VBAs/VBOs schneller. Im Moment zeichne ich nur Punkte, ggf. sehen die Kurven schöner aus, wenn ich OpenGL zwischen Samples Linien zeichnen lasse. Hans schrieb: > ich glaube daher am sinnvollsten (nach der diskussion hier im thread) > dürfte ein gemeinsames visualisierungs-tool Nach meinem kleinen Ausflug in die OpenGL-Welt halte ich Qt + GLUT für gar nicht so unbrauchbar. > und übertragungsprotokoll Da habe ich mir jetzt auch schon ein paar Gedanken gemacht: - little endian network byte order - query protocol wodurch sich Hard- und Software auf Samplingrate, Skalierung etc einigen, bzw. die Software erfährt, was denn die Hardware kann. - Paket-Header bestehend aus Datenformat (float, uint16, uint12, uint8, …), Anzahl der Samples, Index des Triggers (bei Hardwaretrigger), ggf. Samplerate/Sampleinterval, … So far
schaut nett aus :) du kannst übrigends direkt aus der Qt heraus mit opengl widgets zeichnen ... QGLWidget scheint dafür da zu sein.. in kombination mit dem QtCreator hat man eine recht nette rapid-prototype-umgebung... bastle grad an einem discovery shield für 1x 100msps oder 2x 50... garnicht leicht 2 seitig zu routen wenn man 4+ gewohnt ist und +-5V + ground layer bräuchte ... naja platzmäßig schauts noch gut aus... wobei mir noch was zum triggern, -5V erzeugung, variable tiefpässe und ein usb2 phy fehlen... größe ist genau die des discoverys... wird auf jedenfall doppelseitig bestückt sein wenns fertig ist... opvs usw sind alles standard footprints.. also alles was so wie ein 741 oder 324 ist, sollte verwendbar sein.. mit den einschrängungen des jeweiligen derivats natürlich... zusätzlich werde ich versuchen die internen ADCs auch dranzuhängen.. damit ist dann auch 12bit high-res möglich :) 73
Hannes W. schrieb: > Torsten C. schrieb: >> Falls "Multi-Plattform", dann bitte Java! Aber dann kann ich nicht >> helfen. > Warum unbedingt Java? Warum kannst du bei Java nicht helfen? Zugegeben: Die Begriffe Qt, GLUT usw. sagen mir nix. Was ich meine: Viele Leute (so auch ich) wollen möglichst wenige Programme bei sich installieren. Firefox, Flash-Player und Java nerven mich schon jetzt mit ihren ständigen Updates. Ich möchte nicht noch mehr installieren und wäre daher froh, wenn's damit gehen würde. In Java bin ich nicht fit, da bräuche ich zum programmieren 10x so lange, wie in Visual Studio. Gut, wenn ich mir für so ein Projekt Zeit nehmen würde, wäre ich anschließend sicher auch in Java etwas fitter. ;-) Wenn wir uns auf ein Protokoll geeinigt haben (sicher keine 115 KBit/s mit virtuellem com-port), dann kann ja im Grunde auch jeder machen, wie er will. Falls ich was mache, würde ich das hier gern auf dem SVN-Server ablegen. Wollen wir schon ein SVN-Verzeichnis beantragen? Siehe Hilfe:SVN.
Hans Wilhelm schrieb: > schaut nett aus :) Danke. > > du kannst übrigends direkt aus der Qt heraus mit opengl widgets zeichnen > ... QGLWidget scheint dafür da zu sein.. Ja, so in etwa hatte ich mir das gedacht. > in kombination mit dem > QtCreator hat man eine recht nette rapid-prototype-umgebung... Obwohl ich das eher als Multi-Plattform-Buildsystem missbrauchen würde. Ich habe mir über die GUI noch nicht viele Gedanken gemacht, aber ich würde von den "üblichen" Interface ([0], [1]) Abstand nehmen. Die Bedienkonzepte sind meiner Meinung nach nicht durchdacht und beschränken sich darauf ein stand alone-Gerät zu kopieren anstatt die Eingabe- und Bedienmöglichkeiten eines PC sinnvoll zu nutzen. Vertikale und horizontale Ablenkung würde ich z.B. mit dem Scrollrad der Maus (bzw. den entsprechenden Trackpad-Gesten beim Mac) einstellen. Cursor würde ich ähnlich der Einrückungen in WYSIWYG-Editoren realisieren, d.h. einfach auf eine Art Lineal (in DIVs oder s/V) am Bildschirmrand klicken und den Cursor per Drag & Drop bewegen. Ob das Ganze praktisch ist, weiß ich (noch) nicht, aber sicherlich Übersichtlicher als der Murks mit den Slider, Knobs und Comboboxen. > > bastle grad an einem discovery shield für 1x 100msps oder 2x 50... Ok. 100MSa/s ist ja ganz brauchbar. Hast du einen (vorläufigen) Schaltplan den du zeigen möchtest? > > garnicht leicht 2 seitig zu routen wenn man 4+ gewohnt ist und +-5V + > ground layer bräuchte ... naja platzmäßig schauts noch gut aus... Ui. Willst du das wirklich auf 2 Layern machen? Wie groß wäre denn das Shield, damit man mal rechnen kann, was der Preisunterschied zwischen 2- und 4-Layern bei Einzelfertigung wäre. > wobei > mir noch was zum triggern, -5V erzeugung, variable tiefpässe und ein Erfinde das Rad nicht neu - geh kopieren [2][3][4]. Alleine die entsprechende Evaluation der einzelnen Lösungen (falls überhaupt umgesetzt) dürfte lange genug dauern. Vielleicht bieten entsprechende Hersteller (TI?) auch schon Designvorschläge. > usb2 phy fehlen... größe ist genau die des discoverys... Ich denke der F407 hat die PHY on-chip? Oder meinst du für die opto-isolation? > > wird auf jedenfall doppelseitig bestückt sein wenns fertig ist... Das ist ja egal - oder strebst du eine Serienfertigung an? Torsten C. schrieb: >> Torsten C. schrieb: >>> Falls "Multi-Plattform", dann bitte Java! Aber dann kann ich nicht >>> helfen. >> Warum unbedingt Java? Warum kannst du bei Java nicht helfen? > > Zugegeben: Die Begriffe Qt, GLUT usw. sagen mir nix. Man muss ja nicht alles kennen, aber: Google? Warum möchtest du nicht mal über deinen VS-Horizont hinaus illern? > Was ich meine: > Viele Leute (so auch ich) wollen möglichst wenige Programme bei sich > installieren. Firefox, Flash-Player und Java nerven mich schon jetzt mit > ihren ständigen Updates. Wie bitte? Wenn du mit deinem Computer ein Aufgabe erfüllen willst, dann musst du schon die entsprechende Software installieren. Die UNIX-Philosophie ist diametral dazu: für jede Aufgabe gibt es ein Programm was genau diese eine Aufgabe löst und sonst nichts. Dafür löst das Programm diese Aufgabe (hoffentlich) besonders gut/effizient/fehlerfrei. Du musst ja keinen Firefox oder Flash-Player installieren. Wenn dich Updates nerven, dann schalte automatische Updates aus, oder stelle sie so ein, dass sie ohne dein Zutun ablaufen. > Ich möchte nicht noch mehr installieren und > wäre daher froh, wenn's damit gehen würde. Und du denkst, dass ein Software-Oszilloskop einfach geschrieben wird und dann fertig ist? Keine Updates, Fehlerbeseitigung, etc? > > In Java bin ich nicht fit, da bräuche ich zum programmieren 10x so > lange, wie in Visual Studio. Java ist eine Sprache, Visual Studio eine IDE. Ich bin mir nicht sicher, was du genau vergleichst. Möchtest du vielleicht Eclipse (Standard-Java-IDE) mit VS vergleichen? > > Wenn wir uns auf ein Protokoll geeinigt haben (sicher keine 115 KBit/s > mit virtuellem com-port), dann kann ja im Grunde auch jeder machen, wie > er will. Protokoll != Schnittstelle. Ein Protokoll beschreibt i.A. den Verbindungsauf-/abbau, Datenflusskontrolle, Struktur der Nachrichten, Fehlerkorrektur, … Über welche Schnittstelle (USB, Ethernet, UART) das Protokoll abgewickelt wird, kann ja dann egal(*) sein. Dann kann wirklich jeder machen, was er will. (*): Natürlich nur, wenn das Interface auch die geforderte Datenrate bringt. Ich stelle mir ein Plugin-System für Softwarestückchen vor, die ich jetzt mal "Treiber" nennen würde. Ein Treiber hat auf der einen Seite ein festes aber noch zu bestimmendes Interface, damit die GUI mit dem Treiber reden kann. Auf der anderen Seite hat der Treiber ein beliebiges Interface, was ihm ermöglicht mit beliebiger Hardware zu reden. So kann man die GUI auch für den Soundkarten-Kram nutzen, wenn jemand einen Treiber schreibt, oder auch komplett andere Hardware ([2], [4]) anschließen. > Falls ich was mache, würde ich das hier gern auf dem SVN-Server > ablegen. Das kannst du gerne tun, ich würde eher Git benutzen. [0] http://www.armkits.com/product/images/2300.gif [1] http://www.zeitnitz.de/Christian/images/scope_140_small.gif [2] http://www.opencircuits.com/Oscilloscope#Open_Source_Oscilloscopes [3] https://code.google.com/p/opendso/ [4] DSOscope: http://ocrg.org/level2pages/project_corner.html
sorry, aber ich habe svn hassen gelernt... mercurial hab ich am shared-webspace rennen würde... alternativ kommt in absehbarer zeit noch git auf meinen heimserver oder vps.. da bin ich noch unentschlossen... der qtcreator ist zum debuggen und gui-designen ziemlich brauchbar. das mit der gui sehe ich ähnlich... aber zuerst muss das sampling rennen :) der "shield" hat genau die abmessungen des discoverys.. also 66x97mm nachdem ich jetzt erstmal nur meine theorie ausprobieren will, sind mir 4-layer derzeit zu häftig... außerdem will ich das dann nicht mehr mit eagle routen... und bei uns in der firma hat die IT wieder mal das mentor update vermurkst => warten bis ich wieder ein lauffähiges pads bekomm... der controller hat einen fullspeed-phy on-chip. der hat aber einige einschränkungen und kann nur 12mbit/s. hab mir das mit dem externen angeschaut... das wird unter 4-layer nix... ein erster layout/schematic vorschlag kommt später am abend... ein bisserl fehlt noch... fertigen würd ichs bei vrint-pcb oder haka-lp lassen... 1ster wär wesentlich schneller, kosten wären bei 20e/Stk (wobei bei beiden 2 mindestens kommen würden)... die chinesen sind mir schlicht zu langsam... als trigger würde ich jetzt vorerst nur die internen ADCs verwenden... aber mal schaun, vllt bekomm ich da noch irgendwie ein paar komperatoren drauf... ich bin mir übrigends nicht so sicher ob ich die 10mhz analogbandbreite mit dem design so überhaupt hinbekomme... gedacht ists eher zum testen ob man direkt vom F4 die 100msps zusammenbekommt... für die interen ADCs sollts aber reichen... die ganzen chips für einfache frontends kosten in stückzahl alle so um die 3-5e und einzelpreis 10-20e... das ist mir zu viel...für kleinserien ok, aber so komm ich bei 4 channels schon mit adcs und frontends in die gegend von nem rigol... für das was mir vorschwebt sind 10msps eigentlich ok, 100 perfekt.. dafür würd ich gerne >4 kanäle haben... und das günstig... 100e für den prototypen sollten sich ausgehn, und wenn er tut bau ich mir um 400e ein 8channel scope :) 73
Hans Wilhelm schrieb: > sorry, aber ich habe svn hassen gelernt... mercurial hab ich am > shared-webspace rennen würde... alternativ kommt in absehbarer zeit noch > git auf meinen heimserver oder vps.. da bin ich noch unentschlossen... Hihi. Wenn du SVN hast, was denkst du dann von CVS? ;) > der qtcreator ist zum debuggen und gui-designen ziemlich brauchbar. Oh. Der Designer ist so lala aber zum Debuggen ist das Ding nicht zu gebrauchen. > der "shield" hat genau die abmessungen des discoverys.. also 66x97mm Da würde die 4-Layer-Platine ~35€ beim Jakob hier aus dem Forum kosten. > nachdem ich jetzt erstmal nur meine theorie ausprobieren will, sind mir > 4-layer derzeit zu häftig... Ok. Verständlich. Hast du schon mal HighSpeed USB geroutet? Auch auf Duallayer? Funktioniert das mit der Impedanzanpassung? > außerdem will ich das dann nicht mehr mit > eagle routen... und bei uns in der firma hat die IT wieder mal das > mentor update vermurkst => warten bis ich wieder ein lauffähiges pads > bekomm... > > der controller hat einen fullspeed-phy on-chip. Ja, ich hab's gerade gelesen. Warum die das gemacht haben, soll mir ein Rätsel bleiben. Kostet eine HS-PHY so viel mehr? > hab mir das mit dem externen > angeschaut... das wird unter 4-layer nix... Der Vorteil einer externen PHY ist, dass man gleich die opto-isolation mit rein designen kann. Wer die nicht will, kann ja dann die Pads brücken, o.Ä. > > ein erster layout/schematic vorschlag kommt später am abend... ein > bisserl fehlt noch... Keinen Stress. > > fertigen würd ichs bei vrint-pcb oder haka-lp lassen... 1ster wär > wesentlich schneller, kosten wären bei 20e/Stk (wobei bei beiden 2 > mindestens kommen würden)... die chinesen sind mir schlicht zu > langsam... Ok. Bei mir kann's ruhig dauern, wenn es ein paar Euro günstiger kommt. Ist immerhin nur Hobby. > > als trigger würde ich jetzt vorerst nur die internen ADCs verwenden... Also per Software? Oder gibt es da eine Hardware-Vorrichtung, die die Samples analysiert und einen Interrupt o.Ä. generiert, wenn eine Schwelle über-/unterschritten wurde. Wenn es das nicht gibt, macht man sich ja den Vorteil des DMA wieder kaputt, da die CPU jedes Sample anfassen muss. > > aber mal schaun, vllt bekomm ich da noch irgendwie ein paar komperatoren > drauf... Das wäre schön. Ich hoffe der STM32F407 hat mindestens einen DAC eingebaut. > > ich bin mir übrigends nicht so sicher ob ich die 10mhz analogbandbreite > mit dem design so überhaupt hinbekomme... gedacht ists eher zum testen > ob man direkt vom F4 die 100msps zusammenbekommt... für die interen ADCs > sollts aber reichen... Wie meinst du das? Du musst doch nur das AA-Filter passend bemessen. Oder meinst du von der Leiterbahnführung her? > die ganzen chips für einfache frontends kosten in stückzahl alle so um > die 3-5e und einzelpreis 10-20e... das ist mir zu viel...für kleinserien > ok, aber so komm ich bei 4 channels schon mit adcs und frontends in die > gegend von nem rigol... Was meinst du mit Frontend? VGA + ADC-Treiber? Guck dir doch mal den LMH6522 an. Der kostet 18€ und hat 4 Kanäle -> 4,50€ / Kanal. Das geht doch. Zwei von den Dingern und du hast dein 8-Kanal Scope. Oder die VCA26xx-Serie von TI. > > für das was mir vorschwebt sind 10msps eigentlich ok, 100 perfekt.. > dafür würd ich gerne >4 kanäle haben... und das günstig... 100e für den > prototypen sollten sich ausgehn, und wenn er tut bau ich mir um 400e ein > 8channel scope :) Was schwebt dir denn so vor? Was ist deine Anwendung von einem 10MSa/s, 8-Kanal Scope? PS: Darf ich fragen worum es in deiner Diss geht?
mit cvs hat mich gottseidank noch niemand "beglückt"... in der arbeit ist auf jeden fall svn angesagt... und es ist oft ziemlich umständlich... der LMH6522 kann leider kein DC...-5dB bei 1Mhz.. laut den lustigen bildchen... eher sowas:AD8330 ich hab analog muxes zum verstärkung und bandbreiten einstellen eindesignt... die ganzen lustigen logik familien habe ich aber noch nicht durchgeschaut, aber 10mhz können sogar die neuern 4066er... ich hoffe also, bei den muxes ist das auch so... das problem das ich nur 1st order habe :( optoisolieren würde ich mit einem off-the-shelf usb isolator... die einzelnen channels an einen usb-hub und den hub mit einem isolator an den pc. der ADC hat so ein lustiges feature, das man einen interrupt bei über und/oder unterschreitung einer schwelle bekommt.. zwar vergleichweise ein langsamer trigger, aber wär dabei. ich hab jetzt mal beide DACs für die 2 Trigger dran gemacht.... man vllt. will man ja einmal komplett unabhängige channels haben... bei der diss gehts um multiphysics simulation... und ich will meinen simulator gegen testschaltungen benchmarken... wenn ich mir ein einfaches buck converter anschau, dann fallen mir schon ein paar interessante channels ein zum gleichzeitig samplen... für 100kHz schaltfrequenz reichen 10Msps locker... für die effizientberechnung: strom/spannung am eingang strom/spannung am ausgang grundsätzlich interessant: strom durch die diode spanung über die diode strom durch die drossel zum multiphysics benchmarken: 3+ temp channels 2+ h-field probes da wär ich schon bei 7+5 channels... kann man auch nach einander samplen, aber wenn das auf einmal ginge.... ;) ich seh grad, das f3-discovery hätte 4x 5msps on-chip.... hab ich doch auch von irgend einem fae einmal in die hand gedrückt bekommen... sollt das bei zeiten auch mal auf max-speed testen... 73
Hans schrieb: > der LMH6522 kann leider kein DC...-5dB bei 1Mhz.. laut den lustigen > bildchen... Hups. So genau hatte ich das DB gar nicht gelesen. Ich hatte angenommen, der wäre ähnlich dem LMH6518. > > eher sowas:AD8330 Analog. Gut, aber auch teuer. Und dann gleich 'nen 150MHz Verstärker für eine 10MHz-Eingangsstufe. Da passt 'was nicht. > > ich hab analog muxes zum verstärkung und bandbreiten einstellen > eindesignt... > die ganzen lustigen logik familien habe ich aber noch nicht > durchgeschaut, aber 10mhz können sogar die neuern 4066er... ich hoffe > also, bei den muxes ist das auch so... Dafür nimmt man Relais. > > das problem das ich nur 1st order habe :( Ja, ist doch bei Oszis so, oder? > > optoisolieren würde ich mit einem off-the-shelf usb isolator... die > einzelnen channels an einen usb-hub und den hub mit einem isolator an > den pc. Ach du willst für jeden Kanal ein STM32F4 haben, oder wie? > wenn ich mir ein einfaches buck converter anschau, dann fallen mir schon > ein paar interessante channels ein zum gleichzeitig samplen... für > 100kHz schaltfrequenz reichen 10Msps locker... Aber nur, wenn du nicht an den Transienten interessiert bist - sonst ist das Faktor 100 zu wenig. > > für die effizientberechnung: > strom/spannung am eingang > strom/spannung am ausgang Ok, da würde ja ein Mittelwert reichen, für die Temperatursensoren auch. > > grundsätzlich interessant: > strom durch die diode > spanung über die diode > strom durch die drossel Hier bräuchtest du aber die Spitzenwerte, oder? Die wirst du mit 10MSa/s nur mit Glück sehen.
relais => teuer, groß... für ein richtiges scope ja und dann gleich vernünftige hf dinger, für 10MHz... naja dann lieber ein billiges rigol weil besser und ziemlich sicher billiger bei den scope-designs die ich mir so durchgeschaut habe sinds 4-5 polige filter... aber die gingen mit der analog bw schon ziemlich knapp an fs/2 dran... ich will bei meiner diss möglichst einfache modelle finden um möglich effizient thermisches und "emv"-verhalten liefern können. d.h. ich hab einen solver für das thermische und elektrische problem gebaut und rechne mir jetzt demnächst über einen einfachen biot savart solver einmal H über dem pcb aus (irgendwie komm ich in letzter zeit nicht dazu die layout daten in den simulator einfließen zu lassen). klar, werde ich keine vernünftige aussage über abstrahlung bei 100MHz+ treffen können, aber grundsätzliche designfehler sollte man sofort erkennen. da einfach und halbwegs gut dokumentiert habe ich mir einmal einen 34063 modelliert ... die schaltungen im datenblatt sind für 25khz dimensioniert.. das liese sich mit 12Msps meiner meinung schon halb darstellen...128kb sampling buffer sind halt gerade mal 1ms sampling zeit bei 100msps... naja vllt überdenke ich das eh noch komplett und bau ein hartes filter bei 10mhz ein... dann gibts nur eine sampling frequenz... würd das layout wesentlich schöner/übersichtlicher machen. 73
Angehängte Dateien:
-
schope_pcb.png
59 KB
wie versprochen pcb und schematic... wobei beides noch fertig ist.. eher mal um zu schaun ob sich sowas vom platz überhaupt ausgeht...pinning am stecker ist auch noch nicht verifiziert. kurze beschreibung was ich mir gedacht habe: ac/dc kopplung -> 1:1/10:1 für Messbereich, 1Meg impedanz und buffer -> PGA diskret mit variablem tiefpass -> ADC das ganze noch gespickt mit trigger für comparator. 73
Hannes W. schrieb: > Torsten C. schrieb: >> … Was soll denn das STM32F4DISCOVERY tun? > Interface spielen. Die Frage ist ja, ob es nebenbei überhaupt noch etwas > anderes tun kann - der Flaschenhals USB 2.0 bliebe ja bestehen. Hmmm, und das geht jetzt? Und ist das besser als ein 0815-FPGA, der die Sample-Daten nach USB umwandelt? Der könnte im BlockRAM ja auch ein paar Bytes puffern. Torsten C. schrieb: > Zwei STM32F4DISCOVERY habe ich hier rum liegen. Ich habe lestzes Wochenende erstmals mit CooCox ein Programm geschrieben und in's STM32F4DISCOVERY geflasht und würde nun gern auch mal die "Projektidee Oszilloskop" in der Praxis erproben. Aber "Interface spielen" mit einem STM32F4DISCOVERY, macht das Sinn? Hannes W. schrieb: > Torsten C. schrieb: >> Oops, habe ich mit 90€ zuviel bezahlt? Ich habe gestern gerade das ebay >> 121096923360 erhalten. > Ne. Ich hab so ein für-billig-Teil 8-Kanal, 24MS/s mit Cypress FX2. Vielleicht wäre ein "Open Logic Sniffer" die bessere Wahl gewesen. http://www.watterott.com/de/Open-Logic-Sniffer
Soo einige Zeit ist das ganze jetzt abgelegen, jetzt gibts wieder was neues... http://www.st.com/web/catalog/tools/FM116/SC959/SS1532/PF259090 Wenn die säcke noch einen USB2 PHY draufgetan hätten... naja aber schon richtig neat :) farnell meint etwas über 25e... schreit direkt nach einem osci-shield... hin und wieder ists ganz gut etwas abliegen zu lassen :) 73
Hi, ich wollte mal fragén wie es mit deinem Projekt aussieht. Hast du was laufendes hinbekommen?
Böser Kommunist schrieb: > Aber CPLD, diverse passive Elemente +4-Layer PCB habe ich > selbst bezahlt. Alles in allem wird es so um 100-120 Euro kosten. Darf man fragen wo Du die Platinen bestellt hast? Gute Quellen für 4-Layer Platinen die fein genug sind für CPLD und ezahlbat sind imer genr gesehen.
Mit dem F4 discovery, ja... bildchen oben... das neue muss ich mir erst bestellen... war beruflich die letzten monate sehr viel im ausland... und so wie's aussieht wirds so bleiben bis ende des jahres :/ Eigentlich fehlt ja "nur" das frontend... das ist aber auch das eigentliche problem... 1mV/Div würde bei 1MHz Analogbandbreite schon 375MHz GBWP erfordern... das ist mir für so ein schnelles projekt zu aufwendig... ICs wie z.B. ADRF6510 oder LTC6602 wären das Mittel der wahl... da bin ich noch auf der Suche nach was wirklich sinnvollen... Eine andere Idee die mir herumschwebt wäre programmierbare probes zu machen... also einen "HF" tauglichen connector zu nehmen wo man z.b. I2C drüberbringt und sagen wir mal 10MHz. Dann sollte man bis 30V mit einer 10:1 Probe und einem BNC->"anderen stecker" Adapter können und hätte die möglichkeit schlauere adapter mit amp reinzutun... Das problem ist der preis.. ein DS1052 bekommst du schon unter 300e... ideal wär sowas wie bei den "richtigen" scopes... bnc+ein paar pins... dann gibts mit nem zwischenadapter bw-limit, gain-stage,... und sonst halt max 3V (oder meinetwegen die typischen 5V) 73
Hat sich die Projektidee erledigt?
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.