Announcement: there is an English version of this forum on >MM quartus II 9.1 meint das das File corrupted ist...
Unter 13.0 läuft's ohne Probleme, bleibt also nur
13.0 runterzuladen un zu instalieren.
wirehead schrieb: > Hat jemand nen direcktlink zur Version 13.0.1? Zum Upload der .sof-Datei sollte der sog. "Quartus Programmer" ausreichen, das ganze Quartus braucht es dazu nicht. Hier der Link auf die aktuelle Version für Windows: http://download.altera.com/akdlm/software/acdsinst/13.0sp1/232/ib_installers/QuartusProgrammerSetup-13.0.1.232.exe Jörg
> MM quartus II 9.1 meint das das File corrupted ist... > Hat jemand nen direcktlink zur Version 13.0.1? bei mir dasselbe... Ich habe hier 2 Versionen vom Quartus Programmer: II 9.1sp2 und II 11.1 beide behaupten dasselbe! Jetzt muß noch eine 3. Version her oder kann Jörg das auch auf die früheren Versionen konvertieren? Gruß Michael
jetzt habe ich die über 100 MB runtergeladen und installiert, das wäre mit dem II 13.01 die 3. Version auf dem Rechner... Die SOF wird jetzt nicht mehr angepöpelt. > Nach dem .sof Reinladen ist das LCD schwarz, es kriegt merkwürdigerweise > den Reset nicht mit. Man kann F1+F2 gleichzeitig drücken um es zur Räson > zu bringen (manueller Reset). Dann sieht man auch schön das > Vollschreiben mit den Zufallsmustern. Mit F1+F2, meinst du wohl die beiden linken unteren Buttons?! Das Display ist nach laden der SOF Schwarz. Wenn ich beide Tasten drücke, habe ich schwarzen Schnee mit pinkfarbenen Hintergrund, soll das so sein? Gruß Michael
Ich kann es zumindest bestätigen, gerade ausprobiert: Quartus 12.1 kann die Datei verarbeiten, 11.0 nicht. Dazwischen muß irgendwas passiert sein. Wundert mich aber, sonst ist Altera sehr auf Kompatibilität bedacht. Ich habe noch keinen Weg gefunden, da was runter zu konvertieren. Auch ein draus erzeugtes .jic für das Config-Flash weist die Version 11 ab. Jörg
Unsere Postings haben sich überkreuzt, bzw. ich war zu langsam. ;-) Michael D. schrieb: > Mit F1+F2, meinst du wohl die beiden linken unteren Buttons?! Ja, die meine ich, nennen wir sie mal Softkeys 1+2. > Das Display ist nach laden der SOF Schwarz. > Wenn ich beide Tasten drücke, habe ich schwarzen Schnee mit pinkfarbenen > Hintergrund, soll das so sein? Ja, ist korrekt. Die violette Bitplane liegt (nach Wittig-Default) zuoberst. Jörg
Alles klar, dann stimmt ja alles soweit! Mein 2022, weißt bei dem Test schon mal keine Fehler auf, ist soweit i.O. Kann man über Quartus nicht das RAM sichern unter Attached Device? Habe da mal etwas experimentiert, aber irgendwie komme ich nicht ins RAM! Eine Sicherung "attached Device" funzt unter ver.9.1 und ist natürlich als jic 2MB groß. Beim wiederaufspielen startet das Scope aber nicht mehr ohne Neustart...
Hi, da ich jetzt 2h drann geknabbert habe die 13.0.1 unter XP-SP3 ans laufen zu bekommen, hier ein kleiner tip: Quartus Programmer braucht Microsoft Visual C++ 2008 SP1 Redistributable Package, das sagt er aber nicht sondern quitiert den Programmaufruf nach der Installation einfach mit "Anwendung konnte nicht richtig initialisiert werden" Danach gings bei mir. Seid 10min läuft auch der Ramtest bei meinem 2022
W2012: 30 Min. und keine Fehler. Dank an wirehead für den Tip mit dem C++. Gruss Klaus
Hi, so die Kiste ist jetzt 3h ohne Fehler gelaufen, sieht also gut aus für das Speicherinterface. Gruß
Danke an die Tester! Scheint soweit also bei allen zu laufen. Für die Testabdeckung sind meine Geräte also wohl auch schon ganz gut geeignet, mein primäres Bastelgerät scheint die ärgste Problemkiste zu sein. Schlecht für mich persönlich, aber gut für das Projekt. In der zurückliegenden Woche hatte ich dann das Gesamtsystem mit Qsys und 100 MHz zusammengebaut. Läuft nun, nach ein paar Anpassungen. Andi und Oliver habe mitgetestet, es läuft auf allen getesteten Geräten, nur meine Problemkiste will nicht recht. Selbst reduziert auf 94 MHz ist es knifflig. Das erdet mich momentan, ich hatte dieses WE keine rechte Lust, daran weiterzufrickeln. Es gibt irgendwie noch Unterschiede zwischen dem Speichertest und dem Gesamtsystem, obwohl ich die am externen Timing beteiligten Flipflops festgenagelt habe. Ich sollte mich weniger um diese Geschwindigkeitsoptimierungen kümmern... So allgemein ist das neue Timing mit Qsys aber eine tolle Sache. Vorher brauchte ich um 75 MHz zu schaffen alle erdenklichen Optimierungsschalter auf Maximum, die Kompilierzeit stieg auf etwa das Dreifache. Nun "gehen" 100 MHz ganz locker mit den Standardeinstellungen. Interessanterweise ist das zweite, quasi leere FPGA nun kritischer als das erste. Der kritische Pfad geht vom Capture-Speicher zu den Pins des Businterfaces, da kriege ich eine minimale Violation von z.B. 0,1ns. Es ist von Layout her anscheinend einfacher, vom Speicher zum internen Nios zu kommen (erstes FPGA), als zu den Pins (zweites FPGA). So long, Jörg
Jörg H. schrieb: > , die Kompilierzeit stieg auf etwa das > Dreifache. Nun "gehen" 100 MHz ganz locker mit den > Standardeinstellungen. Wie lässt sich das erkläen? Hängt das mit dem Beschreibungssystem von QSYS zusammen oder steckt da ein besserer Synthesealgo dahinter?
Ersteres, Altera hat mit Qsys eine neue Architektur für die Bus-Crossmatrix eingeführt, sie nennen es "network on chip". Orientiert sich wie der Name andeutet an Netzwerktopologie, soll insbesondere bei größeren Systemen mit vielen Busteilnehmern besser skalieren. Ich habe mir die Details noch nicht angeguckt, mit Google findet man so einige Aufsätze. Altera spricht vollmundig von doppelt so schnell, in der Realität bleiben bei uns ca. 20% Verbesserung. (Die 83 MHz schaffe ich wegen eigener Verbesserungen auch noch mit SOPC Builder.) Jörg
Ok, danke. Ich errinnere mich gerade an ein Altera Seminar wo einer der Vortragenden sehr eindringlih den enormen resourcen-Verbrauch der SOPC Systeme beleuchtet hat.
Beim Resourcenverbrauch sind mir keine nenneswerten Unterschiede aufgefallen. Unser FPGA ist etwa halb voll, vorher wie nachher. (Memory ausgenommen, davon könnten wir mehr gebrauchen.) Ich verfolge derzeit noch einen anderen Ansatz für den zwischen SRAM und FPGA-Interconnect gemeinsamen Bus. Statt die 2 verschiedenen Abtastzeitpunkte mit DDR-Inputs zu behandeln nehme ich nun die Delays der Padzellen. Das ist etwas feiner einstellbar und genauer zu kontrollieren, ich habe nun sogar mit meiner Kummerkiste eine Art Plateau von Werten, für die der Speichertest läuft, nicht nur eine einzige Einstellung. Im Gesamtsystem klappt es auf meinem besagten Problemgerät noch nicht so hundertprozentig, aber schon deutlich besser. Im Moment habe ich was präpariert und warte auf einen Absturz, aber nun rennt das Ding seit über einer Stunde unverdrossen... Davon abgesehen, andere Ideen: Ich erwäge, den Samplespeicher nicht mehr fest mit mit dem Capture-Teil zu verbinden, sondern beide über den internen Bus zu schicken. Der Anschluß dieser beiden Teilnehmer wäre mächtig breit (derzeit 256 Bit) und 125 MHz schnell. Wenn sie sich direkt unterhalten bleibt eigentlich alles beim alten, der restliche Bus ist davon unbeeindruckt, wir schaffen dann pro FPGA 2*1GSa/s weg. Man könnte aber bei langsameren Abtastraten den Capturer auch ins SRAM schreiben lassen. Die Zugriffe werden automatisch auf 8 Stück zu 32 Bit zerteilt, wir hätten deutlich mehr Samplespeicher. Dummerweise brauchen wir dann kostbare FPGA-Ramblöcke für FIFOs und so. Bei 4 Kanälen wird es ganz unangenehm, dann müßte man auch vom 2. FPGA aus als Busmaster auf das SRAM zugreifen können. Auch darüber habe ich nachgedacht, erfordert einige Koordination, u.A. weil nur FPGA1 die Adresse und Steuerleitungen anlegen kann. Da wird es mit den Signalleitungen zwischen den FPGAs verdammt knapp, von der Komplexität noch zu schweigen... So long, Jörg
Hallo Jörg! Wie ich gerade lese, bist du immer noch interessiert, die Geschwindigkeit hardwaremäßig zu optimieren. Bei deinen Überlegungen, bei "langsamen" Abtastraten direkt die Daten ins SRAM zu schreiben, möchte ich darauf hinweisen, dass man während die CaptureUnit in den Samplespeicher schreibt, dieser gelesen werden kann und sogar die Stoppadresse on the fly von der CPU Seite aus ändern kann (Roll-Mode). Solange der SRAM nicht voll ist, und die CPU oder DMA schneller die Daten auslesen können, als die CaptureUnit die Daten aufzeichnet, geht das jetzt schon. Die Daten könnten auch direkt vom 2ten FPGA per DMA vom ersten FPGA gelesen werden, wenn man die Schnittstelle zwischen den FPGAs komfortabel in den Adress-Datenbus einbindet. MFG Alexander
Hallo Alex, das ist mir bewußt, aber danke für die Erinnerung. Das 2. FPGA ist bereits "komfortabel" im Adreßraum erreichbar. Jörg
Ein Posting zum Ende des Sommerlochs, einige fragten schon: Ich bin seid ein paar Tagen aus dem Sommerurlaub zurück. Vorher ist auch nicht viel passiert. Das Welec hatte mit Instabilitäten frustriert, deren Quelle mir noch nicht klar ist. Daher ein gewisser Motivationsmangel. Und es war Sommer... Zuletzt habe ich recht erfolglos den externen Interrupt-Controller ausprobiert, Altera drängelt immer mehr den zu verwenden statt des Nios-internen. Der interne wird neuerdings gemobbt, eine nützliche Custom Instruction um die Nummer des höchsten Interrupt zu bestimmen ist entfallen. In der Tat werden Interruptroutinen mit den externen Controller deutlich schneller, statt vorher gut hundert Takte mit der Ursachenbestimmung und Registerrettung zu vebummeln wird der Code quasi direkt ausgeführt, die alternativen Registerbänke genutzt. Der Spaß kostet aber einen RAM-Block im FPGA. Bei uns sind die Interrupts derzeit weder häufig noch geschwindigkeitskritisch. Der Einbau war blöd, statt das nur zu ersetzen mußte ich das QSys-System von Grund auf neu zusammenklicken, vorher gab es obskure Fehlermeldungen, da war irgendwie der Wurm drin. "Lohn" der Mühe: die Software läuft nicht mehr, obwohl Interrupts schon kommen, das ist nicht grundsätzlich kaputtgegangen. Jetzt nach dem Urlaub bin ich erstmal ziemlich raus. Ich weiß noch nicht, wann ich damit wieder anfange. Wird weitergehen, aber derzeit prokrastiniere ich noch. Jörg
Wenn man Schrott poliert, dann sieht er zwar besser aus, bleibt aber trotzdem immer noch Schrott.
nö! Aufgewertet, würde ich sagen!
Aus Schrott kann man schöne Sachen machen... In diesem Sinne eine frohes neues Jahr Hayo
Hmm, ist das Projekt noch aktiv? Sah so vielversprechend aus. Wäre ja schade, wenn das auf Eis liegt...
Michael schrieb: > Hmm, ist das Projekt noch aktiv? > > Sah so vielversprechend aus. Wäre ja schade, wenn das auf Eis liegt... Es wird weitergehen. Ich hatte erstmal ein anderes Altprojekt in wieder in die Hand genommen, z.Zt. bastele ich etwas mit dem Raspberry Pi rum und habe es allgemein ruhiger angehen lassen. Bisher hatte das Projekt auch noch niemand vermißt... Das Welec hat mich wie gesagt mit Instabilitäten genervt. Laut Synthese alles gut, einzeln funktionierte auch alles, in Summe nicht. Das kann alles mögliche sein, vielleicht haben die FPGAs auch zuwenig Abblockkondensatoren und ich ziehe mit zuviel Gezappel die Versorgung punktuell in die Knie. Ich muß wohl etwas runterschalten, bisher habe ich mich sehr bemüht alles voll auszureizen und keine Kompromisse zu machen. Später mehr, Jörg
Jörg H. schrieb: > Bisher hatte das Projekt > auch noch niemand vermißt... > Kann ich mir kaum vorstellen. Ich halte das Projekt (wie sicherlich auch die meisten anderen) für das vielversprechenste überhaupt. Ich bin nicht sonderlich aktiv hier, aber schaue doch jeden Monat einmal rein, um zu sehen, ob es Fortschritte gibt. > Das Welec hat mich wie gesagt mit Instabilitäten genervt. Laut Synthese > alles gut, einzeln funktionierte auch alles, in Summe nicht. Das kann > alles mögliche sein, vielleicht haben die FPGAs auch zuwenig > Abblockkondensatoren und ich ziehe mit zuviel Gezappel die Versorgung > punktuell in die Knie. > Ich muß wohl etwas runterschalten, bisher habe ich mich sehr bemüht > alles voll auszureizen und keine Kompromisse zu machen. > Tja, vielleicht tatsächlich eine 80/20 Regel hier: 80% erreichen mit 20% des Aufwandes :-) Wäre auf jeden Fall immer noch absolut geil, da selbst 80% immer noch 100x besser als Originalfirmware :-D > Später mehr, > Jörg Super!
Hallo Jörg, > vielleicht haben die FPGAs auch zuwenig > Abblockkondensatoren und ich ziehe mit zuviel Gezappel die Versorgung > punktuell in die Knie. Vielleicht sollte sich Jemand mal das Datenblatt diesbezüglich vornehmen, ob genug von den Kondensatoren vorhanden sind und wo diese platziert werden sollten/müssen. Evtl. gibt es ja auch Layout Vorschriften in einer Appnote, so das die optimale Leistung erzielt werden kann, ohne das da was auf der Strecke bleibt. Gruß Michael
Ja, ich kann dem Michael nur Recht geben ... vor allem weil ich ja nun selbst auch die deutlichsten Unterschiede mit erleben dürfte (evtl. auch einen kleinen Beitrag leistete). Bitte mach weiter!!! Und das mit dem Thema Schrott sehe ich anders! Im technischen Umfeld wird schnell mit Kanonen auf Spatzen geschossen. Man(n) baut Controller ein, wo evtl. gar keine notwendig wären. ;-) Ich denke die verbauten FPGA's zeigen auch bei Deinen Test's was da so rauszuholen ist ... Grüße Andiiiy
Jörg H. schrieb: > Später mehr, > Jörg Schon ne Idee, wann Du uns was neues sagen kannst, ob und wie Du weitermachen möchtest?
Jörg H. schrieb: > Bisher hatte das Projekt > auch noch niemand vermißt... Nur weil keiner drängelt bedeutet das nicht, dass keiner wartet. Der USB-Blaster liegt bereit. Gruß Andy
Andy R. schrieb: > Nur weil keiner drängelt bedeutet das nicht, dass keiner wartet. http://www.youtube.com/watch?feature=player_detailpage&v=AL9Y_57fj4k#t=72 SCNR /Hannes
Hallo liebe Wartenden, Das Patentrezept Nummer 1 um mich wieder dranzukriegen wäre: mitmachen! Ich kann alleine keine Entwicklercommunity ersetzen. Und niemand kann sich rausreden er könne nichts beitragen, es gibt auch abseits von C und Verilog genug zu tun, nur ein paar Beispiele die mir gerade einfallen: - Ich bin zu betriebsblind um eine anfängertaugliche Anleitung zu erstellen - Die sinnvollen Modifikationen könnten im Wiki besser dargestellt werden, mit Übersichtsseite, derzeit ist viel in Forumspostings verstreut - Um die GUI könnte man sich fundiertere Gedanken machen - Unsere Zeichensätze sehen verbesserungswürdig aus - Wer sich mit "echten" Oszilloskopen auskennt könnte Anregungen geben, was wir mit den gegebene Mitteln ggf. noch umsetzen könnten - Für PC-Programmierer gäbe es auch zu tun, eine Fernsteuer- und Meßwertapplikation - Jemand der sich mit digitalen Filtern auskennt könnte die Filter von Alex optimieren Es ist ferner nicht so, das nix passiert. Hier ein paar Updates. Wegen anderer Projekte habe ich zuwenig Platz auf dem Tisch für meinen "losen" Welec-Aufbau mit der rausverlängerten Hauptplatine. Daher hatte ich das weggeräumt. Nun ist es aber im Prinzip wieder einsatzbereit. Letztes Wochenende habe ich das Welec seit Jahren erstmal wieder zusammengebaut, den JTAG durch einen Lüftungsschlitz in der Griffmulde unauffällig rausverlängert. Muß ich mal ein Foto von machen, zum Thema Mod-Doku. Ich habe auch noch mehr dran gebastelt, dazu später im Hardware-Thread. Mit Alex hatte ich Kontakt und über seine Filter gesprochen. Dazu gibt es demnächst einen Bugfix, sie konnten intern übersteuern und dann gibt es einen Wraparound-Effekt. Ich habe eine Idee für einen stufenweisen Shifter mit Saturation, um gefilterte Signale anzuheben, den Amplitudenverlust des Filters auszugleichen und mehr Auflösung zu kriegen. Alex hat die Filter seinerzeit auf Frequenzgang optimiert, daher haben wir gewisse Überschwinger. Ich finde, sie gehören für Oszilloskopanwendung stattdessen auf den Zeitbereich optimiert. Ich habe in der Zwischenzeit immer wieder nebenbei über die Architektur nachgedacht. Ich werde Osoz für die alte Hardware wohl sterben lassen, nur noch das neue FPGA supporten. Es sieht nicht so aus, als ob z.B. Hayo sich dem noch annimmt und die kleinen fehlenden Lücken bei Capture und Trigger schließt. Schade, da steckt auch viel Arbeit drin. Bisher ist die neue Hardware der alten recht ähnlich, nur viel schneller und zuende gedacht. Wenn wir ein paar alte Zöpfe abschneiden gibt es jedoch auch neue Möglichkeiten. Ein kleiner erster Schritt wäre das Page-Flipping statt Umkopieren für die Anzeige. Für die Grafik könnte ich mir allgemein noch andere Dinge vorstellen, wenn denn das RAM nicht so knapp wäre... Den Code sollte man bis auf eilige Ausnahmen grundsätzlich aus dem Flash ausführen (geht aber auch mit der alten Hardware). Allgemein zum Stand der Dinge: Viel fehlt ja eigentlich nicht für eine FPGA-Version 1.0, außer Stabilität, wenn ich recht erinnere. Der externe Trigger ist noch nicht samplegenau. Ich wollte da auch gerne eine Logicanalyzer-Funktionalität reinbauen, einen Kanal gibt der Triggereingang, 8 weitere sind am 2. FPGA bei den 4Kanälern verfügbar. Für die erste Version sollte ich mir das vielleicht noch verkneifen. Unsere Firma ist jetzt Altera-Partner. Wir haben nun Zugang zu den stets aktuellsten Tools, das Thema Nios-Lizenz sollte somit vom Tisch sein. Beruflich hatte ich auch gerade viel mit System Verilog zu tun, wenn auch nur für Verifikation. Aber Testbench und Simulieren sollte ich nun können, das habe ich beim Welec noch nicht gemacht, immer am echten FPGA probiert und gemessen. So long, Jörg
Klasse Jörg! Wenn es einen 1.0 Release gibt, helfe ich auf jeden Fall beim Wiki und beim Manual!
Ist das Projekt dann doch jetzt tot? Sauschade...
Hallo Michael, It's not dead, it just smells funny... Im Ernst, ich habe seitdem viele andere Dinge gebastelt, die (finde ich) auch sein mußten. Eine ergonomische Eieruhr mit MSP430, ein nicht so erfolgreicher DAB+ Empfänger, meine kleine RaspberryPi Soundkarte erfreut sich einer gewissen Beliebtheit, mein Wohnzimmer-DAC hat Fortschritte gemacht, im Moment rüste ich einen Oppo 103 zur digitalen AV-Vorstufe hoch, usw., falls die Schlagworte jemandem was sagen. Manchmal habe ich dabei ein "anständiges" Oszilloskop vermißt... Irgenwann geht es hoffentlich weiter, spätestens wenn wer mitmacht. Mit meinen obigen Gedanken vom 15.2. kann ich mich immer noch gut identifizieren. Grüße, Jörg
Hallo Jörg Ich kann Dich gut verstehen. Es gibt so viele spannende Projekte. Ich glaube, ich könnte Dir noch ein paar nennen :-) Trotzdem wäre es ja schaden, wenn dieses Projekt, was ja schon soooo weit gekommen ist, jetzt versandet. Ich hoffe daher, dass Du wieder den Spass und die Zeit findest, dies zumindest zu einer ersten Release-Version weiter zu entwickeln. Viele Grüsse Michael
Angehängte Dateien:
-
USB-Blaster.jpg
29 KB
Hallo Jörg und der Rest... Hier ein USB-Blaster Programmer für den Altera Chip. Der Blaster kostet beim Chinamann gerade mal 4,55€ inkl. Versand(4,72 wegen dem momentanen Wechselkurs) (Ich habe den günstigsten rausgesucht) Habe das Teil gerade geordert. http://www.ebay.de/itm/1Pcs-New-altera-Mini-USB-Blaster-Cable-For-CPLD-FPGA-Download-Line-Programmer-v-/321527128545?pt=LH_DefaultDomain_3&hash=item4adc82a1e1 Der Treiber dafür, ist hier erhältlich: www.altera.com/support/software/drivers Ich setze mal die Links plus die PDF hier rein. Gruß Michael
:
Bearbeitet durch User
Ja den habe ich auch. Hat aber 9.99€ gekostet. Ist so billig hergestellt, dass man noch das Papier über den Leuchtdioden selbst durchstechen muss, funktioniert aber mit dem Standardtreiber von Altera ganz prima. Ich hab das Ding an meinem W2014A (respektive W2024A / OPA656) fest angebaut und zwischen den Gehäusehälften rausgeführt. An der Durchführung habe ich das Flachbandkabel mit Tesa umwickelt, damit das Kabel nicht so gequetscht wird. Gruß aus Sami (Kefalonia) während meines Sundownings :-) Hayo
Nur blöd dass es keinen entgültigen Release gibt den man damit einspielen könnte. Das neue NIOS2 Design ist ja leider kurz vor der fertigstellung eingeschlafen. Die Leute mit genug Ahnung von FPGA Design haben so ein Teil eh schon und alle anderen brauchen es aus oben genanntem Grund eigentlich nicht. Zumindest nicht für das DSO. Ich selber habe auch so ein ähnliches China Teil. Es funktioniert prima. Egal ob mit den alten 5V FLEX Bausteinen, mit den MAX CPLD's oder mit den modernen Cyclons. Für den günstigen Einstieg in die FPGA-Welt auf jeden Fall empfehlenswert.
Oliver P. schrieb: > Das neue NIOS2 Design ist ja leider kurz vor der > fertigstellung eingeschlafen. Nur pausiert! Dass so ein Projekt zwischendurch mal etwas in der Intensität abnimmt, ist doch normal. Da wird es sicherlich noch wieder Neues geben.
Na ja, die Hoffnung stirbt ja bekanntlich zuletzt... :-D
Hallo, ich sollte mich wohl mal wieder melden... Hier hatte ich es bereits angekündigt, falls es jemand bemerkt hat: Beitrag "Re: Wittig(welec) DSO W20xxA Hardware (Teil 2)" Der Andi bearbeitet mich außerhalb der Öffentlichkeit, mein FPGA-Design doch mal langsamer zu drehen, damit es hoffentlich stabiler läuft und released werden kann, ist ja immer noch ein vielfaches schneller. Ich glaube aber da besteht noch ein anderes Problem, was untersucht gehört. Es passieren aber noch andere Dinge: Wenn Osoz die alte Hardware nicht unterstützt kann die neue prinzipiell anders werden. Ich habe viel über die Darstellungsmöglichkeiten nachgedacht, ob man irgendwie in Richtung DPO oder Intensity Grading kommt. Dazu hardwareunterstütztes Zeichnen. Babei gibt es mindestens 2 Engstellen: 1. Der (SRAM)Speicher ist verdammt knapp. 2. Eine Art Decay erfordert kontinuierlichen read-modify-write des gesamten Displays. Nun folgende Ideen: 1. Wenn man pro Kanal eine Byteplane in Größe von nur dem Raster (600*400) einrichtet, dann sind das 240 kBytes. Mal 4 geht gerade noch, Doppelpufferung in sichtbar/Hintergrund entfällt, komme ich noch zu. 2. Der Decay ginge über eine Art Palettenanimation, dann muß zum Abdunkeln erstmal nicht der Speicher verändert werden, nur die Interpretation wird umgewidmet. Allerdings müssen die Pixel, die jeweils ganz verdunkeln auf z.B. Wert 0 gesetzt werden, der außerhalb der Rotation steht und immer schwarz bedeutet. Sonst würden sie auf einmal ganz hell. Ein Decay-Durchgang muß also den ganzen Speicher lesen, und Fundstellen die den aktuellen Wert für minimale Helligkeit enthalten auf 0 schreiben. Das könnte der normale LCD-Scan im Nebenberuf erledigen. Der Speicher muß ja eh ca. 60 mal pro Sekunde gelesen werden. Für den Rest der GUI könnte ich mir eine vollformatig überlagerte 4-Bit Grafik vorstellen, die kostet dann nochmal 150 KiByte. Summa summarum ist dann bei einem 4-Kanäler gut die Hälfte vom RAM für das Display verbraten. Zeichnen ginge ggf. recht edel. Unser digitales Phosphorbyte könnte quasi aufgeladen werden, um einen bestimmten Wert, von einer vorbeistreichenden Interpolation der Meßwerte. So ergibt sich ein recht analoges Bild und das Intensity Grading. Das ginge sogar mit Subpixel-Genauigkeit, wenn die virtuelle Ladung anteilig der Entfernung der benachbarten Pixel aufgeteilt wird. Sowas könnte man mal simulieren, fühlt sich jemand berufen? Bleibt noch das Problem wie wir die schönen Zwischentöne mit der besch...eidenen 9-Bit Anbindung denn darstellen. Die ist ab Werk so verunglückt, das pro Farbe mit den 3 Bit nicht 8 Abstufungen möglich sind, sondern praktisch nur 5. Da erscheint unser Phosphorbyte mit 256 Abstufungen doch sehr verschwendet? Ich habe mir eine kleine Zusatzplatine ausgedacht, die den Datenbus zum LCD von 9 auf 18 Bit aufweitet, die tatsächliche Breite des LCD. Das FPGA könnte ein DDR-Signal ausgeben, Daten auf beiden Taktflanken, sowas ist Standard. Das wird dann von einem kleinen CPLD auf der Platine empfangen und auf die doppelte Leitungszahl demultiplext. So können wir das LCD in voller Farbauflösung nutzen. Es hat dann 6 Bit pro Farbe, also 64 Helligkeitsstufen. Nicht ganz ein Byte, aber immerhin dichter dran. Den Rest kann man vielleicht noch durch Dithering verbessern, je nachdem wie träge das Display ist. Das CPLD-Design steht und ist diesmal sogar simuliert, das Platinenlayout auch fertig (siehe Anhang), geht hoffentlich bald beim Platinensammlerjakob in Produktion. Das CPLD ist ein EPM3032A von Altera, kostet als Einzelstück bei Mouser gut einen Euro. Es kann mit dem ByteBlaster programmiert werden, ich habe auf der Platine wieder so eine 10-polige Stiftleiste vorgesehen. Die fertige Platine kann man dann ohne Löten zwischen Hauptplatine und Displaystecker einfügen. Ein Befestigungsloch ist noch vorgesehen, wenn's paßt wie gedacht kann man eine Schraube vom LCD zweckentfremden. Eine Besonderheit noch: Ich habe eine Erkennung und Modusumschaltung drin. Wenn die Hauptplatine eine gerade Anzahl von Pixeln pro Zeile ausgibt, dann verhält sich das CPLD zwecks Abwärtskompatiblität "neutral" und macht kein DDR-Demuxing. (Es werden lediglich die 3 Bits pro Farbe schlauer aufgeteilt, so daß sich echte 8 Abstufungen ergeben.) So lassen sich die existierenden FPGA-Designs weiter benutzen, ohne die Platine auszubauen. Wenn eine um eins verminderte, also ungerade Anzahl von Pixeln pro Zeile ankommt, dann wird die im weitergereichten Signal wieder erhöht um das ungeschehen zu machen, und der DDR-Demux ist aktiv. So kann das FPGA die Funktion der Platine ein/und ausschalten, ohne das wir eine extra Leitung dafür brauchen. Das ganze Design benötigt 31 Flipflops (=Makrozellen), 32 sind verfügbar. Ist übrigens in Verilog programmiert, auch sowas kleines kann man damit machen. Alle Pins sind belegt, das geht genau auf. Man könnte sagen das CPLD paßt perfekt. Es hat ferner 3,3V I/O- und Betriebsspannung, zufällig auch das was wir zur Verfügung haben. Zur Sicherheit gesagt: Ich mache da jetzt noch keine Sammelbestellung draus, möchte erstmal selber testen ob das auch wirklich so geht. So long, Jörg
Hallo Jörg, Sehr hübsch (auch die Abwärtskompatibilität) -wenn das läuft, nehme ich eine Platine! Viele Grüße, Egberto
Hi Jörg, erst mal danke für das Update! Schön dass das Projekt doch nicht so tot ist wie es den Anschein hatte. Das sind ja tolle Ideen die du hast, vor allem die Sache mit dem Display Extender. Was ich mich frage, könnte man diese Extender Geschichte nicht noch weiter treiben und das komplette Display RAM auf so eine externe Platine auslagern und den jetzigen Displayport als einen high Speed Datenbus zweckentfremden? So hätte man massig RAM im FPGA frei. Grüße Oliver
Hi, bin gerade aus Oslo zurück und lese beim Verlassen der Fähre diese Beiträge. Coole Sache! Ich wäre selbstredend mit mindestens zwei Platinen dabei. Und ich sach noch - hier geht es wieder weiter! Kreative Pausen gehören halt dazu. Hayo
wirklich hoch interessant! Hier wird auch kein mords Aufriss mit der "Kabelage" veranstaltet und ist ja quasi plug&play. Hayo, wie sieht's denn aus? Könntest du das vorübergehen, bzw. parallel zu Osoz, in "deine" FW einbauen? Das war mir gerade so durch den Kopf geschossen... Gruß Michael
Hatte ich auch schon drüber nachgedacht, da man dadurch die Möglichkeiten der neuen Displaysteuerung testen und auch schon praktisch nutzen könnte. Leider geht das aber nur mit entsprechenden Änderungen im FPGA. So wie Jörg das Funktionsprinzip beschrieben hat, schaltet das Modul nur dann in den erweiterten Displaymode um, wenn das FPGA die entsprechenden Signale sendet. Rein firmwareseitig kann man das nicht aktivieren. Gruß Hayo
Welecfan schrieb: > Wenn man Schrott poliert, dann sieht er zwar besser aus, bleibt aber > trotzdem immer noch Schrott. Lese ich daraus, dass Du das Oszi als Schrott bezeichnest oder die SW?
Naja, so wie die Teile vom "Werk" kommen sind sie ja auch tatsächlich Schrott. Sie haben aber genügend Potential um sie ordentlich aufzubürsten. (und das ist es ja was wir daran so lieben...) So wie die Geräte jetzt bei mir stehen kann man sie wirklich benutzen, was man vorher nicht wirklich konnte. Was im Laufe der Zeit an den Geräten verbessert wurde kann man aber schon lange nicht mehr als polieren bezeichenen. Das geht schon weit darüber hinaus. Und es ist noch nicht das Ende der Fahnenstange... Hayo
Andererseits würde ein kleiner Flameware diesem Thread gut zu Gesichte stehen. Dann schlägt endlich mal die Seitenaufteilung zu. :-))
Die Teile sind nun mal Schrott. Im Auslieferungszustand ist Schrott: -Die Firmware -Das FPGA-Design -Die Eingangsstufe Nach Jahrelanger Arbeit der Entwickler hier konnten die Probleme der Firmware und die meisten Unzulänglichkeiten der Eingangsstufe gelöst werden. Was nach wie vor Schrott ist, ist das zugunde liegende FPGA Design. Der Schrott-Faktor liegt also noch bei um die 30% ;-)
Ich würde euch das glatt unterstützen, aber habe wenig Zeit. Momentan lassen sich FPGA-Kenntnisse sehr gut wirtschaftlich vermarkten und zu Geld machen. Ich gehe auch davon aus, dass es nicht damit getan ist, euch ein paar Tipps zu geben, sondern man müsste da was komplett Neues machen, nehme ich an?
M. F. schrieb: > Ich gehe auch davon aus, dass es nicht damit getan ist, > euch ein paar Tipps zu geben, sondern man müsste da was komplett Neues > machen, nehme ich an? Naja, Jörg hat einen Neuentwurf mit enormen Verbesserungen zum Laufen gebracht. Nur mit dem Timing ist er etwas unglücklich, weil es zwar sehr gut aber nicht optimal gut geht. Da können ihm wohl nur wenige helfen, soviel Knowhow können wir nicht aufweisen. :-(
Angehängte Dateien:
-
before.jpg
190 KB -
after_unplugged.jpg
250 KB -
after_plugged.jpg
230 KB -
stack.jpg
140 KB
Die LCD-Platine ist jetzt endlich da, flugs bestückt und programmiert. Anbei ein paar Bilder, wie dieser Mod dann aussehen könnte. Sehr komfortabel ohne Löten einzubauen, man braucht das Gehäuse nur hinten aufschrauben und den Deckel etwas lupfen, Platine zwischenstecken, wieder zuschrauben. Ich bin mir noch nicht sicher, ob ich die LCD-Schraube wie hier abgebildet zur Befestigung nutze (braucht ein Distanzstück von ca. 2,7mm Höhe und eine längere Schraube), oder die Platine um den Teil hinter dem Stecker kürze und allen Halt dem Stecker überlasse. Die Stecker rasten immerhin etwas. Die 10-polige Pfostenleiste ist zum Programmieren des CPLD per Blaster, analog zum FPGA. Muß man nicht unbedingt bestücken, später reicht es vielleicht, das über Pogo-Pins einmalig zu machen. Zum Status: Ich habe mein Logikdesign noch etwas umändern müssen, die Signale sind vielleicht aufgrund von Clock-Skew zur fallenden statt steigenden Flanke stabil. Damit kriege ich nun das gewohnte Bild, der abwärtskompatible Durchreich-Modus funktioniert schon mal. Nun müßte ich einen neuen LCD-Controller für das FPGA programmieren, das ist der aufwändigere Teil... Jörg
:
Bearbeitet durch User
Das sieht ziemlich professionell aus. :-) Wenn das alles in dem Topf ist, wo es kocht, hätte ich bitte auch gern so eine Platine. Muss mir dann nur noch einer kurz den Weg weisen, wie man das Ding nach dem Löten programmiert... /Hannes
ist ja abgefahren und sieht aus, wie aus dem Laden! Und total unauffällig, als würde es zum Board gehören. Ich schließe mich Johannes an. Wo stehen denn da so die Kosten, für das Adapter-Platinchen? Gruß Michael
Michael D. schrieb: > Wo stehen denn da so die Kosten, für das Adapter-Platinchen? Das ist nicht teuer, die Materialkosten liegen unter 10€. Wer's genau wissen will, hier ein Mouser-Warenkorb für die Bauteile (Achtung Nettopreise): http://www.mouser.com/ProjectManager/ProjectDetail.aspx?AccessID=57960b7bcf Von den Platinen habe ich 2 bestellt und 6 bekommen (auch die Überproduktion gekauft), kosteten dann im Mittel 2,20€ das Stück. Jörg
Hi Jörg, dann würd ich hier auch direkt mal Interesse anmelden. (der Oliver aus dem alten Skype Chat) Grüße Oliver
Hallo Ich bin natürlich auch daran interessiert. Habe aber, wie die meisten denke ich, das Problem den CPLD zu programmieren. Man wird einen ByteBlaster kaufen/bauen müssen, Software dafür und einen PC mit LPT suchen usw. Wäre fein wenn sich jemand fände der ein Paar CPLDs gegen Entgelt kauft, programmiert und versendet. Noch besser wenn die Prints und die Stecker dabei wären. Oder steht dem Wunsch Jörgs Erweiterungen nutzen zu wollen noch mehr im Weg? Gruß, Kruno
zum Programmieren des Logik-Bausteins, reicht doch der USB-Blaster über den JTAG Header, oder liege ich da falsch? Den USB-Blaster, der ja über den Quartus-Programmer angesprochen wird, gibt es für unter 5€ hier: Beitrag "Re: made from scratch Firmware für Wittig/Welec Oszilloskop W20xxA" Sollte also kein Problem darstellen, wenn Jörg das Kompilat zur Verfügung stellt. Gruß Michael EDIT:Das "Hünerfutter" und Pinheader hat ja wohl jeder da(zumindest ich), das einzige was dann anfallen würde wären die EPM3032ATC44 und die Platinen-Stecker/Buchsen als auch die Platine.
Mit einer kurzen Doku/Anleitung sollte das eigentlich kein Problem sein. Da sehe ich ja wieder eine neue Ausgabe meiner Dokureihe auf mich zukommen...
Ihr seid ja gedanklich schon recht weit... Wie sagt man so schön: Man soll das Fell des Bären nicht verteilen, bevor er erlegt ist. Das muß erstmal ausprobiert werden ob's überhaupt geht, und auch dann ist es noch weit, bis man mit der Platine was sinnvolles anfangen kann. USB Blaster Clone kaufen ist aber immer eine gute Idee, jeder Welec-User sollte einen haben, finde ich. Jörg
Ok, dann mache ich erstmal mit anderen Dokumentationen weiter. Die Basics sind ja auch nicht unwichtig. -> Beitrag "Re: Wittig(welec) DSO W20xxA Einsteiger"
Jörg H. schrieb: > USB Blaster Clone kaufen ist aber immer eine gute Idee, jeder Welec-User > sollte einen haben, finde ich. Wenn du das sagst, mache ich das doch glatt. Ich hab zwar noch keine Ahnung, was ich damit anstellen kann, aber ich hab erstmal draufgeklickt. Wenn das Ding dann irgendwann da ist, melde ich mich wieder. :-D /Hannes
> ...muß erstmal ausprobiert werden... Na dann währ's doch gar nicht so schlecht wenn's noch ein paar andere Leute eingebaut hätten. Andere Frage, gibt es eigentlich ein aktuelles Repository von der Nios2 Geschichte? Ich kenne nur das bei SVN aber da gab es, im Nios2 Zweig, seit über einem Jahr keine Veränderung mehr. Grüße Oliver
Oliver P. schrieb: >> ...muß erstmal ausprobiert werden... > Na dann währ's doch gar nicht so schlecht wenn's noch ein paar andere > Leute eingebaut hätten. Ausprobieren meinte ich nicht im Sinne von Feldtest, sondern ob das überhaupt geht und sinnvoll ist. Die Platine ist nur die Spitze des Eisbergs, da gehört noch die Implementation eines entsprechenden LCD-Controllers im FPGA dazu. Die gibt es noch nicht. > Andere Frage, gibt es eigentlich ein aktuelles Repository von der Nios2 > Geschichte? Ich kenne nur das bei SVN aber da gab es, im Nios2 Zweig, > seit über einem Jahr keine Veränderung mehr. Doch, das ist der aktuelle Stand, seitdem ist fast nichts passiert. Ich könnte allenfalls noch einen kleinen Bugfix und die Platine einchecken. Jörg
Angehängte Dateien:
-
original.jpg
200 KB -
hicolor.jpg
200 KB -
beide.jpg
450 KB
Ich habe für das FPGA im Welec ein Test-Design gemacht. Es enthält nichts außer einem rudimentären neuen LCD-Controller, der ein hart codiertes Testbild generiert. Sowas ist in 15 Sekunden synthetisiert, viel schnellere Ausprobier-Zyklen als mit Nios, Software, usw. Ergebnis: Meine Platine funktioniert im Prinzip, aber die Datenübernahme ist super-kritisch. (Ein Deja-Vu zum SRAM-Controller...) Ich habe da ziemlich viel rumprobiert, und die Dinge verhalten sich merkwürdig. Ich hoffe das kriege ich noch entschärft. Mir fehlt ein ordentliches Oszi, um da mal zu messen was Phase ist. An dem CPLD kann man leider kaum was einstellen, es hat keine programmierbaren Delays. Bei der nächsten Platinenversion würde ich ein RC-Glied am Takteingang vorsehen, dann kann man da noch was schieben. Zur Erbauung aber mal ein paar Bilder, wie's aussieht wenn's mal funktioniert. Ist gar nicht so einfach zu fotografieren, in Natura sieht's viel besser aus. Der Generator erzeugt Farbverläufe von dunkel nach hell, in den 8 RGB-Kombinationen (na gut, 7, ohne schwarz): blau, grün, cyan, rot, magenta, gelb, weiß. Mit dem normalen LCD-Anschluß werden da 8 Stufen draus, wegen unglücklichem Anschluß der unteren Bits fallen je 2 benachbarte fast gleich aus und es sind praktisch nur noch 5 Stufen. Mit meiner Platine werden es 64 Stufen. Teils kann man die auch noch sehen, besonders im dunkleren Bereich. Die Helligkeit steigt recht steil an, man könnte sagen das Display hat falsches Gamma. Da kann ich aber nichts dran machen. Jörg
Super Jörg! Danke für die Einblicke. Wieder ein Beispiel was Wittig an Potential verschenkt hat. Hoffentlich gibt's irgendwann mal wieder was zum selber spielen.
Sehr cool! Mit der Technik könnte man nette Sachen für unser Oszi programmieren... Gruß aus den Dolomiten Hayo
Johannes S. schrieb: > draufgeklickt. Wenn das Ding dann irgendwann da ist, melde ich mich > wieder. :-D Gestern hat die Post das Briefchen aus China in den Kasten gestopft. Ich hab jetzt also auch ein Gerät da liegen, welches sich am Rechner als Altera USB-Blaster mit Seriennummer 00000000 meldet. :) Jetzt muss ich nur noch das Flachbandkabel ins Gerät fummeln und dann kann's losgehen (was auch immer) :-D /Hannes
Jörg H. schrieb: > Ergebnis: Meine Platine funktioniert im Prinzip, aber die Datenübernahme > ist super-kritisch. (Ein Deja-Vu zum SRAM-Controller...) Ich habe da > ziemlich viel rumprobiert, und die Dinge verhalten sich merkwürdig. > > Ich hoffe das kriege ich noch entschärft. Mir fehlt ein ordentliches > Oszi, um da mal zu messen was Phase ist. An dem CPLD kann man leider > kaum was einstellen, es hat keine programmierbaren Delays. Bei der > nächsten Platinenversion würde ich ein RC-Glied am Takteingang vorsehen, > dann kann man da noch was schieben. Ich habe mir jetzt ein "ordentliches Oszi" gekauft (Tektronix 2467B, soll das beste Analog-Oszi sein wo gibt) und es erfolgreich zum Einsatz gebracht. Gegenüber meinem Hameg 604 war das wie Brille aufsetzen, hurra, ich kann sehen! Es gab verschiedene Probleme, die ich nun lösen konnte. Das Original-FPGA wechselt die LCD-Signale zur fallenden Flanke, genau genommen etwa 2 ns dahinter. So soll es laut Datenblatt LCD nicht sein, das möchte alles zur fallenden Flanke stabil haben, mit 5 ns Setup- und Hold-Zeit drumrum. Welec begeht da also eine hold time violation. Die originale LCD-Ausgabe funktioniert wohl eher mit Glück. (Es ist aber auch gar nichts richtig an diesem Design!) Meine Platine ist also gut beraten, die Signale zur steigenden Flanke abzutasten und die neu erzeugten auch wieder so auszugeben. Dann ist die Übername vom FPGA sicher und die Signale zum LCD sozusagen repariert. So mache ich das also nun, vorher hatte ich zur fallenden Flanke übernommen. Aktuell habe ich eine Platine mit einem schnelleren Speed Grade des CPLD aufgebaut, um da mehr Luft zu haben. Ist aber wohl doch nicht so dringend nötig, stellt sich raus. Dann waren da noch ein paar Bugs in meinem Test-LCD-Controller, die mich daran hinderten dort das Timing durchzukurbeln. Nun habe ich Einstellungen, mit denen die Datenübername stabil und unkritisch klappt. Kurzum, die Erweiterung funktioniert nun ordentlich. Mal sehen wie es damit weitergeht, ich habe im Moment nur leider wenig Zeit dafür. Jörg
:
Bearbeitet durch User
Glückwunsch zum Tek! Ist ja irgendwie der große Bruder von meinem 2465A.
Obwohl technisch eigentlich nicht mehr ganz aktuell können die Dinger
doch schon Einiges was die Neuen nicht können. Haben früher immerhin
lockere 20 Kilo DM gekostet. Das konnten sich nur Profis leisten.... und
jetzt haben wir sie zu Hause stehen :-)
Etliche Funktionen der DSOs haben sie zwar nicht, aber wenn es hart auf
hart kommt zeigen sie einem mehr als die neuen Dinger.
> (Es ist aber auch gar nichts richtig an diesem Design!)
Da wäre ja auch ein Ruf zu verlieren ;-) Anders hat es wohl auch keiner
erwartet...
Wenn ich das richtig verstanden habe ist Dein Display-Converter ja kurz
vor der "Serienreife".
Wie gesagt, ich wäre dabei.
Gruß Hayo
Hi, ich überlege ein Wittig DSO zu Kaufen, die frage ist: Lohnt das noch und leben die Open Source Projekte noch? Das Sourceforge-Wiki scheint es nicht mehr zu geben? Gruß, Marc
Hi, wenn Du es günstig kriegst und wenn Du Lust hast auch selber Hand anzulegen ist es immer noch eine ergiebige Plattform zum Lernen und Basteln die über umfangreiche Funktionen verfügt. Wenn Du nur hin und wieder was messen willst und keine Lust hast Dich näher mit dem Ding zu beschäftigen - nimm was aus China. Die Projekte sind momentan alle nicht mehr aktiv, aber ich supporte immer noch die BF-Firmware und alle meine Hardware-Mods. Wenn Du da was machen möchtest und Fragen hast oder Fehler entdeckst stehe ich jederzeit zur Verfügung. Das sehr vielversprechende FPGA-Projekt pausiert seit einiger Zeit. Ob sich da evtl. wieder was tut kann ich nicht sagen. Gruß Hayo
Danke für die schnelle Antwort! Also grundsätzlich hab ich ein Rigol DS1104z, das Wittig fände ich hauptsächlich spannend aufgrund von 4 Dingen: - 1GS/s pro Kanal, beim rigol sinkt die samplingrate mit jedem zusätzlichen Kanal - 200MHz analog Bandbreite - viel Bastel Spaß, insbesondere Akku Mod finde ich sehr praktisch! - Open Source finde ich gut ;) Was würdest du denn als günstig ansehen? Gruß, Marc
Hi Marc, wenn Du so ein Teil zwischen 100,- und 200,- schießen kannst liegt das im grünen Bereich. Da gab es schon etliche Schnäppchen in der Bucht. Auf die Bandbreite brauchst Du nicht zu achten, das kann man mit einer Modifikation auf den richtigen Weg bringen. Du solltest nur wissen ob Du ein 2-Kanal oder ein 4-Kanal Gerät haben möchtest Das schöne daran ist, dass man zum Einen lernen kann SMD zu löten, Einiges zum Thema Messtechnik und Oszis im Speziellen und irgendwie baut man im Laufe der Zeit mit jeder Modifikation eine Art persönlicher Beziehung zu diesem eigentlich im Urzustand ziemlich unperfekten Gerät auf. Ich kann mir eigentlich keinen effizienteren Weg vorstellen um sich mit dem Thema Messtechnik und seinen Tücken vertraut zu machen. Wie mein Prof immer zu sagen pflegte: Wer misst, misst Mist! Sehr wahr! Also wenn Du da gerne basteln möchtest und Tips und Hilfe brauchst bin ich jederzeit über eines der Foren erreichbar. Ich denke etliche der alten Hasen sind ebenfalls noch über Email-Benachrichtigung im Forum verlinkt. Gruß Hayo
Hallo, wie von Hayo vermutet lese ich noch mit, die Email-Benachrichtigung ist noch aktiv. Aktiver als ich... Zu den Fragen: - Das Wiki gibt es noch, aber read-only. Als Sourceforge (mal wieder) sein System erneuerte drohte alles im digitalen Orkus zu verschwinden. Man konnte immerhin ein Backup ziehen, eine neue Datenbank aufsetzen und das wieder lesbar kriegen, aber das neue System ist inkompatibel. Hier der Link: http://welecw2000a.sourceforge.net/cgi-bin/trac.cgi - Ob so ein Gerät zu empfehlen ist: Allgemein würde ich das ehrlich gesagt nicht mit gutem Gewissen tun, es sei denn es geht um spezielle Dinge. Das Design ist mittlerweile 10 Jahre alt, das ist im schnellebigen Markt der Digitaloszilloskope eine lange Zeit. Mittlerweile ist der Speicher arg klein, sowohl für Meßwerte wie Programm, die VGA-Grafik recht grob, und es fehlt eine schnelle Schnittstelle. Und mal allgemein, wo ich gerade dabei bin: Nach wie vor habe ich einige Ideen, was man aus der Kiste noch rauskitzeln könnte, mit dem neuen FPGA-Design. Ich habe viel nachgedacht, ob was in Richtung DPO oder wenigstens Intensity Grading zu schaffen ist, aber es scheitert immer wieder am Speicher (im FPGA und das SRAM), aber auch an den FPGA-Resourcen wenn man in Richtung hardwareunterstützte Darstellung denkt. Ein Display mit vielen Schattierungen, wie es meine Hardware-Erweiterung prinzipiell bietet, braucht auch viel Bildspeicher. Damit wäre schon ein großer Teil des SRAM belegt, wie auch viel Bandbreite um das 60 mal in der Sekunde zu lesen. Dann muß es auch beschrieben werden. Ungünstigerweise liest das LCD von oben nach unten, wärend man das Signal von links nach rechts schreiben wird. Das verhindert leider eine elegante und effiziente Architektur des Bildspeichers. Das hängt also zu hoch, Schritt zurück. Eine andere interessante Sache ist, MSO-Funktionalität mit unter zu bringen. Das 4Kanal-Gerät hat intern 8 Leitungen frei. Die sind auf einem Stiftleisten-Footprint zugänglich. Wir hätten gerade noch genug Luft, die mit aufzuzeichnen. Debugging im 2. FPGA ist aber eine Strafe, sprich unmöglich, weil es keinen JTAG-Anschluß hat. Das 2Kanal-Gerät könnte immerhin den Triggereingang mit aufzeichnen, gibt also einen Digitalkanal, damit kann man das "üben". Ich würde heutzutage den Capture-Speicher anders aufbauen: unabhängig von der Capture-Unit, stattdessen als normalen Teilnehmer an einem (breiten) Avalon-Bus. Damit die Capture-Unit schreiben kann braucht sie dann einen DMA. Hat den Vorteil, das bei langsamem Capture auch das SRAM als Ziel genommen werden kann, mit größerer Speichertiefe. Haarig wird es dann beim 4-Kanäler. Über die eigentlich zu wenigen Handschake-Leitungen müßte das zweite FPGA auch Busmaster sein können. Das wird eng, geht nur wenn man die Waitstate-Leitung wegläßt und irgendwie durch die Programmierung sicherstellt, nix zu überfahren. Momentan ist die Filter-Mimik aus Alex' Diplomarbeit eingebaut. Das braucht viel Resourcen, ob es in sich lohnt ist die Frage. Ich würde zugunsten von einer feature-reicheren Triggerung weitgehend darauf verzichten. Cool wäre sowas wie segmented memory, kommt aus den Zeiten von wenig Speicher. Protokollanalyse in Hardware ist auch ein Thema. Mir fehlt im Moment die Zeit, das weiter zu voerfolgen. In den nächsten Monaten wird das auch nicht besser. Zuletzt hatte ich mich noch in eine Ecke festdesignt. Irgendwas ist instabil, die Software rennt in eine Exception, keine Ahnung warum. Man müßte schrittweise alles wieder ausbauen. So long Jörg
Thread beobachten
Seitenaufteilung abschaltenBitte 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.