Hallo werte W20xxA Besitzer und Interessierte!
Diesen Thread habe ich als Ersatz für den mittlerweile überfüllten
Thread
Beitrag "Wittig(welec) DSO W20xxA Hardware"
eröffnet. Hier sollen Hardwarefragen erörtert werden wie z.B.
Bandbreitenprobleme, Schwingneigungungen der Eingangsverstärker etc.
Für die Open Source Firmwareentwicklung gibt es einen eigenen Thread:
Beitrag "Wittig(welec) DSO W20xxA Open Source Firmware"
So hier noch eine kleine Wortliste damit der Thread auch von Google
gefunden wird:
DSO Oszilloskop oscilloscope WELEC WITTIG W2000 W2012A W2014A W2022A
W2024A
Gruß, brunowe
Hallo,
wie angekündigt hab ich heute die Abstrahlung eines W2022A im
Frequenzbereich von 150kHz bis 1GHZ in einer Absorberkammer vermessen.
Gleich einmal vorweg... da ich beruflich mit solchen Messungen zu tun
habe, ist mir schon einiges an nicht normgerechten Geräten
untergekommen... Aber unser Welec hat selbst viele Geräte an
Störaussendungen überboten, die erst in einem frühen Entwicklungsstadium
sind.
SO WÜRDE ICH DAS W2022A NIEMALS FÜR DEN EUROPÄISCHEN MARKT ZULASSEN!!!
Mir ist wirklich schleierhaft, wie das Scope diese Messungen einst
bestanden haben soll!
Aufgrund der unterschiedlichen Einsatzbereiche meiner Antennen musste
ich die Messungen splitten. Der erste Bereich von 150kHz- 30MHz wurde
mit einer Stabantenne gemessen. Der Bereich von 30MHz bis 1Ghz mit einer
Antenne die ich üblicherweise für meine Messungen im Automotive Bereich
einsetze.
Von 150kHz bis 30MHz sind laut Norm EN 55011 keine Grenzwerte definiert.
Diese Messung gilt also rein informativen Zwecken. Auch ist der
Absolutpegel dieser Messung nicht ganz realistisch (dieser liegt in
Wahrheit 10dB höher).
Begründung: Niedrige Frequenzen werden bevorzugt von Leitungen, nicht
vom Gerät abgestrahlt. Unsere Messleitungen (Tastköpfe) entsprechen
nicht der normativen Länge für diese Messungen.
Die gemessene Differenz des Absolutpegels lässt sich somit u.a. durch
den höheren Abstand des "Strahlers" Oszilloskop von der Antenne im
Vergleich zu der Messung bei 30MHz bis 1GHz erklären.
Im Anhang erst mal ein paar Fotos vom Messaufbau zur Einstimmung.
Hallo,
jetzt gehts ins Eingemachte...
Angefangen hab ich mit ein paar Vergleichsmessungen, um die Auswirkungen
des Abschlusses der BNC Buchsen (Messeingänge)zu untersuchen.
Fazit: Egal, ob die BNC Buchsen mit 50Ohm, ob sie offen oder mit unseren
Tastköpfen abgeschlossen sind, die Änderung der abgestrahlten Leistung
ist minimal und daher zu vernachlässigen.
->Aus unseren Eingängen wird keine nennenswerte Leistung abgestrahlt!
(Zum Glück für unsere Messobjekte!)
Auch hat die Polarisierung der Antenne kaum Änderungen am Gesamtbild
aufgezeigt, was den Messaufwand schon mal halbiert hat.
Allgemeines zur abgestrahlten Leistung: In der EMV sind vor Allem
Quasipeak, Peak und Average Werte von Bedeutung. Die entsprechende Norm
verlangt eine Messung der Quasipeakwerte. Nur für diese sind Grenzwerte
angegeben.
In den Auswertegrafiken sind die grünen Kurven jeweils der Average-
Messwert, blau ist der gemessene Peak Wert ( bzw. der QP Wert im Anhang
3).
Bei der Nachmessung (Anhang 4) repräsentieren die blauen Kreuze den QP
Wert. Die rote Gerade (mit dem Knick) stellt das erlaubte Limit gemäß
Norm dar.
Eine komplette Quasipeak Messung (QP) von 30MHz bis 1GHz mit nur einer
Polarisation dauert ca. 5 Stunden! (Wen interessiert warum das so ist,
empfehle ich Wikipedias Definition des Quasipeak- Wertes)
Für die Praxis bedeutet das, es wird der Average Wert und der Peak Wert
gemessen und nur die kritischen Frequenzen (solche die über -6dB unter
dem zulässigen Grenzwert liegen) werden einzeln nachgemessen.
Mit diesem Verfahren lässt sich die Messzeit auf ca. 20-25min pro
Polarisation verkürzen.
Zum Vergleich hab ich dennoch mal einen kurzen Teil-Scan mit QP
erstellt.
Nun noch der Teil mit den Messergebnissen von 150kHz bis 30MHz.
Wie bereis geschrieben gibt es für diesen Bereich keine Grenzwerte für
radiated emission.
Ich hoffe auch diese Grafik ist mit dem oben Geschriebenen ausreichend
erklärt.
Als nächstes will ich noch die Störungen, welches unser Oszilloskop auf
die Netzleitung zurückspeist, messen. Die conducted emission also.
Niederfrequente Störungen werden sich, speziell wenn billige DC-DC
Wandler eingesetzt wurden, massiv auf diese Weise zeigen.
Kommentare zu den Messungen sind herzlich willkommen.
Noch ein Nachtrag: aus vorigem Anhang mit den Nachmessungen lassen sich
gut die exakten Frequenzen der Störungen ablesen. Evtl kommt uns die ein
oder andere Frequenz davon bekannt vor? Markant sind natürlich immer die
exakten Frequenzen wie z.B. 150MHz und der Oberwellen (300MHz,
450MHz...). Wahrscheinl. basiert das Ganze sogar auf den gemessenen
49,98MHz. Eine gewisse Frequenzabweichung ergibt sich hier durch die
Messbandbreite von 120kHz. Normalerweise misst man solche Stellen dann
einzeln nach, um bereits bei der Geräteentwicklung solche Problemstellen
identifizieren und beseitigen zu können.
...Das wurde bei unserem Scope wohl verpennt?
So, erst mal genug für heute.
Gruß, brunowe
25 MHz sind der Grundtakt, mit dem die FPGAs laufen und aus denen sich
auch das Timing der externen Speicher ableitet. Eine Spitze in dem
Bereich kann ich mir gut vorstellen.
Jörg
Hmmh,
die 150 kHz bis 30 Mhz sehen ja sauber aus. Normalerweise werden
die doch nur leitungsgebunden geprüft? Womit öffnet man die rtf-Dateien?
Danke für die Messungen, toller Arbeitsplatz! Guido
Hallo,
mein Rhode und Schwarz EMC32 Programm erstellt die Reports direkt im
rtf- Format. Gestern hat die Umwandlung in pdf irgendwie gezickt...
Heute ging das seltsamerweise problemlos...hier also die Testreports im
pdf.
@Guido: es gibt einen gewissen Bereich in dem beide Messarten erlaubt,
bzw. auch verlangt werden.
Momentan führe ich z.B eine leitungsgebundene Störspannungsmessung von
30MHz bis 108MHz für die Automobilindustrie durch. Für das gleiche
Produkt ist aber auch eine RE Messung ab 150kHz (bis 2,9GHz) angesetzt.
Gruß, Bruno
Ich untersuche im Ramen von Osoz gerade, was unser Welec beim Capturing
eigentlich anstellt, mit den 4 versetzten ADCs bei 1GSa Abtastrate.
Das ist ganz interessant buggy, auch abhängig vom FPGA-Bitstream. Mir
sind 2 Versionen bekannt. Mein Scope kam mit 8C7, seit ich es
umprogrammieren kann habe ich mit 1C9 rumgespielt. So wie die Abfragen
in der alten Firmware programmiert sind ist 8C7 die neuere FPGA-Version.
In Osoz habe ich einen Testbutton eingebaut, der die Rohwerte auf die
RS232 rausschreibt. Mit Excel etwas aufbereitet kommen dann solche
Bilder raus wie im Anhang. Dargestellt ist eine steigende Flanke,
absichtlich keine allzu schnelle. Ich habe die Meßwerte der 4 ADCs
zyklisch eingefärbt, so sieht man gut wer welchen Beitrag leistet. Das
sind Rohwerte, absichtlich ohne Offsetkompensation zueinander. Im Ein-
uns Auslauf sieht man diese Fehler als horizontales zyklisches
"Geklingel".
Mit FPGA v1C9 ist ADC1 (blaue Rauten) etwa 8 Samples zu früh dran. Ich
habe ihn im zweiten Bild um 8 Samples nach rechts verschoben, dann paßt
es schon besser. ADC2 (rote Quadrate) liefert ein schlechtes Signal. Ich
habe den Eindruck es gibt da eine Hold Time Violation zum FPGA und
mindestens ein Bit bestimmter Wertigkeit kippt gerne. Wenn ich die
Nullinie mit dem Offset herumschiebe merke ich auch das es Positionen
gibt, wo das +/-1 Rauschen bevorzugt Ausreißer zeigt, ich glaube um 16
Pixel. Von daher kann man sich die Bitnummer schon ausrechnen...
Ich vermute das FPGA filtert intern noch, weshalb die Ausreißer auch die
Nachbarschaft beeinträchtigen, allerdings nur innerhalb desselben ADCs.
Mit FPGA Version 8C9 sieht das Bild anders aus. Es ist natürlich nicht
das identische Capturing, nur ein ähnliches.
Nun benimmt ADC2 sich ordentlich, überhaupt sehen alle ADCs gut aus. Es
gibt einen anderen zeitlichen Versatz. Für das letzte Bild habe ich ADC2
um 8 Samples und ADC1 um 4 Samples nach rechts verschoben, der Dateiname
deutet es an. Dann liegen sie einigermaßen übereinander, der Rest könnte
dem Offset-Geklingel entsprechen.
8C9 ist zumindest in diesem Belang und auf meinem Gerät die bessere
Version.
Apropos Offset, damit habe ich auch experimentiert. Mit einer reinen
Offsetkompensation der ADCs zueinander sah es immer noch nicht richtig
gut aus. Der Offset ist sozusagen pegelabhängig. Oder anders
ausgedrückt, die ADCs haben etwas zueinander abweichende Kennlinien. Ich
überlege, ob man zusätzlich noch eine Skalierung aufnimmt, zur Laufzeit
dann pro ADC eine Lookup-Table draus baut. Mit den Offset-DACs und
kurzgeschlossenem Eingang könnte man die ADCs zur Kalibrierung
durchwobbeln.
All diese Probleme gelten nur für Abtastraten >250MSa, darunter ist nur
ein ADC in Betrieb. Der restliche Capture-Speicher Speicher im FPGA
bleibt leider ungenutzt.
Jörg
Hallo,
heute habe ich die conducted emission Messungen mit meinem W2022A
durchgeführt. Bei diesen Messungen wird das Scope über eine 50 Ohm/ 50
μH Netznachbildung (LISN) angeschlossen und die leitungsgebundene
Störspannung mittels eines EMI Receivers gemessen.
Die Referenzmessung zeigt den systembedingten Messfehler der
Messanordnung auf. Hierbei war zwar die LISN angeschlossen, der 230VAC
Ausgang aber nicht belastet.
Wo Grenzwerte definiert sind, hab ich diese eingetragen.
Ich hab auch Bereiche gemessen in denen keine Grenzwerte definiert sind
(z.B. schon ab 9kHz)
Schön zu erkennen ist der einzelne Peak bei 25MHz, dieser "schafft" es
allerdings nicht eine nennenswerte Störung des 230VAC Netzes
hervorzurufen.
Unser Scope hätte nach den Vorgaben der EN 55011 die CE Messung
bestanden.
Ich werde mir die Tage einmal überlegen, was man gegen die Störstrahlung
unternehmen könnte und wo welche Frequenz abgestrahlt wird. D.h. ich
werde einmal mit der Nahfeldsonde das Scope abtasten.
Gruß, Bruno
Das sind ja interessante Neuigkeiten aus verschiedenen Richtungen.
Auch wenn ich Momentan nicht dazu komme mitzuwirken, bin ich als
Mitleser immer dabei.
Zu Jörgs Ergebnis:
Da müßte man ja eigentlich die 1C9 Versionen auf 8C7 umschießen, um da
noch etwas rauszuholen. Das müßte doch eigentlich machbar sein oder?
Gruß Hayo
Hayo W. schrieb:> Da müßte man ja eigentlich die 1C9 Versionen auf 8C7 umschießen, um da> noch etwas rauszuholen. Das müßte doch eigentlich machbar sein oder?
Klar kann man das. Habe ich heute morgen für die beiden hinteren Bilder
auch gemacht, mein Scope wieder auf 8C7 zurückgeflasht.
Man braucht den unter Windows 7 knifflig zu installierenden Slog-Treiber
und Quartus.
Vielleicht verhält sich die Hardware mit "besserer"
Softwareinitialisierung ja auch noch unterschiedlich. Es gibt in dem
Bereich magische Zahlen die in die ADC-Register geschrieben werden und
die ich nicht verstehe. Teils kommen die eigentlich aus dem sog.
Protected Flash, bei mir sind sie noch hart codiert.
Was ich noch vergessen habe zu fragen: ihr hattet meine ich doch auch
schon verschiedene Grundlagenforschung betrieben?
Jörg
Jörg H. schrieb:> ihr hattet meine ich doch auch> schon verschiedene Grundlagenforschung betrieben?
Ja, ist richtig. Einiges davon ist auf der W2000A Wikiseite zu finden,
wenn ich mich recht erinnere. Auch zur Verschiebung der ADCs hatten wir
schon Tests gemacht - aber noch keine endgültige Lösung gefunden da die
FPGA-Versionen hier für etwas durcheinander sorgten.
Bei den Registerwerten habe ich auch schon herumexperimentiert, die
aktuellen Lösungen findet man bei mir in der FW. Das Optimum ist das
aber sicherlich nicht.
Jörg H. schrieb:> Klar kann man das. Habe ich heute morgen für die beiden hinteren Bilder> auch gemacht, mein Scope wieder auf 8C7 zurückgeflasht.
Dann kann man den 1C9 Besitzern eigentlich nur empfehlen Ihr FPGA auf
8C7 upzudaten. Denn dann wäre wenigsten das übelste Spikeproblem
behoben.
Die Frage ist in wie weit man die unterschiedlichen Versionen supporten
kann um auf die gleiche Signalqualität zu kommen.
Hilfestellung zum FPGA-Update könntest Du dann ja sicherlich geben.
Gruß Hayo
Hallo zusammen.
@Bruno
Danke für die interessanten Messergebnisse!
Es amüsiert mich, dass das Welec in Sachen leitungsgebundene Störungen
besteht...denn das Schaltnetzteil ist ja ein Zukaufteil und nicht von
den Wittigs entwickelt :)
Dass die radiated emissions übel aussehen müssen, ist einem bei einem
Blick in die Kiste eigentlich klar - Toll, dass du das mit Daten
untermauert hast.
@Jörg
Es macht Spaß, dir bei der Arbeit "zuzulesen": du gehst derart
methodisch und fundiert an alles heran, dass es eine wahre Freude ist.
Schnellschüsse oder Bastellösungen sucht man bei dir vergebens -
wirklich vorbildlich.
Gruß
Michael
Hallo
@ Michael: stimmt, das SNT ist ja ein Zukaufteil, das erklärt die guten
Messergebnisse ;)
Als erstes reiche ich noch ein Foto vom gestrigen Messaufbau (CE Tests
mit unserem Welec) nach.
Heute hab ich mal eine RE Messung an einem "richtigen" Oszilloskop
vorgenommen. Der Probant war ein TEK DPO 4054, 500MHz, 2,5GS/s.
Mich haben die Ergebnisse unseres Welec's einfach ziemlich schockiert
und ich wollte mal sehen was ein gutes Gerät so abstrahlt....
Fazit: Es liegen Welten dazwischen, auch wenn ich bei dem TEK eine
Schwachstelle lokalisieren konnte. Ich hoffe die im pdf eingefügten
Fotos und die Erklärung dort machen das deutlich.
Aufgeschraubt hab ich das TEK nicht um meine Vermutung zu bestätigen.
Das wäre bei einem normalen Gerätetest (Qualifizierung) der logische
nächste Schritt....
@Jörg: Wenn ich mehr Ahnung hätte, von dem was du da treibst, dann würde
meine Anerkennung bestimmt noch stärker ausfallen... Dennoch Respekt!
Gruß, Bruno
Hi Bruno,
Du testest wie ich sehe ein 2-Kanalgerät. Ich könnte mir vorstellen,
dass die 4-Kanaler sogar noch einen drauflegen,da ja zusätzlich
Leitungen und Signale abstrahlen.
Gruß Hayo
Hallo Hayo,
ja da hast du bestimmt recht. Das Ergebnis war aber auch so erschreckend
genug.
Bin heute auch schon mal mit der Nahfeldsonde an unser Oszi ran.
Die Vorderseite war relativ clean, abstrahlungstechnisch. Das lässt sich
aber relativ einfach durch das Metall Chassis auf denen unsere Knöpfe
und Drehencoder montiert sind, erklären. Besonders die 25MHz waren aber
seitlich und auf der Rückseite gut zu messen.
Ich werde demnächst noch ein paar Fotos mit Messungen am offenen Herzen
anfertigen ;)
Wenn Frequenzen dermassen stark abgestrahlt werden, so ist das ein
sicheres Zeichen, dass entweder nur eine schlechte oder gar keine
Schirmung vorhanden ist. Darüber hinaus ist auch wahrscheinlich, dass
keine Massnahmen ergriffen wurden um die leitungsgeführte Ausbreitung
der unerwünschten Frequenzen zu unterdrücken -> schlechtes Layout (ggf.
schlechte Masseanbindung) , bzw. schlechtes Schaltungskonzept.
So langsam glaub ich, mit dem know how der Leute hier im Forum, hätten
wir locker ein mindestens genauso gutes Oszi neu entwickeln können!
Wäre mal ne interessante Aufstellung was da an Entwicklungsarbeit und
Kosten zu investieren wäre...
Gruß, Bruno
Bruno We schrieb:> So langsam glaub ich, mit dem know how der Leute hier im Forum, hätten> wir locker ein mindestens genauso gutes Oszi neu entwickeln können!> Wäre mal ne interessante Aufstellung was da an Entwicklungsarbeit und> Kosten zu investieren wäre...
An ein mechanisch kompatibles Mainboard habe ich vage auch schon mal
gedacht. Das Gehäuse kann meinetwegen bleiben.
Mittlerweile gibt es glaubich die Leistung der 4 ADCs auch in einem
Chip, was deutlich einfacher zu handhaben wäre. Die Consumer-Grade FPGAs
dürften mittlerweile auch leistungsfähiger geworden sein. Mehr interner
Speicher wäre nett.
Der analoge Part wurde mit der neuen Eingangsstufe ja schon recht weit
getrieben, die gleich mit drauf ist doch schon die halbe Miete?
Aber vorerst bin ich mit der bestehenden Technik noch ganz gut
beschäftigt...
Jörg
PS: danke für die Blumen!
Bruno We schrieb:> @Jörg: Wenn ich mehr Ahnung hätte, von dem was du da treibst, dann würde> meine Anerkennung bestimmt noch stärker ausfallen...
Geht mir genauso, bitte deute mein Schweigen zu EMV-Themen nicht als
Ignoranz, sondern stille Bewunderung.
Michael H. schrieb:> @Jörg> Es macht Spaß, dir bei der Arbeit "zuzulesen": du gehst derart> methodisch und fundiert an alles heran, dass es eine wahre Freude ist.
Ich versuche schnellen Erfolgserlebnissen zu widerstehen. Ist mir mit
dem Capturing doch ziemlich lange gelungen? Bottom-Up ist wie auf dem
Bau: erstmal ein Teil aushärten lassen (hier: testen) bevor man die
nächste Lage draufstellt, das hält besser.
Ich versuche, von unten beim Prozessor und der Hardware angefangen die
Dinge jeweils vollständig zu verstehen bevor ich drauf baue.
Gelingt aber nicht immer. ;-)
Hallo zusammen,
vielleicht kann mir einer von euch helfen. Mein Oszi geht ja schon eine
ganze Weile nicht mehr und mittlerweile weiß ich zumindest, dass die
Symptome zu einem nicht funktionierenden SRAM passen. Nachlöten bringt
nichts, also möchte ich es ersetzen - nur leider ist es sehr schlecht
erhältlich.
Meine Frage ist nun: weiß jemand, wie schnell die SRAMs angesprochen
werden? Es sind ja 8ns SRAMs drauf, einen äquivalenten Typ mit 10ns
hätte ich aufgetrieben und wüsste nun gern, ob der schnell genug ist.
Ich bin für jede Hilfe dankbar!
Gruß
Michael
Hello! I have many 0603 resistors (24,9 and 150 ohm) for welec hardware
mod.
If interested feel free to send me a private mail: eprota at tiscali.it
Thanks
Erry
Hallo,
was für's Sommerloch, ich habe hier (hoffentlich) eine kleine Sensation:
Das originale FPGA-Design von Welec!
Es ist ja bisher sehr hinderlich, das wir nicht recht wissen was da drin
steckt, und an den Bugs nichts beheben können.
Da baggere ich schon seit Februar mühsam dran rum, vor ein paar Tagen
habe ich endlich erste Dateien erhalten, auch mit der Erlaubnis sie zu
veröffentlichen. Bisher habe ich hier im Forum noch nichts davon
erzählt, damit nicht etwa ein Bedenkenträger bei Wittig aufgescheucht
wird.
Leider ist es nicht das letzte, aktuelle Design, sondern wohl ein
Zwischenstand der Entwicklung. Es scheint aber nichts grundsätzliches zu
fehlen. Vielleicht kriegen wir in ein paar Wochen noch ein Update.
Hier die Links, wohin ich die Files hochgeladen habe. Bei Anonfiles
gehen die Dateinamen verloren (Nomen est Omen?), bitte wieder zurück
umbenennen.
Das hier ist das mit Abstand vollständigste Design:
TomCat-CII_2006_02_23.zip
https://anonfiles.com/file/6c0d44ac02012bb14dbec405dadaae0a
Da sind alle möglichen Files drin, bestimmt auch erzeugte/temporäre,
nicht nur die Quellen. Weil ich mich damit nicht auskenne kippe ich das
lieber vollständig hier ab.
Dann gibt es noch andere Dateibäume, mit andersartigen Nios-Designs ohne
Capture-Einheit. Pinbelegung paßt nicht, die Nios-Peripherie auch nicht.
Vermutlich uninteressant, vielleicht Teile für FPGA-Boards zur
Softwareentwicklung ohne Oszi-Komponenten.
TomCat-CII_2004_06_24.zip
https://anonfiles.com/file/0238b1032ca321333a850bed47e94e8c
TomCat-CII_2006_10_26.zip
https://anonfiles.com/file/7ae427ba9b7dc8ab471fabc3072ca1d3
Als Addon haben wir hier noch den Quellcode für das Welec-Tool, ist
vermutlich uninteressant. Software-Update kann ich bestimmt besser.
Delphi.zip
https://anonfiles.com/file/d0c4a3bf43128ffc931a90515ffa3e67
Im nächsten Posting beschreibe ich, was ich aus
TomCat-CII_2006_02_23.zip bisher rausgefunden habe.
Grüße
Jörg
So, weiter gehts.
Vorweg: Ich bin kein FPGA-Entwickler (sondern Firmware-Entwickler), aber
arbeite in einer Firma die sowas kann. Bei der Arbeit haben wir auch die
Altera-Tools und entsprechende Lizenzen. Ich kenne den Kram ein bischen
vom Hörensagen, aber habe selbst noch nicht an Logikdesigns
rumgefummelt.
Mit einem Altera-erfahrenen Kollegen habe ich mich da dran gesetzt. Wir
haben obiges Design recht problemlos synthetisiert und gemapped
bekommen.
Das Design ist zu Zeiten von Quartus 5 entstanden (aktuell ist 12),
übersetzt haben wir es mit Quartus 9.1. (Wir mußten Zeile 101 in
TomCat-CII.qsf auskommentieren, da wird ein Tool namens "exemplar"
angesprochen was wir nicht haben.)
Nochmal zurück, was ist in dem .zip drin?
Das Design ist nicht in einer Hardwarebeschreibungssprache wie VHDL oder
Verilog formuliert, sondern als ein Satz hierarchische Schaltpläne
grafisch gezeichnet. Das hat den Charme, das auch Laien wie ich da
draufschauen können und eine Chance haben, die Logik zu verstehen. Mit
dem bei Altera kostenlos herunterladbaren Quartus Web Edition kann man
sich das angucken, wenn auch nicht übersetzen.
Kleine Anleitung: Quartus installieren und starten, das Top-Level
Projekt TomCat-CII.qpf öffnen, links im Projektnavigator den Reiter
"Files" anklicken, den Schaltplan TomCat-CII.bdf öffnen. Ab da geht's
ganz intuitiv grafisch weiter, Unter-Blöcke kann man mit Doppelklick als
neues Blatt öffnen.
Dieser Schaltplan-Satz ist schon eine beachtliche Leistung, mein
Respekt. In den Hierarchien ist einiges drin. Mit HDL kann man komplexe
Designs sicher besser beherrschen, außerdem sind sie portabel. Ich
stelle mir vor, ich müßte meine Software komplett als Struktogramm
zeichen statt in C programmieren...
Die CPU und ihre Peripherie ist vom Altera SOPC Builder erzeugt, ein
mitgeliefertes Tool was so einen Softcore erzeugt, mit Bussen und
Peripherie bestückt und aus dem Ganzen ein großes Verilog-File erzeugt,
plus glaube ich ein paar Tabellen mit Microcode oder so.
Bei der Arbeit haben wir keine Bibliothek für den Nios, es gibt nur noch
den Nachfolger Nios-II. Weil das ursprünglich erzeugte Verilog-File noch
da ist können wir das so als Block zwar mit übersetzen, aber nicht mit
dem SOPC Builder verändern. Gegenüber dem Stand in unseren Oszis sind
die Interrupts anders zugeordnet und es fehlen noch 3 GPIO-Ports. Einen
davon benutze ich bei Osoz, den VSync-Interrupt, die anderen beiden sind
für (ungenutzte) Software-Abfrage der Boot-Tasten. Die
Interrupt-Zuordnung könnte man zur Not im Verilog kompatibel patchen.
Mit ein paar Mausklicks könnten wir auch die CPU durch einen Nios-II
ersetzen...
Weiter zum Stand des Logikdesigns, was mir so aufgefallen ist:
- Die zwei FPGAs der Vierkanäler haben denselben Inhalt. Es gibt einen
Pin (E9), der festlegt ob der Chip Master oder Slave ist. Davon abhängig
wechselt die Richtung von 6 bidirektionalen Verbindungsleitungen, mit
denen sie sich über z.B. Trigger und Kanalprogrammierung verständigen.
Der Bus geht an beide.
- Die LED+Keyboard Anschlüsse tragen gerade andere Testsignale, für die
originale Funktion müßte man die wieder zu den ursprünglichen Ausgängen
gerade durchverbinden. Das habe ich erst nach unserer Synthese bemerkt,
daher das Produkt auch nicht ausprobiert. Außerdem weiß ich nicht, wie
ich mein erzeugtes .sof File für beide FPGAs in ein .jic File bekomme,
mit dem ich bisher die FPGAs gebrannt habe.
- Es gibt ein paar Open Ends: einen "Triangle Generator", einiges bei
den Kanälen, z.B. Trigger min/max Speicher
- Ein weiteres Open End ist der Logic Analyzer. Der begegnete uns in der
Software auch schon mal in Andeutung, Funktion war komplett unbekannt.
Anscheinend werden 16 Bit breite Daten die sonst von 2 ADCs kommen
zusätzlich separat behandelt, in einen kleinen Extra-Speicher mit einer
Triggermimik. Bei Zeitauflösungen die nicht alle 4 ADCs erforden hat
Wittig sich wohl eine LA-Möglichkeit vorgestellt. Das ist noch unfertig,
z.B. ist der Reset dieser Baugruppe nur an einen externen Button
angeschlossen statt an den Systemreset. Ohne entsprechende Vorbereitung
der Platine wäre das auch schwer zu nutzen, braucht Eingangstreiber mit
LVDS-Ausgängen parallen zu 2 ADCs.
- Die Trigger Mode Register sind noch nicht vollständig. Wir haben da
vermutlich 8 Register, hier sind es erst 5, ferner noch nicht alle
späteren Bits belegt. Schade, speziell dieser Teil ist nämlich sehr
rätselhaft, es wird ihm auch Einfluß auf das Spike-Problem nachgesagt.
- Ein späterer "Hack" für programmierbare Grid-Farbe fehlt noch. Dazu
wurden später 6 Bit von einem obigem Mode-Register zweckentfremdet.
- Der Ausgang des Testgenerators ist noch nicht verdrahtet (später Y9).
Dafür ist er mit einem Test-Out-Register programmierbar (vielleicht eine
8-bit PWM?), was bei uns keinen Einfluß hat.
Soweit der Stand meiner Forschungen. Ich hoffe, das wirklich
Hardware-Kundige sich des Designs annehmen. Wir können da hoffentlich
noch viel lernen, und den "klassischen" Grund-Übeln nachspüren.
Es wäre z.B. überaus interessant, dem Spike-Problem nachzugehen. Und
warum die Sortierung der ausgelesenen Meßwerte in 4-ADC-Zeitbasen
"verrutscht", vielleicht ist da in der Software auch noch was
unzureichend bedient.
Soweit erstmal, mal schauen was sich noch so ergibt.
Viel Spaß bei der Schaltplan-Lektüre!
Jörg
@Jörg
Hi,
I'm going to see your documents for which I thank you.
I do not understand a couple of things.
The documents you shows us are been obtained starting from the original
Wittig's FPGA artichecture?
If no, how you have obtained them?
Even if not documented (I know Wittig's documentations is lack), with
the debugging tools that you described would not be possible to obtain
similar documents starting from the original FPGA architecture developed
by Wittig?
Cheer,
Cy
Hello Cy,
may I ask who you are, or where from? I haven't seen you here before.
Does babelfish work for you, or shall I translate parts of my posting?
The files I posted are the original Wittig design. However not the most
recent version, as in the devices been sold. But it's a starting point.
Jörg
@Jörg
Hi Jörg,
you are right, I understand I was rude, I'm so sorry for that.
Then, let me introduce myself.
My name is Paul and I'm from Canton Ticino (Italian Switzerland, at this
moment I'm spending the holidays in Italy).
Starting last April I became interested in Wittig's oscilloscopes
because I received a second hand W2012 as gift.
Meanwhile starting to read up on it I found this forum where I learned a
lot of things about it.
You never seen me here before because I'm generally a lurker and the
only time I wrote in the forum I did it on day May 20 2012 in the
firmware section.
I never used a online translator due the fact I prefer try to translate
myself.
As you can see my English is poor and even more poor is my German, so
it's pretty normal that I cannot understand some parts in your post and
I'm so sorry about this.
Thank you for your willingness to act as a translator if necessary, I
hope it will not be needed.
Next time I will try to use a online translator as you suggested me.
Thank you also for all the useful informations and answers you provided
me.
Cheer,
Cy
Hallo,
das ist ja wirklich sehr interessant!
Ich hatte vor ca. 4 Jahren den ersten Kontakt mit dem Welec Scope und
konnte damals nach langem Hin und Her die C-Code files von Wittig
ergattern. Damals wurde mir gestattet die Files zu veröffentlichen und
das Projekt als Open Source ins Leben zu rufen. Recht bald ist den
Profis hier aufgefallen, dass es gravierende Fehler im FPGA Design gibt.
Ich (und auch Andere hier aus dem Forum) haben dann noch über Monate
versucht von Wittig die FPGA Files zu bekommen.
Die Aussage von Wittig damals war immer die Gleiche: Die Rechte liegen
nicht bei Ihnen und somit dürfen und können Sie den Code nicht
freigeben. Nach deren Aussage haben Sie den Code nicht einmal (das Scope
wird in GB gefertigt!). Jetzt wäre also wirklich interessant wo der FPGA
Code her kommt... ich hatte damals eigentlich nicht den Eindruck dass
mir die Unwahrheit erzählt wird...
Jetzt sind also unsere FPGA Cracks gefragt...
Gruß, Brunowe
Hi Brunowe,
schön mal wieder von dir zu lesen. Jörg hat offensichtlich Mittel,
über die wir nicht verfügen. Ob es was hilft müssen wir mal abwarten.
Da wohl immer noch Closed-Design mit drin ist lässt sich das Ganze
ja nicht überarbeiten. So bleibt weiterhin nur die Möglichkeit
Schwächen des FPGA-Designs per Software auszugleichen.
Bruno We schrieb:> Die Aussage von Wittig damals war immer die Gleiche: Die Rechte liegen> nicht bei Ihnen und somit dürfen und können Sie den Code nicht> freigeben. Nach deren Aussage haben Sie den Code nicht einmal (das Scope> wird in GB gefertigt!). Jetzt wäre also wirklich interessant wo der FPGA> Code her kommt...
Ja ich erinnere mich. Aber anscheinend war es doch nicht die ganze
Wahrheit.
Guido schrieb:> So bleibt weiterhin nur die Möglichkeit> Schwächen des FPGA-Designs per Software auszugleichen.
Nicht nur! Erstens ergeben sich Erkenntnisse über Detailfunktionen und
weiterhin läßt sich evtl. auch was am Design ändern.
Die Frage ist hierbei nur wie tiefgreifend wir da ändern wollen. Eine
Möglichkeit die Jörg ja schon angesprochen hat ist der Wechsel (bei
ansonsten gleichen Design) auf NIOS II, was wohl deutlich mehr
Performance verspricht. Auf jeden Fall könnten wir Leute mit
FPGA-Knowhow gut gebrauchen...
Gruß Hayo
Hi,
na das ist doch mal eine gute Nachricht und ein ziemlicher schritt nach
vorn.
hier mal die exemplar.lmf aus meiner max+plus installation. Damit lässt
sich das Projekt unter Quartus 9 ohne Modifikationen bauen. (wenn auch
mit reichlich Warnings)
Was das Übertragen der .sof Datei an geht, sollte sie sich direkt aus
quartus heraus über USB einspielen lassen wenn das scope im ByteBlaster
modus ist. Mit meiner Quartus Installation lässt sich auch der NIOS im
SOPC-Builder öffnen und bearbeiten. Demnach sollte also Designmäßig
alles soweit offen liegen und vorhanden sein.
grüße sunny
Hi sunny,
ich kenne mich mit Altera nicht aus, aber das klingt ja schon
mal gut wenn du das bauen kannst. Was ist mit dem "exemplar",
das Jörg auskommentieren musste macht das max+plus automatisch?
Wozu verwendet man denn dieses max+Plus? Mit Gurgel finde ich
da nix verständliches.
Grüße, Guido
Hi all!
Entgegen meiner obigen Aussage kann man das Design auch mit der freien
Quartus Web Edition übersetzen. Ob es auch läuft weiß ich noch nicht.
Es gibt übrigens keine nicht einsehbaren Teile, hatte ja irgendwer
befürchtet.
@Bruno: hast du noch Komntrakt zu Slog? Du könntest ihn ja mal hierauf
stubsen. Und bei der Gelegenheit fragen, ob er seinen sehr praktischen
Blaster-Treiber auch für 64Bit-Windows kompilieren kann. ;-)
@sunny: Danke für das .lmf File. Die Register kennen wir, und sogar noch
ein paar weniger wichtige mehr, die in diesem Design noch fehlen. Es
wird für uns Softwerker auch ein Header-File erzeugt, das vom aktuellen
Design haben wir.
Weitere Erkenntnisse meinerseits, was mir seitdem auffiel:
- Die Kanalauswahl für den Trigger ist anscheinend noch nicht
verdrahtet.
- Ein Reset per Softkey-Kombination ist vermutlich noch nicht möglich,
denn dann müßte der Keyboard-Teil entsprechende Ausgänge haben. Sprung
in den GERMSloader erst recht nicht, da kommt ein fehlendes Register ins
Spiel.
- Als externer Oszillator war wohl mal 50 MHz vorgesehen, nicht 25 MHz
wie bei uns bestückt. Die Leitungen heißen noch so, auch die PLLs sind
drauf eingestellt. Der Takt zum Nios (halber Systemtakt) ist im
SOPC-Builder allerdings bereits mit 12,5 MHz angegeben. Da hatte man
wohl gerade ein Problem festgestellt und gedrosselt. So wie es jetzt
steht würde der Nios also wie gewohnt laufen, Capturing aber nur mit
halber Geschwindigkeit.
- Ich habe ganz eventuell den Fehler gefunden, warum im 4ADC-Modus die
ADCs gegeneinander verschoben erscheinen. In der Datei tc_acq_ram.bdf:
das Signal "record_ff" wird in allen 4 clock domains für das
Rücksetzsignal "aclr" der Adreßzähler verwendet, aber mit nur dem ersten
Clock "clk_g10" synchronisiert. Für die anderen ist es dann eher Zufall,
wann sie loslaufen. Aber vielleicht habe ich das auch nicht verstanden.
Wie man das korrekt löst weiß ich erst recht nicht.
- In dem Design haben wir keine sog. Constraints gefunden. Das sind
Informationen an die Synthese, wie schnell wir denn z.B. takten wollen.
Von daher kann das Tool auch nicht ausgeben, ob das so klappt. Nur
hinter den PLLs sind die Takte bekannt, da gibt es auch prompt etliche
Violations.
- Ferner habe ich eine Pinliste erstellt, mit den Belegungen im
Wittig-Design sowie den Community-Anläufen ZPU/Leon, siehe Anhang.
Entgegen meiner Hoffnung kamen dabei keine neuen, unbekannten Pins
zutage. Es fehlen im Gegenteil sogar 2, der Kalibrierausgang und ein
Takt. Zwei LVDS-Pärchen für 2 ADC-Pins sind anders verdrahtet. Wer hat
nun recht? Ich vermute "unser" Pinning, vermutlich gab es da noch eine
Layoutänderung.
Die Differenzen habe ich in der Tabelle gelb markiert. Potentiell 27
I/Os sind noch frei. Dürfte aber schwierig sein, da unter dem BGA
dranzukommen.
Mehr später,
Jörg
Hallo Jörg,
Slog ist immer noch im ixbt Forum aktiv. Du kannst ihm ja dort eine
Nachricht auf englisch hinterlassen. Mein Russisch ist zwischenzeitlich
auch schon etwas eingerostet...
http://forum.ixbt.com/topic.cgi?id=48:7811-10
Gruß, Brunowe
@guido
max+plus ist die alte Entwicklungsumgebung für Altera FPGA's. Also das
was heute Quartus ist.
Wieso die exemplar.lmf damals mit bei war und heute nicht, weiss ich
auch nicht.
gruß sunny
Bruno We schrieb:> Slog ist immer noch im ixbt Forum aktiv. Du kannst ihm ja dort eine> Nachricht auf englisch hinterlassen. Mein Russisch ist zwischenzeitlich> auch schon etwas eingerostet...> http://forum.ixbt.com/topic.cgi?id=48:7811-10
@Bruno: ich kann kein Wort Russisch. Hab's trotzdem versucht, mich mit
Hilfe von Google Translate dort angemeldet und ihm eine PM geschickt.
Bin mir aber nicht abschließend sicher, ob das geklappt hat und ihn
erreicht. Wenn du eine Email-Adresse hast wär's einfacher.
@all:
Ich kann jetzt .sof Files in das FPGA laden, das Ergebnis von Synthese
und Mapping. Tut sich leider gar nichts. Eigentlich müßte der ROM
Bootloader eine Kennung auf die serielle Schnittstelle senden. Ich bin
mir nicht sicher, ob der Bootloader tatsächlich den Weg in das .sof
gefunden hat, kennt sich jemand damit aus?
Ich habe im Design folgende Änderungen gemacht (siehe Datei im Anhang):
die Anschlüsse für LED und Keyboard wieder an die originalen Signale
gelegt, den Testgenerator an Pin Y9 verkabelt, eine Inkonsistenz am
SRAM-Adreßbus beseitigt (die untersten 2 Bits weglassen).
Jörg
Hallo Jörg,
ich hatte es gestern auch schon probiert, leider vorerst auch mit dem
selben Resultat. Die Änderungen hatte ich auch schon gemacht.
Der Bootloader müsste eigentlich automatisch eingebaut werden.
Ich werde mich jetzt aber nochmal dransetzen und erst mal Deine bdf
verwenden.
Gruß
Hallo Jörg,
ok, ja die Anmeldung ist etwas tricky wenn man kein Russisch kann.
Ich hab eine Email Adresse und schick Sie dir als PN, will die hier
nicht öffentlich rein stellen.
Gruß, Bruno
So, zumindest tut das neugebaute Design jetzt etwas:
**********************************************
BlueFlash firmware starting!
**********************************************
- Hardware initialization
spurious interrupt number: 00000013
Der Grund, warum das Design bisher scheinbar tot war, ist die
Master-Slave Umschaltung. Ich habe die deshalb vorerst mal fest an GND
gelegt.
Wie Jörg schon festgestellt hatte passen die Ints nicht zu unserer
Software,
deshalb wahrscheinlich die "spurious interrupt number".
Außerdem ist die Takterzeugung noch ziemlich buggy, deshalb stimmt die
Baudrate am UART nicht.
Sehr gut Fritz, das ist ja mal ein Anfang!
(Geradezu genial, wie bist du denn darauf gekommen?)
Ich habe das gerade nachvollzogen, den Inverter hinter dem
Master-Eingang rausgenommen. Vielleicht war der nur zu Testzwecken drin?
Jetzt kriege ich immerhin schon die Startmeldung von Hayos Software zu
sehen, inmitten buntem Pixelsturm. Auf der seriellen ist auch was los.
Eine unorthodoxe Bitrate, ich mußte den LA bemühen: ich messe 1/4 der
nominellen 115200, 28800 Baud, an meinem Terminal nicht einstellbar.
Die Interruptprioritäten habe ich im generierten Verilog des
Nios-Systems auf "unsere" Werte geändert. Das ist dort ganz gut
nachvollziehbar, ab Zeile 3474 in "TCCPU.v". Der Optik halber auch im
SOPC-Builder, aber das ist wirklich nur zur Anschauung, ohne die
Nios-Lib kann ich das nicht neu erzeugen.
Siehe da, es geht ein gutes Stück weiter. Ich sehe (inmitten des bunten
Pixelsturms) das Grid, UI und bewegte Wellen. Scheint also im Groben zu
arbeiten. Es reagiert aber nicht auf Tastendrücke und Drehgeber. Außer
Softkey F2, das löst einen Reset aus. Die LEDs sind wohl anders
verteilt, leuchten jetzt in "unsinniger" Anordnung.
Anbei meine geänderten Dateien. (Vielleicht sollten wir das Design in
svn einchecken? Welche Dateien braucht man denn wirklich?)
Und ein Bild vom der GUI im Pixelsturm. Den müßt ihr euch noch bewegt
vorstellen.
Jörg
Jörg H. schrieb:> (Geradezu genial, wie bist du denn darauf gekommen?)
Naja es war ziemlich offensichtlich, das da etwas generelles nicht
stimmen kann, also habe ich mir als erstes Takterzeugung und Reset
angesehen.
Die NIOS Lib habe ich leider auch nicht, vielleicht sollten wir doch
versuchen den alten NIOS durch den NIOS2 zu tauschen. Ich habs sogar
schon getan, allerdings passt dann die Software nicht mehr. Der
Germs-loader sollte sich einfach übersetzen lassen, allerdings schwebte
mir eher gleich Dein ucl-loader vor.
Meinst Du, das Du den für den NIOS2 übersetzen kannst, ich hab mich an
deinen ASM Code noch nicht rangetraut.
Außerdem hat der NIOS2 nur Int's bis 32, dort müssten wir also dann
umsortieren.
Gruß Fritz
Den Nios II hatte ich testweise auch schon reingetauscht, um zu sehen
wie groß er ist. Das geht mit dem SOPC-Builder ja ganz einfach, mit ein
paar Mausklicks.
Wir können uns den performantesten Nios II, die Variante /f, locker
leisten. Das wird nur unwesentlich größer als mit dem Nios32. Mit
solchen Annehmlichkeiten wie JTAG-Debugging, Multiplikation, ggf. sogar
Division (brauchen wir vermutlich nicht). Als ich spaßeshalber noch die
FPU angewählt hatte bekam ich aber eine Fehlermeldung bei der Synthese
(undefined entity "fpoint_wrapper"), vielleicht fehlt was.
Aber wenn schon, denn schon: Ich würde eher "auf der grünen Wiese" ein
neues Nios-Subsystem zusammenbauen. Die Hardware könnte viel mehr als
mit dem jetzigen Design. Unser SRAM ist 8ns schnell, das reicht in die
Region von 100 MHz. Laut Altera kann man den Nios II auf unserem FPGA
mit 140 MHz synthetisieren, laut meinem Kollegen kann man diese Angabe
auf 2/3 reduzieren, weiterhin haben wir den langsamsten Speed Grade des
FPGA, während Altera bestimmt den schnellsten für's Benchmarking
herangezogen hat.
Also irgendwas bei ca. 70 MHz. Etwas langsamer als der Speicher könnte.
Den Nios-II kann man mit Cache versehen, was ihn zu einem gewissen Grad
unabhängig macht.
Aber asynchroner Speicher soll hohe Strafe kosten, 12 Zyklen oder so. Da
läßt man den Speicher wohl besser auf gleicher Geschwindigkeit.
Das Flash muß allerdings langsamer laufen, dort greift diese Strafe.
Glücklicherweise hat es einen eigenen Bus.
Im Altera-Baukasten gibt es auch noch solche Dinge wie DMA-Controller,
das könnte auch nützlich sein. Mit den Custom-Instructions kann man
einiges anstellen, vielleicht noch einen DMA-Filter der gleich
min/max/average/rms oder sowas bestimmt, viele Möglichkeiten.
Zu ändern wäre der LCD-Controller. Eine saubere Implementierung wäre,
den als Avalon-Busmaster auszuführen und ihm Priorität gegenüber der CPU
zu geben. Er klaut dann Bandbreite vom Speicher, braucht 12,5 MHz davon,
und minus Blanking nur zu <80% der Zeit. Ist also zu verschmerzen.
Ich habe mir schon einige Gedanken gemacht, wie man den LCD-Controller
realisieren könnte. Das Bitplane-Konzept möchte ich unbedingt
beibehalten, für schnelles unabhängiges Zeichnen. Um das flexibler zu
haben stelle ich mir 16 Hardwareregister für die Planes vor, in die man
SRAM-Startadresse und den 9bit-Farbwert reinschreibt. Das paßt zusammen
in 32 Bit. So kann man eine offscreen-Bitplane durch einfaches Umsetzen
des Registers sichtbar machen, muß den Inhalt nicht umkopieren.
Der Controller muß dann diese 16 Planes reihum als Busmaster lesen, um
einen neuen Satz Worte für Schieberegisterwerte bereitzustellen, während
die bisherigen pixelweise mit der LCD-Clock rausgeschoben und die Farbe
bestimmt wird.
Die SPI-Ketten für Tastatur, Drehgeber, LEDs und onboard-Outputs sind
dagegen vermutlich vergleichsweise einfach zu implementieren. Da haben
wir ja auch gleich mehrere Designs zur Auswahl, zum Abgucken.
Das FPGA hat 4 PLLs. Die sind für die 4 um 90 Grad phasenverschobenen
ADC-Clocks (4*250 MHz) leider schon aufgebraucht. Ich habe aber gesehen,
daß man mit einer PLL nebenbei auch noch andere Frequenzen erzeugen
kann. Bei Wittig geschieht das für den LA-Teil, der noch 100 MHz
bezieht. Das ist sogar recht fein einstellbar, in Schritten von wenigen
MHz. Wir könnten unser neues Nios-System also feintunen.
Und wenn's dann soweit ist würde ich vorschlagen die Capture-Unit von
Alex einzubauen. Die erscheint mir wesentlich ausgefeilter. Geringere
Zeitauflösungen werden durch weiterhin hohe Abtastrate und Filterung
erzeugt, statt durch einfach langsamere Abtastung. Zudem funktionieren
die Werte und der Trigger. ;-)
Soviel zum nächsten made-from-scratch Ansatz...
Ach ja, die Software. Ein neuer Bootloader muß her, keine Ahnung ob
Altera da auch sowas wie den GERMSloader für Nios II anbietet, wo man
nur noch UART-Adresse, Tasten-Override und Flash-Routinen anpassen muß.
Von mir aus muß der gar nicht soviel können, lediglich das Flash
anspringen oder auf Tastendruck in einen Modus gehen der vom UART ein
Stückchen Code entgegennimmt und ausführt.
Mein UCL-Loader war ja auch mal in C. Aber der muß es wegen mir nicht
sein, reicht auch "im Nachgang". Zumal es ihn in 2 Versionen gibt, für
RAM und Flash. Der Bootloader sollte möglicht klein sein, spart Block
RAM im FPGA, was ich lieber für Capturing einsetzen würde. Statt 16 kB
müßten eigentlich auch 24 kB pro Kanal möglich sein, dummerweise keine
Zweierpotenz, gibt krummere Zähler.
So long
Jörg
Klingt wirklich alles ganz interessant und vor allem realisierbar.
Etwas FPGA Erfahrung und einen "Spieloszi" habe ich, um etwas von Deinen
Ideen umzusetzen.
Zur Software, den GERMS-loader gibts in dieser Form soweit ich weiß für
NIOS II nicht, allerdings müsste sich der vorhandene Portieren lassen.
Es gibt wohl auch die Möglichkeit den NIOS direkt aus dem
Konfigurations-Flash booten zu lassen, dort ist ja noch Platz vorhanden
denn für den FPGA brauchen wir nur 6 von den 16Mbits.
Gruß Fritz
Realisierbar klingt gut!
Fritz, hast du meine PM von wegen Skype-Gruppe erhalten?
Ich habe mit Kollegenhilfe zum Ausprobieren ein frisches Minimalsystem
mit dem Nios-II aufgesetzt, siehe Anhang. Da sind mal nur die benötigten
(?) Dateien drin, die Pinbelegung von Wittig, .sopc File (also den SOPC
Builder erstmal den ganzen Wahnsinn generieren lassen), die 4 PLLs, ein
Toplevel in Verilog und (neu!) ein .sdc File mit Angaben zur
Taktversorgung drin, damit Quartus uns sagen kann wie das denn so
klappt.
Es hat die gleiche Memory-Map wie unser Nios32-Design. Es enthält die 3
Memories (Boot, SRAM, Flash), 3 Timer, 2 UARTs. Das täte für ein "Hello
World" mehr als ausreichen. Die ganzen Ports sind mit Absicht noch nicht
dabei.
Den Nios takte ich aus einer PLL mit derzeit 1/3 ADC-Clock, also 83,3
MHz. Die Timinganalyse sagt wir könnten bis etwa 90 MHz. Nicht schlecht,
finde ich!
Ob's auch läuft weiß ich nicht. Dazu müßte man Software schreiben, den
Flow kenne ich noch nicht...
Jörg
Ein "Hello World" sollte ich dem schon entlocken können.
Zumindest wurde Dein Design schon übersetzt. Was mir auffiel, ich glaube
man braucht unbedingt noch eine sysid komponente im NIOS II.
Außerdem sollten die unbenutzten Pins nicht zwangsweise auf GND liegen,
das kann man beim Device->"Device und Pin Options" einstellen.
So long
Fritz Richter schrieb:> Zumindest wurde Dein Design schon übersetzt. Was mir auffiel, ich glaube> man braucht unbedingt noch eine sysid komponente im NIOS II.
Ist das dies Zahl beim Nios-Erstellen, die Standardmäßig Null ist? Ach
nee, die heißt cpuid. Gegoogelt: Den Check darauf kann man wohl auch
ausschalten:
http://www.alteraforum.com/forum/showthread.php?t=17705> Außerdem sollten die unbenutzten Pins nicht zwangsweise auf GND liegen,> das kann man beim Device->"Device und Pin Options" einstellen.
Das hatte ich gemacht, habe auch schon von der Unart des
Default-Verhaltens gehört. War wieder verschwunden? Tss...
Jörg
Dank Fritz' Hilfe:
Gestern lief ein erstes "Hello World" auch bei mir auf dem frischen
Nios-II System. Sehr spannend, das alles.
Mit 83 MHz und dem externen SRAM kommt er anscheinend klar.
Stay tuned...
Jörg
Sehr spannend!
Ich verfolge das hier natürlich die ganze Zeit mit, bin aber noch zur
Untätigkeit verdammt da bei mir nur ein Notsystem läuft.
Etwas Offtopic zwar, aber ich hab die ursprünglich bestellte Festplatte
(Amaz...) jetzt nach 3 Wochen storniert und bei einem kleineren Händler
eine andere bestellt die nach 1 Tag da war!!! Jetzt bin ich dabei zu
formatieren und zu kopieren. Hoffe ich bin bald wieder am Ball...
Hayo
Hallo allseits,
ich war schon eine ganze Weile nicht mehr welecmaessig unterwegs.
Beeindruckend was ihr alle auf die Beine gestellt habt. Hut ab!
Joerg hat ja ganz schoene Impulse mit seinem Neuansatz gebracht.
Die Quartus-Sourcen sind schon interessant. TomCat-CII.fit.summary siehe
Anhang zeigt den Resourcenverbrauch im FPGA. Ist noch was frei, vor
allem bei den Multipliern. Nios2 ist ja wesendlich sparsamer beim
Resourcenverbrauch im FPGA was auch wieder was frei machen sollte.
Ausserdem muss auch noch entschieden werden, welcher der 3 Nios2-Typen
genommen wird.
In TomCat-CII.pin steht das genaue Pinning. Einige sind NC. Frage ist,
ob sie auf dem Board auch kein Ziel haben.
Vielleicht rueckt ja Joergs Sourcenquelle auch die Schaltplaene raus.
Traeumen darf man ja ;-)
Fritz Richter schrieb:> Zur Software, den GERMS-loader gibts in dieser Form soweit ich weiß für> NIOS II nicht, allerdings müsste sich der vorhandene Portieren lassen.> Es gibt wohl auch die Möglichkeit den NIOS direkt aus dem> Konfigurations-Flash booten zu lassen, dort ist ja noch Platz vorhanden> denn für den FPGA brauchen wir nur 6 von den 16Mbits.
Da hat er recht. GERMS wird nicht mehr bei Nios2 unterstuetzt. Es gibt
zwar eine von Altera nicht unterstuetzte Portierung bis Quartus6, aber
das wars.
Machen wir halt alles ueber USB. Dann koennen wir uns auch die RS232
sparen oder fuer etwas anderes nutzen. Hat schon einer kuerzlich den
'USB Blaster on the FX1' zum Leben erweckt?
Den Nios wuerde ich auch aus dem SPI-Flash mit Daten versorgen, denn
drin ist er da ja eh schon. Das Flash koennte man ja auch auf 64MBit
aufbohren, natuerlich nicht mit einem ECP64 von Altera. Leicht zu
Loeten, da 0.8er Pitch.
Gibt es eigentlich noch Rohleiterplatten von den neuen Eingangsstufen
V1.4.?
Gruss, Peter
Auch hallo!
> Die Quartus-Sourcen sind schon interessant. TomCat-CII.fit.summary siehe> Anhang zeigt den Resourcenverbrauch im FPGA. Ist noch was frei, vor> allem bei den Multipliern. Nios2 ist ja wesendlich sparsamer beim> Resourcenverbrauch im FPGA was auch wieder was frei machen sollte.> Ausserdem muss auch noch entschieden werden, welcher der 3 Nios2-Typen> genommen wird.
Keine Frage, den schnellsten, die Variante /f.
Der ist etwa genausogroß wie der alte Nios32, mit ein paar Extras kann
er noch wachsen. (Mit Fließkommaeinheit um ca. Faktor 1,5...)
Der nächstkleinere ist nur halb so schnell und wenig kleiner, warum
sollten wir uns das antun? Und der ganz kleine leistet gar nur 1/10.
Das der alte Nios keinen Multiplikationsbefehl konfiguriert bekommen hat
war einfach blöd. Den hätte es quasi gratis gegeben.
> In TomCat-CII.pin steht das genaue Pinning. Einige sind NC. Frage ist,> ob sie auf dem Board auch kein Ziel haben.
Da Slog genau das gleiche rausgemessen hat habe ich da wenig Hoffnung.
Siehe mein Posting dazu mit Pin-Excel weiter oben.
> Vielleicht rueckt ja Joergs Sourcenquelle auch die Schaltplaene raus.> Traeumen darf man ja ;-)
Liegen leider nicht vor, wenig Hoffnung.
> Da hat er recht. GERMS wird nicht mehr bei Nios2 unterstuetzt. Es gibt> zwar eine von Altera nicht unterstuetzte Portierung bis Quartus6, aber> das wars.> Machen wir halt alles ueber USB. Dann koennen wir uns auch die RS232> sparen oder fuer etwas anderes nutzen. Hat schon einer kuerzlich den> 'USB Blaster on the FX1' zum Leben erweckt?
Mit 32Bit-Windows hatte ich den Slog-Treiber verwendet.
Um USB schnell zu kriegen bedarf es einer neuen FX-Firmware. die
derzeitige spricht an 2 GPIO-Pins des FX1 57600 Baud. Ob es der 8051 da
drin auch schneller schafft weiß ich nicht.
Die RS232 ist momentan unser schnellstes Interface. In meinem neuen
Nios-II System erlaube ich auch höhere Baudraten als 115200, der
Pegelwandler kann noch mindestens das doppelte.
> Den Nios wuerde ich auch aus dem SPI-Flash mit Daten versorgen, denn> drin ist er da ja eh schon. Das Flash koennte man ja auch auf 64MBit> aufbohren, natuerlich nicht mit einem ECP64 von Altera. Leicht zu> Loeten, da 0.8er Pitch.
Wir haben aber auch 8 MB paralleles Flash...
Das mit dem Booten aus EPSC-Flash ist nach aktuellsten Erkenntnissen
doch kein Vorteil. Wir dachten wir sparen RAM im FPGA, aber dort wird
trotzdem eines angelegt, beim Booten mit dem EPSC-Inhalt beschrieben.
Jörg
Hi nochmal,
am Wochenende habe ich viel mit dem SOPC-Builer von Altera
herumprobiert, wie man das neue Nios-System schnell kriegt. Habe einiges
gelernt. Mein schneller neuer PC durfte sich endlich mal an was
rechenintensivem austoben, hat das FPGA zig Mal synthetisiert.
Bei den Vorbereitungen für den LCD-Controller hatte ich erstmal einen
Schreck bekommen. Der zusätzliche Busmaster und ein testweiser
DMA-Controller haben unsere Performance auf ca. 60 MHz gedrosselt, wohl
durch die vielen neuen Verbindungen in der Busmatrix.
Nun habe ich gelernt, das in zwei Teile zu teilen, einen möglichst
schnellen für nur das allernötigste (Prozessor, RAM, LCD), und einen
langsamen (25 MHz) für das ganze Peripheriegedöns und auch das Flash.
Dazwischen kommt eine "clock crossing bridge".
Außerdem kostet der JTAG-Debugger recht viel, weil der sich auch überall
anschließt. Im Moment brauchen wir ihn aber, weil wir noch keine andere
Möglichkeit haben da Software reinzubringen. Später könnten wir eine
langsamere Debug-Version für Entwickler bauen und eine schnellere für
User, ohne JTAG.
Ohne LCD synthetisiert das Nios-System mittlerweile für ganz knapp 100
MHz. Also habe ich mal mutig die PLL auf 100 MHz gestellt und das Hello
World ausprobiert. Klappt aber nicht, das ist wohl doch zu schnell für
den externen Bus. Ich kriege einen "verify error" beim Laden des
Programms. Eine Stufe langsamer ist 93,8 MHz, das funktioniert noch.
Hier ist also wohl das Ende unserer Fahnenstange. Aber von 12,5 MHz
kommend nicht schlecht, oder?
Anbei das aktuelle Design. Ja, ich sollte es besser in svn einschecken.
Uns fehlt noch ein Konzept zur Verzeichnisstruktur.
Im schnellen Teil vom Bus habe ich einer Empfehlung folgend die
Basisadressen so vergeben, daß sie sich bereits durch das MSB
unterscheiden. Dann wird der Adreßdekoder sehr einfach, es ist einfach
das Bit. Das kann auch Geschwindigkeitsvorteile bringen. Unsere
Memory-Map ist nicht mehr kompatibel, aber warum sollte sie auch?
Ich habe ein paar PIOs für Tasten, SPI, Drehgeber etc. recht freihändig
vergeben. Sind weniger als vorher, dafür etwas breiter. Denn da können
wir bei der Gelegenheit auch aufräumen, warum soll jeder Fitzel seine
eigene 1 Bit breite PIO haben? Das ist aber bei Bedarf leicht
anzupassen, ist jetzt eher ein Platzhalter.
Ich verwende den SOPC Builder, nicht das neue Qsys. Der Grund dahinter
ist das unsere Nios-Lizenz in der Firma auf Quartus 9 läuft, da gab es
noch kein Qsys. Man kann das SOPC Design aber auch in Qsys laden und
ggf. dort weiterarbeiten. Das habe ich auch ausprobiert (Qsys soll laut
ALtera ja soo viel besser sein, das neue Persil...), aber es war kaum
ein Unterschied, vielleicht 0,5 MHz schneller, das kann aber auch die
Streuung der Anfangsbedingung sein. Auffällig ist das Qsys selbst viel
langsamer arbeitet, die Erzeugung dauert ziemlich.
So long,
Jörg
Hallo!
Nach langer Abwesenheit melde ich mich wieder mal zum FPGA Thema zu
Wort:
@Jörg
Das meiste wird dir bekannt sein, bitte sehen meine Ratschläge zum neuen
NIOSII FPGA-Design als Checkliste ansehen.
Niemals auf den JTAG verzichten, mit dem kann man auch nette
Firmware-Updates machen + man könnte ihn eventuell zur
Datenkommunikation missbrauchen.
Grundsätzlich keine FPU verwenden!
Grund: macht den Rest langsamer!
Division braucht man auch nicht wirklich (Schiebebefehl).
Program Cache maximieren, Daten Cache vorsehen.
SRAM Zugriff schnell machen, da dies der Flaschenhals jedes CPU-Systems
mit Framebuffer VGA ist (Pipelining).
Der SRAM des Welec verhält sich sehr eigenartig:
CS des SRAM unbedingt auf Aktiv low belassen (, solange man nicht mit
dem anderen FPGA sprechen möchte!).
Überprüfen ob die Byte Write Zugriffe funktionieren:
sprintf("%x",0x11223344)
@Jörg
Auch wenn es für dich sehr hart ist: Mache dich mit dem Gedanken
vertraut, den Code im SRAM auszuführen, ansonsten wird dir warscheinlich
das Oszi performancemäßig einschlafen.
Schneller Bus:
Slaves:
SRAM, FLASH, SignalSpeicher (Blockram im Trigger-ea.vhd)
Master:
NIOSII, VGA-Master, DMA (, JTAG)
Der Rest kommt in den langsamen Bus!
MfG
Alexander
alex008 schrieb:> Hallo!>> Nach langer Abwesenheit melde ich mich wieder mal zum FPGA Thema zu> Wort:
Willkommen, @all: Alex war gestern auch im Chat, was denke ich zum
jetzigen Zeitpunkt sehr nützlich ist.
> @Jörg> Das meiste wird dir bekannt sein, bitte sehen meine Ratschläge zum neuen> NIOSII FPGA-Design als Checkliste ansehen.
Danke, in Folge noch ein paar Kommentare.
> Niemals auf den JTAG verzichten, mit dem kann man auch nette> Firmware-Updates machen + man könnte ihn eventuell zur> Datenkommunikation missbrauchen.
Er kostet uns aber ca. 10 MHz Performance. Ich würde ihn nur in der
Developerversion drinlassen. Dort ist er in der Tat sehr nützlich.
Firmware-Updates sollen wie gehabt über den Bootloader laufen, finde
ich.
Zur schnellen Datenkommunikation habe ich den RS232 entdrosselt, mal
schauen was der zu 2x...8x mal 115200 Baud sagt. Ganz aktuell ist nun
auch ein UART mit FIFO drin.
> Grundsätzlich keine FPU verwenden!> Grund: macht den Rest langsamer!
Ich habe es ausprobiert: Das tut sie in der Tat, aber ist nicht so wild,
etwa 3 MHz. die CPU wird aber 50% größer. Wenn wir aus irgendwelchen
Gründen eh Tempo rausnehmen müssen wäre die FPU ggf. drin.
> Division braucht man auch nicht wirklich (Schiebebefehl).
Habe ich auch ausprobiert, der Divisionsbefehl hat keine Nachteile.
Aktuell ist er drin.
Die Software würde derzeit allerdings von beidem nicht profitieren. Es
ist in keiner inneren Schleife eine Division oder gar Fließkomma. Soll
hoffentlich auch so bleiben.
> Program Cache maximieren, Daten Cache vorsehen.
Weil unser SRAM so schnell ist habe ich die Caches minimiert, 512 Bytes
für Code (ohne geht nicht), kein Datencache. Hintergrund ist das ich
gern den Samplespeicher von 16K/Kanal auf eher 24K/Kanal vergrößern
würde. Dazu muß man beim Rest extrem sparsam sein, nur noch 9 RAM-Blöcke
wären dann übrig. Braucht deine Filterung welche?
> SRAM Zugriff schnell machen, da dies der Flaschenhals jedes CPU-Systems> mit Framebuffer VGA ist (Pipelining).> Der SRAM des Welec verhält sich sehr eigenartig:> CS des SRAM unbedingt auf Aktiv low belassen (, solange man nicht mit> dem anderen FPGA sprechen möchte!).
Scheint ohne besondere Maßnamen zu funktionieren. Ein genauerer
Speichertest steht noch aus. Wir haben mit dem Avalon auch ein anderes
Bussystem, andere Komponenten.
> @Jörg> Auch wenn es für dich sehr hart ist: Mache dich mit dem Gedanken> vertraut, den Code im SRAM auszuführen, ansonsten wird dir warscheinlich> das Oszi performancemäßig einschlafen.
Das ist keine Härte, sondern schon immer so gelaufen.
Ich hatte im Hinterkopf, unkritische Codeteile im üppig großen Flash
laufen zu lassen, falls es im SRAM eng wird.
> Schneller Bus:> Slaves:> SRAM, FLASH, SignalSpeicher (Blockram im Trigger-ea.vhd)> Master:> NIOSII, VGA-Master, DMA (, JTAG)>> Der Rest kommt in den langsamen Bus!
Ich bin noch weiter gegangen und habe auch das Flash am langsamen Bus.
Den DMA-Controller habe ich mir auch vorerst verkniffen, der kostet uns
derzeit heftige 20 MHz. Eine kleine Assembler-Kopierschleife im Cache
der CPU ausgeführt ist vermutlich fast genauso schnell.
Auf das Sample-RAM muß man über extern zugreifen können, von daher kommt
es wohl auch nicht an den schnellen Bus. Ich habe noch keine Ahnung, wie
das zu bewerkstelligen ist.
Im Moment bin ich am LCD-Controller dran. Er kann bereits das Timing
generieren, auf dem Schirm sind aber noch keine Daten sondern eine feste
Farbe.
FPGA-Mitstreiter sind herzlich willkommen!
Grüße
Jörg
Ein paar Updates:
Ich habe das neue FPGA-Design jetzt bei Sourceforge ins svn eingecheckt.
Besser als hier Zipfiles posten, gell?
Die Verzeichnisstruktur habe ich soweit mir möglich aufgeräumt, was geht
in Unterverzeichnisse, weil Quartus das Projektverzeichnis zumüllt.
Es gibt eine Wiki-Seite zu unserem neuen Projekt:
https://sourceforge.net/apps/trac/welecw2000a/wiki/niosII
Mit dem LCD-Controller geht es voran. Ich habe ihn der Übersichtlichkeit
halber in 3 Teile geteilt, für Pixel- und Sync-Erzeugung,
Programmierregister und DMA-Speicherleser. Letzterer ist noch nicht
fertig.
Jörg
Hallo Jörg!
RAM-Blöcke:
Ja, meine Filterung braucht diese FPGA internen RAM-Blöcke.
Auswendig weiß ich das leider nicht mehr.
1GS/s->100MS/s keine
100MS/s->10MS/s ????
10MS/s->1MS/s + darunter:
sollte jeweils ein Block-RAM pro Kanal sein und ist konfigurierbar.
Siehe Utilisation by Entity im Quartus Map? Report.
Den Sample-Speicher von 16 kB auf 24 kB zu erweitern sehe ich als nicht
sinnvoll an.
Stattdessen sollte ein ein intelligienter DMA mit höchster Priorität die
Daten vom Samplepuffer in den externen SRAM schreiben.
Das könnte theoretisch vielleicht sogar bis 20 MS/s gehen.
Hast du schon mal ein printf("%d ",12345678) ausprobiert?
Damit kannst du sichergehen, dass die Grafikfehler eines deiner Bilder
nicht von fehlerhaften Halfword- oder Byte-Write- SRAM-Zugriffen kommt.
Solche Fehler führen nur sehr selten zu einem Absturz, da die Pointer
bei 32 Bit Systemen 32 Bit groß sind.
Wie viele LUTs verbraucht nun das Design mit dem NIOSII ohne FPU?
Das LEON3 Design hat ca. 17000 gebraucht.
Davon hat mein Teil über 7000 LUTs ausgemacht.
Grund meiner Frage ist, dass je nach Design und FPGA das ganze ab einer
bestimmten größe (1/3 bis 1/2) der FPGA Kappazität viel langsamer wird!
Zweitens bin ich mir nicht sicher, wenn du meinen Signalerfassungsteil
verwenden möchtest, dass eine Verwendung von ungleich 2^n Bytes für den
Signaldaten-Speicher leicht zu bewerkstelligen ist.
Da wäre schon sinnvoller das auf die wahnsinnig performante ZynQ
Plattform oder die vergleichbare Cyclone V SOC zu bringen.
Der ZynQ hat glaube ich noch einen zweiten DDR3? RAM Controller für den
FPGA Bereich (DDR3 Samplespeicher :-) ).
Übrigens gibts für die Teile schon preiswerte Tochterboards mit SRAM und
FLASH.
Alexander
Etwas offtopic, passt aber gut hier rein.
Offenbar haben sich die Jungs von Wittig noch nicht vollständig aus dem
Scope-Geschäft zurück gezogen, wie ein aktueller Artikel aus der
Elektronikpraxis beweist:
http://www.elektronikpraxis.vogel.de/messen-und-testen/articles/374429/
Zitat:
"... Das Open-Source-Oszilloskop misst 76 mm x 84 mm und ist für 59 Euro
plus Mehrwertsteuer direkt bei Wittig zu beziehen..."
branadic
...und alles open source! Das ist doch mal ein Ansatz!
Software, Schaltplan...
Ob da finanziell viel hängen bleibt? Produktion in China und Versand
nach D, aber die Bauteile sind auch nicht ganz zum Nulltarif (A/D
Wandler, Display...)
Gruß, Brunowe
Hallo,
das mit der Produktion ist ne echt eigenartige Sache. Wer das Ding als
letztes in der Hand hatte und daran produktiv tätig war, kann seinen
Staat als Produktionsstätte angeben. Evtl. wurde in Italien noch ein
Schutzlack auf die Platinen aufgebracht oder ein Käbelchen angelötet.
Glaubt mir, das ist gar nicht so selten. Ich arbeite in einem
EMV-Prüflabor und hab öfter mit so einem Vorgehen zu tun.
Gru0, Brunowe
Hallo liebe Leut',
ich bin aus dem Urlaub wieder da. Vor ein paar Stunden gelandet, leicht
zeitverschoben und gaaanz müde...
Schnell noch ein paar Anmerkungen zu Alex:
alex008 schrieb:> Den Sample-Speicher von 16 kB auf 24 kB zu erweitern sehe ich als nicht> sinnvoll an.
Schade, ein bischen mehr hätten wir uns noch leisten können. Zugegeben
wird die Adressierung komplizierter.
> Stattdessen sollte ein ein intelligienter DMA mit höchster Priorität die> Daten vom Samplepuffer in den externen SRAM schreiben.> Das könnte theoretisch vielleicht sogar bis 20 MS/s gehen.
Aber leider nur für Kanal 1+2, nicht für das 2. FPGA bei den 4Kanälern?
Zumindest fällt mir nichts ein, wie man das vernünftig lösen könnte.
FPGA1 liefert die Adressen, FPGA2 die Daten? Ginge nur mit dem
25MHz-Clock, weil den beide FPGAs haben. Display und CPU wollen aber
auch dran.
> Hast du schon mal ein printf("%d ",12345678) ausprobiert?
Noch nicht, im Moment kriege ich noch gar nichts hin... Hoffentlich nur
Anlaufschwierigkeiten.
> Damit kannst du sichergehen, dass die Grafikfehler eines deiner Bilder> nicht von fehlerhaften Halfword- oder Byte-Write- SRAM-Zugriffen kommt.
Soweit bin ich noch nicht, "eigene" Grafikfehler zu produzieren. ;-)
Der Pixelsturm war mit dem Welec-Design.
> Solche Fehler führen nur sehr selten zu einem Absturz, da die Pointer> bei 32 Bit Systemen 32 Bit groß sind.
Lesen sollte eigentlich immer gehen, weil er das nur 32bittig macht und
intern maskiert. Beim Schreiben wird es spannender, ob man die Byte
Enables richtig verdrahtet hat.
> Wie viele LUTs verbraucht nun das Design mit dem NIOSII ohne FPU?> Das LEON3 Design hat ca. 17000 gebraucht.> Davon hat mein Teil über 7000 LUTs ausgemacht.
Hui. Der Nios II ist etwa halb so groß.
Mein LCD-Controller wird allerdings auch einiges brauchen, alleine 1024
Flipflops, für die 16 Schieberegister der Planes und weitere 16
Prefetch-Register (alle 32 Bit breit).
> Grund meiner Frage ist, dass je nach Design und FPGA das ganze ab einer> bestimmten größe (1/3 bis 1/2) der FPGA Kappazität viel langsamer wird!
Davor habe ich auch schon Angst. Vielleicht helfen Layout-Tricks wie
diese LogicLocks.
> Da wäre schon sinnvoller das auf die wahnsinnig performante ZynQ> Plattform oder die vergleichbare Cyclone V SOC zu bringen.> Der ZynQ hat glaube ich noch einen zweiten DDR3? RAM Controller für den> FPGA Bereich (DDR3 Samplespeicher :-) ).> Übrigens gibts für die Teile schon preiswerte Tochterboards mit SRAM und> FLASH.
Mit anderer Hardwareplattform ist natürlich einiges möglich. Mein Ziel
ist aber, das Welec so wie es ist (mit ggf. kleineren Mods) auszureizen.
Ein neues Mainboard dafür zu bauen ist zwar auch interessant, hätte z.B.
eine Chance die Analogprobleme lösen, aber wäre teuer und hätte nur eine
sehr kleine Nutzerbasis.
So long
Jörg
Hallo Jörg!
Jörg schrieb:
> Aber leider nur für Kanal 1+2, nicht für das 2. FPGA bei den 4Kanälern?> Zumindest fällt mir nichts ein, wie man das vernünftig lösen könnte.> FPGA1 liefert die Adressen, FPGA2 die Daten? Ginge nur mit dem> 25MHz-Clock, weil den beide FPGAs haben. Display und CPU wollen aber> auch dran.
Man muss nicht ubedingt den ursprünglichen 25 MHz Takt für den
Datenaustausch zwischen den FPGAs verwenden. Ich gehe davon aus, dass
eine Taktviertelung über Strobesignale ausreicht um den Datenaustausch
zwischen den FPGAs zum laufen zu bringen.
Ausserdem sind alle gleichfunktionierenden Takte des zweiten FPGAs zu
zum ersten synchron, da sie ja aus dem selben Ursprungsquarz abgeleitet
werden.
Da würde es dann reichen, wenn man ein einfaches Togglesignal nimmt, bei
dem man bei der steigenden Flanke liest und bei der fallenden schreibt
(so wie bei dem SPI).
Vielleicht funktioniert das auch ohne Taktviertelung (, falls die
Verzögerungszeit zwischen den Register der FPGAs höher ist, als deren
PLL-Jitter -> 2*200 pS)!
MfG
Alexander
Hallo Alex & alle,
Danke für deinen Beitrag. Stimmt, die PLLs in beiden FPGAs laufen ja
halbwegs synchron, vielleicht läßt sich damit was anfangen. Ich hatte da
zuwenig Vertrauen. Das mit der Taktviertelung habe ich nicht verstanden,
wodurch entstünde die? Irgendwas geviertelt ist trotzdem schneller als
25 MHz?
Am Tristate Master des SRAM habe ich meinen schnellen Busclock von
derzeit 75-94 MHz. Die Gegenseite muß dann auch damit klarkommen, ich
weiß nicht ob und wie verschiedene Geschwindigkeiten möglich sind.
Wittig hat an diesen Bus noch andere Teilnehmer angeschlossen, nämlich
den Zugriff auf Capturespeicher und Konfiguration. So liest man da vom
eigenen FPGA oder vom anderen. Die Adressen sind anscheinend nicht
durchverbunden, deshalb gibt es da nur einen Auto-Inkrement.
Ich sehe noch nicht wie man einen weiteren Master von außen in das
andere FPGA kriegen würde. Und ich bin bestimmt zu begriffsstutzig das
hier abschließend zu klären, damit langweilen wir den Rest, besser bei
Gelegenheit im Chat. ;-)
So, nun an alle:
Ich freue mich gerade, daß ich am Wochenende meinen LCD-Controller zum
Laufen bekommen habe, mein erstes Design im FPGA. Das ging sogar relativ
problemlos, fast auf Anhieb.
Ähnlich zum Original liest er parallel aus 16 unabhängigen Bitplanes
(definierbar, könnten auch weniger sein) und legt die gewissermaßen
transparent übereinander. Jede Plane hat eine definierte Farbe, das
oberste gesetzte Pixel-Bit "gewinnt", das Pixel kriegt deren Farbe.
Im Unterschied zum Original sind die Startadressen und die Farben
programmierbar, können also zur Laufzeit herumjongliert werden.
Läuft erstmal, es gibt noch ein paar Dinge zu verbessern:
- Es sind noch Warnings drin über inkompatible Bitbreiten.
- Ich habe eine Idee wie ich die Hälfte der Flipflops einsparen kann,
wenn ich einen Memoryblock als FIFO einsetze. Dann muß ich Schieben und
Farbbestimmung vorher machen.
- Der VSync-Interrupt ist noch nicht da, ferner will ich in einem
Kontrollregister das Scanning abschaltbar machen.
Als ich mit dem Quartus-eigenen Logic Analyzer die Bustimings angeschaut
habe mußte ich leider feststellen, daß unser SRAM nicht mit 0 Waitstates
angesteuert wird, sondern mit 2. Es ist also 3 mal langsamer als
vermutet. Das ist ein ziemlicher Klotz am Bein, die LCD-Zugriffe lasten
es nun bereits zur Hälfte aus. Ich weiß noch nicht wo das herkommt, ob
es durch Multimaster und Arbitrierung passiert oder durch den
SRAM-Controller. Den hatte ich eigentlich schon mal überflogen und zuvor
nichts Bremsendes festgestellt.
Von diesen Optimierungen abgesehen wären als nächstes die SPI-Sachen
dran, LEDs, Drehgeber, Tasten. Ich suche auch noch, wo die Leitungen für
die ersten beiden Softkeys an das FPGA angeschlossen sind. Die haben
nämlich eine Sonderbehandlung, für den Reset/Bootloader. In den bisher
bekannten Pins tauchen sie nicht auf.
Soweit erstmal,
Jörg
Jörg H. schrieb:> Und ich bin bestimmt zu begriffsstutzig das> hier abschließend zu klären, damit langweilen wir den Rest, besser bei> Gelegenheit im Chat. ;-)
Hallo Jörg,
hallo Alex,
ich möchte Euch weiter ermuntern ... WIR LESEN GERNE MIT!
Welche Version von Quartus nimmst Du Joerg ? Aus den Quellen lese ich
die Version 9.1!
Ist das die Quartus II Web Edition Software Version 9.1 Service Pack 2
... ?
Da ich derzeit nur 4-Kanal-Versionen im Besitz habe, ist mir noch nicht
klar ob ich die FW über den Blaster dirket in beide FPGA's lade ... Als
ich die alte Welec-Version gesichert hatte, war nur einer zu sehen!
Wenn ich richtig auf der Platine gesehen habe, kann aber jeder einzeln
bespielt werden.
Gruß Andiiiy
Andiiiy schrieb:> Welche Version von Quartus nimmst Du Joerg ? Aus den Quellen lese ich> die Version 9.1!
Bei der Arbeit, ja. Das ist die Version, mit der die späteren Releases
entstehen würden, wegen Nios-Lizenz.
Zuhause verwende ich Version 11. Damit läuft der Nios nur eine Stunde im
Evaluierungsmodus, bzw. länger mit angeschlossenem Debugger. Zum
Rumbasteln reicht das.
Je nachdem welchen Stand ich gerade einchecke steht da also 9 oder 11,
nicht verwirren lassen!
> Ist das die Quartus II Web Edition Software Version 9.1 Service Pack 2> ... ?
Mag sein...
Wie das mit dem 2. FPGA laden geht weiß ich noch nicht. Wenn man das
Config-Flash sichert (*.jic oder *.pof) sind aber beide dabei.
Wo ich gerade tippe:
Ich weiß jetzt wo die Waitstates herkommen.
In dem Script unter
"ip/altera/nios2_ip/altera_nios_dev_kit_stratix_edition_sram/mk_sram.pl"
ist ein Check auf >50MHz, dann wird was eingefügt. Wenn ich den
SOPC-Builder bescheiße und dort als Memory-Clock weniger eingebe (die
Angabe ist eh rein informativ), dann kriegen wir 0WS, aber es funktiert
nicht richtig, weil das Read-Signal zu spät kommt.
Eine richtige Lösung dagegen habe ich aber noch nicht. Mir scheint,
Altera hat gar keinen "richtigen" Controller für asynchrones SRAM im
Sortiment. Die drehen nur die Bustimings so, das man ein SRAM zwar
direkt anschließen kann, es aber nicht optimal angesteuert wird.
Bei Gelegenheit schaue ich mal, ob man einen als Komponente bauen kann.
Betrachte ich aber als nicht vordringlich. Dürfte nicht so schwer sein.
Schreiben ist blöd, weil man da einen Puls braucht, passt nicht so ins
Taktraster. Ein halber Takt ist zu wenig, wenn man einen ganzen nimmt
muß man bei aufeinanderfolgenden Writes einen Waitstate erzwingen, damit
es auch ein Puls wird. Könnte zu verschmerzen sein, dürfte selten
auftreten.
Eher ärgere ich mich über die 2 noch nicht gefundenen Tasteneingänge.
Was kann man denn da machen, gibt es eine Art Durchklingeltool? Wenn ich
im Projekt unbenutzte Eingänge auf Masse ziehen lasse sind diese
Eingänge auch low. Fallen also in diese Kategorie.
Apropos Durchklingeln:
Ich würde da gern noch andere Tests machen, mag mir ein 2Kanal-User beim
Messen helfen, oder mir seine Hauptplatine ausleihen (ganzes Gerät muß
nicht)?
Beim 2Kanäler sind ja die Pads des 2. FPGA zugänglich. Ich würde gerne
testen, ob z.B. die Adressleitungen wirklich nicht angeschlossen sind,
oder read/write tatsächlich doch. Müßte teils im Betrieb erfolgen, was
knifflig ist, die FPGAs sind auf der Vorderseite. Ich habe mir
Verlängerungsleitungen für abgesetzten Betrieb gebastelt.
Außerdem hat Osoz ja noch ein Problem mit 2Kanälern, was ich nicht
debuggen kann.
Jörg
Hallo Jörg,
ich kann dir gerne meinen Zweikanaler (W2012A) zum Testen zur
Verfügung stellen. Ich werde sicher über längere Zeit nicht
dazukommen etwas damit anzufangen, lese aber immer noch begeistert
mit. Achso, der Powerschalter müsste ersetzt werden. :-(
Grüße, Guido
Guido, danke für das Angebot, du hast eine PM.
zum Stand der Dinge:
Eine der beiden Softkey-Leitungen habe ich nun (wieder)gefunden,
erinnerte mich dran, daß F2 im vorliegenden Design einen Reset auslöst.
Es ist also der dort als reset_n bezeichnete FPGA-Pin V14. Ich bringe
gerade meine Pinliste auf Vordermann.
Nun suche ich noch den anderen. Das ganze soll dem noch zu erstellenden
Bootloader dienen, damit der sich wie gewohnt komfortabel verhalten
kann.
Jörg
Ich war zu voreilig, es war nicht reset_n, sondern master_slave, Pin E9.
Der hat im Wittig-Design eine ähnliche Wirkung, weil beim Slave, dem 2.
FPGA, die CPU im Reset gehalten wird.
Die Pinnings sind doch noch recht unterschiedlich. Slog wußte es besser,
in seiner Liste stand das drin. Auch den 2. Softkey habe ich nun dank
Slog gefunden, im Wittig-Design heißt der noch clk_led, Pin AB12. Es ist
ein bischen durcheinander, Wittig hat später wohl noch ein paar Dinge
geändert.
Dummerweise wissen wir jetzt nicht mehr, wo der echte master_slave Pin
nun zu liegen gekommen ist. Mathias hat ein Boundary-Scan Tool, das
könnte helfen, in Verbindung mit der 2kanal-Platine. Gesucht ist ein
Pin, der am 1. FPGA auf high und beim 2. auf low liegt.
Nochmal zu den wiedergefundenen Softkeys:
Als kleine Änderung habe ich im FPGA-Toplevel den Reset mit den beiden
verodert. Drücken beider Softkeys gleichzeitig löst einen Reset aus, wie
gehabt. Die Leitungen liegen auch an einem Input-Port, so daß die
Software sie lesen kann. Dann kann ein Bootloader reagieren wenn eine
bestimmte noch gehalten ist. An der Baustelle könnte es also losgehen...
Jörg
Ein Update:
Jörg H. schrieb:> Läuft erstmal, es gibt noch ein paar Dinge zu verbessern:> - Es sind noch Warnings drin über inkompatible Bitbreiten.> - Ich habe eine Idee wie ich die Hälfte der Flipflops einsparen kann,> wenn ich einen Memoryblock als FIFO einsetze. Dann muß ich Schieben und> Farbbestimmung vorher machen.> - Der VSync-Interrupt ist noch nicht da, ferner will ich in einem> Kontrollregister das Scanning abschaltbar machen.
Die Sache mit dem FIFO habe ich jetzt eingebaut. Spart zum Preis eines
Memoryblocks etwa 512 Flipflops, plus/minus etwas Veränderung an der
Logik drumrum. Die Maximalfrequenz ist um ein paar MHz gestiegen.
Anscheinend hatte ich da einen kritischen Pfad gebaut.
Wenn da jemand mit RTL-Erfahrung mal draufguchen mag: der DMA-Teil
erscheint mir recht groß, ich sehe dicke Multiplexer. Vielleicht
entstehen die durch ein unbedarftes if() im HDL, vielleicht geht das
besser.
Auch habe ich die Programmierregister verändert: es sind nun getrennte
Register, mit denen Basisadresse und Farbe eingestellt werden. Das ist
für die Software einfacher, weil sie i.d.R. nur eines von beiden
verändern wird.
Die Komplexität der Hardware beeinflußt es quasi nicht.
Nun gucke ich nochmal auf das Thema Waitstates. Bin aber noch nicht
damit durch. Das IP für das RAM habe ich versuchsweise in unser Projekt
kopiert. Dort kann ich dann dran rumändern. Habe es statt für IDT71V416
etwas umgedengelt auf unser IS61LV51216 und experimentiere mit den
Timings.
Es ist ein sog. "Tristate Slave" (bzw. ein Script das einen erzeugt),
zum Anschluß hinter einen "Tristate Master". Man kann so mehrere Slaves
an einen Bus hängen. Das brauchen wir auch, nämlich für den Zugriff auf
das andere FPGA.
Dummerweise hat ein Tristate Slave keinen Zugriff mehr auf das
Wait-Signal. Das wird ihm bereits abgenommen, man konfiguriert bei der
Erstellung pauschal die gewünschten Waitstates, Quartus baut dann selbst
eine Logik dafür. Ich hätte es aber gern weniger pauschal, für read und
write unterschiedlicher, und je nach Vorgeschichte...
Eine Lösung wäre, auch den Tristate Master selbst zu bauen. Der kann das
definitiv noch selbst steuern. Dann müssen wir uns aber selbst "zu Fuß"
um die Sache mit dem 2. FPGA kümmern. Kann sein das man das eh besser
täte. Ist aber erstmal mehr Arbeit.
So long
Jörg
Hallo Jörg!
Falls du ein wenig mit der Suche nach dem Master/Slave Pin suchst:
Wieso nimmst du nicht einfach die Schieberegisterkette für die
Drehknöpfe, Taster + DACs her?
Wenn du da einen Mist beim DAC (lauter einser oder lauter nuller)
ausließt, könnte man doch darauf schließen, dass die SW am FPGA2 läuft.
Des weiteren könnte man die EMV Problematik verringern, indem man zwei
verschiedene FPGA Designs baut.
LCD DMA Controller optimierungen:
78 wire next_planeaddress;
79 assign next_planeaddress = datafetch_pulse || (loading &&
!waitrequest && (plane_load != PLANES));
80
81 wire all_reads_done; // when all plane reads are done
82 assign all_reads_done = loading && !waitrequest && (plane_load ==
PLANES);
Diese zwei Zuweisungen könnte man zwei Registerzuweisungen machen (extra
Pipeline-Stufe, die einiges zum umschreiben verlangt!).
if (reset_n == 0)
89 begin
90 loading <= 0;
91 end
92 else if (datafetch_pulse)
93 begin
94 loading <= 1; // set to active
95 end
96 else if (all_reads_done)
97 begin
98 loading <= 0; // in consequence, this de-asserts all_reads_done,
makes it a one cycle pulse
99 end
So sollte man keine HDL Code schreiben.
Eine Registerbeschreibung hat immer so auszusehen!
if (reset_n == 0)
begin
x = 0;
...
end
else
begin
if (y == 0)
x++;
else if (...)
begin
...
end
end
end
VHDL:
if reset_n = '0' then
x <= 0;
elsif rising_edge(clk) then
if (x != 0) then
x <= x +1;
elsif (...) then
...
end if;
end if;
Und das was sicher am meisten bringen wird.
164 if (next_planeaddress)
165 begin
166 load_address <= RAM_Base_Address | ((planeoffset[plane_load] +
reg_addrcount) << 2);
167 end
vor 164:
offset <= planeoffset[plane_load];
statt 166:
load_address(upper:middle+1) <= RAM_Base_Address(ub:mb+1);
load_address(middle:2) <= RAM_Base_Address(mb:2) | offset +
regaddrcount;
load_address(1:0) <= 0;
Bitte das nicht als funktionierenden Code ansehen, nur als Hilfestellung
für die Optimierung der Taktgeschwindigkeit. Das zusätzliche Offset
Register musst du anderswo ausgleichen!
Danach bist du die Verzögerung des Multiplexers los + kleinerer Addierer
+ weniger oder Verknüpfungen.
MfG
Alexander
Hallo Alex, danke für's Feedback!
> Falls du ein wenig mit der Suche nach dem Master/Slave Pin suchst:> Wieso nimmst du nicht einfach die Schieberegisterkette für die> Drehknöpfe, Taster + DACs her?> Wenn du da einen Mist beim DAC (lauter einser oder lauter nuller)> ausließt, könnte man doch darauf schließen, dass die SW am FPGA2 läuft.
Muß aber in Hardware passieren. Den Prozessor können wir nicht starten,
weil er nicht an Flash und RAM kommt.
> Des weiteren könnte man die EMV Problematik verringern, indem man zwei> verschiedene FPGA Designs baut.
Wenn's denn nicht zu erkennen geht bräuchte man zwei verschiedene
FPGA-Designs. Würde ich erstmal versuchen zu vermeiden.
> 79 assign next_planeaddress = datafetch_pulse || (loading &&> !waitrequest && (plane_load != PLANES));> 82 assign all_reads_done = loading && !waitrequest && (plane_load ==> PLANES);>> Diese zwei Zuweisungen könnte man zwei Registerzuweisungen machen (extra> Pipeline-Stufe, die einiges zum umschreiben verlangt!).
Du meinst das ist bereits zu viel Kombinatorik? Du hast gesehen das die
Terme verschieden sind?
> So sollte man keine HDL Code schreiben.> Eine Registerbeschreibung hat immer so auszusehen!>> if (reset_n == 0)> begin> x = 0;> ...
Du meinst, das ich nochmal extra begin-end um die die
nicht-reset-Bedingungen schreiben soll? Oder ist was Funktionales dran
faul?
Gut, kann ich machen.
> Und das was sicher am meisten bringen wird.> vor 164:> offset <= planeoffset[plane_load];
Du meinst, die Bestimmung des Offsets in einen anderen Takt auslagern?
Hmm, dann habe ich das Ergebnis einen später. Erfordert Umbau, muß mal
sehen wie das geht.
> statt 166:> load_address(upper:middle+1) <= RAM_Base_Address(ub:mb+1);> load_address(middle:2) <= RAM_Base_Address(mb:2) | offset +> regaddrcount;> load_address(1:0) <= 0;
So eine Zusammensetzung statt großem Oder hatte ich bereits versucht.
Das Design wurde nicht kleiner (oder sogar größer?). Anscheinend erkennt
die Synthese das bereits. Die Addition wird bestimmt nur so breit wie
die Operanden ausgeführt, beim Oder werden konstant auf Null stehende
Bits wohl auch erkannt.
Ansonsten:
Ich habe angefangen, einen neuen Speichercontroller zu schreiben, für
mehr Performance. Wir werden wohl ohne "echte" Waitstates auskommen,
brauchen aber Pipelining. Beim Lesen steht ein Datenwort erst nach 3
Takten zur Verfügung, aber derweil können bereits 2 weitere Lesezugriffe
angefangen werden.
Von Guido habe ich eine 2kanal Hauptplatine bekommen. Ich bin mühsam
alle alle 484 Pins des 2. FPGA durchgegangen, leider fast ohne neue
Erkenntnisse. Es ist kein Pins angeschlossen, der nicht schon bekannt
wäre. Die Pinreihe über FPGA2 ist wohl zum Test, an verschiedene Pins
angeschlossen die der nicht braucht (wären bei FPGA1 RAM-Leitungen).
Osoz habe ich auch drauf losgelassen, um zu schauen was für ein Problem
der mit 2kanälern hat. Nach ca. 20 Capture-Runden kommt einfach kein
Capture-Interrupt mehr, keine Ahnung warum. Diese Wittig-Capturelogik
ist ja leider ein Buch mit sieben Siegeln. Also auch da keine schnellen
Erkenntnisse.
Was ich aber rausgefunden habe: Hab' mich immer schon über die 3+3
leeren Footprints rechts und links unterhalb von FPGA2 gewundert (siehe
Bild). Je oben und unten ein 8poliger wie für ein Widerstandsarray, in
der Mitte ein dickerer.
Die Boards sind anscheinend für eine individuelle Kalibrierung der ADCs
zueinander vorbereitet. An den äußeren Pinreihen liegt von jedem der 16
ADCs der Pin REFADJ an. Damit könnte man die ADCs einzeln trimmen. Ich
weiß noch nicht was in die Mitte sollte, ein elektronisches 8fach Poti?
So long,
Jörg
oh man Jörg, jetzt hast du aber an der falschen Stelle gespart( :-) ),
ich habe eine 26 Zöller und kann das Bild kaum sichten...
Und es wird immer interessanter, Respekt!
Gruß Michael
Michael D. schrieb:> oh man Jörg, jetzt hast du aber an der falschen Stelle gespart( :-) ),> ich habe eine 26 Zöller und kann das Bild kaum sichten...
Ich hatte grad kein besser aufgelöstes Bild zur Hand. Das ist aus dem
Wiki, schnell gecropt und 2 Kringel reingemalt.
Jörg
Ich nehme alles zurück, habe auch nur das Pic und mir schon einen Wolf
nach was brauchbarem gesucht.
Selber habe ich jede Menge Pic's gemacht, natürlich von dem Teil nicht,
wie solls auch anders sein :-(((
Gruß Michael
Ich habe mal bei Digikey nach 8fach DACs in passendem Gehäuse gesucht:
Das fehlende Bauteil in der Mitte dürfte ein MAX5259 sein, Abmessungen
und Belegung passen.
Ich weiß noch nicht wo die Steuerleitungen hinführen.
Jörg
Jörg H. schrieb:> Ich weiß noch nicht wo die Steuerleitungen hinführen.
Jetzt weiß ich es:
- DIN und SCLK gehen über je einen Transistor an die bekannte, "große"
SPI-Chain, Data und Clock
- /CS geht an das FPGA, Pin E7, für den ersten DAC direkt, für den
zweiten über einen Inverter
- /LDAC geht an das FPGA, Pin V9
Die FPGA-Pins hatten bei Wittig schon so verdächtige Namen, so kam ich
drauf. Mit einem Testdesign im FPGA habe ich das nun überprüft.
Der Spaß kann also losgehen.
Jörg
Wenn keiner was schreibt muß ich halt alleine weiterbloggen...
MAX5259 ist bestellt, sollte hoffentlich bald eintrudeln. Vermutlich
kann man den DAC auch mit dem bestehenden Nios-Design ansteuern. Die
Kalibrierung ist aber nur für die Modi interessant, bei denen mehrere
ADCs arbeiten und deshalb zueinander kalibriert werden müssen. Genau
diese Modi sind im alten Design aber ziemlich kaputt, wie ihr ja wißt.
(Vertauschung, Spikes)
Zum neuen Design: (das kann noch lange nicht messen)
Heute habe ich die Vorschläge von Alex in meinen LCD-Controller
eingearbeitet. Er hatte per Skype seinerzeit geduldig meine Rückfragen
beantwortet. Nochmals danke an Alex, das er sich so tiefgehend damit
beschäftigt hat.
http://welecw2000a.svn.sourceforge.net/viewvc/welecw2000a/fpga/nios2/altera/ip/W2000_LCD_Controller/lcd_dma.sv?r1=676&r2=684
Nun sieht es da drin schon aufgeräumter aus. Ist nun nicht mehr mein
HDL-Erstlingswerk, sondern eher mein drittes...
Ich habe die Adressberechnung in 3 Pipelinestufen zerteilt. Etliche
Kombinatorik wurde einfacher, dann habe ich noch überflüssige
Bedingungen bei der Zuweisung der Ausgangsdaten gefunden.
Die Maximalfrequenz des Gesamtdesigns liegt nun etwa 5 MHz höher.
Entweder lag das an einem kritischen Pfad bei mir, oder an nun
gesunkener Komplexität.
Ansonsten schlage ich mich schon sehr lange mit meinem SRAM-Controller
herum. Das Ding steigt mir oberhalb von 75MHz beim Schreiben aus, obwohl
das eigentlich nicht sein kann. Lesen scheint zu gehen, und das ist
kritischer. (Schön zügig, jeder Takt ein Datenwort.)
Jörg
Das mit den zusätzlichen DAC's ist ja interessant. Ich hatte mich schon
immer gefragt, wie die diese Teile Baugleich bekommen. Ich hatte vor ca.
einem Jahr ein Oszi mit starken Spikes zu den Wittek-Brüdern gesendet.
Als dieser zurück kam, waren die wirklich weg. Gesehen habe ich auf dem
Board aber nichts. Wenn die die DAC's nicht einsetzten ... wie habe die
das dann gemacht?
To Jörg:
Sehr schöne Erfolge ... man(n) kann ja jeden Tag die Neuerungen lesen
und verfolgen ... ;-)
Wie testest Du denn den neuen FPGA-Inhalt? ... im Quartus ...oder hast
Du schon ein System geschlachtet ... und arbeitest mit Testprogrammmen
und NIOS2?
Grüße Andi
Hallo Andreas,
> Ich hatte vor ca.> einem Jahr ein Oszi mit starken Spikes zu den Wittek-Brüdern gesendet.> Als dieser zurück kam, waren die wirklich weg. Gesehen habe ich auf dem> Board aber nichts. Wenn die die DAC's nicht einsetzten ... wie habe die> das dann gemacht?
Ist es denn noch die gleiche Hardware, oder wurde evtl. die Hauptplatine
getauscht? Was für eine Hardwareversion hast du? (Mit der BF-Firmware
unter Utility -> About)
> Wie testest Du denn den neuen FPGA-Inhalt? ... im Quartus ...oder hast> Du schon ein System geschlachtet ... und arbeitest mit Testprogrammmen> und NIOS2?
Schon mit der echten Hardware. Schlachten braucht man da nix. Mit dem
Slog-Treiber braucht man das Gerät nicht mal öffnen.
Weil der unter 64Bit Windows nicht geht habe ich aber doch einen
"echten" USB JTAG Adapter (Byteblaster) im Einsatz, an der Hauptplatine
angesteckt.
So kann ich das FPGA mit meinem neuen Inhalt laden, Testprogramme für
den Nios 2 hinterher. Ist (derzeit, mit Absicht) flüchtig, beim nächsten
Einschalten ist wieder alles beim alten.
Jörg
PS: Ich mache endlich Fortschritte mit dem Speichercontroller. Später
mehr.
> Ist es denn noch die gleiche Hardware, oder wurde evtl. die Hauptplatine> getauscht?
Die Seriennummer war noch gleich... Nun ist mir nicht klar ob die das
Board getauscht haben und mir die alte SN eingespielt. Glaube ich aber
fast nicht.
> Was für eine Hardwareversion hast du? (Mit der BF-Firmware> unter Utility -> About)
Ich verwende beide Versionen ... 1C9.0L und 8C7.0E
> Mit dem Slog-Treiber braucht man das Gerät nicht mal öffnen.
Ja diesen hatte ich zum Auslesen/ Sichern des EPCS16 auch benutzt. Da
ich die 4-Kanal-Variante verwende, musste ich aber vorher eine Brücke
(Platinenjumper) schließen.
> Weil der unter 64Bit Windows nicht geht habe ich aber doch einen> "echten" USB JTAG Adapter (Byteblaster) im Einsatz, an der Hauptplatine> angesteckt.
Ja der USB-Blaster liegt auch noch vor mir und findet ab und an seinen
Einsatz ...
> So kann ich das FPGA mit meinem neuen Inhalt laden, Testprogramme für> den Nios 2 hinterher. Ist (derzeit, mit Absicht) flüchtig, beim nächsten> Einschalten ist wieder alles beim alten.
Mir war gar nicht bewusst, dass Du den FPGA-Inhalt flüchtig gestalten
kannst. Wie gehst Du denn dabei vor?
Ich verwende jetzt die selbe Quartusversion 11.0 wie Du. Nach einem Test
mit der Version 9.1 und doch vielen Fehler hatte ich mich dann
umentschlossen.
Leider war des UART-Modul noch eine Herausforderung, da dieser unbedingt
den Ausgabepfad C:\Dokumente verwenden wollte. Eine Kompilierung (der 1
Stundenversion) war aber später erfolgreich.
Andi
Andreas W. schrieb:>> Was für eine Hardwareversion hast du? (Mit der BF-Firmware>> unter Utility -> About)>> Ich verwende beide Versionen ... 1C9.0L und 8C7.0E
Du brutzelst das selber hin und her, deine nicht-mehr-Spikes sind also
unabhängig vom FPGA-Inhalt?
Interessant, dann muß da ja was in echter Hardware verändert worden
sein. Ich hoffe, dir fällt noch was auf?
> Mir war gar nicht bewusst, dass Du den FPGA-Inhalt flüchtig gestalten> kannst. Wie gehst Du denn dabei vor?
Ohne Nios-Lizenz geht es sogar nur so, es werden keine ROM-Files
erzeugt, sondern nur eine .sof Datei. Die kannst du mit dem Programmer
oder dem Signal Tap Logic Analyzer übertragen. Ich nehme nur noch
letzteren, weil ich in der Regel auch interne Signale angucken will.
(Merkwürdigerweise muß man da aber immer zweimal probieren, beim ersten
Mal tut er nix.)
> Ich verwende jetzt die selbe Quartusversion 11.0 wie Du. Nach einem Test> mit der Version 9.1 und doch vielen Fehler hatte ich mich dann> umentschlossen.
Mit 9.1 muß es aber auch passend gemacht werden, weil wir die auf der
Arbeit haben. Im .tcl von meinem SRAM-Controller müssen noch ein paar
inkompatible Zeilen raus, war beim LCD auch so.
> Leider war des UART-Modul noch eine Herausforderung, da dieser unbedingt> den Ausgabepfad C:\Dokumente verwenden wollte. Eine Kompilierung (der 1> Stundenversion) war aber später erfolgreich.
Komisch, hat bei mir auch unter Linux geklappt, ich wechsele da munter
hin und her.
Jörg
> Komisch, hat bei mir auch unter Linux geklappt, ich wechsele da munter> hin und her.
Da es bei Dir sofort ging, habe ich mir heute das Thema noch einmal
angesehen. Ja es liegt an den Pfadangaben im Windows. Bitte nutzt keinen
Pfad mit einem Leerzeichen ... da scheint es teilweise im Quartus zu
hängen.
Ich habe den Ordner direkt mal nach C:\NIOS2 geschoben ... und siehe da
es geht (auch nach dem löschen der UART's.v).
Mit dem Signal Tap Logic Analyzer kann ich noch nicht starten, da ich
zwar die Enwicklungsplattform sehe (durch den Slog-Treiber) aber noch
keinen FPGA. Es scheint so als ob ich erst wieder die genannte Brücke
schließen muss.
Andi
Ich wollte ja noch was zum Speichercontroller schreiben, der das SRAM
ansteuert:
Nach laaangem Getüftel kann ich das nun mit voller Geschwindigkeit ohne
Waitstates (nur Latenz für Pipelining), aber es ist knifflig und hat so
seine Kompromisse. Ich kann auch nicht gut testen, denn um mein
Speichertestprogramm laufen zu lassen brauche ich derzeit den JTAG, der
den Nios langsamer macht.
Ich brauche verschobene/verlängerte Hilfs-Takte:
Einen für die Datenübername beim Lesen, denn das SRAM tut uns nicht
unbedingt den Gefallen, die Daten passend zu einer normalen Clockflanke
gültig zu haben. Die Daten können/müssen 27ns nach Anlegen der Adresse
durch das FPGA übernommen werden. Solange dauert die Runde raus aus dem
FPGA, zum RAM, Zugriff (nominell 8ns) und wieder rein. Bei 75 MHz klappt
das gut, das sind 2 Takte. Aber je nach Taktrate ist da keine Flanke,
dann muß besagter Hilfsclock das in ein Register takten, von dem es
weiter übernommen wird. Das Spiel konnte ich testweise bis 125 MHz(!)
treiben (ohne CPU, nur LCD gucken), aber der Übernahmezeitpunkt wird
super-kritisch, im sub-ns Bereich. Die CPU lief stabil mit 94 MHz.
Der zweite Takt für den Schreibpuls. Den brauchen wir einmal pro Takt,
aber laut Datenblatt muß er mindestens 6.5ns breit sein. Man kann
kombinatorisch mit dem Takt verknüpfen, kriegt dann einen Puls mit
halber Zyklusdauer. Ab 75MHz wird der aber zu kurz. Dann brauche ich den
zweiten Hilfstakt, mit Duty Cycle > 50% und passender Phasenlage. Damit
geht auch das Schreiben mit 94 MHz, aber etwas instabil, ich habe das
noch nicht so genau eingestellt.
Im Moment habe ich noch die 2kanal Platine von Guido da. Ein kurzer Test
mit meinen Timings schlug fehl, vermutlich ist der Bus schneller weil
die Last des 2. FPGAs fehlt, und/oder Exemplarsteuung.
Für diese verschobenen Takte werden die PLL-Resourcen knapp. Wir haben 4
PLLs, mit je 3 Ausgängen. Derzeit erzeugt jede der PLLs einen der 4
verschobenen Quadraturclocks für die ADCs. Bei Alex zusätzlich noch
einen halb so schnellen, mit dem er seine Verarbeitung macht. Bleibt
noch je ein Ausgang frei für unsere Zwecke, aber wenn ich meine 3 Clocks
aus verschiedenen PLLs nehme stehen die nicht so wie sie sollen. Man
müßte das also anders belegen, könnte nachteilig für die
ADC-Taktqualität sein.
Fazit: 75 MHz für den Nios ist ein "sweet spot". Ihn so schnell zu
takten wie derzeit synthetisierbar ist möglich, aber das
Speicherinterface wird knifflig.
Jörg
Hallo Jörg,
tolle Arbeit die du da leistes.
Eines verstehe das nicht. 27ns für eine Runde. Was braucht da so lange?
8ns braucht das RAM. Dann haben wir noch 19ns. In der Zeit legt das
Licht 5,7m zurück. OK auf der Leiterkarte warscheinlich nur 2m. Also
sind es die Leitungslänge schon mal nicht. Sind die Bussteiber im FPGA
richtig eingestellt?
Michael
PS. Habe leider von der Materie zu wenig Ahnung um zu helfen.
Michael schrieb:> Eines verstehe das nicht. 27ns für eine Runde. Was braucht da so lange?
Kommt mir auch viel vor, ich weiß nicht. Die "fehlenden" 19ns sind für
raus und rein, pro Richtung also etwa 9 ns. Es gibt innerhalb des FPGA
natürlich Delays, und rückwärts ist vor dem Eintakten eine Setup-Zeit
einzuhalten. Was haben wir denn so, ein paar Werte habe ich versucht
nachzulesen:
- von Taktflanke bis es tatsächlich im Register ist: 0.3ns
- Routing vom Register zum Ausgang: je nachdem
- Geschwindigkeit des Ausgangs, in Konfiguration LVTTL 24mA: 3ns
- kapazitive Last am Ausgang macht ein Deratating: 60ps/pF
- ringing an unterminierten Leitungen?
- Jitter addiert sich zum worst-case: 0.5ns
Dann durch's SRAM, 8ns später in ähnlicher Weise von dort wieder zurück.
> Sind die Bussteiber im FPGA richtig eingestellt?
Ich denke schon, die sind auf maximalen Strom eingestellt. Vielleicht
macht weniger Strom aber auch weniger Ringing.
> PS. Habe leider von der Materie zu wenig Ahnung um zu helfen.
Da haben wir was gemeinsam... Ich frage nochmal die Kollegen.
Jörg
Ein paar Updates zu verschieden Themen:
Mit dem Speicherbus habe ich noch etwas experimentiert und einen
Kollegen konsultiert. Er kann sich vorstellen, das wir mit Reflexionen
auf den Leitungen zu tun haben, es daher die 27ns braucht bis sich die
Lage beruhigt hat. Die Topologie ist ungünstig: In der Mitte das FPGA,
nach links zum SRAM, nach rechts zum anderen FPGA, nirgendwo
Serienwiderstände oder Terminierung. Das ist halt nicht für high speed
gebaut, Wittig betreibt das mit 25 MHz. Versuchsweise habe ich mal die
Treiberleistung vom FPGA reduziert, in der Hoffnung wenige Geklingel zu
erzeugen. Wurde aber eher schlechter.
Seien wir also zufrieden mit 75 MHz, ist ja immerhin 6 mal schneller als
die alte CPU.
Dann ist ein CY7C64713 eingetroffen, das ist der USB FX1 Chip im Scope.
Mit dem will ich ein Bastelsystem aufbauen, um zu schauen was aus dem so
rauszukitzeln ist. Das ist aber ein Langfristprojekt, für später mal, es
sei denn es kümmert sich wer anders drum. Man könnte in das Scope evtl.
auch den pinkompatiblen FX2-Chip einlöten, für USB2-Speed...
Noch mehr Chips: Die Trim-Dacs sind da. Ich habe sie eingelötet und eine
Softwareansteuerung dafür geschrieben. Letzteres erfordert beim 4kanäler
einige Tricks, weil der 2. Chip ungünstig angeschlossen ist. Er bekommt
ein gegenüber dem ersten Chip invertiertes SPI Chip Select. Das führt
dazu das sich immer beide angesprochen fühlen, jeder auf einer Flanke.
Wenn ich anfange mit dem normal angeschlossenen zu "reden", dann meint
der verkehrte, die letzten 16 Bits auf dem Bus seien für ihn gewesen und
interpretiert die als Kommando. Ich muß ihm also vorher irgendwas
sinnvolles auf den Bus tun, ohne das sich sein Chip Select bewegt. Ich
mißbrauche dazu ein Dummy-Kommando an den Offset-DAC. Das hat 24 Bit,
ein NOP ist auch dabei, dann sind die unteren 16 Bit don't care und ich
kann dort ein Kommando für den Trim-DAC reinschreiben. (Alles klar?)
Glücklicherweise interpretiert jener nur die letzten 16 Bit als
Kommando, stört sich nicht dran wenn es mehr waren, sowas habe ich
nämlich auch schon erlebt.
Mit diesem Trick kann ich paarig beliebige Kommandos an die beiden
Trim-DACs schicken. Auch dort gibt es ein NOP, so das ich gezielt auch
nur einen ansprechen kann.
Mit der eigentlichen Trimmung geht es frühestens weiter wenn die
Hardware steht, logo. Die Dimensionierung der Serienwiderstände ist
gerade in Arbeit.
So long,
Jörg
Jörg H. schrieb:> Die Topologie ist ungünstig: In der Mitte das FPGA,> nach links zum SRAM, nach rechts zum anderen FPGA, nirgendwo> Serienwiderstände oder Terminierung.
Hallo Joerg,
klasse, was du da machst.
Hast du schon mal die 'Cyclone II On-Chip Termination' ausprobiert?
http://www.altera.com/devices/fpga/cyclone2/features/onchip/cy2-onchip.html
Im 'Pin Planner' einfach mit links auf 'Node Name' oder einen anderen
Spaltennamen und 'Customize Columns...' waehlen (siehe Anhang).
Dann kannst du auch zusaetzlich noch einmal mit den Stromtreibern
spielen.
Viel Erfolg und Gruss, Peter
Hallo Peter,
aha, das kannte ich noch nicht. Ich wußte auch nicht, das es da
potentiell noch mehr Spalten gibt. Ist ein Serienwiderstand nicht so
ähnlich wie verringerte Treiberstärke?
Danke für solche Tool-Tipps. Das kann ich gut gebrauchen. Mir ist zwar
von der Logik meist klar was zu tun ist, aber die Stellschrauben der mir
neuen Werkzeuge kenne ich mitunter nicht.
Im Moment habe ich keine Lust mehr auf die Baustelle Optimierung des
SRAM-Interfaces, habe das zurückgestellt, denn das ist wohl "premature
Optimization". Später muß man da mal dran messen um zu sehen was
wirklich anliegt, wie knapp das ist oder wo noch Luft ist. In der Firma
haben wir ein geeignetes Oszi.
Um weiter zu kommen habe ich das Timing auf konservativ eingestellt,
sogar einen Waitstate beim Schreiben weil es mit dem Write Pulse auf 1/2
Clockbreite noch Fehler gab.
Später werden wir sehen wie schnell das vollere FPGA den überhaupt noch
laufen kann, was für Hilfstakte noch möglich sind, etc.
Ich habe mich jetzt dem Thema SPI zugewandt (LEDs, Tasten, Drehgeber,
Kanaleinstellungen), um das System vollständig genug für eine
Softwareportierung zu kriegen. Mehr dazu später.
Jörg
Zum SPI und sonstigem:
Die SPI-Teile baue ich derzeit als Buskomponenten. Das hat gegenüber dem
Anschluss an PIOs den Vorteil, dass das nicht so ein Nadelöhr ist. Auch
kann ein Schreibzugriff direkt eine Aktion auslösen, man muss nicht erst
mit einem Startpin wackeln. Aber mal der Reihe nach:
LEDs:
Damit habe ich angefangen, sozusagen zum Warmwerden. Die LEDs haben
ihren eigenen SPI-Bus, also eine schön abgeschlossene Sache. Es gibt nun
ein LED-Register im Adressraum. Wenn die Software da drauf schreibt geht
es gleich los, die Bits werden rausgetaktet. Es muß nichts abgewartet
werden. Selbst wenn die Software das Register noch während des Schiebens
neu beschreibt wird einfach abgebrochen und ein neuer Transfer
gestartet. Die Software merkt also gar nicht, daß das in Wirklichkeit
keine parallelen Bits sind. Die einfache Bedienung könnte für z.B.
Bootloader-Experimente nützlich sein.
Tasten:
Die lange SPI-Kette (56 Bit) mit den Tasten und Drehgebern wird
natürlich zyklisch gelesen, mit etwa 7 kHz. Die Tastenbits davon landen
in einem Register. Ich habe auch die unbenutzten Bits des letzten
Schieberegisters dazugenommen (sind dann 32, eine schöne Zahl für ein
Register). So haben wir potentiell 4 Eingänge mehr, ist gedacht für
Drehgeber mit Pushbutton. Liegen schon länger bei mir herum.
Eine Änderung des Tastenstatus kann einen Interrupt auslösen. Im
Unterschied zum originalen Design kriegen wir nicht nur die Info das
eine Taste gedrückt wurde, sondern auch das sie losgelassen wurde, auch
haben wir Zugriff auf den Status aller Tasten gleichzeitig. Das erlaubt
potentiell andere Bedienung, z.B. Scrollen solange Taste gedrückt,
Umschaltfunktionen, langes Drücken macht was anderes, o.Ä.
Drehgeber:
Der obige Tastenscanner reicht die abgetasteten 12*2 Leitungen der
Drehgeber an ein weiteres Modul. Ist getrennt weil ein Avalon-Slave nur
einen Interrupt haben kann, ich für Tasten und Drehgeber aber
unterschiedliche möchte. Hier gibt es 12 Zähler auf die die Software
Zugriff hat. Wenn ein Encoder bewegt wurde wird ein zugehöriges Bit in
einem Statusregister gesetzt und kann ein Interrupt ausgelöst werden.
Die Software sieht dann mit einem Blick ins Statusregister um welchen
Zählerwert sie sich kümmern darf (und setzt den Status zurück).
So macht es keinen Unterschied, wenn mal 2 Knöpfe gleichzeitig gedreht
werden (Pong wird möglich ;-). Das originale Design kann das nicht. Es
hat auch die lästige Eigenart, schnellere Bewegungen erst im Nachhinein
zu melden wenn der Knopf nicht mehr bewegt wird, oder nur noch langsam.
Kanaleinstellungen:
Der SPI-Teil für Relais, Verstärkung, Offset-DACSs und demnächst
Trim-DACs ist die Hölle. Da ist alles mögliche dran angeschlossen, was
unterschiedlich behandelt werden will. 8, 16, 24 Bit Länge, invertiert
oder nicht, Chip Selects auf verschiedene Weise, usw. Das originale
Design kümmert sich selbst um diesen Zoo, aber es geht nur das was
vorgesehen war. Soweit will ich mit Absicht nicht gehen, ich mache den
Transfer in einem Config-Register in all diesen Aspekten parametrierbar,
die Software ist dann verantwortlich. Es gibt ein abfragbares Busy-Bit,
das hatte mir gefehlt. Kann auch einen Interrupt auslösen.
Ich bin noch am Debuggen von dem Ding.
Wenn das fertig ist wäre das Grundsystem (ohne Capturing) soweit
vollständig. Dann kann es mit der Software richtig losgehen, Boot-ROM,
UCL-Dekompressor, Build-Environment, Osoz portieren...
Ich habe bei Tasten und Drehgebern drauf geachtet, dass die
Bitpositionen gleich bleiben. So brauche ich die Header nicht ändern.
In der Hardware fehlt außer dem Capturing (große Baustelle, klar) noch
ein PWM-Generator für den externen Triggerpegel und der 1kHz
Testgenerator. Wollen wir den vielleicht auch auf z.B. 1 MHz umschaltbar
haben, falls die Schaltung das hergibt?
Hier zu guter Letzt nochmal der Aufruf das Mitmacher immer herzlich
willkommen sind. Danke an Thomas aka Fritzi für seine Unterstützung!
So long,
Jörg
Jörg H. schrieb:> Wenn das fertig ist wäre das Grundsystem (ohne Capturing) soweit> vollständig. Dann kann es mit der Software richtig losgehen, Boot-ROM,> UCL-Dekompressor, Build-Environment, Osoz portieren...
SPI funktioniert soweit, ich kann keine Fehler mehr feststellen. Damit
wäre mein selbstgesteckter Meilenstein erreicht, das Nios-II Design ist
bereit für die Software.
Noch ein paar News vom 2. FPGA: Mathias hat dem JTAG hinterher
gefahndet, die Platine von Guido war auch nützlich. Am 2. FPGA ist der
JTAG leider nicht vollständig angeschlossen, nur TDI und TDO, aber kein
TCK und TMS. Warum auch immer. Damit haben wir leider keine Chance, das
2. FPGA so komfortabel wie das 1. in Betrieb zu nehemen. Es geht nur
Blindflug, den Inhalt mit ins Config-Flash packen und hoffen.
Jörg
Hi, sitze hier am Flufhafen Wien und warte auf den Weiterflug - gute
Gelegenheit mal den Fortschritt zu verfolgen. Ich bin beeindruckt. Das
nimmt ja Formen an, die wir vorher kaum für möglich hielten.
Leider kann ich FPGA-Seitig wenig Hilfe anbieten. Doch hoffe ich bei der
Implementierung der neuen Software wieder meinen Beitrag leisten zu
können.
Gruß Hayo
(Hayo, siehe weiter unten)
Am Wochenende habe ich einen Bootloader für den Nios II und unsere
Hardware geschrieben. (Die Ablösung für den GERMSloader, der wird nicht
mehr unterstützt.) Ging schneller als erwartet, ich hätte nicht gedacht
das Thema schon abschließen zu können. Ich mußte schließlich erstmal
lernen, wie man denn was im Boot ROM plaziert, wie Assemblercode dafür
erstellt.
Es gibt eine gute Vorlage, eine AppNote samt Sourcecode von Altera:
http://www.altera.com/literature/an/an458.pdf
Unser neuer Bootloader basiert nun auf dem "Small Boot Copier Example".
Ich habe ihn noch verschlankt/beschleunigt, z.B. auf immer 32bittig
kopieren statt byteweise, Nutzung des Datencache.
Altera hat sich ein Format ausgedacht, wie ein Programm im Flash
abgelegt ist, mit was für Headern drumrum, und liefert Scripte die sowas
erzeugen. (Sie nennen es "Boot Image".) Also machen wir das auch so,
kein Grund das Rad neu zu erfinden.
Was den Bootloader dann zu "unserem" macht ist die Abfrage, ob beim
Booten F1 gehalten ist, und wenn ja nimmt er so ein Image nicht aus dem
Flash, sondern von der seriellen Schnittstelle entgegen. Binär, keine
S-Records mehr.
Seinen Status vermeldet er mit LEDs, die grüne Run-LED wenn er vom Flash
startet, die rote Single-LED wenn man ihn mit F1 angehalten hat und er
auf die RS232 wartet, sowie verschiedene Fehlerzustände.
Von den 512 Bytes sind derzeit noch 160 frei, wir könnten uns also sogar
noch etwas Luxus erlauben, eine Bootmeldung oder sowas. Vorschläge?
Hayo, es gibt da noch etwas was du ohne viel Aufwand Gutes tun könntest:
Ich brauche einen definierten Platz in Flash, wo das Nios-II Boot Image
liegen kann, den die alte Firmware nicht anfasst. Wir sollten für den
Übergang das Flash sinnvoll partitionieren. Von den grotesk vielen
möglichen Signalspeichern könnte man gut was freimachen, die Firmware da
einschränken. Könntest du einen Release mit sowas machen?
Weitere News:
Die Widerstandsarrays für die Trim-DACs sind bei mir eingetroffen. Ich
habe sie aufgelötet, die Hardware ist nun vollständig, aber noch nichts
weiter damit gemacht. Die Baustelle kommt später. Ich habe noch welche
übrig, weil eine Verpackungseinheit 50 Stück waren, kann also ggf. noch
Leute damit versorgen.
Meine Probierplatine für den FX1 USB-Chip ist da. Ich habe sie bestückt,
mal kurz angestöpselt, aber auch hier noch nichts weiter gemacht. Das
wird auch noch länger nix.
Als nächstes gucke ich mir die Portierung der UCL-Loader an, oder gleich
Osoz, mal schauen.
So long,
Jörg
Hallo Jörg,
mit meinen eigenen Pfad-Vorstellungen hat sich das NIOS2 System nicht in
Betrieb nehmen lassen ... was soll's nun heiße ich auf meinem Rechner
halt Joerg ... ;-)
Hura ... die ersten UART-Meldungen sowie Bildschirmanzeigen sind zu
sehen.
Leider kann ich derteit nur die "Pulse Width" Taste drücken! Alle
anderen reagieren nicht.
Wenn ich aber die geannte Taste drücke, kann ich über den U/Div Kanal 1
etwas ändern bis zum Assert ... (wie im Bild zu sehen...)
Ein Grundmenü kann ich auch schon erfolgreich sehen ...
Hat Deine schon vollzogene Hardwareänderung der Trimmung evtl. schon
negative Folgen für den Lauf meines Systems?
Das Debuggen ist ja absolut genial ...
Gruß Andi
Andreas W. schrieb:> mit meinen eigenen Pfad-Vorstellungen hat sich das NIOS2 System nicht in> Betrieb nehmen lassen ... was soll's nun heiße ich auf meinem Rechner> halt Joerg ... ;-)
Oh, da sind irgendwo absolute Pfade drin? Mist. Wo denn?
Es soll sich ja niemand verleugnen müssen...
Wenn du mit dem SOPC Builder das System neu erzeugst muß auch das BSP
"aufgefrischt" werden, mit der aktuellen System ID und Timestamp. Oder
man muß die Verwendung selbiger wegkonfigurieren.
> Hura ... die ersten UART-Meldungen sowie Bildschirmanzeigen sind zu> sehen.
Glückwunsch! Ich freue mich sehr, wenn jemand das nachvollzieht. Ein
erster Schritt zur Mitarbeit. :-)
Und für mich eine gute Kontrolle, ob ich das richtige eingecheckt habe.
Offensichtlich noch nicht ganz.
Für interaktive Dinge kann man mich im Skype-Gruppenchat erwischen. Wer
da rein will möge mir seine ID mitteilen.
> Leider kann ich derteit nur die "Pulse Width" Taste drücken! Alle> anderen reagieren nicht.> Wenn ich aber die geannte Taste drücke, kann ich über den U/Div Kanal 1> etwas ändern bis zum Assert ... (wie im Bild zu sehen...)> Ein Grundmenü kann ich auch schon erfolgreich sehen ...
Du kommst da weiter als ich, habe ich den Eindruck. Bei mir zerlegt es
sich i.d.R. schon vor der Hauptschleife. Da ist noch irgendwas richtig
faul, und ich habe derzeit keinen Schimmer. Seit meiner letzten Meldung
kam ich auch noch zu nix.
> Hat Deine schon vollzogene Hardwareänderung der Trimmung evtl. schon> negative Folgen für den Lauf meines Systems?
Nein, das ist mit ziemlicher Sicherheit auszuschließen. Die DACs zu
beschreiben ist "fire and forget", ob sie wirklich da sind merkt der
Rest nicht.
> Das Debuggen ist ja absolut genial ...
Ist schon ein Fortschritt, gell? Nett wäre wenn er mir anzeigen würde
woher meine Exception kommt. Vielleicht geht das irgendwie, und ich habe
das Knöpfchen noch nicht gefunden.
Jörg
Hallo Jörg,
> Oh, da sind irgendwo absolute Pfade drin? Mist. Wo denn?> Es soll sich ja niemand verleugnen müssen...> Wenn du mit dem SOPC Builder das System neu erzeugst muß auch das BSP> "aufgefrischt" werden, mit der aktuellen System ID und Timestamp. Oder> man muß die Verwendung selbiger wegkonfigurieren.
... genau da sind noch absolute Pfade drin. Diese hatte ich versucht
anzupassen ... bis auf einen (der war nicht im Editor sichtbar ...
müsste also im Klartext geändert werden) ... damit musste ich das BSP
sowie so neu kompilieren.
Die System ID und Timestamp frische ich immer in der Software auf ...
ist eh bei jedem Start von Quartus notwendig ... bzw. erst beim
Verbinden und einspielen der Software (nach NIOS2).
Ich freue mich auch über den derzeitigen Lauf ... und den Assert über
den UART. Ich werde mal versuchen ein genaueres Debuggen zu ermöglichen.
> Ein erster Schritt zur Mitarbeit. :-)
Ich habe für Hajo schon einige beschriebene BUGs entfernt ... ;-) und
freue mich schon wenn Hajo wieder Zeit hat.
Ich werde mich erst einmal in die Software einarbeiten ... und suchen wo
der Welec-Typ festgelegt wird (2 oder 4 Kanal) ...
Gruß Andi
> Die System ID und Timestamp frische ich immer in der Software auf ...> ist eh bei jedem Start von Quartus notwendig ... bzw. erst beim> Verbinden und einspielen der Software (nach NIOS2).
Hmm, das muß ich deutlich seltener, mittlerweile fast gar nicht mehr.
Nur wenn sich im SOPC Builder was geändert hat, Peripherie,
Basisadressen, solche Dinge.
> Ich freue mich auch über den derzeitigen Lauf ... und den Assert über> den UART. Ich werde mal versuchen ein genaueres Debuggen zu ermöglichen.
Die Assertion ist weg, heute habe ich etliche Bugs entfernt.
Mittlerweile läuft das System normal, zumindest auf der 2Kanalplatine
von Guido die ich gerade dranhabe. Ich habe den seriellen Treiber noch
nicht eingecheckt, baue da zwischenzeitliche krude Workarounds wieder
aus.
> Ich werde mich erst einmal in die Software einarbeiten ... und suchen wo> der Welec-Typ festgelegt wird (2 oder 4 Kanal) ...
Bei Osoz? In CaptureInit(), bzw. abgefragt durch
CaptureGetNumChannels(). Für den Nios II habe ich da derzeit hart 2
eingetragen, bis zum zweiten FPGA ist es noch ein gutes Stück Arbeit...
Für den jetzigen Trockenbetrieb kannst du aber wohl auch eine 4
eintragen.
Jörg
Jörg H. schrieb:> Bei Osoz? In CaptureInit(), bzw. abgefragt durch> CaptureGetNumChannels(). Für den Nios II habe ich da derzeit hart 2> eingetragen, bis zum zweiten FPGA ist es noch ein gutes Stück Arbeit...> Für den jetzigen Trockenbetrieb kannst du aber wohl auch eine 4> eintragen.
Ach da hatte ich mich gestern doch nicht versehen ...
Ja ich meine bei Osoz für NIOS II ...
Na da werde ich nach dem "Einchecken" mal einen Test machen ...
Prinzipell sollte das ja auch mit der 4 Kanal-Variante funktionieren.
Gruß
> Na da werde ich nach dem "Einchecken" mal einen Test machen ...> Prinzipell sollte das ja auch mit der 4 Kanal-Variante funktionieren.
So, ist drin. Das serielle Kommandointerface geht bei mir wieder.
Weil der neue UART ja FIFOs hat (und wegen der Granularität der
FPGA-Memories sogar je 512 Bytes groß) habe ich das gepufferte Senden
per Interrupt für den Nios II ausgebaut. Der Sende-FIFO hat quasi den
gleichen Effekt, und es beißt sich nicht mit "unbehandeltem" printf().
Jörg
Test vor UART-Checkin:
Also der BugFix für die Tasten ist gelungen ... wenn auch die Tasten
sehr empfindlich sind (besonders "Main / Delayed" habe ich das Gefühl).
Die Anzeige für den Kanal 1 sieht noch etwas komisch aus ... siehe Bild.
- ist auf der Linie des Kanals um ein Pixel nach rechts verschoben
- die Anzeige BW und DC/AC sieht verknispelt aus
Ja sonst ist das schon ein geniales Stück Software was da entstanden ist
...
Andi
> Also der BugFix für die Tasten ist gelungen ... wenn auch die Tasten> sehr empfindlich sind (besonders "Main / Delayed" habe ich das Gefühl).
Ja, die prellen noch, da muß ich nochmal an die Hardware. Ich habe es
auch speziell bei Main/Delayed gemerkt.
> Die Anzeige für den Kanal 1 sieht noch etwas komisch aus ... siehe Bild.> - ist auf der Linie des Kanals um ein Pixel nach rechts verschoben> - die Anzeige BW und DC/AC sieht verknispelt aus
Das habe ich gar nicht. Hast du was Spezielles gemacht? Auch die
verschobene Linie gefällt mir nicht. Steht das still, oder zittert was?
Könnten Probleme mit dem Speicher sein, zu agressives Timing.
Zerdetschte Grafik hatte ich, als der LCD-Treiber cachebaren Speicher
rausgereicht hat. Das tut er nun übergangsweise nicht, später wird man
nach Grafikupdates den Cache flushen.
Jörg
Jörg H. schrieb:
> Das habe ich gar nicht. Hast du was Spezielles gemacht? Auch die> verschobene Linie gefällt mir nicht. Steht das still, oder zittert was?
Naja ... das ist so eine Frage ... Ich habe auf dieser Position schon
beim einspielen von NIOSII eine Linie (sieht jedenfalls so aus) ... wenn
gewünscht kann ich Dir mal ein Foto einstellen nach dem Einspielen von
NIOSII ohne Software!
ABER ...
Drehe ich am Encoder die 0-Position des Kanal 1 geht dieser Strich mit.
Die Grafik AC/DC zittert etwas ...
Ich habe derzeit noch keine Besonderheiten eingestellt. Noch ist (fast)
alles wie bei Dir ... nur mit einem 4-Kanaler im Test ...
Bei den schlechten Fotos sollten wir auf jeden Fall wieder an einer
Screenshotfunktion arbeiten ;-)
Andi
> Naja ... das ist so eine Frage ... Ich habe auf dieser Position schon> beim einspielen von NIOSII eine Linie (sieht jedenfalls so aus) ... wenn> gewünscht kann ich Dir mal ein Foto einstellen nach dem Einspielen von> NIOSII ohne Software!
Dann ist wohl meine Hardware im FPGA schuld.
Ich habe ferner manchmal den Eindruck, das Quartus ab und zu einen
schlechten Tag hat und mit dem Syntheseergebnis wenig anzufangen ist.
Vielleicht fehlt mir noch ein nötiger Constraint oder sowas. Hast du das
mal neu angeworfen?
> Drehe ich am Encoder die 0-Position des Kanal 1 geht dieser Strich mit.
Was heißt "geht mit"?
> Die Grafik AC/DC zittert etwas ...
Zittern ist schlecht. Deutet auf irgendwas marginales mit dem SRAM hin.
Normalerweise zerlegt es dann die Software aber sehr schnell. Unter
altera/software/hello sind noch meine Unittests, da ist auch ein
Speichertest dabei, den könntest du mal probieren. Ich habe ihn mir ins
Flash gebrannt, so zum Test des Bootloaders.
> Ich habe derzeit noch keine Besonderheiten eingestellt. Noch ist (fast)> alles wie bei Dir ... nur mit einem 4-Kanaler im Test ...
Ich habe jetzt auch meine Platine wieder dran. Uh, geht längst nicht so
gut, die üblen Exceptions sind wieder da. :-(
Da ist wohl echt noch der Wurm drin, in der Hardware.
> Bei den schlechten Fotos sollten wir auf jeden Fall wieder an einer> Screenshotfunktion arbeiten ;-)
Die ist nach wie vor drin. Im Terminal "screenshot" eingeben. Erscheint
mir auch schneller als vorher. Aber es gibt immer noch keine
Empfängersoftware.
Speicherfehler wird sie auch nicht wiedergeben.
(Ich weiß, du hast es nicht ernst gemeint.)
Jörg
> Dann ist wohl meine Hardware im FPGA schuld.> Ich habe ferner manchmal den Eindruck, das Quartus ab und zu einen> schlechten Tag hat und mit dem Syntheseergebnis wenig anzufangen ist.> Vielleicht fehlt mir noch ein nötiger Constraint oder sowas. Hast du das> mal neu angeworfen?
Oh ja ... da vergeht eine Zeit (ca. 3 Minuten bei einem Intel E8400).
> Was heißt "geht mit"?
Ich meine, dass die genannte Linie mit dem Pixel nach rechts in der
Y-Achse mitwandert wenn ich den 0-Punkt-Encoder drehe.
> Zittern ist schlecht. Deutet auf irgendwas marginales mit dem SRAM hin.> Normalerweise zerlegt es dann die Software aber sehr schnell.
Hatte ich heute bis jetzt (außer gestern) noch gar nicht!
> Unter altera/software/hello sind noch meine Unittests, da ist auch ein> Speichertest dabei, den könntest du mal probieren. Ich habe ihn mir ins> Flash gebrannt, so zum Test des Bootloaders.
Den werde ich morgen mal probieren ...
> Ich habe jetzt auch meine Platine wieder dran. Uh, geht längst nicht so> gut, die üblen Exceptions sind wieder da. :-(> Da ist wohl echt noch der Wurm drin, in der Hardware.
Da habe ich derzeit gar keine ... bzw. war das UART-Modul nicht ganz
fit.
> Speicherfehler wird sie auch nicht wiedergeben.> (Ich weiß, du hast es nicht ernst gemeint.)
;-)
Andi
Es gibt erstes Wellengezappel mit dem Nios II Design und Osoz drauf!
Ich habe zum Test ganz grob was reingestrickt, nur 2kanal, immer 1GS,
kein Trigger. Hat noch nichts mit Alex' Sachen zu tun, gibt Timing
Violations und sogar Spikes. (Ich gebe mir echt Mühe, das originalgetreu
hinzukriegen ;-)
Aber schön, da erstes Leben zu sehen. Ermöglicht weitere Tests, z.B. ob
die Kanaleinstellungen funktionieren.
Es zappelt sogar ziemlich schnell, obwohl ich den Datencache noch nicht
recht nutze, der Compiler unoptimierten Code erzeugt und die
Möglichkeiten der neuen Hardware wie LCD-Flip statt Copy noch ungenutzt
sind.
Vielversprechend, das wird mal richtig schnell!
Was ich dabei noch gelernt habe, als ich die vielen LVDS-Leitungen von
den ADCs erstmals benutzt habe:
Der Fitter duldet in der Nachbarschaft der LVDS-Pins keine "normalen"
TTL-Pegel. Ich hatte vorher alle unbenutzten / noch unbekannten
Leitungen zum Test auf PIOs gelegt, um ggf. zu gucken ob sich da was
tut. Die mußte ich nun größtenteils wegnehmen oder zu differentiell
umwidmen, wo möglich.
Es gibt nun nur noch einen(!) freien/unbekannten I/O der für Logikpegel
verwendbar ist. Ferner noch ein paar Clockeingänge, die theoretisch
Inputs sein könnten. Die FPGA-Hardware ist also von den Pins praktisch
ausgereizt, wenig Wahrscheinlichkeit da noch unbekannte Features zu
entdecken.
Das erklärt auch, warum das LCD ärgerlicherweise mit nur 3 Bit pro Farbe
angebunden ist, es gab einfach keine Pins mehr.
Jörg
Den Haupt-Bremsklotz habe ich gerade mal testweise gelöst, den Code mit
Optimierungen übersetzt. Hiu, da geht's ab, ich bin echt von den Socken!
Die neue Hardware ist in dem Fall den ich verglichen habe etwa 10 mal
schneller. Eine ruhige Nullinie wird mit etwa 1500 fps gezeichnet (kein
Tippfehler). Komplexere Signale, zwei Kanäle immer noch 200 fps. Mit
Main/Delay Gesamtdarstellung gut 40 fps (das war vorher ziemlich lahm).
Wenn das mit dem LCD-Flip statt Copy drin ist wird es nochmal schneller.
Der für LCD noch ungenutzte Datencache macht sich hingegen quasi nicht
bemerkbar. Mit Cache ist es nicht schneller.
Weitere Hardware-News:
Die Glitches und die Timing Violations sind weg. Ich habe jetzt den
"echten" Capture-Datenpfad gebaut, mit halber Frequenz und doppelter
Breite. Damit kommt das FPGA besser klar. Am Eingang verwende ich
DDR-Zellen um den Takt zu reduzieren. So wird das recht elegant und
passiert direkt an den Pins. Alex hatte das seinerzeit "zu Fuß" gebaut.
Vor seiner Filterei habe ich große Hochachtung, da traue ich mich noch
nicht ran... Wir haben aber neulich länger telefoniert, er hat mir eine
Tour gegeben.
Ich kämpfe noch etwas mit dem Capture-Speicher, das erste Datenwort ist
immer falsch, auch wenn ich es überspringe, sehr merkwürdig.
Im SPI-Teil habe ich einen Glitch gehabt, der zu Querbeeinflussung der
Kanaleinstellung führte. Ist nun sauber.
Gibt trotzdem immer noch viele Baustellen. Irgendwas ist instabil
(Businterface?), besonders mit meiner Hardware. Ich verwende derzeit
meist die von Guido, aber das muß natürlich noch gelöst werden.
Jörg
Ich schreib' mal wieder was, ist eine Weile her, seitdem ist einiges
passiert.
Alex hat mir mit dem Sample-Speicher geholfen, der funktioniert jetzt.
Ich habe erste Vorbereitungen für das 2. FPGA getroffen. Der Bootloader
testet jetzt, ob er das Flash erreichen kann (was nur auf dem 1. FPGA,
dem Master, möglich ist). Wenn nicht, dann läuft das wohl auf dem Slave.
Abhängig davon werden interne Signale für Rollenverteilung und die
Richtungsumschaltung der Verbindungsleitungen gesetzt. Beim Slave geht
die CPU dann in Dauer-Reset.
Das 2. FPGA wird blöd zu debuggen, weil Wittig dort leider 2 wichtige
JTAG-Signale nicht angeschlossen hat. Wir können nur den Bitstream ins
Config-Flash brennen und hoffen.
Zu Testzwecken kann es auch die kleinste Nios-II Version sein, der /e.
Der ist nämlich lizenzfrei und ich kann auch daheim den ROM-Inhalt
erzeugen. Geht sonst nur mit JTAG im Evaluationsbetrieb.
Letzte Woche habe ich mich und die Chat-Teilnehmer ausführlich mit einem
"Phasenabgleich" der 4 ADCs pro Kanal beschäftigt. Die sampeln reihum
versetzt mit 250 MHz, um 1 GSa/s zu erzeugen. Diesen Versatz können wir
mit den 4 PLLs recht fein einjustieren, um die Abtastzeitpunkte akkurat
zu haben. Ich habe mit Andrés Hilfe ein Matlab-/Octave-Script gebastelt,
was den Phasenversatz der ADCs bestimmen kann, um dann geeignet
nachzukalibrieren. Das gab erstmal Verwirrung, wie sich rausstellte
hatte ich die ADCs anders angeschlossen als die Clocks.
Nun wo das endlich gefunden ist kann ich einen Kanal perfekt einstellen,
den 2. aber leider nicht, weil Wittig sozusagen einen Layoutfehler
gemacht hat. Die 4 Takte gehen nicht gleichartig von dem einen
ADC-"Cluster" zu dem des anderen Kanals, sondern 2 Takte kommen von
hinten, 2 von vorn. Die Laufzeitunterschiede addieren sich zu ziemlich
genau 90° Phasenverschiebung. So fallen 2 ADCs eines Kanals für eine
sinnvolle Messung praktisch aus. Wir haben etwas Glück im Unglück, es
sind die ADCs 2 und 4, die bereits für 500 MSa/s nicht mehr verwendet
werden. Man kann also mit Kanal 1 (und 3, falls vorhanden) 1GSa messen,
mit Kanal 2 (und 4) sinnvoll nur 500 MSa. Oder wir stellen das so ein,
das es für beide Kanäle mittelkrumm ist...
Die PLLs sind nicht zur Laufzeit programmierbar, das passiert bei der
Erstellung des FPGA.
So long,
Jörg
An die stillen Leser, was hat sich inzwischen getan:
Ich habe die Wittig-Hardware vermessen, was für Farben am LCD denn genau
rauskommen und das als Default nun auch so eingestellt.
Es gibt ein rudimentäres Empfängertool für das Screenshot-Format von
Osoz. Es kann den Terminaloutput zu .bmp Grafiken dekomprimieren.
Andreas macht da hoffentlich was Schöneres draus.
Den LCD-Controller habe ich nochmal überarbeitet. Den Ausgabeteil hatte
ich Neuling mir vom Altera-Code abgeguckt, mittlerweile fand ich geht
das einfacher. Hatte den sehr schönen Nebeneffekt das die
Bildschirmdarstellung jetzt auch bei Andreas in Ordnung ist. :-)
Der Nios-II Bootloader kann nun erkennen, ob er auf FPGA1 (Master) oder
FPGA2 (Slave) läuft. Er testet, ob er das Flash erreichen kann und setzt
entsprechend Portbits. Beim Slave wird dann die CPU im Dauerreset
gehalten. Die Portbits hatte ich mir für eine Richtungsumschaltung der
bidirektionalen Verbindungsleitungen vorgestellt, sowie allgemein die
Rollenzuweisung.
Den Ansatz habe ich aber mittlerweile verworfen, die jeweils ungenutzten
Busteilnehmer haben zu viele Nachteile. Es werden nun doch 2
verschiedene FPGAs, die aber viel Code gemeinsam haben. Ich hoffe ich
kriege das 2. im JTAG-losen Blindflug hin...
Ich habe erste Experimente mit dem zweiten FPGA gemacht, da einfache
Testdesigns reingebrannt die Daten eintakten und wieder zurückgeben. So
habe ich getestet, wie schnell denn das werden kann. Weil der Datenbus
mit dem SRAM geteilt wird ist es sehr erstrebenswert, dort mit dem
gleichen Takt arbeiten zu können (derzeit 75 MHz, angestrebt bis zu 94
MHz). Das klappt so gerade.
Den SRAM-Controller habe ich in Vorbereitung auf seine Doppelrolle
umgebaut. Seine Ausgänge sind jetzt durchgehend Register, keine
Kombinatorik mehr dahinter (außer bei der Schreibleitung, s.u.). Davon
erhoffe ich mir stabileres Timing.
Die PLLs habe ich noch mal umsortiert. Weil die 125 MHz DDR-Takte der
Datenübername so schön unkritisch sind traue ich mich auch, sie in einer
anderen PLL zu haben als den zugeordneten ADC-Takt. Bisher war das mit
Rücksicht auf Jitter in der jeweils gleichen. Das schafft nun Raum für
einen zukünftigen SRAM-Lesetakt in der gleichen PLL wie der normale
CPU+SRAM-Takt, der bei höheren Takten nötig ist. Auch den 3/4
Schreibtakt habe ich wiederbelebt, wenn auch aus der nächsten PLL. Damit
geht das Schreiben doppelt so schnell, ohne Waitstates dazwischen.
Bisher hatte ich das Toggeln der Schreibleitung synchron erzeugt, und
das gibt halbe Frequenz. Ein initialer Waitstate ist auch entfallen,
damit ist das SRAM-Interface jetzt komplett ohne Waitstates.
Klappt aber immer noch nicht zuverlässig. Meine Hardware ist sehr
kritisch, bei Guidos läuft das in der Regel, die Ergebnisse der Synthese
sind mitunter nicht reproduzierbar. Timing nach Extern habe ich noch
nicht richtig verstanden...
Zauberworte sind Constraints, set_input_delay, set_output_delay,
set_min_delay, set_max_delay, FAST_INPUT_REGISTER, FAST_OUTPUT_REGISTER,
FAST_OUTPUT_ENABLE_REGISTER, kennt sich damit jemand aus?
Jörg
Hallo,
noch hat sich keine Hilfe zu den Timingfragen aufgedrängt. Der Kollege
den ich fragen könnte ist schwer beschäftigt.
Bei mir tat sich erstmal nicht, ich habe vor einer Woche die Platte
meines Festplattenrecorders falsch umkopiert und eine Woche mit
erfolglosen Datenrettungsversuchen verbracht.
OT, für Linux-Experten: Sinngemäß habe ich ein "dd if=/dev/sda1
of=/dev/sda" statt einem "dd if=/dev/sda1 of=/dev/sdb1" abgesetzt. Bis
ich es gemerkt und (leider) abgebrochen habe waren ca. 10GB Daten ein
unbekanntes Stück nach vorn kopiert, über die Partitionstabelle.
Dann habe ich ein Tool geschrieben um den Versatz zu suchen, habe auch
einen Kandidaten. Es ungeschehen machen klappte leider doch nicht, das
zusammengefügte Filesystem mounted nicht.
Zurück zum Welec: ich bin nun etwas raus, vielleicht geht es dieses WE
weiter, mal sehen.
Jörg
Wünsche frohe Weihnachten gehabt zu haben!
Die Daten von meinem Festplattenrecorder sind wieder da, nicht zuletzt
dank tatkräftiger Mithilfe aus dem Forum. Da bin ich ja froh, das hier
eher beiläufig erwähnt zu haben.
Das Oszi hatte eine längere Zwangspause, in der ich stattdessen über das
ext3-Dateisystem gelernt habe.
Nun versuche ich wieder reinzukommen, muß gestehen es gelingt mir nicht.
Der (wegen gemeinsamer Datenleitungen) Mix aus SRAM-Interface und
externem Interface zum zweiten FPGA ist eine harte Nuß für mich.
Vielleicht fehlt mir da die richtige Methodik. Als State-Machine wäre es
wohl übersichtlicher, aber wegen des Pipelinings ist es eine mir gerade
nicht mehr verständliche Ansammlung von Signalen und Flipflops, während
mir die Kobinatorik dazwischen zu komplex für anständige Taktfrequenzen
wird...
Jörg
hab seit kurzem Probleme mit Spikes. Und zwar treten diese bei Kanal 2
erheblich auf, auch sogar ohne Signal. Kanal 1 ist i.O.
Wenn das Gerät dann eine Zeit lang betrieben wird verschwinden sie
vollständig, bei kühlem Gerät (12-18°C Werkstatt) wieder Spikes.
Defintiv thermisch, Lötstelle? Wären da die SRAMs denkbar?
Ich bin mir recht sicher das die Spikes interne Timingprobleme im FPGA
sind. Das Design da drin ist zu sehr auf Kante genäht. Das Problem
scheint ja quasi jeder zu haben, mehr oder weniger. Daher glaube ich
nicht an im Einzelfall auch denkbare Lötfehler am FPGA oder einem ADC.
Das RAM wird es sicher nicht sein, da stürzt dir vorher die Software ab
oder so.
Mit dem Leon-Design oder dem neuen Nios-II Design sind die Spikes
bestimmt weg, weil die internen Datenpfade mit halber Geschwindigkeit,
aber doppelter Breite arbeiten. So ist auch ein "legales" Timing
hinzukriegen.
Ich habe leider noch nichts schlüsselfertiges mit Nios-II zum Testen,
das war mal besser, bevor ich die SRAM-Baustelle wieder aufgerissen
habe...
Jörg
aber das trat so stark nie auf, ist jetzt nicht auf den Bildern zu sehen
aber ich habe zum Teil heftige Spikes schon ohne Signal auf der
Nulllinie, noch stärker als im Foto. Sobald das Teil dann warm ist (die
reine Betriebsdauer seit dem anschalten ist nicht entscheidend) ist
alles augenscheinlich prima.
Anfangs (das Scope ist 3 Jahre alt) gabs da nichts derartiges, da hatte
ich nur die Spikes an den bekannten Stellen, die selten auftraten, aber
nicht im normalen Signal.
So ist das Oszi quasi unbrauchbar, ich kann eigentlich nur an ein
Hardwareproblem glauben, am FPGA Design sollte sich ja nichts von heut
auf morgen ändern?
okay, im Thread von 2009 gelesen... Gabs schon öfter dass die Spikes
wieder verschwinden nach aufwärmen. Mich wundert aber das auftreten nach
mehreren Jahren dennoch.
Hm, merkwürdig. Bei mir treten die Spikes nur auf wenn das Gerät warm
wird und auch nur beim 4 Kanaler. Das 2 Kanal Gerät hat nichts
dergleichen. Falls es tatsächlich ein Problem mit kalten Lötstellen sein
sollte, tippe ich eher auf die ADCs. Einfache Möglichkeit - rückwärtige
Geräteabdeckung entfernen und während des Auftretens der Spikes mal auf
die ADCs drücken.
Beim RAM würden andere Symptome auftreten. Von Streifen auf dem
Bildschirm über Abstürze bis überhaupt kein Firmwarestart.
Die Tatsache, dass die Spikes jetzt auf einmal nach drei Jahren
auftreten, könnte theoretisch auch an alternden Bauteilen liegen
(Kondensator). Das wäre aber dann der erste mir bekannte Fall.
Gruß Hayo
Nachschlag:
Deine Bilder zeigen auf Kanal 2 verschiedene Spannungsbereiche für
mit/ohne Spikes.
- Treten die Spikes nur in bestimmten Spannungsbereichen auf oder in
allen?
- sind alle Zeitbasen betroffen oder nur bestimmte?
Hayo
ne, also tritt bei verschiedensten Zeit- und Spannungseinstellungen auf,
wobei ich jetzt nicht jede Kombination ausprobiert habe. Zum Teil auch
noch viel heftiger als auf dem Foto.
Im alten Thread hatte Guido und Bruno mal berichtet dass er sein Gerät
auch aufwärmen muss bis die Spikes weg sind.
Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil2)"Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil2)"
Werde mir die ADCs und den Rest der Platine mal ansehen, viel mehr kann
ich ja eigentlich nicht machen.
Das Zusammenspiel mit der Temperatur ist halt seltsam.
Du kannst ja mal versuchen, teile der Elektronik per Kältespray zu
malträtieren. Alternativ kannst du auch versuchen, die Chips mit dem
Lötkolben am Gehäuse aufzuheizen.
Dann kannst du zumindest den Fehler eingrenzen und dir Sicher sein, ob
es ein Temperaturthema ist oder nicht.
werde ich machen. Ein Problem mit der Temperatur ist es aber defintiv,
lässt sich 100% reproduzieren. Dauert aber noch paar Tage bis ich das
angreife.
Vielleicht mag auch mal einer sein W2022 ins kühle stellen und schauen
was passiert. So 10-12°C rum hatte ich den Fehler dann eigentlich immer.
Wobei ich mir eigentlich sicher bin, dass es früher nicht so empfindlich
darauf war.
Ok Ben, laß Dein Oszi zu!
Mein Versuch auf der Terasse endete mit einem Aha-Erlebnis.
Temperatur 5 - 6 Grad Celsius. Zwei Stunden draußen stehen gelassen und
dann in Betrieb genommen.
Bei mir war exakt das Gleiche zu beobachten wie bei Dir. Kanal 1 ohne
Probleme. Kanal 2 genau die gleichen Spikes wie bei Deinem Gerät, auch
an den gleichen Stellen.
Also das Gerät wieder reingeholt und kurz warmlaufen lassen - Spikes
sind weg.
Offensichtlich ist es bei mir im Programmierzimmerchen wohl so warm,
dass mir das nie aufgefallen ist.
Eine kalte Lötstelle kann daher wohl ausgeschlossen werden. Mit
ziemlicher Sicherheit hat Jörg recht und das Timing des FPGA ist so
grenzwertig ausgelegt, dass schon geringe Temperaturschwankungen das
Ganze aus dem Gleichgewicht bringen.
Ein Grund mehr auf ein neues FPGA-Design zu setzen.
Gruß Hayo
gibt es keine Möglichkeit, das zu kompensieren?
Bei meinem 2 Kanal, tritt es ja auch, mal mehr, mal weniger auf.
Zur Beobachtung, bei horizontaler Signalverschiebung, also nach oben
oder unten, nehmen die Spikes aber ab u. zu.
Könnte es sein, das es etwas mit der Pixelberechnung der Displayausgabe
zusammenhängt? Mir kommt das manchmal so vor...
Gruß Michael
Danke Hayo (und all die anderen)!
Dann hab ich das Oszi wohl tatsächlich bisher kaum benutzt, bevor die
Werkstatt nicht angenehme 20°C hatte und es ist nicht aufgefallen.
Temperatur ist schon fies...
Michael, werden die Spikes bei dir auch weniger wenn das Gerät eine Zeit
lang in Betrieb ist? Nach 30 Minuten war bei mir alles gut.
Nein, die Pixelberechnung ist definitiv nicht temperaturabhängig :-)
Die Vertikalverschiebung der Nulllinie bewirkt allerdings auch eine
Änderung der Spikes. Das hängt aber wohl eher mit dem binären 8 bit Wert
zusammen der an den entsprechenden Stellen der Spikes auftritt und
anscheinend irgendwie verfälscht wird.
Softwareseitig läßt sich das eigentlich so gut wie gar nicht
kompensieren, evtl. mit dem Noise Filter etwas abschwächen.
Einzige Möglichkeit - Gerät erst warmlaufen lassen (5 Minuten reichen
bei mir), dann ist nichts mehr von den Spikes zu sehen.
Hayo
@Ben
> Michael, werden die Spikes bei dir auch weniger wenn das Gerät eine Zeit> lang in Betrieb ist? Nach 30 Minuten war bei mir alles gut.
Nun ja, ich habe hier 18°C und noch rammeln die Spikes bei 500MSa/s
munter weiter...vielleicht sollte ich das Teil mal auf den Ofen stellen
;-)))
Von 1GSa/s bis runter 250MSa/s sind die Spikes am häufigsten und das
Signal ist sehr unruhig.
Ab 25MSa/s ist wieder alles hübsch und ruhig.
Gruß Michael
was ich dazusagen muss, mein Gerät hat einen gemoddeten Lüfter der eher
weniger als mehr Luft als der Originale bringt (gedrosselter
Noiseblocker 40mm, aber mit "Luftkanal" nach außen blasend)+
Schrimblech, also gut möglich dass sich deswegen eine etwas höhere
Innentemperatur einstellt (geschätzt gute 40°C).
Michael D. schrieb:> Ab 25MSa/s ist wieder alles hübsch und ruhig.
Ja das liegt daran, dass ab dieser Samplerate nur noch 1 ADC arbeitet
statt 4. D.h. es müssen nicht mehr 4 Register ausgelesen werden sondern
nur noch Eines.
Ben L. schrieb:> mein Gerät hat einen gemoddeten Lüfter der eher> weniger als mehr Luft als der Originale bringt
Das hat aber eher keine Auswirkungen. Bei mir arbeitet ein
hochmotivierter 80er Lüfter, und nach 5 Minuten ist alles warm genug.
Der Stein des Anstoßes ist das FPGA, und das liegt außerhalb des
Luftstromes zwischen den beiden Platinen. Vermutlich sind da eher
unterschiedliche FPGA Revisionen der Grund.
(Bei mir 8C7.0L)
Hayo
Jörg H. schrieb:> Warum nicht gleich den richtigen Widerstand von 174 Ohm einlöten?
Ich konnte 174 Ohm weder auf irgendwelchen Teileträgern noch als Neuteil
zum Kauf finden, jedenfalls nicht bei meinen üblichen Verdächtigen.
Also habe ich mich für den nächsten gängigen Wert entschieden. Die
Widerstände haben 1% Toleranz und ich habe mir die rausgesucht die etwas
nach unten abweichen. Der resultierende Unterschied dürfte im Rahmen der
üblichen Bauteiletoleranzen liegen und sich auch nicht weiter auf die
Skalierungsfaktoren auswirken. Für mich war aber interessant zu sehen,
dass sich tatsächlich gegenüber den 150 Ohm eine sichtbare Verbesserung
einstellte. Die Fehlanpassung nach unten hatte wohl doch einigen
negativen Einfluß.
Also wer 174 Ohm zur Hand hat sollte die dann natürlich nehmen. Ich kann
den Wert ja im Hardwaremenu auf 174 ändern, damit da keine
Missverständnisse aufkommen.
Gruß Hayo
Bei RS oder Farnell kann man die 174 Ohm kaufen, bei Mouser oder Digikey
natürlich erst recht. Bis vor kurzem bei RS sogar ohne Versandkosten...
:-(
Der Wert ist leicht aufgerundet.
Zugegeben kann laut Datenblatt der Innenwiderstand der ADCs stark
streuen, im Mittel 4400 Ohm, aber von 3000 Ohm bis 6500 Ohm.
4 ADCs parallel und noch unser Widerstand parallel sollen 150 Ohm
ergeben.
Also R = 1 / (1/150Ohm - 4/Ri)
Kann schlimmstenfalls von 165,3 bis 187,5 Ohm liegen, ist aber
unwahrscheinlich das alle 4 ADCs am gleichen Anschlag der Toleranz
liegen.
Jörg
@Jörg,
> Längswiderstände: Mit denen verringert sich die Spannung am ADC und der> Vorteiler kann im Ausgleich mehr draufgeben, eine Stufe unempfindlicher> werden. Beides zusammen sorgt dafür, das der ADC wesentlich besser> ausgesteuert wird, quasi perfekt statt vorher nur gut zur Hälfte. Die> Darstellung wird deutlich feiner, weil die Software die Rohwerte nicht> so aufzoomen muß.> Leider beginnt im neu erreichten Aussteuerbereich bereits die Sättigung> der letzten Ausgangsstufe, die wird dort etwas nichtlinear. (Müßte in> der FFT-Darstellung gut als K3 zu sehen sein.) Um das zu vermeiden kann> laut Branadic die Versorgungsspannung des letzten OpAmp von 3,3V auf 5V> umgeändert werden. Das hat aber noch keiner ausprobiert. Scheint> zusammen mit Längswiderständen eine sinnvolle Modifikation zu sein.
Wenn die 5V in der Nähe der ADC's verlaufen, sollte das machbar sein.
Die 3V kappen und die 5V Volt druff, nur wenn die zu weit weg sind und
man erst einen Kilometer Kabel ziehen muß, könnte man sich darüber ein
paar Parasiten einfangen, oder?
> Kann schlimmstenfalls von 165,3 bis 187,5 Ohm liegen, ist aber> unwahrscheinlich das alle 4 ADCs am gleichen Anschlag der Toleranz> liegen.
Bei mir sind es ja "nur" 2 ADC's, wenn die von derselben Charge sind,
sollte das passen!
(mal den Plan und das Layout raus popeln...)
Gruß Michael
Michael D. schrieb:> Wenn die 5V in der Nähe der ADC's verlaufen, sollte das machbar sein.> Die 3V kappen und die 5V Volt druff, nur wenn die zu weit weg sind und> man erst einen Kilometer Kabel ziehen muß, könnte man sich darüber ein> paar Parasiten einfangen, oder?
Es gibt in der Nähe 5V. Etwas weiter unten sitzt ein Spannungsregler, so
zwischen 2 Kanälen, der aus 6V "frische" 5V erregelt. Wo die noch
hingehen weiß ich aber nicht.
Am OpAmp möchte man ja noch einen Blockkondensator behalten, damit wird
es etwas kniffliger. Ich habe mir da noch keinen Plan zurechtgelegt.
>> Kann schlimmstenfalls von 165,3 bis 187,5 Ohm liegen, ist aber>> unwahrscheinlich das alle 4 ADCs am gleichen Anschlag der Toleranz>> liegen.> Bei mir sind es ja "nur" 2 ADC's, wenn die von derselben Charge sind,> sollte das passen!
Auch bei dir sind es 4 ADCs, nämlich pro Kanal. ;-)
(Es sei denn, du hast auf 500MSa abgerüstet und die Häfte weggebaut...)
Jörg
Nachtrag:
Hier der Beginn eines Plans. Die 5V gehen an so einiges im Analogteil.
Entgegen dem Schaltplan liegen da keine 6V an, sondern besagte 5V.
Ich habe das in beiliegendem Bild markiert. (Für Kanal 1+2, 3+4 sieht
ähnlich aus.) Rot umrandet und nach unten gezogen sind die 5V-Bereiche,
lila und nach oben gezogen die Versorgungspins der Ausgangs-OpAmps.
Praktischerweise geht eine 5V-Leiterbahn nach oben hoch, bis fast an den
einen OpAmp ran.
Man könnte den Blockkondensator oberhalb des OpAmp um 90° verdreht auf
seinem Massepad auflöten, so daß Masse noch verbunden ist, aber der
andere Anschluß im freien Bereich liegt. Dann von dort einen Fädeldraht
an den hochgebogenen Pin 3 und weiter nach 5V.
Jörg
> Auch bei dir sind es 4 ADCs, nämlich pro Kanal. ;-)> (Es sei denn, du hast auf 500MSa abgerüstet und die Häfte weggebaut...)
:-)))
Du hast natürlich Recht! Hätte es wissen müssen, habe denen ja noch die
Kühlkörper verpasst, wie man sieht... :-(
Nur Mut, das geht schon. Siehe angehängtes Nachher-Bild, ich hab's heute
morgen mal ausprobiert, an der schwierigeren Stelle (Kanal 2). Der
vorhandene weiße Patchdraht ist teflonisoliert, dem passiert nichts.
- Mit Flußmittel und Entlötlitze für weniger Zinn an dem OpAmp-Beinchen
sorgen
- Lötstelle des Pin 3 mit einer feinen Lötspitze verflüssigen, dabei den
Pin mit einer Nadel abheben und ausrichten, nicht abbrechen!
- Sicherstellen das man keine Lötbrücke hochgezogen hat. Mit nochmal
Flußmittel das verbliebene Zinn auf der Platine verflüssigen, so daß es
glatt fließt.
- den Blockkondensator auslöten und neu ausrichten, schräg am Massepad
wieder anlöten, mit Pluspol frei
- einen neuen Patchdraht ziehen, vom freien Pin des Blockkondensators
zum OpAmp-Pin und zu +5V.
- Sicherstellen das auch wirklich kein Kurzschluß zwischen den
vorherigen 3,3V und den neuen 5V besteht oder bei Berührung von Pin3
passieren kann. Ggf. Kleber oder Isoliermaterial dazwischen.
Ich hatte noch keine Zeit zu testen, ob sich die Linearität verbessert.
Werde ich am Wochenende probieren.
Jörg
Moin Jörg,
> - Lötstelle des Pin 3 mit einer feinen Lötspitze verflüssigen, dabei den> Pin mit einer Nadel abheben und ausrichten, nicht abbrechen!
Pfff...das wär's dann gewesen :-(
Den Kerko 90° zu drehen, wäre wohl etwas eng geworden? Das dachte ich
mir schon fast.
Heute Abend, wollte ich sowieso mal die Widerstände Austauschen... wenn
ich bis dahin wüsste, das die 5V was bringen, dann würde ich das gleich
mitmachen!
Sagst du gleich bescheid, wenn du getestet hast?
Gruß Michael
Michael D. schrieb:>> - Lötstelle des Pin 3 mit einer feinen Lötspitze verflüssigen, dabei den>> Pin mit einer Nadel abheben und ausrichten, nicht abbrechen!> Pfff...das wär's dann gewesen :-(
Naja, dann muß man einen neuen einlöten und kann das dann auch gleich
ordentlich machen. ;-)
Beim Einbau der neuen Eingangsstufe bleiben je Kanal 1-2 davon übrig.
> Den Kerko 90° zu drehen, wäre wohl etwas eng geworden? Das dachte ich> mir schon fast.
Es ginge wohl schon, aber so ist der Patchdraht etwas kürzer. Die Länge
bis zum Blockkondensator sollte induktionsarm sein.
> Heute Abend, wollte ich sowieso mal die Widerstände Austauschen... wenn> ich bis dahin wüsste, das die 5V was bringen, dann würde ich das gleich> mitmachen!> Sagst du gleich bescheid, wenn du getestet hast?
Heute ab 22:00 guckt meine Frau ihre Lieblingssendung, dann könnt's
gehen. ;-)
Hayo W. schrieb:> Du hast bei Kanal 1 noch die 0 Ohm Widerstände drin???> Zu Testzwecken?
Ja, damit ich die Software auch für Forumskollegen mit originalem Oszi
ausprobieren kann. Kanal 3+4 haben die neue Eingangsstufe (nicht mehr im
Bild). Die müßte für die 5V-Modifikation leider kurz wieder beiseite, um
das da drunter machen zu können.
Jörg
Ob sich die Änderung auf 5V auf die Linearität positiv auswirkt würde
mich auch mal interessieren. Desweiteren, ob die Skalierung sich dadurch
ändert, was eigentlich nicht der Fall sein sollte.
Wenn das positiv verläuft werde ich das auch gleich mal nachziehen. Ich
hatte beim Blockkondensator allerdings so die Idee selbigen einfach
senkrecht stehend auf seinem Pad aufzulöten, dann ist man schön frei vom
3.3V-Pad und der Draht ist auch nicht länger.
Gruß Hayo
Hayo W. schrieb:> Ich> hatte beim Blockkondensator allerdings so die Idee selbigen einfach> senkrecht stehend auf seinem Pad aufzulöten, dann ist man schön frei vom> 3.3V-Pad und der Draht ist auch nicht länger.
Hatte ich auch erwogen, der Draht wird dann noch kürzer. Ist mir aber zu
abbrech-gefährdet, wenn man mal unbedarft über die Platine fingert.
Zum Thema Linearität hatte ich mich im Osoz-Thread mal ausgelassen. Hier
der allgemeine Text:
Beitrag "Re: made from scratch Firmware für Wittig/Welec Oszilloskop W20xxA"
Hier im Update (2 Postings später) die besser visualisierten Daten:
Beitrag "Re: made from scratch Firmware für Wittig/Welec Oszilloskop W20xxA"
Jörg
Erste vorläufige Messung: die Linearität wird nicht besser, sieht
gegen Ende der Skala etwa gleich krumm aus wie vorher.
Mist!
Was nun, liebe Hardwerker?
Jörg
> Erste vorläufige Messung: die Linearität wird nicht besser, sieht> gegen Ende der Skala etwa gleich krumm aus wie vorher.
so ein Mist, hatte mir doch eine kleine Veränderung erhofft, also lohnt
der Aufwand nicht?!
Na ja, werde schon mal die 24 Ohm und den 180 Ohmler Tauschen.
Gibt es nur diesen einen Abschlusswiderstand?
(jetzt muss ich mal blöd fragen)
Müssten da nicht zwei sein, also je einer pro Kanal?
Gruß Michael
Michael D. schrieb:>> Erste vorläufige Messung: die Linearität wird nicht besser, sieht>> gegen Ende der Skala etwa gleich krumm aus wie vorher.> so ein Mist, hatte mir doch eine kleine Veränderung erhofft, also lohnt> der Aufwand nicht?!
Tja, ich war auch recht zuversichtlich, daß das die Ursache ist, hatte
wenig Zweifel am Sinn der Maßname.
Es kann sein daß es für die neue Eingangsstufe sinnvoll ist, wäre an der
Stelle noch den Versuch wert. Denn dort ist dieser OpAmp das letzte
verbliebene Originalteil im Signalweg. Und auch dort ist die
Nichtlinearität in gleicher Weise sichtbar.
> Gibt es nur diesen einen Abschlusswiderstand?> (jetzt muss ich mal blöd fragen)> Müssten da nicht zwei sein, also je einer pro Kanal?
Ja, jeder Kanal hat einen Abschlußwiderstand, so ziemlich mittig auf der
Rückseite der 4 ADCs. Und 2 Längswiderstände hinter besagtem letzen
OpAmp.
Jörg
Michael D. schrieb:> Müssten da nicht zwei sein, also je einer pro Kanal?
Es ist ein differentieller Abschluss, man könnte jeden Pfad einzeln
gegen Masse abschließen oder einfach einen Abschluss zwischen den beiden
Pfaden einlöten, dass spart dann ein Bauteil.
Ich wundere mich doch sehr, dass die 5V-Versorgung keine Verbesserung in
der Linearität bringen soll. Allerdings muss ich zugeben, dass ich den
Einfluss dieser Maßnahme nicht für die originale Eingangsstufe überdacht
habe sondern ausschließlich für die neue Eingangsstufe.
branadic
Hallo Jörg,
ist denn schon bekannt, wie das PIN4 der MAX1121 beschalten ist?
Eigentlich sollten doch alle 4 ADC eines Kanals mit der gleichen
externen common mode Spannung beschalten sein. Lt.
"Analog-Input-Part_assignment_V1_3_3.pdf" ( was der letzte Stand ist?)
müsste also PIN2/U12, Messpunkt13 und PIN3 der 4 ADC je Kanal verbunden
sein. Im Datenblatt MAX1121 wird von 1,4V Vcm gesprochen. Mit dem
eingezeichneten Teiler im Stromlaufplan kommen wir aber nur auf 1,25V?
Kann das eine Ursache für die Begrenzung der Spannungen sein?
Gruß
Jürgen
Hallo Jürgen,
guter Punkt, da liegen 1,25V an, weil die ADCs es so brauchen.
Von daher bringt eine großartige Erweiterung des positiven Rails
vermutlich wenig, man könnte das negative etwas tiefer als Masse legen.
Aber vorher mal messen, was da wirklich passiert...
(Dank an branadic für die Diskussion per Skype)
Jörg
Uff, mir fällt ein Stein vom Herzen, endlich habe ich das mit dem
SRAM-Interface für das Nios II Design hingekriegt. Beide mir zur
Verfügung stehenden Hauptplatinen laufen stabil.
Schon von einem Monat habe ich das Interface gründlich umgebaut, auf
Registerausgänge, in der Hoffnung das Timing sauberer zu kriegen. Aber
nach Sekundenbruchteilen stürzte es hoffnungslos ab, auf meiner Platine
ging es gar nicht.
Nun habe ich mir am Wochenende ein stark verkleinertes Testdesign
gebaut, nur noch Speicher, LCD und ein Dummy-Master, keine CPU und keine
Peripherie. Das kompiliert in 20 Sekunden statt 2 Minuten, so konnte ich
schneller systematisch an der PLL für die Speichertakte rumspielen, am
LCD dann sehen ob das Bild OK ist.
Ergebnis war: das neue SRAM-Interface ist "zu gut"! Die Timings hatten
sich um ca. einen halben Takt nach vorne verschoben, mein
Abtastzeitpunkt lag nun voll daneben. Das neue Interface würde sich bei
110 MHz am wohlsten fühlen, dann gingen die Lesedaten mit passender
Phasenlage für den Speichertakt glatt durch. Es ist total unkritisch,
auch die Maximalfrequenz von 125 MHz ist (mit einem passenden Lesetakt)
kein Problem. Vorher waren solche Frequenzen höchst kritisch, ging
praktisch nicht, die PLL für den Lesetakt mußte auf Bruchteile von
Nanosekunden stimmen. Nun ist da üppig Luft.
Das ist aber alles zuviel für unseren Nios und die Verbindung zum
zweiten FPGA, da bleibt es vorerst bei 75 MHz. Von daher muß ich das
SRAM ein bischen ausbremsen, die Daten zum halben Takt in ein
Zwischenregister übernehmen, dort ein bischen rumtrödeln lassen bis zur
"richtigen" Taktflanke.
Und noch ein zweiter Fehler spuckte mir in die SRAM-Suppe: Solange das
zweite FPGA noch seinen Originalinhalt hat darf ich an den beiden
Interconnects nicht rühren, die bisher ein Chip Select dafür darstellen.
Sonst treibt es auf den SRAM-Bus und macht mir dort die Daten kaputt.
Ich hatte angefangen die für meine neue Verbindungsmimik umzuwidmen, das
darf so noch nicht.
Deshalb ging auf meiner 4kanal-Platine gar nichts mehr. (2 Fehler
übereinander mit gleichem Symptom sind übel, man bemerkt es nicht wenn
man einen behebt.) Nun habe ich das umbelegt, Osoz rast wieder fröhlich
vor sich hin.
Puh, ich bin heilfroh über diesen Berg zu sein!
Jörg
Na das nenn ich mal eine Erfolgsmeldung. Dann rückt eine Neugeburt
unseres DSO ja in greifbare Nähe.
Zu dem Trigger API - ich teste/probiere gerade intensiv an den Holdoff
und Pulsweiteneinstellungen herum in der Hoffnung hier neue Erkenntnisse
zu gewinnen. Für die Tests am Holdoff brauche ich allerdings erstmal
einen Bitmustergenerator, sonst komme ich da nicht weiter.
Kennt jemand eine Software, die Bitmuster auf RS232 oder LPT ausgeben
kann?
Ansonsten bin ich am überlegen, ob ich mir selbst was schreibe, oder mir
einen Generator aus einem Schieberegister selbst zusammenbaue.
Gruß Hayo
Hayo W. schrieb:> Für die Tests am Holdoff brauche ich allerdings erstmal> einen Bitmustergenerator, sonst komme ich da nicht weiter.>> Kennt jemand eine Software, die Bitmuster auf RS232 oder LPT ausgeben> kann?
Die Tx-Leitung der RS232 könntest du in Grenzen nehmen. Start- und
Stopbit liegen vom Pegel zwar fest, aber mit den Bits dazwischen ließen
sich einfache Muster bauen. Über die Baudrate kannst du noch das Timing
hindrehen.
Wenn das reicht kannst du dir eine große Datei mit immer dem gleichen
Zeichen (oder dem Zeichenmuster) machen, die dann auf den COM-Port
kopieren. Oder ein Script/Programm, was in Endlosschleife drauf
schreibt.
Mit der Soundhardware lassen sich lange und freie Muster bauen.
Allerdings sind die Ausgänge AC-gekoppelt. Eventuell läßt sich das
Signal vorher abgreifen, an z.B. einer USB-Hardware?
Jörg
Jörg H. schrieb:> Die Tx-Leitung der RS232 könntest du in Grenzen nehmen. Start- und> Stopbit liegen vom Pegel zwar fest, aber mit den Bits dazwischen ließen> sich einfache Muster bauen. Über die Baudrate kannst du noch das Timing> hindrehen.
Ja sowas in der Art hatte ich mir auch schon überlegt .bzw. das weiter
unten...
> Wenn das reicht kannst du dir eine große Datei mit immer dem gleichen> Zeichen (oder dem Zeichenmuster) machen, die dann auf den COM-Port> kopieren. Oder ein Script/Programm, was in Endlosschleife drauf> schreibt.
...nämlich mit einem kleinen Programm Muster auf den Ports ausgeben.
> Mit der Soundhardware lassen sich lange und freie Muster bauen.> Allerdings sind die Ausgänge AC-gekoppelt.
Da hatte ich die Hoffnung, dass ich nicht der Erste bin, der sowas
braucht und dass sich schon mal jemand rangesetzt hat und sowas
geschrieben hat.
Habe aber per Google-Suche nix gefunden.
Gruß Hayo
Nur bedingt,
da würde ich dann lieber ein kleines C-Progrämmchen schreiben. Aber
danke für den Tip. Ich denke ich werde mir mit einem Schieberegister
einen Mustergenerator bauen, den ich dann mit dem Funktiongenerator
takte, da bin ich dann mit der Frequenz schön flexibel.
Gruß Hayo
Hi Sebastian,
nein auch nicht ganz. Die Signale sind eher für Audio Projekte gedacht.
Mir geht es um digitale Bitmuster, die die Funktion der Holdoff-Zeiten
wiederspiegeln können.
Gruß Hayo
Mal eine Statusmeldung von der Nios II Hardware:
Ich habe ziemlich lange an der Anbindung des 2. FPGAs herumgetüftelt.
Das ist eine Erweiterung des SRAM-Controllers, weil dessen Bus quasi
nebenberuflich die Verbindung bildet. Er muß es also auch koordinieren.
Ist mir bisher noch nicht gelungen, da Timing fliegt mir um die Ohren,
zuviel Logik zwischen 2 Takten. Und das, obwohl ich das schon mit einem
Waitstate für den externen Zugriff entschärft habe. Da muß ich nochmal
zurück ans Reißbrett.
Andiiiy meinte, ich solle mich erstmal mal um Trigger und Zeitbasis
kümmern, damit es zumindest als 2Kanäler mehr einsetzbar wird und wir
mehr Begeisterung für die Softwareentwicklung wecken, Hayo abholen.
Grübel grübel, auch keine leichte Sache, das mit dem Trigger. Die
Ansprüche steigen ja auch gerade...
Ich habe mir in dem Zuge das Leon-Design genauer angeguckt, da gibt es
ja schon mehr als ich dazu je zustande brächte. Eigentlich hatte ich
geplant, das hoffentlich irgendwann schrittweise zu verstehen und zu
portieren.
Die Quellen sind leider kaum kommentiert. Dieses Wochenende habe ich
VHDL-Legastheniker damit verbracht, mich durch die Hierarchien zu
wühlen, um rauszufinden wo denn da unten und oben ist. Und es reifte ein
Plan:
Wir könnten den Signalverarbeitungsteil so wie er ist in ein (großes) IP
verpacken, als Avalon-Slave. Also als eine von den vielen Einheiten am
Bus, der Rest des Systems besteht auch aus solchen, schon fertige von
Altera oder selbstgeschriebene für unsere speziellen Hardwareeinheiten.
Dann spielt es auch keine Rolle daß das in VHDL geschrieben ist und mein
Rest in Verilog. Damit hätten wir hoffentlich eine solide Ausgangsbasis.
Alex hat sein Zeug ja schon simuliert und getestet.
Ein paar Details:
Alex hat ausgenutzt, das die 125 MHz Signalverarbeitung (250 MHz / 2)
ein Vielfaches von seiner CPU-Frequenz von 31,25 MHz ist. Das möchte ich
nicht, aber wir haben eh einen langsameren Peripherietakt, an den wäre
das IP sowieso angeschlossen. Den habe ich nun von 25 auf 31,25 MHz
umgestellt. Ich wollte den eh erhöhen, um das 90 ns Timing für das Flash
besser erzeugen zu können. Momentan wurde das zu 120 ns aufgerundet, nun
sind es 96 ns, fast perfekt.
Ich habe mir die Interfaces des Signalteils angeguckt. Es erscheint gut
machbar, das für uns anzupassen. Nur zwei Komponenten müssen stark
verändert oder neu gemacht werden:
1. Der Bus-Anschlus für die Programmierregister und den Zugriff auf den
Samplespeicher muß in die Altera-Welt überführt werden. Aus taktischen
Gründen mache ich 2 Slaves draus, einen für SFR, einen anderen für den
Speicher. Nur SFR braucht die 31,25 MHz, den Speicher kann ich dann
später im 2. FPGA an den schnellen Bus anschließen. Ein leeres IP für
diesen Doppel-Slave habe ich schon gebaut und eine VHDL-Hülle erzeugen
lassen.
2. Die ADC-Daten kommen bei uns anders rein, da würde ich gerne den
DDR-Trick weiterhin anwenden. Alex hat in dem Teil auch die PLLs
instantiiert und stellt nebenbei alle Systemtakte zu Verfügung. Bei uns
geschieht das außerhalb, das kann entfallen.
Alles was nicht zum Signalteil gehört kommt raus. Also der Leon und
seine verschiedenen IPs, sowie die Alex-Teile für RAM-Interface, LCD,
Keyboard, Drehgeber. All das habe ich ja bereits passend für Alteras
Avalon-Bus und mit Verlaub, in recht leistungsfähiger Ausführung.
Für jemanden der VHDL kann ist dieser Umbau vermutlich keine große
Sache. Ich hingegen müßte das erst lernen. Mag mir jemand helfen, haben
wir noch unentdeckte Talente?
Viele Grüße
Jörg
Also da ich mit FPGAs im Studium nur am Rande zu tun hatte kann ich da
nur anerkennend nicken. Ich bin ja gespannt was dabei rauskommt. Das
hört sich ja sehr vielversprechend an.
Achtung, ab hier kurzfristig etwas offtopic...
Inzwischen habe ich mal in der neuen Version versuchsweise mit einer
Execution Queue experimentiert, auch mit verschieden priorisierten
Tasks. Das funktionierte auch ganz gut, nur bei zeitkritischen Vorgängen
war dann der Verwaltungsoverhead für die bescheidene Rechenleistung des
NIOS zu groß. Da funktionierte dann die simple Flagsteuerung in der
Endlosschleife besser. Ich hab das dann also erst mal wieder
rausgenommen und nur eine einfache verzögerte dynamische
Funktionsausführung mittels VSync-Interrupt implementiert.
Ab hier wieder voll im Thema...
Mit der neuen FPGA-Implementierung sehe ich aber wirklich interessante
Möglichkeiten da dank der deutlich besseren Performance auch keine
Abstriche mehr wegen etwas Verwaltungsoverhead gemacht werden müssen.
Solange das neue FPGA-Design noch "under constuction" ist werden ich
noch etwas an der alten Firmware rumtüfteln, bin aber schon ganz
gespannt was so alles möglich sein wird.
In diesem Sinne
Gute Nacht (oder Morgen)
Hayo
Moin,
Hayo, tüftele nicht zuviel, das kann nun recht schnell gehen hier. Nach
dem Einbau des Leon-Signalteils wäre das neue Design zumindest als
2Kanäler fertig. (Vorbehaltlich Debugging, es ist noch nicht alles
getestet.)
Für jemanden der VHDL kann wäre der Einbau vermutlich eine Sache von
wenigen Stunden. Ich hingegen muß erst ein Buch lesen...
Zum offtopic:
Komisch, für so'n bischen Verwaltungskram sollte die CPU-Geschwindigkeit
keine Rolle spielen. Bei Osoz geht's doch auch?
Jörg
Ich ziehe für die 6.3 noch ein paar Kleinigkeiten glatt, keine großen
Sachen. Das Experimentieren mit der Queue war auch für mich zum lernen
gedacht. War einfach neugierig ob das gut funktioniert und das tut es.
Meine Queue war 8 Handles lang und im Normalbetrieb waren maximal 4
Handles gleichzeitig belegt da die längste Prozesskette eben 4 Prozesse
enthält.
Nur bei den ganz langsamen Zeitbasen (Rollmode) da ist das Timing so
eng, dass der NIOS es nur alle 5 - 10 Acquisitionen schafft, die
komplette Prozesskette zu durchlaufen. Das führte dann ständig zu
Queue-Überläufen oder eingefrorenem Bildschirm. Da ist die Schleife mit
den Flags einfach stabiler und arbeitet die asynchron auftretenden
Anforderungen ohne Ruckler ab.
Mit der Rechenleistung des NIOS II sollte das aber kein Problem sein.
Hmm, ist ja eigentlich völlig offtopic hier...
Gruß Hayo
So, von mir mal wieder einige Screenshots zu einem Thema das mir seit
einiger Zeit durch den Kopf geht. Da ich zum Testen immer an allen
Kanälen das gleiche Signal liegen habe ist mir aufgefallen, dass bei
meinem unmodifizierten W2014A die Amplitude des Signals je nach
Abtastrate zwischen den Kanälen stark abweicht. Ich habe mal von 01 - 06
die Abtastrate kontinuierlich erhöht. Man sieht sehr schön wie die
Amplitude immer mehr abweicht. Auf Bild 07 und 08 kann man sehen, dass
Kanal 1 und 3 kaum Abweichung haben, dagegen Kanal 2 und 4 sehr starke
Abweichung.
An allen Kanälen liegt das gleiche Signal mit gleich langen Zuleitungen
an.
Die Frequenz des Signals ist die ganze Zeit gleich (35Hz Rechteck).
Hat jemand vergleichbare Beobachtungen gemacht?
Mein Verdacht ist ja, dass das evtl. mit unseren bekannten
Abschlußwiderständen zusammenhängt, denn siehe nächster Beitrag...
...beim modifizierten W2022A mit der Widerstandskombination 24.9/180 Ohm
ist das so gut wie überhaupt nicht zu beobachten.
Mich würde ja interessieren ob die Verteilung der Abweichung über die
Kanäle bei allen Geräten gleich ist, oder ob das so rein zufällig
verteilt ist.
Gruß Hayo
Noch ein kleiner Nachschlag, wenn man die beiden am stärksten
voneinander abweichenden Kanäle nimmt (2 + 4) und dann ans Ende des
Memory scrollt stellt man fest, dass sich die Amplituden zum Ende hin
wieder annähern, was irgendwie auf kapazitiven Einfluß hindeutet bzw.
auf eine (parasitäre?) RC-Kombination. Kann gut sein, dass unsere
Abschlußwiderstände hier mit reinspielen. Ich werde wohl demnächst auch
das 2014A mal mit den richtigen Widerständen ausstatten, dann habe ich
den direkten Vergleich.
Was ich mir auch vorstellen könnte, das ist das die Abgleicheinsteller
im Eingang unter den Abschirmblechen da einen Einfluß drauf haben. Das
Thema hatten wir ja auch schon mal vor längerer Zeit.
Hayo
Jo, sieht nach Überschwinger (grün) bzw. Kriechen (rot) aus.
In den späteren Bildern ist das durch die extreme Dehnung
nicht mehr zu erkennen. Ich würde das erstmal mit 1 kHz
kontrollieren, sollte aber durch Abgleich behebbar sein.
Grüße, Guido
Guten Abend Hayo, Branadic, Jörg H., Kurt Bohnen und all jene, die an
dem Projekt beteiligt sind Welec!
Hayo W. schrieb:
>...beim modifizierten W2022A mit der Widerstandskombination 24.9/180 Ohm>ist das so gut wie überhaupt nicht zu beobachten.
It is a bit of time that I wanted to ask some questions about the
hardware in the Welec DSOs.
The new resistors as was suggested by Branadic (RESPECT!) last summer
and experimented by Jörg H. (RESPECT!) and others (RESPECT!) should be
of 174 Ohm for the best results.
I understand their values range is between 165,3 and 187,5 Ohm but
better choice is 173,684Ohm (~ 174 Ohm) but in order to match with the
HARDWARE setting in the latest firmware release what is the right
value?, 180 or 174Ohm?
I guess 180 Ohm is the value that Hayo used to recompile the
tc_vars.cpp file, because the 174 Ohm is more hard to find: is it
correct?
Also I guess they should be at least with tolerances of 1% or better and
with temperature coefficients of 1ppm/°K or better.
24,9/150 Ohm resistors I put in my DSOs were as gift in the materials I
bought from Kurt Bohnen (many thanks and RESPECT!) and I don't know
their tollerance and temperature coefficients, again seems to me I never
read about it in the Forum (but maybe I wrong).
So now in order to do the modify what are the right tolerances value and
temperature coefficients?
Thanks in advance.
After I changed the front-end's resistors in my two DSOs (a W2022a and a
W2012a) the 3dB bandwidth became incredibly linear and much better than
before.
Now I read that changing the 150 Ohm resistors with new ones 180 Ohm
values (~174 Ohm) then it is possible to obtain a further improvement
and I'd like to make the modify because I often have to deal with RF
signals.
Even if the final improvement is still small it would be useful to me,
waiting for the pickaback by Branadic can it be handled by the firmware
in the new "OZOS" FPGA by Jörg H. & C.
Hayo W. schrieb:
>Hat jemand vergleichbare Beobachtungen gemacht?
Hayo, what you wrote is really very interesting.
Since roughly one year my DSOs have a 24,9/150 Ohm resistors in them and
seems to me the DSOs' behaviour is what You have described.
The only thing that I can add and that I had already pointed out long
ago is that in my point of vision could be a little mismatch among the
channels phase as I wrote here:
Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil3)"Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil3)"
and going ahead.
Nochmals vielen Dank an alle Unterstützer des Projekts Welec!
Mit freundlichen Grüßen,
Luc
In Bezug auf Beitrag "Re: Wittig(welec) DSO W20xxA Hardware (Teil 2)":
Ich habe in meinem Buch gelesen, VHDL gelernt (ist gar nicht so schlimm
wie alle sagen) und mich da mal rangemacht.
Im ersten Schritt (svn #852) habe ich das jetzige Sampler-IP im Nios II
Design so umgebaut, wie auch das Leon-IP aussehen soll. Dadurch sind die
beiden einfach austauschbar.
Im zweiten Schritt (svn #855) habe ich den vorhandenen Sampler in das
zukünftige IP kopiert und nach VHDL übersetzt, sozusagen zum Üben. Er
funktioniert noch.
Im dritten Schritt habe ich die Leon-Sourcen die wir brauchen dort
eingepflegt und sukzessive umgebaut. Die restlichen Systemteile raus,
Eingang und Businterfaces quasi neu. Das ging insgesamt besser als ich
dachte. Alex hatte das schon recht gut strukturiert. Die meisten Dateien
konnte ich unverändert übernehmen.
Wer schauen mag, wie das nun aussieht, was für Änderungen nötig waren:
http://welecw2000a.svn.sourceforge.net/viewvc/welecw2000a/fpga/nios2/altera/ip/W2000_Downsample/
Die Verzeichnisstruktur habe ich stark vereinfacht, aber die Dateien
heißen noch wie im Original.
Der aktuelle Stand enthält also bereits den Signalteil und Trigger vom
Leon-Design, mit dessen aufwändiger Filtermöglichkeit und so. Das FPGA
ist nun etwa halb voll, dauert ca. 1,5 mal so lange zu übersetzen wie
davor (der neue Teil ist schon ein großes IP).
Als nächstes steht an, das zu testen und den Softwaretreiber anzupassen.
Auf Anhieb wird bestimmt nicht alles richtig sein. Ich muß nun erstmal
schauen, was ich denn mit den neuen Register so anstellen soll...
(Ich sollte Alex mal Bescheid sagen, das seine Diplomarbeit nun nach 4
Jahren hoffentlich endlich zu Ehren kommt.)
Jörg
Guten Abend Jörg H. und all jene, die an dem Projekt beteiligt sind
Welec!
Jorg, es ist wirklich interessant, was du geschrieben hast.
Vielen Dank für die Arbeit und Freizeit, die uns freundlicherweise zur
Verfügung gestellt: KLASSE!
Ich habe ein paar Fragen.
Ihr neuer FPGA-Design "OSOZ" wird in das Oszilloskop auf die gleiche
Weise die Alex [alex008] LEON geladen? (Vielen Dank an Alex: KLASSE!)
Sie können versuchen, es in den Speicher des Oszilloskops ohne die
Notwendigkeit, sie dauerhaft setzen, wie es für LEON war?
Vielen Dank im Voraus!
Mit freundlichen Grüßen,
Luc
Hello Luc,
let me try to clarify:
Osoz is the new software. It currently runs on both the original FPGA
and the new one I'm working on.
For the original FPGA, Osoz loads pretty much the same way as Hayo's BF
software, to Flash or RAM, using my compression loader.
The 2nd half of last year I got distracted from continuing it, because
we got hold of an earlier version of the original FPGA design sources.
They turned out to be not really useful, but I got interested in
bringing up a new design which best utilizes our Altera FPGA and
toolchain. Made from scratch on a higher level, not just the software,
also the hardware.
It doesn't have a catchy name yet, so far we just call it the Nios II
design, after the now used CPU core. It is probably the most powerful
you can get into that FPGA, can be clocked about 2-3 times faster than
the Leon, because it is specifically designed for (Altera) FPGAs, versus
the Leon is for ASICs (real chips), doesn't synthesize too well on an
FPGA. Unfortunately it's not free, but we have a license at work.
I made all the W20xx specific peripherals as IPs for the Altera SOPC
builder, their way of graphically putting a system together. The newly
developed IPs are the sampler, SRAM interface, keys, LCD, LED, PWM
generators, rotary, SPI, bridge to 2nd FPGA. A lot of stuff...
For the sampler I sortof gave up my primitive proof of concept design
and lately adapted the signal processing part of Alex' design, which is
pretty sophisticated.
All in all we now have (or will shortly have) a best of all worlds
design!
It was pretty easy to port Osoz to the Nios II design, because it was
made to be portable and the new hardware has similarities to the old
one.
You asked how to load it:
FPGA loading is similar to the procedure with the Leon design, using
Altera Quartus. You can load it using the Slog driver and the builtin
USB1 chip, which only works for 32 bit Windows and is a bit tricky to
install, because Windows so much loves to use its builtin HID driver
instead.
Or better get a cheap $10 USB blaster clone and plug it to the JTAG
port, giving you USB2 speed.
After FPGA loading, which can be done non-volatile, the Nios II has the
advantage that you can download and debug its software over JTAG, too.
(With Leon this was done cumbersome over the serial, I never managed
that.)
Osoz for the Nios II can be flashed, thanks to the bootloader I wrote.
It has a different load address, so both can coexist, the Flash is
rather large. You can prepare that while still using the original
design. If this is in place, once the FPGA has been loaded with Nios II,
it immediately starts its software from Flash.
If ony day you love it, you can also program the FPGA permanently, into
it's dedicated configuration flash. If for some reason you change your
mind, flash your original backup.
Nothing released yet, stay tuned...
(Right now I'm tring to figure out how to configure Alex' capture unit.
It's not my hardware, for a change.)
Jörg
Neulich war mal eine variable Amplitudeneinstellung Thema, wenn ich
recht erinnere. Oft ist die starre 1-2-5 Teilung etwas grob. Bei meinem
uralten Analogoszi kann ich mit einem Extraregler das kalibrierte Grid
verlassen und das Signal so groß stellen wie ich mag. Ist mitunter
nützlich, um 2 Signale verschiedener Amplitude zu vergleichen, z.B. Ein-
und Ausgang.
Kollege branadic hat noch auf einen weiteren Vorteil der neuen
Eingangsstufe hingewiesen:
Die Verstärkung ist dort in 2dB-Schritten einstellbar. Damit sind
feinere Abstufungen möglich, unter Beibehaltung einer guten
ADC-Aussteuerung.
Statt 1 - 2 - 5 hätten wir pro Dekade:
1 - 1,25 - 1,6 - 2 - 2,5 - 3,2 - 4 - 5 - 6,4 - 8
Also jeweils 2-3 Zwischenstufen, oder anders ausgedrückt 10 statt nur 3
Schritte pro Dekade..
Was kontinuierliches dazwischen wäre mit Softwareskalierung möglich.
Wer's genau wissen will, was da wann intern zu schalten und wie zu
skalieren ist, siehe Anhang. (Ist auch von branadic.)
Jörg
Hallo Jörg,
das ist nicht nur bei deinem Analogoszi so.
Das Voltcraft/Hantek/Tekway, hat das ebenfalls und zwar auch stufenlos.
Bei der groben Einstellung gehen die großen Sprünge ebenfalls auf 1-2-5.
Hier ein paar Shots, wie das in der Menuführung dargestellt ist.
Zur besseren Darstellung, habe ich die V/DIV Anzeige markiert.
Gruß Michael
Guten Abend Jörg H., Branadic und all jene, die an dem Projekt beteiligt
sind Welec!
Well Jörg, thank you very much for this great explanation: RESPECT!
Before I didn't know some things but now all it's much clear, thank You
again also for the great work You are working on: KLASSE!
I know QUARTUS so I think it will easy to put your new design on the
DSO, I can't wait for the public release! :-)
Jörg H. schrieb:
>Neulich war mal eine variable Amplitudeneinstellung Thema, wenn ich>recht erinnere. Oft ist die starre 1-2-5 Teilung etwas grob. Bei meinem>uralten Analogoszi kann ich mit einem Extraregler das kalibrierte Grid>verlassen und das Signal so groß stellen wie ich mag. Ist mitunter>nützlich, um 2 Signale verschiedener Amplitude zu vergleichen, z.B. Ein->und Ausgang.
Really very impressive, this is as dream come true, no words: RESPECT!!!
@Jörg H. and Branadic
Much terrific what I read, again this time I'm speechless, no words:
RESPECT!
Great the support for Huckepack by Branadic, finally! :-)
Another dream who come true!: RESPECT!!! :-)
Nochmals vielen Jörg H., Branadic an alle Unterstützer des Projekts
Welec!
Sie sind alle wirklich großen: KLASSE!
Mit freundlichen Grüßen,
Luc
Ein Update:
Am Wochenende habe ich erste Gehversuche mit der frisch integrierten
Capture-Hardware vom Alex gemacht. Er hat mich auch höchstpersönlich
unterstützt, was sehr hilfreich war. Ich denke, mittlerweile habe ich
verstanden wie das arbeitet. (Bis auf die Filter, die sind nicht zu
verstehen ;-)
Beim Interruptteil hatte ich noch einen Bug eingebaut, und die Kopplung
für das 2. FPGA ist nun vorbereitet.
Die Hardware scheint nun wie vorgesehen zu arbeiten, ich sehe erstes
Wellengezappel. Sprich, es geht!
Ich würde eine Sache noch gerne ändern, das Format der Speicherung im
FPGA. Derzeit wären die Capture-Daten etwas ineffizient zu kopieren,
Byte- oder Wortweise in teils mehreren Durchgängen, statt linear mit 32
Bit Zugriffen.
Dann gibt es noch einiges in der Software zu tun. Trigger und Zeitbasis
einbauen, eine andere Samplespeicherverwaltung, die berücksichtigt das
es im FPGA nun einen gemeinsamen Speicher für beide Kanäle gibt.
Jörg
Leider kann ich dir nur virtuell auf die Schulter klopfen,
gute Arbeit!
Jörg H. schrieb:> (Bis auf die Filter, die sind nicht zu verstehen ;-)
Ja, geht uns doch allen so, man muss nicht alles im Detail
verstehen, solange es funktioniert. Alex wird sicherlich
niemals vergessen wie das geht. ;-) Ich wollte mir vor
kurzer Zeit eigentlich nur mal die Mathematik dazu ansehen,
ist schon sehr aufwendig und momentan nicht zu machen.
Es ist aber schön zu sehen, dass Alex Arbeit nicht umsonst war.
Grüße, Guido
Jetzt mal was ganz Anderes, mit Bezug auf meinen Beitrag weiter oben
Beitrag "Re: Wittig(welec) DSO W20xxA Hardware (Teil 2)"Beitrag "Re: Wittig(welec) DSO W20xxA Hardware (Teil 2)"
Ich habe jetzt mal versucht mit den beiden Justierschrauben den
Unterschiedlichen Pegel richtig einzustellen. Dazu habe ich mir im 5V
Bereich ein Rechteck mit 100 KHz und 10Vpp eingestellt. Bei 100ns und
bei 50ns kann man ziemlich gut sehen ob die Pegel der einzelnen Kanaäle
übereinstimmen. Wichtig ist, dass man vorher das Channel Delay richtig
einstellt. Bei mir hat es sich auch als hilfreich erwiesen den Noise
Filter auf Smooth zu stellen.
Man nimmt sich einen Kanal als Referenzkanal und richtet die Anderen
daran aus. Man muß mit beiden Einstellern etwas spielen bis es stimmt,
dann kriegt man die Signale aber total deckungsgleich. Zum Einstellen
habe ich einen Kunstoff-Schraubendreher verwendet der bei meinen
TEK-Tastköpfen dabei war.
Das zeigt auch, dass die Justierung bei Wittig eher lieblos war, wenn es
denn überrhaupt eine gab. Wer also bei sich auch feststellt, dass seine
Kanäle nicht deckungsgleich sind sollte da mal selbst nachjustieren.
Aber Vorsicht! Man muß das bei abgenommener Rückwand machen und kann
sich da am Netzteil gehörig einen wegholen wenn man unachtsam ist!
Auf dem Screenshot sieht man nur noch einen kleinen Channel Delay, aber
die Pegel und die Kurvenform sind identisch. Beim W2014A sieht es jetzt
genauso gut aus.
Gruß Hayo
Und hier noch mal das W2014A nach dem Abgleich. Man sieht ziemlich
deutlich den Unterschied zu vorher. Ich habe übrigens das Signal einfach
ohne Abschlüsse mit vier gleich langen Meßleitungen und diversen
T-Stücken direkt angeschlossen. Das angezeigte Signal ist natürlich aus
meßtechnischer Sicht nicht brauchbar, aber zum Abgleichen der Kanäle
untereinander durchaus gut zu gebrauchen.
Gruß Hayo
Ach ja noch ein kleiner Tip, der untere Einsteller beinflußt das
negetive Teilsignal am meisten und der obere Einsteller das positive
Teilsignal.
Guats Nächtle
Hayo
@Hayo
> Wichtig ist, dass man vorher das Channel Delay richtig> einstellt.
Wie meinst du das denn? Den 1. Kanal als Referenz nehmen, quasi "0ns"
Delay, den 2.Kanal nachziehen z. B. "2-3ns" Delay und dann abgleichen,
oder beide auf "0"ns (Software technisch)stehen lassen?
Gruß Michael
Also erstmal braucht man ein Signal mit möglichst steiler Flanke. Mein
Rechteck hat ca. 30ns Risetime. Das ist jetzt nicht so superschnell,
aber reicht dafür locker aus. Die Aussteuerung sollte möglichst so bei 6
Div-pp liegen, damit man auch was erkennen kann.
Die Signalfrequenz selbst ist eher unwichtig. Ich habe ca. 100KHz
verwendet. Pretrigger auf Bildschirmmitte stellen. Normal oder
Combi-Trigger einstellen, so dass die Flanke schön ruhig in der
Bildmitte steht. Die Timebase sollte mindestens auf 100ns stehen, besser
50ns, da hier erst die Frequenzeinflüsse des Signals richtig sichtbar
werden.
Dann sieht man schon ob die Kanäle ein Delay haben (Bild Delay01). Das
Delay so einstellen, dass die Flanken möglicht in Deckung sind(Bild
Delay02).
Wenn das erledigt ist, kann man sich um die Einstellung mittels der
kleinen Einsteller unter der Abschirmung kümmern. Dieser Abgleich dient
der Frequenzkompensierung des Eingangs! Das ist also nicht für
Gleichspannungen oder langsame Signale gedacht. Das ist vergleichbar mit
der Abstimmung eines Tastkopfes.
Beim Vergleich mit meinem anderen Oszi schien mir Kanal 1 am ehesten der
richtigen Signalform zu entsprechen, daher habe ich dann die anderen
Kanäle so abgestimmt, dass sie mit Kanal 1 deckungsgleich wurden.
Mit dem unteren Einsteller beeinflußt man die negative Halbwelle, mit
dem oberen Einsteller die positive Halbwelle.
Gruß Hayo
ok, wenn man Kanal 1 als Referenz nimmt, dann muß ja wohl an dessen C's
nicht geschraubt werden, es wäre also nur Kanal 2 einzustellen. Sehe ich
das richtig?
Gruß Michael
EDIT: Uff, du hast 31,6V P-P ?
Michael D. schrieb:> ok, wenn man Kanal 1 als Referenz nimmt, dann muß ja wohl an dessen C's> nicht geschraubt werden, es wäre also nur Kanal 2 einzustellen. Sehe ich> das richtig?
Ja richtig. Es sei denn der ist auch so verbogen, dass man beide Kanäle
richten muß. Halte ich aber für nicht so wahrscheinlich.
> Gruß Michael>> EDIT: Uff, du hast 31,6V P-P ?
Jupp mein uralter HP3310B Generator hat soviel raus.
Hayo
Erstmal Dank an alle, die in den beiden W2000A-Foren (Hardware und
Firmware) so produktiv arbeiten. Vor einigen Tagen habe ich mein W2022a
aus der Ecke geholt und statt der Welec 1.3 die BF 6.3 drauf gebracht,
ich war begeistert. Nach ein paar erfolgreichen Testtagen ist das Gerät
leider ausgefallen, es zeigt nur noch eine mit senkrechten Pixelstreifen
überlagerte Anzeige oder gar keine. Die Tasten reagieren nicht mehr, bis
auf die beiden linken unter dem Display, die das Loaden/Flashen
erlauben. Testweise habe ich noch 6.4 geflasht, das Logo erscheint auch,
ansonsten die Störung ist geblieben (vgl. Foto). Ich gehe von einem
Hardware-Problem aus. Bevor ich jedoch das Gerät entsorge (täte weh),
die Frage: hat jemand einen Hinweis zur möglichen Lösung des Problems?
Bitte entschuldigt, dass ich das hier poste, aber das ist wohl noch die
einzige Stelle, wo Expertise zum W2000 vorhanden ist.
Vielen Dank im voraus! Nicki
Nicki schrieb:> hat jemand einen Hinweis zur möglichen Lösung des Problems?
Kein Grund sich vom Gerät zu trennen - heiz schon mal den Lötkolben an.
Mein Tip wäre eine schlechte Lötverbindung beim RAM. Damit gab es schon
öfter Probleme. Die Experten sehen bestimmt aus dem Photo gleich,
welcher Baustein der schuldige ist.
Jupp, Wolfgang hat Recht, das ist das RAM. Das Display ist ins RAM
gemappt und wenn da einer oder zwei Pins schlechten Kontakt haben, gibt
es diese typischen Streifen. Es gibt eine zweistufige Lösung. Da es zwei
RAM Bausteine gibt, würde ich erst den am leichtesten Zugänglichen in
Angriff nehmen. Dazu brauchst Du nur den rückwärtigen Deckel mittels der
drei Schrauben zu lösen, und dann hast Du den ersten RAM-Chip schon vor
Dir. Es ist der Chip direkt am Display-Stecker unterhalb der ersten vier
ADCs. Da einfach mit der Spitze des Lötkolbens auf alle Pins einmal
drauftippen und dann nochmal testen, ob es weg ist. Wenn nicht....der
zweite Chip ist direkt unter diesem Chip auf der Rückseite. Dazu mußt Du
die Hauptplatine ausbauen.
Oberteil vom Netzteil abschrauben (vier Schrauben), dann die beiden
Steckerchen abziehen, die von der Netzteilplatine ans Display gehen. Als
nächstes den Displaystecker lösen und die Befestigungsschraube der
Hauptplatine. Die Drehknöpfe auf der Frontseite müssen leider auch ab.
Die sitzen zum Teil sehr fest und lassen sich mit einem sehr kleinen
Schraubendreher abhebeln gegen den Rand auf der Achse, wo der
abgeflachte Achsenteil anfängt.
Die Muttern der BNC-Anschlüsse lösen und die Hauptplatine ist raus. Bei
dem zweiten RAM-Baustein ebenfalls die Pins nachlöten. Das sollte es
gewesen sein. :-)
Gruß Hayo
p.s. Wie Ihr schon gemerkt habt gibt es hier an der Ski-Piste WLAN -
welch Glückes Geschick, tirili...
> p.s. Wie Ihr schon gemerkt habt gibt es hier an der Ski-Piste WLAN -> welch Glückes Geschick, tirili...
Das glaub ich doch jetzt nicht...der Hayo fährt mit dem Laptop Ski, da
freut sich Petra bestimmt ;-)
Danke Wolfgang und Hayo für den guten Zuspruch und die unglaublich
schnelle Hilfe. Ich hab den Kasten aufgemacht und bin zu dem Schluss
gekommen, dass ich ohne Lupe und spezielle Spitze besser nicht an die
SMT-Lötstellen rangehe. Sobald ich ein Ergebnis habe, melde ich mich
zurück. @Hayo: WLAN an der Piste, wie hat man sich das vorzustellen? Auf
den Brettern, Ski-Handschuhe ausgezogen und dann mit dem Smartphone...
;-)
Grüße, Nicki
Haha, ja das wär cool. Nein, ist ganz einfach, wir wohnen in einer
Pension direkt neben der Piste und die hat WLAN. Ist also nur halb so
spektakulär.
Aber noch ein Tip zum Probieren: Es kann sein, dass es schon reicht beim
Hochfahren leichten Druck auf den RAM-Chip auszuüben. Möglicherweise
geht es dann schon wieder und Du weißt dass es an diesem Chip liegt.
Gruß Hayo
Leider waren alle Versuche negativ. Löten mit 300°C Spitze die
RAM-Beinchen sekundenlang angetippt, schließlich das ganze
auseinandergebaut und auch die andere Seite behandelt. (Danke für den
Tipp mit den Drehknöpfen!) Letztendlich zeigen sich im Moment keine
Streifen mehr, aber auch sonst gar nichts ;-). Weiterhin reagiert das
Scope nur noch auf die beiden linken unteren Tasten. Bildschirm hell,
dann dunkel. Ein paar LEDs leuchten dabei mal, mal so... Erstmal ein
schöne Tage im Schnee! Hast Du Dir verdient! Grüße, Nicki
Nicki schrieb:> Letztendlich zeigen sich im Moment keine> Streifen mehr, aber auch sonst gar nichts ;-)
Hallöchen,
auch dabei möchte ich Dich ermutigen, da ich das Gleiche durchmachen
musste. Du hast beim Löten ggf. 2 Beinchen kurzgeschlossen. Bei waren es
ausgerechnet die 3,3 V ca. in der Mitte des Bausteines.
Bitte löte noch einmal alles mit VIEL Flussmittel nach!
Gruß Andiiiy
Ausfall meines W2022A:
Danke für den Zuspruch. Ich hab noch mal einen Anlauf genommen und alle
Pins an dem RAM Baustein nachgelötet.
Ergebnis unverändert. Flashen per WelecUpdater scheint noch zu gehen.
Der Bildschirm bleibt aber dunkel. Ich werfe das Handtuch.
Grüße, Nicki
Nicki schrieb:> Der Bildschirm bleibt aber dunkel. Ich werfe das Handtuch.
Hallöchen,
ich kann aus eigener Erfahrung sagen, dass es sich schon lohnt etwas zu
warten. Solche Fehler müssen etwas reifen ... (bei mir ca. 6 Monate) ...
und dann geht es in 5 Minuten wieder! Die Freude ist dann um so größer
...
Da es in absehbarer Zeit das neue Design geben wird, wäre ein gänzliches
Aufgeben nicht so sinnvoll.
(Jörg ich möchte Dich nicht antreiben -;)
Grüße Andi
Hi, bin wieder im Lande. Hier gibt es ja mehr Schnee als in den Alpen -
das braucht ja Keiner!
Zu Deinen RAMs: Wenn der Verdacht besteht, dass es Kurzschlüsse zwischen
den Beinchen gibt kann Entlötlitze helfen. Einfach quer über die
Pinreihe legen und dann die Reihe mit der Lötspitze abtupfen. Dadurch
wird alles was an überflüssigem Lötzinn haltlos rumwabert von der
Entlötlitze abgesogen, und nur der Teil bleibt übrig, der vom Übergang
Pin zu Pad gebunden wird.
Gruß Hayo
Also als Erstes müssen wir mal feststellen, was noch geht. Dazu mit der
üblichen Prozedur die aktuelle Firmware flashen. Dann das Gerät wieder
ausschalten. Jetzt ein Terminal mit den bekannten Einstellungen
(Anleitung liegt im doc Verzeichnis) starten und danach das DSO starten.
Anhand dessen, was jetzt ausgegeben wird (oder auch nicht) kann man
schon mal abschätzen ob zumindest die Firmware läuft. Wenn die normale
Startausgabe erscheint, kann man versuchen einige Remotefunktionen
aufzurufen. Eine ganz einfache Testmöglichkeit ist der Frame-Counter,
den man mit Shift + K aufrufen kann.
Gruß Hayo
p.s. Beim Nachlöten ohne Lötzinn kann es sein, dass sich beim Erhitzen
das eine oder andere Beinchen etwas angehoben hat und dadurch der
Kontakt zum Pad ganz unterbrochen wurde. da müßte man dann mit etwas
Lötpaste nachhelfen. Die Lötpaste hat auch den Vorteil, dass sie sehr
viel Flußmittel enthält, was einem sauberen Verlauf sehr entgegen kommt.
Dein Problem ist mit großer Sicherheit eines oder mehrere der
RAM-Beinchen. Sobald diese wieder richtig auf den Boden der Tatsachen
zurückgebracht werden (sprich aufs Pad) sollte die Kiste auch wieder
laufen.
Ich melde mich auch mal wieder...
Während Hayo sich im Skizirkus vergnügte war ich letzte Woche schwer
grippekrank. Üble Sache, für die Zukunft empfehle ich impfen.
Am Wochenende davor hatte ich Alex' Samplespeicher überarbeitet, so das
er für die Software besser zu benutzen ist und in allen Situationen die
volle Kapazität nutzbar ist. Wir nicht mehr 16K pro Kanal, sondern 32K
pro FPGA. Wenn man nur einen der 2 Kanäle eines FPGAs benutzt, dann
steht doppelte Speichertiefe zur Verfügung.
Erst hatte ich da falsch gedacht, aber mit einem etwas anderen Ansatz
funktioniert es. Die Daten müssen beim Auslesen leider meist byteweise
umformatiert werden, aber neuerdings immerhin cache-freundlich. Sie beim
Reinschreiben in voller Breite richtig zu drehen wäre leider sehr
aufwändig, eventuell könnte ein späterer Umkopier-DMA-Controller aber
sowas leisten.
Na gut, ich lasse das mit den Details. Ansonsten schaut es gut aus mit
der neuen Hardware, "eigentlich" ist sie für den 2Kanäler bereits
fertig.
Letztens WE habe ich, wieder genesen, die Softwareseite bearbeitet. Der
gemeinsame Speicher erfordert ein deutlich unterschiedliches Konzept.
Damit bin ich noch nicht zuende.
Jörg
Gestern beim Feierabendbier mit Andi (bin gerade beruflich in Dresden)
kam uns eine Idee:
Es müßte eigentlich ein Leichtes sein, dem Welec einen VGA-Ausgang
nachzurüsten. Das interne Display hat VGA-Auflösung und -Timing. Wenn
die Sync-Impulse noch nicht ganz passen sollten, so könnte ich das
zumindest beim neuen Design passend einstellen.
Man muß die 3 Bits pro Farbe über Widerstände R2R-mäßig zusammenführen,
um je eine Spannung draus zu machen. Die Syncsignale müßten bereits
passen. Bauteileaufwand im Minimum also 9 Widerstände und eine
VGA-Buchse.
So ähnlich wie dieser Kollege sein Board verdrahtet hat:
http://www.pyroelectro.com/tutorials/fpga_vga_resistor_dac/schematic.html
In schönerer Ausführung könnte man eine Platine mit Zwischenstecker für
den LCD-Anschluß machen. Dazu noch Treiberstufen, damit ESD an der
VGA-Buchse nicht bis ins FPGA blitzt...
Ich brauche allerdings keinen VGA-Ausgang. Damit mögen sich gern andere
beschäftigen. Dies nur als kleiner Projekttipp. ;-)
Jörg
W2022 Ausfall: SMDs löten ist offensichtlich nicht mein Ding. Nach dem
letzten Nachbesserungsversuch an den RAMs zeigt nun auch das Drücken der
beiden "linken Tasten" keine Reaktion mehr. Langer Rede kurzer Sinn:
Damit noch etwas Sinnvolles mit dem Gerät geschieht (Ersatzteillager
etc.) würde ich es gern einem "Aktivisten" hier in der Gruppe schenken.
Hayo, hast Du evtl. Interesse? Ich würde mich dann per PN melden. Grüße,
Nicki
Ich wollte demnächst mal einen Gesuch-Aufruf nach einem hoffnungslos
defekten Gerät starten, bzw. eigentlich reicht uns die Hauptplatine.
Der Hintergrund davon ist, das wir nicht 100% sicher sind, alle
FPGA-Verbindungen zu kennen, ob die Hardware vielleicht noch unbekannte
Möglichkeiten hat, die das neuen FPGA-Design nutzen könnte. Dazu müßte
man von einer "Opferplatine" das (erste, beim 4Kanäler) FPGA auslöten,
und den USB-Chip. In der Firma haben wir geeignete Infrarotlöttechnik.
Aber wieder zusammenbauen ist schwierig, mühsam und nicht ohne Risiko
(erfordert FPGA-Reballing), deshalb lieber mit einer Opferplatine.
Nicki, ich glaube aber nicht das dein Gerät das gesuchte Opfer ist, das
hat bestimmt nur ein kleineres Problem. (Es sei denn, du hast bei deinen
Lötversuchen alles zerbrutzelt.)
Jörg
Hi Nicki,
ja klar, ist eine Idee. Ich sehe mir das mal an. Vielleicht ist es nicht
so schlimm. Wenn es mit wenig Aufwand wieder herzustellen ist kannst Du
es danach auch gerne wieder haben oder wir stellen es als Testgerät den
Hardware-Spezis zur Verfügung, oder einem anderen armen Schwein dessen
Gerät nicht mehr so richtig will.
Schick mir mal ne PN.
Hayo
Jörg H. schrieb:> Ich wollte demnächst mal einen Gesuch-Aufruf nach einem hoffnungslos> defekten Gerät starten, bzw. eigentlich reicht uns die Hauptplatine.
Ich glaube auch nicht das dieses Gerät defekt ist.
Sollte es aber wirklich am Ende sein - gebe ich Jörg recht - wäre es ein
optimales Opfer für den Schaltplan. Erste wichtige Fragmente sind nun
auch schon digital im Eagle-Format.
Grüße Andi
Jörg H. schrieb:> Gestern beim Feierabendbier mit Andi (bin gerade beruflich in Dresden)> kam uns eine Idee:
Ach? Da würde ich doch glatt mal ein Bier mit trinken. ;-)
/Hannes
Johannes S. schrieb:> Jörg H. schrieb:>> Gestern beim Feierabendbier mit Andi (bin gerade beruflich in Dresden)>> kam uns eine Idee:>> Ach? Da würde ich doch glatt mal ein Bier mit trinken. ;-)>> /Hannes
Da müssen wir uns beeilen, ich habe heute den letzten Feierabend vor
Ort!
Jörg
So hier mal ein Screenshot von der neuen BF.6.5 - zur Zeit noch beta.
Man sieht hier den neuen Peak Detect Modus an dem ich seit einiger Zeit
arbeite.
Aber jetzt denkt Ihr bestimmt - wie offtopic hier im Hardwarethread.
Nein, falsch, ich wollte eigentlich nicht die neue Firmware vorstellen.
Was völlig Anderes - der Screenshot ist gemacht mit Nickis DSO, das
heute bei mir angekommen ist. Eigentlich wollte ich erst am Wochenende
ran, dann hat es mir aber doch keine Ruhe gelassen. Tatsächlich waren
einige Pads von den Bahnen abgerissen und es etwas gefummel unter dem
Mikroskop um das wieder hinzukriegen.
@Nicki
Willst Du das Ding wieder haben?
Gruß Hayo
Hallo Hayo,
wo wird "Peak-Detect" aktiviert und was hat damit auf sich?
BtW. wenn du schon dabei bist...
Im Quickmeasure zickt die Rise u. Fall-Time Messung. Es wird ab u. zu
statt "µs" nur "s" angezeigt und natürlich wird dann auch kein Wert
angezeigt bzw. 0s.
Kannst du mir folgen?
Vielleicht schaust du mal nach, bevor du die neue Version raus bringst?
Gruß Michael
Hi Michael,
ich vermute Du hast für die Rise/Fall-Timemessung eine zu kleine
Zeitbasis eingestellt. Dann reichen ihm die Punkte zur Messung nicht
mehr aus.
Mach mal einen Screenshot - aber dann im Firmwarethread.
Gruß Hayo
p.s. zu Peak Detect sag ich noch was, muß erst mal die beste aller
Ehefrauen bekochen. Ist wegen der Bastelei etwas spät geworden.
ich hatte verschiedene Zeitbasen benutzt. Zwischen ms und ns wurde eben
s angezeigt und nur mal sporadisch µs, also fehlt doch was zwischen ms
u. ns, oder? Also Nanosekunden wurden ja wieder gemessen.
Mache dann ein paar Shots... muß jetzt auch erstmal was essen
Gruß Michael
@hayo: mir fällt ein Stein vom Herzen. Ich hatte das W2022 schon
halbwegs abgeschrieben, aber die Hoffnung stirbt zuletzt! Danke!!! Unter
diesen Umständen möchte ich das Gerät gerne weiter benutzen. Über den
Rest schreibe ich eine PN.
Grüße, Nicki
Mal wieder ein kurzer Bericht aus dem WELEC Forschungslabor:
Ich habe die Gelegenheit Nickies DSO hier zu haben mal dazu genutzt
Vergleiche anzustellen. Dabei habe ich festgestellt, dass es anscheinend
zwischen den verschiedenen Hardwarerevisionen Performanceunterschiede
gibt.
Ich habe mit gleicher Firmwarversion und identischen Einstellungen den
Framecount bei verschiedenen Funktionen gemessen (Trigger NORMAL,
200mV). Jedes mal mit vergleichbaren Ergebnissen. Zum Vergleich hier die
Ergebnisse für Zweikanalbetrieb bei 200ns/Div, alle Filter aus.
Mein W2022A - 8C7.0G: 1320 Frames/min
Nickies W2022A - 8C7.0F: 1213 Frames/min
Mein W2014A - 8C7.0L: 1116 Frames/min
Alle Messungen mehrfach durchgeführt mit Schwankungen von +/- 4 Frames.
Wenn ich die neue Firmware fertig habe, würde mich mal interessieren
welche Werte da bei Euch rauskommen. Mit der "alten" BF.6.4 C6 läßt sich
das leider nicht vergleichen, da ich in der neuen Version einige
Performanceverbesserungen vorgenommen habe und diese daher schneller
ist.
Ich kann mir die Unterschiede momentan nicht so richtig erklären.
Mögliche Ursachen könnten Bauteiletoleranzen sein z.B. beim Schwingkreis
der den Takt für den FPGA vorgibt, oder FPGA-interne Unterschiede.
Gruß Hayo
Der Oszillator kann es nicht sein, weil du das Gerät mit sich selber
mißt. Es ist ja keine weitere "neutrale" Zeitquelle an Board.
Ich könnte mir vorstellen, das ein Gerät mehr rauscht und schneller
triggert?
(Davon ab finde ich persönlich das Mysterium eher uninteressant, alte
Hardware, Frames pro Minute, hihi)
Jörg
Jörg H. schrieb:> Der Oszillator kann es nicht sein, weil du das Gerät mit sich selber> mißt. Es ist ja keine weitere "neutrale" Zeitquelle an Board.
Das würde ich so nicht sagen, denn die neutrale Zeitquelle ist die
Stoppuhr mit der ich die Die Meßintervalle ausmesse. Es könnte also rein
theoretisch auch der Oszillator sein und das würde sich auch auf das
neue FPGA-Design auswirken.
ZUm Messvorgang:
Ich Starte die Messung mit Shift + K und beende sie nach genau einer
Minute wieder ebenfalls mit Shift + K (via Terminalprogramm). Die
Zeitmessung mache ich mit einer Stoppuhr. Der Framecounter wird bei
jeder Bildschirmausgabe um eins hochgezählt. Bei Shift + K wird der
aktuelle Stand auf dem Bildschirm ausgegeben und der Zähler wieder
zurückgesetzt.
Kann also jeder bei seiner Kiste selbst testen.
Gruß Hayo
Ja, ich brauchte eine einfache schnelle Möglichkeit die Wirkung von
Performanceoptimierungen zu testen. Da war das die beste Möglichkeit -
und es kann jeder auch an seiner Kiste selbst testen ohne in einen
speziellen Testmodus schalten zu müssen.
Btw. es wird ja immer so über das WELEC geschimpft, aber ich muß an
dieser Stelle auch mal was Positives sagen. Auch wenn die Schwächen
allseits bekannt sind kann man mit dem DSO sehr schön auf Fehlersuche in
defekten Geräten gehen.
Aktuelles Beispiel:
Ich habe mir gerade einen 100MHz Pulsgenerator in der Bucht geschossen
um besser an unserem DSO herumtesten zu können. Wie das Leben so spielt
ist das Teil leider defekt. Ich bin dann erstmal mit dem analogen
Tek2465A (dessen Qualitäten ja bekannt sind) rangegangen um die
Signalwege durchzumessen. War etwas mühselig. Ich habe dann mein W2014A
genommen und mir dann das Signal der triggernden Taktquelle auf Kanal 4
gelegt, und dann die Messpunkte der anderen Stufen auf die andern
Kanäle. Das Ganze bei 80 - 100 MHz wohlgemerkt.
Man konnte schön alles im Überblick sehen und das Problem war schnell
eingekreist. Ersatzteile sind bestellt...
Ich benutze das WELEC ja eigentlich nur zum Programmieren, aber da war
ich doch angenehm überrascht.
Gruß Hayo
Neues von WELEC:
Angeregt durch Nicki habe ich mal die Bucht durchforstet nach Angeboten
zu unserer Kiste. Und siehe da, Wittig verkauft tatsächlich wieder
W2022A Modelle für 190 Euronen. Anscheinend jetzt unter neuem
Verkäufernamen wscop. Wie ich den Bewertungen entnommen habe ist unsere
Gemeinde potentiell um 9 Mitglieder angewachsen :-)
Btw. kommt jemand aus der Region Berlin? Dort macht gerade einer seinen
Keller leer und haut seinen ganzen Bastelbestand in einem Rutsch raus.
Unter anderem ist auch ein W2022A dabei. Leider wegen der Menge nur mit
Selbstabholung. War schon am überlegen....aber 300 Km hin und nochmal
300 zurück...
Gruß Hayo
Hi,
ich bin so einer der bei der Bucht für 190 ein W2022 direkt bei Herrn
Wittig gesteigert hat.
Was meint Ihr, ist das jetzt ein Reinfall?
Wenn nein, was würdet Ihr mir empfehlen?
Wie soll ich vorgehen, muss ich jetzt erst den FPGA flashen?
Und dann die Firmware?
Und wenn ja, was ist die am weitesten fortgeschrittenste?
Blick das ganze hier noch nicht ganz, muss ich auch was an der HW was
tun?
LG Martin
Hallo Martin,
nein kein Reinfall. Das Gerät hat zwar einige Schwächen und die
originale Firmware ist schlicht Schrott (praktisch nicht benutzbar) aber
mit einem Update wird das Gerät zu einem praktischen Helfer im
heimischen Labor.
Wenn Du vor SMD-Löten nicht zurückschreckst bieten sich auch noch einige
Hardwareverbesserungen an.
Am FPGA mußt Du erstmal nichts machen, das ist ein Projekt das noch in
den Anfängen steckt und nochmal deutliche Verbesserungen verspricht.
Weiterhin arbeiten wir auch noch an einer neuen Plattformunabhängigen
Firmware die sich ebenfalls noch im Entwicklungsstadium befindet. Der
Thread ist hier ->
Beitrag "made from scratch Firmware für Wittig/Welec Oszilloskop W20xxA"
Du lädst Dir am Besten erstmal die aktuelle Firmware runter (BF.6.4.C6),
die findest Du im Firmwarethread ->
Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware (Teil5)"
oder bei sourceforge net. Auf der Wiki-Seite findest Du alles Wichtige:
http://sourceforge.net/apps/trac/welecw2000a/
Downloads hier:
http://sourceforge.net/projects/welecw2000a/?source=navbar
In dem doc-Verzeichnis des Firmwaredownloads findest Du genauere
Anleitungen und Infos.
Oder auch hier:
http://sourceforge.net/apps/trac/welecw2000a/wiki/FWupload
In Kürze:
- Du brauchst einen RS232 Anschluß an Deinem Rechner! Die
USB-Schnittstelle wird nicht unterstützt (zu langsam)!
- das originale Flashprogramm von WELEC kann man nicht verwenden!
- es gibt ein Windowsprogramm (WELEC-Updater), das aber sehr langsam
ist.
- bessere Wahl ist, Dir Perl zu installieren (Windows -> active Perl)
bei Linux ist es ohnehin an Bord.
Weiterhin brauchst Du den seriellen Porttreiber Win32-SerialPort.
Damit kannst Du dann sowohl unter Linux als auch unter Windows das
mitgelieferte Perlscript benutzen, welches den Upload in 180 Sekunden
erledigt (statt 20 - 40 Minuten)
- Eine Flashsequenz wird immer eingeleitet, in dem das Gerät in den
Monitormodus gebracht wird.
- Gerät einschalten
- ganz linke Funktionstaste drücken und gedrückt halten. Jetzt
zusätzlich kurz die zweite Funktionstaste von links drücken und wieder
loslassen. Jetzt die ganz linke F-Taste loslassen. Der Monitor leuchtet
kurz hell auf und wird dann schwarz - der Upload kann beginnen.
Wenn Du weitere Fragen hast, dann poste das einfach im Firmwarethread.
Wenn Dein Upload geklappt hat, berichte mal ob es Dir gefällt oder was
Du an Verbesserungsvorschlägen hast.
Viel Spaß
Hayo
Ach ja, noch ein kleiner Nachschlag.
Wenn Du erst mal nur probieren möchtest, dann kannst Du statt zu flashen
auch die Firmware einfach nur ins RAM laden mit der Datei TomCat.ram
bzw. dem Script ramloader.bat (oder .sh unter Linux). Wenn Du das Gerät
ausschaltest, ist beim nächsten Start alles wieder wie vorher.
Hayo
Wie ich gerade in meinen Mails lese hat Nicki sein DSO inzwischen wieder
zurück und ist zufrieden.
Daher noch ein kleiner Hinweis für alle Neubesitzer eines WELEC DSOs.
Zwei kleine und einfache Hardwaremodifikationen sind auf jeden Fall
empfehlenswert. Materialaufwand:
- eine selbstschneidende Blechschraube ungefähr 4 x 10mm
- ein Tesafilmstreifen ca. 10cm lang
Es muß nur der rückwärtige Deckel mittels der drei Schrauben abgenommen
werden.
Mit der Blechschraube wird jetzt der Blechrahmen im Gerät an der Ecke
beim Ein/Ausschalter festgeschraubt. Bohrung und Aufnahme sind schon
vorhanden, Wittigs haben einfach nur mit der Schraube gegeizt. Durch das
Festschrauben wird beim Drücken der Netztaste und der Funktionstasten
der Rahmen nicht mehr so nach innen gedrückt.
Die zweite Modifikation ist hier beschrieben und sorgt für bessere
Belüftung:
http://sourceforge.net/projects/welecw2000a/files/Hardware/Modifications/
Datei Optimizing Thermal Design.
Wer mehr möchte kann sich vom zweiten Teil inspirieren lassen.
@Nicki
Ich war so frei bei Dir die Modifikation ungefragt vorzunehmen.
Gruß Hayo
kurze frage an hayo:
Warum dürfen sich die Kühlkörper nicht berühren?
Die oberfläche der ADCs ist doch eh nicht leitfähig... und kontakt zu
Metall haben die doch auch nicht?
@Hayo
jaja, diese dämliche Schraube hatte ich mal gesucht weil ich dachte, sie
wäre runter gefallen, dabei war die nie vorhanden...
@felixh
Weil die ADC's nicht alle plan aufliegen und deswegen, der eine oder
andere, keine richtige Verbindung mit dem Kühlkörper hätte.
Gruß Michael
Hallo Klaus,
ich freue mich, dass Du in unserer kleine Fangemeinde erhalten bleibst.
Ja ich war auch einige Zeit am Zweifeln ... genau diesen Fehler hatte
ich auch!
Grüße Andiiiy
felixh schrieb:> Warum dürfen sich die Kühlkörper nicht berühren?
Wie Micheal schon schrieb ist der Oberflächenkontakt nicht optimal wenn
man einen großen Kühlkörper drauf klebt. Aber was noch problematischer
sein kann ist bei Erwärmung die unterschiedliche Ausdehnung der Platine
unter den ADC und des Kühlkörpers auf den ADCs. Da kann es durch die
Verspannungen passieren, das sich die Beinchen der ADC nach einiger Zeit
von den Lötpads lösen und man kalte Lötstellen bekommt die mal
funktionieren und mal nicht - so einen Fehler zu finden ist schon eine
Herausforderung. Also auf jeden Fall auf jeden ADC einen eigenen kleinen
Kühlkörper kleben auch wenn es etwas mehr Mühe macht. Nicht vergessen,
die Oberfläche des ADC etwas anzuschleifen (Sandpapier) und mit Spiritus
zu entfetten, damit der Sekundenkleber gut hält. Wenn sich der
Kühlkörper löst und irgendwas kurzschließt ist der Jammer groß...
Gruß Hayo
Hi Hayo,
vielen Dank für diesen tollen "Empfang" hier in diesem Forum.
Die neue FW 1.2.BF.6.5 habe ich direkt mit deiner .bat
aufgespielt.(Perl)
(hab nen USB/seriell Adapter genommen)
KEIN VERGLEICH ZU VORHER ! ! - - -RESPEKT- - -
Auch den kleinen HW Mod hab ich grad gemacht.
Software soweit mal durchgetestet, vor allem das neue Peak Detect
gefällt mir. Min Max Points -> Super :-)
Hatte auch gleich nen Einsatz. (Hatte vorher kein Scope)
Mein Netbook Aspire One hatte immer geschwächelt wenn ich den USB Port
benutzte im Akkubetrieb. Im Netzbetrieb ging's immer.
Mit dem w2022 konnte ich das mal schön nachweisen :-) Genial
Nur wie kann ich das jetzt dokumentieren?
Ich hab da so ein w2000a Screenshot Tool probiert, er sagt aber meine HW
8C7.0E sei veraltet? Ich solle updaten...
Wie mache ich also ein Screenshot, bzw wie transferiere ich die Daten
zum PC?
gruß Martin
Danke für den Tipp mit der Verbindung fürn Screenshot, ja es ist
vermutlich so, dass ich das DSO danach aktiviert habe. Ich probiers heut
Abend nochmal.
Jetzt warum ich hier schreibe.
Was kann ich alles tun um HW zu verbessern.
habe was gelesen von nem Piggypack um die Auflösung zu verbessern?
Auch in SW Setup mit dem Widerständen?
Wo muss ich die Umlöten und vor allem was bewirken die
Widerstandsunterschiede?
Woher bekomme ich diese?
Typ 605? Toleranz 1% ?
Sorry für die vielen Fragen, bin noch nen Noop ;-)
gruß Martin
Martin Haßlöcher schrieb:> Was kann ich alles tun um HW zu verbessern.
Oh da gibt es Einiges. Angefangen bei größeren Lüftern, Kühlkörpern auf
den ADC, LEDs für die Triggeranzeige, Änderungen an der
PWM-Signalgenerierung für den externen Trigger, die Addon Eingangsstufe
oder die Widerstandsbestückung am Eingangsverstärker.
> habe was gelesen von nem Piggypack um die Auflösung zu verbessern?
Das ist etwas aufwändiger und wurde bislang meines Wissens erst von zwei
oder drei Leuten implementiert. Meine Platinen liegen hier auch noch und
warten auf den Einbau...
> Auch in SW Setup mit dem Widerständen?
Das ist eine relativ einfache Möglichkeit den Frequenzgang des Gerätes
gerade zu biegen und das Verhalten bei höheren Frquenzen zu verbessern.
Es gab eine Zeit lang unterschiedliche Widerstandskombinationen die
ausprobiert wurden, daher ist im Hardwaremenü noch ein weiterer Eintrag
vorhanden. Empfohlen ist aber die Kombination 2 x 24,9 Ohm / 1 x 174
Ohm.
Originalbestückung ist 2 x 0 Ohm / 150 KOhm. Ich habe bei mir statt der
174 Ohm einen 180 Ohm Widerstand mit Tendenz zu 178/179 Ohm eingebaut,
da ich hiervon eine 5000er Spule rumliegen habe.
> Wo muss ich die Umlöten
Rückseite der Hauptplatine. D.h. Du mußt diese ausbauen. Kurze
Ausbaubeschreibung hier:
Beitrag "Re: Wittig(welec) DSO W20xxA Hardware (Teil 2)"> Woher bekomme ich diese?
Ich kann Dir welche zuschicken, brauche dafür Deine Adresse...
> Typ 605? Toleranz 1% ?
0603 / 1%
> Sorry für die vielen Fragen, bin noch nen Noop ;-)
Kein Problem, dafür haben wir diesen Thread ja - und waren wir nicht
alle mal Einsteiger?
Gruß Hayo
Aus gegebenem Anlaß noch ein Hinweis zur Löterei an den
SMD-Widerständen.
Die Dinger sind so klein, dass man schon etwas spezielle Ausrüstung für
die Bearbeitung braucht.
- ein geregelter Lötkolben mit sehr feiner Spitze sollte es schon sein.
Die Temperatur sollte bei ca. 315 Grad liegen. Die Chinaboys bieten da
mittlerweile ganz anständige Lötstationen an. Mit einer Dachrinnenlöte
richtet man unter Umständen ziemliche Schäden auf der Platine an.
- sehr empfehlenswert ist die Verwendung von Lötpaste mit einem
Flußmittel welches hinterher nicht entfernt werden muß. Bei mir hat sich
CR 44 bewährt.
Wenn man Bauteile verwendet die man von Teileträgern abgelötet hat kann
es auch ohne gehen, bei neuen Bauteilen geht es nur mit Lötpaste.
- auch wenn ihr sonst keine Brille tragt - hier ist eine optische Hilfe
fast unumgänglich. Eine starke Lupenbrille (Uhrmacher) kann schon gehen,
besser ist ein Auflichtmikroskop. Da gibt es das günstige
USB-PC-Mikroskop das hier einige benutzen oder auch ein richtiges
Standmikroskop welches ich bevorzuge. Nur mit solchen Hilfmitteln kann
man wirklich alle Details beim Löten erkennen. Zum Thema USB-Mikroskop
gibt es ( im 1. Teil) einige Beiträge.
Beitrag "Re: Wittig(welec) DSO W20xxA Hardware"
Hab bei der Gelegenheit auch gleich den Hinweis zur Lage der Widerstände
gefunden:
Beitrag "Re: Wittig(welec) DSO W20xxA Hardware"
Gruß Hayo
Hallo, mich gibt's auch noch, oder wieder!
Ich habe einen ziemlich stressigen Arbeitseinsatz hinter mir, der meine
Freizeit deutlich eingeschränkt hat. Aber nun feiere ich Überstunden ab
und kann mich mal intensiver unserem Projekt widmen.
Hayo W. schrieb:> Am FPGA mußt Du erstmal nichts machen, das ist ein Projekt das noch in> den Anfängen steckt und nochmal deutliche Verbesserungen verspricht.
Kleiner Protest, die Hardware ist 'eigentlich' fertig, zumindest für den
2Kanäler. Bei Osoz gibt es noch einiges zu tun, wegen der
unterschiedlichen Organisation des Samplespeichers, bzw. allgemein mehr
Möglichkeiten. Die alte Hardware hat getrennte Speicher für jeden Kanal,
die neue einen gemeinsamen pro FPGA. Mit der alten Hardware hatten wir
im 'Normalfall' nur 4K Speichertiefe (Abtastrate <= 250MSa), weil beim
erstebenswerten Betrieb mit nur einem ADC blöderweise 3 von 4 Bytes
ungenutzt bleiben. Die neue Hardware hat (bei 8 Bit Auflösung) immer die
vollen 16K, schaltet man einen Kanal ab kann der andere dessen Speicher
mitnutzen und so kommen wir sogar auf 32K.
Heute habe ich für die Nios II Hardware eine Speichertest-Software in
Assembler geschrieben, die in die 512 Bytes des Boot-ROMs paßt. (Mit Ach
und Krach, nach viel Getüftel sind noch 2 Bytes frei.) So kann ich den
gesamten Speicher testen, denn das Testprogramm selbst steht nicht im
SRAM.
Es schreibt den Speicher mit Pseudo-Zufallszahlen voll und überpüft in
einem zweiten Durchgang den Inhalt, macht Ausgaben auf RS232 und
rudimentär mit den LEDs. So ein Durchlauf dauert nur 0,2 Sekunden (ich
habe einen coolen Zufallsgenerator gefunden, der nur 3 Befehle braucht,
ein LFSR), das Programm macht das in Endlosschleife mit immer neuen
Werten.
Bisher keine Vorkommnisse, läuft stundenlang ohne Fehler, es sei denn
man provoziert Kurzschlüsse am SRAM. Ich wollte 'schon immer' mal
getestet haben, ob ich meinem Businterface trauen kann. Bisher mache ich
das gedanklich für alle auftretenden gelegentlichen Instabilitäten
verantwortlich, aber ich muß mir wohl einen neuen Schuldigen suchen!
(Z.B. Software-Bugs?)
So long,
Jörg
Hi Jörg,
ich meinte mit den Anfängen auch eher den Gesamtstatus des Projektes.
Dass die FPGA-Seite schon recht weit fortgeschritten ist wollte ich
natürlich nicht unter den Tisch kehren. Nachdem ich jetzt in der
aktuellen BF Firmware eigentlich alles implementiert habe was die
Hardware noch so hergibt könnte ich eigentlich mal Funktionen für
Hardwareunabhängigen Teil von OSOZ schreiben. Bräuchte nur mal eine
Einweisung in den aktuellen Stand. Für den Anfang kannst Du mir auch
einfach sagen was wir brauchen und wo ich das implementieren soll.
Gruß Hayo
mal zurück zu meinem Spike Problem
(Beitrag "Re: Wittig(welec) DSO W20xxA Hardware (Teil 2)").
Habe endlich etwas Zeit gefunden und konnte das ganze mit Eisspray
tatsächlich auf die ADCs vom 2. Kanal eingrenzen (20°C Raum -> Spikes, 5
Minuten warmlaufen -> keine Spikes, Eis auf ADC Chip -> Spikes 2. Kanal
z.B. 200mV).
Leider brachte Nachlöten aber keine Abhilfe.
Das ganze tritt jetzt wie gesagt auch bei normaler Raumtemperatur und
den entsprechenden Zeitbasen "immer" auf, also ohne aufwärmen geht da
nichts mehr. Wie ich eingangs schon schrieb, das war vor einem Jahr
nicht der Fall, das wäre in diesem Maße definitiv aufgefallen. (Weswegen
ich ein Timing Problem in der Software/ FPGA Design ausschließe).
Übrigens brauchte wie zu erwarten war das Einspielen des Original- FW
Dump keine Besserung.
@sar brachte das bei dir wirklich Dauerhaft Abhilfe? Weil ansonsten
waren unsere Probleme fast identisch.
Werde jetzt mal als nächstes die ADC Bausteine tauschen.
Hallo Ben,
nein, tu dir das nicht an, die ADCs sind unschuldig, es ist wirklich ein
Timing-Problem.
(Mal davon ab braucht es eine Infrarotlötanlage um sie zu wechseln, die
haben unten drunter ein großflächiges Thermopad. Ist nicht ohne Risiko.)
Ich hatte die Spikes am Anfang auch weniger, jetzt mehr, und zudem bei
hohen Abtastraten auch Bildstörungen.
Mit dem neuen FPGA-Design ist der Spuk verschwunden, alles sauber.
Das Originaldesign hat eine haarsträubende Architektur, der Signalteil
arbeitet mit den vollen 250 MHz, was das FPGA klar überfordert. Das neue
Design arbeitet mit halbem Takt und doppelter Breite. So bleibt das
Timing in legalen Grenzen.
Jörg
aber die ADCs sind doch auf 250Mhz spezifiziert (zugegeben, Maximum) und
auch nur an denen habe ich einen thermischen Einfluss. Das FPGA kann ich
abkühlen wie ich will.
Warum entsteht ein Timing Problem zwischen September (Oszi funktionierte
OHNE jegliche Spikes) und Dezember (siehe Beiträge).
Habe doch auch mittlerweile rausgefunden, dass es jetzt auch bei 20°C
auftritt und auch OHNE Signal Spikes auf der Nulllinie vorhanden sind
(Kanal 2).
Alterung oder Defekt des ADC Chips daher für mich nicht auszuschließen
(Mit Heissluft geht das Auslöten, klar ein Risiko hat man immer).
Die Temperatur beeinflußt natürlich das Timing, verschiebt es in
gewissen Grenzen. Das heißt aber nicht, daß das Bauteil was du gerade
abkühlst/erwärmst und wo sich ein Effekt zeigt auch defekt ist.
Das originale Gesamttiming ist halt völlig kritisch. Ich kann dir nur
von meinen Erfahrungen berichten...
Die ADCs sind zwar für 250 MHz, dabei bleibt es auch mit dem neuen
Design, aber das FPGA nur in der Theorie (in einzelnen Bereichen),
praktische Designs erreichen das nicht.
Vor irgendwelchen Hauruck-Aktionen würde ich an deiner Stelle mal das
neue FGPA-Design ausprobieren. Dazu brauchst du Quartus, oder auch nur
die Standalone-Programmer Software von Altera, und entweder den
Slog-Treiber oder einen USB-Blaster.
Nochmal zur Löterei:
Mit Heißluft alleine würde ich da nicht dran. Da muß man den Chip schon
arg überhitzen damit auch die Unterseite und die Platine dort heiß genug
wird, es besteht die Gefahr das die Platine im offenen Bereich überhitzt
und "Blasen schlägt", sich die Lagen trennen, Durchkontaktierungen
aufreißen.
Mit einer Anlage die zusätzlich Unterhitze kann schon eher.
Jörg
Guten Morgen, Ben L.,Jörg H. und all jene die an dem Projekt beteiligt
sind Welec!
@Ben L.
Ich glaube, dass Jörg richtig ist, der ADC sind unschuldig.
Mir ist auch aufgefallen Probleme, zufällige Spitzen, die vollständig,
aber nichts war gebrochen.
Das Problem äussert sich mehr oder weniger stark nach den Situationen.
Firmware Hayo entwickelt haben sich enorm verbessert, das Problem, aber
es hat nicht gelöst komplett.
In der Tat, als er Jörg schreibt und andere vermuten, die gleiche Sache,
es Fehler in der Konstruktion des FPGA (Timing) sein.
Ich weiß auch nicht empfehlen, mit dem Schweißgerät zu intervenieren.
Es wäre gefährlich und wahrscheinlich vergebliche.
Viel besser, zu versuchen das neue FPGA Design von Jörg & C. und sehen,
was passiert, dann werden wir sehen, ob er nicht mit Schweißgerät
eingreifen.
Würden Sie immer pünktlich zu sein, nichts überstürzen.
Frohe Ostern an alle!
Mit freundlichen Grüßen,
Luc
Auch ich habe bei WSCOP auf eBay ein W2022A erstanden. Da ich mich hier
im Forum schon informiert hatte wusste ich ungefähr was ich zu erwarten
hatte. Tatsächlich ist das Gerät Dank Hayos Software eine feine Sache
und ich freue mich zu lesen, dass die Entwicklung weiter geht.
Es ist schon ein großer Schritt von meinem 70er Jahre HM207 mit HZ36
Vorsatz zu einem echten 2-Kanal Gerät. Nur an das Rauschen auf den
Signalen muss ich mich noch etwas gewöhnen.
Hier die Daten des Geräts das ich erhalten habe:
Model: W2022A
Hardware Version: 8C7.0E
FlashID: C293
Im Moment läuft 1.2.BF.6.4.C6 und das erfreulich geschmeidig.
Ich habe etwas weiter oben in Thread die Tipps an Martin gelesen, dazu
anderswo auch Vorschläge für zusätzliche Abschirmung.
Gibt es im Forum einen W20xxA Noob-Thread, damit wir Einsteiger nicht
immer in die produktiv-Threads reingrätschen?
Viele Grüße
Andy R.
Hallo Andy,
willkommen an Bord.
> Gibt es im Forum einen W20xxA Noob-Thread, damit wir Einsteiger nicht> immer in die produktiv-Threads reingrätschen?
Nein sowas gibt es nicht, aber es wäre eine Idee. Vielleicht mag ja
einer der frischen W2000A Besitzer so einen Thread anlegen und den Link
hier posten? Ich beantworte da auch gerne alle Fragen die einen als
Neubesitzer so beschäftigen, unter anderem auch zu den zusätzlichen
Funktionen die unsere alternative Firmware so bietet.
Gruß Hayo
Wie im Einsteiger-Thread angekündigt bin ich zur Zeit eher
hardwarelastig am arbeiten und suche eine Möglichkeit das Rauschen in
den Griff zu bekommen. Soviel zu diesem Zeitpunkt schon mal vorweg - ich
habe eine Möglichkeit gefunden, die recht einfach zu realisieren ist und
das Rauschen deutlich reduziert.
Um das Ganze noch rund zu machen arbeite ich im Augenblick an einer
Frequenzgangkorrektur die den Frequenzgang glattbügelt. Ohne die
Korrektur steigt die Amplitude ab 50MHz um etwa 10% an.
Ich werde meinen Mod demnächst mit einer angepassten Firmware hier
vorstellen.
Gruß Hayo
Hmmh, 10 % in der Amplitude ist doch unter 1 dB. Übertreib mal
nicht, das rächt sich meist an anderer Stelle. ;-) Ein
Präzisionsinstrument wird das Welec sicher nicht werden.
Grüße, Guido
Schönen Sonntag, Hayo und all jene, die an dem Projekt beteiligt sind
WELEC.
Hayo W. schrieb:
>Um das Ganze noch rund zu machen arbeite ich im Augenblick an einer>Frequenzgangkorrektur die den Frequenzgang glattbügelt. Ohne die>Korrektur steigt die Amplitude ab 50MHz um etwa 10% an.
Hayo, meinst du ein Software-Update für Geräte, die noch den
ursprünglichen Widerstände Fabrik?
Es scheint mir, dass mit den neuen Widerstände 24,9/174 Ohm, und bereits
mit denen von 24,9/150 Ohm Frequenzgang im Durchlassbereich flach sogar
übertraf 50MHz.
Mit freundlichen Grüßen,
Luc
Hi Luc,
You are right, but due to my newest hardware modification there is a
little failure in the frequency response. it is not so bad but I have an
idea to compensate it. I will present this solution in detail in some
days, but so far I can say it is working well and the noise is much
better with it.
Regards
Hayo
Gut Nachmittag, Hayo und all jene, die an dem Projekt beteiligt sind
WELEC.
Hayo W. schrieb:
>but due to my newest hardware modification there is a>little failure in the frequency response.
Do you mean the change of the resistors?
What is frequency where you detect the greater inconsistency?
And, how great is it?
Hayo W. schrieb:
>it is not so bad but I have an idea to compensate it.
All that who it can help to improve our DSO is welcome, so thank You for
the aid!
Hayo W. schrieb:
>I will present this solution in detail in some>days, but so far I can say it is working well and the noise is much>better with it.
Okay Hayo, we will see.
However, about the noise matter, I think a good solution already is the
pickaback developed by Branadic.
But like I wrote before all that who it can help to improve our DSO is
welcome, so thank You for the aid!
But like I wrote before all things who can improve our DSO are welcome.
;-)
Have a good afternoon Hayo.
Mit freundlichen Grüßen,
Luc
Luc schrieb:> However, about the noise matter, I think a good solution already is the> pickaback developed by Branadic.
Yes indeed, but for all those who didn't get one or those who prefer a
simple solution with good result this may be an interesting possibility
to modify the DSO for a better result. This solution only needs a few
SMD resistors and 2 or 4 SMD capacitors.
The only requirement is the eqipment for soldering SMD parts.
So long
Hayo