Hayo W. schrieb:>Ich hab das Gefühl, es wird nicht so> einfach sich da einzuarbeiten wenn ich wieder Zeit habe. Aber das Ganze> scheint wirklich gut durchdacht zu sein.
Na, ich hoffe es wird sehr einfach sein, liest sich wie ein Buch und
erklärt sich quasi selbst. ;-)
Im Erst, wenn die ganz wenigen Grundkonzepte klar sind ist es
hoffentlich wirklich einfach. Alles ist übersichtlich, es gibt keine
komplexen Riesenfunktionen und keine langen Dateien, die zugehörigen
Header definieren jeweils klar die Schnittstellen.
Wenn ich nun im UI keinen Unsinn anstelle bleibt das hoffentlich so.
Mit Doxygen fällt auf Knopfdruck eine Dokumentation raus, die sicher
noch verbessert werden kann.
>> Wenn Hayo auch sowas in seine Firmware einbauen täte,>> dann bräuchte ich auch nach einem Neustart in seine geflashte Firmware>> nicht mehr drücken.>> Habe das nur nebenbei so mitbekommen. Was müßte ich denn wo einbauen?
Wenn an der Schnittstelle eine Befehlszeile ankommt die mit "S2" anfängt
(und in Folge nur HEX-Ziffern hat, falls du das weiter verifizieren
magst), dann sowas in der Art tun:
1
// jump to the ROM monitor program, for bootstrapping
2
voidPlatformMonitor(void)
3
{
4
uint32_tstartaddress=na_boot_ROM_base+0x4A;// magic: behind the button / flash signature test
5
// note: stack and CWP may not be optimal, missing the init
6
void(*fnBoot)(void)=(void*)(startaddress/2);// half because of Nios-style jump, 16 bit instructions
Nächster Blog-Eintrag:
Die Offset-Kalibrierung ist jetzt drin. Sie dauert länger als in der
BF-Firmware (etwa 15 Sekunden), aber arbeitet hoffentlich auch
gründlicher. Ich mache eine Ausreißerelimination, um Spikes nicht mit in
das Ergebnis einfließen zu lassen. Der Durchschnitt wird mit einer
Festkommaberechnung bestimmt, kann also genauer sein als die eigentliche
ADC-Auflösung. Ferner mache ich ein Wägeverfahren (sukzessive
Approximation), um den Meßwert mit dem Offset-DAC möglichst genau in die
Mitte zu bringen, so bleibt der Amplitudenfaktor des jeweiligen
Meßbereichs außen vor, muß gar nicht bekannt sein. Das erfordert 16
Schritte pro möglicher Y-Verstärkung, bei jedem Schritt wird ein Bit
bestimmt, das verbliebene Intervall halbiert. Immerhin mache ich das mit
allen Kanälen parallel.
Noch nicht drin ist ein Splash-Screen mit einem Wartebalken oder so,
während das passiert. Ferner muß ich eigentlich die Bedienung
verriegeln, damit derweil keiner irgendwo dran rumdreht und mir unter'm
Hintern Offset, Amplitude oder Zeitbasis verstellt. Deshalb gibt es
heute noch kein nächstes Preview...
Die zweite neue Errungenschaft ist Persistenz ins Flash. Das neue
Persistenz-Modul meldet sich als View auf alle Werte des Modells an.
Wenn sich also irgendeiner ändert wird es aufgerufen und
startet/erneuert einen Softwaretimer, derzeit 10 Sekunden. Wenn dieser
Timer also zuschlägt wurde was verändert, aber ist nun seit 10 Sekunden
in Ruhe. Damit vermeide ich nervöses Abspeichern von Dingen, die sich eh
noch ändern.
Die Timerbehandlung macht dann noch mal einen Vergleich mit der letzten
Flash-Kopie (könnte ja sein das nur was hin- und hergedreht wurde) und
wenn das unterschiedlich ist wird wirklich gespeichert.
Im gewählten Flashsektor (ich habe den bisher unbenutzen Sektor 2
definiert) wird der Datensatz hintenangehängt. Es gibt dort eine Art
Listenstruktur, mit Länge und Versionsnummer, so das auch alte,
inkompatibel gewordene Einträge verbleiben können. Der Sektor muß nur
gelöscht werden, wenn diese Liste überläuft. Derzeit passen über 300
Dumps des Modells in den Sektor, das Modell speichert sehr kompakt. Es
muß also nur sehr selten gelöscht werden, was ja die Flash-Abnutzung
ausmacht und etwa eine halbe Sekunde dauert. Der Normalfall, die knapp
200 Bytes in einen frischen Flash-Bereich abspeichern geht unmerklich
schnell.
Zum schöneren Entwickeln mit Test-Ausschriften a'la printf() habe ich
nun stattdessen überall ein TRACE()-Makro verwendet. Das kann man pro
Datei an- und ausknipsen, und das tatsächliche Ausgabeformat zentral
festlegen, z.b. ein bestimmtes Anfangszeichen. Dann kann eine spätere
PC-Software die wegfiltern.
Ein ASSERT()-Makro gibt es auch schon seit einer Weile, falls ihr wißt
wovon ich rede... Damit kann man den Code in der Entwicklungsphase
spicken, um Bedingungen abzutesten die bei korrekter interner Funktion
erfüllt sein müssen, z.B. Parameterbereiche und Initialisierungen, statt
das wohlmöglich weich abzufangen und zuvor gemachte Fehler zu
"übermalen". Wenn so eine Bedingung nicht erfüllt ist bleibt die Kiste
mit einer entsprechenden Meldung stehen und der Entwickler muß
nachsitzen.
Auf meinen Feature-Aufruf hat bisher nur André reagiert, dafür aber mit
umso mehr:
"DPO Funktionalität... geht das oder reicht auch dafür der vorhandene
Speicher nicht aus? Zudem wäre Äquivalantzeitabtastung ein gutes Thema,
könnte unter Umständen auch hilfreich sein. Dann noch Funktionen nach
Stand der Technik... Histogramm der gesampleten Daten. Maskentest,
Interpolation: Linear und Sin(x)/x, Automatische Messungen: Mittelwert,
Effektivwert (RMS), Mittelwert Zyklus, Effektivwert Zyklus,
Standardabweichung Kurve, Standardabweichung Zyklus, Amplitude, Top
Level, Base Level, pos. Überschwingen, neg. Überschwingen,
Spitze-Spitze-Spannung, pos. Spitzenwert, neg. Spitzenwert, Periode,
Frequenz, Verzögerung, Phase, Burst-Breite, Anzahl Pulse, Anzahl neg.
Pulse, Anzahl steigende Flanken, Anzahl fallende Flanken, Pulsbreite,
invertierte Pulsbreite, Tastverhältnis, neg. Tastverhältnis,
Anstiegszeit, Abfallzeit, Triggerperiode, Triggerfrequenz,
Cursor-Messung: Spannung, Zeit, Spannung und Zeit, Verhältnis X,
Verhältnis Y, Anzahl Pulse, Spitzenwert, Effektivwert (RMS), Mittelwert,
Tastverhältnis, Burst-Breite, Anstiegszeit, Abfallzeit, Vertikaler
Marker, Mathematik: Addition, Subtraktion, Multiplikation, Division,
Maximum, Minimum, Quadrat, Wurzel, Betrag, positiver Anteil, negativer
Anteil, Reziprok, Invers, Integral, Differenzierung, log10, ln,
Tiefpassfilter, Hochpassfilter, FFT, Messkurven-Arithmetik: Off,
Envelope, Average, Smooth, Filter, Dezimationsalgorithmen: Sample, Peak
detect, High resolution..."
(Zitat Ende, hat er hauptsächlich bei R+S rauskopiert.)
Den DPO-Zahn mußte ich ihm mangels Speicher ziehen, ansonsten viel
Rechnerei mit den gesampelten Daten. Ich frage mich, ob das nicht
Prospektfeatures sind, einfach um möglichst viel auflisten zu können.
Da kann man sicher einiges von tun, falls sinnvoll. Die Architektur
beeinflußt das jedenfalls nicht.
Was mir aktuell etwas "Sorge" macht: ich beobachte mich dabei, den
MVC-Ansatz insofern zu mißbrauchen, als das ich auch reine GUI-Werte im
Modell unterbringe, wegen der praktischen Benachrichtigungen und nun
auch Speicherung. Man erkennt sie daran, das keine Hardwarefunktion
hinterlegt ist, sondern nur Views angemeldet werden. Eigentlich gehören
da nur Dinge für das "blinde" Oszilloskop rein, die GUI ist davon völlig
unabhängig ein View.
Die GUI könnte ihr eigenes Modell haben und einen ähnlichen Mechanismus
anwenden, um ihrer Komponenten Herr zu werden. Dann muß ich beide
speichern, das Scope-Modell und das GUI-Modell. Den Aufwand spare ich
mir z.Zt. noch.
So long,
Jörg
Ist ja nicht so das Echo hier...
Jetzt gibt es den Wartebalken und die UI-Verriegelung während der
Offsetkalibrierung. Ferner zum Test noch eine FPS-Anzeige der
Updategeschwindigkeit in der Statusleiste. Damit kann man schön
experimentieren, was Signalhöhe, Anzahl der Kanäle, Dots vs. Lines etc.
kosten.
Hier also die versprochene nächste Alphaversion. Die Amplitudenwerte
sind noch nicht ganz korrekt, aber das stört im jetzigen Stadium
hoffentlich nicht.
Viel Spaß beim Ausprobieren!
Jörg
Hi,
kurzes Lebenszeichen von mir. Bin gerade aus dem Urlaub zurück und im
Endspurt zum Schein. Mir brummt der Kopf vor lauter bekloppten
Formulierungen. Ich bin also erstmal noch auf den Background hier
beschränkt.
Ist aber interessant die Fortschritte mitzuverfolgen.
Gruß Hayo
könnte bitte jemand ein paar Videos von Osoz bei Youtube hochladen,
würde mir auch gerne mal ein Bild machen habe das Oszi aber ein paar
Wochen nicht zur Hand.
Branadic hat gemurrt, das Osoz so langsam ist, er erinnerte eine
Leon-Demo...
Der hat zwar mehr CPU-Power, aber mit seinem unglücklich organisierten
Bildspeicher kann da derzeit nichts Richtiges draus werden.
Wie auch immer, ich habe Osoz nochmal optimiert, jetzt ist es grob
doppelt so schnell. Hier im Anhang die "Turbo-Version".
Ich habe 3 Dinge getan:
1.) Die Kopierfunktion aus dem FPGA-Speicher ist jetzt auch eine
Assemblerfunktion vom Schlage memcpy32 und memset32, die mit maximal
schnellen Unrolling. Es gibt auch eine "Verwerfungsfunktion" für zur
Darstellung ungenutzen Speicher. Die ist noch schneller. (Man muß das
FPGA dummerweise immer komplett auslesen.)
2.) Von deaktierten Kanälen wird nur ein Dummy-Wort gelesen. Das ist
Minimum, braucht die Hardware anscheinend als Bestätigung.
3.) Es gibt eine neue Zeichenfunktion, die die Meßwerte nur mit
vertikalen Linien verbindet, nicht der allgemeinen Linienfunktion. Bei
>= 1 Sample pro Pixel kommt das visuell fast auf's selbe raus, ist aber
schneller. Sie ist nun der Standard, die normale aber auch auswählbar
(im Display-Menü).
Ein paar Zahlen:
Am schnellsten ist ein einzelner Kanal in Dot-Darstellung. Eine ruhige
Nullinie wird mit etwa 160 fps gezeichnet. In der neuen
Liniendarstellung sind es gut 100 fps, mit der klassischen 85 fps. Mit
mehr Kanälen teilt sich das entsprechend runter.
Mit Signal hängt es natürlich von der Höhe und dem "Füllgrad" ab. Mit
einem Rechteck, 2 Div hoch, 4 Flanken pro Div, komme ich in
Liniendarstellung auf 55 fps.
Aber das eigentliche neue Feature, was über's Wochenende in erster
Version fertig wurde ist die ADC-Kalibrierung. Die ist mit dieser
Version möglich. Ich kalibriere derzeit nur den Offset der ADCs
zueinander, später könnten es auch die Kennlinien werden. Ersteres tue
ich allerding sogar mit Subsample-Auflösung. Bei unserer gedehnten
Darstellung (Gridhöhe 400 Pixel, Aussteuerung aber i.d.R keine 200
Digits) macht sich das positiv bemerkbar. Die Samples werden zur
Kalibrierung heftig gefiltert, wegen der Ausreißer.
Die kriege ich speziell in dem 1GHz-Modus (Zeitbasis auf Subsampling=1).
Kann man mit den Offsetreglern schön erforschen, besonders in
Dot-Darstellung. Es gibt da so Schwellen, bei denen ein Grisseln zu ganz
anderen Meßwerten passiert. Es scheinen mir aber doch keine Bitkipper zu
sein, das paßt irgendwie nicht. (Meßwerte mit Dump ausgeben)
Thomas O. schrieb:> könnte bitte jemand ein paar Videos von Osoz bei Youtube hochladen,> würde mir auch gerne mal ein Bild machen habe das Oszi aber ein paar> Wochen nicht zur Hand.
Habe ich noch nie gemacht, überlasse ich gern anderen... ;-)
Soo viel gibt es auch noch nicht zu sehen.
Grüße
Jörg
Das Feedback hier ist nicht gerade motivierend... Immerhin haben Stand
heute sich 11 Leute mein letztes Osoz-Preview gesaugt, wenn auch
kommentarlos.
Letzte Woche ging es vielleicht deshalb etwas langsamer, ich habe mich
ein paar Tage um andere Dinge gekümmert.
Was trotzdem passiert ist:
Hauptfeature waren Umbauten in der Wave-Darstellung, um das Signal
zweimal unabhängig anzeigen zu können. Das ist natürlich um den
Bildschirm zweiteilen zu können, in Main und Delayed, Ausschnitt und
kompletter Sample-Speicher.
Liegt nun auf der entsprechenden Taste. Sie zeigt im Unterschied zur
alten Firmware kein Menü, sondern schaltet direkt zwischen den beiden
Darstellungen um. Das finde ich intuitiver. Die Gesamtdarstellung kostet
ziemlich Performance, zumindest wenn man alle Samples darstellen will,
was ich zur Zeit tue. Da treten merkwürdige Effekte des Capturings
zutage: Ich sehe mitunter einen Bruch an fester Stelle etwa in der Mitte
das Samplebuffers. Hoffentlich ist das nur falsche Benutzung der
Hardware, nichts Grundsätzliches. So langsam sollte ich doch mal was mit
Triggerung probieren.
Der Bildschirm wird übrigens asymmetrisch geteilt, etwa 2/3 Main, 1/3
Delayed. Finde ich besser proportioniert, dank der Displaytabellen kann
ich das ohne Geschwindigkeitsverlust frei einstellen. Das kleine Display
hat vereinfachte seitliche Marker, ohne weitere Angaben, das wird sonst
zu eng. Das Grid ist vereinfacht, die vertikale Linien machen dort
keinen Sinn, feinere Ablesehilfen auch nicht.
Ich will mit den beiden Modi auch eine Trennung von Samplerate und
Darstellungs-Zoom hinkriegen (Anregung von Branadic). Im normalen
Main-View täte man mit Dreh am Horizontalknopf die Samplerate verändern,
im dualen View hingegen den Ausschnitt, innerhalb sinnvoller Grenzen.
Das ist aber noch nicht drin.
Als kleineres Feature gibt es jetzt Offscreen-Pfeile für den Offset. Den
kann man legalerweise je nach Bereich recht weit aus dem Bild kurbeln,
bei Signal mit hohem Gleichanteil kann das auch nützlich sein. Jetzt
erscheinen entsprechend farbige Pfeile, wohin denn die Nullinie
entschwunden ist.
So long
Jörg
Hallo Jörg,
was du da leistest finde ich ganz toll. Ich lese jeden Beitrag von dir
mit wachsender Begeisterung und freue mich auf osoz.
Leider fehlt mir selbst die Zeit neben Beruf und Familie dich zu
unterstützen. :-(
Von mir auf jeden Fall ein großes Lob für deine geleistete Arbeit und
ich hoffe du bleibst weiterhin dabei.
Gruß
Dirk
Hallo Jörg,
ich lese auch jeden deiner Schritte interessiert mit - leider ist mein
Oszi halt noch immer hin, so dass ich noch nicht in den Genuss gekommen
bin, dein Werk mal live zu testen. Nach wie vor klingt alles wunderbar
durchdacht und deine Fortschritte sind erstaunlich.
Irgendwann werde ich schon mal dazu kommen, den Ram zu tauschen und mit
etwas Glück läuft die Kiste dann wieder...
Gruß
Michael
Hallo Jörg,
Oszilloskope sind eines meiner Steckenpferde und ich verfolge schon
lange die Entwicklung der Welec Firmware.
Ich war immer wieder positiv überrascht wieviel Einzelne (vor allem
Hayo) aus der vermurksten Kiste machten , was es an "Eigenheiten" zu
entdecken gab und wieviele Themenkomplexe bei der Entwicklung
auftauchten.
Diesen Thread habe ich eben erst entdeckt und in einem Stück
verschlungen (dauerte ~1.5h).
Hör bloß nicht auf, es ist einfach super und wirklich bewundernswert was
du da machst !
Hallo Jörg,
ich lese auch ganz regelmässig was sich hier abspielt.
Ich finde es wirklich beeindruckend, welchen akademischen Ansatz Du zu
dem Thema hast und habe irgendwie ein sehr gutes Gefühl dabei.
Mein Wittig-Oszi lebt seit Jahren mit der BF-Firmware und wird immer
besser,
doch ich spüre die Trägheit immer wieder und daher bin ich echt erfreut,
dass Dein Ansatz deutlich gesteigerte Geschwindigkeit ermöglicht.
Mit tatkräftiger Unterstützung kann ich leider nicht dienen, mangels
SW-Erfahrung die mit Deinen Standards mithalten kann, aber ich bewundere
Deinen Eisatz und warte sehnsüchtig auf eine halbwegs realitätsnahe
Firmware, die ich dann im echten Lben beurteilen kann.
Gib' bitte nicht auf, es ist sehr bereichernd, Deinen Blog zu lesen!
Hi!
Ich verfolge auch gespannt die Entwicklung der Firmware, bin aber eher
ein 'stiller geniesser'
Ich finde es ist der hammer, was du bisher auf die beine gestellt hast
(vorallendingen: wie schnell!), und warte wirklich ungeduldig darauf,
dass sie fertig wird. Bloss ausprobieren ist bei mir immer ein riesen
act, da ich nurnoch einen alten Rechner mit Serieller schnittstelle
habe.
Ich wünschte auch, ich könnte aktiv irgendwie mithelfen, aber meine
Kenntnisse in Software & co reichen gerade mal aus, um nen AVR irgendwie
zum laufen zu bringen...
Was ich aber wirklich cool fände, währe eine Pluginschnittstelle, wie
von dir allerdings bereits angeregt (fand es nicht nötig, dass zu
Widerholen...).
also, bitte nicht aufgeben!
Felix
Ich finde deinen Ansatz auch sehr gut - wenn man so ziemlich alle
Schwächen der bestehenden Software erkannt hat, eine komplett neue zu
schreiben (und nicht nur zu flicken).
Jetzt scheint mir allerdings die Zeit gekommen (da bei dir ja das
Grundgerüst steht), die Ressourcen zu bündeln und zusammen mit Hayo
etwas "massentaugliches" daraus zu machen (d.h. eine im Prinzip
funktionierende Alpha, mit der man das Oszi auch praktisch betreiben
kann).
Dann wird auch die Zahl der Tester sprunghaft ansteigen und das Feedback
um so besser!
Viele Grüße und weiter so,
egberto
Auch ich verfolge die Fortschritte voller Interesse,
muß mich aber aus zeitlichen Gründen zurückhalten. Kleiner Zwischenstand
- der SBF See ist geschafft, jetzt kommt der SBF Binnen und dann bin ich
wieder mit von der Partie.
Gruß Hayo
das ist doch easy.....
- Praxis und Untersuchung vom SBF See gelten 1 Jahr
- Binnen Buch kaufen, sich das ca. 1 Tag reinprügeln (die blöden Berg-
und Talfahrer usw.),
- theoretische Prüfung machen
also gibt es morgen bestimmt eine neue Version ;-)
Viele Erfolg!!
Fast richtig, wenn da nicht noch der blöde Beruf wäre. Ständig soll man
da seine Zeit verplempern...
Und dann abends noch den ganzen Lernstoff reinprügeln - da brauche ich
einfach etwas länger für. Prüfung ist am 9.Juni, dann ist der Drops
gelutscht und ich kann endlich wieder was Vernünftiges in Angriff
nehmen.
Gruß Hayo
p.s. an Ideen mangelt es nicht...
Hallo,
danke für's aufgescheuchte Feedback der stillen Leser. Keine Sorge, ich
bin nicht frustriert, nur weiß ich ohne halt nicht woran ich bin, ob das
eine relevante Anzahl Leute interessiert, usw. Bestimmt haben auch nicht
alle Stammleser der "etablierten" Threads diesen hier gefunden.
Etwas langsamer wird's in Zukunft: Beruflich zieht's gerade ziemlich an,
Gartensaison, Urlaubszeit, solcherlei. Aber es geht weiter, keine Sorge.
Um mitzumachen muß man nicht dasselbe tun wie ich, es gibt genügend
andere Betätigungsmöglichkeiten, willkürliche Beispiele: jemand
(typo)grafisch begabtes könnte gern die beiden Zeichensätze
überarbeiten, eine PC-Software als Gegenstück wäre nett, Gedanken über
Usability, Pflege von Doku+Wiki.
Richtig gut gebrauchen können wir FPGA-Expertise...
Jörg
Hallo Jörg,
auch ich bin schon lange ein stiller Mitleser und möchte dir sowie Hajo
und den anderen Entwicklern meine große Bewunderung zum Ausdruck
bringen, was Ihr mit dem Welec schon auf die Beine gestellt habt. Alle
Achtung! Gerne hätte ich auch etwas aktiv zum Gelingen beigetragen,
musste aus Zeitgründen aber leider verzichten.
Was mich mal interessieren würde: Wie seht Ihr dieses Projekt? Ist es
für euch immer noch eine rein sportliche Herausforderung, um alles aus
dem vorhandenen Welec herauszuholen, was machbar ist, oder geht es euch
jetzt in erster Linie darum, aus dem dank euch praxistauglich gewordenen
Gerät eines mit Mehrwert zu bekommen?
Wenn Letzeres der Fall wäre, würde es nicht Sinn machen, zumindest mal
darüber nachzudenken, die Schwachstellen des Welec komplett zu umgehen
und die rechenintensive Arbeit von einem Zusatzboard erledigen zu
lassen? Eure bisherige Glanzleistung in allen Ehren, aber man muss sich
das Leben ja nicht unnötig schwer machen. Z.B. würde sich der Raspberry
PI angesichts seines Preis-Leistungsverhältnisses und seiner geringen
Größe m.E. hervorragend als Zusatzboard für diverse Zwecke anbieten.
Soweit ich mich erinnern kann, wurde in diesem oder einem ähnlichen
Welec-Thread auch schon mal darüber nachgedacht, die Hauptplatine des
Welec aufgrund der analogen Probleme komplett zu ersetzen.
Jörg H. schrieb:> Richtig gut gebrauchen können wir FPGA-Expertise...
Wofür genau?
Vielleicht wäre es gut, wenn jemand von euch eine detaillierte
Todo-Liste anzufertigen könnte, so dass sich jeder stille Mitleser ein
konkretes Bild machen könnte, was benötigt wird, was bereits in Arbeit
bzw. schon erledigt wurde. Dann könnte ich vielleicht auch den einen
oder anderen Punkt finden, wo ich aktiv mithelfen kann.
Grüße
Ingo
Hallo Ingo,
mir persönlich geht es darum, ein praktikabel bedienbares Gerät draus zu
machen auf das man sich verlassen kann.
Ich habe mir vor gut 2,5 Jahren das Welec gekauft nachdem ich den
Monster-Tread hier entdeckt hatte, weil man dran rumbasteln kann, es
eine "offene" Plattform ist. Aber in der Praxis bewährt hat es sich noch
nicht. Es steht über Eck mit einem guten analogen Hameg, und zum Messen
benutze ich nur letzteres (plus einen kleinen USB Logic Analyzer). Liegt
wohl am Analoggefühl, alles passiert sofort, ich bin mir sicher das
Signal zu sehen und keine Unterabtasteffekte. Rein digital werde ich
also wohl nie glücklich...
In meinem Eingangsposting hier habe ich ja beschrieben, das für das
Welec deutlich mehr geht, wir aber in einer Software-Sackgasse steckten.
Daran arbeite ich nun also, nachdem ich jahrelang leider keine Zeit
dafür hatte. Ein bischen spät, das Welec hat den anfänglichen Schwung,
den Reiz des Neuen verloren, viele der damaligen Pioniere sind
mittlerweile abgesprungen. Aber das ist ja keine Einbahnstraße.
Zu den Zusatzboard-Ideen: Das Raspberry PI kenne ich auch (in meinem
Büro liegen seit Monaten zwei rum, lange bevor es offiziell erhältlich
war), aber ich halte das mit Verlaub für eine Schnapsidee. Ich wüßte
nicht, wie man das vernünftig anbinden sollte. Rechnen ist das eine,
aber es braucht auch eine schnelle Verbindung zur Capture-Hardware, also
einen breiten Bus. Den kriegst du da nicht dran, und selbst mit einen
dual-port-memory Adapter o.Ä. wäre es eine sehr anspruchsvolle Bastelei.
Da folgt dir keiner. Schon die neuen Eingangsstufen waren ja anscheinend
zu schwierig.
Was für "Probleme" soll es denn überhaupt lösen? Wenn wir auch das FPGA
mit was Eigenem im Griff hätten (soviel zu der Frage) mangelt es
eigentlich nur an Block Memory, um Dinge wie DPO zu realisieren.
Ein Redesign der Hauptplatine halte ich da schon für lohnender, aber wg.
geringer Stückzahlen wäre das nicht billig. Eine leere
Multilayer-Platine der Größe kostet wohl 200€, mit größerem FPGA,
aktuellen ADCs, Eingangsstufen sind schnell 1000€ erreicht. Man würde
dann vom Welec quasi nur das Gehäuse verwenden und ein neues Oszilloskop
reinbauen.
Darf man aber alles nicht wirtschaftlich sehen. Man spart kein Geld beim
Selbstbau. Wenn ich mich statt meiner Welec-Bastelstunden bei Mc Donalds
hinter den Tresen gestellt hätte, dann könnte ich schon ein Tek, R&S,
etc. hier haben. ;-)
(Und davon unabhängig, wenn ich eines haben wollte, dann stünde es auch
hier.)
ToDo-Liste: habe ich ja ansatzweise versucht, siehe die mittlerweile
alte Wiki-Seite. Ich dachte auch, es ist einigermaßen klar wo es
hingeht, was man für ein Oszi so braucht? Oder andersrum gefragt, was
kannst+magst du denn?
Zur besseren Motivation sucht man sich sein Betätigungsfeld ja selbst,
zuteilen klingt nicht nach Hobby+Freizeit. Wer etwas vermißt und sich
drum kümmern kann, der tut das dann.
Jörg
In der Tat sehe auch ich das rein sportlich! Es macht einfach Spaß daran
rumzuforschen und eigene Ideen einzubringen. Auch bei mir wäre es kein
Problem sich einfach ein teures Scope hinzustellen, aber darum geht es
nicht.
Gruß Hayo
Ich hatte es eh demnächst vor, nun fragte schon jemand per Email:
hier ist eine neue Probierversion von Osoz.
Was ist neu? Teils hatte ich es schon genannt:
- 2 Ansichten, Main und Delay
- noch etwas schneller, wegen min/max als Assemblermakro
- die Kanäle werden nahezu gleichzeitig in den sichtbaren Speicher
kopiert, vermeidet Wabbeln bei langsamen Zeichenmodi
- es wird gespeichert, in welchem Menü man gerade ist (und natürlich
beim Start wiederhergestellt)
- Zeitbasis wurde verallgemeinert, es gibt 2 mehr
- die Statusleiste zeigt jetzt die Samplerate an, statt kryptischem
Hardwareteiler
- die Pegel für Widerstandsumrüstung und neue Eingangsstufe stimmen
besser
Mit der Samplerate kann man ganz gut experimentieren. Die ist
erstaunlich fein einstellbar, speziell wenn's langsamer wird. Anfangs
wird das Gigasample 5 mal gehälftelt, aber dann sind es beliebige, durch
8 teilbare Teiler, bis hin zu grotesk langsam (32 bit Auflösung). Kommt
man mit dem derzeit linearen Zeitbasisknopf aber schlecht hin, das muß
ich noch vergröbern.
Und im Delay-View sieht man, was so im Speicher landet. Bei Kanal 1+2
gibt es da einen Bruch an Zufallsposition, das sollte eigentlich der
Anfang sein, da bediene ich wohl die Hardware noch nicht richtig.
So long,
Jörg
Hallo Jörg,
habe gerade mal deine Preview 3 auf meinem W2022A (8C7.0E) getestet.
Leider konnte ich sie nicht nutzen: Er erscheint kein Signal (nicht mal
eine Null-Linie zu sehen). Habe bisher nur den RAM Loader zum Testen
genutzt.
Die Menüs sind alle da und auch bedienbar.
Scheinbar wird das Oszi als 4-Kanaler erkannt? In der oberen
Statusleiste gibt es vier Einträge und auch die LEDs von Kanal 3 und 4
sind beleuchtet.
Habe deshalb gerade mal Preview 2 getestet, auch dort habe ich die
gleichen Probleme. Deine erste Preview läuft dagegen.
Allgemein großen Respekt vor deiner Arbeit, ist eine klasse Sache, dass
so viel Zeit in das Oszi investiert wird.
Gruß
Sebastian
Ich habe einen 4-Kanäler (wie du dir wohl schon gedacht hast), das mit 2
Kanal muß ich mal testen, soweit möglich. Es gibt eine zentrale
Auskunftsfunktion, die benutze ich auch eigentlich immer, aber kann
natürlich sein daß ich was vergessen habe.
Ich werde die mal testweise hart 2 Kanäle zurückliefern lassen und
gucken was bei mir passiert.
Interessant, daß die LEDs bestückt sind.
Von wegen kein Signal: Sowas habe ich auch manchmal, bei vielleicht 20%
der Starts. Vielleicht initialisiere ich die Hardware noch nicht so wie
sie es mag. z.B. mit bestimmtem Timing. Im Effekt kommt kein
Capture-Done-Interrupt, dessen Bearbeitung sonst das nächste Capturing
auslöst, usw. Diese Kette kommt dann nicht in Gang.
Jörg
Vor allem an die Zweikanaluser:
bitte probiert mal, ob sich hiermit was tut.
So recht testen kann ich die Zweikanalkompatibilität nicht (ich hab's
versucht), weil die tatsächlich vorhandenen FPGAs behandelt werden
müssen, mit weniger gibt es sich nicht zufrieden.
Was ich seit der letzten Version geändert habe:
- Es werden nur die verfügbaren Kanäle per Default eingeschaltet, nicht
alle 4, das könnte das Problem gewesen sein
- Im Persist-Modus wird der Kanal gelöscht, sobald man an Einstellungen
dreht
- Interne Vorbereitungen für verschiebbares Main-Window, bessere
Hardware-Abstaktion der Zeitbasen und des Samplespeichers
Grüße
Jörg
Hallo Jörg,
ich habe die pre4 mit dem Flashloader in mein 2-Kanal Welec geladen; das
Ergebnis ist ähnlich wie von Sebastian beschrieben: Am unteren Bildrand
erscheint eine durchgehende gelbe Linie, die sich nicht durch die
Kanaleinstellungen beeinflussen lässt. Sieht so aus, als würde
tatsächlich kein Capture stattfinden.
Mehrfaches Aus-/Einschalten brachte immer das selbe Ergebnis. Nach einem
Soft-Reset erscheint auch die Linie nicht.
Ich hoffe, die Info hilft dir etwas weiter.
Viele Grüße,
Ulrich
Der Jörg befindet sich momentan im Urlaub. Daher bitte nicht wundern,
wenn er in den nächsten Tagen nicht auf eure Probleme eingehen kann.
Ich selbst habe ein 4-Kanäler und konnte bis heute solche Effekte nicht
beobachten.
Habt ihr in den entsprechenden Kanaleinstellungen auch eure Hardware
korrekt ausgewählt (Kanal anwählen und die Hardwareeinstellung setzen)?
branadic
Hallo,
ich bin aus dem Urlaub wieder da (Italien retten, gibt ja nicht nur die
Griechen). Noch bin ich nicht wieder im Welec-Modus, die nächsten Tage
noch anderweitig abgelenkt.
Das mit dem 2Kanäler ist ja echt blöd. Kann ich wie gesagt nicht testen.
Mögliche Auswege: entweder ich finde noch was im alten Code, oder Hayo
hilft, er hat so ein "halbes" Welec als Zweitgerät.
Jörg
Hi, welcome back.
Es sind jetzt beide Prüfungen geschafft, aber auch ich bin momentan noch
etwas busy. Sobald ich wieder dazu komme kann ich da aber gerne
recherchieren.
Gruß Hayo
Hi, ich habe schon länger nichts mehr geschrieben, ist überfällig.
Nach meinem Urlaub bin ich zunächst nicht so recht wieder in Gang
gekommen mit dem Welec, ein paar andere Dinge wollten auch getan werden.
Erst seit einer Woche geht es wieder weiter.
Hauptsächlich habe ich einen neuen PC, Ivy Bridge i7 statt
Centrino-Notebook, SSD statt HD, und so weiter. Rattenschnell, Osoz
kompiliert in 2 Sekunden. Aber das hieß auch Neuinstallation, alle Tools
wieder installieren, das setzt einen für eine Woche außer Gefecht. So
recht fertig wird's nie, aber ich bin zumindest wieder arbeitsfähig.
Zurück zu Osoz:
Große neue Features gibt es noch nicht. Hauptsächlich sitze ich mit
Branadic an der Amplitudenkalibrierung, wie wir das am besten
hinkriegen. Die Exemplarstreuung ist wohl doch so hoch, daß man die
Meßbereiche besser individuell kalibriert. Der eingebaute Generator
taugt dafür nicht, er ist selbst zu ungenau. Man müßte also extern
bekannte Spannungen anlegen, oder dem Offset-DAC vertrauen und den als
Kalibrierquelle nehmen.
Die Widerstands-Modifikation, falls sich jemand erinnert: Statt 150 Ohm
Terminierung an den ADCs verwenden wir mittlerweile 174 Ohm. Es wurden
nämlich die Innenwiderstände der ADC-Eingänge übersehen, die liegen
parallel dazu und setzen den Wert herab. Mit 174 Ohm erhält man in Summe
die gewünschten 150 Ohm. Ansonsten sind es nur 132 Ohm und man
überlastet strenggenommen den Ausgangstreiber der Eingangsstufe, auch
stellen sich nicht die gewünschten Pegel ein.
In der Software habe ich hauptsächlich das Kommandozeileninterface an
der seriellen Schnittstelle ausgebaut, um dort Infrastruktur für ein
paar Testbefehle zu haben. Es gibt nun eine "richtige" Kommandozeile,
man kann die Zeile mit ANSI-Steuerzeichen des Terminals auch editieren,
es gibt eine History. Ferner ein paar Funktionen zum Parsen der
Argumente, damit kann man dann recht schnell Befehle zusammenbauen die
auch Parameter haben können.
Als nächstes habe ich einen Umbau der Meßdatenerfassung vor, so wie es
jetzt ist gefällt es mir noch nicht, wäre in Zukunft schwer zu warten.
Im Moment ist das ein ausuferndes Modul, was Daten captured, die Wellen
darstellt und im Sonderfall die Daten alternativ an die Kalibrierung
weiterreicht. In Zukunft will man noch Meßwerte bestimmen und hat
alternative Darstellungen, X/Y oder FFT.
Deshalb will ich die Aquisition von der Anzeige trennen. Irgendwie
müssen sich Datenabnehmer dann anmelden und werden aufgerufen.
Bis zu den nächsten aufregenden Features für User dauert es also noch
etwas.
Grüße
Jörg
Hallo Jörg,
jetzt bin ich auch endlich mal dazu gekommen, deine Previews auf mein 2
Kanal Welec zu flashen. Es werden quasi 4 Kanäle oben in der Leiste
angezeigt und auch die LED's dafür leuchten, jedoch gibt es auch bei mir
keine Signallinien, wie es bereits Sebastian u. Ulrich beschrieben hat.
Einen durchgehenden gelben Balken, kann ich nicht bestätigen. Die Menus
sind alle sichtbar u. auch anwählbar.
Gruß Michael
An der Zweikanalthematik habe ich noch nichts gemacht, hoffe das
aussitzen zu können bis Hayo dazustößt... (wink)
Mittlerweile bin ich mit meiner Umstrukturierung durch. Erfassung und
Darstellung sind getrennt, die Kalibrierung benutzt auch den neuen
Anmeldemechanismus. Das macht die Pflege in Zukunft einfacher.
Als nächstes will ich (zunächst experimentell) die ADCs mal einzeln
kalibrieren, Digit für Digit, automatisiert mit dem Offset-DAC. Bin
gespannt was da rauskommt. Könnte ein Schritt in Richtung Linearisierung
der 4 ADCs pro Kanal zueinander sein.
Grüße
Jörg
Hallo werte Gemeinde,
leider mußte ich einen kleinen Rückschlag hinnehmen. Bei dem Versuch
parallel zu meiner Windows- und Suse-Linux Installation noch ein Ubuntu
aufzuspielen habe ich mir leider die Festplatte sprich die
Partitionstabellen zerschrotet. Mit einem Partitionierungstool habe ich
es jetzt soweit hingebogen, dass ich an die meisten Daten wieder
rankomme. Bis auf ein Notwindows läuft aber zur Zeit nix hier. Ich warte
z.Zt. noch auf eine neue Festplatte die ich als Backupmedium benutzen
werde bevor ich in irgendeiner Form weiter mache. Leider meldet mir
Amazon gerade, dass die Platte erst am 7. August (???) kommen wird. Da
bin ich sonst schnellere Lieferung gewöhnt.
Bis dahin bin ich leider nicht in der Lage an unserem Projekt weiter zu
arbeiten. Ich verfolge aber wie immer die Fortschritte hier im Forum.
Gruß Hayo
Man Hayo, das war ja jetzt mal echt leichtsinnig von dir...aber ich kann
da auch ein Lied von singen(von meinem Leichtsinn), seitdem kommt jedes
Betriebssystem auf eine separate Platte und gebootet wird beim
hochfahren, da kann ich mir die Platte aussuchen mit F12! Sollte bei
fast jedem Rechner dieselbe Option sein!
Gruß Michael
Neuinstallation, mein Beileid. Hatte ich ja auch gerade. Hayo, was
bestellst du für seltsame Festplatten? Ich persönlich würde zu einer SSD
raten, zumindest als Systemplatte... Die "großen" Daten auf einem NAS,
dann kommt man auch von allen Rechner aus dran.
Wieder zum Thema:
Ich habe meinen Kalibrator einsatzbereit. Für die Nullpunktkalibrierung
hatte ich ja bereits eine Routine, die mit dem Offset-DAC bei
kurzgeschlossenem Eingang per Intervallsuche genau den ADC-Wert 128
ansteuert, gemittelt über den Meßwertspeicher mit leichtem
"Dithering"-Rauschen wird das sehr präzise. Das tue ich nun für jeden
möglichen ADC-Wert. Die Extremwerte 0 und 255 muß ich auslassen, weil
ich dann keine "zu hoch" bzw. "zu tief" Info mehr kriege. Ferner macht
die Mittelung am Rand wegen Clipping Probleme.
Der Offset-DAC hat eine Auflösung von 14 Bit (bei mir 16, gemodded), hat
also genügend Reserve zur Vermessung.
Spuckt nun jede Menge Meßwerte aus, ich bin mir noch unschlüssig wie ich
damit umgehe.
Kurzzusammenfassung:
Die Linearität der einzelnen ADCs ist sehr gut, weicht aber wie erwartet
voneinander ab. Nur eine Offsetkorrektur reicht nicht, die haben auch
leicht unterschiedliche Steigungen.
Mit der Widerstandsmodifikation versauen wir uns die Linearität.
Anscheinend fällt es dem Ausgangstreiber schwer, mit Terminierung und
Spannungsabfall an Längswiderständen die Aussteuergrenze der ADCs zu
erreichen. Da sollten wir noch mal genauer drüber nachdenken.
Im Anhang meine Meßwerte. Ich habe 2 Meßreihen aufgenommen, die
Excel-Datei hat daher 2 Blätter. Jeweils unten sind Diagramme.
1.) Nur den ersten ADC, im 250MSa-Bereich gemessen. Diese Werte sind
sehr genau, weil das Ausreißer-Phänomen hier nicht auftritt. Hier kann
man die Linearität des einzelnen ersten Wandlers gut ablesen. Ohne
Widerstandmodifikation über quasi den ganzen Bereich perfekt, mit nur im
Intervall von ca. 40...210 brauchbar.
2.) Alle 4 ADCs pro Kanal getrennt vermessen, im 1GSa-Bereich. Hier muß
ich wegen der Ausreißer heftig filtern (mache ich intern mit
Histogramm), was die Werte weniger zuverlässig macht. Aber nur hier
können wir sehen, wie die ADCs parallel laufen. Ich habe noch keine in
die Waagerechte "gekippten" und aufgezoomten Kurven erzeugt, dort noch
Rohwerte.
Ach ja:
Kanal 1 ist bei mir unmodifiziert, Kanal 2 hat die
Widerstandmodifikation mit 25 Ohm Längswiderständen und 174 Ohm
Terminierung (macht mit ADC-Impedanzen effektiv 150 Ohm), Kanal 3+4 die
neue Eingangsstufe, inklusive Widerstandsmodifikation.
Grüße
Jörg
SSD ist ebenfalls schon geordert...
Lieferzeit nur 2 Tage (im Gegensatz zu der anderen Platte). Mit etwas
Glück bin ich doch etwas eher wieder dabei.
Freundlicherweise hat mir noch einer der Forums-Mitleser (seines
Zeichens Linuxprofi) Hilfe angeboten. Ein wirklich netter Zug.
Zu deinen Messungen: Eine Linearitätskorrektur hatte ich auch schon in
den Anfängen der BF-Firmware vorgesehen, aber aus Performancegründen
wieder verworfen, da zu dem Zeitpunkt die Skalierung noch nicht aus
Lookuptabellen generiert wurde sondern noch einzeln berechnet wurde. Da
haut so eine Multiplikation ganz schön rein...
Nach dem aktuellen Stand ließe sich das natürlich ohne
Performanceeinbuße integrieren. Schaun wir mal.
Gruß Hayo
Ich habe Blatt 2 der Meßwerte erweitert, um aussagekräftigere Grafiken
zu kriegen (wie erwähnt in die Waagerechte gekippt und vergrößert).
Willkürlich nehme ich den ersten ADC als Referenz (blaue Kurve) und
vergleiche die anderen damit. Aus dem für alle meine Kanäle linearen
mittleren Teil von ADC1 habe ich eine Ausgleichsgerade bestimmt, dann
die Abweichung der Werte zu selbiger aufgetragen. Einheit ist
ADC-Digits.
Man kann gut sehen, wie manche ADCs sich relativ zueinander bewegen,
andere auch eher nicht. Die Werte sind wie befürchtet wegen der
Ausreißerfilterung weniger stabil als auf dem 1. Blatt, aber durchaus
brauchbar.
Nun muß ich mir noch ausdenken, wie ich eine Kalibrierung dafür
verläßlich automatisiere...
Diese Kompletterfassung dauert ca. 20 Minuten, aber so viele Werte
brauchen wir längst nicht.
Eine "echte" Linearisierung möchte ich nicht machen, das brauchen wir
hoffentlich nicht. Nur eine Korrektur der Empfindlichkeiten, sprich die
unterschiedliche Steigung.
Hayo W. schrieb:> Lieferzeit nur 2 Tage (im Gegensatz zu der anderen Platte). Mit etwas> Glück bin ich doch etwas eher wieder dabei.
Sag' Bescheid wenn's losgehen soll, wann wir einen "Osoz-Kurs" machen.
:-)
Jörg
> Sag' Bescheid wenn's losgehen soll, wann wir einen "Osoz-Kurs" machen.> :-)> Jörg
...jaaaa und das es dann auch auf einem 2 Kanal Welec läuft?!?
> Gruß Michael
"Kleine" Statusmeldung:
Ich experimentiere gerade damit, wie wir für Osoz ein performantes
Screenshot-Feature kriegen, mit effizienter Kompression des Bildinhalts
und Übertragung im Hintergrund.
In der alten Firmware dauert mir das mit ca. 15 Sekunden entschieden zu
lange. Dort findet eine Lauflängenkodierung statt, die die Bilddaten auf
ca. 25% der Originalgröße eindampft. (Sonst würde es etwa ein Minute
dauern.)
Mit dieser Kompression war ich nicht recht zufrieden - für ein Binärbild
erscheint mir das nicht so geeignet, weil die Pixel sich nicht an
Bytegrenzen halten.
Ich habe nun etwas experimentiert und einen einfachen und recht
effizienten Kompressor "from scratch" gebaut. Ich komme auf knapp 3% der
Originalgröße. Im Moment rechnet der noch länger als die Übertragung
dauern würde, etwa 2 Sekunden, Übertragung wäre gut eine halbe, aber ist
auch noch nicht sonderlich optimiert.
Falls es jemanden interessiert wie der arbeitet:
Kompression besteht allgemein aus 2 Teilen:
1. Prediktion: alles was man irgendwie vorhersagen kann braucht man
nicht übertragen, man nutzt Redundanzen, Selbstähnlichkeiten, auch
herbeigeführt durch Transformationen aus
2. Kodierung der Residuums: der zu übertragende Rest soll möglichst
geschickt kodiert sein, mit wenig Bits, z.B. die Statistik des
Restsignals ausnutzend
Konkret wird's greifbarer. Benachbarte Pixel sind bei uns oft gleich,
nebeneinander wie übereinander. Als Prediktion mache ich deshalb eine
XOR-Verknüpfung von jeweils nebeneinanderliegenden Zeilen und danach
Spalten (mit 32 Bit parallel geht das recht fix). Dabei bleiben nur die
Pixel übrig, die sich geändert haben. Das ist eine Art Kantenfilter.
Weil das in beide Richtungen passiert bleiben von einem Rechteck nur die
4 Eckpixel übrig, der ganze ausgefüllte Bereich ist weg. (Ein einzeln
stehendes Pixel wird allerdings auch zu 4 Pixeln aufgeblasen.)
Mit ähnlichen XOR-Operationen läßt sich das beim Empfänger vollständig
wieder umkehren. Ist speziell in Spaltenrichtung anstrengender, weil
nicht mehr parallel möglich, aber das muß ja der PC machen.
Es sind nach der Filterung nur noch wenige gesetzte Pixel übrig, das ist
mein Residuum, die gilt es geschickt zu übertragen. Ich mache das
allerdings recht einfach, ginge bestimmt besser, aber wir wollen nicht
lange dran rumrechnen... Also kein Huffman, keine adaptiven Statistiken,
etc. Die Restpixel treten gern in Gruppen auf, auch übereinander, da
ginge was.
Ich übertrage einfach nur, wie weit es von einem Pixel zum nächsten ist,
zeilenweise durchgescannt. Also für jedes übriggebliebene Pixel eine
Zahl. Kleine Zahlen sind häufiger, daher nehme ich eine Kodierung die
kleine Zahlen mit wenig Bits ausdrückt, große mit mehr: Exp-Golomb, so
in der Art:
http://en.wikipedia.org/wiki/Exponential-Golomb_coding
Etwas angepaßt, um 1 versetzt, denn die Abstände sind mindestens (und
meistens) 1, die 0 tritt also nicht auf. Unsere 1 wird dann auch mit nur
einem Bit codiert. Größere mit deutlich mehr Bits, aber damit
überspringen wir ja auch bereits erhebliche Bildteile.
So, genug der Kompression.
Zuvor hatte ich vorbereitet, das Senden auf der seriellen Schnittstelle
im Hintergrund stattfindet, gepuffert und mit Interrupts. Das hatte ich
zwar bereits in meiner Treiberschicht, aber blieb noch ungenutzt und
hatte noch peinliche Bugs. Die Laufzeitbibliothek weiß von meinem Code
erstmal nichts, ein printf() benutzt blockierende Funktionen aus dem
SDK, steht da rum und dreht Däumchen bis das letzte Byte über die
Schnittstelle geht. Das habe ich nun rausgeschmissen und durch meine
Funktionen ersetzt. So bleibt nun alles in der Reihenfolge, ein printf
drängelt sich nicht dazwischen.
Und ein kleiner Wehrmutstropfen: es gibt noch kein PC-Gegenstück. Ein
write-only Screenshot ist noch nicht sooo nützlich...
Fühlt sich jemand berufen? Am besten was mit GUI, Windows+Linux
portabel, Qt, Java, oder was nimmt man heute? Die entsprechenden
Kernfunktionen kann ich (in C) gern beisteuern.
Grüße
Jörg
Hallo Jörg,
schöne Sache...
Ich würde mir als Option noch wünschen, das das Bild auch ohne Software
mit einem Terminalprogramm zu empfangen ist z.B. jpg + Z-Modem.
Ist so etwas angedacht?
Ansonsten weiter so!
Viele Grüße,
egberto
2 ähnliche Fragen...
Bitte erinnert euch daran, das in dem Oszi eine kleine CPU mit 12,5 MHz
am werkeln ist, und auch nicht üppig Speicher zur Verfügung steht (2 MB
für alles, Code, Daten, Stack, Bildspeicher, Capture-Speicher).
@egberto: Nein, das wird nicht gehen, das Oszi erzeugt noch kein
"brauchbares" Bildformat, sondern überträgt sehr optimiert seinen
Bildspeicherinhalt, der dann auf dem PC weiterverarbeitet wird,
schließlich mit Standardbibliotheken in eine Datei geschrieben wird.
(JPEG würde ich wegen lossy und Kantenklingeln auch nicht für geeignet
halten, eher PNG)
@Lukas (Schlaumeier...!): siehe oben, sowas macht sich hier ganz
schlecht. Wir brauchen was sehr schlankes, um überhaupt eine Chance zu
haben. Wenn es denn auch noch schnell sein soll, dann muß man schon
genauer nachdenken was hier welchen Effekt hat.
Jörg
Hi,
ich benutze mein Welec-Oszi zZ für die Einarbeitung in QSys,
habe seit (7.x?) nichts mehr gemacht (damals SOPC). Von daher
ist der Fortschritt hier immer interesant und motivierend für
eigene Entwicklungen. (Ich z.B. möchte das SRAM komplett für
Sampling verwenden, damit habe ich dann je 1MByte/Channel
bei 2 Channels mit 200-250Samples/Sec. Für NiosII bleibt damit
natürlich nur noch das interne RAM, d.h. etwa 30-60KB. Reicht
aber für sehr kleine Projekte)
Bemerkungen/Fragen:
1. Bild => PC senden: Warum muss das komplette Bild gesendet
werden? Ist's nicht besser, nur die Settings und Samples via
RS232&Co zum PC zu schicken (<<100KByte) und dort dann den
Bildaufbau zu machen. Das habe ich in einem kleinen Testprojekt
mal gemacht (nur Samples vom ADC gelesen) und ging schnell
genug um am PC realzeitig zu arbeiten.
2. In einem der letzten Posts wurde als ADC-Kalibrierungsquelle
der Offset-DAC verwendet. Kann einer von euch etwas über die
Linearität sagen? Privat habe ich leider kein teures/gutes
Testequipment zum Nachmessen und muss mich daher auf die
Datenblätter verlassen.
Gruss
Hallo Sigi,
du bist (FPGA-)Entwickler? Sowas brauchen wir!
> ich benutze mein Welec-Oszi zZ für die Einarbeitung in QSys,> habe seit (7.x?) nichts mehr gemacht (damals SOPC). Von daher> ist der Fortschritt hier immer interesant und motivierend für> eigene Entwicklungen. (Ich z.B. möchte das SRAM komplett für> Sampling verwenden, damit habe ich dann je 1MByte/Channel> bei 2 Channels mit 200-250Samples/Sec. Für NiosII bleibt damit> natürlich nur noch das interne RAM, d.h. etwa 30-60KB. Reicht> aber für sehr kleine Projekte)
Nios II? "Standardmäßig" haben wir nur einen Nios I. Wenn es denn mal zu
neuer FPGA-Überarbeitung kommt wäre das aber mein Wunschkandidat, weil
nur etwa halb so groß wie der Leon.
Deine 250 Sample/sec könntest du auch ins Flash schreiben, da hast du 8
MB minus Programmgröße. Oder live zum PC übertragen.
> Bemerkungen/Fragen:> 1. Bild => PC senden: Warum muss das komplette Bild gesendet> werden? Ist's nicht besser, nur die Settings und Samples via> RS232&Co zum PC zu schicken (<<100KByte) und dort dann den> Bildaufbau zu machen. Das habe ich in einem kleinen Testprojekt> mal gemacht (nur Samples vom ADC gelesen) und ging schnell> genug um am PC realzeitig zu arbeiten.
Das wäre ein anderer Modus, habe ich auch drüber nachgedacht. Schließt
einander ja nicht aus. BTW, mein Screenshot ist < 10KByte.
Grob überschlagen, 2 Kanäle mit 600 Samples sichtbare Breite übertragen
dauert gut eine Zehntelsekunde. Im besten Fall hat man also knapp 10
fps, nicht schlecht.
Für die Zukunft wäre auch die USB-Schnittstelle denkbar, für schnellere
Übertragung, aber da müßte die Firmware für den FX-Chip geändert werden.
Die Screenshots habe ich bei meinen GUI-Arbeiten vermißt. Dann kann man
schön kontrollieren, ob alles da sitzt wo es hingehört. Stattdessen habe
ich mein Lötmikroskop auf den Schirm gerichtet und die Kanten oder was
auch immer kontrolliert...
> 2. In einem der letzten Posts wurde als ADC-Kalibrierungsquelle> der Offset-DAC verwendet. Kann einer von euch etwas über die> Linearität sagen? Privat habe ich leider kein teures/gutes> Testequipment zum Nachmessen und muss mich daher auf die> Datenblätter verlassen.
Ich habe noch nicht nachgemessen. 14 bis 16 Bit sollte noch mit einem
halbwegs normalen Tischmultimeter kontrollierbar sein (was ich aber auch
nicht habe).
Für die 8-Bit ADCs dürfte es reichen, oder was ist deine Sorge?
Grüße
Jörg
>..250 Sample/sec..
Ups, soll 250 MEGA-Samples/Sec heissen. (Bei 2x16b 8ns-SRAMS
sportlich, aber machbar. Es muss ja nur schnell geschrieben
werden, beim lesen kann man's gemütlich angehen lassen.
Dieser Ansatz und QSys/MM-Slave schliessen sich dann wohl
aus)
Und Flash wäre also viel zu langsam, und ständig auf den
Flashspeicher möchte ich auch nicht zugreifen.
>du bist (FPGA-)Entwickler?
Seit Jahren nur noch gelegentlicher Hobbiker (mit Altera/QII
und Xilinx/ISE vertraut).
>Ich habe noch nicht nachgemessen. 14 bis 16 Bit sollte noch mit einem>halbwegs normalen Tischmultimeter kontrollierbar sein (was ich aber auch>nicht habe).>Für die 8-Bit ADCs dürfte es reichen, oder was ist deine Sorge?
Mein Problem bis jetzt ist, dass ich noch nicht mit allen
Pfaden innerhalb des Oszis vertraut bin. Bis jetzt habe ich
mich hauptsächlich in die "digitalen" Komponenten wie ADC,
LCD, Buttons und LEDs eingearbeitet bzw. diese angesteuert.
Gruss
Sigi schrieb:>>..250 Sample/sec..>> Ups, soll 250 MEGA-Samples/Sec heissen. (Bei 2x16b 8ns-SRAMS> sportlich, aber machbar.
Lieber Sigi,
wir reden hier aber bitte um 1GS/s auf allen 4 Kanälen! Alles sonst
bleibt unter dem ursprünglichen Design weit zurück!
Gruss
Jürgen schrieb:
>wir reden hier aber bitte um 1GS/s auf allen 4 Kanälen! ..
Schon klar (und ich habe vergessen zu sagen, dass ich nur
2 Kanäle habe). Bei 4 Kanälen hat man auch 2 FPGAs und
dazwischen nur ein paar Pins (~8 ??). Soweit ich weiss, ist
nur ein FPGA direkt mit den beiden SRAMs verbunden, und vom
2.FPGA die Daten zum ersten mit 2GS/s zu pumpen halte ich
für unereichbar.
Mein Ziel ist es (neben der grossen Sample-Menge), nach den
1GS/s je Kanal erstmal zu filtern und dann die verbleibenden
200-250MS/s ins RAM zu schiessen (200-250 je Kanal) und dann
je nach Bedarf auf dem LCD auszugeben oder an den PC zu senden.
Ich will also nicht die ADC-Rohdaten in grosser Menge, zum
Filtern reichen kleinere Mengen. Mehr ist beim CycloneII bei
grossen Datenmengen eh nicht drin, es sei denn, man beschränkt
sich auf vieleicht 16KB, max 32KB für beide Kanäle und nimmt
die internen RAM-Blöcke.
Gruss
Sigi, du bist HDL-erfahren? Sowas brauchen wir, aktuell mehr denn je.
Und für alle, hier der Grund warum ich mich bisher bei Osoz nicht mit
dem Trigger und kaum mit dem Capturing befaßt habe:
Beitrag "Re: Wittig(welec) DSO W20xxA Hardware (Teil 2)"
Schon länger gab es die Aussicht, in das originale Design reinzugucken.
Da mochte ich keine Reverse-Engineering-Arbeit in diesen mysteriösen
Teil stecken, habe noch abgewartet und mich mit solchen Nebenthemen wie
Screenshots beschäftigt. ;-)
Nun kann es da weitergehen, auch wenn wir leider nicht das aktuelle
Design haben und genau da noch Unterschiede sind.
Jörg
Sigi, hallo, wo bist du?
Ich mache zur Zeit nichts an Osoz, weil ich in die FPGA-Ecke abgedriftet
bin, siehe Hardwarethread.
Der made-from-scratch Ansatz wird also gerade erweitert...
Im Moment lerne ich jede freie Minute Verilog + Altera Quartus, was man
damit so anstellen kann. Ist schon interessant!
Jörg
Es gibt Neuigkeiten für die Zweikanaluser:
Guido hat mir seine Hardware geliehen, nun habe ich mich nochmal
drangesetzt, hier läuft es nun. Ergebnis siehe Anhang, bitte probiert es
mal damit.
Jörg
Ich sehe gerade, die letzte Version ist ja schon eine Weile alt, noch
deutlich vor meiner FPGA-Abschweife. Dann lohnen sich ja noch "Release
Notes", was tat sich seit der letzten Version:
- es gibt eine serielle Kommandozeile, sogar mit einfachem Editor und
History
- ein paar Testkommandos unter selbiger, mal 'help' eingeben
- Erfassung und Darstellung intern getrennt
- ADC-Kalibrierung, im Moment aber nur Messung
- Kalibrierungen können durch Tastendruck abgebrochen werden
- printf() und sonstige serielle Ausgaben senden ihre Zeichen im
Hintergrund
- schneller komprimierter Screenshot, PC-Gegenseite fehlt noch
- Fix: die Waves passen nun zeitlich zusammen
- interne Vorbereitungen für Trigger
- Fix für 2kanal Geräte, siehe voriges Posting
Jörg
Hallo stille Welt,
ich habe noch kein Feedback von Zweikanalusern, funktioniert das jetzt?
Ein paar weitere News zu Osoz:
Ich portiere es gerade auf das Nios II Design. (Bis auf Capturing,
versteht sich, das gibt es dort noch nicht.) Die eigentliche Portierung,
die Anpassung der Firmware-Schicht, war recht schnell gemacht, das hat
ca. 1 Tag gedauert. Osoz war ja darauf vorbereitet, und ich habe die
neue Hardware im Hinblick darauf gebaut. Im Detail gab es noch ein paar
übersehene/geschluderte Ecken wo Anpassungen nötig waren. Der neuere gcc
Compiler ist deutlich strenger. Dem fielen z.B. etliche unbenutzte
Variablen und fehlende #include auf.
Nun bin ich am Debugging...
Primär kämpfe ich mit mysteriösen Exceptions, die die Software schnell
zu Fall bringen.
Stand der Dinge ist, wenn obiges mal gutmütig ist sehe ich bereits das
UI, kann die Offsetzeiger spazierenkurbeln. Auf Tastendrücke reagiert es
noch nicht, obwohl die prinzipiell ankommen. Gibt halt noch Arbeit...
Bei der Inbetriebname sehr nützlich ist, das nun mit JTAG und der
Eclipse-IDE echtes Debugging möglich ist, mit Breakpoints, durch den
Code steppen, Variablen angucken, hängende Software anhalten, solcherlei
Komfort. Das ist schon deutlich produktiveres Entwickeln.
Die Quellen von Osoz sind umgezogen, residieren in Sourceforge nun zwei
Verzeichnisebenen höher. Ich hatte das damals ganz bescheiden unter
fpga/nios einsortiert, aber nun ist es übergreifend. Es wird nun auch
etwas anders gebaut: Das Makefile und die Scripte liegen nicht mehr ganz
oben in der Verzeichnisstruktur, sondern es gibt 2 Satz, unter
platform/nios bzw. platform/nios2. Also im entsprechenden Verzeichnis
bauen. Der Buildflow für die beiden Targets ist derzeit völlig
unterschiedlich. Ich habe für den Nios II erstmal den Flow von Altera
unverändert verwendet, inklusive dem BSP, deren Firmware-Layer. Etliches
davon macht Osoz bereits selbst, das kann später noch ausgedünnt werden.
So long
Jörg
Hallo Jörg,
hier mal ein 2 Kanal-User...
Habe deine OSOZ-5 mal in's RAM gesetzt.
Als erstes habe ich "Calibrate Offsets" durchgeführt. Mit
Fortschrittsanzeige...chic.
Danach "Calibrate ADC's".
Die Nulllinie sitzt besser als bei der jetzigen FW.
Führt man als erstes "Calibrate ADC's" durch, bleibt das Welec stehen!
"Test Linearity" dauert mal locker 5-6min.
Die Signallinien lassen sich hoch u. runter bewegen, die Nulllinie folgt
schön mit.
Bei anlegen eines 1kHz Signals, wird dieses wiedergegeben nur lässt es
sich nicht einfangen. Oben zappelt dann auch "fps" munter mit.
"Persist" funktioniert, auch hier ein Pic davon.
Anbei mal ein paar Pic's mit den Einstellungen
Gruß Michael
EDIT: Beim hochladen der Pic's ist mir ein kleiner Fehler unterlaufen,
"Calibrate ADC's" gibt keine Fortschrittsanzeige an, dafür ist der
Abgleich zu kurz...
Michael, danke für den Test. Das mit der hängenden Kalibrierung muß ich
mir mal ansehen. Es kommt also auf die Reihenfolge an?
Es gibt noch keinen Trigger. Von daher ist es "normal" daß du das Signal
nicht stehend kriegst. Außer mit "single" ;-)
Jörg
Zu Osoz auf Nios II:
Das sieht jetzt ganz gut aus, es läuft alles was da ist, also außer
Capturing. Das Menüsystem geht, das Kommandozeileninterface, Offsets
spazierenkurbeln, Sichern der Einstellungen ins Flash, usw.
Man könnte also sagen, Osoz ist portiert. Mir sind keine Bugs oder
Lücken mehr bekannt.
Wer mit Quartus und dem FPGA-Download umgehen kann mag herzlich gerne
mit testen.
An der Hardwarefront bestehen noch folgende Probleme:
- Andreas beobachtet auf seiner Hardware Grafikfehler in der gelben
Plane. Könnte das Businterface sein, aber das hat sich sonst anders
geäußert.
- Quartus erzeugt mir mitunter ziemlich kaputte Bitstreams, auf denen
die Software sehr wackelig läuft. Das war die Ursache für die
Exceptions. Entweder fehlt mir irgendeine Einstellung, ein Constraint,
oder Quartus ist buggy.
Beides sehr seltsam.
Davon abgesehen könnte man nun langsam daran denken, was in Richtung
Capturing einzubauen.
Jörg
Zu Osoz mit NIOS II:
Wie Joerg schon erwähnt hat, habe ich bei mir einige springende Pixel
... besonders bei der gelben Plane (Kanal 1).
Teilweise (wenn das Gerät kalt ist) sehe ich diesen Effekt auch bei der
roten Plane (Kanal 4).
Wie es bei dem Zweitgerät aussiegt kann ich erst später sagen!
Andiiiy
Please can someone help me. I have a Wittig W2022 and it refuses to
work. I can get Byteblaster to work and the Altera software to see the
Cyclone CPU. I can load some Jit files to the DSO but I cannot get the
Germsloader to work and get the proper firmware back to my DSO. PLEASE
PLEASE help.
Thank you in anticipation.
Paul King (B.Eng (Hons. and Distinction))
Hi Paul,
as I wrote You in the email You have to use (a must!) the RS232 to
update your firmware. So what OS do You use on Your PC? Linux or
Windows? 32 or 64 bit?
The germsloader needs an installed Perl because the loader uses a Perl
script. Under Windows you can use the free Active Perl. Also you have to
install the Serial Port module.
All that is described in "how to upload via shell script" .
Did You consider this?
Kind regards
Hayo
Hello Hayo,
I did do all of this before I got onto this forum and cried for help. I
did follow your instructions but my Witteg does not seem to respond to
the RS232.
I am using Windows XP - 32 bit but also have Windows 7 64 bit, both
computers with working RS232.
I loaded active Perl on and installed the RS232 serial port drivers on
my spare XP laptop. This is working - no problem.
After this I am stuck !!!!
I will read your attachment and update you tomorrow.
Thank you for responding.
Paul
Hi Jörg,
ich habe angefangen die Capture-Treiber für den OSOZ-Trigger zu
schreiben. Dafür mußte ich aber am Unterbau Deine vorgegebenen
Funktionen und Enumeratoren ändern, da diese nicht ganz zum Kontext
passten.
Ich habe den Rohbau eben eingecheckt. Kannst Du mal drüber gucken ob das
für Dich ok ist bevor ich anfange da Details reinzuprogrammieren.
Gruß Hayo
Sehr gut, ich bin begeistert!
(Für alle: das ist das fehlende Puzzlesteinchen, damit Osoz in Zukunft
auf beiden Plattformen läuft, beide von der Applikationsentwicklung dort
profitieren.)
Mein Rohbau dort war eh nur geraten. Fühl' dich also frei, das den
Gegebenheiten entsprechend hinzubauen.
Wenn das Nios II Design da später mal mehr kann müssen wir es halt
aufbohren. Aber das Problem möchte ich erstmal haben. ;-)
(Extrapunkte für Gleichziehen des Nios II capture.c Files, wenn du die
API änderst.)
Jörg
Jörg H. schrieb:> (Extrapunkte für Gleichziehen des Nios II capture.c Files, wenn du die> API änderst.)
Ok, ist notiert.
Bin auch schon dabei die ersten Register zu setzen...
Gruß Hayo
So hab jetzt schon mal ordentlich vorgelegt. Die aktuelle Version ist
auch schon eingecheckt. Bin aber noch längst nicht fertig. Ich komme
aber dank guter Vorarbeit von Jörg ganz gut im Coding zurecht. So macht
das Arbeiten Spaß!
Jetzt werde ich mich erstmal von der besten aller Ehefrauen unter der
Bettdecke anwärmen lassen...
Guats Nächtle
Hayo
Moin!
Sehr schön.
Meine Vorarbeit war an einer Stelle undeutlich: Für die über SPI
einzustellende externe Triggerei gibt es schon ein Modul, trigger.h/.c
Das sollten wir vielleicht in etrigger.* umbenennen, samt seiner API?
Als ich das anfing war mir die Aufgabenverteilung der Hardware noch
nicht klar.
Du brauchst (hoffentlich) nur die Aspekte des Triggers behandeln, die
von der Capture-Hardware im FPGA erledigt werden. Ist etwas unglücklich
das sich die Aufgaben der beiden Hardwareeinheiten logisch vermischen,
aber ich würde die Trennung beibehalten, damit sich jeder Treiber um
seine Hardware kümmert, dem anderen nicht in die Register greift.
Jörg
Moin,
ja das mit dem SPI hatte ich gestern schon gefunden und eingebaut.
Ich bin jetzt fertig mit dem Prototypen der Treiber. Diese sind noch
nicht getestet, mir fehlt dazu im Augenblick der Überblick welche
Main-Files sich da anbieten.
An einigen Stellen kann man außer Funktionstest vielleicht noch prüfen
ob die Register einfacher gesetzt werden können. Ich habe mich aber
erstmal an der laufenden BF-Firmware orientiert um eine Basis zu
bekommen.
Das API für NIOS II habe ich auch schon angepasst.
Eingecheckt ist auch schon, was vergessen? Hoffe nicht.
Gruß Hayo
Hallo Hayo,
ich habe mich am Wochenende erstmal nicht von meiner
Verilog-Großbaustelle ablenken lassen, daher noch keine Reaktion
meinerseits auf den Trigger.
Aber fühle dich wertgeschätzt und bedankt!
Hayo W. schrieb:> ja das mit dem SPI hatte ich gestern schon gefunden und eingebaut.
Sorry, eben, das ist jetzt doppelt. Der Capture-Treiber soll nicht am
SPI drehen, die Teile sind im unglücklich benannten (external)Trigger
Treiber.
> Ich bin jetzt fertig mit dem Prototypen der Treiber. Diese sind noch> nicht getestet, mir fehlt dazu im Augenblick der Überblick welche> Main-Files sich da anbieten.
Ich bin auch 'ne Weile raus. Die Funktionen müssen vom Model aufgerufen
werden, und die Werte vom Model müssen noch passen.
> Das API für NIOS II habe ich auch schon angepasst.
Prima, danke!
Jörg
Jörg H. schrieb:> ...daher noch keine Reaktion meinerseits auf den Trigger.
Ja nee kein Problem, wollte nur 'nen Status abgeben damit Ihr wißt wo
ich gerade unterwegs bin und welchen Stand das Projekt hat.
Bin gerade vom sagenumwobenen Griechen zurück und mache noch schnell den
heutigen Statusbericht.
Zum SPI: Ich glaube da haben wir uns klassisch mißverstanden. Mit meinem
Kommentar ->
> ja das mit dem SPI hatte ich gestern schon gefunden und eingebaut.
meinte ich tatsächlich das API, nicht den Hardwarezugriff. Den habe ich
nur für das PWM Register nicht gefunden und deshalb direkt eingebaut.
Habe ich das dazugehörige API Übersehen? Gesucht habe ich schon....aber
nix gefunden (in der SPI Datei), vielleicht war ich auch schon
betriebsblind. Gib mir mal nen Tip, dann baue ich die SPI Funktion
stattdessen ein.
Ansonsten:
Ich habe das Trigger API in die aktuelle BF Firmware eingebaut um in
vertrauter Umgebung testen zu können. Das hatte gleich zwei Vorteile.
Erstens hat es die alte Firmware schön aufgeräumt und ich habe auch
schon einige Einstellungen überprüfen bzw. verbessern können. Der größte
Teil der Treiber ist schon getestet und überarbeitet, drei stehen noch
aus (Pulsweitentriggerung, Holdoff).
Nebenbei fällt noch eine neue Firmwareversion dabei ab die mit einem
erweiterten Triggermenü (neuer Modus Freerun) aufwarten kann. Die
Gemeinde wirds freuen...
Gruß Hayo
Ich habe gerade versucht meine Änderungen einzuchecken, was aber auf
ziemliche Ablehnung gestoßen ist. Nach genauerer Untersucheng scheint
Andi ebenfalls am API rumgeschraubt zu haben. Ich habe jetzt meine
Änderungen in einem zweiten Anlauf eingecheckt, aber ich weiß nicht ob
evtl. die anderen Änderungen gelöscht wurden.
Vielleicht sollten wir uns da besser abstimmen und nicht mit mehreren an
der gleichen Source rumdengeln.
Gruß Hayo
Hallo Hayo, vielen Dank!
Locker bleiben, Andi hat nur eine einzige Zeile gelöscht, die hattest du
noch übersehen. Ansonsten hätte der Nios-II Code nicht kompiliert.
SVN ist genau für sowas gemacht, gleichzeitiges Entwickeln. Wenn du
deine Änderungen nicht einchecken kannst weil jemand anders
dazwischenkam, dann kannst du mit svn update erstmal seine Änderungen
bei dir mit reinpflegen lassen. In der Regel klappt das automatisch,
wenn ihr nicht gerade an derselben Stelle bei wart. Dann wie gewohnt
einchecken.
Jörg
Hayo W. schrieb:> Nach genauerer Untersucheng scheint> Andi ebenfalls am API rumgeschraubt zu haben.
So ist es wenn wir an gemeinsam an dem OSOZ arbeiten ... ;-)
Wie Jörg schon erwähnt hat, habe ich nur minimale Anpassungen
vorgenommen um auch mit NIOSII wieder weiter arbeiten zu können.
Wie ich gesehen habe, sind wir zur gleichen Zeit über den Fehler in der
API gestolpert.
Ich freue mich aber sehr, dass Du schön im OSOZ mit "bastelst".
Gruß Andi
Hayo W. schrieb:> Hallo Jörg,>> hattest Du Deine 16 Bit signed MSTEP Multiplikation erfolgreich> getestet?> Ich hatte damit immer falsche Ergebnisse.> Ich hab das mal in eine Inline-Funktion gekippt mittels> Inline-Assembler, und dann etwas umgeschrieben, das sieht dann so aus> und liefert auch richtige Ergebnisse:
Doch, ich habe sogar ein Testprogramm geschrieben das alles
durchrastert:
http://welecw2000a.svn.sourceforge.net/viewvc/welecw2000a/osoz/app/unittest/main_test_smul.c?revision=712&view=markup
Das mit der Inline-Funktion hat den Nachteil, das ein weiteres Register
Window aufgemacht wird, während die Assemblerfunktion gleich in dem des
Aufrufers läuft. Vielleicht gibt es aber auch unentdeckte Nebeneffekte?
Jörg
Jörg H. schrieb:> Das mit der Inline-Funktion hat den Nachteil, das ein weiteres Register> Window aufgemacht wird
Bist Du sicher? Im Dumpfile wurde das nahtlos eingefügt. Das neue
Register-Window müßte doch mit einem "save" eingeleitet werden, oder
sehe ich das falsch?
Ich hatte jedenfalls Probleme die Routine direkt aufzurufen und bekam
immer einen Referenzfehler. Ich habe dann das Coding in die Inline
Funktion gepackt und getestet. Wenn der Multiplikant negativ und der
Multiplikator positiv sind stimmt auch alles. Wenn es umgedreht ist oder
beide negativ, dann bekam ich immer sehr merkwürdige Ergebnisse. Mit der
Änderung (s.o.) stimmt das Ergebnis aber.
@Andi
Ja ich war etwas überrascht, dass das SVN sich so zickig anstellte. Da
ich mit SVN nicht so vertraut bin war es erstmal etwas schwierig die
Ursache festzustellen.
Gruß Hayo
Hayo W. schrieb:>> Das mit der Inline-Funktion hat den Nachteil, das ein weiteres Register>> Window aufgemacht wird>> Bist Du sicher? Im Dumpfile wurde das nahtlos eingefügt. Das neue> Register-Window müßte doch mit einem "save" eingeleitet werden, oder> sehe ich das falsch?
Nein, dann bin ich nicht sicher. ;-)
Meine Nios Assemblerkenntnisse sind etwas eingerostet. Macht der Sprung
bereits was?
Was ist denn noch der Unterschied (im Disassembly) zwischen den
Varianten?
Jörg
Jörg H. schrieb:> Macht der Sprung bereits was?
Er springt ja nicht, sondern das Codefragment wird mit den dynamisch vom
Compiler angepassten Registern in den umgebenden Code eingebettet.
> Was ist denn noch der Unterschied (im Disassembly) zwischen den> Varianten?
Das ist auch schon ein wesentlicher Unterschied, bei Deiner Variante
springt er zu der Unterroutine und die Register sind fest vorgegeben.
Hayo
Inzwischen habe ich mich ein wenig mit Quartus beschäftigt. Der Altera
USB-Blaster den ich für unter 10,-€ in der Bucht beim Chinaman
geschossen habe arbeitet auch sehr gut. Unter Linux wollte er anfangs
nicht, erst als ich Quartus mit Root-Rechten gestartet habe hat er das
DSO erkannt. Treiber braucht man keine.
Unter Windows braucht man einen USB-Blaster Treiber, den man in einem
Unterverzeichnis der Quartusinstallation findet. Dann geht es ebenfalls
sofort.
Jetzt muß ich nur noch meinem W2014A einen Widerstand einlöten damit ich
das auch noch anschließen kann.
Eine Sicherung des W2022A Eproms hat problemlos geklappt. Das ist nach
all dem Rumgetüftle mit dem Treiber von Slog mal ein echtes
Erfolgserlebnis.
@Jörg
Ich bekomme leider Dein Projekt aus dem SVN bei mir nicht generiert. Es
bricht sowohl unter Linux als auch unter Windows mit Fehler ab.
Übrigens weiß ich jetzt auch warum die Installation unter Windows bei
uns nicht geklappt hat. Ich habe kein C: Laufwerk. Da sucht aber die
Installationsroutine nach einem Installationsordner und ist so blöde
dort bis in alle Ewigkeit zu suchen. Ich bin drauf gekommen, als ich
während der Installtion einen USB-Stick eingesteckt habe. Und plopp ging
die Installation sofort weiter weil der USB-Stick sich mit Laufwerk C:
angemeldet hat.
Gruß Hayo
Hayo W. schrieb:> Ich bekomme leider Dein Projekt aus dem SVN bei mir nicht generiert. Es> bricht sowohl unter Linux als auch unter Windows mit Fehler ab.
Mit was denn für einem Fehler?
Und was für ein Projekt, das FPGA, oder die Software, für welches
Target?
Bei dem Quartus-Projekt gibt es leider einen absoluten Pfad, den man
individuell ändern muß. Andii kann dir dazu wohl mehr sagen, der ist da
auch durch.
Jörg
Nein, das war es nicht, ich hab es noch mal probiert, es hakt im
SOPC-Builder bei der Systemgenerierung. Und zwar sind es die UARTs. Die
machen beide einen Fehler. Wenn ich die beiden rausnehme (Häkchen in der
Checkbox) dann läuft die Generierung sauber durch. Ich glaube das
Gleiche hatte ich mit Jörg hier bei mir auch schon.
Gruß Hayo
Ja klar, den Cycl II hab ich drauf, die meisten anderen habe ich aus
Platzgründen weggelassen. Hätte ja sein können, dass noch Komponenten
dabei sind die gebraucht werden, aber dann kann ich das ja weglassen.
Ich habe mir den Fehler mal näher angesehen. Leider werde ich da nicht
so richtig schlau draus. Der Fehler tritt bei der Generierung der UARTS
auf, genau gesagt beim Punkt --tx_fifo_LE=0
Ich hänge das Protokoll mal an. Vielleicht sagt Dir das ja mehr als mir.
Fehlt da evtl. eine Datei?
Hayo
Moin moin,
wenn ich mir so die Fehlermeldungen ansehe versucht Quartus anscheinen
das Verzeichnis "/home/W2000A/NIOS/_sim" anzulegen, schafft das aber
nicht. Gibt es da eventuell Probleme mit den Rechten ?
Gruß
Dirk
Ja dachte ich auch zuerst, aber das sollte eigentlich nicht sein, da ich
Quartus explizit mit root Rechten starte, da sonst auch der USB Blaster
nicht arbeitet. Ich würde das daher eigentlich ausschließen. Zudem ist
das Problem unter Windows XP das gleiche, und da mache ich sowieso alles
mit Admin-Rechten.
@Jörg
Welche Version nimmst Du? Ich verwende hier die 11.1 von Dir.
Hayo
Hab es noch mal mit der 12.1 unter Win XP probiert - gleiches Ergebnis.
Was läuft denn da schief. Hat hier noch jemand so ein Ergebnis? Oder bin
ich da der Einzige?
Hayo
Hast du das mal genauer angesehen? Vllt. ein Problem mit
Groß- Kleinschreibung.
/opt/altera/11.1/quartus//sopc_builder/bin//filename_utils.pm line 142.
Ansonsten kannst du das Verzeichnis ja mal von Hand anlegen.
Gruß, Guido
Hab ich mal versucht, kriege jetzt folgenden Fehler:
Error: uart_rs232: Generation callback did not provide a top level file
(expected `add_file $output_dir/uart_rs232.v|vhd|sv {SIMULATION
SYNTHESIS}`)
Also wie schon vermutet fehlt ihm etwas. Wenn ich mir die Generierung so
ansehe läuft die bei den UARTs auch irgendwie anders. Er ruft da
irgendein Perlscript auf, während die anderen Komponenten einfach so
durchlaufen.
Gruß Hayo
Hayo W. schrieb:> Hab es noch mal mit der 12.1 unter Win XP probiert - gleiches Ergebnis.> Was läuft denn da schief. Hat hier noch jemand so ein Ergebnis? Oder bin> ich da der Einzige?
Anscheinend bist du der Einzige...
Ich verwende die gleichen 11er Versionen, unter Linux und Windows,
beides geht. Bei der Arbeit auch mal eine 9er Version, 12er hatte ich
auch schon. Ein Versionsproblem ist es wohl nicht.
Andii übersetzt die Sourcen auch regelmäßig.
Als root unter Linux muß es hoffentlich nicht sein. Für den USB-Blaster
kann man vielleicht eine udev-rule anlegen? Unter Linux habe ich ihn
zugegeben noch nicht benutzt.
Nicht aufgeben!
Jörg
Also irgendwie kommt er mit den Verzeichnissen für die UARTs
durcheinander habe ich so das Gefühl. Naja, da ich um 4:00 wieder raus
muß werd ich jetzt die Sache mal beeenden.
Bis dann
Hayo
Hallo Hayo,
hier weiter, weil Osoz-softwarelastig:
Hayo W. schrieb:> 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.
Freut mich zu hören, daß du Neuem aufgeschlossen bist! (Hab schon
befürchtet, du kommst nie von der alten Software weg.)
Im Moment habe ich eine größere offene Baustelle, wegen besagtem
Samplespeicher. Osoz kompiliert derzeit nicht für den alten Nios, weil
ich das noch nicht nachgezogen habe, die Capture-API noch nicht stabil
ist.
Den Code kannst du dir natürlich trotzdem angucken, ich gebe dir gern
eine Tour.
Lass' uns das mal interaktiver besprechen, per Telefon oder im
Skype-Chat.
Was in Osoz z.B. noch völlig fehlt sind die Meßfunktionen und
alternative Signaldarstellung, namentlich FFT und X/Y.
Ferner bin ich auf ein Detailproblem gestoßen, wo mich interessieren
würde wie das in der BF-Firmware gelöst ist:
Man braucht m.E. eigentlich 3 Sätze von Settings, nicht nur einen,
nämlich einen für das aktuell dargestellte Signal, einen für die
laufende Messung, und einen für die zukünftige Messung. Dann kann man an
den Knöpfen drehen und das aktuelle Signal zoomen und verschieben, sowie
z.B. Zeitbasis und Offset für zukünftige Messungen verändern. Für die
laufende kommt das zu spät, die hat deshalb wiederum eigene Settings.
Jörg
Hallo,
schon eine Weile nicht mehr "gebloggt", vor lauter Fortschritten komme
ich gar nicht dazu! ;-)
Im Ernst, ich hatte um Ostern noch 1 Woche Überstunden abzubummeln und
deshalb hier Vollzeit dran arbeiten können. Das hat die Sache doch
gehörig vorangebracht.
Die große Baustelle Samplespeicher ist geschlossen, es kompiliert wieder
für beide Plattformen. Ich habe die neue Capture-Hardware weiter in
Betrieb genommen, bis auf Kleinigkeiten scheint sie zu funktionieren.
Trotzdem viel Arbeit, dort sind die größten Unterschiede.
So langsam wird es rund.
Wir haben jetzt neu:
- Zeitbasis (nicht soo bemerkenswert)
- Trigger, der steht wie eine Eins
- Hardwarefilter statt Subsampling, das ist der Bringer, Rauschen weg
;-)
Ein paar kleinere Dinge will ich noch einbauen, bevor ich mich damit an
die Öffentlichkeit traue. Vor allem fehlt mir noch sowas wie der
Autotrigger, das auch bei Nicht-Triggerung noch was angezeigt wird.
Aber freut euch schonmal drauf, das Ganze ist (ähem, ich bin ja
eigentlich bescheidener) schon ein ziemlicher Hammer:
- keine Spikes und sonstige Störungen mehr
- vermutlich auch keine Frequenzgangkapriolen mehr (falls die vom FPGA
kamen), kann ich mangels Generator aber nicht testen
- etwa 10 mal schneller (und Osoz ist ja auch schon auf dem alten Nios
um ein Mehrfaches schneller), insgesamt also eine ziemliche Rakete
- bis zu 8-fache Speichertiefe
- mit aktivierter Filterung bei nicht maximalen Samplingraten sehr
rauscharm
Die Plattform hat noch einige weitere Goodies, die teils noch nicht
ausgenutzt sind. (Z.B. das Page-Flipping des Grafikspeichers, derzeit
wird noch herumkopiert.) Wir sind noch am Anfang, so gibt es noch keine
assembleroptimierten Teile, derzeit ist alles in C.
Auch für den Capture-Teil bin ich mit Alex noch an ein paar Ideen dran.
Der Hardware fehlt noch die 4-Kanaligkeit, das habe ich derzeit
zurückgestellt um mit dem Capturing voranzukommen, es ein Oskilloskop
werden zu lassen.
So long,
Jörg
Du bist der Held! Deine gute Nachricht freut mich außerordentlich.
Wie schaut es mit folgenden Möglichkeiten aus:
- Display mit höherer Auflösung
- das Problem mit der Anzahl der darstellbaren Farben
- Auswerten aller Schieberegistereingänge z.B. für weitere Tasten
- Beim Trigger: Einstellbare Offtime, d.h. trotz Trigger wird noch
nicht sofort ausgelöst, erst nach einer Wartezeit, um Fehltriggerungen
zu unterbinden (manchmal nötig bei komplizierten Signalen) - bin da von
meinem LeCroy sehr verwöhnt ;-)
Auch von meiner Seite: ich danke Euch ganz herzlich.
Hallo "eProfi",
du hast ein paar gute Punkte angesprochen.
> - Display mit höherer Auflösung
Irgendwo meine ich gelesen zu haben, das es ein mechanisch kompatibles
Display in 800*600 gibt. Könnte das jemand (du?) mal näher untersuchen,
wo kriegt man es, was kostet es, hat es wirklich die gleichen
Anschlüsse?
Prinzipiell kann man sowas anschließen, den LCD-Controller im FPGA drauf
trimmen. Hauptproblem ist der Speicherverbrauch, die 2 MB SRAM sind
knapp. Wir haben jetzt 16 Bitplanes a 38400 Bytes (640*480/8), plus noch
4 für verdecktes Zeichnen, das macht 768000 Bytes. Derzeit passiert die
Darstellung nicht mit dem Display synchronisiert, wenn man das will
braucht man eigentlich 4 weitere Hintergrundplanes (für triple
buffering), dann sind wir bei 921600 Bytes. Also knapp die Hälfte des
RAMs ist nur dafür schon weg.
Bei 800*600 wären das flächenproportional bei triple buffering 1440000
Bytes. 2-Kanal User kommen günstiger weg. ;-)
In der Praxis läßt sich vielleicht noch was einsparen, wir verwenden
noch nicht alle 16 Planes. (S.u.)
Die Speicherbandbreite hält sich noch im Rahmen. Derzeit verbraucht das
LCD knapp 15% der Buskapazität. Der Rest steht dem Prozessor zur
Verfügung, aber dank Cache will der gar nicht immer ran.
> - das Problem mit der Anzahl der darstellbaren Farben
Welches Problem genau meinst du? Die alte Hardware hat da verschiedene:
3 von den 16 Planes waren nicht nutzbar, weil schwarz. 2 hatten die
gleiche Farbe und Priorität, da hätte evtl. auch eine gereicht. Sind wir
schon bei 4 verschwendeten Planes. Eine hat einen Bug, der die linken
und rechten 32 Pixel nicht nutzbar macht. Dann gibt es noch ein paar
obskure Querbeeinflussungen der Farben.
Die neue Hardware kann da einiges besser:
Alle 16 Planes sind individuell in der Farbe einstellbar, so frei wie es
die Pins zum LCD erlauben (9 Bits). Bei der alten Hardware war nur eine
Plane einstellbar, die vom Grid, und auch nur mit 6 Bits.
Bei allen Planes ist die Basisadresse im Speicher programmierbar, auch
zur Laufzeit, so können wir Page Flipping.
Nochmal zu den Farben:
Trotz 9 Bit können wir eigentlich "nur" 125 Farben, 5 Abstufungen für
rot, grün, blau. Hardwaremäßig sind es wegen 3 Bit pro Farbe eigentlich
8 Stufen, aber die fallen paarig quasi zusammen, benachbarte
unterscheiden sich nur um eine irrelevante Winzigkeit.
> - Auswerten aller Schieberegistereingänge z.B. für weitere Tasten
Das ist in der Hardware schon drin. Wir haben die Möglichkeit, 5 Tasten
mehr anzuschließen. Ich habe mir bereits Drehgeber mit Tastfunktion
besorgt. ;-)
> - Beim Trigger: Einstellbare Offtime, d.h. trotz Trigger wird noch> nicht sofort ausgelöst, erst nach einer Wartezeit, um Fehltriggerungen> zu unterbinden (manchmal nötig bei komplizierten Signalen)
Du meinst holdoff? Da hat sogar die alte Hardware ein Register für, die
neue noch nicht. Gerade am Wochenende hatte ich drüber nachgedacht,
sowas noch einzubauen. Ist das eine Totzeit nach dem Trigger, für die
eine weitere Triggerung unterdrückt wird? Oder wird immer 2 mal
getriggert?
Bei uns müssen wir noch berücksichtigen, das wir meist eine blinde Zeit
haben, nämlich die unsere Zeichnen länger dauert als das Capturing.
Danke für konstruktive Vorschläge,
Jörg
Hi,
war in den letzten Tagen ziemlich busy da mir einiges Unvorhergesehenes
in die Quere gekommen ist und mich vom eigentlich Wichtigen ;-)
abgehalten hat.
Zum Holdoff:
Wie Jörg schon sagt gibt es die auch in der alten Firmware (sprich
BF.x.x). Das scheint auch ganz gut zu funktionieren. Wenn man einen
Impulsgenerator hat der Bitmuster produzieren kann, läßt sich das
schnell prüfen.
Mein Neuzugang kann Doppelpulse generieren. Wenn man normal triggert
springt das Signal hin und her, da mal auf den ersten und mal auf den
zweiten Puls getriggert wird. Wenn man Holdoff etwas größer einstellt
als den Abstand der beiden Pulse aber kleiner als die Periode, dann
erwischt er immer nur den ersten Puls.
Jörg H. schrieb:> Ist das eine Totzeit nach dem Trigger, für die> eine weitere Triggerung unterdrückt wird?
Ja
> Oder wird immer 2 mal getriggert?
Nein
Gruß Hayo
Nachschlag zur Realisierung:
Ich vermute, dass man die Holdoffsteuerung auch mit der
Pulsbreitentriggerung oder umgekehrt kombinieren kann.
Eine Pulsbreitentriggerung könnte ich mir als Kombination aus
Flankentrigger mit Holdoff vorstellen.
Also Trigger auf steigende Flanke, Holdoff-delay und dann Trigger auf
fallende Flanke (für den Bereich ">"). Zusätzlich müßte eine weitere
steigende Flanke den Prozess wieder neu starten da sonst auf die nächste
fallende Flanke der nächsten Periode getriggert würde.
Das Holdoff ist ja im Prinzip nur ein programmierbarer Timer der ein
Ereignis auslöst. Welches Ereignis das ist, müßte man ja wählbar machen
können.
Gruß Hayo
Jörg H. schrieb:> Bei uns müssen wir noch berücksichtigen, das wir meist eine blinde Zeit> haben, nämlich die unsere Zeichnen länger dauert als das Capturing.
Mach dich da mal nicht schlechter als du bist. Selbst Rhode und Schwarz
hat eine blindtime bei ihren Oszis. Bei denen ist sie nur vielleicht ein
wenig kürzer ;)
Btw: als bisher stiller mitleser wollte ich dir mal meinen Respekt vor
deiner Arbeit aussprechen. Es ist immer interessant was was du tust und
ich lese den Thread immer aufmerksam mit - obwohl ich garkein Welec habe
und auch keines kaufen werde.
Grüße, Sebastian
Mit den Farben meinte ich Folgendes:
> Nochmal zu den Farben:> Trotz 9 Bit können wir eigentlich "nur" 125 Farben, 5 Abstufungen> für rot, grün, blau. Hardwaremäßig sind es wegen 3 Bit pro Farbe> eigentlich 8 Stufen, aber die fallen paarig quasi zusammen,> benachbarte unterscheiden sich nur um eine irrelevante Winzigkeit.
Das kann man ändern, indem man 9 Display-Leitungen auf Gnd oder 3V3
legt:
Beitrag "Re: Welec W20xx Bedienelemente modifizieren: Drehgeber Encoder LED BNC-Buchsen"
Dort stehen auch die Infos zu Displays mit höherer Auflösung.
Optrex wurde von Kyocera Display Corp. übernommen, deswegen gehen die
Links nicht mehr.
in Frage kommen folgende 7.0" displays (6.5 wie das Original haben sie
nicht mehr, weil die Produktionsanlagen zu alt sind):
http://www.kyocera-display.com/products/partdetail.asp?PartNumber=TVL-55728D070J-LW-I-AAN
www.kyocera-display.com/products/partdetail.asp?PartNumber=TCG070WVLQAPN
N-AN00
www.kyocera-display.com/products/partdetail.asp?PartNumber=TCG070WVLPAAN
N-AN50
www.kyocera-display.com/products/partdetail.asp?PartNumber=TCG070WVLPAAN
N-AN00
http://www.sharpsma.com/lcds/5-9-inch-13-25-cm/LQ065Y5DG03 (800x480)
Ein Ersatz für das originale 640x480 wäre evtl.
NL6448BC20-08
Besserwisser schrieb:> Mit den Farben meinte ich Folgendes:>> Nochmal zu den Farben:>> Trotz 9 Bit können wir eigentlich "nur" 125 Farben, 5 Abstufungen>> für rot, grün, blau. Hardwaremäßig sind es wegen 3 Bit pro Farbe>> eigentlich 8 Stufen, aber die fallen paarig quasi zusammen,>> benachbarte unterscheiden sich nur um eine irrelevante Winzigkeit.>> Das kann man ändern, indem man 9 Display-Leitungen auf Gnd oder 3V3> legt:> Beitrag "Re: Welec W20xx Bedienelemente modifizieren: Drehgeber Encoder LED BNC-Buchsen"
Damit büßt du aber Helligkeit ein (auf Gnd legen) oder schaffst kein
Schwarz mehr (auf Vcc legen).
Ich finde das Zusammenschalten der unteren Bits seitens Wittig recht
geschickt. Zwar weniger Farben, aber die volle Dynamik.
Wenn man den Konflikt lösen will könnte man ein
Zwischensteckerplatinchen bauen, mit einem ROM/PLD etc. was die je 3 Bit
einigermaßen gleichmäßig auf 6 Bit skaliert (Multiplikation mit 9). Wenn
es gelingt, anderswo noch FPGA-Ausgänge freizuräumen, dann könnte man
noch Extra-Bits zuführen. Das wäre aber ein garstiger Verhau...
Wir haben nach wie vor 16 binäre Planes, das man für jede nur aus 125
Farben auswählen kann empfinde ich nicht als signifikante Einschränkung.
Bei einem Vollfarbmodus wäre das vielleicht anders, aber der ist mir zu
teuer in Hinsicht auf Speicherverbrauch und Update-Problematik.
>> Dort stehen auch die Infos zu Displays mit höherer Auflösung.> Optrex wurde von Kyocera Display Corp. übernommen, deswegen gehen die> Links nicht mehr.>> in Frage kommen folgende 7.0" displays (6.5 wie das Original haben sie> nicht mehr, weil die Produktionsanlagen zu alt sind):
Die sind alle 800*480, also nicht 4:3, paßt das sinnvoll hinter den
Gehäuseausschnitt?
Ich hatte mehr auf 800*600 geschielt, aber nichts gefunden, außer
vielleicht elektronische Bilderrahmen auszuschlachten. (Falls die noch
nicht zu hoch integriert sind, noch ein abtrennbares Panel haben.) Das
wäre aber keine sehr nachhaltige Beschaffungsquelle.
Jörg
mal ne Zwischenfrage, wozu brauchen wir denn so eine Farbenpracht im
Display?
Reichen die vorhandenen denn nicht aus?
> Die sind alle 800*480, also nicht 4:3, paßt das sinnvoll hinter den> Gehäuseausschnitt?
Das wäre dann ja schon fast 16:9 und passt auf keinen Fall in den
Gehäuseausschnitt, würde ich mal so auf die Schnelle behaupten.
800x600 wäre ja dann wieder 4:3.
Wenn dann eine höhere Auflösung gefahren werden könnte, wieviel macht es
dann bei der Darstellung der Signalformen aus? Die ja im Moment so ab
50MHz(z.B.Rechteck)nicht so besonders ist.
Ich habe da ja den direkten Vergleich einer solchen Darstellung.
Das Voltcraft mit seinen WVGA 800x480 kann bis 80MHz ein Rechteck noch
gut erkennbar darstellen. Wahrscheinlich geben die Grafikchips ja nicht
mehr her?!
Was ist da eigendlich im Welec verbaut? Im Voltcraft habe ich was mit
Samsung im Gedächtnis
Gruß Michael
Jörg H. schrieb:> Wenn man den Konflikt lösen will könnte man ein> Zwischensteckerplatinchen bauen, mit einem ROM/PLD etc. was die je 3 Bit> einigermaßen gleichmäßig auf 6 Bit skaliert (Multiplikation mit 9).
Hallo Jörg,
3 Bit mal 9 ist doch genau das Ausgangsbitmuster zwei mal
hintereinander. Das sollte doch ohne ROM/PLD gehen.
Frank schrieb:> 3 Bit mal 9 ist doch genau das Ausgangsbitmuster zwei mal> hintereinander. Das sollte doch ohne ROM/PLD gehen.
Stimmt! Genial!
(Ich wollt's mir noch aufmalen, wie das binär eigentlich aussieht...)
Aber klar: Mal 8 ist links-schieben um 3 Bit, plus mal 1 ergibt weil
unten nun alles null ist nochmal die originalen 3 Bit.
Dann sind es doch nur Drähte. Kann man knifflig auf dem Board patchen,
oder mit einem passiven Zwischenstecker.
Ich nehme zurück, was ich über Wittigs geschickte Zusammenschaltung
gesagt habe, das hätte man doch besser machen können.
Jörg
So,
hier gibt es nun endlich eine Alpha-Version des neuen FPGA-Design samt
passendem Osoz zum Ausprobieren für alle.
Ähem, genauer: alle die ein .sof in das FPGA schreiben können. (Damit
ändert man temporär den FPGA-Inhalt, bis zum nächsten Ausschalten.)
Dazu braucht man den Slog-Treiber (geht glaube ich nicht mit 64 Bit
Windows), oder bevorzugt einen "USB Blaster" bzw. China-Nachbau, gibt es
für <10€ in der Bucht.
Dann noch die Programmer-Software von Altera, wenn schon nicht die ganze
Quartus-Suite:
https://www.altera.com/download/software/prog-software
Beim 4-Kanäler muß man in der Nähe der JTAG-Steckers noch einen 0-Ohm
Widerstand bzw. eine Brücke einlöten. Gab es neulich ein Bild zu, ich
finde es nicht.
Osoz tut man vorher ins Flash, mit dem guten alten GERMSloader-Verfahren
(nicht mal UCL, buh). Es kommt an eine andere Stelle als die
BF-Firmware, die beiden stören sich nicht. Man verbaut sich also nichts.
Wenn das .sof geladen ist startet es die Software aus dem Flash, so
braucht man da nichts weiter nachladen. Nach Aus- und Einschalten hat
man wieder das alte FPGA und die BF-Firmware. Man kann das neue FPGA
auch zum permanenten Gebrauch in das EPCS-Flash brennen, aber das
kriegen wir später (klappt z.Zt. nicht, obwohl ich das prinzipiell schon
mehrfach gemacht habe).
Ich hoffe, wir helfen uns gegenseitig, eine "ordentliche" Anleitung z.B.
im Sourceforge-Wiki zu erzeugen. Ich bin vermutlich zu betriebsblind für
die anfänglichen Schwierigkeiten.
Was geht: (es ist schon ein Oszilloskop)
- sauberes Capturing ohne Glitches oder Sample-Vertauschung, mit voller
Speichertiefe
- Trigger auf einzelne Samples genau
- Zeitbasis, wenn auch nur als Samplerate, nicht us/Div
- Filterung der Samples in Hardware, niedrigere Zeitauflösungen dadurch
rauschfrei
- alles was Osoz kann: Settings im Flash, serielles Terminal, schneller
Screenshot, ...)
Was geht nicht:
- 4 Kanäle, derzeit kriegt jeder nur 2
- alles was in Osoz noch nicht drin ist (z.B. Meßfunktionen, Zoom, X/Y,
FFT, ...)
Noch ein paar Bedienhinweise (für Osoz-unkundige):
- Nach dem 1. Start kalibrieren. Die Eingänge kurzschließen oder
zumindest offen lassen, im Utility-Menü "Calibrate Offsets" anklicken.
Das bestimmt für jede Verstärkungsstufe den Nulloffset. Dann noch
"Calibrate ADCs", das bestimmt die Abweichung der 4 ADCs pro Kanal
zueinander. Derzeit nur die Nullabweichung, nicht die Linearität. Dafür
erzeugt der letzte Menüpunkt langwierige Ausgaben auf RS232, aber nur
zum Test, das braucht ihr nicht durchführen.
- Die Filterung kann man im Menü "Aquire" ausschalten. Sie wirkt
generell nur bei <125 MSa/s.
- Im Display-Menü kann man mit den Darstellungsmodi experimentieren
- Das Edge-Trigger Menü bietet Einstellmöglichkeiten
- Die Kanal-Menüs auch
- Main/Delayed bietet eine Ansicht aller Samples, statt sonst nur der
ersten 600
- Die anderen Menüs sind noch leer
- Run/Stop Single geht
Ich bin gespannt auf den Frequenzgang, ob das alte FPGA den künstlich
verbogen hat. Wenn das mal jemand testen kann, ich habe keinen
Generator. Vorher vielleicht die Filterung ausschalten, bzw.
vergleichen.
Viel Spaß!
Jörg
> Damit büßt du aber Helligkeit ein (auf Gnd legen) oder> schaffst kein Schwarz mehr (auf Vcc legen).
Ist aber marginal, da nur die unteren Bits betroffen sind.
Ich habe ein Welec umgebaut, wenn man es nicht weiß, bleibt es
unbemerkt.
> 3 Bit mal 9 ist doch genau das Ausgangsbitmuster zwei mal> hintereinander. Das sollte doch ohne ROM/PLD gehen.
Na das nenne ich Teamwork, genial!
Statt die jeweils 3 unteren Bits auf Gnd oder Vcc zu legen, löten wir
sie an die oberen 3 Bits an, das geht relativ easy im vorhandenen Kabel.
Danke Frank!
> mal ne Zwischenfrage, wozu brauchen wir denn so eine Farbenpracht> im Display? Reichen die vorhandenen denn nicht aus?
Es macht schon einen riesen Unterschied, ob Du aus 125 oder 512
auswählen kannst, wenn man z.B. Verläufe oder Bilder darstellen will.
Und es kostet ja nichts, außer ein paar Lötungen.
Wegen dem 800x600 muss ich nochmal nachschauen, ich meine auch, ein
kompatibles gesehen zu haben.
Ich habe als Displayersatz oder -zusatz schon auf ein Pad geschielt,
z.B. das Xoom mit 10,1" (1280 x 800), das es als Wi-Fi-Version (ohne
Telefonfunktion) oft recht günstig gibt (nachdem die "Dummy with active
display" für 15 Euro plötzlich in 06.2012 vom Markt verschwanden).
Beitrag "Handydummy (Attrappe)mit richtigem Display 10Zoll - u.a.Motorola Xoom"
Hallo Jörg,
ich verfolge deinen Ansatz schon länger und bin echt begeistert wie weit
Du und die andern Entwickler mittlerweile gekommen seit - Respekt!
Ich wollte das Design jetzt mal ausprobieren, hab aber keinen
USB-Blaster.
Es ist doch möglich den internen FX1 entsprechend zu programmieren:
http://sourceforge.net/apps/trac/welecw2000a/wiki/USBBlaster
Ist das möglich, was spricht dagegen?
Das hätte auch den Vorteil, dass ich das Gerät nicht aufschrauben muss.
Gruß
Stefan
Hallo Jörg,
hier der Vergleich eines 50MHz Signals aus einem uralten Rohde und
Schwarz Mess-Sender dargestellt auf NIOS und dem neuen NIOS II .
Bei dieser Gelegenheit möchte ich meine grosse Hochachtung vor dieser
Arbeit aussprechen und auch allen anderen Beteiligten danken, die dieses
Projekt unermüdlich voranbringen.
Gruss Klaus
Stefan V. schrieb:> Ich wollte das Design jetzt mal ausprobieren, hab aber keinen> USB-Blaster.> Es ist doch möglich den internen FX1 entsprechend zu programmieren:>> http://sourceforge.net/apps/trac/welecw2000a/wiki/USBBlaster>> Ist das möglich, was spricht dagegen?> Das hätte auch den Vorteil, dass ich das Gerät nicht aufschrauben muss.
Ja, genau das meinte ich mit "Slog-Treiber". Und es hat den Vorteil, das
Gerät nicht öffnen zu müssen und auch keinen 0-Ohm-Widerstand oder
Brücke einlöten zu müssen. (Edit: ich bin jetzt verwirrt, wann man die 0
Ohm braucht. Anscheinend doch für Slog...)
Ich fand den Slog-Treiber recht knifflig zu installieren, weil sich
Windows immer wieder mit dem HID-Treiber vordrängelt. Unter Linux soll
das besser gehen.
Oder man ändert die USB-Firmware permanent, dann hat man wohl nicht das
Problem das es sich zuerst noch als HID-Device meldet.
Ich weiß auch nicht, wie die FPGA-Programmierung am besten zum
Breitensport wird. Gibt ungefähr 3 Wege.
Klaus, vielen Dank für den Test. Kannst du die Frequenz variieren, gibt
es da Auffälligkeiten?
Jörg
Hi,
bin leider noch beim analogen Part und komme deshalb (zerlegte Geräte)
nicht dazu das zu testen. Sobald ich die Kisten wieder zusammen habe
mache ich mal eine Frequenzganganalyse. Allerdings sind beide DSO nicht
mehr original bestückt. Ein Vergleich zur originalen Bestückung wäre
wohl auch recht interessant...
Hayo
Hallo Jörg,
zum Frequenzgang kann ich mit diesen Messmitteln wenig sagen, aber es
ist schon richtig schön zu sehen, dass die Sinusform bis über 100MHz
sauber erhalten bleibt. (kein Ringing on Welec). Die Spikes Problematik
ist offensichtlich auch vollständig behoben.
@ all
Ich kann nur jedem empfehlen das neue Design auszuprobieren. Es geht mit
installiertem Quartus ganz einfach und der Weg zurück ist der
Netzschalter.
Gruss Klaus
Hi all,
etwas neues an der Windows7x32-Front zum Breitensport ;)
Jörg H. schrieb:> Ich weiß auch nicht, wie die FPGA-Programmierung am besten zum> Breitensport wird. Gibt ungefähr 3 Wege.
einer könnte sein....
..."Slog-Treiber" installieren ging einfach nachdem die Datei
"CyUsb.spt" noch im "Driver" Verzeichnis stand(einfach aus CyUsb nach
Driver kopieren).
Den falschen Treiber erwischt man dann ganz gut wenn man inder
Systemsteuerung von Windows "Geräte u. Drucker" öffnet, dann einfach
über die Eigenschaften des pösen Gerätes den Treiber aktualisieren
\USB_Blaster_for_W2000_v1.1\Driver\CyUSB.inf auswählen und dann
AlteraUsbdevice von der zur Auswahl stehenden nehmen.
Warnungen ignorieren und Software trotzdem installieren.
Wichtig: Ein leerer Ordner "CyUsb" muß vor all dem im Verzeichnis
Windows\System32\ angeleget werden.
Jörg, Kompliment zu zu dem Großen Wurf - alle Achtung!
Auch an dieser Stelle noch meinen Dank für die tolle Arbeit.
so long
Jochen
Ok ich mache die Rückmeldung zur Frequenzgangmessung mal hier, weil das
ja für OSOZ interessant ist und nicht nur rein Hardwaremäßig.
1. Der Frequenzgang ist mit dem NIOS II FPGA identisch zur originalen
NIOS I Ausführung. Es wird also nicht im FPGA gefiltert wie wir vermutet
hatten. Auch hier stürzt der Amplitudengang ab 15MHz ab und erreicht bei
70 MHz die -3dB Grenze.
2. Der Bildschirm flimmert ziemlich stark und hat Störungen auf der
rechten Seite und auch über den ganzen Schirm verteilt.
3. Der Drehgeber für den Spannungsbereich reagiert manchmal nicht. Man
kann hin und her drehen ohne das etwas passiert. Nach einiger Zeit
reagiert er dann wieder.
4. Das Signal verliert ab 73 MHz den Trigger. Ab da läuft das Signal
durch und er kann es auch nicht mehr bei höheren Frequenzen fangen.
Gruß Hayo
Danke an alle Tester und für die Blumen,
(wer hat es noch nicht getestet, und warum nicht?)
Hayo W. schrieb:> 1. Der Frequenzgang ist mit dem NIOS II FPGA identisch zur originalen> NIOS I Ausführung. Es wird also nicht im FPGA gefiltert wie wir vermutet> hatten. Auch hier stürzt der Amplitudengang ab 15MHz ab und erreicht bei> 70 MHz die -3dB Grenze.
OK, dann also analog weitersuchen... Die 100MHz-Geräte sind also
irgendwo künstlich arg begrenzt?
> 2. Der Bildschirm flimmert ziemlich stark und hat Störungen auf der> rechten Seite und auch über den ganzen Schirm verteilt.
Das ist interessant. Andi hat bei kaltem Gerät auch leichte Störungen,
bei mir ist alles sauber.
Ich habe mittlerweile die LCD-Ansteuerung auf reine Registerausgänge
umgestellt. Das sollte ein saubereres Timing ergeben, war beim SRAM
seinerzeit der Durchbruch. Kannst du mal bitte das angehängte .sof
ausprobieren? (@all: Das ist kein neuer Release, nur eine Testversion,
zeitlimitiert weil ohne Nios-Lizenz.)
> 3. Der Drehgeber für den Spannungsbereich reagiert manchmal nicht. Man> kann hin und her drehen ohne das etwas passiert. Nach einiger Zeit> reagiert er dann wieder.
Das kenne ich gar nicht, nie gehabt. "Known bugs" sind träge Tasten bei
main/delay und springende Werte beim ersten Drehen, da muß ich noch was
tun.
> 4. Das Signal verliert ab 73 MHz den Trigger. Ab da läuft das Signal> durch und er kann es auch nicht mehr bei höheren Frequenzen fangen.
Da bist du mir mit deinem Equipment voraus, sowas habe ich nicht im
Haus. (Hmm, ich könnte einen unbenutzen Ausgang des FPGA mit einer
PLL-Frequenz belegen.)
Über den Trigger habe ich letztens auch mit Alex diskutiert, eventuell
ist da noch was in der Hardware zu verbessern. Deren
Softwareeinstellungen sind aber auch noch nicht ausgereizt.
Ansonsten:
Man kann das neue FPGA-Design jetzt auch permanent reinbrennen. Bei der
Softwareentwicklung spart das Zeit, und es ist faszinierend, wie schnell
das Gerät startet. Geht im Sekundenbruchteil.
Dank an Andi, der rausgefunden hat das beim 4Kanäler der Originalinhalt
im 2. FPGA "stört".
Auf Wunsch kann ich die .jic Files veröffentlichen.
Ich habe das Design jetzt in 2 'Revisions' aufgeteilt, in Master und
Slave, für die beiden FPGAs. Das Thema will ich als nächstes angehen,
damit wir auch wieder 4 Kanäle haben.
Zuletzt hatte ich noch mit "custom instructions" experimentiert. Man
kann für den Nios eigene (Rechen)Befehle implementieren, und ggf. so die
Software schneller kriegen. Für's erste habe ich Befehle für min, max,
und clipping implementiert. Bringt ein bischen was, war hauptsächlich
zum Üben.
Grüße,
Jörg
Jörg H. schrieb:> OK, dann also analog weitersuchen... Die 100MHz-Geräte sind also> irgendwo künstlich arg begrenzt?
Genau, ich habe auch schon zwei Ansätze, wird aber ein ziemliches
Gefummel das rauszufinden.
> Kannst du mal bitte das angehängte .sof> ausprobieren? (@all: Das ist kein neuer Release, nur eine Testversion,> zeitlimitiert weil ohne Nios-Lizenz.)
Bin leider eben erst vom Training zurück und bin morgen voll ausgebucht.
Wird vermutlich erst am Wochenende was.
>> 3. Der Drehgeber für den Spannungsbereich reagiert manchmal nicht. Man>> kann hin und her drehen ohne das etwas passiert. Nach einiger Zeit>> reagiert er dann wieder.> Das kenne ich gar nicht, nie gehabt. "Known bugs" sind träge Tasten bei> main/delay und springende Werte beim ersten Drehen, da muß ich noch was> tun.
eigentlich läuft es ganz flott, nur manchmal reagiert es gar nicht.
>> 4. Das Signal verliert ab 73 MHz den Trigger. Ab da läuft das Signal>> durch und er kann es auch nicht mehr bei höheren Frequenzen fangen.> Da bist du mir mit deinem Equipment voraus, sowas habe ich nicht im> Haus. (Hmm, ich könnte einen unbenutzen Ausgang des FPGA mit einer> PLL-Frequenz belegen.)> Über den Trigger habe ich letztens auch mit Alex diskutiert, eventuell> ist da noch was in der Hardware zu verbessern. Deren> Softwareeinstellungen sind aber auch noch nicht ausgereizt.
Kann das mit der Taktfrequenz zusammenhängen? Die liegt ja auch in dem
Bereich.
Gruß Hayo
bin heute früher zu hause als gedacht und habe gleich mal Deine
master.sof geladen.
Zuerst mal - es ist besser geworden. Die ganz üblen Störungen am
Bildschirmrand sind weg. Es sind aber immer noch kleinere Störungen da.
Ich liste mal auf:
- in der Zerolevelbeschriftung "DC" gibt es eine flimmernde Störung die
den Schriftzug zum Teil unleserlich macht (wird besser je wärmer das
Gerät wird)
- im Grid ist auf Höhe des Zerolevels ein Pixel verschoben. Diese
Störung läuft mit dem Zerolevel mit.
- auf Höhe des oberen Signalpegels gibt es Störungen neben dem Grid die
so aussehen wie eine Weiterführung des Signals aber viel schwächer.
- das Ganze aber nur bei Kanal 1. Bei Kanal 2 tritt das nicht auf.
- das Bild flimmert immer noch - abhängig von der Zeitbasis und dem
Zeichenmodus und - der Signalfrquenz! Bei einer Kombination hatte ich
das obige zweite Bild.
- Wenn ich Kanal 1 abschalte und nur Kanal 2 anschalte ist alles ok,
kein Flimmern, keine Störungen.
Übrigens sehr schönes Scrollen mit dem Zerolevel. Wirkt schon fast
analog. Gefällt mir gut.
Eine vorstellbare Ursache der Störungen könnte die Tatsache sein, dass
bei meinem Gerät wegen der analogen Umbauten die Abschirmbleche zur Zeit
ausgebaut sind. Allerdings treten die Störungen beim NIOS I nicht auf.
Gruß Hayo
p.s. interessante Zeitbaseneinteilung...
Hallo Hayo,
mit was hast du denn da oben gefüttert?
Beitrag "Re: made from scratch Firmware für Wittig/Welec Oszilloskop W20xxA"
Sehe ich das richtig, 70MHz Dreieck?
Ich muß erst mal was essen, danach klopp ich mal das NIOS-II drauf.
Mal sehen, was das W2022 so erzählt, ob da Störungen sind oder nicht.
@Jörg
Sind bei der Software die Widerstandsmodifikationen berücksichtigt oder
für die originale Bestückung? Frage nur interessehalber denn bei mir ist
wieder alles original. Ich warte auch erst Hayo's HW-Mod. ab.
Gruß Michael
Hey Hayo,
ja diese Störungen kannte ich auch. Bei mir traten/ treten (wenn er kalt
ist) diese nur im Zusammenhang mit der Farbe Gelb auf. (Jörg kann das
schon fast nicht mehr hören ;-)
Auch ein Verschieben in eine andere Plane brachte damals keine Änderung!
Einen Test habe ich noch für Dich!
Du könntest mal in der lcd.c folgende Werte ändern ...
// signal display layer
0x00FFFF00, // ePlaneChannel1: yellow
zu
0x00DDFF00, // ePlaneChannel1: yellow
Nach dieser Änderung waren alle von Dir aufgeführten Probleme weg.
Gruß Andi
Hi,
ich muß leider gerade passen, da meine Schätzchen wieder zerlegt auf dem
Rücken liegen. Ich suche wieder nach der angezogenen Handbremse der
100MHz Geräte.
@ Michael
> Sehe ich das richtig, 70MHz Dreieck?
Nein 70 MHz Sinus, das sieht bei der Auflösung nur nach Dreieck aus.
Hayo
Hayo W. schrieb:> So sieht das dann in Natura aus...
Jaja, wie alte Männer halt arbeiten. Das kenne ich nur
zu gut. ;-)
Grüße, Guido, der momentan mehr mit dem Bohrhammer unterwegs ist.
Ich habe den thread heute zum ersten male gesehen und bin sehr
interessiert, mehr dazu zu erfahren. Meine sponante Frage wäre, ob es
zielführend ist, einen NIOS im FPGA zu benutzen, wo doch der FPGA gerade
auf low lovel Ebene viel effektiver einzusetzen wäre.
Gibt es keine andere Möglichkeit, firmware laufen zu lassen?
Mark F. schrieb:> Gibt es keine andere Möglichkeit, firmware laufen zu lassen?
Klar, gehen tut alles. Die Aufgabenstellung für ein Oszilloskop
ist jedoch so komplex, dass diese kaum in Hardware zu realisieren
ist. Andererseits ist der FPGA so leistungsfähig, dass es wenig
Sinn macht, auf einen integrierten µC zu verzichten.
So, habe mal das OSOZ aufgespielt und mal ein 80MHz Signal mit 2ns
Risetime drauf gegeben.
Ich nehme mal an, das momentan nicht mehr als 50ns zur Verfügung stehen,
deshalb habe ich von der BF.6.4C6 dieselbe Zeitbasis gewählt.
Während das Signal im OSOZ vom Jörg ohne "Stopmodus" schön still hält
(siehe Foto), zappelt es in der BF6 ordentlich ab, also ohne das Display
einzufrieren, wäre kein Foto möglich gewesen.
Verzerrungen auf dem Schirm jeglicher Art, konnte ich jetzt in keinem
Modi feststellen auf dem W2022.
Gruß Michael
EDIT: Ich habe auch noch mit anderen Frequenzen zwischen 8-32MHz
herumgespielt, dabei ist mir aufgefallen, das bei der BF.6 wieder die
Spikes ihr Unwesen trieben, in der OSOZ nicht!
Hui, voll was los hier!
@Hayo: du hast ja interessante LCD-Phänomene. Da fällt mir dummerweise
fast nichts zu ein. Das sieht nicht nach Timingproblemen am Pixelbus
aus, sondern danach das er sich falsche Daten greift. Das wäre ein
FPGA-internes Problem, aber wenn da das Timing nicht sauber ist würde
Quartus das bereits anmeckern.
Sehr schwierig da aus der Ferne was dran zu machen, da müßte man sich
interaktiv rantasten.
Zum PS: Die Zeitbasen ergeben sich aus den verfügbaren Teilerstufen. Den
Rest muß die Software dann noch hübsch machen.
@Michael: Wie du dann vielleicht gesehen hast kann man pro Kanal
einstellen, wie denn der Eingang bestückt ist, original, 25+175 Ohm,
neue Eingangsstufe.
Für die Spikes kann Hayos Software nichts, das ist das kaputte originale
FPGA-Design.
@Mark: So ein Nios II/f ist bestimmt die schnellste CPU, die wir in den
FPGA reinkriegen. (Außer vielleicht: 2 davon.) Du störst dich daran, das
die CPU die Daten abholen und Linien zeichnen muß? Es gab auch mal einen
anderen Ansatz, das ZPU-Design. Das hatte die kleinstmögliche CPU und es
wurde möglichst viel in Hardware gemacht (sogar die
Benutzeroberfläche!), aber die Features waren sehr eingeschränkt, der
Aufwand explodiert sonst.
Wir wollen aber noch mit den Daten herumrechnen, statistische Meßwerte
bestimmen und was nicht alles, da tut eine ordentliche CPU richtig gut.
Jörg
@Jörg
> @Michael: Wie du dann vielleicht gesehen hast kann man pro Kanal> einstellen, wie denn der Eingang bestückt ist, original, 25+175 Ohm,> neue Eingangsstufe.
Jupp! Habe ich dann auch gesehen...
Wird diese Konstellation 25/175 Ohm jetzt beibehalten, oder könnte sich
da noch etwas verändern? Also wenn dem nicht so ist, würde ich gerne
bald den Austausch der R's(zum 3.Mal) vornehmen.
> Für die Spikes kann Hayos Software nichts, das ist das kaputte originale> FPGA-Design.
So hatte ich das auch gar nicht gemeint.
Hayo gab sein Bestes, was die Software betrifft, keine Frage!
Zu Hayo's Pixelproblem: Wieso habe ich das denn nicht? Könnte das nicht
ein HW Fehler sein?
BtW. Ich kann das FPGA direkt über Quartus in den Speicher setzen, ohne
vorher die Software mit dem Germsloader zu laden!
Noch was, was ist denn der Unterschied zwischen der 'W2000Nios2.sof' und
der 'master_time_limited.sof' bis auf die Meldung im Programmer, das er
die jetzt abschaltet? Wenn der USB-Anschluß zum DSO wären dessen
bestehen bleibt, friert das Welec ein!
Gruß Michael
Michael D. schrieb:> Wird diese Konstellation 25/175 Ohm jetzt beibehalten, oder könnte sich> da noch etwas verändern?
Also eigentlich wollte ich es ja nicht vorweg nehmen, aber bei meiner
BF-Mod habe ich die Werte 2 x 24,9 Ohm mit 330 Ohm gewählt, was einem
resultierenden Lastwiderstand von 300 Ohm entspricht.
Die Spezifikation des AD8131 sagt zwar, dass dieser als Twisted Pair
Leitungstreiber für eine Last von 200 Ohm ausgelegt ist, aber er kann
eine Last bis zu 800 Ohm treiben ohne das die grundlegenden
Eigenschaften sich allzu sehr ändern. Mit der originalen
Wittig-Bestückung liegt der Lastwiderstand bei etwa 630 Ohm, was noch
voll im spezifizierten Bereich ist.
Ich denke daher, das es Seitens Wittigs kein Versehen sondern so
beabsichtigt war. Der verbogene Frequenzgang wird auch nicht vom AD8131
verursacht, sondern vom OPA656. Die Bestückung mit 200 Ohm Last biegt
den Frequenzgang lediglich wieder etwas zurück, aber nicht genug und hat
als unangenehmen Nebeneffekt, dass eine Vollaussteuerung des
ADC-Eingangs nicht mehr vernünftig möglich ist.
Mit meiner 330 Ohm Bestückung läßt sich der ADC-Bereich wieder voll
nutzen, was ich im 5V-Bereich auch ausnutze (bis auf +/- 5 Stufen).
Entgegen der bisherigen Vermutungen hat das keine negativen Nebeneffekte
und ist nur äußersten Bereich minimal nichtlinear.
Nähere Details (auch zur Frequenzgangbegradigung) gibts in meiner BF-Mod
Doku.
Gruß Hayo
Hallo Miteinander!
Gegen die Probleme beim OSOZ mit dem Display hätte ich für Jörg einen
Vorschlag:
Entweder den LDC Clock oder alle Datensignale um einen halben LCD Clock
verzögern.
Das habe ich in letzter Zeit in meiner Firma sehr oft gemacht, falls der
Takt irrlange braucht um den Pegel zu wechseln.
Das ist meiner Meinung nach über 10 MHz immer zu kontrollieren.
MfG
Alexander
Nachschlag,
ich habe das jetzt auch mal bei meinem W2022A eingespielt und da treten
die Störungen nicht auf. Das Bild ist ruhig und alles funktioniert
prima.
Auch hier sind die Abschirmbleche entfernt. Soweit dazu.
Hayo
Ein Versuch gegen die LCD-Störungen:
Eine Idee hatte ich noch über Nacht, heute umgesetzt. Ich habe die
Bereitstellung der Daten aus dem RAM und das LCD-gerechte Rausschieben
noch weiter entkoppelt. Da ist schon länger ein FIFO zwischen, bis jetzt
hat das LCD-Ende selbst rechtzeitig den nächsten Block a 32 Pixel
angefordert, jeweils einzeln. Nun läuft das zeilenweise
füllstandsgetrieben, der Lieferant arbeitet so schnell es geht.
Falls in dem Bereich ein Problem war sollte es jetzt anders aussehen.
Hayo, kannst du damit nochmal testen?
@Alex: Den "Trick" kenne ich auch, aber danach sieht mir das Symptom
nicht aus. Wenn die Datenübername nicht sauber ist stelle ich mir
Störungen von +/- 1 Pixel vor, nicht so verrutschte Bereiche.
Das Timing wollen wir aber noch messen. Andi hat die Stecker für ein
Zwischenstück, und einen LA.
Michael D. schrieb:> BtW. Ich kann das FPGA direkt über Quartus in den Speicher setzen, ohne> vorher die Software mit dem Germsloader zu laden!
Die Germsloader-Prozedur braucht man nur einmal machen. Die Software ist
dann im Flash (nicht im RAM). Wenn man das FPGA lädt findet es die dort,
der Bootloader kopiert sie ins RAM und startet.
> Noch was, was ist denn der Unterschied zwischen der 'W2000Nios2.sof' und> der 'master_time_limited.sof' bis auf die Meldung im Programmer, das er> die jetzt abschaltet? Wenn der USB-Anschluß zum DSO wären dessen> bestehen bleibt, friert das Welec ein!
Diese "_time_limited" Versionen entstehen beim Kompilieren ohne
Nios-Lizenz. Das sind dann Evaluierungsversionen, die ca. 1 Stunde
laufen und sich auch nicht permanent brennen lassen.
Jörg
@Jörg,
> Die Germsloader-Prozedur braucht man nur einmal machen.
Aha!
> Die Software ist> dann im Flash (nicht im RAM).
Oha!!!
> Wenn man das FPGA lädt findet es die dort,> der Bootloader kopiert sie ins RAM und startet.
Jetzt habe ich die Software die ganze Zeit im Flash, bzw. für immer und
ewig???
Wenn ich das DSO ausschalte und dann wieder ein, ist die Sofware immer
noch drin!
Das mit der Evaluierungsversion, habe ich schon verstanden. Ich glaube,
ich mache das mal per PN...
Was bedeutet eigentlich die Bezeichnung "F484" nach dem EP2C35?
Gruß Michael
Hier mal 2 Bildchen vom Delay mit 1kHz Rechteck. Da kann man ja
unbegrenzt zoomen, wie geil ist das denn?
Wieso ist da kaum ein Rauschen zu verzeichnen?
Gruß Michael
Hayo, hier ein weiteres LCD-Experiment. Das ist das gleiche Design wie
vorhin, aber mit verschärften Constraints für die LCD-Ausgänge. (Damit
zwingt man den Fitter, sich Mühe zu geben das die Signale kurze Wege
nach draußen kriegen.) Ob es wirklich was ändert weiß ich nicht, ich
hatte dem Quartus mit "FAST_OUTPUT_REGISTER" bereits gesagt das er die
Flipflops von den Padzellen selbst nehmen soll.
Michael D. schrieb:> Jetzt habe ich die Software die ganze Zeit im Flash, bzw. für immer und> ewig???
Naja, in 2 bisher unbelegten Flash-Sektoren, die die BF-Software nicht
stören.
> Wenn ich das DSO ausschalte und dann wieder ein, ist die Sofware immer> noch drin!
Solange bis du eine bessere einspielst. Sie wird nur mit dem neuen
FPGA-Design gestartet, das alte was nach dem Einschalten kommt startet
nach wie vor die BF-Software.
Aber ich denke du hast das schon verstanden und willst mich nur mit
künstlicher Erregung aufziehen. ;-)
Wenn du das Nios II Osoz unbedingt restlos löschen willst kannst du das
Hexfile nach den Zeilen die mit 'e' anfangen abschneiden, dann wird nur
gelöscht, nichts mehr reingeschrieben.
> Was bedeutet eigentlich die Bezeichnung "F484" nach dem EP2C35?
Das er 484 Pins hat. Ob das 'F' was bedeutet weiß ich nicht.
Michael D. schrieb:> Hier mal 2 Bildchen vom Delay mit 1kHz Rechteck. Da kann man ja> unbegrenzt zoomen, wie geil ist das denn?
"Unendlich", naja, es gibt schon Oszis mit deutlich mehr Speicher... ;-)
Aber wir nutzen unser bischen jetzt bis zu 8 mal besser.
> Wieso ist da kaum ein Rauschen zu verzeichnen?
Weil der Hardwarefilter von Alex an ist. Kann man im "Aquire" Menü
umschalten. Bei langsamen Abtastraten bringt der sehr viel. Hat aber
derzeit ein leichtes Überschwingen, wie man auch in deinem Bild sieht.
Alex, können wir den Filter etwas entschärfen?
Jörg
Hier ist ja wieder was los...
Muß den Test für die neue Displayansteuerung etwas verschieben, da zur
Zeit nur mein W2022A einsatzbereit ist und das hat ja keine der Probleme
gehabt. Das W2014A ist noch häppchenweise über mein Zimmer verteilt. Ich
seh mal zu, dass ich da einen Testbericht liefern kann sobald es wieder
zusammengefunden hat.
Morgen (bzw. heute) soll ja das Wetter gut sein, da werde ich wohl die
Gelegenheit nutzen unsere 8L Hubraum durch die Gegend zu scheuchen was
mich zeitlich etwas zurückwirft.
Also nicht ungeduldig werden, Ergebnis kommt noch.
Hayo
Jörg H. schrieb:> Das ist das gleiche Design wie> vorhin, aber mit verschärften Constraints für die LCD-Ausgänge. (Damit> zwingt man den Fitter, sich Mühe zu geben das die Signale kurze Wege> nach draußen kriegen.) Ob es wirklich was ändert weiß ich nicht, ich> hatte dem Quartus mit "FAST_OUTPUT_REGISTER" bereits gesagt das er die> Flipflops von den Padzellen selbst nehmen soll.
Hey Jörg,
bei mir sind nun die Randprobleme weg. Auch im kalten Zustand kann ich
keine Fehler mehr erkennen (auch bei gelb nicht ;-).
Grüße
Jörg H. schrieb:
> Michael D. schrieb:>> Jetzt habe ich die Software die ganze Zeit im Flash, bzw. für immer und>> ewig???> Naja, in 2 bisher unbelegten Flash-Sektoren, die die BF-Software nicht> stören.
Na dann...
>> Wenn ich das DSO ausschalte und dann wieder ein, ist die Sofware immer>> noch drin!> Solange bis du eine bessere einspielst. Sie wird nur mit dem neuen> FPGA-Design gestartet, das alte was nach dem Einschalten kommt startet> nach wie vor die BF-Software.
Ich wollte eben nur wissen, wo was sitzt, nicht das das Flash noch aus
allen Nähten platzt ;-)
> Aber ich denke du hast das schon verstanden und willst mich nur mit> künstlicher Erregung aufziehen. ;-)
:-)))
>> Wenn du das Nios II Osoz unbedingt restlos löschen willst kannst du das> Hexfile nach den Zeilen die mit 'e' anfangen abschneiden, dann wird nur> gelöscht, nichts mehr reingeschrieben.
oder eben eine neue FW einspielen, wenn ich das richtig verstanden
habe!?
>> Was bedeutet eigentlich die Bezeichnung "F484" nach dem EP2C35?> Das er 484 Pins hat. Ob das 'F' was bedeutet weiß ich nicht.
Achso? Wieder was gelernt, das 'F' könnte für 'Füsse' stehen :-)))
>> Michael D. schrieb:>> Hier mal 2 Bildchen vom Delay mit 1kHz Rechteck. Da kann man ja>> unbegrenzt zoomen, wie geil ist das denn?> "Unendlich", naja, es gibt schon Oszis mit deutlich mehr Speicher... ;-)> Aber wir nutzen unser bischen jetzt bis zu 8 mal besser.
Naja, da hat wohl das Wort 'fast' unbegrenzt gefehlt.
Trotzdem, sehr praktisch, das ein so großer Bereich in einem Modi
abgedeckt wird!
>>> Wieso ist da kaum ein Rauschen zu verzeichnen?> Weil der Hardwarefilter von Alex an ist. Kann man im "Aquire" Menü> umschalten.
Ich hab's entdeckt, der Alias Filter!
Welcher Frequenzbereich wird da abgeschnitten?
Nehme ich den Filter raus, nimmt das Rauschen wohl "etwas" zu, aber kein
Vergleich zu vorher, saubere Arbeit!!!
> Bei langsamen Abtastraten bringt der sehr viel. Hat aber> derzeit ein leichtes Überschwingen, wie man auch in deinem Bild sieht.
Ja, an den Flanken links u. rechts...Tastkopf habe ich vorher
kalibriert, dachte erst, es liegt daran.
Noch ein Pic mit deakiviertem HW-Filter 1kHz, Tastkopf 1:1
Gruß Michael
Mach' mal den Kanal 2 aus, solange du ihn nicht benutzt. Dann hast du
doppelt so viel Speicher für den verbliebenen Kanal, und Main/Delay
sieht nochmal anders aus.
Der Filter soll je das wegfiltern, was man eh nicht sieht. Die
Grenzfrequenz hängt also von der Abtastrate ab.
Jörg
Hallo
die Filter sind in 10er Dezimationsstufen aufgebaut.
Jörg hat den 1GS->100MHz Filter rausgeschmissen, weil ihm vor der
Filterung die ADC Kalibrierung fehlt.
Dieser deaktivierte Filter ist ein Dreieck-Fenster, mit wahlweise 1
(keine Filterung),3,7, oder 15 Werten aufgebaut aus einem Addierbaum.
Die anderen Filterstufen ...
125Ms-12,5Ms bzw 100Ms->10Ms
und sicher noch 10Ms->1Ms, (-> einstellbar zur laufzeit und auch per
VHDL Konstante)
... sind Kaiser Beta 4 FIR Filter, welche immer auf Fs/4 begrenzt sind,
und als Polyphasendezimator effizient implementiert wurden.
Die Koeffizienten wurden mit einem Octave Skript erstellt, zum Ändern
muss man aber das LEON3 Zeug durchstöbern, wo das ist. Es gibt im Moment
keine Möglichkeit, die Filter zur Laufzeit mit der CPU zu ändern.
Ja, man kann die Überschwinger auf Kosten der linearen Bandbreite
geringer machen.
Das F von F484 bezieht sich meines wissens nach auf die BGA Gehäuseart
F->fine
Das C8-C5 ist der Speed Grade (weniger ist besser, aber
unwerschwinglich)
Alexander
Hallo,
ich habe länger nichts geschrieben, aber viel getan. Daher ein
Zwischenstand:
Momentan sitze ich an der Anbindung des 2. FPGAs, für die
4Kanal-Modelle. Endlich, das fehlte ja bisher allen
Eigenbau-FPGA-Ansätzen.
Technisch ist das knifflig, weil das 2. FPGA mit an den Datenleitungen
vom SRAM hängt (leider nicht auch an den Adressleitungen), zusätzlich
gibt es 6 Handshake-Leitungen. Davon verbrauche ich 4 für das
Businterface, eine Art Tunnel für den Nios-Bus. Plus noch 2 für Trigger
hin und zurück, weg sind die Leitungen. Es gibt strenggenommen noch eine
weitere, die Test-Taste auf der Platine geht auch an beide FPGAs. Bei
Bedarf könnte man diese Leitung noch nutzen, wenn keiner die Taste
drückt.
Das 2. FPGA wird bei mir in den Adressraum des Nios eingeblendet, er
kann transparent drauf zugreifen. An den gemeinsamen Datenbus muß erst
die Adresse angelegt werden, dann kommt der eigentliche Buszugriff. Das
ganze noch koordiniert mit den eigentlichen SRAM-Zugriffen macht es so
heikel. Ich wollte das SRAM-Timing nicht verschlechtern müssen. Das hat
gerade so geklappt, aber nur mit einem vereinfachten Ansatz. Erst wollte
ich einen Auto-Inkrement der Adresse vorsehen, damit die bei
aufeinanderfolgenden Zugriffen nicht übertragen werden muß. Hat im
ersten Ansatz nicht hingehauen, da platzt mir der Kopf vor Komplexität
und dem FPGA das Timing. Nun muß vor dem nächsten Lesezugriff brav das
Ergebnis des 1. abgewartet werden, es gibt kein Pipelining.
Trotzdem ist der Zugriff recht schnell, wahrscheinlich sogar schneller
als beim 1. FPGA. Das 2. FPGA ist quasi leer und hat eine ganz einfache
Busstruktur, kein Nios drin, daher kann ich es mir leisten den
Capture-Speicher an den schnellen Bus anzubinden (so schnell wie Nios
und SRAM), statt an den langsamen Peripheriebus wie in FPGA1.
Stand der Dinge: das 2. FPGA müßte jetzt eigentlich funktionstüchtig
angebunden sein. Ich kann z.B. das ID-Register der Capture-Hardware
auslesen. Nun ist noch ein Haufen Software nötig, der Capture-Treiber
muß erweitert werden. Da bin ich gerade bei.
Das zweite FPGA ist leider nicht per JTAG erreichbar, was hauptsächlich
für mich ein Problem ist, testet sich schlecht. Zudem kann man nicht so
einfach ein .sof reinladen wie beim ersten, und nach Aus- und
Einschalten ist alles wieder normal. Der einzige Weg ist, das
Konfigurationsflash mit dem Inhalt beider neuer FPGAs zu brennen. Bei
der nächsten Testrunde müßt ihr also erst ein Backup eurer FPGAs machen,
dann mein Zeug reinbrennen. Das sind aber auch nur ein paar Mausklicks
mehr im Quartus Programmer. ;-)
Später mehr, ich habe da noch ein paar Ideen und Erwägungen...
Jörg
Hallo Jörg,
das hört sich sehr gut an! Und ich komme dann sicher eher zum Testen,
wenn die FPGA's über den Konfigurationsflash geladen werden können und
ich nicht jedes Mal die Kiste öffnen und das Programmierzeugs anfummeln
muss. Weil, ich erinnere mich, daß die Softwarelösung über FX2-Firmware
recht schwer wieder zu entfernen war...
Bin jedenfalls gespannt.
Gruß
Jürgen
Jürgen schrieb:> das hört sich sehr gut an! Und ich komme dann sicher eher zum Testen,> wenn die FPGA's über den Konfigurationsflash geladen werden können und> ich nicht jedes Mal die Kiste öffnen und das Programmierzeugs anfummeln> muss. Weil, ich erinnere mich, daß die Softwarelösung über FX2-Firmware> recht schwer wieder zu entfernen war...
Den Slog-Treiber muß man ja auch nicht gleich wieder entfernen, stört
doch nicht? Ich fand's eher schwierig zu installieren.
Die meisten scheinen das mit dem vorhandenen USB ohne aufschrauben
einfacher zu finden.
Für meine nicht-zerbastelte Zweitkiste habe ich JTAG nach draußen
verlängert: 10poliger Pfostenstecker, ein Stückchen Flachbandkabel durch
einen Lüftungsschlitz hinter dem Tragegriff, dort eine 10polige
Steckwanne aufquetschen. Die könnte man da glatt ankleben, macht sich
sehr unauffällig.
Jörg
Zu den Ideen und Erwägungen:
Die eine Erwägung ist eine Korrektur der ADC-Abweichungen zueinander,
und zwar in Hardware, vor Triggerung und Filterung. Die 4 ADCs pro Kanal
haben einen gewissen Offset zueinander, und eine etwas unterschiedliche
Empfindlichkeit. Es würde die hohen Abtastraten deutlich verbessern,
wenn wir pro ADC die Werte mit einem Korrekturoffset addieren und einem
Korrekturfaktor skalieren.
Das ginge auf 3 Arten:
1. Lookup-Tabelle pro ADC
Das kostet pro ADC einen FPGA-internen Speicherblock, also 8
Speicherblöcke pro FPGA. Können wir uns gerade noch leisten, obwohl ich
das lieber als CPU-Cache oder Reserve behalten hätte. Der Vorteil ist,
auch eine Linearitätskorrektur ist damit möglich. Wir verlieren aber
etwas Auflösung.
2. Addierer und Multiplizierer im FPGA
-> es wären 16 Multiplizierer nötig, soviel haben wir nicht mehr frei
:-(
3. Offset-Korrektur im FPGA, Gain-Korrektur mit nachbestücktem Trim-DAC
Der Offset wird im FPGA durch Addierer ausgeglichen, die Skalierung
extern angepaßt. Welec hat dafür Trim-DACs vorgesehen die die ADCs
steuern, aber nicht bestückt. Die analoge Skalierung erhält den
Wertebereich, aber es ist keine Linearitätskorrektur möglich. Erfordert
Bastelei.
Und zu den Ideen:
Das 2. FPGA hat recht prominent 8 Testpins rausgeführt. An der Oberseite
der Platine sind 8 Pads im Raster 1,27mm in einer Reihe, neben dem
Frontpanel-Anschluß.
Ich habe da erstmal GPIOs draus gemacht, aber damit läßt sich sicher
noch nützlicheres anstellen. Das 2. FPGA ist recht leer, wir könnten
sogar noch 16 kB Speicher zusammenkratzen, meine aktuelle Idee ist ein
8-Kanal Logikanalyzer der parallel zur Oszilloskopfunktion aufzeichnet.
Keine gewaltige Speichertiefe, aber passend zum Rest.
Den externen Trigger könnte man auch noch als Digitaleingang
mißbrauchen, dort hätte man zudem eine einstellbare Schaltschwelle.
Ein bischen denke ich nebenbei über einen Grafik-Coprozessor nach. Wir
haben mit unseren Bitplanes einen ähnlichen Grafikspeicheraufbau wie der
selige Amiga, wenn auch 16 Planes statt 5 und VGA statt TV. Der Amiga
konnte in Hardware u.A. Linien zeichnen und Blöcke verschieben. Fans
haben das mittlerweile auch in einem FPGA nachgebaut, dort könnte man
vielleicht was recyclen.
So ein DMA-Coprozessor sollte auch die Daten vom FPGA ins SRAM kopieren
und konvertieren können...
Ein anderer Gedanke sind 2-3 Byteplanes statt den Bitplanes. Macht die
Welt bunter, aber braucht mehr Speicher. (Und ist total inkompatibel zum
alten Design.)
Im SRAM läuft derzeit auch die beim Start dort reinkopierte Firmware,
aber dafür ist es eigentlich zu schade. Die könnten wir größtenteils
direkt aus dem Flash laufen lassen.
Es gibt aber auch noch genug mit dem jetzigen Stand zu tun, dies nur mal
als Ausblick. Mitmacher wären toll...!
So long,
Jörg
Jörg H. schrieb:> Für meine nicht-zerbastelte Zweitkiste habe ich JTAG nach draußen> verlängert: 10poliger Pfostenstecker, ein Stückchen Flachbandkabel durch> einen Lüftungsschlitz hinter dem Tragegriff, dort eine 10polige> Steckwanne aufquetschen. Die könnte man da glatt ankleben, macht sich> sehr unauffällig.
Das ist natürlich eine gute Idee! Auch wenn das Flashen besser ist :-)
Jörg H. schrieb:> Zu den Ideen und Erwägungen:>> Die eine Erwägung ist eine Korrektur der ADC-Abweichungen zueinander,> und zwar in Hardware, vor Triggerung und Filterung. Die 4 ADCs pro Kanal> haben einen gewissen Offset zueinander, und eine etwas unterschiedliche> Empfindlichkeit. Es würde die hohen Abtastraten deutlich verbessern,> wenn wir pro ADC die Werte mit einem Korrekturoffset addieren und einem> Korrekturfaktor skalieren.
Ich denke wir kommen doch auch nur mit einem Offset aus, der im FPGA zu
jedem ADU addiert wird?. Der wirkt ja auch im ausgesteuerten Bereich.
Wie groß sind denn jetzt die maximalen Abweichungen zwischen den ADU's?
Genügen doch ev. +-8 Inkremente pro ADU. D.h. in 1 Byte sind Werte für 2
ADU's unter zu bringen (wenn denn die notwendigen Addierer noch da sind
??) Das würde schon Tempo bringen!
Jürgen
Jürgen schrieb:> Wie groß sind denn jetzt die maximalen Abweichungen zwischen den ADU's?
Nach meinen Erfahrungen nicht größer als 4. D.h. +/- 8 ist fast schon
etwas oversized.
Hayo
Es ist alles da, man kann auch auf Kanal 3 oder 4 triggern. (Hätte ich
für das Bild mal machen sollen, fiel mir später auch ein.)
Die Software ist derzeit noch etwas wackelig, da muß ich noch was tun.
Vielleicht etwas ausführlicher:
Im FPGA2 steckt die identische Capture-Hardware wie in FPGA1. Über
meinen neuen Busadapter kann der Prozessor da rübergreifen, als ob das
zusätzlich in FPGA1 stecken würde, der merkt den Unterschied gar nicht.
Dann gibt es noch 2 "gekreuzte" Triggerleitungen, damit das FPGA was
gerade nicht die eigentliche Triggerquelle ist auf die Triggerung des
anderen FPGAs triggern kann. (Alles klar? Wie oft paßt das Wort
'Trigger' in einen Satz? ;-)
Dabei entsteht ein Versatz, der noch auszugleichen ist. Ob das in allen
Situationen klappt gilt es noch herauszufinden. Die beiden FPGAs werden
nicht synchron gestartet, denn dafür haben wir eigentlich keine Leitung
mehr.
Jörg
Hallo Jörg,
sehr sehr genial wieviel Herzblut Du in die FGPA/Osoz Entwicklung
steckst.
Vielen vielen Dank.
Jetzt muss ich das Welec und den Slog Treiber mal installieren. ;-)
Weiter so.
Gruß Sven
Wenn Du irgendwelche Tests bei höheren Frequenzen mit allerlei
Signalformen brauchst, sag Bescheid, bzw. stell mal die .sof's rein mit
einer kurzen Anleitung wie man den zweiten FPGA beglückt.
Gruß Hayo
Hallo Jörg,
absolut cool! Ich bin begeistert! Danke für Deine Mühe!
Jörg H. schrieb:> Dabei entsteht ein Versatz, der noch auszugleichen ist. Ob das in allen> Situationen klappt gilt es noch herauszufinden. Die beiden FPGAs werden> nicht synchron gestartet, denn dafür haben wir eigentlich keine Leitung> mehr.
Nicht synchron gestartet macht doch nichts?
Die Samples sollten doch nach einem, von mir aus asynchronen Start,
immer einfach in jedem FPGA landen. Wichtig ist doch nur die richtige
Bufferadresse bei Triggerung zu wissen für jeden Kanal. Wann, wieviel
und wo dies dann auf dem Display dargestellt wird kann doch im
Nachhinein in der Software auseinander klamüsert werden. OK, das kostet
dann wieder Zeit.Aber die Daten sind dann aber immer korrekt
zueinander...
Oha, das wirft ja mehr Fragen auf, als ich eben Antworten habe..:-)
Wieviel Samples vor dem Triggerzeitpunkt und wieviel nach dem
Triggerzeitpunkt werden von der Bedienoberfläche eingestellt? Zusammen
sicher immer Bufferlänge! Also doch Ringbuffer?...
Gruß
Jürgen
Jürgen, so ungefähr hast du recht, mit den Details wollte ich die
Öffentlichkeit eigentlich nicht belasten:
Der Speicher ist "natürlich" ringförmig. Ich starte zuerst den Slave,
dann den Master. Der Master wird vom Signal getriggert, Auflösung bis zu
1/1GHz, der Slave vom Master, Auflösung 1/125MHz Speichertakt, Latenz
vielleicht 2 solche Takte.
Pro Speichertakt verarbeiten wir 8 Samples in einem Rutsch, das ist die
"Wortbreite" auf der Schreibseite. Nach dem Triggern hat nun jedes FPGA
seine eigene Stop-Speicherposition, gemäß der lese ich sie aus. Den
genauen Triggerzeitpunkt innerhalb der 8er Samplegruppe nehme ich immer
vom Master-FPGA.
In diesem Themenbereich könnte ich mir Randwertprobleme vorstellen.
Wegen der 8er Gruppen ist der (noch ungetestete) externe Trigger derzeit
ungenau. Derzeit gibt es keine Mimik, die sich merkt bei welchem der 8
Samples der externe Trigger auftrat. Habe ich aber auf der Liste.
Im Moment habe ich 2 drängendere Probleme, und keine Ahnung woran das
jeweils liegt:
1. Wenn ich das 1. FPGA bei der Arbeit synthetisiere (mit Quartus 9,
aber Nios-Lizenz), dann klappt das augenscheinlich, Timing ist in
Ordnung, aber das Ergebnis läuft nicht. Kein Lebenszeichen, nicht mal
die LED vom Bootloader. So kann ich keinen Release bauen.
2. Seit meiner SRAM-Controller-Erweiterung für den Zugriff auf FPGA2
geht mitunter das Capturing nicht oder nur kurz, je nach Syntheselauf
oder wasweißich. Es ist, als ob ich keinen Interrupt bekäme. Hat
eigentlich so gar nichts mit dem SRAM zu tun.
So der aktuelle Stand, alles nicht so einfach.
Jörg
Hallo Jörg!
Gratulation zu deinem riesen Erfolg mit dem 2ten FPGA.
Die letzt beschriebenen Probleme, dass das Synthesetool keine
Timing-Warnings ausgibt, das ganze aber aufgrund von Timing-Problemen
nicht (richtig) läuft kenne ich vom LEON3 nur allzu gut!
Das Problem liegt einfach darin, dass das Synthesetool von sich aus nur
die Pfade zwischen 2 Registern mit demselben Clocksignal überprüft und
optimiert. Selbst wenn man für die Datenpfade zwischen 2 verschiedene
Clocksignalen von der selben PLL eine Zeit vorgibt, erreicht man nix, da
man entweder einen Fehler bekommt oder eine Warning, das dieses timing
constraint sinnlos ist und verworfen wird.
Meine nicht sehr saubere, jedoch erfolgreiche Strategie war einfach, bei
der Synthese auf Fläche zu optimieren.
Habe da bitte keine Angst, wenn Quartus meint, dass das Design um 10% zu
langsam ist, es wird trotzdem (besser als mit optimize on speed) gehen!
Bei der Größe des Gesamtdesigns ist generell von "optimize on speed"
abzuraten!
Alexander
Danke für den Tipp mit Optimierung auf Fläche. Andi probiert damit
gerade herum und meint auch, es sei besser, wenn auch noch nicht gut.
Aber irgendwie fehlt hier doch was. Man muß doch in der Lage sein, das
Design so auszulegen daß es nachvollziehbar und ohne Glück funktioniert.
Die Pfade zwischen verschiedenen Takten, die als "false path" definiert
sind, können für die Funktion doch nicht kritisch sein? Da wird ein
Signal früher oder später erwischt, aber Hauptsache überhaupt. Damit
könnte ich mir vielleicht noch die Capture-Probleme erklären, aber nicht
das die CPU gar nicht losläuft.
Mal noch was anderes, erfreulicheres:
Auf den Screenshots kommt nicht so recht rüber, wie die hohe
Darstellungsgeschwindigkeit dem optischen Eindruck hilft. Das erhöht die
"gefühlte Auflösung" nämlich, macht es analoger. Wenn ich das Bild
stoppe sieht es enttäuschend pixelig aus.
Jörg
Hi,
hab eben auch mal Osoz mit dem neuen FPGA Design getestet. Ich finde das
sehr geil! Sowohl die Geschwindigkeit als auch die Reaktion auf Eingaben
ist schon Wahnsinn. Daher auch von mir vielen dank für die ganze Arbeit!
Gruß
Torsten
Ich habe mit Optimierung auf Fläche nun auch unter Quartus 9 eine
lauffähige 4-Kanalversion hinbekommen. Hier für alle zum Ausprobieren,
Anleitung siehe Readme-Files da drinnen. Ganz grob, wie gehabt: erst
noch mit dem originalen FPGA die beiliegende Osoz-Software flashen, dann
das FPGA neu laden.
Das geht nun auch permanent. 2Kanal-User müssen das nicht, können auch
flüchtig das .sof laden, 4Kanal-User müssen das Konfig-Flash brennen,
denn das ist der einzige Weg ins zweite FPGA.
Wenn man wieder Heimweh kriegt spielt man das vorher erstellte Backup
zurück. Bis dahin kann man den sehr schnellen Start beim Einschalten
genießen.
So ganz stabil scheint mir das noch nicht, nach ein paar Stunden ist die
Software in eine Assertion gestürzt und auch das Capturing bleibt gerne
hängen. Vielleicht hilft es in Zukunft, die SFRs der Capture-Hardware
mit 125 MHz zu betreiben, falls möglich.
Die eine Timing-Violation die die Synthese gemeldet hat betrifft die
Write-Leitung des SRAMs, könnte die Ursache für die Software-Assertion
sein. Das ist eh ein Puls aus eigenem PLL-Takt, den könnte ich
nachtrimmen. Muß ich mal mit einem "echten" Oszilloskop nachmessen, wie
der wirklich liegt.
So long,
Jörg
Hi,
sehr fein, werde ich gleich ausprobieren!
Eine Frage hab ich aber noch:
Wie kann ich im Quartus Programmer das orginal Configflash sichern?
Hab da leider nix gefunden, warscheinlich bin ich aber nur Blind...
Gruß
Torsten
Wenn Interesse besteht, kann ich mal eine bebilderte Quartus-Programmer
Anleitung vom Backup und dem wieder aufspielen in das EPCS16-Device
schreiben.
@wirehead
EPC235 anklicken(muß blau hinterlegt sein)
--> rechte Maustaste
--> Attache Flash Device
--> EPCS16 Haken setzen --> OK
--> Examine Haken setzen (sonst keinen anderen Haken setzen!!!)
--> Start drücken und die Massage-Box beachten.
Speichern, "Namen.jic" vergeben, das File muß 2049KB groß sein.
@Jörn
Was hat es denn mit "Test Linearity" auf sich?
Wenn ich das durchlaufen lasse, habe ich später ein mächtiges Rauschen
auf den Kanälen ülus ein Rechteckflattern, ohne das ein Signal anliegt!
Gruß Michael
Hi,
danke für die Anleitung!
Ich hab auch ein Rauschen zu verzeichnen bei 1GS/s und 10mV/div macht
das Spitze Spitze 2div, Trigger auf Normal, je nach Triggerlevel, sieht
nach einem periodischen Burst aus. Bei kurzgeschlossenen Eingängen.
Gruß
Torsten
Und Jörg vermutlich ;-)...
Ich werde mir die Sachen mal morgen in einer ruhigen Minute reinbrennen.
Dann mache ich auch auch gleich mal ein paar Messungen und Tests bei
höheren Frequenzen.
Meine Hardware-Aktivitäten stocken leider etwas weil meine "tolle"
China-Lötstation das Zeitliche gesegnet hat, Ersatz ist aber schon
bestellt.
Gruß Hayo
und bitte, hat das so geklappt mit dem Quickguide?
Ich selber habe mal die "2channel.jic" in das FPGA gebrannt, bleibt ja
dann permanent im Kasten.
Danach mit Quartus das vorher erstellte Backup wieder eingespielt, geht
wunderbar!
natürlich Jörg! Also Sowas...
Gruß Michael
Hayo W. schrieb:> Ersatz ist aber schon> bestellt.
Oh, leider zu spät. Sonst hätte ich gesagt: tu dir den Gefallen
und nimm eine JBC. Ich habe auch beide hier zum Vergleich.:-)
Grüße, Guido
Kurz zu den Fragen:
Schließt mal ein serielles Terminal an, dann wird einiges klarer.
Der Lineritätstest erzeugt dort jede Menge Output. Er sucht für jeden
ADC-Wert die Offsetspannung, um ihn trotz Null Input zu erreichen. Der
Offset-DAC löst feiner auf, ich vermesse mit ihm sozusagen die ADCs.
Nach der Messung sollte eigentlich alles wieder zurückgestellt werden,
wenn nicht ist da ein Bug.
Einen Screenshot löst man mit dem Befehl "screenshot" auf der Konsole
aus. Dann kriegt man komprimierten Binäroutput erwidert, aber als ASCII
in base64. Ein komfortables PC-Gegenstück steht noch aus, fühlt sich
jemand berufen? Im svn ist Sourcecode für ein Kommandozeilentool, was
den Output dekomprimiert und ein .bmp draus macht, was man dann
sinnvollerweise noch in ein .png wandelt. So habe ich das derzeit
betrieben...
Jörg
Hi,
also zuerstmal, die Anleitung mit dem Config-Flash auslesen
funktioniert, allerdings muss beim ersten auslesen nach dem einschalten
zuerst der Flashloader in den EP2C35. Das heist es muss beim EPCS16 ein
Haken bei "Examine" sein und beim EP2C35 ein Haken bei
"Programm/Configure".
Damit wird der Flash Loader IP ins FPGA geschoben und danach der
ConfigFlash gelesen.
Wenn man zwischenzeitlich nicht ausschaltet oder eine andere Config läd
braucht man "Programm/Configure" beim zweiten lesen/schreiben auf den
EPCS16 nicht anhaken.
Dann ist mir beim spielen mit Osoz noch aufgefallen das wenn der Trigger
auf Normal steht und man die Eingangsbereiche hoch schaltet nicht mehr
getriggert wird. Soweit iO, das Triggerlevel das vorher auf die
Signalspitze eingestellt war wird nun nichtmehr erreicht.
Wenn man nun zurück schaltet auf den vorherigen Spannungsbereich muss
man das Triggerlevel erst wieder ein gutes Stück zur Mitte zurückdrehen
bis wieder getriggert wird.
Hardware oder Software Problem?
Der von mir weiter ob(
Beitrag "Re: made from scratch Firmware für Wittig/Welec Oszilloskop W20xxA" ) beschriebene Burst
tritt periodisch auf, dies sieh man sehr schön im Delayed Modus be 1GS/s
und 10mV.
Dann gibt es einen (bei mir) reproduzierbaren Absturz mit Flackern und
totalem Schrott auf dem Schirm (schrott wiederhohlt sich Vertikal 3mal),
das Bild hat dann nichts mehr vom normalen Screen. Das Flackern reagiert
nicht auf Eingaben. Alle ca. 200 Frames sieht man das Grid für höchsten
einen Frame aufblitzen. Aber zu weit unten.
Geht bei mir folgendermaßen:
Oszi einschalten beide Ch auf 10mV/div TB auf 1GS/s, Delayed Mode an,
Trigger auf Auto, CH2 abschalten, CH1 abschalten, CH2 wieder
einschalten, 2sec warten (Signal ist eingefrohren), die show beginnt.
Manschmal kehr der normale Screen kurz zurück um dann nach ein paar sec
wild hin und her zu springen. Signal ist dann immer noch gefrohren,
keine Reaktion auf Benutzereingaben.
Funktioniert ab und zu auch ohne ohne vorher Delayed einzuschalten.
Oszi war zu dem Zeitpunkt ca. 10-15min eingeschaltet.
Ich hoffe das hilft weiter.
Gruß
Torsten
Hallo Torsten,
was Du in Deinem Eintrag beschrieben hast, steht soweit in dem genannten
Wiki.
Zu Deinem beschriebenen Problem:
wirehead schrieb:> Geht bei mir folgendermaßen:> Oszi einschalten beide Ch auf 10mV/div TB auf 1GS/s, Delayed Mode an,> Trigger auf Auto, CH2 abschalten, CH1 abschalten, CH2 wieder> einschalten, 2sec warten (Signal ist eingefrohren), die show beginnt.> Manschmal kehr der normale Screen kurz zurück um dann nach ein paar sec> wild hin und her zu springen. Signal ist dann immer noch gefrohren,> keine Reaktion auf Benutzereingaben.
Ich habe es versucht nachzustellen. Leider konnte ich diesen
beschriebenen Absturz nicht nachstellen. Ich nutze derzeit die 4
Kanalversion fest aus dem EPCS16.
Bei den gemeinsamen Versuchen mit Jörg sind noch so einige bestehende
Hürden für den FPGA aufgefallen. Aus diesem Grund ist das immer noch ein
Alpha-Status! Also bitte nicht wundern wenn die Software auch noch nicht
rund läuft ...
Bei den gemeinsamen Versuchen zur Erstellung des *.JIC-Files haben wir
immer unterschiedliche Syntheseergebnisse. Die Folge ist ein mal
laufendes und mal nicht laufendes Grundsystem für den FPGA.
Aber ich kann Dich beruhigen ... die Show wird weiter gehen ;-)
Grüße Andi
Hi,
ich hab vergessen dazuzuschreiben das ich ein W2022A verwendet habe.
Ich könnte mir auch vorstellen das das durch Streuung der Hardware auf
anderen Geräten nicht auftritt.
Gruß
Torsten
Servus,
ich hab heute auch mal den Alpha Release auf meinem W2024 (im
Originalzustand) getestet. Das Gerät ist, was die Performance angeht, ja
nicht wieder zu erkennen. An dieser Stelle möchte ich dann auch mal
meinen Respekt und ein großes Dankeschön an das gesamte Entwicklerteam
zum Ausdruck bringen. Es ist echt bemerkenswert wie viel Freizeit, Mühe
und Herzblut Ihr in dieses Projekt steckt!
Eine Frage hätt ich da mal noch. Ich wollte mir das Design im Quartus
ansehen (Version 9.0). Ich hab also einen kompletten SVN Checkout
gemacht. Den Versuch das Projekt mittels "W2000Nios2.qpf" zu öffnen
qittiert Quartus nur mit 2 Fehlermeldungen.
Error: Error reading Quartus II Settings File
C:/niosII/altera/master.qsf, line 585
Info: set_global_assignment -name SOPC_FILE master.sopc
Error: Tcl Script File master.qip not found
Info: set_global_assignment -name QIP_FILE master.qip
Gibt es da noch irgend etwas zu beachten?
MfG Oliver
Die ist vorhanden.
Bei einem anderen Projekt funktioniert es auch.
Hier scheint er die master.sopc nicht zu finden.
Kommentiert man die beiden Zeilen in der master.qsf aus, öffnet Quartus
zumindest schon mal das Projekt. Dann kann man den SOPC Builder starten
und die master.sopc Datei manuell auswählen. Dort meckert er dann aber
an, dass er die welec eigenen IP-Komponenten nicht findet. Auch wenn man
den IP-Suchpfad hinzufügt findet er diese nicht. Es ist fast so als
hätter er ein Problem mit den Pfaden. Bei den derzeitigen Pfadnamen
sollte das aber nicht der Fall sein?!?
Oliver hat Recht. Zum Öffnen des Projektes wird Nios II Lizenz noch
nicht berücksichtigt.
Welche Version von Quartus nutzt Du? Wir verwenden für die Tests die
Version V 11.0 (Web-Edition) und für die Alphaversionen die V9 mit Nios
II Lizenz und können die Quellen öffnen.
Du schreibst das Du eine Nios-Lizenz hast! Für weche Quartusversion
denn?
Grüße Andiiiy
Oliver,
Bleib dran, auch ich mußte seinerzeit an den Files etwas rumschrauben,
bis es auf 9.1 funktionierte. Ich vermute, bis runter auf 9.0 ist es
nicht weit. Im "schlimmsten Fall" könnte man die Projektfiles neu
aufsetzen.
Jemand zweites mit Zugang zu einer Nios-Lizenz wäre cool, ich lege da
weißgott keinen Wert auf ein Monopol, sondern betrachte das eher als
Pferdefuß. Aber noch mal für alle zur Klarheit: Jeder kann das Design
übersetzen und testen, aber ohne Lizenz kommt keine permanent brennbare
Version dabei raus, sondern eine Eva-Version. Nur die kleinste Variante
des Nios II ist lizenzfrei, aber leider auch 7 mal langsamer als die
schnellste (die wir verwenden).
Jörg
Hallo Jörg,
danke für die Info. Es hat sich aber mittlerweile erledigt. Ich habe im
Skype Chat was dazu geschrieben. Das ist aber wohl noch nicht angekommen
weil wir noch nicht gleichzeitig online waren. Hab den Skype Rechner
erst morgen wieder an.
Grüße Oliver
Hallo,
ich habe Zugriff auf eine Nios Lizenz, gültig glaube bis 11.0 (kann am
Montag nachschauen).
Eigentlich sollte es doch auch möglich sein einen Build-Server
aufzusetzen der jede Stunde ein SVN-Update macht, Synthetisiert und das
Ergebnis hoch lädt.
Würde das weiterhelfen das Versionschaos zu reduzieren?
Hallo,
ich bin aus dem Urlaub wieder da, deshalb war ich in letzter Zeit so
passiv.
@student: Einen Build Server fände ich im Moment etwas übertrieben, aber
valide Lizenz kann generell nicht schaden. Als Gast kann ich dich nicht
kontaktieren, schick mir mal eine PM oder so.
Das mit den automatischen Builds hätte im Moment den Nachteil, das man
das Ergebnis noch bewerten muß. Öfters kriegt er das Timing nicht hin,
weil er sich wohl mit dem Layout verrannt hat, manchmal läuft das
Resultat aus unbekannter Ursache trotz gutem Timing nicht.
Jörg
Nach dem Urlaub brauche ich "immer" ein Weilchen, bis ich wieder
reinkomme.
So auch diesmal. Langsam geht's wieder weiter, wie
svn-Mailinglistenabonnenten schon wissen.
Zum einen bereite ich (vorerst gedanklich) die Erweiterung des Frontends
auf 9 Bit vor. Nicht weil die ADCs auf einmal besser werden, sondern
weil spätere Offset- oder Kennlinienkorrektur dann etwas höher auflösen
können, auf ein halbes ADC-Digit genau. Die Memory-Blöcke des FPGA haben
auch 9 Bit, wenn wir daraus Korrekturtabellen bauen paßt das ganz gut.
Zum anderen habe ich mir die Busstruktur nochmal vorgenommen. Ich habe
gelernt, das man für den Anschluß von Busteilnehmern mit langsamerem
Takt nicht zwingend eine "Clock Crossing Bridge" braucht, die ich da
bisher drinnen hatte und deren FIFOs uns 3 Memoryblöcke kosten. Man kann
das auch "einfach so" anschließen, der SOPC Builder erzeugt dann eine
Registerlogik für den Übergang. Der Vorteil der Bridge ist, das sie auf
der langsamen Seite wieder Pipelining draus machen kann, bei
aufeinanderfolgenden Zugriffen auf Speicher (Cache-Refills) ist das
vorteilhaft. Wenn dahinter nur I/O Register liegen bringt das aber nix.
Bisher hatten wir nur das SRAM und JTAG vorne am Prozessorbus, alles
andere langsamer hinter der Bridge. Vorne ist alles kritisch, deshalb
kostet uns JTAG Performance. Ich hatte sogar mal erwogen, eine
schnellere "Release Version" ohne JTAG zu bauen, vs. eine "Developer
Version" mit. Nun habe ich außerdem gelernt, das JTAG gar nicht
unbedingt da vorne dran sein muß, allerdings den vollen Takt braucht.
Jetzt habe ich das ganz anders gebaut, mit zwei einfachen Bridges. Vorn
nur Prozessor und SRAM, hinter der ersten Bridge ist noch voller Takt,
da ist JTAG und alles Speicherartige dran angeschlossen: Flash, Boot
ROM, Capture-Speicher. Dann die zweite Bridge mit langsamem Takt, da
sind alle I/Os hinter.
Hat den Vorteil, das nun alle Speicher (fast, bis auf eine Takt hin und
her für die Bridge) so schnell wie möglich sind und JTAG keine Strafe
mehr ist. Das Auslesen der Capture-Daten aus dem ersten FPGA geht nun
mehr als doppelt so schnell. Bisher kostete ein Zugriff auf nicht-SRAM
Speicher etliche Takte hin und zurück für die Taktsynchronisation. Die
gesparten 3 Memoryblöcke können wir gut gebrauchen. Im Slave-FPGA habe
ich ebenfalls die Clock Crossing Bridge weggespart, auch mit Blick auf
den Logic Analyzer.
So long,
Jörg
Schön zu hören, dass Du wieder voran kommst. Ich selbst komme leider
momentan nicht dazu mich um unser Projekt zu kümmern. Die Doku zur OP653
Mod liegt noch halbfertig rum. Bei diesem Wetter gibt es halt Sachen die
vorgehen. Aber es geht sicher auch bei mir bald wieder weiter.
Bin gespannt was da bei Dir so rauskommt. Inzwischen sind ja schon
etliche gute Ideen und Verbesserungen eingeflossen.
Gruß Hayo
Ich hatte in der Vergangenheit schon mal SOPC Builder versus Qsys
getestet. Für nicht so Eingeweihte: das ist das Tooling, mit dem man
sich unter Altera Quartus das Prozessorsystem und die Peripherie
zusammenklicken kann.
Bisher hatte ich keinen spürbaren Unterschied bemerkt und bin beim SOPC
Builder geblieben. Nun habe ich gemerkt das ich das grandios falsch
gemacht habe: Qsys erzeugt seine Produkte in einem anderen Verzeichnis,
man muß sein Projekt schon drauf umändern. Ich hatte also nur zwei
SOPC-Kompilate verglichen... (wie peinlich)
Nun habe ich das bemerkt und das umgebogen. Die Kompilierung schlägt
erst mal fehl, verhaspelt sich mit Benennungen in Alex' Code, wegen oder
trotz "library" und "use" am Anfang der Files findet er den restlichen
Code nicht. Meine VHDL-Kenntnisse reichen nicht, um das gängig zu
machen. Ich habe als Workaround alle seine Dateien direkt ins Projekt
hinzugefügt, indirekt über das erzeugte .qip klappt es nicht wie sonst.
Das Syntheseergebnis sieht besser aus als mit SOPC. Wir könnten den
Nios-Teil vermutlich eine Stufe schneller laufen lassen, mit 83,33 MHz
statt 75 MHz.
Die schlechte Nachricht ist, das die Karre bisher noch nicht recht
läuft. Das Display bleibt dunkel, die Software hängt sich früh auf, beim
Anmelden des ersten Interrupts. Der Speichertest hingegen geht.
Nun bin ich dabei, statt dem automatisch konvertierten Gesamtsystem ein
neues von Grund auf mit Qsys aufzubauen und abschnittsweise zu testen.
Das Problem beim LCD habe ich bereits gefunden, der Busmaster muß in
einer bestimmten Situation toleranter sein.
Unabhängig davon habe ich die Idee, den Capture-Speicher als sog.
"tightly coupled memory" (TCM) an die CPU anzubinden. Man kann der CPU
einen Extra-Port rankonfigurieren, für exklusiven Zugriff auf schnellen
Speicher, statt dafür über den normalen Bus gehen zu müssen. Dann kann
die CPU darauf maximal schnell zugreifen, genau so schnell wie auf den
Cache.
Mit dem SPOC Builder klappt der Zusammenbau nicht, sollte aber, ich
vermute einen Bug. Bei QSys geht es, aber bisher lese ich nur Nullen
aus.
Alles in allem, Qsys ist ein recht interessantes Thema. Es gibt neue
Möglichkeiten für geteilten Zugriff auf Pins, wie wir es für SRAM vs.
zweites FPGA brauchen. Auch kann man wohl den Bus "tunneln", wie ich es
zum zweiten FPGA getan habe. Ich vermute aber, das diese generischen
Methoden nicht so effizient sind wie unsere maßgeschneiderte Lösung.
Aber man hätte vielleicht einfacher dahin kommen können.
Jörg
Zu lange ruhig hier.
Qsys ist wirklich gut, den Prozessor kriege ich deutlich schneller, wohl
2 Stufen (94 MHz) statt nur einer (83 MHz). Im "leeren" FPGA (ohne
Capture) läuft er mit sogar 106 MHz, da habe ich zuvor nur 94 MHz
hingekriegt. Für das Gesamtsystem erscheint 94 MHz also machbar. Das ist
auch die Maximalfrequenz, die ich zwischen den FPGAs hinbekommen habe.
Leider fliegt mir das SRAM-Interface bei >75 MHz um die Ohren. Das ist
merkwürdig, denn seit der Umstellung auf Registerausgänge und Benutzung
der Register direkt in den Padzellen war das bisher total stabil, ich
hatte es damals testweise sogar bis 125 MHz (LCD lesend, ohne Nios)
geprügelt.
In dem Thema habe ich ich mich ziemlich verzettelt, viel erfolglos
herumprobiert. Ich kriege zwar einen stabilen Betrieb hin, aber die PLL
für den Lesezeitpunkt muß dermaßen genau eingestellt sein, daß das beim
nächsten Gerät bestimmt nicht mehr klappt.
Ein Problem habe ich gefunden: Den zwischen SRAM und FPGA2 gemeinsamen
Datenbus brauchen wir zu zwei verschiedenen Zeiten eingetaktet, für SRAM
zu einem bestimmten krummen Zeitpunkt, für FPGA2 zum normalen Takt. Die
Padzelle hat aber nur ein Flipflop. Da braucht es noch ein zweites
Flipflop, und das hat das Layout sonstwohin gelegt. Man kann die
Position auch erzwingen, aber direkt neben das Pad gesetzt klappte auch
nicht besser.
Mittlerweile verfolge ich die Ergebnisse der Synthese auf dem Chip. Es
scheint, da gerät was durcheinander. Die Signale werden bunt gemischt an
mal das eine, mal das andere Flipflop angeschlossen, es wird nicht
berücksichtigt daß das verschiedene Takte sind. Ich habe verschiedene
Quartus-Versionen und Fitter Settings ausprobiert, immer dasselbe. Sieht
aus wie ein Bug, keine Ahnung wie er dazu kommt, aber meist befindet
sich das Problem ja zwischen Monitor und Stuhllehne...
Wenn ich den FPGA2-Anschluß ausbaue, nur noch ein Takt gilt, wird es
komischerweise noch schlimmer, von daher will ich nicht behaupten das
fundiert im Griff zu haben.
Heute hatte ich noch eine neue Idee: Ich könnte es mal mit DDR-Eingängen
und einem asymmetrischen Takt versuchen, dessen steigende und fallende
Flanke die beiden Abtastzeitpunkte darstellen. Dann muß doch hoffentlich
jedes Signal seinen eigenen Weg gehen.
Jörg
Wieder was gelernt:
Das FPGA hat an den Pins einstellbare Verzögerungszeiten. Standardmäßig
wird bei Eingängen dort die maximale Verzögerung eingestellt, etwa 5 ns,
warum auch immer. Für Speicherinterface oder FPGA-Verbindung versuche
ich ja gerade, die Latenz klein zu kriegen, damit möglichst viel pro
Takt passiert.
Wenn ich das stattdessen auf Minimum konfiguriere, dann funktioniert die
FPGA-Verbindung auch noch bei höheren Frequenzen. Zuvor war da bei 94
MHz Schluß, nun geht es auch noch mit mindestens 125 MHz. Da habe ich
aufgehört zu testen, denn der Rest kommt da eh nicht hin. Diese
Verbindung ist kein Flaschenhals, wie ich vorher dachte.
Und noch was gelernt: Es macht großen Unterschied, welche Pins man
verwendet, ob die günstig beisammen liegen. Ich dachte ja, das wegen
FPGA2 komplexer gewordene Businterface ist am Limit, aber das lag an
ungünstig gewählter Pinbelegung, die Logik ist nichts dagegen. Ein paar
mit dem SRAM-Interface verwandte Signale mußten einmal quer über den
Chip.
Nun habe ich die anders verteilt. Die Pins an der Oberkante wo das SRAM
angeschlossen ist sind allerdings knapp. Die Leitung für den Test-Taster
mußte mit ran, denn die geht auch an beide FPGAs und liegt oben. Den
Taster in Zukunft nicht mehr drücken... Geht nix kaputt, aber würde den
4kanal-Betrieb stören. Eine weitere Leitung (das Wait-Signal) kommt
notgedrungen doch von unten, aber da habe ich ein Zwischenregister
eingebaut, sie ist nicht zeitkritisch. So kann das Layout sich irgendwo
eine Insel als Zwischenstopp bauen.
Nun ist auch hier kein Flaschenhals mehr.
Momentan experimentiere ich mit 100 MHz für CPU und SRAM. Mit den neuen
Maßnamen geht das fast gut, über einen recht weiten Bereich, aber ein
böses Datenbit (die 22) hängt gerne mal auf Null. Mein Bastelgerät
scheint besonders anspruchsvoll zu sein. Auch mein Zweitgerät zeigt
diesen Effekt, wenn auch weniger ausgeprägt. Für das und die Platine von
Guido geht es eigentlich zuverlässig, ein Speichertest lief stundenlang
ohne Fehler.
Ich vermute Leitungsreflektionen, habe auch schon mit der Treiberstärke
experimentiert. Kann ich natürlich nur an der FPGA-Seite einstellen, das
SRAM macht sein Ding.
Ohne die Signale zu messen tappe ich einigermaßen im Dunkeln, kann nur
die Bitfehler beobachten. Ich müßte also mal meinen Aufbau incl. PC in
die Firma schleppen, um das an einem "richtigen" Oszi zu messen...
Den Speichertest poste ich mal. Das ist nur ein .sof, keine weitere
Software nötig, temporär reinladen reicht. Blinkt entweder friedlich vor
sich hin, oder macht bei Fehlern alle Lampen an.
So long,
Jörg
Hat der verwendete FPGA eventuell on-chip Termination? Das dann auf
jeden fall mal ausprobieren. Das reduziert die Reflektionen auf der
Leitung.
Michael
Michael schrieb:> Hat der verwendete FPGA eventuell on-chip Termination? Das dann auf> jeden fall mal ausprobieren. Das reduziert die Reflektionen auf der> Leitung.
Ja, hat er, aber nur in Senderichtung. Davon habe ich auch teils
Gebrauch gemacht, für die Steuersignale.
Da kann man 25 Ohm Längswiderstand konfigurieren, aber ich vermute in
Wirklichkeit wird die Treiberstärke entsprechend verringert, was wohl
aufs Gleiche rausläuft. Man kann auch direkt die Stärke wählen.
In Empfangsrichtung sind wir wohl dem Signal vom SRAM ausgeliefert,
müssen warten bis es ausgeklingelt hat, oder finden einen günstigen
Punkt. So scheint es mir im Moment zu sein, denn in beide zeitliche
Richtungen (früher/später) verstärkt sich die Tendenz zu der hängenden
Null auf D22.
Ohne Messung ist das aber alles Spekulation, und selbst mit muß es nicht
aufschlußreicher werden...
Es gibt noch ein FPGA-Feature namens Bus Hold, da wird der Bus wenn er
Eingang ist nicht einfach hochohmig, sondern mit ca. 7 kOhm schwachem
Treiber auf dem letzten Zustand gehalten. Das habe ich probiert, mir
einen gewissen Terminierungseffekt erhofft, aber keine Verbesserung, es
ist wohl zu schwach.
Jörg
Uff, ich bin jetzt endlich drauf gekommen, was an meinem
SRAM-Interface schief läuft, das es bei höheren Frequenzen so
überproportional schlecht funktioniert:
Ich betreibe die Steuersignale zu kurz, der Ausgang wird schon wieder
hochohmig wenn der Zeitpunkt für die Datenübername gekommen ist.
Ich bin drauf gekommen, weil die Fehler stets das letzte Wort einer
Cacheline betrafen, die nahtlos zuvor gelesenen Daten waren intakt.
Die Daten brauchen ca. 18 ns ab unserem Anlegen von Adresse und
Steuerung bis ich sie als Ergebnis übernehmen kann. (8ns für das RAM
selbst, den Rest wohl für FPGA+Platine raus und wieder rein.) Bei 75 MHz
sind das 1,35 Takte, die Steuersignale liegen nur im ersten Takt an. Die
restlichen 0,35 Takte (=4,7 ns) sind "freihändig", da beginnt bei
aufeinanderfolgenden Zugriffen schon überlappend der nächste, das RAM
ist mit der Rückrichtung beschäftigt und merkt noch nichts.
Bei 100 MHz sind es aber 1,8 Takte, also 0,8 Takte oder 8 ns Blindflug
gegen Ende. Das ist offensichtlich zuviel, da schaltet das RAM schon
wieder aus.
Nun steuere ich die Read- und Chipselect-Signale etwas länger aktiv, für
den Bruchteil eines Taktes. (Wieder mal mit einem DDR-Ausgang, meine
Universallösung für's Feintuning). Nicht den ganzen Takt lang, weil ich
einem evtl. drauffolgenden Schreibzugriff noch Zeit für den
Richtungswechsel geben will. Mal schauen ob das klappt, den Part habe
ich noch nicht getestet.
Der Speichertest läuft jetzt prima auch auf meiner "Problemplattform",
ich habe die anderen Tweaks an Längswiderständen etc. ausbauen können.
Auch das deutet drauf hin, jetzt die echte Ursache gefunden zu haben,
ohne fette Meßtechnik aufzufahren.
Am Wochenende habe ich die Praxistauglichkeit von 100 MHz für das
komplette Design erprobt. Die Synthese hat auch für das Ganze das Timing
durchhalten können. Ich kann sogar noch die FPU dazunehmen, immer noch
100 MHz. (Braucht 5% der FPGA-Gatter extra.) Lediglich bei meinen Custom
Instructions muß ich nacharbeiten. Die sind zu komplex für einen Takt,
müßte ich auf 2 aufteilen.
Tja, und die allgemeine Wieder-Inbetriebname des nun Qsys-Systems steht
noch aus.
Das SRAM hat mich jetzt ein paar Wochen beschäftigt, bin froh das das
hoffentlich durch ist. Gibt ja wichtigeres...
Wir können aber sehr froh sein, das Welec ein so schnelles SRAM verbaut
hat. (Die Dinger sind teuer.) Sie selbst haben das überhaupt nicht
ausgereizt.
Jörg
Zum Wochenende was zum Mitmachen:
Hier ist der "versprochene" Speichertester. Ist nützlich für gleich
mehrere Dinge, sollte man im Hause haben:
1. Ihr könnt damit das SRAM testen, z.B. weil es unter Verdacht steht,
schlecht gelötet ist, etc.
2. Ich hätte gerne einen Feldtest, ob meine aktuelle RAM-Ansteuerung
stabil bei allen funktioniert.
3. Wir üben nochmal, wie man das FPGA lädt. ;-) Steht schon anderswo,
eine Beschreibung spare ich mir an dieser Stelle.
Das ist ein "autarkes" .sof File, enthält statt dem normalen Bootloader
nun einen Speichertest. Es reicht aus es flüchtig in das FPGA zu laden.
Man muß nix brennen, keine Software extra. Nach Wiedereinschalten ist
alles wie vorher.
Was ist drin, was tut es:
Das ist ein abgespecktes FPGA-Design mit nur dem Nötigsten, plus
LCD-Controller für parallele Zusatzlast auf dem Bus. Der Speichertest
läuft im Boot-ROM und hält alle Variablen in Prozessorregistern, kann
deshalb das ganze SRAM mit Testpattern vollschreiben.
Es wird zyklisch das RAM mit Pseudozufallszahlen vollgeschrieben, dann
ausgelesen und die Folge mit gleichem Seed überprüft. Dann geht es mit
neuem Seed weiter. Ein Durchlauf (Schreiben und Lesen) dauert 0,15
Sekunden (!), in dem Takt blinkt die Run/Stop-LED. Wenn ein Fehler
erkannt wurde leuchten oder blinken alle LEDs. Auf der seriellen
Schnittstelle gibt es zusätzlich eine Ausgabe der Fehler und einen
Rundenzähler, wen's genauer interessiert.
Nach dem .sof Reinladen ist das LCD schwarz, es kriegt merkwürdigerweise
den Reset nicht mit. Man kann F1+F2 gleichzeitig drücken um es zur Räson
zu bringen (manueller Reset). Dann sieht man auch schön das
Vollschreiben mit den Zufallsmustern.
Ich hoffe auf rege Beteiligung! Den Test einfach laufenlassen, nach ein
paar Stunden nochmal schauen das hoffentlich nur die eine LED brav
blinkt.
Wenn Fehler auftreten kann ich noch ein paar Varianten mit anderem
Timing veröffentlichen. Dies hier ist aber mein Favorit, funktionierte
auf allen 3 Geräten und scheint etwas Luft zu haben.
Jörg
Hallo Jörg,
schön das es was zu testen gibt, es ist absolut spannend zu sehen wie du
dich da durchackerst!
Der Speichertest läuft bei mir auf einem W2022a seit 15min stabil, d.h.
run_stop blinkt schön vor sich hin.
Gruß Jochen
Hallo,
Jochen R. schrieb:> Der Speichertest läuft bei mir auf einem W2022a seit 15min stabil, d.h.> run_stop blinkt schön vor sich hin.
... jetzt nach über sieben Stunden noch immer keine Fehler, sehr gut.
Soll ich den Test noch ein paar std laufen lassen?
Wie sieht es bei den anderen Testern aus?
..sehr spannend das alles, besonders die nächste Beta?
Gruß Jochen
Moin,
bei mir läuft der Test auf einem W2024 sei ca. einer Stunde Problemlos.
Bin auch schon sehr gespannt wie es weiter geht. Sieht ja alles schon
super aus.
Gruß
Dirk
Dirk B. schrieb:> bei mir läuft der Test auf einem W2024
Super, schon ein W2024...
u. man kann aufhören die ram´s nachzulöten, sehr beruhigend, toll!
-
Vielen Dank schon mal zwischendurch. Nach Stunden kann man den Test wohl
abbrechen, dann sollte Betriebstemperatur erreicht sein. Wohlmöglich
kommt irgendwann doch noch ein Alphateilchen daher und verhagelt die
Bilanz...
Wichtiger fände ich viele Geräte, wegen Exemplarsteuung. Meine beiden
W2024 sind z.B. schon ziemlich unterschiedlich, Guidos W2022-Platine ist
unkritischer.
Jörg
W2022A: ca 3 Stunden fehlerfrei, Run 0x00010000, Error 0x00000000.
(optisch sind meine SRAMs sehr gut verlötet)
Wär's nicht besser, den Speichertest in einen eigenen
Thread auszulagern?
Thread beobachten
Seitenaufteilung abschalten