Hallo, ich weiß nicht ob das einen Thread wert ist, aber für Anfänger wie mich sind solche Beispiele doch ganz nützlich. Also: Ich habe ein DSO gebastelt das das Bild über VGA ausgibt, im Groben aus einem FPGA und einem ADC. Und zwar ohne CPU sondern nur in VHDL. Bauteile: Nexys2 (Digilent) -- das FPGA Board Flashy (KNJN) -- das ADC Board mit ADC08200 Rotary-Encoder VHDL Komponenten: VGA (1024x768) Entprelleinheit für die Rotary-Encoder Das "Main" mit der Ansteuerung von RAM und dem ganzen Rest. Probleme: 1. Der PSRAM ist zu langsam, ich verwende also nur BRAM. 2. Über ca. 100MHz Samplerate wird das Signal schlecht, das liegt vermutlich am Nexys2. Ich warte noch auf die Artix-Boards bei Trenz und werde dann da den DDR3 als Speicher verwenden und hoffentlich auch 200MHz als Samplerate erreichen. Code: Klar hab ich, kann ich auch anhängen aber da ich am Board viel rumgelötet habe wird das nicht 1:1 laufen. Ich würde lieber auf konkrete Fragen mit Codebeispielen (die ich dann noch verständlicher gestalte) antworten.
Angehängte Dateien:
-
DSO_board.jpg
410 KB -
DSO_screen.jpg
180 KB
Für eigene Starterkit-projekte wurde ich gern auch Drehgeber verwenden. Wie es ausschaut hast du bei dir diese angelötet und nicht gesteckt, warum?
Weil ich keine passenden Stecker hatte und den PMOD vom Nexys2 (JC)
schon vorher weggelötet hatte.
Also die kann man auch stecken, man sollte sie vor allem aber richtig
beschalten. Ich habe da große (>10k) Widerstände drinnen (hier die Seite
mit den 3 Pins):
V+ ------ R ------ Encoder_Pin_0 ------ FPGA_Pin
|
|
GND -------------- Encoder_Pin_1
|
|
V+ ------ R ------ Encoder_Pin_2 ------ FPGA_Pin
Es liegt also V+ (3,3V) am FPGA an ausser der Encoder verbindet gerade
V+ mit GND. Und im FPGA hatte ich dann zuerst fallende Flanken
verwendet, das ging auch, aber nicht sonderlich gut. Das muss man noch
entprellen.
Entprellen geht auch mit einem Kondensator, ich hab das aber im FPGA
gemacht.
Die fehlen noch Einheiten im Bild. So nutzt das nichts. Vielleicht könnte man das Projekt mit denen hier verknüpfen und etwas allgemein Nutzbares daraus zaubern? Beitrag "FPGA Oszilloskop mit VGA Ausgang" Beitrag "Gesucht: FPGA-basierter LA / Oszi mit VGA-Ausgang"
Gustl Buheitel schrieb: > Code: Klar hab ich, kann ich auch anhängen Dann mach das doch. Die Fragen kommen oft erst mit dem Lesen des Codes...
Einheiten habe ich nicht, weil ich noch keinen Plan habe, wie ich Text auf den Monitor schreibe ohne, dass es in viel Arbeit ausartet. Das werde ich aber auf jeden Fall dann mit einbauen, wenn ich auf ein anderes Board und vielleicht auch ADC umsteige. Der Code ist wirklich unleserlich, ich hab das nie richtig gelernt oder so und mich auch an keine Guidelines gehalten. Ich wollte eigentlich eher so prinzipielle Sachen erschlagen und vielleicht auch Fragen dazu beantworten. Das Ganze ist nich sehr einfach, also auch das Zoomen (x-Achse) geht nur in 2er Potenzen und viele weitere Beschränkungen. Ich muss mir auch mal eine vernünftige Triggerfunktion überlegen bei der ich eine variable Steilheit zum Triggern einstellen kann.
Gustl Buheitel schrieb: > Einheiten habe ich nicht, weil ich noch keinen Plan habe, wie ich Text > auf den Monitor schreibe ohne, dass es in viel Arbeit ausartet. Das > werde ich aber auf jeden Fall dann mit einbauen, wenn ich auf ein > anderes Board und vielleicht auch ADC umsteige. Zufälle gibt's... Ich arbeite aktuell an einem Logicanalyzer mit VGA-Ausgabe auf einem Nexys3: http://www.mikrocontroller.net/articles/Durchblicker Bewegliche Cursor und Zeichenausgabe (Hex) ist drin, Quellen auf sourceforge (siehe Artikel unten). Bei der Integration in dein Projekt würde ich gern unterstützen. MfG,
Ui, das sieht richtig gut aus! Klar mein ADC hat jetzt 8 Bit Auflösung, es werden alle bei jedem Takt 8Bits geschrieben. Genauso könnte man die 8Bits dann nicht als einen wert sondern als 8 getrennte binäre Werte auffassen quasi 8 "Binärspektren" anzeigen. Das Nexys3 hat leider auch keinen schnellen RAM in den mal so mit 100MBytes/s schreiben kann, ich werde mich also noch nach einen Board mit externem RAM umgucken. Hast du VHDL und so mal richtig gelernt? Ich meine, das wird eher unspaßig wenn du dir mal meine Quelltexte durchliest ... Soweit wie ich bisher bin dient es eigentlich als Lernprojekt für mich selbst, ich würde das gerne dann auch mit besserer Hardware von Null an neu aufziehen und einiges verbessern - gerne dann auch mit LA Eingängen. Also wenn du mitmachen willst, sehr gerne! Mit minimalen Änderungen bekommst du da recht schnell aus dem DSO einen LA gebaut und auf deinem Nexys3 zu laufen.
Angehängte Dateien:
-
Prot2.png
59 KB
Interessant, interessant:) Schaue mal mein Projekt an:) Beitrag "Erste Platine (und das erste Hobbyprojekt) meines Lebens." Ich verwende auch die ADC08200. Die 4-Layer Platinen sind nach allenSignalregeln "gelayoutet" und sind schon bestellt ( kommen nächste Woche an). Die Firmware für CPLD ist eben schon fast fertig und nimmt ca. 200 LE an, D.h. man hat noch 370 freie LE für weitere Features:)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 versorgt die ADC's mit CLK (frei wählbar zwischen 250MHz,125MHz, 62.5 Mhz,31.25 Mhz.) 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. 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.Leider sind keine negative Spannungnen messbar. 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;) (VGA Display, Steuerung, externe SDRAM). Das Modul werde ich im Rahmen meines ursprunglichen Projektes für CCD-Kamera Interface zusammen mit DE1 Altera Board verwendet: 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 extern leicht ändern kann.
Das klingt ja spannend. Schaffen die ADC08200 die 250MHz? Ich habe noch nie was mit CPLDs gemacht, also wenn ich jetzt die 48GPIOs durch die 3x8Bit der ADCs teile komme ich auf 2. Also kann ich wenn ich die Daten vom ADC an den FPGA auf einem anderen Board übertrage die Hälfte der tatsächlichen Samplerate nehmen und dafür immer die 16 statt 8 Bit je ADC übertragen?! Der Preis ist auch voll ok, ich habe für das ADC Modul mit nur einem ADC08200 auch gute 100€ mit Zoll bezahlt.
Aus dem Datenblatt von ADC08200 "Although the ADC08200 is tested and its performance is ensured with a 200 MHz clock, it typically will function well with clock frequencies from 10 MHz to 230 MHz." Also einwenig overclocken sollte noch klappen:) Mit CPLD habe ich übrigens auch keine Erfahrung, aber ich denke es soll genauso gehen wie FPGA:)) Ich verstehe nicht ganz, was du mit 16 bits meinst. Etwa die doppelte Übertragungsrate im Fall, dass dein FPGA Board die 250 Mhz nicht erreicht? Eigentlich kann man ja auch alles mit externen CLK(z.B. direkt aus FPGA-PLL) ansteuern.So wird es sogar synchroner laufen... Ah ja, ich habe mich geirrt: 5 GPIO sind auf GND bzw Vcc gelegt, d.h. man hat 43 GPIO. Im Nottfall nimmt man die zwei DEV Ausgänge auch als I/O. Mindestens zwei Inputs sind für externe Steuerung reserviert, außer man lässt das Modul immer bei den gleichen Einstellungen laufen. 18 IO des CPLD sind nicht angeschlossen wegen Platzmangel, na gut wenn mann die LEDS wegnimmt, passt noch eine Stiftleiste drauf.
Genau ich dachte falls ich die 250MHz nicht schaffe. Aber eigentlich sollte das schon funktionieren. Und dann finde ich schade, dass so ADC Platinen immer nur zu speziellen FPGA-Boards wirklich passen, also die Belegung so ist, dass es einfach zusammengesteckt werden kann. Klar das ist nicht dein Problem und auch keine Kritik sondern eher so generell. Ich würde gerne ein möglichst "nacktes" FPGA Board verwenden das nur das FPGA, RAM, Spannungsversorgung und dann eben viele IOs hat - wie diese Module von Trenz. Das kann man dann immer irgendwie auf normale Stiftleisten "übersetzen" aber die Pins für GND und V+ passen dann nicht und die für die GCLK Eingänge auch nicht. Dein ADC Board ist also zu den Terasic Boards kompatibel ... die muss ich mir mal angucken. Leider sind die eher weniger "nackt" und auch nicht Xilinx. Ein Adapter lässt sich aber vermutlich auch löten. Ich bestelle jetzt einfach mal ein Board bei dir.
Das wird dich vllt. Wundern, aber mein ADC Modul ist nicht für einfach "einstecken und fertig":) Die Pinbelegung stimmt auch mit meinem DE1 Board nicht überein, d.h. ich werde ca. 3x8 Kabel brauchen, um beide Boards zu verbinden:) Die Spannungsversorgung erfolgt für beide Boards getrennt. Mein FPGA Board ist an USB angeschlossen, und kann max 500mA ziehen. ADC Board wird bei max Leistung so um 800 mA verbrauchen. Das ist für USB zu viel. Aber das ist eben ein Prototype, ich weiss noch nicht wie gut das alles noch funktionieren wird. Falls alles gut läuft, kann man sicherlich die Platine einwenig re-layouten und für bestimmte Boards anpassen. Oder man baut einen Adapter, oder lässt es einfach so zum Verkabeln. Ich bekomme 3 Platinen, und habe Teile um zwei zu bestücken. Einen Altera Programmer wirst du für CPLD noch brauchen, aber die sind für 10 Euro auf Ebay erhältlich. Na, nachdem ich mein Prototype zusamenbaue, können wir gucken wie es weiter geht.
Oh ok, ja das ist doch eigentlich super, ich kenne mich da zwar nicht mit aus, aber so Adapter für andere FPGA Boards dürften nicht soooo teuer werden. Spannungsversorgung könnte man dann auch vom FPGA Board nehmen wenn das genügend liefert - hier mein Nexys2 hängt auch am Netztel und nur zum programmieren am USB. Genau, bau das in aller Ruhe zusammen und teste das mal durch, ich bin jedenfalls sehr an einem (vielleicht auch mehrere) Modul interessiert das dann auch die 250MHz (oder zumindest 200MHz) schafft und nicht sonderlich schwierig zum Ansprechen ist. Mit Altera wollte ich mich sowieso mal beschäftigen, aber eher mit FPGAs. Was spricht gegen einen kleinen Cyclone? Oder auch Spartan?
Gegen FPGA sricht der Preis (MAXII kostet so um 10-20 Euro/stück,MAXV sogar billiger, Cyclone II so um 20-60 €) und die Tatsache, dass CPLD seine Konfiguration behält,während FPGA bei jedem Einschalten wieder Programmiert werden muss.
Den Spartan3A gibt's auch schon für 12 Euro und Flash kostet auch nicht mehr die Welt
Also meinetwegen auch ein CPLD das ist deine Entscheidung. Ich dachte nur, wenn Waveshare ein Board mit XC3S500E + ROM und bisschen Spannungswandler für rund 30$ verkaufen und es einen XC3S200 bei Reichelt für rund 15€ gibt wäre das vielleicht ganz nett.
Ich will jetzt mal meine Lösung vorstellen. Die Ausgabe ist nicht als VGA Signal auf dem Schirm, sondern den RAM per Uart auslesen und dann das Hexdump File in ein VCD Datei konvertieren. GTKwave kann mit VCD umgehen und auch Analoge Signale anzeigen. Damit ich die Wandlung einfach konfigurierbar ist, habe ich ein File (wire.conf) in dem die Verdrahtung in dem Puffer erfasst ist. einfach testen. g++ vcd.cpp ./a.out test.abc wire.conf >test.vcd gtkwave test.vcd
Ähm, sorry aber ich verstehe gerade echt nicht was das ist, also ich sehe das in gtkwave und es sieht nach RAM aus, aber?! Klar man kann den RAM Inhalt auch per UART an den Rechner schicken oder abfragen oder so und das dann da plotten, aber wieso mit gtkwave? Wenn, dann würde ich bei einem 8-Bit ADC immer 1 Byte je Sample schicken und das dann mit gnuplot einfach plotten - oder sehe ich das falsch? Ich habe das sogar schonmal gemacht, da lief dann mehrere Tage lang eine Messung und im FPGA wurde auch ein Spektrum gebaut und das dann an den Rechner geschickt und da geplottet, das müsste mit den Werten vom ADC genauso gehen. Ich hätte gerne VGA damit man eben ohne Rechner auskommt und auch damit man leichter größere Datenmengen anzeigen kann, also mit externem RAM dann vielleicht so 128M Punkte. Das über UART zum Rechner zu schicken würde recht lange dauern (ja es gibt auch USB). Eigentlich wollte ich mit dem DSO einmal was mit ADC machen. Ich habe nämlich eine Problemstellung: Ein Detektor für radioaktive Zerfälle lievert bei jedem Zerfall sehr kurze Spannungsimpulse deren Fläche der Energie des Zerfalls entspricht. Derzeit wird ein altes (> 20 Jahre) Gerät verwendet, das das Analoge Signal anguckt und irgendwas damit macht und dann sind die Impulse deutlich länger. Danach kommt ein genauso altes Gerät das quasi ein ADC ist, aber der liefert für jeden Impuls nur ein Bitmuster, das verwende ich dann um da Spektren im FPGA draus zu bauen. Aber: Es gibt Fälle in denen die schnellen Impulse so nahe zusammen liegen, dass sie nach den Geräten als ein Impuls angesehen werden und man Information verliert. Ich will also irgendwann mit einem schnellen ADC das Signal das aus dem Detektor kommt direkt angucken und da dann genauere Informationen über die Zerfälle bekommen wie es jetzt der Fall ist, vor allem will ich schnelle Impulse die nache beieinander liegen sauber trennen können. Klar dafür brauche ich kein VGA mehr und ich werde das auch direkt zu einem PC schicken, aber ich brauche hohe Samplerate, so 200MHz wären fein. Und weil mit das mit den FPGAs Spaß macht möchte ich auch da was weiterbasteln und gerne noch externes schnelles RAM anbinden, auch wenn ich das später nicht brauche weil es direkt an den PC geht. Schrift auf dem Monitor will ich auch noch lernen wenn ich Zeit habe.
Gustl Buheitel schrieb: > Ähm, sorry aber ich verstehe gerade echt nicht was das ist, also ich > sehe das in gtkwave und es sieht nach RAM aus, aber?! > > Klar man kann den RAM Inhalt auch per UART an den Rechner schicken oder > abfragen oder so und das dann da plotten, aber wieso mit gtkwave? GTKwave wird häufig zur Darstellung von Simulationsergebnissen benutzt. Dieses Tool ist sehr weit verbreitet. Mann kan sich die Zeit scrollen und auch Daten in verschiedene Formate als Ascii Wert oder in Hex oder... darstellen. Sicher kann man mit GNUplot auch eine Menge machen aber dafür wirklich nicht das Vorzugstool.
Ah ok, ich hatte gtkwave immer so gesehen, dass man damit nur wie bei einem LA mehrere digitale Signale anzeigen kann. USB-DSOs gibt es ja einige, auch im DIY-Bereich. Da gibt es auch Software die quasi "live" die daten vom FPGA als Oszi Bild darstellt mit allen möglichen Features wie dann auch FFT und so. http://www.knjn.com/Flashy.html Das ist das ADC Board das ich verwende, die Firma verkauft auch gleich passende leider sehr magere FPGA Boards ohne externes RAM und leider auch ohne VGA, aber oft mit USB. Und wie man sieht haben die auch eine Oszi Software.
GTKwave gibt es für Mac Win und Linux. Hier ist eine Einführung für eine Simulation mit GHDL und GTKwave. http://www.dossmatik.de/ghdl/ghdl_unisim.pdf http://www.fpgarelated.com/showarticle/20.php Dann verstehst du den Sinn und die Hauptanwendung im Gesamtkonzept für GTKwave besser.
Cool, wusste garnicht, dass gtkwave auch "analoge" bilder anzeigen kann. Also kann man die Daten vom ADC zum PC schicken, also lauter 8Bit Werte, da dann in eine Datei schreiben und sich danach das Signal mit gtkwave anzeigen lassen wie auf einem Oszi Bildschirm? Das ist sogar ziemlich fein.
Genau. Da GTKwave mit hexdumps nicht anfangen kann, weil die Information der Datenbreite/Verdrahtung fehlt, kommt mein Konvertierungsprogramm zu Einsatz.
Ja also sowas kann man natürlich mit einbauen, nur dass UART nicht sooo schnell ist, also für den "live" Modus muss man dann die Skalierung der Zeit im FPGA machen so dass man immer nur z.B. 1024 Pinkte schickt und da auch ne hohe Bildrate hinbekommt. Und wenn man das mal speichert, also die Aufnahme stoppt, kann man ja auch kurze Zeit warten bis dann sehr viele Punkte zum PC geschickt wurden. Ich kenne mich am PC mit UART und so halt leider nicht wirklich aus, ich verwende da derzeit Cutecom und schreibe das einfach in eine Datei die ich danach mit einem C programm durchgehe und Spektren baue. Aber wie man live auf die Schnittstelle zugreift und da dann auch live Spektren baut und updatet weiß ich nicht. Aber eine Funktion die den RAM Inhalt (nach Anfrage des PCs oder auf Knopfdruck oder in einem festen Zeitintervall) verschickt sollte leicht machbar sein und habe ich auch schon mit einem 921600Baud UART so ähnlich gemacht.
Hi, ihr wisst von den Aktivitäten von Jörg am FPGA-Design mit NIOS II für das Welec (4 Kanal-DSO, je zwei pro FPGA)? Es basiert zum Teil auf den vorangegangenen Arbeiten von Alex und seinem Leon3 (2 Kanal-DSO mit einem FPGA). Im Mikrocontroller-Teil dieses Forum wird man unter dem Stichwort Welec oder Wittig schnell fündig. Es gibt zu den Arbeiten auch eine SF Seite: http://sourceforge.net/apps/trac/welecw2000a/wiki/niosII Das Design ist schon recht weit gediehen und Jörg hat viele der Bugs im originalen Design bereinigen können. Begleitend dazu entsteht auch eine Firmware. Sicherlich könnt ihr das ein oder andere davon verwenden. Es lohnt in jedem Fall sich die Arbeit einmal anzuschauen.
Ja, das kenne ich. Mich schreckt aber die CPU ab :-D Sowas hab ich noch nie gemacht und ich will eigentlich auch nur vhdl verwenden. Klar von der hardware her wäre es sehr fein, da hat man gleich ein passendes Gerät mit Display, ADCs, RAM ...
In den Anfängen wurden auch rein Hardware basierte Ansätze verfolgt, siehe ZPU oder T51: https://svn.code.sf.net/p/welecw2000a/code/fpga/
ich würde eine hw-basierte lösung ins auge fassen. für einen LA braucht man nicht viel sw, es reicht eine sample einheit mit intelligentem trigger und der muss in vhdl geschrieben sein, da echtzeitfähig auch die anzeigen haben viele schon in vdhl gemacht einige anmerkungen: für die darstellung müsst ihr noch etwas besseres erfinden die striche oben sind nicht durchgezogen es fehlen die einheiten (zeichensatz?) die vga ausgabe sollte etwas mehr leisten, als 800x600 ich empfehle 1280x1024, da kann man das oszi raster 10x8 perfekt mit 128 Punkten unterbringen
Welche Striche sind nicht durchgezogen? Die Horizontalen? Die hab ich nur als Abgrenzung von den beiden Bereichen. Ja Zeichensatz fehlt kommt noch. Und das ist jetzt schon 1024x768 und wird es wohl auch bleiben. (Weil geht recht einfach) Ich will eigentlich kein festes Raster sondern 2 Coursors die man frei verschieben kann und die Zeit zwischen den Beiden wird dann angezeigt.
Wie Raster, Cursor, anzeige in VHDL funktioniert sieht man hier: http://www.mikrocontroller.net/articles/Datei:Durchblicker_screen_V03.jpeg Ich kämpfe noch mit dem SVN-Depot auf Sourceforge, sobald ich einen Snapshot von dort in einem neuen Verzeichnis kompilieren kann, wird es "offizierl releast. Der Zeichensatz steckt in den Dateien: http://sourceforge.net/p/fpgastartset/code/17/tree/%20fpgastartset-code/Durchblicker/src/charrom.vhd - 8x8 font für 0-9 und a-f und http://sourceforge.net/p/fpgastartset/code/17/tree/%20fpgastartset-code/Durchblicker/src/display.vhd - VGA RGB Ausgabe die cursorsteuerung (rechts , links, toggle active cursor) findet sich da: http://sourceforge.net/p/fpgastartset/code/17/tree/%20fpgastartset-code/Durchblicker/board_specific/nexys3/src/button_map.vhd - "tasten/Schalter" MfG,
Danke! Also Coursor hab ich mittlerweile schon drinnen, auch steuerbar mit einem Rotary-Encoder und unterschiedlicher Geschwindigkeit je nach Zoomstufe. Das mit dem Font muss ich mir mal angucken, sieht gar nicht sooo schwer aus. Die Zeit zwischen den Coursorn hab ich ja in Samples, also in 10ns Schritten. Ich werde wohl us als Einheit wählen, also erstmal fix. Noch kämpfe ich mit dem Problem, dass die Auswahl in der Übersicht unten nicht dem tatsächlichen Bild oben entspricht, also grob gesehen schon, aber es ist leicht verschoben. Mal sehn wann ich die Tage mal wieder Zeit habe ...
Angehängte Dateien:
-
oszi_20130711_small.jpg
220 KB
So, Coursor sind drinnen und zumindest Ziffern auch für eine Anzeige die die Zeit zwischen den Coursors anzeigt, hier ein 100kHz Rechteck. Mehr hat bei der Hardware nicht soo viel Sinn, also Spannung kalibrieren und anzeigen weil ich dafür keinen Spannungsgenerator habe. Bugs sind natürlich auch noch drinnen, also es sind Offsets in der Anzeige drinnen die durch Berechnungen entstehen, das muss ich noch fixen. Ich würde das gerne auf besserer Hardware nochmal in "ordentlich" machen, dann mit externem RAM und zwei Kanälen.
Angehängte Dateien:
Hallo:) Also das aq-Modu (Prototype-1) ist fertig. Drauf sind einige Fails zu sehen, wie zB einwenig falscher Footprint für den Spannungsregler (ist nicht dramatisch), und es fehlen vier Vias für zwei Kondensatoren( wie habe ich so was übersehen???), ist aber auch nicht so dramatisch, das habe ich mit dem Kupferdraht repariert. Aber wenn man nachdenkt, das ist meine Erste Platine und mein erstes Projekt, dann sehe ich das trotzdem als Erfolg:) Im Moment läuft drauf ein simpler LED-Zähler ,d.h. das Ding lässt sich auch programmieren:)) Ich werde am Wochenende versuchen die Firmware zu Ende zu schreiben und gucken ob alles so funktioniert wie geplannt;)
Wow super! Hier™ Beitrag "Re: Spartan-6 Entwicklungsboard, was braucht man noch?" baut auch Jemand ein Board mit einer ADC Erweiterung. Vielleicht könnt ihr euch gegenseitig helfen ...
Hallo, da bin ich wieder - und auf der Suche nach ordentlicher Hardware. Es gibt da eine feine ADC FMC die zwar teuer ist, aber auch einiges kann: http://shop.trenz-electronic.de/catalog/product_info.php?products_id=1122&language=de&SID Jetzt ist das aber ein FMC HPC Stecker, also brauche ich auch ein FPGA Board das einen solchen hat?! Sowas gibt es auch, z.B.: http://shop.trenz-electronic.de/catalog/product_info.php?cPath=243_249&products_id=1384 Aber leider finde ich kein Board das einen solchen FMC Anschluss hat, und darüber hinaus auch noch ein paar freie IOs für VGA und Bedienelemente. Ausser natürlich man gibt gleich richtig viel Geld aus, aber so unter 300€ für das FPGA Board wären fein. Alternativ gibt es von Altera ein paar FPGA Boards die gleich ADCs mit drauf haben, das sind diese hier: http://www.altera.com/products/devkits/altera/kit-dsp-2C70.html http://www.altera.com/products/devkits/altera/kit-dsp-2S60.html Und das hier: http://dev.emcelettronica.com/files/u7607/4.jpg Wie ist das eigentlich mit den FMCs? Passen da LPC und HPC zusammen, also rein stecktechnisch, also wenn bei einer HPC nur die Pins belegt sind die auch bei LPC veroanden sind? Gibt es Adapter die einen HPC Stecker "teilen"? Weil alle Pins werden bestimmt nicht von der ADC Karte verwendet, dann könnte man die üblichen für andere Dinge nutzen ... Vielen Dank!
Gustl Buheitel schrieb: > Wie ist das eigentlich mit den FMCs? Passen da LPC und HPC zusammen, > also rein stecktechnisch, Ja. > also wenn bei einer HPC nur die Pins belegt > sind die auch bei LPC veroanden sind? HPC hat 40 Kontakte * 10 Reihen = 400 Kontakte. Bei LPC sind sind davon nur 4 Reihen bestückt: LPC 40 Kontakte * 4 Reihen = 160 Kontakte > Gibt es Adapter die einen HPC > Stecker "teilen"? Ist mir nicht bekannt. Die Boards die FMC-HPC-Anschlüsse haben, sind meist auch eher hochpreisig, da auch FPGAs mit vielen IO gebraucht wird. Evtl. kannst Du eine FMC-LPC-Karte mit der benötigten Hardware entwerfen: ADC, VGA sowie etwas GPIO (PMOD). Dann kann man diese Karte an verschieden FPGA-Boards verwedenen: SP601, SP605, ZedBoard, ML501, ... Duke
Ok, ich sehe gerade, dass die ADC Karte doch einen FMC LPC hat. Das ist dann fein, ich könnte also das SP605 verwenden wobei das echt viel Zeug drauf hat das ich nie brauchen werde. Aber immerhin auch DVI/VGA und so, leider keine weiteren freien IOs für Rotary Encoder ...
Gustl Buheitel schrieb: [SP605] > leider keine weiteren freien IOs für Rotary Encoder ... Doch. Über J55 hast Du 4 IOs + VCC + GND und zwei weiter GPIO übder die SMA-Buchsen J39 und J40. An J45 kannst Du I2C-Erweiterungen anschließen. Duke
Danke! Ich muss aber erst noch überlegen ob ich das verwenden will das Board, für ein reines Hobbyprojekt ist es schon recht teuer. Vielleicht nehme ich auch ein billigeres Board wie das http://shop.trenz-electronic.de/catalog/product_info.php?cPath=243_249&products_id=1384 und gucke dann welche Pins am FMC nicht vom ADC verwendet werden, da könnte ich ja dann auch irgendwie noch einen Stecker ranlöten für VGA und Bedienelemente. Von den 160 Pins dürfen noch einige frei sein.
Anderer Vorschlag: Parallel im "uC & Elektronik"-Forum gibt's viele Beiträge zu den Welec/Wittig-Oszi (W2022A etc.). Die Oszis haben 2/4 Kanäle, 1GS-ADC, LCD + viele Buttons/LEDs und einen Cyclone II FPGA. Und das alles zusammen mit sehr umfangreicher Doku und Tools. Schau einfach mal rein. Mit ein wenig Glück kriegst du das 2Kanal-Oszi schon für unter 200 Euronen und kannst dann selber ein Design aufsetzen. Habe ich auch mal gemacht, läuft super.
Oho! das klingt nach einer Idee ... Ist der Cyclone groß, also kann man alles da drinnen machen oder muss man da irgendwie einen uC mit C nutzen? Und sind das echte 1GS? Hier ging neulich erst im Markt ein Oszi weg mit 100MHz Bandbreite aber nur 10MHz Samplerate?! Keine ahnung wie das geht ... Haben diese Welec Oszis irgendwelche krassen Nachteile? Wie ist das Display angeschlossen, also ist das VGA oder muss man das irgendwie komisch ansprechen? Ich will es möglichst einfach :-D Kann man "einfach" mit dem ADC reden? Danke! Edit: Sieht so aus als hätte dieses Oszi recht wenig Speicher ... da ist mir ein Spartan6 (der schon einiges an BRAM mitbringt) und zusätzliches DDR2 oder DDR3 schlon lieber, da hat man dann seine 128 oder 64 MPoints.
Bevor ich das DSO versuche zu beschreiben, liess dir einfach mal alle Beiträge zum Welec durch (dauert aber WOCHEN!!). Nur ganz kurz: Im Prinzip ist das ganze DSO ein FPGA (EP2C35) DevKit, alle Komponenten lassen sich relativ leicht ansteuern. Einzig die Buttons/LEDs und die Oszi-Vorstufen müssen per Shiftregister-Bausteine angesteuert werden, ist aber auch kein grösseres Abenteuer. LCD und ADC dagegen sind sehr bequem ansteuerbar. (LCD: wie VGA, ADC: einfach Clock rein, Daten raus) Programmiert wird das Board ganz einfach per Altera QuartusII. Beim ADC handelt es sich genaugenommen je Kanal um 4 ADCs mit echten 250MS, die phasenversetzt zu einer Samplerate von 1GS in der Lage sind (Bandbreite liegt bei angeblich 200MHz, relalistisch sind aber 150MHz, lässt sich aber auf 300-350MHz aufbohren). Wichtig gegenüber "deinen" Boards sind aber auf jedenfall die Vorstufen vor den ADCs, die ein DSO ausmachen. Viel Spass
Genau das viele Lesen wollte ich mir sparen :-) Klar die Vorstufe ist extrem wichtig und mit einer reinen ADC Karte kann ich bei weitem nicht den Spannungsbereich abdecken. Ich muss mich halt entscheiden zwischen einem deutlich neuerem FPGA mit viel externen Speicher und einer eher schlechten analogen Vorstufe und einem Oszi das zwar gute analoge Eigenschaften bietet (wobei wie ich gesehen habe auch da schon fleißig rumgelötet wird) und einem eher alten FPGA mit wenig RAM. Ich tendiere da eher zu den Lösung mit dem vielen Speicher, da kann man dann auch lange aufnehmen und danach das Signal angucken auf Fehler wenn man z.B. selten auftretende Ereignisse beobachten möchte.
Das Welec-DSO ist ja auch nur ein Beispiel. Es gibt noch andere DSO mit FPGA/uC und DDR-Speicher, die relativ gut dokumentiert sind. Musst dich einfach mal durch's uC-Forum durchquälen, dann findest du zumindenstens einige Hinweise. Ich selbst kenne mich halt nur mit dem Welec-DSO aus.
Gustl Buheitel schrieb: > Fehler wenn > man z.B. selten auftretende Ereignisse beobachten möchte. Wie lange willst Du aufzeichnen? Auch 1GB RAM sind bei den Abtastfrequenzen sehr schnell voll. Um einen Trigger kommst Du ncht herum. Ich würde mich eher darauf konzentrieren, komplexe Signalfilter zu integrieren und diese als Trigger zu verwenden. Denkbar wäre z.b. ein programmierbares Muster, nachdem gesucht werden kann.
Stimmt schon, vermutlich finde ich es einfach cool wenn man im nachhinein durch die aufgezeichneten Daten scrollen kann :-) Das mit dem Trigger funktioniert jetzt schon ordentlich. Ich bekomme zwei Arten von Signalen die ich messen möchte, es handelt sich jeweils um schöne glatte Peaks aus einem Detektor. Einmal ist der Peak so 10-20ns lang, und wenn man den dann durch einen analogen verstärker schleift der noch anderes Zeug macht, dann ist der danach einstellbar ein paar µs lang. Von der Spannung her kann ich das schon so einstellen, dass es im dem Bereich des ADC liegt und ich keine weitere Vorstufe brauche (?). Jedenfalls wenn ich den langen Peak jetzt mit den 100MHz und 8Bit ADC den ich verwende digitalisiere und danach ein Spektrum aus den unterschiedlichen Peakflächen (diese entsprechen der Energie) baue, dann sieht das ok aus, aber noch nicht gut. Ich würde das also gerne mit höherer Auflösung und/oder schneller samplen umd die Peakfläche genauer zu bestimmen. Daher fände ich den 16Bit 250MS/s ADC so interessant - dagegen ist 1GS bei 8Bit schlechter. Allerdings könnte man bei 1GS auch die kurzen Peaks angucken, klar sehr ungenau weil man jeweils nur so 10-20 Werte erhält, also grob 12Bit insgesamt. Ich muss mal gucken was ich mache, es funktioniert ja derzeit mit alter Hardware und ich mache das eigentlich nur, weil ich mal was mit ADCs machen wollte und, weil diese alte Hardware in der Stückzahl nicht oft vorhanden ist und wir die nachbauen lassen müssten. Zusätzlich zu dem "was mit ADCs machen" kommt jetzt noch das "was mit neueren FPGAs und externem RAM machen" :-D
Gustl Buheitel schrieb: > Edit: > Sieht so aus als hätte dieses Oszi recht wenig Speicher ... da ist mir > ein Spartan6 (der schon einiges an BRAM mitbringt) und zusätzliches DDR2 > oder DDR3 schlon lieber, da hat man dann seine 128 oder 64 MPoints. so als Grundlage fuer S6 (da ist's ein Logic-Analyzer): Beitrag "BitHound - FPGA Logic Analyzer" Du findest da (was ich prima fand) eben auch den Transfer der Daten zum PC mit recht fixem Ethernet...
Ethernet ist auch so was was ich irgendwann mal machen möchte. Mal sehen. Derzeit reicht mir für den Anwendungsfall der UART. Es wird je Peak nur ein Wert (die Peakfläche) und die genaue Zeit übertragen. Ich basten einfach mal weiter, vielleicht auch mit einem anderen Board.
berndl schrieb: > Du findest da (was ich prima fand) eben auch den Transfer der Daten zum > PC mit recht fixem Ethernet... Dieses echt fixe Ethernet ist laut Beschreibung der Webseite: "100MBit/s Ethernet interface for fast data transfer" Gäbe es eine Möglichkeit das einfach zu beschleunigen?
Thomas Werner schrieb: > Gäbe es eine Möglichkeit das einfach zu beschleunigen? Use the Source, Luke! Wenn Du passenden Hardware hast, sollte es einfacher sein 1 GBit-Ethernet zu implementierren, als 100 MBit. Duke
Das wäre doch mal eine lohnende Projekterweiterung, oder? Leider kann ich meinen GBIT-Core nicht beitragen, weil ich ihn seinerzeit komplett in und für die Firma gemacht habe. Mit 1GBit bekäme man aber die Osibilder in Echtzeit auf den Schirm!
Duke Scarring schrieb: > Wenn Du passenden Hardware hast, sollte es einfacher sein 1 > GBit-Ethernet zu implementierren, als 100 MBit. Ja?
So, also ich habe nicht viel Neues. Ich werde vermutlich ein DSO im Rahmen einer Arbeit and der Uni bauen, aber nur mit kleinem Funktionumfang. Ist auch alles noch in Planung und so. Heute habe ich auf einem RC10 von Celoxica schonmal sowas wie "Intensity-Grading" in simple gebastelt. Also ohne einen Bildspeicher, weil der XC3S1500L dafür zu wenig RAM hat, sondern nur mit einzelnen Punktereihen. Ich habe also 32 BRAMs die jeweils beschrieben werden und durchrotiert werden, also immer der mit den ältesten Daten wird überschrieben. Und dann bei der VGA-Ausgabe wird geguckt wieviele der BRAMs genau an dem Punkt einen Wert gespeichert haben (ganz grob). Dazu bekomme ich dann 32 Bedingungen die entweder True oder False sind - das wird dann in einem Takt "addiert", also quasi das Zählen von gesetzten Bits in einem 32 Bit Vector in einem Takt was tatsächlich bei 75MHz Pixeltakt funktioniert. Das Ergebnis bestimmt dann die Helligkeit auf dem Schirm. Bilder: Ein Kanal mit "Intensity-Grading", einer ohne.
Viele Signale sind zwar periodisch, aber nicht immer vollkommen gleich. Das IG dient dazu, herauszufinden wie oft, also im sinne von Häufigkeit, welche Signalform vorkommt. Eigentlich sagt das nur, dass Signalformen oder Stellen an Signalformen um so heller werden, je häufiger sie vorkommen. Hier ist das ganz gut erklärt: http://www.hit.bme.hu/~papay/edu/DSOdisp/gradient.htm Ich kann mit dem kleinen Spartan FPGA leider derzeit nur wenige Signalformen überlagern, ich plane aber für später einen großen Artix7.
interessierter Mitleser schrieb: > Was ist denn der ureigenste Zweck des Intensitygradings? Man kann damit auch seltene Ereignisse sichtbar machen. Duke
Genau. Erklärung: Eer Monitor zeigt nur eine begrenzte Zahl an Bildern je Sekunde und Punkten (=Samples) je Bild an. Sagen wir das Signal wird mit 100MSamples/s abgetastet, es werden je Bild 1000 Punkte angezeigt und die Bildrate ist 100 Bilder/s. Dann sieht man 1000Punkte * 100Bilder/s = 100kPunkte/s. Von den 100MPunkten/s erreichen nur 100kPunkte/s den Bildschirm und können betrachtet werden, das ist 0,1% der Zeit, die restlichen 99,9% bleiben verborgen. Das will man natürlich nicht, also versucht man möglichst viele Samples in die Bilder zu packen. Wenn man die einfach nur reinzeichnet, dann sieht das nicht sonderlich gut und informativ aus, eine Art "Gewichtung" durch Farbe oder Helligkeit ist da deutlich besser. Es ist auch ein Unterschied zwischen Nachleuchten und Intensity-Grading. Beim Nachleuchten bleiben die Daten über mehrere Bilder hinweg zu sehen und "verblassen", bei IG ohne Nachleuchten werden in jedes Bild neue Daten gezeichnet, also die alten vom Bild vorher verschwinden und werden durch neue ersetzt. Man kann aber beides kombinieren. Will man bei z.B. 100MSamples/s und den anderen Voraussetzungen von oben alle Samples auf den Schirm bringen, dann werden das 100MSamples/(100Bilder/s * 1000Sampes/Bild) = 1000 Signalverläufe je Bild die überlagert werden. Man kann also IG mit 10Bits machen. Natürlich ist auch das nicht perfekt, denn auch hier verliert man Zeit, man kann nämlich nicht einfach die Signalverläufe überlagern, sondern will das auch möglichst deckungsgleich, also man muss den Trigger beachten. Das läuft dann so, dass man einen Signalverlauf aufnimmt, also ins Bild schreibt, dann wartet bis zum nächsten Trigger und dann den nächsten Signalverlauf schreibt. Die Zeit zwischen Bildende und nächstem Trigger ist dann verloren.
Duke Scarring schrieb: > interessierter Mitleser schrieb: >> Was ist denn der ureigenste Zweck des Intensitygradings? > Man kann damit auch seltene Ereignisse sichtbar machen. > > Duke Man kann die Information in Verrauschten Signalen besser sehen. Wichtig ist dabei eine unverrauschte Triggermöglichkeit.
Hallo, am DSO baue ich nicht weiter weil ich a) wenig Zeit habe b) für das was ich will (Intensitygrading) eine dickeres FPGA bräuchte c) ich für einiges eine (Messungen) CPU im FPGA bräuchte, aber nicht will weil ich kaum C kann. Ja, also ich verwende Bestandteile für verschiedene Messungen, hier bekomme ich schnelle Spannungsimpulse, sample diese und dann baue ich ein Sektrum aus den Impulsflächen.
Gustl Buheitel schrieb: > b) für das was ich will (Intensitygrading) eine dickeres FPGA bräuchte > c) ich für einiges eine (Messungen) CPU im FPGA bräuchte, aber nicht Ich weiß nicht, ob beim RedPitaya (http://redpitaya.com/) die Rechenleistung für Grading reicht. Aber eine CPU ist da im FPGA schon mit drin. Das Ding wäre für mich die geeignete Platform, wenn ich mich dem Thema Selbstbau-DSO nähern wöllte. Duke
Hallo, ja und nein. Ich möchte Grading in Hardware machen wenn überhaupt, also wirklich die komplette Zeit abtasten. Das wäre quasi: Warten auf Trigger Abtasten bis Speicher voll Warten auf Trigger ... So würde man eine extrem hohe Wiederholrate schaffen und brauht aber auch schnelles RAM, BRAM. Wenn ich 8Bit Sampletiefe verwende würde ich quasi ein Bild mit 256 Zeilen haben. Für jede Zeile ein eigenes BRAM. Das wird in jedem Takt gelesen und wenn von einem Sample "getroffen" im Wert erhöht, wenn nicht "getroffen" dann im Wert verringert. Die CPU bräuchte ich für Dinge wie Bedieninterface, das will man nicht in VHDL machen. Das RedPitaya ist hübsch, aber hat nur Transformatoreingänge, es kann also nicht wie ein normales Oszi auch sehr langsame Signale erfassen.
Interessante Unterhaltung hier. Ich zerbreche mir für das Welec-Projekt auch gerade den Kopf, wie wir sowas wie Intensity Grading hinbekommen. Zuerst dachte ich an einen Nachleuteffekt für Persistenz. Meine Überlegungen dazu siehe hier: Beitrag "Re: made from scratch Firmware für Wittig/Welec Oszilloskop W20xxA" (Beim Welec haben wir noch das spezielle Problem, daß das LCD mit zuwenig Bits angeschlossen ist, das soll die dort vorgestellte Platine umgehen.) Die zweite Anwendung für Grau-/Farbstufen ist die Verdichtung vieler Meßwerte zu einer Pixelspalte, bei Überabtastung. Andi hat eine nette Zusammenstellung gefunden, wie die verschiedenen Hersteller das machen: http://www.hit.bme.hu/~papay/edu/DSOdisp/gradient.htm Von daher interessiert mich schon mit etwas mehr Detailgrad, wie der Gustl das getrickst hat. Auch beim Welec haben wir nix zu verschenken, Blockrams im FPGA sind zugunsten der Speichertiefe quasi alle, muß irgendwie mit dem externen SRAM und CPU-Unterstützung gehen. Jörg
Hallo, diese Übersicht hatte ich weiter oben schon verlinkt. Ist durchaus interessant auf wie unterschiedliche Weise sich das machen lässt. Und es gibt noch eine Möglichkeit die sehr einfach ist aber auch nicht soooo gut. Die Intensität bei einem Analogoszi ist ja dort Höhe wo der Strahl in der gleichen Zeit die kürzere Strecke zurücklegt. Jetzt haben wir beim DSO einzelne Samples. Diese Samples verbinde ich mit einer Linie. Im einfachsten Fall mit je einem Sample je Pixel in X-Achsenrichtung ist die Linie zum Verbinden von zwei Samples nur ein vertikaler Strich. Die Länge ist also die Differenz der Samplewerte. Und weil die Zeit zwischen zwei Samples immer gleich ist, ist das auch proportional zur Geschwindigkeit. Hat man also 8Bit Samplewerte könnte man sowas machen: Farbe = 256 - |(Wert(Sample0) - Wert(Sample1))| Das ist vermutlich wirklich nicht sehr hybsch, habe ich auch noch nicht in VHDL gemacht, aber ich könnte mir vorstellen, dass es "besser als Nichts" ist.
:
Bearbeitet durch User
Jörg H. schrieb: > Auch beim Welec haben wir nix zu verschenken, > Blockrams im FPGA sind zugunsten der Speichertiefe quasi alle Hat denn diese Hardware ein externes SRAM? Bei einem VGA mit 640x480 müsste das mit der Pixelbandbreite noch hinhausen, oder?
Oh, der Tread lebt noch etwas. :-) Das FPGA im Welec hat 2 MByte externes SRAM angeschlossen, 32 Bit breit, die ich mit max. 100 MHz ansprechen kann. Das ist von der Bandbreite her schon nicht schlecht. Der LCD-Speicher liegt da drin, mein selbstgebauter LCD-Controller holt sich per DMA die Daten. Den Speicher muß er sich mit dem einsynthetisierten NIOS Prozessor teilen. Der Speicher ist von der Größe aber knapp. Mit double buffering wird es schon eng.
Ja er zuckt noch. Ich würde gerne wie geschrieben Intensitygrading in verschiedenen Arten probieren. Dafür bräuchte ich aber ein FPGA mit vielen BRAMS und das kostet mir derzeit zu viel. Ein richtiges DSO werde ich nicht machen weil ich das mit einer CPU und C nicht will und ohne soetwas GUI und Messungen keinen Spaß machen. Vielleicht hole ich mir mal einen dicken Artix, ein Board mit dem 200er, gutem VGA (viele Bits) oder HDMI und einem ADC wäre was.
Gustl B. schrieb: > Ich würde gerne wie geschrieben Intensitygrading in verschiedenen Arten > probieren. Dafür bräuchte ich aber ein FPGA mit vielen BRAMS und das > kostet mir derzeit zu viel. Das müsste sich aber doch mit einem billigen SRAM leisten lassen, oder?
Das was ich will leider nicht. Wenn der ADC 8 Bits hat und ich auch die alle verwenden will brauche ich 256 BRAMs. Wenn da ein 8 Bit wert daherkommt, z. B. y und das nach dem Triggerereignis das x-te Sample ist, dann wird im y-ten Bram an Position x 1 addiert und in allen anderen BRAMs ausser dem y-ten an Position x 1 subtrahiert. Das hätte dann den Effekt dass häufigere Signalformen heller sind. Man könnte da noch anderes Zeug machen wie dass man zwar 1 subtrahiert wenn der BRAM nicht getroffen wird, im getroffenen (y-ten) aber gleich den Wert an Position x auf 255 setzt (bei 8 Bit Helligkeit). Das hätte dann eher den Effekt dass neuere Signalformen heller sind, also eher etwas zeitliches. Man könnte sich auch anderes überlegen vor allem für Fälle in denen man nichtmehr Samples direkt ins Bild baut sondern wo die Zetbasis länger ist dann man viele Samples zu einem zusammenstauchen muss. Da könnte man also ein Zählerarray machen, wie die 256 BRAMs, jedoch keine BRAMs sondern 256x8Bit. Wenn da das Sample mit Wert y ankommt wird der y-te Zähler von den 256 erhöht. Will man also sagen wir 32 Samples in später eine vertikale Linie stauchen macht man das 32 mal mit den 256 Zählern, teilt dann alle Werte durch 32 und schreibt das in die 256 BRAMs vom Bild. Da kann man dann leider später nichtmehr hineinzoomen weil die einzelnen Samples fehlen. Will man Zoomen und keine Aliaseffekte, dann wüsste man z. B. von den 32 Samples das mit dem höchsten und das mit dem niedrigsten Wert speichern. Also nicht Durchschnitt über alle 32 bilden oder so etwas. Die beiden Werte kann man dann mit einer Linie verbinden deren Intensität ihrer Länge entspricht (wobei das eigentlich nur bei zwei aufeinanderfolgenden Samples korrekt wäre). Jedenfalls kann man durch speichern von Max und Min etwas Intensitygrading machen und ist Aliaseffekte los. Keine Ahnung ob das alles so stimmt aber einen Versunch wäre es wert irgendwann ...
:
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.