Forum: Mikrocontroller und Digitale Elektronik made from scratch Firmware für Wittig/Welec Oszilloskop W20xxA


von Sigi (Gast)


Lesenswert?

>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.

von Jörg H. (idc-dragon)


Lesenswert?

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

von Michael D. (mike0815)


Lesenswert?

> 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

von Michael D. (mike0815)


Lesenswert?

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

von Jörg H. (idc-dragon)


Lesenswert?

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

von Jörg H. (idc-dragon)


Lesenswert?

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

von Michael D. (mike0815)


Lesenswert?

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...

von wirehead (Gast)


Lesenswert?

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

von Klaus D. (Gast)


Lesenswert?

W2012: 30 Min. und keine Fehler.

Dank an wirehead für den Tip mit dem C++.

Gruss Klaus

von wirehead (Gast)


Lesenswert?

Hi,
so die Kiste ist jetzt 3h ohne Fehler gelaufen, sieht also gut aus für 
das Speicherinterface.

Gruß

von Jörg H. (idc-dragon)


Lesenswert?

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

von Markus F. (Gast)


Lesenswert?

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?

von Jörg H. (idc-dragon)


Lesenswert?

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

von Markus F. (Gast)


Lesenswert?

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.

von Jörg H. (idc-dragon)


Lesenswert?

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

von alex008 (Gast)


Lesenswert?

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

von Jörg H. (idc-dragon)


Lesenswert?

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

von Jörg H. (idc-dragon)


Lesenswert?

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

von Welecfan (Gast)


Lesenswert?

Wenn man Schrott poliert, dann sieht er zwar besser aus, bleibt aber 
trotzdem immer noch Schrott.

von Michael D. (mike0815)


Lesenswert?

nö! Aufgewertet, würde ich sagen!

von Blue F. (blueflash)


Lesenswert?

Aus Schrott kann man schöne Sachen machen...

In diesem Sinne eine frohes neues Jahr

Hayo

von Michael (Gast)


Lesenswert?

Hmm, ist das Projekt noch aktiv?

Sah so vielversprechend aus. Wäre ja schade, wenn das auf Eis liegt...

von Jörg H. (idc-dragon)


Lesenswert?

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

von Michael (Gast)


Lesenswert?

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!

von Michael D. (mike0815)


Lesenswert?

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

von Andiiiy (Gast)


Lesenswert?

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

von Michael (Gast)


Lesenswert?

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?

von Andy R. (andreas_r68)


Lesenswert?

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

von Johannes S. (demofreak)


Lesenswert?

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

von Jörg H. (idc-dragon)


Lesenswert?

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

von Michael (Gast)


Lesenswert?

Klasse Jörg!

Wenn es einen 1.0 Release gibt, helfe ich auf jeden Fall beim Wiki und 
beim Manual!

von Michael (Gast)


Lesenswert?

Ist das Projekt dann doch jetzt tot?

Sauschade...

von Jörg H. (idc-dragon)


Lesenswert?

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

von Michael (Gast)


Lesenswert?

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

von Michael D. (mike0815)


Angehängte Dateien:

Lesenswert?

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
von Blue F. (blueflash)


Lesenswert?

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

von Oliver P. (mace_de)


Lesenswert?

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.

von Blue F. (blueflash)


Lesenswert?

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.

von Oliver P. (mace_de)


Lesenswert?

Na ja, die Hoffnung stirbt ja bekanntlich zuletzt... :-D

von Blue F. (blueflash)


Lesenswert?

Genau ;-)

von Jörg H. (idc-dragon)


Angehängte Dateien:

Lesenswert?

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

von Egberto (Gast)


Lesenswert?

Hallo Jörg,

Sehr hübsch (auch die Abwärtskompatibilität) -wenn das läuft, nehme ich 
eine Platine!

Viele Grüße,

Egberto

von Oliver P. (mace_de)


Lesenswert?

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

von Blue F. (blueflash)


Lesenswert?

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

von Michael D. (mike0815)


Lesenswert?

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

von Blue F. (blueflash)


Lesenswert?

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

von Markus F. (Gast)


Lesenswert?

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?

von Blue F. (blueflash)


Lesenswert?

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

von Guido B. (guido-b)


Lesenswert?

Andererseits würde ein kleiner Flameware diesem Thread gut zu
Gesichte stehen. Dann schlägt endlich mal die Seitenaufteilung
zu. :-))

von Oliver P. (mace_de)


Lesenswert?

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% ;-)

von Markus F. (Gast)


Lesenswert?

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?

von Guido B. (guido-b)


Lesenswert?

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. :-(

von Jörg H. (idc-dragon)


Angehängte Dateien:

Lesenswert?

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
von Johannes S. (demofreak)


Lesenswert?

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

von Michael D. (mike0815)


Lesenswert?

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

von Jörg H. (idc-dragon)


Lesenswert?

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

von Oliver P. (mace_de)


Lesenswert?

Hi Jörg,

dann würd ich hier auch direkt mal Interesse anmelden.
(der Oliver aus dem alten Skype Chat)

Grüße Oliver

von Kruno (Gast)


Lesenswert?

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

von Michael D. (mike0815)


Lesenswert?

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.

von Blue F. (blueflash)


Lesenswert?

Mit einer kurzen Doku/Anleitung sollte das eigentlich kein Problem sein. 
Da sehe ich ja wieder eine neue Ausgabe meiner Dokureihe auf mich 
zukommen...

von Jörg H. (idc-dragon)


Lesenswert?

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

von Blue F. (blueflash)


Lesenswert?

Ok, dann mache ich erstmal mit anderen Dokumentationen weiter.
Die Basics sind ja auch nicht unwichtig.

-> Beitrag "Re: Wittig(welec) DSO W20xxA Einsteiger"

von Johannes S. (demofreak)


Lesenswert?

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

von Oliver P. (mace_de)


Lesenswert?

> ...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

von Jörg H. (idc-dragon)


Lesenswert?

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

von Jörg H. (idc-dragon)


Angehängte Dateien:

Lesenswert?

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

von Oliver P. (mace_de)


Lesenswert?

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.

von Blue F. (blueflash)


Lesenswert?

Sehr cool!

Mit der Technik könnte man nette Sachen für unser Oszi programmieren...

Gruß aus den Dolomiten

Hayo

von Johannes S. (demofreak)


Lesenswert?

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

von Jörg H. (idc-dragon)


Lesenswert?

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
von Blue F. (blueflash)


Lesenswert?

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

von Marc S. (marc_s86)


Lesenswert?

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

von Blue F. (blueflash)


Lesenswert?

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

von Marc_s86 (Gast)


Lesenswert?

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

von Blue F. (blueflash)


Lesenswert?

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

von Jörg H. (idc-dragon)


Lesenswert?

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

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
Noch kein Account? Hier anmelden.