Hallo, ich mache für mein "coming out" mal einen neuen Thread auf, in Abgrenzung zu der "klassischen" Thread-Serie Beitrag "Wittig(welec) DSO W20xxA Open Source Firmware (Teil5)" Das Welec-Oszi hat ja so eine Art Softwarekrise. Die vom Hersteller offengelegte Firmware spottet vom inneren Aufbau her jeder Beschreibung, außer unserem hartgesottenen Hayo mag sich da niemand drin umtun, die Open-Source Entwicklung ist außer seinem Zweig praktisch zum Erliegen gekommen. Ich würde das Ding als nicht wartbar bezeichnen. Die Hardware, das Nios FPGA-Design des Herstellers, hat auch etliche Macken, nur leider liegen dafür die Quellen nicht offen. Mit dem Leon-Design für das FPGA gibt es einen vielversprechenden Neuansatz, der damit aufräumen könnte. Die Softwareentwicklung dafür hat nicht recht angezogen. Für meinen Teil liegt es daran, daß das Leon-Design Stand heute nur 2 Kanäle unterstützt. Der Autor (Alex) kann ferner im Moment leider keinen Support dafür leisten. Nun der Ansatz: Ich möchte die Keimzelle für eine neue Software legen, die sowohl das Nios-Design wie auch das Leon-Design unterstützt. Sie soll "ordentlich" aufgebaut sein und auch portabel, ggf. vielleicht auch auf andere Oszilloskope wie Owon etc. Mit der Idee gehe ich schon länger schwanger, habe bei meinem Besuch bei Hayo ausgiebig mit ihm drüber gesprochen. Sein Commitment dabei mitzumachen ist mir sehr wichtig. Dies soll keine Absplitterung werden, sondern der neue Mainstream. Die jetzige Nios-Firmware soll nur noch soweit wie nötig gepflegt werden, bis Applikationsentwicklung mit der neuen Architektur möglich ist. Die eigentliche Energie soll in den Neuansatz fließen. Ich hoffe, auch andere Alt- und Neuentwickler dafür begeistern zu können. Nun habe ich tatsächlich angefangen und vorgelegt. Im Sourceforge-Wiki habe ich zunächst eine Seite eingerichtet, die die Architektur umreißt und die Designs gegenüberstellt: https://sourceforge.net/apps/trac/welecw2000a/wiki/FWreloaded Kenner der jeweiligen Designs mögen das bitte gern vervollständigen! Ich aktualisiere die Seit derzeit häufig mit meinen High-Level-Ergebnissen. Im "praktischen Teil" habe ich losgelegt, das System zunächst für Nios von unten neu aufzubauen. Sowas kann ich ganz gut, bin vorbelastet. Es geht schon einiges, ich bin bei der Treiberschicht und schreibe jeweils Testprogrämmchen dafür. Weil die Programme sehr klein sind kann man schnell Dinge ausprobieren, das macht echt Spaß. Ich "erforsche" die Hardware von Grund auf und lerne so auch interessante Features (und Bugs) kennen, die der Software mehr Potential geben. Soll für's erste Posting reichen, nachfolgend beschreibe ich meine Fortschritte und eröffne hoffentlich fruchtbare Diskussionen. Jörg
Weiter geht es, zum praktischen Stand der Dinge, was geht denn schon? Jeden Tag mehr, momentan ist viel Bewegung drin. Zwischen den Jahren habe ich etwas Zeit mich auch um solche Themen wie Build-Flow zu kümmern, da muß noch Grund rein. Wenn der steht werde ich das Ganze bei Sourceforge einchecken und somit veröffentlichen. Momentan habe ich folgendes: Message-Queue: fertig. Quasi das Betriebssystem, die Hauptschleife für eine ereignisgesteuerte Applikation. Aus Hardware-Interrupts oder dem Programmfluß heraus werden Nachrichten geschickt, die das Hauptprogramm in einer Endlosschleife abarbeitet. Das wird so recht elegant. Es soll nirgendwo gepollt werden, so minimiert sich die Latenz. LCD: geht, erste Drawing-Primitives für Rechtecke und Linien existieren. Ich kann in den 16 Planes zeichnen. Textausgabe und eine BitBlit-Funktion fehlen noch. Bei den Experimenten fand ich einige Eigenarten heraus, die erste Plane funktioniert in den ersten und letzten 32 Pixelspalten nicht richtig, das ganze Bild ist um 1 Pixel nach rechts verschoben und der sichtbare Bereich so auf 639 Pixel reduziert, die Mischergebnisse der Planes sind mitunter unerwartet. Drehimpulsgeber: fertig, incl. Beschleunigungsoption. Die schicken ihre Events in die Queue. Eine Sache finde ich unschön: beim schnellen Drehen erfolgen keine Updates, sondern erst wenn's wieder langsamer geht. Hat mich an der Firmware immer gestört. Das ist leider ein Hardware"feature". Intern ist das anscheinend so gelöst, daß die Drehgeber nach Änderungen und einem kurzen Timeout einen Interrupt auslösen. Dreht man schnellen als dieses Timeout, dann gibt es erstmal keine Werte. Ich habe mich um einen Workaround bemüht, die Geber zwischendurch versucht auszulesen, aber vergebens. Die Werte stehen erst mit dem Interrupt an. Tasten: fertig. Tastendrücke landen nach ihrem Interrupt in der Queue. Hier gibt es wenig zu berichten, das funktioniert einfach. Von der Hardware wird nur das Drücken gemeldet, nicht das Loslassen. Mehrere Tasten gleichzeitig sind auch ausgeschlossen. Die noch unbenutzten Eingänge auf der Frontplatine werden wahrscheinlich von der Hardware nicht mit verwendet, die Bitmaske legt die Vermutung nahe. Ist aber noch zu überprüfen. Timer: angefangen. Einen der drei Timer starte ich, kann ihn zum Messen verwenden. Ein Mechanismus zum Beantragen von zeitgesteuerten Events steht noch aus, hauptsächlich weil ich die Anforderungen noch kennenlernen muß. Wie werden die Timer derzeit verwendet? Sonstiges: (Nebenbei finde ich zahllose Dinge, die in der alten Software nicht beachtet wurden. Instabilitäten dort würden mich nicht wundern. In Interruptfunktionen wird viel zuviel gemacht, auf Variablen zugegriffen die im Hauptprogramm nicht gelockt werden. Es gibt generell keinerlei Locking gegen Interrupts zur "Unzeit". Die RAM-Speicherbereiche der Hardware werden dem Code / den Variablen nicht entzogen, das ist alles reine Glückssache.) Ich habe herausgefunden, daß die Nios-CPU mit 12,5 MHz läuft. Hört sich wenig an. Als Plus hat sie aber 256(!) Register, von denen in einem Fenster immer 32 benutzbar sind. Bei Unterprogrammaufrufen wird dieses Fenster weitergedreht. Das macht solche Funktionsaufrufe sehr schnell (zumindest bis irgendwann doch auf den Stack ausgelagert werden muß). Ein brachliegendes Feature der CPU habe ich gestern gefunden: der je nach FPGA-Design optionale Befehl "MSTEP" zur bitweisen Multiplikation ist bei uns vorhanden. Der Compiler weiß davon nichts und erzeugt recht langsamen Code, der "zu Fuß" multipliziert. Das kann man ändern, indem man ihm eine Implementation der Multiplikation unterschiebt, die MSTEP verwendet. Dann wird die auch automatisch überall verwendet. Ist viel schneller, tolle Sache! Der Code läuft generell im SRAM, wird von einem Startup-Code aus dem Flash dorthin kopiert. das SRAM ist 16 bit breit, die Instruktionen des Nios auch, der läuft so anscheinend ungebremst. Wir könnten abweichend vom Altera-Flow den Code auch im (nur 8 bit breiten) Flash laufen lassen und nur die geschwindigkeitskritischen Teile ins RAM kopieren. So können wir zum einen eine größere Applikation schreiben als derzeit möglich, zum anderen möglichst viel vom RAM für "sinnvolle" Dinge wie Capture-Buffer freihalten. Ich habe einen GDB-Stub für den Nios gefunden. Altera liefert den wohl mit, nur bei unserem Code-Vermächtnis war er nicht dabei. Ich habe ihn noch nicht angepaßt und compiliert. Das ist das Target-Gegenstück zum Gnu-Debugger. Damit kann man auf dem Target debuggen, Code downloaden, Breakpoints setzen, durch den Code steppen, Variablen anzeigen lassen und so. Allerdings muß man dafür die serielle Schnittstelle freihaben, die Applikation darf sie dann nicht benutzen. Vielleicht hilft die USB-Schnittstelle. Ich habe rausgefunden, das die Baudrate des zweiten seriellen Interfaces zu selbiger einstellbar ist. Wenn wir unsere Interruptroutinen schön auf Performance gebürstet haben könnte das unsere neue Lieblingsschnittstelle werden. Was man alles so findet, wenn man sich mal von Grund auf mit den Dingen beschäftigt... Jörg
Hallo Jörg, hast du dich für die nächsten Jahre von deiner Frau verabschiedet? ;-) Ich bin mal gespannt wie das verläuft und drücke fest die Daumen. Gruß, Guido
Nun mal zur Zukunft, was ich als nächstes mache, was noch fehlt, worüber ich noch nachdenke, wo ich Hilfe gebrauchen kann. SPI: Wenn die Timer "etabliert" sind werde ich die Schieberegisterketten in Betrieb nehmen, mit denen die Augänge realisiert sind. An solchen hängen die LEDs der Frontplatine, sowie im wesentlichen die Steuerung der Eingangsstufen (alt wie neu). UART: Die seriellen Schnittstellen kriegen noch "ordentliche" Treiber, mit Übertragung per Interrupt. Nur wenn der Sendebuffer voll ist muß eine Schreibfunktion blockieren, ansonsten passiert das im Hintergrund. Empfangen wird auch in einen Puffer, das erste eintreffende Zeichen wird per Message an die Hauptschleife gemeldet. (Nicht jedes, das erzeugt zu viele Messages, das Hauptprogramm kann dann ja den Puffer leeren). Wenn alle Interruptroutinen im System so schlank wie möglich sind, nur die Hardwarewerte o.ä. abholen, eine Message schicken und den Rest dem Hauptprogramm überlassen kriegen wir hoffentlich eine schnelle Übertragung per USB hin. Kanaleinstellung: Setzt auf SPI auf, ist dann nicht mehr schwierig. Flash: Wir brauchen passende Routinen, um einen bestimmten Bereich des Flash selbst verwalten zu können, für persistente Einstellungen und Abspeichern von Messungen. Sollte sich abgucken lassen. Wenn später mal das Programm selbst im Flash läuft muß diese Routine im RAM landen, sowie auch alle Interruptroutinen, damit derweil keine anderen Zugriffe stattfinden. Capturing + Trigger: Die beiden Arbeitspakete werden vermutlich schwieriger. Bisher weiß ich noch fast gar nichts darüber. Eine gute Gelegenheit, sich Spikeproblemen und anderen Phänomänen anzunehmen. Dann wären wir in der unteren Schicht aber auch schon durch, oder habe ich was vergessen? Von der Architektur her bin ich noch nicht sicher, ob wir darüber dann eine Abstraktionsschicht brauchen, um Unterschiede der Designs vor der Applikation zu verbergen. Wenn z.B. dem Leon kein in einzelnen Bitplanes organisierter Bildspeicher beizubringen ist, dann funktioniert das Zeichnen fundamental anders, es sind mehr Lösch-/Neuzeichne-/Kopieraktionen und der Speicher dafür nötig. In zukünftig anderen Oszilloskopen wird man wohl auch eher einen "normalen" Bildspeicher vorfinden als eine solch speziell optimierte Konstuktion. Allerdings dürften solche Geräte dann auch die nötigen Resourcen haben, sprich mehr und schnelleren Speicher. Auch eine wie ich finde reizvolle Idee: Man könnte ein PC-Programm schreiben, was diese untere Schicht simuliert. Dann kann man die Applikation auch komfortabel auf dem PC entwickeln, sie dort laufenlassen und debuggen. Ist jemand fit mit Qt, SDL oder sonstig geeignetem und mag etwas programmieren, was einen Screen in VGA-Größe umrahmt von den Bedienelementen zeigt, per Mausrad die Drehregler und per Klick die Knöpfe bedienbar? Eine weitere nötige Entscheidung: Ich überlege, ob wir die libc überhaupt verwenden sollten. Sie ist nicht gerade klein, und wir brauchen kaum Funktionen daraus. Sowas wie die Stringfunktionen, memset(), memcpy() ist im benötigten Umfang auch leicht selbst zu programmieren/kopieren. Bleibt noch printf(), sprintf() als recht teure Funktion, hauptsächlich wegen des Formatparsings und Fließkomma. Auch da kommt man mit einzeln angestückelten Ausgaben eigener Funktionen zum Ziel. Zuletzt die eigentliche Arbeit: die Applikation, neu geschrieben oder mit Versatzstücken der alten Software. Ich bin nicht der Experte, wie man effizient Benutzeroberflächen auf kleinen Mikrocontrollern programmiert. UI Widgets und so. Da oben sollten andere ran. Das Menüsystem in (Spaghetti)Code ausformulieren ist sicher keine gute Idee. Selbst die jetzige Software verwendet Tabellen (sehen allerdings derzeit ungeschickt aus), sowas kann ich mir gut vorstellen, vielleicht noch mit Funktionspointern für Handler drinnen. So, mehr fällt mir nicht ein, nun warte ich darauf daß die richtigen Leute diesen Thread entdecken und sich einbringen. Jörg
Ok schon entdeckt :-)
Du kommst ja super schnell voran - Respekt!
Ich habe gerade erst nach dem Update auf Suse 12.1 mein System wieder
zum Laufen gekriegt. Diese blöden Schnickschnackfunktionen von KDE4.x
bringen bei mir alles durcheinander.
Zu den Timern, diese werden derzeit so genutzt:
Timer1 -> wird für den Combi-Trigger von Stefan als Timeout Counter
benutzt
Timer2 -> wird für den USTB Mode genutzt und steuert die Intervalllänge
zwischen zwei Abtastwerten.
Timer3 -> wird für alle anderen zeitgesteuerten Ereignisse genutzt
(Popup-
Anzeigedauer etc.)
Das mit der Multiplikation hört sich vielversprechend an und könnte für
die Mathematischen Funktionen extrem nützlich sein. Ebenso für das
Quickmeasurement.
Ein Debugger wäre natürlich das Non plus Ultra! Das hab ich die ganze
Zeit vermisst.
Das printf() ist übrigens eine abgespeckte Version ohne Floating Point
Unterstützung. Diese habe ich mittels kleiner Zusatzfunktion
implementiert.
Ein gutes Konzept für die neue Menüfunktion kann ich momentan leider
auch noch nicht anbieten. Da werden wir wohl etwas Rechercheaufwand
reinstecken müssen. Ich denke je mehr Zeit wir am Anfang in vernünftige
Konzepte investieren, desto schneller werden wir später Resultate
erzielen.
Gruß Hayo
Wie sind denn die Echtzeitanforderungen an die Timer? Ich vermute mal bei 2 sehr straff, bei 1 weniger und bei 3 am allerwenigsten? Timer sind immer ein knappes Gut, finde ich. Die Altera-Timer sind sehr simpel, lassen sich eigentlich nur für je einen Zweck verwenden. (Bin ich nicht gewohnt, im Atmel AVR kann man mit Capture, 2-3 mal Compare, Overflow pro Timer gut mehrere Dinge abfrühstücken.) Ich habe das in der Vergangenheit i.d.R. so gemacht, das ich die schnellen Dinge direkt den passenden Timerresourcen zugewiesen habe (der Timer gehört denen dann praktisch), aber alles was langsam läuft (so im Millisekundenbereich) und kein präzises Timing braucht über einen zentralen Heartbeat-Interrupt abwickle. Dort werden die zur Laufzeit beantragten Timer runtergezählt und bei Ablauf Messages verschickt. Für welche Timer würde sich so ein Verfahren noch eignen? Die Reaktionszeit auf eine Message wird von der längsten Aktion der UI bestimmt, was die halt so worst-case mäßig als Reaktion auf irgendwas tut. Im Extremfall also z.B. den ganzen Bildschirm neu zeichnen, eine FFT rechnen, einen Screenshot übertragen. Währenddessen wird auf nichts anderes reagiert, muß ja vielleicht auch nicht, es staut sich aber alles auf. Jörg
Jörg H. schrieb: > Wie sind denn die Echtzeitanforderungen an die Timer? Ich vermute mal > bei 2 sehr straff, bei 1 weniger und bei 3 am allerwenigsten? Ja korrekt. > Timer sind immer ein knappes Gut, finde ich. Die Altera-Timer sind sehr > simpel, lassen sich eigentlich nur für je einen Zweck verwenden. Leider auch korrekt. > Ich habe das in der Vergangenheit i.d.R. so gemacht, das ich die > schnellen Dinge direkt den passenden Timerresourcen zugewiesen habe (der > Timer gehört denen dann praktisch), Ja so ist es bei Timer 1 und 2. > aber alles was langsam läuft (so im > Millisekundenbereich) und kein präzises Timing braucht über einen > zentralen Heartbeat-Interrupt abwickle. Da muß ich passen, dieser Begriff sagt mir nix. > Dort werden die zur Laufzeit > beantragten Timer runtergezählt und bei Ablauf Messages verschickt. > Für welche Timer würde sich so ein Verfahren noch eignen? Timer drei wird halt für alle Ereignisse im GUI-Bereich verwendet. Diese operieren alle mit Intervallen von 1 - 3 Sekunden. > Die Reaktionszeit auf eine Message wird von der längsten Aktion der UI > bestimmt, was die halt so worst-case mäßig als Reaktion auf irgendwas > tut. Im Extremfall also z.B. den ganzen Bildschirm neu zeichnen, eine > FFT rechnen, einen Screenshot übertragen. Währenddessen wird auf nichts > anderes reagiert, muß ja vielleicht auch nicht, es staut sich aber alles > auf. Momentan habe ich dieses Problem durch ein globales Flag (UI_request) gelöst welches in der ISR gesetzt wird und dann den aktuellen Ausgabevorgang oder Berechnung an definierten Stellen abbricht. Das Ganze wäre aber mit einer Message-Queue sicherlich eleganter. Gruß Hayo p.s. bin heute in der Firma und daher nur über Forum zu erreichen.
Den Code lese ich so, das Timer 1 fest alle Millisekunde kommt, egal ob da was aktiv ist oder nicht. Timer 2 für USTM je nach Zeitbasis alle 20 ms bis 20 s. Timer 3 löscht Popups nach 2 s. Der Kombitrigger sieht so nach Workaround aus, das stelle ich gedanklich erst mal zurück, bis ich ihn verstanden habe und nach Untersuchung von Trigger/Capture einsehe das wir sowas tatsächlich brauchen. ;-) Kann er mit USTB zusammenfallen? Einen Timer sollten wir nach Möglichkeit frei laufenlassen, als hochauflösende Systemzeit. Der kann dann keine programmierbaren Interrupts generieren. Ferner haben wir noch den VSync-Interrupt. Den habe ich noch nicht getestet. Wenn er das tut was der Name sagt, dann eignet der sich wohl als Heartbeat-Interrupt. Damit ist ein recht gemütlicher regelmäßiger Interrupt gemeint (Größenordnung 100 Hz), für allgemeine Systemaufgaben wie z.B. UI-Timer. Die haben dann als Auflösung die Anzahl dieser Ticks. Gestern habe ich noch (erfolglos) mit den User-Instructions des Nios experimentiert. Die waren wohl für die Mathematikfunktion gedacht, haben es aber nicht in das ausgelieferte FPGA geschafft? Jörg
Hallo, ich begrüße diese Entwicklung sehr und freue mich über euer Engagement. Ich bedauere es euch bei der Entwicklung nur motivierend unterstützen zu können. branadic
Motivation kann auch nie schaden! In der gestrigen Spätschicht habe ich den Heartbeat-Timer gebaut. Der VSync-Interrupt kommt tatsächlich (auch wenn der DMA für das Display noch gar nicht aktiviert wurde), mit knapp 60Hz, das wird dann also die Zeitauflösung für den Applikationsteil. Die Applikation kann einen "Rückruf" nach Zeitablauf beantragen, oder einen solchen laufenden abbrechen, z.B. als Timeout verwenden. Timer 3 ist meine freilaufende Systemzeit (für busy-wait und so), die anderen beiden Timer sind noch frei, z.B. für Capturing und Trigger-Workarounds. Ferner habe ich einen kleinen SPI-Treiber geschrieben. Der benutzt das busy-wait um abzuwarten, daß das FPGA die Daten rausgeschoben hat. Nun freue ich mich über zeitgesteuert blinkende LEDs als Anwendung davon. Drüberliegend kann man also die "echte" LED-Ansteuerung realisieren und die Kanaleinstellungen der Eingangsstufe(n). Es geht voran in Richtung Capturing... Jörg
Jörg H. schrieb: > Der Kombitrigger sieht so nach Workaround aus, Genau das ist er... > das stelle ich gedanklich > erst mal zurück, bis ich ihn verstanden habe und nach Untersuchung von > Trigger/Capture einsehe das wir sowas tatsächlich brauchen. ;-) Da der hardwaremäßig implementierte Autotrigger bei niedrigeren Zeitbasen (<500ns) nicht sonderlich gut triggert, da dann der Timeout zu kurz ist, hat Stefan den Combitrigger implementiert. Dieser funktioniert ganz einfach so, dass der Normaltrigger aktiv ist und wenn innerhalb des Timerintervalls kein Ereignis auftritt dann auf den Autotrigger umgeschaltet wird. Im ADC-Handler wird dann die Flanke gesucht und das Anzeigefenster passend positioniert. Das funktioniert ganz gut und ist bei langsameren Zeitbasen eine echte Hilfe. Ich fürchte, das der Autotriggertimeout nicht von außen änderbar ist, ich habe da jedenfalls nichts gefunden. > Kann er mit USTB zusammenfallen? Da der Kombitrigger während des USTB-Modus nicht gebraucht wird kann der Timer 1 auch für beide Zwecke verwendet werden. > Ferner haben wir noch den VSync-Interrupt. Den habe ich noch nicht > getestet. Den hatte ich erstmal abgeschaltet, weil dieser ungenutzt ständig Interrupts erzeugte. Den kann man aber natürlich wie Du schon sagtest als "arme Leute Timer" verwenden. Gruß Hayo
In der gestrigen Spätschicht entstand eine sehr optimierte Linienzeichnefunktion. Die neue Software soll ja mehr Schwuppdizität haben ;-) Auch in Assembler dürfte sich das kaum verbessern lassen, das Disassembly zeigt, daß der Compiler genau das erzeugt hat, was ich von ihm wollte. Ich habe die Laufzeit mit der alten nicht verglichen, könnte mir aber Faktor 2 oder so vorstellen. Stay tuned... Jörg
Hi Jörg, ich wollte nur kurz einwerfen, dass ich hochinteressiert mitlese und begeistert bin, was in so kurzer Zeit schon an Fortschritt erzielt wurde. Außerdem toll, dass du die Energie hast, das ganze voranzutreiben! Endlich werden wir die ganzen Altlasten los und vielleicht läuft das ganze ja in absehbarer Zeit sogar auf dem Leon-Design von Alex... Weiter so! Michael
Hi Jörg, Du bist ja kaum noch zu bremsen. Ich habe die Dateien mal dem Compiler untergeschoben und Probemessungen gemacht. Die Ergebnisse lassen sich sehen! Ich hab das im Firmwarethread mal gepostet. Arbeitet die neue Zeichenfunktion nach Bresenham? Oder hast Du was Neues ausgebrütet? Zur Zeit prüfe ich gerade den nr_delay() - Hatte ich das richtig in Erinnerung, dass der Zähler statt mit 50000 mit 10000 geladen werden muß? Gruß Hayo
Hi, bin selber seit einer Woche Besitzer eines 2Kanal-Welec W2022A. Schönes Teil, insbesondere wenn man's als FPGA-Board mit wohlausgewählten Komponenten betrachtet. Deren Ansteuerung ist dank der herforragenden Doku auch sehr leicht möglich (habe jedenfalls schon alles ansteuern können). Meine Sorge bis jetzt: Bei 250MHz ADC-Takt (und entspr. Takt im FPGA) wird's vieleicht ein wenig heiss. Eine Anleitung zur Kühlung der ADCs ist auf SourceForge\.. zu finden. Aber über einen Kühler für den FPGA findet man leider nichts. Hat der Genug Platz für einen flache Kühlkörper, konnte leider bis jetzt nicht die Platine ausbauen? Gruss
Hayo W. schrieb: > Arbeitet die neue Zeichenfunktion nach Bresenham? Oder hast Du was Neues > ausgebrütet? Besser als Bresenham geht wohl nicht, dem bin ich schon treu geblieben. Ich mache aber die Wort- und Bitadressierung gleich mit in der Schleife, statt eine SetPixel()-Funktion aufzurufen (bzw. als inline drin zu haben). > Zur Zeit prüfe ich gerade den nr_delay() - Hatte ich das richtig in > Erinnerung, dass der Zähler statt mit 50000 mit 10000 geladen werden > muß? Nein, mit "nasys_clock_freq_1000" (also 12500), das steht in der Datei die ich dir schickte aber schon drin. @Sigi: deine Frage ist eher was für den Hardwarethread (Beitrag "Wittig(welec) DSO W20xxA Hardware"). Die ADCs oder gar das FPGA sind meines Wissens nach noch niemandem durchgebrannt. Wenn du dich mit HDL auskennst, kannst du vielleicht das verwaiste Leon-Design supporten? Da hätten wir dringend Bedarf... @All: mein unterer Layer ist letztlich nicht viel Code. Aber er gibt dem Ganzen hoffentlich eine Struktur. Ich bin auch gespannt auf's Feedback, möchte ihn zur Eingewöhnung gern bald veröffentlichen. Vorher will ich aber noch ein "ordentliches" Build-System (sprich Makefiles) und eine Verzeichnisstruktur hinbekommen haben (lasse mir auch gern dabei helfen, meine Makefile-Allergie schlägt wieder an). Im Moment verwende ich noch das alte Schema, alles in ein Verzeichnis, muß meinen Code ferner .cpp nennen obwohl es eigentlich reines C ist. Jörg
@Sigi Willkommen in der Gemeinde :-) Kann gut sein, dass dem FPGA etwas Kühlung gut tun würde. Leider steckt das gute Stück in dem schmalen Spalt zwischen den beiden Platinen. Da passt nicht mehr viel rei, höchstens ein dickes Wärmeleitpad. Jörg H. schrieb: ... >> Zur Zeit prüfe ich gerade den nr_delay() - Hatte ich das richtig in >> Erinnerung, dass der Zähler statt mit 50000 mit 10000 geladen werden >> muß? > > Nein, mit "nasys_clock_freq_1000" (also 12500), das steht in der Datei > die ich dir schickte aber schon drin. Das dachte ich mir eigentlich auch so nachdem ich etwas in den Dateien gestöbert hatte. Tatsache ist aber, dass eine Timingüberprüfung ergeben hat, dass es erst richtig läuft wenn tatsächlich der Zähler mit 10000 geladen wird. Wie kann das angehen? Gruß Hayo
Stimmt, das passt nicht ganz, Startwert 10000 ist wenn ich recht erinnere korrekt. In Zukunft können wir aber mit der Timerfunktion arbeiten statt mit einer Zählschleife. Der Thread soll nun aber kein Fachgespräch zwischen Hayo und mir werden. Solche Details klären wir besser direkt, statt hier die Leute abzuschrecken. Hier geht es drum, wie es der neuen Firmware geht, was wir auch gern von Anderen noch brauchen können, welche Entscheidungen ausstehen. Zum Status: In den letzten Tagen habe ich die Zeichenfunktionen "zuende" optimiert und mich an die Textausgabe gemacht. Es kamen ein paar Funktionen zum Zeichnen von Buchstaben und kleinen Bitmaps (z.B. Icons) hinzu, sowie die Handhabung von Zeichensätzen. Dazu mußte ich etwas weiter ausholen: Bisher sind die Bitmaps für die Zeichen als vertikale Pixelreihen gespeichert, obwohl der Bildspeicher horizontal organisiert ist. In einer bizarr ineffizienten Zeichenfunktion wurde das dann zur Laufzeit gedreht. In der neuen Software ist das durchgehend horizontal und dürfte eine Größenordnung schneller sein. Ich muß aber die bestehenden Zeichensätze und Grafiken in mein neues Format konvertieren. Dafür habe ich nun ein Programm geschrieben. Als nächstes ist nun wirklich das von mir nicht so geliebte Thema Build-System (Makefiles) dran. Mittlerweile stört es an mehreren Stellen, daß ich meinen C-Code als C++ kompiliere. Und dem was gern noch kommen möge: Fühlt sich neben neuen Firmware- und FPGA-Entwicklern auch ein talentierter PC-Programmierer mittelfristig berufen, uns zu unterstützen? Ich denke dabei an die PC-Simulation der unteren Layer, um die spätere Applikationsschicht wahlweise auf einem PC zu kompilieren und zu debuggen. Weihnachtliche Grüße Jörg
Hallo Betreffend der PC Software könnte ich vlcht. was machen. Kann Assembler und C für µCs und C#(.NET) für PC, derweil nur auf Windows. Hab' viel Erfahrung in alldem. Bitte um eine Beschreibung/Skizze/Spezifikation der Aufgabe um den Aufwand abschätzen zu können. Bin berufstätig, habe drei Kinder und Frau die ich (noch) behalten möchte und will nichts anfangen dass ich nicht fertigmachen und pflegen kann. Bitte um eine EMail mit mehr Details. Gruß Kruno
Hallo Kruno, danke für dein Angebot. Ist wie gesagt mittelfristig, ich wollte nur schon mal Reklame machen. Noch ist es nicht konkret genug. Was würdest du denn gerne machen? Daran liegt es ja hauptsächlich. Der Spaß an der Sache soll ja nicht abhanden kommen. Mal so ganz persönlich: Mit Beruf und meine-Frau-behalten gelingt mir das hier nur knapp, mit zusätzlich 3 Kindern fände ich es geradezu verantwortungslos, bist du dir sicher daß das hier was für dich ist? Jörg
Mal weiter zum Status: ich habe das Makefile umgearbeitet, so daß es mit einer "anständigen" Verzeichnisstruktur arbeitet und der Code auch in C (statt C++) kompiliert wird. Das hat ein paar Probleme gelöst, die mich blockierten. Für den Nios kommt nämlich ein uralter Compiler, Stand ca. anno 1999/2000, zum Einsatz (gcc 2.9, aktuell 4.6.x), mit C kommt er beser klar. Dann konnte ich meine neue Textausgabe mit der Zeichenfunktion testen. "Hello World" auf dem Bildschirm. Ich habe dann noch ein weiteres Softwaremodul für Icons gemacht und mit einer Scrolling-Funktion experimentiert. Heute ging es zum Aufwärmen mit einem kleinen LED-Treiber los, der auf dem SPI-Treiber aufsetzt. Im Moment bin ich nun bei einem Treiber für die serielle Schnittstelle, mit Interrupts und so. Noch ausstehend: Ähnliches falls möglich für USB, und ein Flash-Treiber für persistente Daten. Dann kommen die echten Oszilloskopfunktionen: Kanaleinstellung, Offseteinstellung, Trigger, Capturing. Und dann kann es mit der Applikationsentwicklung losgehen. Wenn der Schwung nachlässt mache ich mal einen Release von meinem Code in Sourceforge, damit man sich das angucken kann. Ohne Versionsverwaltung fühle ich mich selber unwohl, dann kann man nicht auf ältere Stände rückgreifen bzw. muß selber Backups machen. Grüße Jörg
Hallo Jörg Ich könnte ein paar Monate darauf 2-3 Abende/Woche daran arbeiten ohne das ich schlechtes Gewissen bekomme. Ich wollte die Beschreibung dessen um beurteilen zu können ob es sich in gegebener Zeit ausgeht. Ihr könnt mich auch sonst wie beschäftigen, mit Code-review, Bibliotheken oder Teilen davon. Einfach anschreiben bitte. Wäre schön wenn es eine VMWare VM mit allen Tools (Compiler, ev.Debugger, SVN usw.) für die FW-Entwicklung geben würde welche alle interessierten verwenden könnten ohne sich den Aufwand einzeln antun zu müssen. Es würde den Einstieg wesentlich erleichtern und vom Betriebssystem abkoppeln. Einer müsste es halt erstellen und pflegen. Gruß
Status: Der Treiber für die serielle Schnittstelle ist fertig. Ich kann jetzt im Hintergrund Daten senden und empfangen. Davon verspreche ich mir Verbesserungen für z.B. die Screenshot-Funktion. Das Hauptprogramm kann den Bildinhalt komprimieren, während er im Hintergrundübertragen wird. @Kruno: nochmals danke für dein Angebot. Da finden wir sicher was. Bist du bei Skype angemeldet? Wenn, ja, dann schicke mir doch mal deine ID per PN, ich lade dich gern zu unserem Gruppenchat ein. Größere open source Projekte haben i.d.R. einen IRC-Channel, wir machen das derzeit per Skype-Gruppe. @all: Wer sonst noch rein möchte, einfach melden. Anderes Thema: Fällt jemandem ein schöner Name für dieses Projekt ein? Jörg
Ich habe jetzt einen Zwischenstand eingecheckt, zum Review und zur Sicherheit. Hauptproblem war der Name... ;-) Ich habe dem Projekt jetzt den Arbeitstitel 'Osoz' gegeben. Nicht übermäßig einfallsreich, für 'Open Source Oszilloskop'. Es liegt ganz bescheiden im Nios-Unterverzeichnis, obwohl es ja nicht nur dafür sein soll. Ich hänge hier absichtlich kein .zip ran, um euch gleich die richtige Arbeitsweise mit Versionsverwaltung aufzunötigen. So kann man prima verteilt entwickeln, Updates ziehen, Änderungen einchecken. Man den Dateibaum mit einem svn-Client eigener Wahl auschecken. Z.B. mit Linux/Cygwin Kommandozeile:
1 | svn co https://welecw2000a.svn.sourceforge.net/svnroot/welecw2000a/fpga/nios/osoz |
oder einer IDE wie Eclipse, oder einem grafischen Tool wie TortoiseSVN unter Windows. Angucken geht auch per Browser: http://sourceforge.net/apps/trac/welecw2000a/browser/fpga/nios/osoz Der Applikationsteil tut noch herzlich wenig. Ich habe da verschiedene Tests für meine unteren Schichten zur Auswahl. Das 'spannendste' mag vielleicht das Terminalprogramm sein (schreibt auf den Bildschirm was man ihm per RS232 sendet) und ein Etch-A-Sketch, malen mit 2 Drehknöpfen. Fragen? Anmerkungen? Jörg
Nur nicht so drängeln! ;-) Kleines Status-Update: Die Kommentare in den Headern (unter platform/include) für Funktionen und Typen sind jetzt für Doxygen formatiert. So haben wir dann stets aktuell eine nette API-Beschreibung meiner unteren Schicht. Wenn in Zukunft die Applikation auch mit solchem Kommentarformat geplegt wird dann natürlich auch von selbiger. Das Makefile ruft Doxgen auch auf, falls installiert, "make doc" erzeugt die Dokumentation. Sie wird in 2 Formaten generiert: HTML zum rumklicken, alles schön verlinkt, und LaTex. Wer das installiert hat kann im erzeugten 'latex' Verzeichnis wiederum make aufrufen und erhält ein PDF. Jörg
Ich schreibe mal wieder was, nicht das ihr denkt ich liege hier faul rum... Bin fleißig dabei. Was ist seitdem passiert: - Ich habe das SPI-Timing an den Schieberegisterketten (LEDs, Kanaleinstellungen) präzise vermessen, damit die Software nicht länger wartet als nötig (es gibt kein Ready-Flag o.Ä.) - es gibt jetzt einen (kleinen) Treiber zur Einstellung der DC-Offsets - ein etwas größerer Treiber ist neu, für die Kanaleinstellungen der alten und neuen Eingangsstufe - Optimierungen für die Relais: Settling Time jetzt gemäß Datenblatt, und auch nur wenn es tatsächlich etwas umzuschalten gab - die angefangene BitBlit-Funktion ist jetzt vollständig (sie dient zum Umkopieren beliebiger Bildausschnitte, und ist eine harte Nuß, daran kann man sich das Hirn verrenken) - Treiber für Triggereinstellungen, bisher nur für den externen Trigger Bei letzterem fiel mir auf, das beim externen Trigger ein Hardwareproblem besteht, zumindest bei meinem Gerät. Könnte die nächste Tuning-Baustelle sein. Mehr dazu demnächst im Hardware-Thread. Grüße, Jörg
Hi Jörg, ich muß mich entschuldigen, dass ich bislang noch nichts beigetragen habe zum neuen Projekt. Bin momentan etwas busy und konnte nur schnell ein paar Bugfixes für die alte Firmware einreichen. Ich werd mich aber in Kürze mal dranmachen und einen Flashtreiber beisteuern. Gruß Hayo
Nachtrag - falls Du mit Hardwareproblem meinst, dass der Triggerlevel nicht proportional zum Registerwert ist beim Ext. Trigger -> das ist "normal". Hab übrigens erste Versuche mit dem KDE-SVN unternommen und die OSOZ Ordnerstruktur ausgecheckt. Compilieren geht. Hab mal etwas in den Sourcen gestöbert - ist etwas anders vom Stil als ich es gewohnt bin aber sieht ganz aufgeräumt aus. Muß mich erst an die neue Struktur gewöhnen. Für den Flashtreiber würde ich dann einfach eine flash.c und flash.h beisteuern, entspricht das Deinen Vorstellungen? Hayo
Hallo Hayo, > ich muß mich entschuldigen, dass ich bislang noch nichts beigetragen > habe zum neuen Projekt. Bin momentan etwas busy und konnte nur schnell > ein paar Bugfixes für die alte Firmware einreichen. Kein Entschuldigung nötig, so war mein Posting keinesfalls gemeint. Ich wollte nur kundtun was so abgeht. > Nachtrag - falls Du mit Hardwareproblem meinst, dass der Triggerlevel > nicht proportional zum Registerwert ist beim Ext. Trigger -> das ist > "normal". Nein, ich meine damit das ich einen heftigen 500mV-Ripple von der PWM auf der "Gleichspannung" habe mit der die Triggerung vergleicht. Dadurch kriegt der Komparatorausgang einen erheblichen Jitter, Netztrigger ist sogar quasi unmöglich weil des Vergleichssignal eine kleinere Amplitude hat. > Hab übrigens erste Versuche mit dem KDE-SVN unternommen und die OSOZ > Ordnerstruktur ausgecheckt. Compilieren geht. Hab mal etwas in den > Sourcen gestöbert - ist etwas anders vom Stil als ich es gewohnt bin > aber sieht ganz aufgeräumt aus. Muß mich erst an die neue Struktur > gewöhnen. Ich führe dich gern ran, frag bzw. sag Bescheid was du als ungünstig empfindest. Die API hat noch kein Review gesehen. Ist keinesfalls in Stein gemeißelt, sondern ein erster Vorschlag. > Für den Flashtreiber würde ich dann einfach eine flash.c und flash.h > beisteuern, entspricht das Deinen Vorstellungen? Ja, ganz genau. Im "Peer Review" werden wir es spätestens richten. Ich hätte auch noch zahllose kleinere Fragen, laß' dich gern mal wieder im Chat sehen... ;-) Jörg
Bin leider gleich wieder weg zum Punktspiel und komme erst spät wieder. Wird also heute wohl nix mehr. > Kein Entschuldigung nötig, so war mein Posting keinesfalls gemeint. Nein das hatte ich auch nicht so verstanden, aber Du gibst hier so viel Gas, das man schon etwas ein schlechtes Gewissen bekommt... :-) Aber ich finde das echt prima, dass Du so vorlegst, das motiviert einen auch was beizutragen. > sag Bescheid was du als ungünstig empfindest. War so nicht gemeint, sondern das ich mich erst an den neuen Progammierstil gewöhnen muß. Ist doch schon anders als die alten Sourcen - zum Glück. Macht auf jeden Fall keinen schlechten Eindruck. > das ich einen heftigen 500mV-Ripple von der PWM auf der > "Gleichspannung" habe ist ja eine üble Nummer. Da müßte man auf jeden Fall mal gegenprüfen ob das auch in der Serie vorkommt und gegebenenfalls versuchen da eine Filterung einzubauen. Gruß Hayo
Jörg H. schrieb: > @all: Wer sonst noch rein möchte, einfach melden. Sorry, hab kein solches Scope. Vielleicht fällt mir ja mal eins in die Hände... > Anderes Thema: Fällt > jemandem ein schöner Name für dieses Projekt ein? Wie wärs mit neoWIWEO? ;) Gruß, Edson
Um es an einer geeigneten Stelle noch einmal für alle festzuhalten: Daniel hat uns den Hinweis auf die Verbindung zwischen FPGA1 und FPGA2 geliefert. Das Ganze wurde wohl mal von Slog ermittelt und ist hier festgehalten: http://sourceforge.net/apps/trac/welecw2000a/browser/fpga/zpu/quartus/W2000A.qsf Intessierend sind die Zeilen 263 - 268. branadic
Ich blogge mal wieder raus, was derweil so passiert: Letztes Wochenende habe ich mich mit der Trigger+Capture Mimik beschäftigt. Was da so abgeht war für mich völlig neu, jetzt ist es schon klarer. Ich bin das Ziel, die erste Waveform zu sehen dann aber doch nicht so agressiv angegangen, sondern erstmal weiter Grundlagen geschaffen. Es gibt nun einen Capture-Treiber, aber er tut noch nicht viel, enthält hauptsächlich Kommentare was ich so rausgefunden / mir erarbeitet habe. Vermutlich nichts grundlegend Neues, aber hoffentlich mal versammelt. Ach ja: meine Sample-Kopierroutine in C ist schneller als die dort bisherige in Assembler. Ob das was nützt / dort kritisch ist weiß ich aber noch nicht. Es gibt 2 "magische" Werte, die aus dem Flash gelesen werden und so 1:1 in die Register geschrieben werden, sie scheinen irgendwas mit Filterung zu machen. Warum aus dem Flash? Wohlmöglich gibt es verschiedene Hardware-Versionen. Ferner wird allen Ernstes die Helligkeit des Grid-Layers mit ein paar Bits des Capture-Registersatzes eingestellt, die wohl noch frei waren. Eine Herausforderung für die Modularität der Software, denn das gehört funktional in den LCD-Treiber, der wiederum mit diesen Registern nichts zu schaffen hat. Für die ersten Waveforms brauche ich noch Infrastruktur. Ich habe ein kleines Modul eingeführt, was sich um das Grid kümmert. Sieht soweit schon mal gut aus. Statuszeile und erste Softkeys wären auch nicht schlecht. Das geht jetzt schon deutlich in Richtung UI, und da fehlen noch die Konzepte. (Mitmacher sind willkommen.) But wait, there's one more thing: Gestern habe ich mich mal um Grundlagen des Softwarestarts gekümmert. Die Makefiles wie wir sie kennen kompilieren die Software zur Ausführung im RAM, dann wird für die Flash-Datei noch ein gottgegebener Teil davorgeschnallt (ist wohl irgendwann mal von der uns nicht zugänglichen Altera-Suite erzeugt worden), der anscheinend das Umkopieren vom Flash ins RAM übernimmt. Dieses Stückchen Code habe ich gestern mal disassembliert. Es kopiert in der Tat, und zwar byteweise! Dazu hilft es vielleicht zu wissen, das der Nios immer 32Bit-Zugriffe macht, auch wenn weniger gefordert ist. Der Flash-Baustein ist mit 8 Bit angeschlossen, das Speicherinterface muß also 4 Zugriffe machen um einen solchen auszuführen. Mit einem Extra-Befehl werden dann 3 von den 4 mühsam geholten Bates verworfen. Dann wird das Byte ins RAM geschrieben. Ähnliche Abfolge rückwärts: das Byte wird mit einem vorbereitenden Befehl vierfach in das Register repliziert, denn auch Schreiben geht nur mit vollen 32 Bit. Dann kommt der eigentliche Schreibbefehl. Das RAM ist zumindest 32 Bit breit, dort kein weiteres Nadelöhr. In Summe also 4 Befehle und 4 Buszyklen am Flash plus einer am RAM, um ein Byte zu bewegen. Wenn man das 32bittig macht sind es stattdessen 2 Befehle und gleiche Busaktivität, um gleich 4 Bytes auf einmal zu bewegen. Ich habe dann eine alternative Startroutine programmiert, die erstens natürlich mit 32 bit arbeitet, zweitens ist ein recht extremes loop-unrolling drin. Mache ich sonst nicht, aber für die Startroutine sind eh 256 Bytes reserviert, die kann ich also auch mit sinnvollem Code füllen. Ferner kopiert die Startroutine nur so viel wie nötig. Die alte Routine hat (recht willkürlich) 641180 Bytes kopiert, egal ob Hayos Software kleiner oder schlimmstenfalls gar größer ist (aktuell hat sie 577936 Bytes). Ich habe die Startroutine zum Test mal passend auf Hayos aktuellen Release eingestellt und statt des alten Loaders davorgepappt, das ganze geflasht. Ergebnis: Beinahe Instant-On! Vorher hat das Gerät ja beim Einschalten ca. 5 Sekunden kein Lebenszeichen von sich gegeben, das dauert jetzt vielleicht noch eine Sekunde. Ich werde das heute abend mal im Software-Thread anhängen, zum allgemeinen ausprobieren. Mit Osoz wird es noch schneller gehen, weil das derzeit viel kleiner ist und effizienter initialisiert. An der ganzen Übung ist auch interessant, das wir nun wissen wie die Software ganz am Anfang gestartet wird. Damit könnte man den Loader auch selbst in der Software unterbringen und das entsprechend linken. Es muß auch nicht unbedingt alles ins RAM, die große Masse an unkritischem Code und Tabellen könnte man auch im Flash lassen, hat dann mehr RAM frei. Im Detail: der GERMS-Monitor prüft an Adresse 0x4000C (das ist im Flash), ob dort die 4 Zeichen "Nios" abgelegt sind. Wenn ja, dann springt er die Adresse 0x40000 an. Ab dort flashen wir, zuerst den Loader, 256 Bytes später das RAM-Image. Was ist eigentlich in den üppigen 256KB darunter? Nur der GERMS-Monitor, oder auch Platz für einen FPGA-Bitstream? So long, Jörg
Hallo Jörg! Gratuliere zu der geschafften Performanceerhöhung durch ersetzen des Altera Codes. Ich glaube nicht, dass die 256 kB reichen, um den Cyclone II/35K zu konfigurieren, die SOF Datei hat und hatte bei mir immer so rund 800 kB. Für einen kleineren Vertreter ist das durchaus denkbar! Alexander
Ich habe den Make-Flow nun so verändert, daß beim Kompilieren auch der Loader mit gebaut wird, für genau die passende Größe. So hat man dann automagisch alles richtig beisammen. Im per Script erzeugten .flash-File wird auch die korrekte Anzahl Flash-Blöcke gelöscht. (Das Script hat mich echt Nerven gekostet, ich wollte das erst als Einzeiler mit ins Makefile packen, habe aber schließlich aufgegeben.) Man könnte diese Mimik auch für die alte Software übernehmen. Osoz wird sich vermutlich irgendwann vom getrennten Loader wegevolutionieren... Jörg
Ich schau mir das Makefile mal an. Inzwischen habe ich mich etwas mit SVN angefreundet. Scheint soweit ganz gut zu funktionieren. Ich bin auch schon beim Flash-Treiber (wenn ich zwischendurch mal Zeit hab) und habe auch schon einige Zwischenstände eingecheckt (wie Du wahrscheinlich schon bemerkt hast). Gruß Hayo
Ja, ist beides positiv aufgefallen. ;-) Weiter so! Wo ich denn schon so eine effiziente Art memcpy() für den Loader gebastelt hatte, habe ich heute daraus eine generische Funktion gebaut, wie auch für memset(), und beides Osoz hinzugefügt. Sie sind aber schon noch auf 32Bit Alignment spezialisiert, heißen daher memcpy32() und memset32(). memset32 ist gut Faktor 2,2 mal schneller als memset, memcpy32 ist 1,4 mal schneller als memcpy. Im Moment verwende ich die Funktionen zum LCD-Löschen und in meinem Terminal-Testprogramm zum Scrollen. Eine LCD-Plane löschen dauert 2,4 Millisekunden, eine umkopieren 5,6 ms. Beim Timer ist eine Inline-Funktion für einfaches timergesteuertes Warten dazugekommen, der Flash-Treiber scheint Bedarf dafür zu haben. So long Jörg
So bin etwas schrumpelig von der Badewanne, muß aber trotzdem nochmal checken was hier so los ist. > Wo ich denn schon so eine effiziente Art memcpy() für den Loader > gebastelt hatte, habe ich heute daraus eine generische Funktion gebaut, > wie auch für memset(), und beides Osoz hinzugefügt. Sie sind aber schon > noch auf 32Bit Alignment spezialisiert, heißen daher memcpy32() und > memset32(). Hört sich gut an. 32 Bit wird aber wohl auch die Hauptanwendung sein denke ich. > Beim Timer ist eine Inline-Funktion für einfaches timergesteuertes > Warten dazugekommen, der Flash-Treiber scheint Bedarf dafür zu haben. Ja so ist es, für die alte Firmware habe ich dafür ein nr_delay_us() gebaut und der Niosbibliothek hinzugefügt. Ich brauche eine Möglichkeit relativ genau (5%) 1 µs zu warten, kann die Funktion das? Übrigens habe ich nach dem Vorbild von Osoz das Makefile der alten Firmware umgebaut. Leider habe ich das Problem, dass dis entstandene Tomcat.flash nur nach manueller Nacharbeit vom Perlskribt geladen wird. Es hakt daran, dass da Leerzeilen drin sind und nach der Bootroutine ein S8 Befehl steht der das Skribt zum Anhalten bringt. wenn man das manuell entfernt funktioniert alles. Hattest Du da keine Probleme? Gruß Hayo
Hayo W. schrieb: >> Beim Timer ist eine Inline-Funktion für einfaches timergesteuertes >> Warten dazugekommen, der Flash-Treiber scheint Bedarf dafür zu haben. > Ja so ist es, für die alte Firmware habe ich dafür ein nr_delay_us() > gebaut und der Niosbibliothek hinzugefügt. So etwas ähnliches hatte ich damals auch für das SPI-Bitbanging der neuen Eingangsstufe eingebaut, Sleep_us(). > Ich brauche eine Möglichkeit > relativ genau (5%) 1 µs zu warten, kann die Funktion das? Im Prinzip ja, aber der Call-Overhead kommt hinzu, liegt in der Größenordnung von 31 Takten, dauert also bereits länger. Mit einem Dutzend NOPs kommst du wohl besser hin. Wie immer können auch Interrups dazwischenkommen und die Sache weiter verzögern (aber derzeit nicht auf's Flash zugreifen). Bei den Flash-Bausteinen kann man doch in der Regel auch drauf pollen, das sie fertig sind, mit einem Toggle-Bit? Es gibt auch einen m.W. noch nicht näher erforschten Flash-Ready-GPIO. > Übrigens habe ich nach dem Vorbild von Osoz das Makefile der alten > Firmware umgebaut. Prima. Ist mir auch aufgefallen. ;-) > Leider habe ich das Problem, dass dis entstandene > Tomcat.flash nur nach manueller Nacharbeit vom Perlskribt geladen wird. > Es hakt daran, dass da Leerzeilen drin sind und nach der Bootroutine ein > S8 Befehl steht der das Skribt zum Anhalten bringt. wenn man das manuell > entfernt funktioniert alles. > > Hattest Du da keine Probleme? Öm, könnte dran liegen das ich es selbst nicht ausprobiert habe. Da muß ich wohl nochmal ran... Jörg
OK, ist behoben, sorry. Änderungen im Makefile und im Script. Jörg
Super, läuft wie geschmiert! Klasse ist, dass die alte Firmware schon so von den Arbeiten an der neuen Firmware profitiert. Die Routinen für den Flashtreiber verwende ich z.B. auch gleich für die alte Firmware, da ich ohnehin die Tests mit der alten FW mache. > Bei den Flash-Bausteinen kann man doch in der Regel auch drauf pollen, > das sie fertig sind, mit einem Toggle-Bit? Mache ich auch, aber ich möchte das Timeout möglichst genau haben um nicht versehentlich zu kurz zu liegen (so wie bei der alten Routine). > Es gibt auch einen m.W. noch nicht näher erforschten Flash-Ready-GPIO. Den könnte ich mal näher unter die Lupe nehmen. Hayo
Habe gerade mal versucht das Cygwin auf den aktuellen Stand zu bringen, falls ich mal unter Windows was machen will oder für diejenigen die kein Linux haben. Leider gibt es hier Probleme mit dem Shellscript das die Sektorlöschbefehle generiert. Aus irgendeinem Grunde bleibt es in der Schleife hängen und schreibt bis zum jüngsten Tag e00040000 hinein. Eine Idee? Hayo
Ja, das Script benutzt BASH Syntax zum Rechnen, sh ist in der alten Cygwin Umgebung aber keine BASH Shell. Da bei mir in der alten Cygwin bash auch nicht laufen mag (win7?), versuche Ich gerade ein Build Environment mit einer aktuellen Cygwin Umgebung zu bauen. Das funktioniert bisher ganz gut, die erste Firmware ist zumindest lauffähig kompiliert (C4). Bjoern
Ah so. Vielleicht kann man zum kompatibleren Berechnen "expr" verwenden. Vermutlich muß man die Variablen dann dezimal führen, was ich bisher aus Gründen der Lesbarkeit nicht getan habe. So in der Art: addr=262144 ... addr=$(expr $addr + 65536) Jörg Edit: es funktioniert zumindest mit der Bash noch, ich checke das mal probehalber so ein.
Eine aktuellere Cygwin Build Umgebung wäre natürlich das Optimum da wir dann alles 1:1 übernehmen könnten. Ansonsten übernehme ich erstmal Jörgs Lösung um überhaupt etwas anbieten zu können. Ich bin gespannt... Hayo
Ich habe mir jetzt auch Cygwin auf meinem Windows-Notebook installiert, allerdings natürlich die aktuelle Version. Das gestrige Script läuft damit. Wo bekommt man denn das Nios CDK für Cygwin her? Jörg
Bin gerade (noch mal) dabei den CDK aus den Quellen neu zu kompilieren. Soll ich es Dir dann mal zusammenpacken? Bjoern
Sowas kannst du? Und warum "nochmal"? Es muß doch schon ein Cygwin-Kompilat geben, oder? Wenn nicht nehme ich gern deines, aber einen "offiziellen" Stand fände ich definierter. Edit: hab's gerade gefunden, bei Sourceforge unter Files, Development: http://sourceforge.net/projects/welecw2000a/files/Development/NIOS_Cygwin.zip/download (Die Wiki-Suche kommt da nicht lang.) Ich hatte auch mal probiert den Compiler zu compilieren (unter/für Linux), das hat aber nicht hingehauen. Könnte man das Nios-Backend eigentlich auf einen neueren gcc verpflanzen? Jörg
Die Cygwin Version von SF habe ich auch erst benutzt. Es gibt aber eine minimal neuere GCC Version von Altera. Die cygwin Version auf SF ist die "gcc version 2.9-nios-010801-20030718", die letzte Altera Version für den Nios I ist "gcc version 2.9-nios-010801-20041001" (GNU Tool 3.2). Den Source findest Du auf der Altera Seite. http://www.altera.com/support/ip/processors/nios2/ide/ips-nios2-ide-tutorial.html Zumindest für den NIOSII gibt es da neuere GCC Versionen. Ob sich aber der NIOS Kram auf einen neueren GCC porten lässt, kann ich Dir leider nicht sagen. Ich hab die Version von der Altera Seite mal als "/opt/cdk4nios" kompiliert. Wenn Du möchtest, kannst Du es gerne mal testen. Die letzte BlueFlash Version lies sich bei mir damit problemlos kompilieren. http://dl.dropbox.com/u/3409975/cdk4nios-3.2.tar.gz Björn
Hallo Björn, werde ich probieren, danke! Das ist ja ein interessantes Versionskuddelmuddel. Ich kannte bisher nur das verwaiste CDK4NIOS Projekt bei Sourceforge: http://cdk4nios.sourceforge.net/ Deren neueste Version heißt 2.9-nios-010801-20030923. Die habe ich wohl probiert. (Und auch unter Linux im Einsatz.) Nun gerade noch mal frisch mit den Sourcen von Altera. Das ist immerhin der vertraute configure-make-make install Flow. Aber auch da entgleist mir das make wieder. Was für einen gcc verwendest du? (hier: 4.4.3) Jörg
Jörg H. schrieb: > Edit: hab's gerade gefunden, bei Sourceforge unter Files, Development: > http://sourceforge.net/projects/welecw2000a/files/Development/NIOS_Cygwin.zip/download Genau die wollte ich auf den aktuellen Stand bringen. Selbige hat nämlich den Charme dass man sie ohne Installation auch vom USB-Stick starten kann. Übrigens funktioniert das Script auch nach Deiner Modi nicht mit der alten Cygwin-Umgebung. @Björn Wenn Du das so kompakt auf den neueren Stand bringen könntest (mit Bash) wäre das natürlich echt super. Dann könnte ich (oder Du wenn Du einen User hast den ich einrichten könnte) das auf SFN für alle zum Download bereitstellen. Gruß Hayo
@Jörg Du musst einen 3er GCC nehmen, mit den 4er GCCs mag er den Code nicht mehr compilen. Unter Cygwin geht es auch nur mit dem gcc-3 (3.4.4). Dazu kommt, dass der Source bergeweise DOS line endings enthält. Die müssen weg, sonst provoziert das auch einige Fehler. Welche Distri benutzt Du eigentlich zum Entwicklen? @Hayo Ich schau mal, was sich machen lässt. Grüße, Björn
Hallo Björn, deine Cygwin-Kompilate funktionieren bei mir. Analog zu der Linux-Installation habe ich noch so ein Pfade-Setz-Script nach /opt/cdk4nios/etc kopiert, und mir einen Alias gemacht der das durchsourced. Ich habe Osoz erfolgreich damit kompiliert. Ist aber gruselig langsam. So habe ich das aus einem anderen Projekt vor Jahren auch in Erinnerung. Ich habe zum Test erstmal die Default-Installation von Cygwin gemacht. PATH enthält (dummerweise?) die Windows-Suchpfade, so holt er sich bei mir "make" aus einer AVR-Installation ran, und würde Perl aus einer ActiveState-Installation nehmen. Das täuscht drüber weg, daß man das eigentlich noch bei Cygwin nachinstallieren muß. Jörg
Hab mir gerade bei meinen Tests für den Flashtreiber das Flash zerschossen. jetzt warte ich bis der Dump wieder eingespielt ist... Aber es geht voran. Hayo
Ok es lebt wieder! Werd jetzt noch mal cygwin testen...
@Björn Ich habe erstmal die alte Cygwin Umgebung mit Jörgs neuem Script zum Laufen gebracht und zum Download bereitgestellt. Falls Du da eine aktuellere Cygwinversion zusammengebaut kriegst sag Bescheid. Gruß Hayo
Hallo, ich habe mich mal an einer neue Cygwin Version versucht, inkl. Perl und passender Pfade. Das Archiv ist allerdings eine ganze Ecke größer als das Alte (~60MB). Wäre nett, wenn Ihr mal testen könntet, ob das ganze bei Euch funktioniert. http://dl.dropbox.com/u/3409975/NIOS_Cygwin_1.7.zip @Jörg Ich habe die Version 3.2 von Altera mal unter Ubuntu kompiliert. Falls das bei Dir sauber funktioniert, könnten wir dann unter Cygwin und Linux die selbe Compilerversion verwenden. http://dl.dropbox.com/u/3409975/cdk4nios-linux-3.2.tar.gz Grüße, Björn
Hallo Björn, (ggf. erstmal herzlich willkommen! Du bist mir bisher noch nicht als "Projektmitarbeiter" aufgefallen. Sorry wenn ich was übersehen habe, bin neu hier.) Ich habe da mal reingeschaut, aber aber es noch nicht installiert. Mir fällt auf, daß ein bischen mehr drin ist, mit Absicht? Im bin-Verzeichnis finden sich noch bison, flex, make und andere Tools, die eigentlich besser vom Host kommen sollten. Unter lib liegen auch noch Systembibliotheken, man und share enthalten "Zeug". Kann ich natürlich selbst ausdünnen. Nochmal: mit welchen Compiler kannst du das erfolgreich übersetzen? @All: Ich habe gestern noch mit Eclipse experimentiert. Wenn man ein Projekt passend eingerichtet hat ist das eine sehr komfortable Sache. Ich kann auf Knopfdruck kompilieren, den Download zum Welec anstoßen, Files in SVN einchecken. Man hat das Crossreferencing zur Hand, kann also mit Rechtsklick auf Funktionsnamen oder sonstige Bezeichner gleich zur Definition springen. Kompilerfehler kann man anklicken und landet gleich im Code. Das ist der Mercedes, meine bisherige Arbeitsweise mit getrenntem Editor, einer Shell zum Kompilieren und dem Download-Batch ist dagegen wie Dreirad fahren. (Ich habe Eclipse schon in der Vergangenheit benutzt, eine IDE ist ja nix neues, nur für die Welec-Sachen halt noch nicht.) Das SVN-Plugin "stört" sich etwas daran, das wir auf gleicher Höhe wie das Makefile unsere Produkte ablegen, unter obj/ und die Doxygen-Sachen unter latex/ und htmt/. Das möchte er defaultmäßig alles mit einchecken, sehr gefährlich. Man kann das auf die Ignore-Liste setzen, muß es aber halt tun. Vielleicht sollten wir unseren Flow ändern und die Produkte unter ../build oder so erzeugen? Ich habe Eclipse unter Windows eingerichtet, zum Kompilieren muß er dann Cygwin nehmen. Funktioniert fast genauso wie unter Linux, man muß dem Projekt als Build Environment PATH nur "C:\cygwin\bin;C:\cygwin\opt\cdk4nios\bin" mitgeben. Leider ist Cygwin (bei mir) enorm langsam. Das kleine Osoz-Projekt kompiliert unter Linux in 3 Sekunden, unter Cygwin bummelt er 54 Sekunden dran rum. (Die Rechner sind beide nicht schnell, Linux ist ein VIA-C7 Stromsparserver mit 1 GHz, Windows ein Centrino-Notebook mit 2 GHz.) Jörg
Hallo Jörg, danke, ich bin in der Tat ganz neu hier. Du hast recht, das Linux Kompilat gehörte noch aufgeräumt. Ich hatte gestern nur getestet, ob es bei mir unter Ubuntu BlueFlash kompiliert und es dann direkt einfach in ein Tar gepackt, um zu sehen, ob das ganze bei Dir überhaupt funktioniert. Ich hab gerade ein aktualisiertes tar auf dropbox gepackt, das ist deutlich aufgeräumter. Wie schon gesagt, mit dem gcc > 4 mag er den Code nicht übersetzen. Übersetzt ist das ganze also mit gcc 3.4.4 unter Ubuntu 10.04. Den alten gcc muss man allerdings aus dem Hardy Repository installieren. Björn EDIT: Die Cygwin Umgebung habe ich auch noch mal aktualisiert.
Björn F. schrieb: > Wie schon gesagt, mit dem gcc > 4 mag er den Code nicht übersetzen. > Übersetzt ist das ganze also mit gcc 3.4.4 unter Ubuntu 10.04. Den alten > gcc muss man allerdings aus dem Hardy Repository installieren. Entschuldigung, ich hatte dein Posting von gestern 18:50 Uhr übersehen. Ich verwende Ubuntu 10.04, auf meinem Stromspar-Server läuft allerdings was ganz spezielles (Porteus). Jörg
Hallo Jörg, ich Dir mal den gepackten Source, so wie er jetzt bei mir compiled, auf dropbox gelegt. http://dl.dropbox.com/u/3409975/nios-gnupro-src-3.2-mod.tar.gz Björn
Prima, das schreitet ja super voran. Auch von mir ein willkommen an Dich Björn. Bist Du auch ein WELEC-DSO Besitzer oder einfach ein Interessierter? @Jörg Habe den vorläufig fertigen Treiber eingecheckt. Die Funktionen sind soweit als stabil getestet. Nicht getestet aber vermutlich wegen des einfachen Aufbaus trotzdem ok sind die Byte- und Integerschreibfunktion. Todo: - die Delays sind zurzeit noch nicht mit Timer realisiert. Man muß mal sehen ob das noch umgestellt werden muß - es gibt nur Grundfunktionen. Spezialisiertere Funktionen werden wir wohl außerhalb der Treiberschicht implementieren denke ich. Wenn noch eine entscheidende Funktionalität fehlt bitte ich um Info. - falls Dir moch weiteres Optimierungspotential auffällt (soll heißen wenn ich irgendwo einen Bock geschossen habe) immer raus damit. Hayo
Ich habe heute mal die CDK-Quelltexte der Sourceforge-Version 3.1 und der Altera-Version 3.2 verglichen. (Björn, wie hast du denn vermutlich automatisiert die line ends korrigiert?)
1 | diff -qrb nios-gnupro-src-3.1/src/ nios-gnupro-src-3.2/src/ | grep ".c differ" |
2 | diff -qrb nios-gnupro-src-3.1/src/ nios-gnupro-src-3.2/src/ | grep ".h differ" |
Ergebnis: Außer den Versionsbezeichnungen habe ich im Quelltext nur eine einzige Änderung gefunden, ich glaube zum Schlechteren, sieht mir wie ein Versehen aus: In gcc/gcc.c Zeile 848 ist ein Backslash am Zeilenende verschwunden. Vermutlich sind wir mit der gewohnten Version 3.1 besser dran. Jörg
Jörg H. schrieb: > (Björn, wie hast du denn vermutlich > automatisiert die line ends korrigiert?) Naja, vermutlich einfach mit "fromdos". Gruß, Guido
Hayo W. schrieb: > Bist Du auch ein WELEC-DSO Besitzer oder einfach ein Interessierter? Ich habe seit kurzem ein W2024A hier stehen. Dank Eurer Arbeit ist das Teil für meine Zwecke im Moment absolut ausreichend. Vielen Dank an alle, die die Firmware soweit gebracht haben. Was Ihr hier mit der neuen Firmware anfangt, sieht ja auch schon sehr fein aus. Die Möglichkeit (und wenn aus Zeitgründen auch nur theoretisch) an dem Teil "schrauben" zu können war dann auch einer der Gründe es anzuschaffen. Jörg H. schrieb: > (Björn, wie hast du denn vermutlich > automatisiert die line ends korrigiert?) Tar entpackt, src mit zip wieder komprimiert und dann mit unzip -a wieder entpackt. Ging bei den vielen kleinen Dateien schneller als find + fromdos. Jörg H. schrieb: > Vermutlich sind wir mit der gewohnten Version 3.1 besser dran. Ja, vermutlich. Das war dann also mal effizient Zeit verschwendet :-) Kann mir jemand sagen, wo der Source für die aktuell verwendete Cygwin nios-gnupro zu finden ist? Die Versionsnummer ist die 2.9-nios-010801-20030718, was zwischen der cdk4nios 3.1 (2.9-nios-010801-20030923) und 3.01 (2.9-nios-010801-20030320) liegt. Grüße, Björn
Hayo W. schrieb: > Todo: > > - die Delays sind zurzeit noch nicht mit Timer realisiert. Man muß mal > sehen ob das noch umgestellt werden muß > > - es gibt nur Grundfunktionen. Spezialisiertere Funktionen werden wir > wohl außerhalb der Treiberschicht implementieren denke ich. Wenn noch > eine entscheidende Funktionalität fehlt bitte ich um Info. > > - falls Dir moch weiteres Optimierungspotential auffällt (soll heißen > wenn ich irgendwo einen Bock geschossen habe) immer raus damit. Ich habe jetzt eine revidierte Version eingecheckt. Sie ist noch völlig ungetestet, da komme ich vielleicht heute abend zu. Björn F. schrieb: > Ja, vermutlich. Das war dann also mal effizient Zeit verschwendet :-) Finde ich nicht, es ist doch sehr beruhigend, wenn man prinzipiell den Compiler übersetzen kann. Hast du dir die Differenz in gcc.c mal angesehen? Ferner habe ich (unter gcc/config/nios/abi) eine Beschreibung der Calling Convention gefunden. Bisher konnte ich bei meinen (wenigen) Assemblerfunktionen nur raten, welche Register ich erhalten muß. > Kann mir jemand sagen, wo der Source für die aktuell verwendete Cygwin > nios-gnupro zu finden ist? Die Versionsnummer ist die > 2.9-nios-010801-20030718, was zwischen der cdk4nios 3.1 > (2.9-nios-010801-20030923) und 3.01 (2.9-nios-010801-20030320) liegt. Ich leider nicht... Jörg
Mal was ganz anderes, um nach kleinen Details wieder auf das große Ganze zu blicken: Ich mache mir schon länger im Hintergrund Gedanken, wie wir denn in die Applikation Grund rein kriegen, ohne daß es wieder so ein Verhau mit ganz vielen globalen Variablen wird. Na gut, so hätten wir das diesmal nicht gemacht, aber verallgemeinert: ohne eine große Menge Zustände, auf die an verschiedensten Stellen zugegriffen werden muß. Oder gar an verschiedenen Orten verändert, mit allen möglichen Konsequenzen der Aktualisierung. Angefangen hat mein Gedankenweg bei der Statusleiste, die ich langsam brauche. Wenn ich an den Kanalempfindlichkeiten drehe, sollen sich die Werte ja dort wiederfinden. Dazu müßte man im Code der die Drehregler behandelt Funktionen der Statusleiste aufrufen, daß die sich aktualisiert. Dabei will der Drehregler doch eigentlich keine Abhängigkeit zur Statusleiste haben, den interessiert ja gar nicht was die darstellen will und was nicht. Ähnliches findet man bei weiterem Nachdenken allerorten: über die serielle Kommandoschnittstelle wollen wir auch mal Parameter einstellen können, Änderungen sollen im Flash landen, etc. Ergebnis ist wieder das Gespinst, in dem jeder Zugriff auf alles braucht und alles ändern kann. Vor ein paar Tagen ist der Knoten in meinem Kopf geplatzt, nach etwas Recherche erkenne ich das uns eine "klassische" Model-View-Controller" Architektur die Sache entwirren würde. Siehe z.B. hier, Wikipedia fand ich ausnahmsweise nicht so hilfreich: http://msdn.microsoft.com/en-us/library/ff649643.aspx (Die Web-spezifischen Details bitte überlesen.) Es gibt aber noch unzählige weitere Literatur. Das Modell enthält die eigentliche Mimik, aber keine Darstellung und keine Bedienung. Der View ist die Darstellung der Zustände des Modells. Der Controller steuert das Model, und stößt ggf. Aktualisierung des Views an. Das Modell ist in unserem Fall die eigentliche Meß-Maschine des Oszilloskops. Sie enthält die ganzen Zustände wie Kanaleinstellungen, Zeitbasis, Trigger, und ist im Prinzip unabhängig lauffähig, wenn auch erstmal "blind und taub". Views haben wir mehrere: Die Wellendarstellung incl. Offsets und Triggerleveln ist natürlich einer. Mitunter gibt es eine zweite Darstellung, wenn man herumzoomt, das könnte vielleicht ein zweiter View sein, falls zweckmäßig. In der Statusleiste sehe ich einen weiteren, die könnte man auf diese Weise unabhängig halten. Bei näherem Nachdenken ist auch das Flash einer, denn es empfängt auch Zustandsänderungen. Es zeigt sie zwar nicht an, aber speichert sie. Controller haben wir auch mehrere: Als erstes natürlich die Gesamtheit der Regler und Knöpfe, in Kombination mit dem zu schaffenden Menüsystem. Ein weiterer ist die serielle Kommandoschnittstelle. Ein dritter ist das Flash während der Startphase, es hat dann die aktive Rolle, stellt die gespeicherten Einstellungen wieder her. Wir haben die aktive Variante von MVC, d.h. nicht (nur) der Controller stößt eine Aktualisierung der Views an, sondern vor allem auch das Modell. Dazu wird das Observer-Pattern erwähnt, genau das schwebte mir auch vor: Die Views melden sich beim Modell als Beobachter an, um in Folge von ihm benachrichtigt zu werden. Im Detail können sie noch angeben, für welche Arten von Ereignissen sie sich interessieren. Diese Konzepte kommen aus der objektorientierten Welt. In C sollte sich das mit ein paar Funktionszeigern aber auch hinkriegen lassen. Ich hoffe, so kriegt man das beherrschbar. Mir fallen gute Nebeneffekte ein. Die Kommandoschnittstelle kann z.B. völlig gleichberechtigt agieren, das macht für das Oszi keinen Unterschied. Kann/mag mir jemand folgen? Jörg
> Ich habe jetzt eine revidierte Version eingecheckt. Sie ist noch völlig > ungetestet, da komme ich vielleicht heute abend zu. Alles klar, ich hab noch einige kleine Scheinheitskorrekturen an der Namensgebung gemacht und eingecheckt. Sieht soweit ganz gut aus. Allerdings bin ich mir nicht so sicher ob beim Byte-Verify die Timerfunktion etwas "träge" ist und unter Umständen das Ganze etwas verlangsamt. Hast Du schon eine Test-Suite für den Flash-Zugriff? > Kann/mag mir jemand folgen? Jup, das Konzept gefällt mir. Ich werde mich mal etwas genauer in die Theorie des Model View Controllers einlesen. Grundsätzlich hört sich das sehr gut an, wir müssen aber mal sehen wie sich das performanceseitig auswirkt. Gruß Hayo
Jörg: Ich vermute auch das die Performance darunter leidet, wenn die Beobachter sich anmelden und extra mit Daten versorgt werden müssen. Ich würde jedem Beobachter eine änderbare Priorität geben, wann er sich die benötigten Daten aus einem zentralem Datenspeicher holen darf.
Thomas O. schrieb: > Jörg: Ich vermute auch das die Performance darunter leidet, wenn die > Beobachter sich anmelden und extra mit Daten versorgt werden müssen. Ich meinte nur den Kontrollfluß, nennenswerte Daten werden da nicht bewegt. Da ist es meiner Erfahrung nach völlig unerheblich, ob. z.B. ein Tastendruck 3 Funktionsaufrufe auslöst oder eine Kaskade von 10 Aufrufen, ob ein Aufruf hart codiert passiert oder über einen Funktionspointer. Pointer darf man ja weiterhin verwenden. ;-) Ich bin ein großer Freund von performantem Code, habt ihr wahrscheinlich schon gemerkt. Aber im Kontrollpfad geht eine saubere Architektur eindeutig vor. Ein berühmtes Softwarezitat: "Premature optimization is the root of all evil". http://en.wikipedia.org/wiki/Program_optimization#When_to_optimize > Ich > würde jedem Beobachter eine änderbare Priorität geben, wann er sich die > benötigten Daten aus einem zentralem Datenspeicher holen darf. Das habe ich nicht verstanden. Wieso Priorität? Die Benachrichtigungen müssen doch eh verteilt werden. Kleinere Daten kann man da z.B. gleich mitgeben, größere kann sich der View in Reaktion abholen. Thomas, hast du da Erfahrungen mit einem ähnlichen oder anderen Modell? (Ich will hier keinesfalls irgendwas abbügeln.) Jörg
nein habe keine Erfahrung mit solchen Modellen, meinte nur das es nicht nötig ist irgendwelche Benachrichtigungen durch die Gegend zu schicken, sondern lieber irgendwo ein Bit zu setzen und einzelnen Routinen schauen dann im Pollinverfahren noch ob etwas interessantes für sie vorliegt. Wie oft dann eine Routine nachsieht könnte man dann noch mittels Zähler beeinflussen.
Hallo Miteinander! Ich hatte mir schon mal vor längerer Zeit auch einmal gedanken gemacht, wie man ein Oszilloskop am Saubersten aufbaut. Dass man die Signalerfassung, das Remote-Controll-System inklusive Screenshots, usw, und die Bedienung in einem Betriebssystem mit je unterschiedlichen Tasks (mindestens 3) bearbeiten muss, ist klar. Meiner Meinung lässt sich meiner Meinung nach die GUI hier schwierig von der Signalverarbeitung trennen. Das liegt schon daran, dass bei der Anzeige nur einmalig die Rohdaten skaliert werden sollten und mindestens drei verschiedene Offsets dazugerechnet werden müssen. Einige dieser Offsets sind Hardware gebunden, einige durch die Darstellung bestimmt. Als zweites kommt hinzu, dass man ab und zu mal vertikal und horizontal Zoomen möchte. Dabei sollte man dann auch wieder von den Rohmessdaten direkt wegrechnen, damit das nicht zu ungenau wird. Für die Darstellung braucht man dann zum Interpolieren, Filtern, Darstellung mit Punkten oder Strichen mit unterschiedlichen Stärken wieder direkt die Signalverarbeitung oder zumindest sowas ähnliches. Nicht vergessen, für das Interpolieren und Filtern verschiedene Arten verwenden. XY-Darstellung, Non Interleaved und auch Hayo`s Steckenpferd, den Ultra Slow Mode wären auch ganz nett. Da es bei einer Oszilloskop-Software sehr viel um die Darstellung und Bearbeitung der Signale dreht, sollte man sich einmal eine Liste machen, in der die Anforderungen an die Darstellung (Offsets, Skalierung, Beschriftung, Math-Funktionen, Kalibrierdaten, ...) beschrieben werden. Besonders wichtig wären einmal die Querbeinflussungen zu dokumentieren. Beispielfragen: Wann ist es besser, den Offset analog einzustellen, oder wann ist es besser den Offset digital zu machen. Dazu stellt sich noch die Frage, wie und wo man dann die Kalibrierwerte speichert... Wo macht man die genaue Trennung zwischen der Signalverarbeitung für den Bildschirm oder der Signalverarbeitung für das Remote Interface... Dürfen die Cursor und Measure Werte durch die Bildschirmskalierung bedingt ungenau sein, oder nimmt man auch hier die wieder die Rohdaten zur Auswertung... Meiner Meinung nach macht es Sinn sich sowas vor der Auftrennung in die verschiedenen Software-Layer zu überlegen. Alexander
Hayo W. schrieb: > Hast Du schon eine Test-Suite für den Flash-Zugriff? Jetzt ja, siehe mein Commit. Apropos: Hayo, magst du beim Einchecken englische Kommentare verwenden? Passt besser zum Code. ;-) Der Treiber scheint zu funktionieren. Erste Zahlen: sector erase took 12024502 cycles byte write took 299 cycles word write took 963 cycles sector write took 13989317 cycles Morgen optimiere ich noch ein bischen dran rum. (root of all evil...) Zur Architektur später mehr. Jörg
Warte mal mit dem Optimieren, ich habe noch einige Änderungen die ich noch eincheckken möchte. Es wird Dir gefallen. Die kannst Du dann gleich mit optimieren. Hayo
Hab's gerade gesehen (das Busy-Signal ist offenbar verdrahtet), als ich selber meine Optimierungen einchecken wollte... Nun merge ich erstmal... Jörg
Sector Erase braucht jetzt nur noch die halbe Zeit! -> nicht vergessen FlashInit() in die main mit einzubauen! Hayo
Hayo W. schrieb: > Sector Erase braucht jetzt nur noch die halbe Zeit! Hatte es bei mir auch... Man braucht nämlich nicht den ganzen Sektor auszulesen. Der interne Löschalgorithmus ist durch, wenn ein beliebiges Byte 0xFF geworden ist. Und mein gestriger Fehler: erst recht braucht man nicht für jedes akkurat gelöschte Byte auf die Uhr schauen. Ich habe jetzt die Methode "Status aus Chip auslesen" und "externes Busy-Signal prüfen" ausgiebig verglichen. Ergebnis: das externe Signal ist langsamer, mitunter drastisch(?), und ich habe es sogar beim Prellen "erwischt". In Konsequenz habe ich das wieder ausgebaut. Wir müssen dem nicht nachtrauern. Ist höchstens dann von Vorteil, wenn es einen Interrupt auslösen kann (im Nios-Design nicht der Fall) und wir ein Multitasking-RTOS hätten, was in der Zwischenzeit andere Tasks dranlassen kann. Jörg
Schade :-( sah irgendwie geschmeidig aus. Aber wenn das Auslesen eines beliebigen Bytes reicht und zuverlässiger ist, dann nehmen wir das lieber. Gruß Hayo
Hallo, ich habe mich nach langem hin und her dazu überwunden, dass ich mit dem Reference Manual für das LEON3 FPGA-Design anfange, welches nicht zufällig Ähnlichkeiten mit einem Microcontroller Datenblatt aufweist. Abbildungen zur besseren Verständlichkeit sind noch keine drinnen, folgen irgendwann später einmal. Alexander
Danke Alex! (Ich bin jetzt nicht so überrascht, habe es ja auch schon reviewen dürfen.) Das Leon-Design sucht noch einen Betreuer, vorher fange ich damit nicht an. In diesen Tagen geht es langsamer voran, ich habe gerade vorübergehend nur wenig Zeit für Osoz, es sind noch ein paar andere Dinge zu tun. Nochmal wieder zur Architektur: Alex, was du vor ein paar Tagen schriebst liest sich m.E. doch auch sehr nach dem, was ich als Model-View-Controller beschrieb. Wenn Signalverarbeitung und Darstellung so verzahnt sind, dann gehört das beides zum View, der Controller sollte Rohdaten liefern, aber auch die Informationen wie die ggf. zu kompensieren sind. Vielleicht ist auch eine zwischengeschaltete Filterstufe sinnvoll, für die ganz allgemeinen Sachen. Offsets sind in der bisherigen Software rein analog, eine (Y-) Softwareskalierung gibt es auch nicht. Und ein ganz anderes Thema: Beim Flash-Test hatte ich mit Osoz ein "Problem" was auch schon früher mal auftrat: Manchmal ist RS232 vom Start weg einfach "kaputt", es kommt nur Unsinn raus, es hilft nur Reset und Software nochmal ramloaden. Gefühlt bei jedem 3. Start oder so, wenn man besonders interessiert draufschaut nach Murphy noch öfter. Mein Flash-Test hat nur einmal kurz was ausgegeben, daher habe ich ein anderes kleines Testprogramm geschrieben und meinen Logic Analyzer an RS232 angeschlossen, um zu messen ob das Timing durcheinander ist. Nun tritt das Problem gar nicht mehr auf... Murphy wirkt stark. Hayo, hattest du auch schon mal Auffälligkeiten mit der seriellen? Wo der LA grad dran hängt habe ich die Auslastung der RS232 beim Firmware-Upload gemessen. Da geht noch was, zwischen den S-Record-Zeilen macht der Upload Pausen, vermutlich wegen seiner Ausgabe. Mit Multithreading könnte man das noch ca. 15-20% schneller kriegen. Ich hab's aber nicht so mit Perl. So long, Jörg
Hmmh, liegt ev. das Übersprechproblem garnicht an Kurts Platine sondern am Welec? Dass es mit LA nicht auftritt macht mich stutzig.
vielleicht Reflektionen die mit der geringen Last des LA schon verhindert werden, ist es mit einer längeren Leitung besser oder eher schlechter?
Ich glaube nicht das es ein elektrisches Problem ist, vermutlich kriege ich die Softwaresituation halt nicht nachgestellt. Mit dem LA bin ich hinter dem Pegelwandler auf dem Welec, da ist es eine Punkt-zu-Punkt Verbindung zum FPGA. Kurt hatte (meine ich) eine Leitung auf seiner Platine einfach offen gelassen. Jörg
Jörg H. schrieb: > Wo der LA grad dran hängt habe ich die Auslastung der RS232 beim > Firmware-Upload gemessen. Da geht noch was, zwischen den S-Record-Zeilen > macht der Upload Pausen, vermutlich wegen seiner Ausgabe. Mit > Multithreading könnte man das noch ca. 15-20% schneller kriegen. Ich > hab's aber nicht so mit Perl. Das galt dann wohl mir. :-) Ich schau mir das gelegentlich mal an (wenn sich nicht vorher einer findet)...
Jörg H. schrieb: > Ich > hab's aber nicht so mit Perl. > > So long, > Jörg Hallo Jörg, ich habe dieses Perl-Zeugs noch nie(!) verwendet! Mit einem ordentlichen Terminalprogramm läuft es ebenso. Allerdings nur über eine richtige serielle Schnittstelle oder über einen guten USB-Seriell Konverter(FTDI). Das gilt ebenso für Linux oder Windows-XP. Das ist also kein Grund :-) Gruß Jürgen
Hallo Jörg, ich bin seither zwar nur stiller Mitleser, aber da ich mich mit Perl einigermaßen auskenne, habe ich das Perlskript mal leicht modifiziert, um die Performance der seriellen Schnittstelle besser messen zu können. Ergebnis bei mir beim Auslesen der Firmware: ~112,2 kbps (WinXP, USB-Seriell-Konverter). Damit sind wir schon ziemlich am theoretischen Maximum von 115,2 kbps => eine Performance-Steigerung um 15-20% ist (zumindest bei mir) somit also nicht mehr möglich. Das geänderte Perlskript benutzt jetzt übrigens eine deutlich höher aufgelöste Zeit und rechnet mit Float-Werten => die Zeitangaben sind auch am Anfang schon ziemlich stabil und springen nicht mehr so wild hin und her. Bei dieser Gelegenheit möchte ich den ganzen Entwicklern und Testern mal herzlich für die super Arbeit danken. Ihr habt mein W2024 überhaupt erst sinnvoll verwendbar gemacht. Gruß, Daniel
Dein Script kann ich nicht downloaden, vielleicht hat die Forumssoftware was gegen Perl-Attachments, hält die gleich für CGI-Scripte etc.? Hättest du das vielleicht in einem .zip? Lesen habe ich nicht getestet, schreiben finde ich relevant. ;-) Vielleicht erledigt dein Rechner die Ausgabe viel schneller als meine Möhre. Besonders drastisch gebremst wird das Script, wenn ich es unter Eclipse laufen lasse, der sich die Ausgabe abgreift (habe ich noch nicht mit LA gemessen). Ich denke, da kann es nur dann ungebremst schnell werden, wenn man das RS232-Protokoll in einen Thread auslagert. Dann kann die Ausgabe während der I/O-Wartezeit nebenherlaufen. Ferner muß man ja auch nicht nach jeder S-Record-Zeile was kundtun, einmal pro Sekunde reicht ja auch. Das "klassische" Script vertut sich am Anfang ziemlich, weil die Zeilen mit den Flash-Löschbefehlen so viel langsamer laufen als der Rest. Noch eine Beobachtung an der Stelle: bei diesen Löschzeilen läßt es sich auch besonders viel Zeit. Nach dem Bestätigungs-"X" passiert erstmal 100ms lang nichts, bis die nächste Zeile gesendet wird. Die Lücken zwischen den normalen Datenzeilen sind bei mir unterschiedlich, von <1ms bis 6ms. (vergleiche Übertragungszeit der Zeile: 4,9ms) Jörg
Jörg H. schrieb: > Besonders drastisch gebremst wird das Script, wenn ich es unter Eclipse > laufen lasse, der sich die Ausgabe abgreift (habe ich noch nicht mit LA > gemessen). Hast du denn mal spaßeshalber die Ausgabe auskommentiert und geschaut, ob es dann Vollgas gibt oder das Ganze doch an irgendeiner anderen Komponente bei dir liegt?
Johannes S. schrieb: > Hast du denn mal spaßeshalber die Ausgabe auskommentiert und geschaut, > ob es dann Vollgas gibt oder das Ganze doch an irgendeiner anderen > Komponente bei dir liegt? Das war wohl zu naheliegend als das ich drauf käme... Aber wenn die Ausgabe in der gleichen Schleife passiert, dann muß sie ja bremsen. Habe ich nun gemacht. Die Lücken zwischen den Paketen sind deutlich kleiner, wenn auch nicht "nahtlos". Ich habe ab und an trotzdem noch größere Lücken, das liegt wohl an der Auslastung durch den LA, eine "USBee". Den (oder den Upload) muß ich mal auf einem separaten Rechner laufen lassen. Soo eine große Welle wollte ich aus dem Thema gar nicht machen. Nur mal aufzeigen, daß da noch was geht. Man könnte auch mal ausprobieren, längere S-Records zu schicken, dann sinkt der Overhead. Ferner kann man die Übertragung vielleicht sogar ineinander verschränken, noch bevor die Bestätigung kommt bereits mit der nächsten Zeile anfangen. Weil die GERMS Monitor Implementation vermutlich nicht mit Interrupts und Empfangspuffer arbeitet, sondern der Einfachheit halber pollt, geht vielleicht nur ein Zeichen Verschränkung, z.B. das 'X' nicht abwarten. @Daniel: Das Perl-Download-Problem bestand wohl nur bei mir. Ich habe die Datei nun von André bekommen (aber noch nicht ausprobiert). Jörg
Ich liebe Performancemessungen... :o) Also hier der Vergleich vorher nachher: System: AMD X2 3GHz - echter RS232 Port unter Linux. Testsuite: Flashen der aktuellen BF-Version. Ergebnis: Altes Script 164s Neues Script 164.2s Das sieht mir nicht so großartig unterschiedlich aus. Die Ausgabe ist aber tatsächlich ruhiger. Ich übernehme also die neue Version mal. Gruß Hayo
So hab mal die Textausgabe ausgeknipst. Ergebnis 161.8s - das scheint also tatsächlich für die nicht ganz ausgereizte Performance verantwortlich zu sein. Hayo
Hayo W. schrieb: > Das sieht mir nicht so großartig unterschiedlich aus. Die Ausgabe ist > aber tatsächlich ruhiger. Ich übernehme also die neue Version mal. Da hatte ich aber irgendwann noch eine klitzekleine Änderung dran gemacht, wo ich mich gar nicht mehr erinnern kann, warum. Hatte sicher was mit der Erkennung des Upload-Endes zu tun, aber auf jeden Fall war das nicht Grundlage der Änderung von Daniel. Ich führe das mal zeitnah zusammen und schau, dass ich die Ausgabe in einen anderen Thread ausgelagert bekomme.
Johannes S. schrieb: > Da hatte ich aber irgendwann noch eine klitzekleine Änderung dran > gemacht, wo ich mich gar nicht mehr erinnern kann, warum. Hatte sicher > was mit der Erkennung des Upload-Endes zu tun, aber auf jeden Fall war > das nicht Grundlage der Änderung von Daniel. Das war hier: Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware" Diese kleine Änderung habe ich jetzt mit Daniels Anpassung zusammengeführt, siehe Anhang. Jetzt werde ich mir mal die Ausgabe in einem getrennten Thread zu Gemüte führen.
Ich habe mich rangetastet, wie lange S-Record-Zeilen der GERMS Monitor vertragen kann. Ergebnis: 89 Byte. Bisher wurden immer nur 21 Byte pro Zeile übertragen. Hayo, wenn du die offiziellen Meßwerte nimmst, dann probier' diese TomCat.ram mal aus. Sie enthält deine Version 5.2C2, ist aber wegen des geringeren Zeilenoverheads gut 20% kleiner. Sollte auch entsprechend schneller laden. Wie ich die erzeugt habe: "srec_cat -Output test.hex -Motorola -Line_Length 192 TomCat.ram" srec_cat ist ein Tool aus dem Paket "srecord". Unter Linux mit der Paketverwaltung der Wahl zu installieren, gibt es auch für Windows: http://sourceforge.net/projects/srecord/files/ So ganz perfekt arbeitet es nicht, erzeugt alle 1,5kB ein Alignment und dann kürzere Zeilen. Wir könnten so ein Tool zur S-Record Nachbearbeitung mit in den Makeflow einbauen, oder das Perl-Script müßte die Daten parsen und zu längeren Zeilen zusammenstellen. Jörg
Haach, das überschneidet sich alles wieder :) Ich habe jetzt kein Scope hier, darum kann ich überhaupt nix testen, aber ich habe mal einen ersten threaded Versuch des Perlscripts angehängt. Vielleicht kann das mal einer ausprobieren?
Jörg H. schrieb: > Wir könnten so ein Tool zur S-Record Nachbearbeitung mit in den Makeflow > einbauen, oder das Perl-Script müßte die Daten parsen und zu längeren > Zeilen zusammenstellen. Erklär mir, was da wie passieren muss, und es wird eingebaut. Das Verarbeiten von Text ist ja gerade die Domäne von Perl.
Das lange Zeilenformat ist etwas problematisch. Einmal hat der Upload geklappt. Danach hatte ich nur noch Abbrüche, immer bei Zeile 3, also der ersten langen Zeile. Hayo
@Hayo: kannst du bitte mal mit dem ursprünglichen Format den letzten Skript-Upload testen? Geht das Ding, und wenn ja, wie schnell (verglichen mit dem alten Skript)?
So und noch ein Vergleich. Um die Scripte mit einander vergleichen zu können hab ich nochmal einen RAM-Upload mit der aktuellen BF-Version (mit kurzen Zeilen) gemacht. -> alte Version 157s -> Daniels Version 157,7s -> Johannes threaded Version 157,8s Die threaded Version hat zudem auch noch ein Problem mit dem Linefeed, es werden die ganze Zeit neue Zeilen erzeugt. So viel läßt sich da wohl nicht mehr rausquetschen. Die ein oder zwei Sekunden kann ich aber auch locker aussitzen. Wenn ich da an die Anfänge denke als ich noch 20 Min auf jeden Upload gewartet habe... Hayo
Ich habe die Ausgabe des Threaded-Scripts noch etwas korrigiert, es landete nicht alles im Thread. Mit den langen Zeilen hat es Probleme. Merkwürdig, das Script hat doch keine Limitierung, oder? Vielleicht war es Zufall, ist generell instabil. Probiere ich nochmal aus, wenn ich mehr Zeit habe. So richtig schnell würden wir die Sache kriegen, wenn wir im GERMS-Format nur einen kleinen Dekompressor schicken und starten, der dann das eigentliche Image binär und komprimiert über die RS232 entgegennimmt. Ich habe sowas schonmal gemacht, der Dekompressor (UCL) war ca. 800 Byte groß, schnell, und effizienter als .zip. Das würde die zu übertragenden Daten auf ca. 1/10 reduzieren. Jörg
@Jörg: könnest du dir das nochmal mit dem LA anschauen? Ich vermute, dass die Perl-Thread-Mimik (also das Übergeben der Ausgabezeile in den anderen Thread) einfach genauso lahm ist wie die direkte Ausgabe, was es mit reinem Perl dann also etwas umständlicher machen würde, noch Beschleunigung rauszuholen. Achso, und ja, ich hab da leider noch ein paar Stellen vergessen, die innerhalb der Schleifen eine Ausgabe erzeugt haben, aber die Ausgaben am Ende sind sicher eher nicht tempo-relevant. Hast du die nur der guten Ordnung halber auch in den Thread verlegt? ;-)
Und das Vergleichsergebnis mit Jörgs modifizierter threaded Version: -> 159,6s Es wird irgendwie nicht besser. Mir scheint die Kompressormethode tatsächlich die einzige Möglichkeit zu sein dass ernsthaft zu beschleunigen. Hayo
Ich vermute die Thread-Aufteilung ist noch ungünstig. Die Schleife schreibt ja nicht nur auf RS232, sondern kümmert sich auch und das Dateilesen, Parsing, Übergabe der Ausgabestrings, halt alles außer nun die Ausgabe selbst. "Idealerweise" macht der eine Thread nur die Datenpumpe. Nun denn. Vorwärtsblickend in Richtung Kompression: Johannes, kannst du das Skript vielleicht folgendermaßen weiterentwickeln: Wenn eine Zeile mit einem Spezial-Steuerbefehl kommt (irgendein Anfangsbuchstabe den der GERMSloader noch nicht verwendet), dann schaltest du in einen zu schaffenden Binärmodus? Um die Eingangsdaten weiterhin als ASCII zu halten würde ich sagen, da kommen weiterhin S-Records, aber du müßtest die Binärdaten da rauspuhlen und senden. Das ganze so lange, bis der Spezialbefehl wieder zurückschaltet. Z.B. B1 für binär an, B0 für binär aus. Ggf. vielen Dank! Jörg
Jörg H. schrieb: > Ich vermute die Thread-Aufteilung ist noch ungünstig. Die Schleife > schreibt ja nicht nur auf RS232, sondern kümmert sich auch und das > Dateilesen, Parsing, Übergabe der Ausgabestrings, halt alles außer nun > die Ausgabe selbst. "Idealerweise" macht der eine Thread nur die > Datenpumpe. War ja nur ein erster Schnellschuss. Ich werd mal schauen, wo das Skript welche Zeit vertrödelt, dann stell ich das entsprechend um. > Nun denn. Vorwärtsblickend in Richtung Kompression: Johannes, kannst du > das Skript vielleicht folgendermaßen weiterentwickeln: > Wenn eine Zeile mit einem Spezial-Steuerbefehl kommt (irgendein > Anfangsbuchstabe den der GERMSloader noch nicht verwendet), dann > schaltest du in einen zu schaffenden Binärmodus? Klar. Ist das so geplant, dass das Gegenstück im Scope beides versteht und mittels des neuen Befehls seinerseits erst in den Binärmodus geschaltet wird? Bzw., zumindestens sollte der neue Loader im Scope anders prompten, damit ich erkennen kann, dass ich da in die richtige Senke hineinschaue. > Um die Eingangsdaten weiterhin als ASCII zu halten würde ich sagen, da > kommen weiterhin S-Records, aber du müßtest die Binärdaten da rauspuhlen > und senden. > Das ganze so lange, bis der Spezialbefehl wieder zurückschaltet. > Z.B. B1 für binär an, B0 für binär aus. Ok. Gib mir mal - falls du das schon hast - ein Stück Firmware mit so einem Dekompressor (bzw. ein Win- oder Linuxbinary, ich finde hoffentlich noch einen alten Rechner mit serieller Schnittstelle, der mir das Scope emuliert), um das dann auch zu testen. /Hannes
Johannes S. schrieb: > Ist das so geplant, dass das Gegenstück im Scope beides versteht > und mittels des neuen Befehls seinerseits erst in den Binärmodus > geschaltet wird? Nein, nicht ganz. Auf den GERMSloader haben wir keinen Einfluß, deshalb müssen wir "klassisch" anfangen. Ich würde dann aber "nur" einen möglichst kleinen Loader voranstellen, der binär und Dekompression kann. Der wird als S-Record geladen und gestartet. Das Perl-Script macht derweil weiter und schickt ihm die Binärdaten. > Bzw., zumindestens sollte der neue Loader im Scope > anders prompten, damit ich erkennen kann, dass ich da in die richtige > Senke hineinschaue. Das stelle ich mir "on the fly" vor, da wird gar nicht gepromptet. Du schickst einfach weiter Daten. Wenn's Probleme gibt müssen wir da eine kleine Pause oder eine Startbestätigung des Loaders einfügen, zugegeben. > Ok. Gib mir mal - falls du das schon hast - ein Stück Firmware mit so > einem Dekompressor (bzw. ein Win- oder Linuxbinary, ich finde > hoffentlich noch einen alten Rechner mit serieller Schnittstelle, der > mir das Scope emuliert), um das dann auch zu testen. Da kriegen wir jetzt ein Henne-Ei Problem? Ich kann meinen Loader ohne deinen Binärmodus nicht gut testen. Da müßte ich mit einem Mischbetrieb aus Script und vielleicht Terminalprogramm probieren, als Binär hinterhersenden. Mir ist nicht ganz klar, was du genau testen willst. Den Binärmodus kannst du vielleicht mit ein paar Test-Ausschriften in Betrieb nehmen? Jörg
Ich habe ein wenig mit den Sourcen gespielt. Um sowohl BlueFlash, als auch die Anfänge von OSOZ besser zu verstehen, habe ich damit begonnen, BlueFlash auf die Osoz Platform zu "portieren". Über den Sinn der Übung kann man sicher streiten und bisher beschränkt sich das ganze auch auf die Display und Flash Teile. Die funktionieren allerdings soweit problemlos, Dabei bin ich über einen kleinen Bug in der text.c gestolpert. string ist ein const char *, ch ist uint32_t. Ohne einen unsigned cast geht das für Zeichen >127 schief. Siehe Patch. Gruß, Björn
Jörg H. schrieb: > Der wird als S-Record geladen und gestartet. Das Perl-Script macht > derweil weiter und schickt ihm die Binärdaten. Einfach so, ohne Punkt und Komma? Ok. :-) > Das stelle ich mir "on the fly" vor, da wird gar nicht gepromptet. Du > schickst einfach weiter Daten. Wenn's Probleme gibt müssen wir da eine > kleine Pause oder eine Startbestätigung des Loaders einfügen, zugegeben. Jo, das wäre genau das, was ich mir vorgestellt hatte, aber ich bin ganz offensichtlich nicht ansatzweise so sehr auf Performance getrimmt wie du, ich geh lieber dreimal sicher als einmal zu schnell. > Mir ist nicht ganz klar, was du genau testen willst. Den Binärmodus > kannst du vielleicht mit ein paar Test-Ausschriften in Betrieb nehmen? Ich wollt nur sehen, ob das, was ich da treibe, auch klappt. Bin gar nicht auf die Idee gekommen, dass dir das genauso geht. :-) Also, ich werd dann mal den Binärmodus da reinbasteln und dann sehen wir weiter. /Hannes
Björn F. schrieb: > Ich habe ein wenig mit den Sourcen gespielt. Um sowohl BlueFlash, als > auch die Anfänge von OSOZ besser zu verstehen, habe ich damit begonnen, > BlueFlash auf die Osoz Platform zu "portieren". Über den Sinn der Übung > kann man sicher streiten und bisher beschränkt sich das ganze auch auf > die Display und Flash Teile. Die funktionieren allerdings soweit > problemlos, Sehr schön daß du dich damit beschäftigst! (Ich hoffe allerdings inständig die Portierung bleibt eine Übung...) Da haben wir schon noch Besseres vor. Der Capture-Treiber steht noch aus, dessen bin ich mir sehr bewußt. Aus bestimmten Gründen habe ich mit dem noch nicht weitergemacht, kommt aber. Dann kann es mit der Applikation so richtig losgehen. > Dabei bin ich über einen kleinen Bug in der text.c gestolpert. string > ist ein const char *, ch ist uint32_t. Ohne einen unsigned cast geht das > für Zeichen >127 schief. Siehe Patch. Vielen Dank! Werde ich mir anschauen und korrigieren. Jörg
Ein freundliches Hallo an die Gemeinschaft der Wittig/Welec Oszilloskop W2022A Begeisterten. Da ich neu im Forum bin stelle ich mich kurz mal vor. Rufname Monty, 34 Jahre alt und in der Elektronikwelt tätig. Ich habe mit großem Interesse die Ideen und die Umsetzung zum Thema W2022A verfolgt und bin seit ca. 1/2 Jahr auch Besitzer eines dieser Geräte. Auf der Suche nach einem gut bedienbarem Oszi, bekam ich mal die Gelegenheit eines zu testen und zu benutzen und so bin ich nach kurzer Überlegung einem Kaufangebot gefolgt. Die Firmwareumrüstung war mit einigen Hindernissen verbunden, aber ein gut informierter Kollege konnte mir da erfolgreich zur Hand gehen, bzw. er hat die Umrüstung erfolgreich gemeistert. Die letzte verfügbare Version ist vorhanden und lässt sich auch bedienen, jedoch plagen mein Oszi ein wenig andere Probleme. Beide Kanäle sind tot, also um es ganz einfach auszudrücken ich sehe auf dem Display kein Eingangssignal. Ich habe schon mal den Kontakt zu einigen W2022A Nutzern gesucht, aber hier konnte mir auch nicht geholfen werden und so hoffe ich bei euch Rat zu finden. Ich denke mal ich schlage mich da mit einem Hardwareproblem rum, vielleicht es ja auch nix Wildes, aber ich suche dringend nach einer Lösung. Hat sich jemand schon mal der Hardware angenommen und eventuell schon mal diesen Defekt vorleigen gehabt? Großartiges Messen ohne Stromlaufplan gestaltet sich schwierig, so hätte ich zumindest mal die Möglichkeit dem angelegten Eingangssignal zu folgen, aber wild und ohne Plan die Bauteile gegenzuprüfen könnte ein langes Projekt werden.Gibt es verfügbare Stromlaufpläne die man erwerben könnte, oder noch besser gibt es unter den Forumsmitgliedern versierte Fachleute die meine Hardware wieder funktionsfähig bekommen würden? Meine Ideen sind momentan ein wenig begrenzt, vielleicht sind die A/D Wandler tot oder ein anderes Bauteil hat sich verabschiedet. Ich kann leider nur Überlegungen dazu anstellen und komme aber auf keinen grünen Zweig. Kann mir da jemand auf die Sprünge helfen? Danke für Die Infos im Forum, ich werde weiterhin treuer Leser bleiben. Gruß Monty
@Monty, du bist hier etwas OT, in jenem Thread besser aufgehoben: Beitrag "Wittig(welec) DSO W20xxA Hardware" Grüße Jörg
Danke für die Info Jörg, ich stelle meine Anfrage in den richtigen Thread. Gruß Monty
Hayo W. schrieb: > Und das Vergleichsergebnis mit Jörgs modifizierter threaded Version: > > -> 159,6s > > Es wird irgendwie nicht besser. > > Mir scheint die Kompressormethode tatsächlich die einzige Möglichkeit zu > sein dass ernsthaft zu beschleunigen. Ich hätte hier ein nettes Vergleichsergebnis, mein Dekompressor läuft in erster Version: was haltet ihr von knapp 16 Sekunden? (!) Kein Tippfehler, könnt ihr selbst ausprobieren, siehe Anhang. Jörg H. schrieb: > So richtig schnell würden wir die Sache kriegen, wenn wir im > GERMS-Format nur einen kleinen Dekompressor schicken und starten, der > dann das eigentliche Image binär und komprimiert über die RS232 > entgegennimmt. > Ich habe sowas schonmal gemacht, der Dekompressor (UCL) war ca. 800 Byte > groß, schnell, und effizienter als .zip. > Das würde die zu übertragenden Daten auf ca. 1/10 reduzieren. Genau so habe ich es jetzt gemacht. Weil es den Binärmodus von Johannes noch nicht gibt habe ich die Ramloader-Scripte so modifiziert, daß die den Dekompressor klassisch mit dem Perl-Script hochladen, danach ein Binärfile stumpf auf die serielle kopieren. So haben wir zwar keine Fortschrittsanzeige und Erfolgsmeldung, aber es funktioniert erstmal. Kann vielleicht sogar so bleiben? Der Dekompressor ist knapp 2kB groß, wird selbst in einer knappen Sekunde hochgeladen. Ich habe ihn in C programmiert, da er doch recht komplex ist, in Assembler wäre das sehr aufwändig. Etwa 500 Byte an Code sind nicht von mir, sondern der C-Runtime. Ich habe sie schon sehr klein konfiguriert. Ein gewisser Overhead müßte auch in Assembler sein, da ich z.B. den seriellen Empfang mit Interrupts mache. Das ist für die Parallelität von ungebremster Übertragung und gleichzeitiger Dekompression nötig. Der nächste Schritt wäre, so einen Loader auch für's Flash zu machen (Dieser hier ist nur für Ramload). Er muß dann Sektoren löschen und das Flash gemäß dem Datenblatt-Algorithmus zu beschreiben. Der Download wird dann nicht so schnell gehen, weil das Flash selbst dann der Flaschenhals ist. Es ist leider nicht möglich, einen Sektor im Voraus zu löschen und parallel einen anderen zu beschreiben. Zurück zur Praxis, wie erzeugt man so ein .ucl-File mit den passend komprimierten Daten? Ich verwende den Algorithmus NRV-2e, weil er mit unseren Daten die höchste Kompression erreicht, siehe: http://www.oberhumer.com/opensource/ucl/ Man braucht erstmal ein Binärfile der Applikation, statt einem S-Record. Das geht im Makefile oder einzeln mit:
1 | nios-elf-objcopy -O binary obj/TomCat.out tomcat.bin |
Dann braucht man das Oberhumer-Tool "uclpack", Aufruf mit ein paar undokumentierten Optionen:
1 | uclpack --best --2e -b8000000 tomcat.bin tomcat.ucl |
(beste Kompression, Algorithmus 2e, alles in einen Block) Werde ich noch in den Buildflow einarbeiten, wenn sich das etabliert. So long Jörg
Ich schreib' mal wieder was, nicht das jemand denkt Osoz wäre eingeschlafen, mitnichten. Die letzten 2 Wochen habe ich mich dem Exkurs "wie kriegen wir zügig die Software in's Oszi" beschäftigt, mit denke ich recht gutem Erfolg. Mittlerweile gibt es das Verfahren auch für's Flash, und kaum langsamer. Als "Abfallprodukt" ist für Osoz eine schnellere Routine zum Schreiben in's Flash abgefallen. Der Trick ist, nach dem erfolgreichen Warten auf ein geschriebenes Byte möglichst schnell das Nächste anzufangen, keine Totzeit aufkommen zu lassen. Daher bereite ich nach dem Schreibbefehl das nächste Byte schonmal soweit wie möglich vor. Außerdem wird zu dem Zeitpunkt getestet, ob das Timeout des vorherigen Bytes überschritten wurde. Erst dann geht's in die Warteschleife. Der Effekt ist nicht soo doll wie ich dachte, einen 64K-Sektor flashen dauert nun etwa 0,7s statt vorher 0,9s, aber immerhin. Hat nun nach dem Einsatz im Flashloader auch Einzug in den Flashtreiber von Osoz gehalten. Ich habe lang und breit experimentiert, wie der Flashloader denn am Schnellsten arbeiten kann, wie man das am geschicktesten aufteilt. Er hat 4 Dinge zu tun: 1. Datenempfang (im Interrupt, daher schon mal nebenläufig) 2. Dekompression, wenn Eingangsdaten da sind 3. Sektoren löschen und Bytes flashen, wenn das Flash nicht busy ist 4. Prüfsumme der dekomprimierten Daten errechnen, soweit verfügbar Die Aufteilung zwischen 2/3/4 ist kniffliger als es sich anhört. Während das Flash gelöscht oder beschrieben wird kann ich anderswo nicht mal lesend drauf zugreifen. Ich dekomprimiere daher erstmal prinzipiell ins RAM, um da nicht limitiert zu sein. (Der Dekompressor braucht den Rückgriff auf bereits produzierte Daten, das ist gerade der Kern des Verfahrens.) Letztendlich mache ich nun die eigentliche Dekompression und Prüfsummenbildung für einen Sektor in der Zeit, die es braucht diesen Sektor zu löschen (ca. 0,5s). Auch das Warten auf Eingangsdaten passiert ggf. dort. Das paßt ganz gut, ich bin eine Idee langsamer, in der Regel ist der Sektor dann bereits gelöscht wenn ich wieder nachgucke, ich brauche nicht weiter warten. Das Schreiben passiert dann mit der oben beschriebenen Routine. Soweit aus dem Entwickler-Nähkästchen, Jörg
Ok, vielleicht etwas OT in diesem Thread aber nur ein bißchen. Auch ich bin nicht untätig (trotz etwas knapper Zeit). Zum Einen verfolge ich sehr interessiert den Werdegang des neuen Loaders - wobei mir nicht ganz klar ist ob schon ein stabiles Release erreicht ist oder nicht, benutze aber noch den Alten. In der Zwischenzeit bin ich dabei (inspiriert von den OSOZ Fortschritten) die BF Firmware im Bereich Datenacquisition zu überarbeiten. Ziel: alle alten Assemblerroutinen rauszuschmeißen. Derzeitiger Stand: Die Ausleseroutinen sind schon umgestellt auf C++ und laufen genauso schnell wie die alten Routinen. Die Invertierung habe ich wieder in die Capture-Routine zurückverlagert, da ich dadurch doppelt so schnell geworden bin. Ich hoffe dass Teile davon in OSOZ einfließen können oder zumindest hilfreich sind. Die neue BF.5.4 gibt's jedenfalls in Kürze, evtl. schon mit dem neuen Loader. Gruß Hayo
Hayo W. schrieb: > Zum Einen verfolge ich > sehr interessiert den Werdegang des neuen Loaders - wobei mir nicht ganz > klar ist ob schon ein stabiles Release erreicht ist oder nicht, benutze > aber noch den Alten. Doch, könnte man so sagen. Ich benutze nur noch den Neuen, gerade zum Entwickeln ist das eine echte Arbeitserleichterung. Es könnte vielleicht noch Verfeinerungen des Protokolls geben. Das Perl-Script muß dann zum Loader passen. Dank SVN ja kein Problem. > In der Zwischenzeit bin ich dabei (inspiriert von den OSOZ > Fortschritten) die BF Firmware im Bereich Datenacquisition zu > überarbeiten. Hmm, du könntest dich auch um den Capture-Treiber von Osoz kümmern. Das ist ja der letzte, der noch fehlt. Ich schrecke noch ein bischen davor zurück, wegen diesen unverstandenen Filterung und den "magischen" Registerwerten. Stattdessen verdrücke ich mich auf Nebenkriegsschauplätze wie den Loader. ;-) Auch sehr unglücklich ist eine Verquickung mit der LCD-Funktionalität: die Helligkeit des Grid-Layers wird mit ein paar freien Bits der ADC-Register eingestellt. Aus diesem Grunde erwäge ich, erstmal einen generischen internen ADC-Treiber zu machen, auf den dann Capture und LCD zugreifen können. Ähnlich SPI, auch dafür habe ich so einen Innenlayer, der von LED, Ext-Trigger und Kanaleinstellungen benutzt wird. Im Moment lerne ich gerade, wie man Interruptserviceroutinen in Assembler schreibt. Der SDK-Support für Interruptroutinen ist sehr unglücklich, mit enormen Latenzen. Es dauert 75 Takte bis man endlich in der eigenen Funktion ankommt, und nach deren Ende nochmal 40 Takte, bis abgeräumt ist und der Rücksprung erfolgt. Beim der eigentlich sehr kompakten ISR für die serielle Schnitstelle führt dieser Overhad dazu, daß die CPU bei Datenempfang bereits zu 20% ausgelastet ist. Kern des Problems ist, das der Compiler keinen Support für ISRs hat. Bei den Atmel AVRs gibt Pragmas dafür das ein entsprechender Prolog/Epilog gebaut wird, bei Nios nicht. Das SDK enthält quasi als Workaround ein Framework, was für normale C-Funktionen über einen generischen Einsprungmechanismus vorbereitet und nachbereitet. Der ist recht umständlich. So long, Jörg
Ich sehe Du rührst schon wieder im Eingemachten ;-) Ich gebe zu, so sehr habe ich mich mit den Interna noch nie auseinandergesetzt. Aber offensichtlich ist da an Stellen Optimierungspotential an denen ich das nicht vermutet hätte. Meine Ausleseroutine vermischt aus Performancegründen den Hardwarelayer etwas mit dem Applicationlayer. Für OSOZ ist das vermutlich so nicht zu übernehmen. Aber ich denke man es als Ansatz für die OSOZ-Routinen verwenden. Unter Umständen siehst Du auch noch Optimierungspotential. Ich mach das mal fertig und dann kannst Du ja mal nen Blick drauf werfen. Ich habe übrigens jetzt auch den hart im Assembler adressierten Wertebuffer durch ein Array ersetzt. Das ging ja gar nicht... Unter Anderem stelle ich gerade diverse Variable nach dem Schema "Variable_CH1, Variable_CH2..." um auf "Variable[4]". Das ist etwas nervig und mühselig, aber ermöglicht viel schöneren und schnelleren Code. Was mir noch einfällt - Du erwähntest die Möglichkeit mit einem "Section" Befehl bestimmte Speicherbereiche zu reservieren. Ich konnte da nix drüber finden. Kannst Du mir da auf die Sprünge helfen? So wie es im Moment läuft, ist es ja vermutlich nur ein glücklicher Zufall, dass sich das da nicht in die Quere kommt. So werde gleich mal Frühstück machen. Gruß Hayo
Hayo W. schrieb: > Was mir noch einfällt - Du erwähntest die Möglichkeit mit einem > "Section" Befehl bestimmte Speicherbereiche zu reservieren. Ich konnte > da nix drüber finden. Kannst Du mir da auf die Sprünge helfen? So wie es > im Moment läuft, ist es ja vermutlich nur ein glücklicher Zufall, dass > sich das da nicht in die Quere kommt. Siehe Osoz (das .ld Script für den Linker), da mache ich das so, für den Bildschirmspeicher. Dessen Adresse ist ja durch die Hardware fest vorgegeben, der Rest muß sich drumrum organisieren. Der Capturebuffer hingegen ist unter unserer Kontrolle, da würde ich das ohne Not nicht machen. Ganz normal statisch deklarieren oder mit malloc() holen. Letzteres hat den Vorteil, das der Speicher vom Startup-Code nicht erst genullt wird, weil er dann auf dem Heap statt im BSS-Segment liegt. Jörg
Ja mir geht es da auch nur um die Bereiche die fest vorgegeben sind. Für den ADC-Readout habe ich einfach ein Array als statisches Klassenattribut deklariert. Die Signalbuffer muß ich noch umstellen. So werd jetzt erstmal den Baumarkt unsicher machen. Noch frohes Schaffen. Hayo
Jörg H. schrieb: > Im Moment lerne ich gerade, wie man Interruptserviceroutinen in > Assembler schreibt. Der SDK-Support für Interruptroutinen ist sehr > unglücklich, mit enormen Latenzen. Es dauert 75 Takte bis man endlich in > der eigenen Funktion ankommt, und nach deren Ende nochmal 40 Takte, bis > abgeräumt ist und der Rücksprung erfolgt. Beim der eigentlich sehr > kompakten ISR für die serielle Schnitstelle führt dieser Overhead dazu, > daß die CPU bei Datenempfang bereits zu 20% ausgelastet ist. Es hat geklappt, ziemlich auf Anhieb sogar. Ich kann den "isrmanager" nun weglassen, was mir die Größe der verbliebenen C-Runtime halbiert. Der Loader ist nun etwas kleiner und schneller. Ist bei Osoz eingecheckt, aus Versehen hat das keinen Checkin-Kommentar. (Ist ungefähr so blöd wie eine Email ohne Subject-Zeile) Hayo W. schrieb: > Ja mir geht es da auch nur um die Bereiche die fest vorgegeben sind. Was wäre das? Mir ist nur der LCD-Framebuffer bewußt. Jörg
Jörg H. schrieb: > Was wäre das? Mir ist nur der LCD-Framebuffer bewußt. Genau, aber bis ich alle andern Speicherbereiche umgestellt habe möchte ich diesen Bereich lieber auch schützen. Mein Readout schreitet übrigens voran. Zur Zeit experimentiere ich mit Geschwindigkeitsoptimierungen. Gruß Hayo
Die ersten Messungen des optimierten Readout ergeben Erstaunliches. Der Invertierte Modus ist jetzt schneller als der normale Modus! Dieser bringt die Framerate im Einkanalbetrieb von 969 (Assembler) auf 1059 Frames/min (C-Code) Im invertierten Modus sind es sogar 1155 Frames/min. Damit bin ich ganz zufrieden. Hayo
Frames/min ist aber eine ungewöhnliche Einheit. Assembler = 16,15 fps C = 17,65 fps C(invert.)= 19,25 fps
Ich messe in fpm, hatte aber keine Lust zum Umrechnen. Hayo
Meine Optimierungen und Tests sind soweit fertig. Hier mal das Coding. Evtl. ist das für den OSOZ-Treiber ja ganz hilfreich. Den schnellen Predecrement habe ich von OSOZ übernommen. Vielleicht siehst Du da ja noch Optimierungspotential. Hayo
Hallo Hayo, ich mag ja auf dem Holzweg sein, aber hattet ihr nicht beschlossen am Nios nur noch bekannte Bugs zu beseitigen und stattdessen die Energie in Osoz zu stecken? Jetzt scheint es eher wieder in Richtung parallele Entwicklung zu gehen und Jörg arbeitet mehr oder weniger allein an Osoz. Das fänd ich persönlich bedauerlich. branadic
Nein, das ist nicht ganz korrekt. Ich wollte nur keine größeren neuen Funktionalitäten mehr einbauen. Was ich im Augenblick mache ist eine Mischung aus Optimierung der alten Firmware und Erkenntnisse sammeln für OSOZ. Das Coding für den aktuellen Readout z.B. ist entstanden, weil ich gesehen hatte, dass Jörg mit der Umstellung der ADC-Routinen angefangen hat. Er hat aber bislang nur ganz fundamentale Funktionalitäten implementiert. Mit den neuen Routinen der BF-Version hat Jörg jetzt einen weiteren Anhaltspunkt was noch gebraucht wird und wie man es implementieren könnte - oder auch noch optimieren könnte. Die Übernahme einzelner Funktionen von OSOZ in die alte BF ist auch eine prima Möglichkeit die Funktionalität zu konsolidieren. Dabei handelt es sich aber immer nur um einzelne Funktionen, die Gesamtstruktur läßt sich leider nicht mit vertretbarem Aufwand ändern. Daher wird auf jeden Fall die BF-Version irgendwann ein Auslaufmodell. Kein Grund zur Sorge also. Gruß Hayo
Mal wal ganz anderes: Liest "Toolmaster" Björn noch mit? An den hätte ich mal eine Frage. Wir haben ja im Moment keinen gdb-Client, aber die Sourcen sehen danach aus, als ob man einen bauen könnte. Björn, könntest du das mal versuchen? Mein Thema wäre dann wohl der Server auf dem Oszi. Jörg
Hallo Jörg, ja, ich lese noch mit und schaue mir Eure Änderungen an, komme aber momentan leider kaum selbst zum Coden. Unter Cygwin habe ich den GDB nicht kompiliert bekommen (ein Problem mit TCL IIRC). Das nios-elf-gdb Binary, das in der SF Cygwin Umgebung dabei ist, läuft (bei mir zumindest) auch nicht (auch TCL). Ich habe mir das ganze aber auch nicht weiter angesehen, denn unter Linux lies sich der nios-elf-gdb problemslos kompilieren. Das Binary startet unter Ubuntu bei mir auch ohne Probleme. Mangels Gegenstelle habe ich aber noch nicht weiter getestet. Auf der Suche nach dem Nios Gegenstück bin ich zwar über einen GDB Stub gestolpert, aber auch hier bin aber noch nicht zum Ausprobieren gekommen. http://users.ece.gatech.edu/~hamblen/4006/projects/viconbot/Code/Nios%20Directories/Software/lib/ Eventuell kannst Du damit ja etwas anfangen, falls Du das nicht schon selbst gefunden hast. Gruß Björn
Hallo Jörg, ich wollte mal den ultra boost loader testen. Beim make bekomme ich aber schon folgende Meldung: make: uclpack: Kommando nicht gefunden Was ist zu tun? Hayo
Hayo W. schrieb: > make: uclpack: Kommando nicht gefunden > Was ist zu tun? uclpack installieren. ;-) Gibt es wie ich bestimmt schon schrieb bei Herrn Oberhumer: http://www.oberhumer.com/opensource/ucl/download/ucl-1.03.tar.gz Und muß man kompilieren (configure make make install) Zur Bequemlichkeit im Anhang mein Kompilat für Linux 32bit. Björn F. schrieb: > Auf der Suche nach dem Nios Gegenstück bin ich zwar über einen GDB Stub > gestolpert, aber auch hier bin aber noch nicht zum Ausprobieren > gekommen. > > http://users.ece.gatech.edu/~hamblen/4006/projects... > > Eventuell kannst Du damit ja etwas anfangen, falls Du das nicht schon > selbst gefunden hast. Den Link kannte ich noch nicht, aber ich hatte den Source von gdbstub woanders gefunden. Wenn du das mit dem GDB für Cygwin noch hinkriegen würdest, das wäre prima. Mit Linux kann ich das derzeit nicht testen. Jörg
Jörg H. schrieb: > uclpack installieren. ;-) Jupp hatte ich, aber das scheint nicht so ganz geklappt zu haben. Ich habe die Datei jetzt mal manuell ins bin-Verzeichnis kopiert. Die Erzeugung der komprimierten Files klappt jetzt. Allerdings funktioniert Deine ramloader.sh bei mir nicht. Irgendein Shellbefehl passt ihm da nicht. Wenn ich das anpasse auf mein System läuft er auch los - aber ich bekomme folgende Ausgabe: Device : /dev/ttyS0 Flash filename : ramloader.germs UCL filename : TomCat_ram.ucl --- Writing GERMS firmware... Use of uninitialized value $filesize in addition (+) at GERMSloader.pl line 268. Writing line 000025 of 000025: Use of uninitialized value $filesize in concatenation (.) or string at GERMSloader.pl line 273. S8 detected, end of GERMS transmission. Successfully wrote GERMS firmware in 0.3 seconds! --- Writing compressed firmware ( bytes / 0 chunks of 4096 bytes)... Writing chunk 1 of 0 - Illegal division by zero at GERMSloader.pl line 289. done. Hayo
Wenn ich das aktuellste Perlskript nehme kommt folgendes: Device : /dev/ttyS0 Flash filename : ramloader.germs UCL filename : TomCat_ram.ucl ' not found!at_ram.ucl done. Hayo
Er findet die Datei nicht. Ist aus deinem Make ein TomCat_ram.ucl rausgefallen? Das Makefile muß analog zu Osoz umgebaut werden. Ich hatte die Make-Targets von Osoz noch etwas umgeräumt: Ein normales "make" ohne spezielles Target baut die beiden .ucl-Files, TomCat_ram.ucl und TomCat_flash.ucl. Ein "make srec" baut die alten Hex-Files, wie früher. Für uns ungeduldige Entwickler gibt es noch "make ram", der baut nur das für Ramload nötige TomCat_ram.ucl. Ferner noch "make aux" für die Listings und "make doc" für Doxygen. Die Shellscripte habe ich nicht getestet, mangels Linus nah am Scope. Wenn da noch was falsch ist, gerne korrieren und wieder einchecken. Jörg
Jörg H. schrieb: > Er findet die Datei nicht. Genau, aber warum? Die Datei steht definitiv im gleichen Verseichnis. Der Fehler tritt auch nicht nur bei der BF-Version auf, sondern auch bei OSOZ. Am make kann es also nicht liegen. Das hab ich für das BF-Build längst angepasst und läuft gut. Es werden schön die komprimierten Dateien rausgeworfen. Irgendwie ist es das Perlskript das da über die komprimierte Datei stolpert - Grund unbekannt. Hayo
Wäre eine Möglichkeit, aber ich denke da ist nur die Ausgabe nicht ganz ok. Ich vermute da kommt ein return bevor die Ausgabe durch ist. Hayo
Ok - neue Erkenntis!
Unter Windows funktioniert es! Das scheint ein Problem mit Linux zu
sein.
Ich bin leider nicht so firm mit Perl dass ich den Grund erkennen
könnte.
Es ist aber wohl definitiv der Abschnitt ab
if ($uclfilename) {
Danach wird dann die Datei geöffnet was irgendwie schiefgeht. Da ist
jetzt Johannes gefragt. Ich werd mal parallel im Firmwarethread eine
Anfrage machen.
Hayo
Ich habe mal nachgeschaut - in den Scripten sind versehentlich DOS line endings reingekommen, das habe ich gerade behoben. Ansonsten scheinen die anzulaufen. Ich habe kein Oszi hier, kann daher nur trockentesten. Das Perl-Script scheint mir soweit auch OK zu sein. Was macht denn ein nackter Aufruf von
1 | perl GERMSloader.pl -d /dev/ttyS0 -b TomCat_ram.ucl |
(Schnittstellenname ggf. anpassen.) Ohne irgendwas angeschlossen sollte der die Chunks der Datei rauspusten, dann ca. 10 Sekunden auf Antwort warten, danach mit einem Fehler abbrechen. Jörg
Den Fehler, dass durch das Verwenden der Shellskripte falsche Dateinamen ans Perlskript durchgereicht werden, wenn in den Shellskripten DOS-Lineendings stehen, das Ganze aber unter Linux ausgeführt wird (dadurch bekommt das Perlscript effektiv den Namen TomCat_flash.ucl<#13> übergeben) werde ich gleich noch abfangen. Danke für's Finden, das hätte ich selber nie entdeckt. ;-) Nicht passiert wäre der Fehler übrigens, wenn du es einfach direkt von der Befehlszeile ausgeführt oder die UCL-Datei über den Automatismus in der GERMS-Datei angehängt hättest (dort behandle ich die Zeilenenden schon korrekt, bilde ich mir ein, das überprüfe ich aber auch gleich noch). /Hannes
Hi Jörg, hier das Coding des schnellen ADC_Readout(). Leider läßt sich hier der Application Layer aus Performancegründen nicht ganz vom Hardwarelayer trennen. Vielleicht hast Du ja eine Idee wie man das für OSOZ verwerten kann ohne das Layerprinzip dabei zu verletzen. Auf jeden Fall ist das Ganze hitverdächtig schnell. Da kann man die "tollen" Assemblerroutinen getrost vergessen. Gruß Hayo
Ohne die Details schon zu verstehen fällt mir auf: Diese parallele Offsetkorrektur funktioniert nur so lange, wie kein ADC-Wert plus Offset je die Byteauflösung überschreitet. Sonst gibt es böse Wraparound-Effekte und Überläufer in Nachbarbytes. Vielleicht ein Grund für (Pseudo-)Spikes? War das vorher auch schon so? (Pointer-Dereferenzierung für adc_offs muß auch nicht sein, das könnte einfach ein Wert sein. Mit Glück hat der Compiler das bereits aus der Schleife genommen.) Die alte Eingangsstufe ist ja recht schwach ausgesteuert, da mag das noch eher gutgehen. Wenn die Offsets aus irgendeinem Grunde "aggressiv" stehen aber auch nicht. Spätestens mit der neuen riecht es nach Problemen. Meine 0,02€... Jörg
Jörg H. schrieb: > Ohne die Details schon zu verstehen fällt mir auf: > > Diese parallele Offsetkorrektur funktioniert nur so lange, wie kein > ADC-Wert plus Offset je die Byteauflösung überschreitet. Ja das ist korrekt. Ich habe mal mit größeren Aussteuerungen getestet konnte aber keine Probleme feststellen. Grundsätzlich hast Du natürlich recht. > Vielleicht ein > Grund für (Pseudo-)Spikes? War das vorher auch schon so? Nein das hängt nicht zusammen. Das gab es auch schon vorher. > (Pointer-Dereferenzierung für adc_offs muß auch nicht sein, das könnte > einfach ein Wert sein. Mit Glück hat der Compiler das bereits aus der > Schleife genommen.) Stimmt, das kann ich noch optimieren, hatte ich im Überschwang glatt übersehen. > Die alte Eingangsstufe ist ja recht schwach ausgesteuert, da mag das > noch eher gutgehen. Wenn die Offsets aus irgendeinem Grunde "aggressiv" > stehen aber auch nicht. Spätestens mit der neuen riecht es nach > Problemen. Die Offsets bewegen sich in der Regel zwische 0 - 4. Das ist recht unkritisch. Wie sieht das mit der neuen Stufe aus? > Meine 0,02€... Pling, pling... Hayo
Ich habe für OSOZ mal eine neue Funktion geschrieben und eingecheckt welche die Manufacturer ID ausliest. Ergebnis: meine beiden Kisten haben ebenfalls Macronix Chips drin. Die Funktion habe ich auch in der BF.5.5 fest eingebaut, damit alle die Möglichkeit haben das zu prüfen. Gruß Hayo
Schade ... schau gerad auf ebay, aber es gibt keines dieser Geräte mehr zu kaufen? Wollt mir eins als Spielzeug zum Basteln zulegen :-)
Weitersuchen, habe gerade neulich zwei für einen Kumpel günstig geschossen. Die tauchen immer mal wieder in der Bucht auf. Hayo
Angehängte Dateien:
-
W2024_Knobs_klein.jpg
74 KB
Hi Leute, falls noch Interesse an einem W2024 besteht: ich möchte mein Gerät verkaufen, da ich auf ein Owon umgestiegen bin. Hier die Eckdaten meiner Anpassungen: - neuer Lüfter eingebaut - Schirmblech eingebaut - Drehknöpfe aus Alu gefertigt, schraubbar (Madenschrauben) - 4 unbestückte AddOn Platinen für die Erweiterung der Eingangsstufen (mir waren die Lötungen zu filigran) lege ich bei Ansonsten ist das Teil im Originalzustand mit der aktuellen Blueflash Firmware und 4 Messleitungen. Bitte nur ernstgemeinte Angebote an michel-werner[at]gmx[dot]de. Michel
Na bitte, sag ich doch! Aber mal was anderes wieder zum Thema. Ich habe den readout() Treiber mal umgeschrieben so dass kein Byte-Overflow mehr passieren kann. Ist immer noch ziemlich schnell, aber doch deutlich langsamer als vorher. Daher werde ich in der BF-Version den schnellen Treiber beibehalten solange es keine Probleme gibt. Aber für OSOZ ist der "sichere" Treiber evtl. die bessere Wahl. Gruß Hayo
Ach so, vielleicht ein kleiner Geschwindigkeitsvergleich: Alter Assembler Treiber -> 970 FPM verbesserter C-Code Treiber -> 970 FPM "sicherer" C-Code Treiber -> 1089 FPM aktueller BF.5.5 Treiber -> 1580 FPM Hayo
Hi, durch den neuen Schwung in diesem und den anderen W20xx Threads ist das Interesse an dem Scope größer als ich dachte. Kurzum - das W2024 ist weg. Michel
Hab' lang nix mehr geschrieben... Bin aber noch fleißig dabei. Die letzte Zeit habe ich mich zugegeben in eine vielleicht nicht übermäßig sinnvolle Baustelle verrannt, nämlich den Dekompressor-Loader komplett in Assembler zu schreiben. Nicht unbedingt um ihn schneller zu kriegen, sondern kürzer. Das macht den Ladevorgang letztendlich auch schneller. Und weil sich ein Loader in C halt nicht gehört, fand ich. Und weil der Berg halt da war. Aufgrund der eingeschränkten Debugmöglichkeiten (kein gdb, kein printf) ist das eine knifflige Sache, geht nur in kleinen Schritten. Und gerade die sind beim Dekompressor schwierig, der funktioniert entweder komplett, oder es kommt nur Unsinn raus. Erst habe ich versucht, eine gefundene Implementation in ARM-Assembler auf unseren Nios zu portiern. Hat aber ums verrecken nicht hingehauen, obwohl ich das zig mal verglichen habe. (Vielleicht arbeitet der Kompressor je nach Zielimlementation anders, nimmt Rücksicht auf jeweilige Optimierung?) Dann habe ich die vorhandene C-Implementation nach Assembler portiert. Das hat letztendlich hingehauen. Das Bitgeschubse konnte ich noch gehörig auf den Nios optimieren (eine der Ausnahmen, wo Assembler wirklich deutlich mächtiger ist). Der Dekompressor ist jetzt nur noch 1/3 so groß und rennt doppelt so schnell. Letzteres nützt nix, wir warten eh auf die serielle Schnittstelle. Ich optimiere also auf Codegröße. Ferner brauche ich außer dem Empfangspuffer kein RAM und keinen Stack, der Code rennt vollständig in den Registern. Es ist also auch kein Startup-Code nötig. Ich habe aber auch einiges gelernt. In Nios-Assembler macht mir zur Zeit keiner was vor. ;-) Eigentlich programmiert sich der Nios ganz wunderbar in Assembler, dank seines Register-Window Verfahrens a'la Sparc. Eine Unterfunktion hat 16 "frische" Register zur Verfügung. Ich habe 2 "defekte" Instructions gefunden: RRC und RLC (rotieren durch Carry). Die arbeiten nicht wie im Datenbuch beschrieben, sondern machen nur ein NOT. Sehr merkwürdig. Ferner scheint unser Nios eine Art Write Buffer zu haben. Ein Mini-Cache für 32 Bit oder so, mit dem er Schreibzugriffe in den Hintergrund schiebt. Das ist mir mit meinem variablenlosen Code auf die Füße gefallen. Die Daten, die die ISR geschrieben hat, kann ich in der Hauptschleife trotzdem noch nicht gleich lesen. Fällt sonst in C vielleicht nicht auf, weil mittlerweile andere Speicherzugriffe die Daten rausgedrückt haben. Ich bin mir aber noch nicht abschließend sicher, ob ich keinem Bug aufgesessen bin. Zurück zum Loader. Die RAM-Version habe ich fertig, an der für Flash arbeite ich noch, habe funktionsfähige Routinen aber schon beisammen. Anbei der Ramloader. "Niemand wird je Programme schreiben, die größer sind als 640 Bytes" - oder wie sagte Bill Gates damals? Der Ramloader hat 632 Bytes. Der Quellcode ist deutlich größer. Wer mal schauen will wie sowas aussieht: http://sourceforge.net/apps/trac/welecw2000a/browser/fpga/nios/osoz/platform/nios/ucl_loader/ramloader.S Weil das komplett neuer Code ist könnte Hayo mal ausprobieren, ob er damit immer noch sein Problem hat. Grüße Jörg
Hi Jörg, habe den Ramloader ausprobiert - mehr dazu im Firmware Thread. Hayo
Alle Achtung Jörg, du kommst ja rasend schnell voran. Klar geht es im Moment nur in kleinen Schritten, aber deine Leistung ist schon enorm. Keine Angst, das Feedback hier ist gering, aber ich bin sicher, dass viele, so wie ich, regelmäßig mitlesen. Nur kann halt nicht jeder alle deine Erkenntnisse verstehen und richtig einordnen. Wie z.B.: Jörg H. schrieb: > Ich habe 2 "defekte" Instructions gefunden: RRC und RLC (rotieren durch > Carry). Die arbeiten nicht wie im Datenbuch beschrieben, sondern machen > nur ein NOT. Sehr merkwürdig. Teufel nochmal, sowas ohne Debugger rauszufinden ist schon klasse. Den "Alten" kann man halt so schnell nix vormachen. Grüße, Guido
Hi Jörg, ich mußte echt lachen als ich gelesen habe dass Du Dich in Assembler vertieft hast. Ich bin ja seit der letzten Version immer noch dabei an den ADC-Treiberroutinen zu basteln. Da ich mit C/C++ etwas an die Grenzen gestoßen bin (jetzt kommt der Teil bei dem Du lachen kannst) habe ich mich auf meine alten Assemblertage in der digitalen Signalverarbeitung besonnen und habe mich ebenfalls in den NIOS Assembler gekniet. Nachdem ich mich 3 Jahre erfolgreich davor gedrückt habe stelle ich fest, dass es doch noch einen Unterschied macht wenn man geschwindigkeits-kritische Abläufe in Assembler handoptimiert. Da ist der C Compiler anscheinend nicht ganz so effektiv. Ich habe jetzt den ADC-Treiber komplett neu in Assembler geschrieben und bin gerade dabei noch Feintuning zu betreiben. Mit dem ursprünglichen Assemblertreiber hat das Ganze nichts mehr zu tun. Im Gegensatz zu diesem wird auch kein hart (Adressen) kodierter Zwischenbuffer verwendet, sondern alles aus den Registern direkt in den Signalbuffer geschrieben. Obwohl der Assemblertreiber im Prinzip das Gleiche macht wie der C-codierte Treiber, läuft der Assemblertreiber etwas schneller. Wäre das für OSOZ eine Option den ADC-Treiber in Assembler zu schreiben oder ist das absolut verpönt und ein NoGo? Gruß Hayo edit: selbstverständlich ist das Ganze so ausführlich kommentiert, dass auch ein nicht Assemblerkundiger versteht was da abläuft. @Guido ja der Jörg ist schon echt fit, das kann man nicht anders sagen :-) Das hat dem Ganzen wieder einen netten Ruck nach vorn gegeben.
Noch einige Überlegungen zum Thema Menüs und Buttons in OSOZ. In der BF-FW liegen die Menüeinträge und Steuerparameter ja verteilt in diversen Tabellen und haben auch eine etwas unübersichtliche Struktur. Meine Idee für OSOZ wäre, die Eigenschaften eines Buttons in einer Struktur zu kapseln. Quasi ein wenig objektorientiert (für Arme) wenn man so will. Diese Struktur könnte z.B. folgende Felder enthalten: - Menü (Nr) in dem der Button auftauchen soll - Position in dem Menü - Textzeile 1 - Ausgabeoffset Textzeile 1 - Textzeile 2 - Ausgabeoffset Textzeile 2 - Sonderzeichen (Symbol) - Position Sonderzeichen - Sonderfunktion des Buttons bzw. das Verhalten (zahlencodiert) Die Pointer auf diese Strukturen könnte man in eine zentrale Menütabelle aufnehmen. Beim Aufruf eines Menüs kann dann die Menüzeichenfunktion alle Einträge zu diesem Menü aus der Tabelle heraussuchen und die Buttons gemäß der Eigenschaften in der jeweiligen Struktur zeichnen. Dieses Konstrukt wäre problemlos wartbar und erweiterbar. Hat jemand dazu noch Vorschläge, Verbesserungen oder auch Gegenargumente? Gruß Hayo
Hallo Hayo und alle anderen,
verstehe ich Dich richtig, Du willst in der Struktur verankern wo der
Button auftaucht?
Wenn Du die Buttons abstrahieren willst, dann doch so, dass die Knöpfe
an verschiedenen Stellen auftauchen können, oder?
Idee :
Knopf-Struct (typedef struct KS ..) :
- Textzeile 1 (Tz)
- Offset Tz 1
- Textzeile 2 (Tz)
- Offset Tz 2
... und zusätzlich
- Pointer auf Knopf-Routine (wird ausgeführt beim Drücken)
z.B. void (*knopfFunc) (void * ptr)
Dazu die Funktionen
void KnopfFunc1 (void * xxx) ..
...
und die Knopfdefinition ...
const KS Knopf1 = {...., *knopfFunc1 };
Menüstruktur:
const KS * Menue[Nr][Zeile] = { { &Knopf1, ...} ,,,}
Aber vielleicht ist das ja schon zu konkret ?
Viele Grüße,
Rainer
Mit meinen Assembler-Exzessen bin ich nun hoffentlich erstmal durch. Anbei das Resultat für den Flashloader. Geschwindigkeitsmäßig hat sich leider nicht viel getan. Die eingesparten Sekundenbruchteile multiplizieren sich über alle User vermutlich nie zu den Dutzenden von Stunden, die ich da reingesteckt habe... Wen der Quellcode interessiert: http://sourceforge.net/apps/trac/welecw2000a/browser/fpga/nios/osoz/platform/nios/ucl_loader/flashloader.S Ich habe aber einiges gelernt, sollte mal eine Wiki-Seite über effizientes Programmieren für Nios in C und Assembler anfangen... Zum Thema Assembler in Osoz: gehört natürlich nur in den Plattformlayer, nicht in den portablen Teil. Dort von mir aus, wenn's denn tatsächlich was bringt. Eine äquivalente C-Routine sollte man sich alternativ immer aufheben, wegen Lesbarkeit und Wartbarkeit. Vorher sollte man aber gründlich draufschauen, ob man denn in C bereits alles "richtig" gemacht hat oder vielleicht noch was umstellen sollte. Da hilft es, hinter die Kulissen zu gucken, an kritischen Stellen den vom Compiler produzierten Assemblercode anzugucken. Wird bei uns durch "make aux" erzeugt, die Datei TomCat.objdump im obj-Verzeichnis. Gängige Kandidaten für solche Entscheidungen sind Laufzeiger vs. Arrayzugriff, Zählschleifen abwärts gegen Null laufen lassen, Prä- versus Post-inkrement/dekrement, versehentliche Arithmetik mit Datentypen kleiner als Maschinenbreite, unnötige Vorzeichenerweiterungen durch signed-Typen, Rücksicht auf Einschränkungen von Konstanten (Immediate-Werten), um ein paar zu nennen die mir grade einfallen. Assembler macht eigentlich nur Sinn, wenn man im konkreten Algorithmus Spezialitäten der Architektur ausnutzen kann, die dem Compiler nicht zugänglich sind, meist weil man sie in C nicht ausdrücken kann. Das Gefühl dafür kriegt man durch .objdump-Lesen und genaues Studium des Prozessormanuals... Bei meinem Dekompressor waren das Instruktionen für Bittests, oft auch Benutzung von Rotate und Carry (hier ging das aber nicht). Beim Flash u.A. ein Trick um mehrere Konstantenbytes in einem Register zu kombinieren. Beim Nios kann man "von Hand" den Delay-Slot nach einem Verzweigungsbefehl meist sinnvoll füllen, z.B. durch Umstellen, der Compiler schafft das oft nicht. Das mit dem ADC-Treiber würde ich mir also konkret auch gern anschauen. Hayo, du darfst ihn auch gern gleich für Osoz schreiben, da fehlt zufällig noch dieser letzte Treiber. Nächstes Posting zu den Buttons, sonst wird's zu lang hier. ;-) Jörg
@Jörg Jörg H. schrieb: > Hayo, du darfst ihn auch gern gleich für Osoz schreiben, da fehlt > zufällig noch dieser letzte Treiber. Ja das kann ich gerne machen, aber ich wollte damit erstmal fertig werden und dann mit Dir abstimmen was wir davon in welcher Form übernehmen. Ich habe alle Treiberversionen auswählbar in der aktuellen Firmware eingebaut. Ich hoffe ich kann diese bis zum Wochenende bereit stellen. Gruß Hayo Jörg H. schrieb: > Da hilft es, hinter die > Kulissen zu gucken, an kritischen Stellen den vom Compiler produzierten > Assemblercode anzugucken. Leider ist das Problem bei der BF-FW der recht umfangreiche code. Da ist es nicht ganz einfach die richtigen Stellen zu finden, aber Du hast natürlich recht. Ich werde (wenn ich den Feinschliff fertig habe) mal die Routinen gegeneinander abgleichen. Vielleicht kann ich damit dann die C-Routine doch noch auf das gleiche Niveau bringen. Gruß Hayo
Rainer H. schrieb: > verstehe ich Dich richtig, Du willst in der Struktur verankern wo der > Button auftaucht? Ja genau. Damit ist die Position gemeint, also 1 - 6. Das Menü ist quasi der Primärschlüssel zusammen mit der Position. Daraus ergibt sich eine eindeutige Zuordnung. Rainer H. schrieb: > Wenn Du die Buttons abstrahieren willst, dann doch so, dass die Knöpfe > an verschiedenen Stellen auftauchen können, oder? Ich will ja eigentlich nicht abstrahieren, sondern die Eigenschaften jedes einzelnen Buttons zentral an einer Stelle verfügbar haben. Jeder Knopf hat dann "seine" feste Position. Was ich natürlich in meiner ersten Ausführung vergessen hatte war ein weiteres Feld für den Pointer auf die auszuführende Funktion - sollte nicht fehlen ;-) Hayo
Hallo Hayo, ich habe glaube ich noch nicht verstanden wie Du den richtigen Menü-Eintrag finden willst. Ansonsten ist wohl vieles Gemackssache. Ich würde versuchen die Position im Menü aus der Struktur rauszuhalten, weil innerhalb der Strukturen zu suchen dauert. Eher ein Array (aus Menüs) mit einem Array (aus Menüeinträgen) zu verwenden, hier ist dann Index gleich Position. Ist ja nix Dynamisches dran (nehme ich an). Viele Grüße, Rainer
Hayo W. schrieb: >> Da hilft es, hinter die >> Kulissen zu gucken, an kritischen Stellen den vom Compiler produzierten >> Assemblercode anzugucken. > > Leider ist das Problem bei der BF-FW der recht umfangreiche code. Da ist > es nicht ganz einfach die richtigen Stellen zu finden, Doch, das ist ganz einfach, der C-Code steht noch dazwischen drin. Man braucht also nur nach seiner Funktion oder Codezeile zu suchen. Nun aber zu den Buttons: An der Position als Member in der Button-Struktur störte ich mich auch, dachte das ergibt sich durch die Reihenfolge, in der sie in's Menü eingetragen sind. Aber das ist nur ein Detail. Grundsätzlich erstmal: Datenstrukturen gut, Code böse. Wir sollten soviel wie möglich vom Menüverhalten in Datenstrukturen definieren, um für das Verhalten keinen immer ähnliche Code zu schreiben. Wenn man es schlau anstellt kann man den Preprozessor verwenden, um das Füllen dieser Datenstrukturen möglichst gut lesbar zu haben. Unions oder optional dazugezeigerte Unterstrukturen helfen, daß nicht jeder Eintrag eine worst-case Größe belegt. Einen Wert toggeln oder ein Untermenü aufrufen kann ein Button vielleicht alleine. Es sollten möglichst wenig Handlerfunktionen (oder -messages) nötig sein, die Standardfunktionalitäten schon alleine laufen, denke ich. Nur wenn echte Aktionen die über die Darstellung hinausgehen nötig sind muß "die Außenwelt" bemüht werden. Ich muß noch drüber nachdenken wie das zu Model-View-Contoller passt. Wir reden ja gerade über Controller und ein bischen View. Stellt euch hypothetisch vor, das ist alles jederzeit auch parallel und gleichberechtigt über die RS232 änderbar. Dann können wir nicht einfach an Werten rumfummeln, sondern ein Controller beantragt das beim Model, das wiederum aktualisiert die Views. Bevor wir uns aber in diesen Details verlieren hätte ich gern erstmal aufgestellt, was wir denn wollen, was das Button+Menüsystem leisten soll. Was kann so ein Knopf denn alles, was ein Menü? Ist zumindest mir als Nicht-User gar nicht so klar. Da gibt es mitunter noch diese Zusatzfähnchen über den Buttons, Popups und weißnich was. Es muß auch nicht genau wie bei Welec sein, vielleicht fällt euch mitunter noch was Schlaueres ein? Und wenn jemand echte Erfahrung mit sowas hat, oder weiß wo man es abgucken kann, dann immer her damit! Grüße Jörg
Ok, nochmal zum Ansatz meiner Konstruktion. Das Menü kann dabei gar nichts. Alle Funktionalität steckt im Button. Das Menü dient nur zur Gruppierung. Der Vorteil dieser Konstruktion ist, dass über den Primärschlüssel Menü/Position jeder Knopf eindeutig identifizierbar ist. Dabei ist die Reihenfolge der Einträge völlig egal. D.h. ich kann jederzeit einen neuen Knopf erzeugen und ihn an die Menütabelle dranhängen bzw. vorhandene Knöpfe einfach umhängen. Wir brauchen dann eine Funktion die die Menüs zeichnet, die muß dann nur mit der zu zeichnenden Menünummer versorgt werden und sucht sich dann alle zu zeichnenden Knöpfe selbst raus. Als Zweites brauchen wir einen Buttonhandler der bei Knopfdruck einfach die Knopfnummer und das aktive Menu als Parameter braucht damit er die zum Knopf passende Struktur ausfindig machen kann und dann die hinterlegte Funktion aufrufen kann. Rainer H. schrieb: > Eher ein Array (aus > Menüs) mit einem Array (aus Menüeinträgen) zu verwenden, hier ist dann > Index gleich Position. So ist das ja momentan gelöst, was sich aber als schlecht wartbar und unübersichtlich erweist weil alle weiteren Parameter ebenfalls über diverse Arrays verstreut sind. Die von mir angedachte Konstruktion verbraucht auch nur so viele Einträge wie es tatsächlich Buttons gibt und muß keine leeren Hüllen reservieren die nicht genutzt werden. Es ist also eine Tabelle, dessen Zeilentyp die Struktur mit den Daten der Knöpfe ist und es gibt dann für jeden Knopf einen Tabelleneintrag. Gruß Hayo
Jörg H. schrieb: > Doch, das ist ganz einfach, der C-Code steht noch dazwischen drin Ahja, hast recht, ich hatte da immer nur am Anfang rein gesehen und das dann sein gelassen. Aber das geht besser als ich dachte. Danke für den Tip. Gruß Hayo
Hab mal den Assemblercode das Compilers mit dem handoptimierten verglichen. Da wird schon klar wo die Zeit liegen bleibt. Der handoptimierte Code ist deutlich kompakter, verzichtet auf Speicherzugriffe und berechnet alles direkt aus den Registern heraus. Es ist also auf jeden Fall was rauszuholen damit. Ich werde also mal weiter den Assemblertreiber optimieren... Hayo
Kleines Beispiel zur Anschauung: Der Compiler erzeugt folgenden Code aus einer IF Kondition: PFX %hi(255) ; limiter to 255 CMPI %r0, %lo(255) ; if r0 > 255 -> r0 = 255 IFS cc_nc PFX %hi(255) MOVI %r0, %lo(255) Dazu lädt er vorher noch einen Wert aus dem RAM in R0. Alles in einer Schleife mit 16384 Durchläufen. Handoptimiert ist der Wert schon längst im Register r0 (aus vorherigen Berechnungen). Vor dem Schleifenanfang wird der Verrgleichswert in ein Register geschrieben: PFX %hi(255) ; preload local register with MOVI %l3,%lo(255) ; 255 for limiter In der Schleife sieht der Vergleich dann so aus: CMP %l3, %r0 ; limiter to 255 IFS cc_n ; if r0 > 255 -> r0 = 255 MOV %r0, %l3 Derer Beispiele gibt es einige. Ich werde mal versuchen ob ich den Registerpreload im C-Code erzwingen kann. Gruß Hayo
Tja Hayo, so kommt man schließlich auf die Idee den Compiler lieber selbst zu schreiben (das muss doch besser gehen?).;-) Grüße, Guido
Um Gottes Willen....bloß das nicht. Aber ich muß sagen wenn man sich erstmal an den NIOS Assembler gewöhnt hat macht es sogar Spaß, weil man doch noch einige "Register" ziehen kann die einem sonst verwehrt bleiben. Es geht doch nichts über absolute Kontrolle ;-) Gruß Hayo
Hallo Hayo, Hayo W. schrieb: > Als Zweites brauchen wir einen Buttonhandler der bei Knopfdruck einfach > die Knopfnummer und das aktive Menu als Parameter braucht damit er die > zum Knopf passende Struktur ausfindig machen kann und dann die > hinterlegte Funktion aufrufen kann. Ich hätte gedacht der Buttonhandler besteht nur aus einer Sprungtabelle, die beim Menüanzeigen aktualisiert wird. In der Sprungtabelle könnten dann für jeden Knopf die in der Knopfstruktur hinterlegten Funktionspointer liegen. Der Buttonhandler braucht dann nicht zu suchen. Viele Grüße, Rainer
Ja, da bist Du schon einen Schritt weiter. Diese Vorgehensweise ist sicherlich effektiver. Mir ging es erstmal um das Prinzip, denn da müssen wir ja erstmal auf ein gemeinsames Modell kommen welches dann feingeschliffen wird. Gruß Hayo
Ich habe gestern mal ganz kurz mit einem Kumpel über unser Vorhaben gesprochen, der langjährig im Bereich Headunits/Navis für Autos arbeitet. Also von der Bedienung her ähnliche Systeme, mit Display, Softbuttons und so. Er hat mich in einigen Punkten bestärkt. Model-View-Controller ist das anerkannt beste Konzept für sowas. UI in Datenstrukturen abbilden und nicht in Code ist auch klar. Es sollte aber keine Funktionspointer für Handler geben, sondern die Buttons sollten Messages auslösen. So passieren die Dinge indirekt und können auch von woanders ausgelöst werden. Vielleicht muß ich meine Messagequeue nochmal ändern. "Früher" habe ich da immer mit IDs gearbeitet, sprich eine Message besteht aus einer Kennung und einem ganz kleinen Datenteil. Zum Beispiel ID für "Taste wurde gedrückt" und im Datenwort steht welche. Aktuell arbeite ich nicht mit IDs, sondern habe an der Stelle einen Funktionspointer. Damit erspare ich mir fette switch/case Blöcke, um diese IDs wieder zu zerlegen. Dem Sender muß der Empfänger dann bereits bekannt sein. Das ist Teil des "Vertrags", mal mit der Brille des "Design By Contract" gesehen. Für den Tastaturtreiber ist also klar, daß es eine Empfängerfunktion geben muß, bei Osoz übergebe ich die bei der Initialisierung. Eine Message ist also ein verzögerter Funktionsaufruf. Für uns praktisch, wir haben ja kein Multitasking, das sich die Dinge so in kleinere Häppchen zerlegen, es immer wieder durch die Hauptschleife geht. Die Punkt-zu-Punkt Message entspricht auch der logischen Sicht. Beim höher abstrahierten Entwurf macht man oft keine Unterscheidung zwischen Messages und Funktionen. Unpraktisch wird es nun beim Herumreichen, wenn z.B. mehrere Views auf eine Message reagieren sollen. Oder vorgefiltert wird, wer was abbekommt, weil er es abonniert hat. Da sind IDs und/oder Bitmasken praktischer. Es muß allerdings nicht nur die eine große Messagequeue geben. Die UI-Schicht könnte da auch was Eigenes haben. Also z.B. zwar eine Message in die Hauptschleife tun, die ein UI-Event signalisiert, aber darauf in der UI-Schicht eine eigene Verwaltung betreiben. Soweit ein paar Gedanken... Jörg
Nach einer Weile mal wieder ein paar Updates. Nicht das jemand denkt hier passiert nichts... Die letzten ca. 2 Wochen bin ich gedanklich wie die Katze um den heißen Brei um die Implementierung eines geeigneten Model-View-Controller Konzepts herumgeschlichen, und generische Button-Menüs. Ich habe leider keine Literatur oder Open Source gefunden, wie man MVC im kleinen effizient auf einer Embedded Plattform umsetzt. Dieses Rad erfindet vermutlich jeder Gerätehersteller der weit genug ist selbst, oder es bleibt verborgen in kommerziellen Tool-Baukästen. Die konkrete Lösung wie's jeweils optimal gelöst ist mag aber auch sehr speziell sein. Meine gedanklichen Anforderungen waren: - kein C++, das muß auch mit Tabellen, Strukturen und Funktionszeigern gehen - keine dynamischen Speicheranforderungen (wg. Fragmentierung) - kein Durchsuchen von Tabellen/Listen, keine großen switch-case, alles soll direkt gehen So vorgestern bis gestern ist aber der hauptsächliche Knoten in meinem Hirn geplatzt, jetzt sehe ich den Weg und bin wieder am Implementieren. (Das fehlende Puzzleteil waren verkettete Listen für die Registrierung von Views.) Ob es so letztendlich wirklich bis zum Schluß trägt weiß ich nicht. Bestimmt wird man da nochmal was ändern müssen. Das Modell ist eine abstrahierte Art, Parameter des Oszilloskops einzustellen, sowie über Änderungen zu benachrichtigen. Statt vieler Einzelfunktionen wie in den Hardwaretreibern gibt es nur eine, der einzustellende Parameter wird als eine ID übergeben, plus der neue Wert und bei uns als Spezialität noch optional die Kanalnummer. So kann man die ID des Parameters z.b. in eine Tabelle packen, die einen Button repräsentiert. Das ginge zwar auch mit individuellen Funktionszeigern, aber wenn es eine zentrale Funktion ist kann die sich auch gleich um Benachrichtigungen kümmern, und in gleicher Weise ist der Wert auch rücklesbar. Das Modell ist auch eine Mini-Datenbank (keine Angst, ohne Ballast), die den vormals in unzählige Variablen verstreuten Gerätezustand bündelt. Abspeichern wird so nebenbei auch ganz einfach. Puh, ist das alles sprachlich blöd auszudrücken. Nehmen wir mal ein Beispiel: Wir wollen die Vertikalablenkung für Kanal 2 verändern, weil der User am Knopf gedreht hat. Es wird deshalb die Modellfunktion zum Setzen aufgerufen, sinngemäß:
1 | ModelValueSet(eChannelAttenuation, 2, eChAtt50mV) |
Die Wertübergabe geschieht mit einem Universaltyp, ich habe ihn mal variant_t genannt, der eine 32bit-Union aus allen vorkommenden Datentypen ist. ModelValueSet guckt in einer internen Tabelle nach, welche Wrapper-Funktion zur Hardware zuständig ist. Falls vorhanden ruft es die auf. Der Wrapper ruft die Hardwarefunktion mit dem "echten" Datentyp auf. Danach speichert ModelValueSet den Wert in eigenem Speicher ab. So ist er später rücklesbar (mit ModelValueGet). Zum Schluß kommt die Benachrichtigung der Views. Dazu guckt ModelValueSet in eine weitere Tabelle, pro ID ist dort der Anfang einer verketteten Liste mit angemeldeten Views. Die Liste wird falls vorhanden iteriert und die View-Funktionen aufgerufen. Einen View zu registieren ist einfach und schnell. Mit ModelViewRegister() wird an entsprechender Stelle in obiger Tabelle ein Eintrag in die Liste gekettet. Dafür brauchen nur 2 Zeiger umgesetzt zu werden. Intern gibt es noch eine Liste freier Einträge, die zum Start besetzt wird. Daher geht das zur Laufzeit, ein Button kann sich als View anmelden wenn er sichtbar wird, und beim Abbau wieder abmelden. Ich gehe davon aus, das für die meisten Buttons gar kein Code nötig ist, sondern nur noch zu definierende Tabellen. Später mehr zu Buttons und Menüs. Da habe ich auch ein paar Ansätze, bin aber noch nicht damit durch. Zur Belohnung für die Mühe ist die Anzeige automagisch konsistent, ohne das der Code dafür gepflegt werden müßte. Auf unsere Vertikalablenkung ist die Statuszeile angemeldet, die Änderungen dann auch anzeigt. An anderen Parametern hängen LEDs oder gerade sichtbare Buttons. Ich habe ersten Code für das Model eingecheckt. Das definiert auch die Schnittstellen für Controller und Views, die sind dagegen einfach und brauchen kein eigenes Codemodul, außer natürlich ihrem Wirk-Code. http://sourceforge.net/apps/trac/welecw2000a/browser/fpga/nios/osoz/app/include/model.h http://sourceforge.net/apps/trac/welecw2000a/browser/fpga/nios/osoz/app/src/model.c Ist nicht viel Code, und die zukünftigen Erweiterungen wären nur noch weitere Tabelleneinträge und Wrapperfunktionen. Zur Zeit wird dort nicht mit Messages gearbeitet, sondern mit direkten Funktionsaufrufen. Mal sehen ob das so bleibt. Konstruktive Kritik ist wie immer herzlich willkommen! Nun geht's an Test und Inbetriebname. Soll ja regnen... Jörg
Hallo Jörg, mir raucht der Schädel :-). Soviele Konzepte, die ich nie kennengelernt habe, aber nagut, ich bin auch kein Informatiker. Habe ich das richtig verstanden, eine linked list, bei der alle eventuellen Elemente vordefiniert sind, so dass kein malloc o.ä. benötigt wird? Scheint mir eine geniale Idee zu sein, eigentlich zu einfach, dass es funktionieren könnte. Andererseits spricht nix dagegen, außerhalb der Compilierung müssen wohl keine Elemente erzeugt werden. Das kann ja heiter werden, irgendwann haben wir den Punkt erreicht, an dem dir niemand mehr folgen kann. Hajo, streng dich an!;-) Grüße, Guido
Mist, dann habe ich es nicht gut genug erklärt. Eigentlich ist die Idee, das es einfacher wird. Zumindest in der Benutzung. Die fertige Lösung ist ja oft einfach, man fragt sich dann warum man nicht gleich drauf gekommen ist. Ja, es ist wirklich nur eine "linked list", wie du schreibst. Jeder zu setzende Parameter kann eine haben, muß aber nicht. Am Anfang wird einmal eine feste Anzahl von View-Deskriptoren allokiert und hintereindergekettet als Liste der freien abgelegt. Stell dir eine Kette von Post-It Haftnotizen vor. Wenn nun ein View für einen bestimmten Parameter angemeldet wird, dann wird das oberste Post-It aus der Frei-Liste abgezogen, die verbliebene Kette wieder an die Stelle gepappt. Das Post-It wird nun beschriftet wer zu benachrichtigen ist, dann neben den gewünschten Parameter geklebt. Wenn da schon einer oder mehrere klebten, dann kommt die vorhandene Kette hintenan. Wenn sich später ein Parameter ändert und was danebenklebt, dann wird die Kette durchgegangen und alle benachrichtigt. Wenn ein View sich von einem Parameter abmeldet, dann muß doch ein klein bischen gesucht werden. Die Post-Its neben dem Parameter werden durchgegangen, bis der gesuchte gefunden ist. (Das sind aber selbst im Extremfall nur wenige.) Die Kette wird dort aufgeteilt, der Gesuchte entnommen, und wieder zusammengefügt. Der nun freie Zettel kommt zurück in die Frei-Liste. Wieder vorne an, weil das am wenigsten Arbeit macht. Mittlerweile habe ich den Code getestet, er scheint auf Anhieb zu funktionieren. Ich habe das aber noch nicht bis ins letzte Detail durchgetestet, mit mehrere, entfernen und so. Was anderes ist mir auf die Füße gefallen: Die Idee ist, ich mache nur zur Initialisierung meine malloc()s, gebe den Speicher dann nie wieder frei. So kann nichts fragmentieren. Bei unserer Umgebung funktionier malloc() aber nicht, es gibt immer Null zurück. Hayo, nicht das du dich wunderst. Ich habe dann mal ins Disassembly der libc geguckt (leider kein Sourcecode), was da schiefgeht. Glücklicherweise habe ich es schnell gefunden, reiner Zufall: Das eigentliche Allokieren auf dem Heap macht eine interne Funktion namens _sbrk(). Die geht von einer Variablen am Anfang des Heaps aus, wo das aktuelle Heap-Ende verzeichnet ist. Meiner Meinung nach ist das da ein Fehler. Es gibt diese Variable zwar, aber das ist eine reine Linker-Adresse, ohne Inhalt. Man kann es aber "reparieren", indem man dort tatsächlich den Heap verzeichnet, auf hinter die Variable selbst. Ich habe am Anfang meines main() nun folgendes stehen:
1 | // bugfix for heap manager, _sbrk() expects this to be a variable and point to heap |
2 | extern uint32_t* _nasys_uninitialized_storage_end; |
3 | _nasys_uninitialized_storage_end = (uint32_t*)&_nasys_uninitialized_storage_end + 1; |
Voila, in Folge klappt es auch mit malloc(). Könnte man auch in einer Platform-Initialisierung verstecken oder in den Startupcode einarbeiten. Eine Unschönheit bleibt: Die Implementation von _sbrk() nimmt als Kriterium für kein-Speicher-mehr-verfügbar, ob der Heap dem Stack nahekommt. Ist so Standard. Bei uns ist dazwischen aber noch der Framebuffer, die Funktion müßte stattdessen testen ob der erreicht würde. Ich kann _sbrk() nicht überschreiben (habe es versucht), das Original wird nicht als "weak" gelinkt und die doppelte Funktion verursacht einen Fehler. Damit müssen wir also leben, müssen selbst drauf achten nicht bis in den Bildspeicher zu allokieren, oder unsere eigene Speicherverwaltung schreiben. Für nur allokieren und nie wieder freigeben ist das ganz einfach, nur einen Zeiger hochsetzen. Jörg
Hi, schön zu hören dass Du voran kommst. Leider hab ich momentan überhaupt keine Zeit, da ich für den SBF See/Binnen lerne und mich demnächst für die Prüfung anmelde. Dabei kribbelt es mir in den Fingern. Ich will noch die ADC-Treiber fertig optimieren und bei OSOZ einpflegen. Weiterhin hab ich auch schon eine Idee für eine neue Funktion des Oszis im Hinterkopf... Jörg H. schrieb: > Bei unserer Umgebung funktionier malloc() aber nicht, es gibt immer Null > zurück. Hayo, nicht das du dich wunderst. Das hab ich schon. Ich wollte schon vor einiger Zeit das alte Coding auf malloc() umrüsten, bin dabei aber wie schon von Dir beschrieben auf die Nase gefallen. Ich hab dann aber nicht so tiefenwirksam weitergeforscht wie Du sondern es erstmal auf sich beruhen lassen, bzw. bin dazu übergegangen den Speicher per Arrays zu allokieren. Dein Patch hört sich cool an, werd ich natürlich wenn ich wieder Zeit habe übernehmen. Auch Dein MVC Konzept hört sich gut an, bin gespannt ob das so aufgeht. Gruß Hayo
Danke Jörg, jetzt kapiere ich es. Die Vorratsliste muss bei der Initialisierung ja verkettet werden. Das kann der Compiler so nicht übernehmen. Mir gefällt das Prinzip aber völlig unabhängig von OSOZ, das wäre was für meinen Compiler, ich mag die linked lists, will aber keine dynamische Speicherverwaltung implementieren. Grüße, Guido
Angehängte Dateien:
-
pixel-art-radius.gif
1,6 KB
Was ganz anderes: Haben wir "Grafikkünstler" unter uns? Ich arbeite im Vorfeld des UI gerade an abgerundeten Ecken. Siehe Anhang für die ersten 10 Radien, das dürfte reichen. Geht es noch besser? (ohne Antialiasing, wir haben nur Bitmaps) Ganz wichtiges Thema, schon klar. ;-) Hayo W. schrieb: > Ich will noch die ADC-Treiber > fertig optimieren und bei OSOZ einpflegen. Gern, läuft derzeit auch nicht weg. Mit dem UI-Kram bin ich noch eine Weile beschäftigt. Hayo W. schrieb: > Weiterhin hab ich auch schon > eine Idee für eine neue Funktion des Oszis im Hinterkopf... Irgendwas, was wir bei Osoz frühzeitig berücksichtigen sollten? Oder "Spielkram"? ;-) Guido schrieb: > das wäre was > für meinen Compiler, Wie, deinen Compiler? Schreibst du einen? Jörg
Hallo Jörg, Jörg H. schrieb: > Model-View-Controller ist das > anerkannt beste Konzept für sowas. diese Konzept kannte ich bisher auch noch nicht. Ich habe mich gerade in Wikipedia etwas eingelesen. Ich muss gestehen, dass ich dies derzeit zwar nicht benötige aber dergleichen sollte man schon in der Hinterhand haben. Kannst Du mir Literatur dazu empfehlen? Mit freundlichen Grüßen Guido (Nicht der nicht angemeldete Guido)
Hallo angemeldeter Guido, wie ich hier schon schrieb: Jörg H. schrieb: > Siehe z.B. hier, Wikipedia fand ich ausnahmsweise nicht so hilfreich: > http://msdn.microsoft.com/en-us/library/ff649643.aspx > (Die Web-spezifischen Details bitte überlesen.) > Es gibt aber noch unzählige weitere Literatur. und: Jörg H. schrieb: > Ich habe leider keine Literatur oder Open Source gefunden, wie man MVC > im kleinen effizient auf einer Embedded Plattform umsetzt. Dieses Rad > erfindet vermutlich jeder Gerätehersteller der weit genug ist selbst, > oder es bleibt verborgen in kommerziellen Tool-Baukästen. Die konkrete > Lösung wie's jeweils optimal gelöst ist mag aber auch sehr speziell > sein. Eine heiße Spur hatte ich nicht. Die beiden Kernfeatures meiner Implementation sind das zentrale Setzen von Parametern, die dann nicht nur gespeichert werden sondern auch Gerätefunktionen auslösen, und die (dynamische) Registrierung von Benachrichtigungen auf Änderungen. Damit im Hinterkopf ist es eigentlich trivial. Als Besonderheit habe ich noch Arrays "im Programm", ein Parameter kann auch ein Array sein, die dann gleichartig behandelt werden. Jörg
Angehängte Dateien:
-
buttons.png
5,2 KB
Ach ja, ich wollte ja noch was zu den Menübuttons schreiben. Hoffentlich hat Hayo zwischen seiner Prüfungsvorbereitung noch einen Augenblick, um das zu überprüfen. Ich habe mich mal so durchgeklickt und Screenshots gemacht, versucht alle Arten von Buttons zu finden. Siehe angehängte Collage. Hier der Versuch einer Klassifizierung: Bis auf den Fall 10. im Bild gibt es immer zwei Zeilen. Die erste Zeile kann folgende Elemente haben: - ein optionales Icon vorab, mit den Möglichkeiten: - Drehregler-Icon, aktiv rot oder inaktiv grau (Bild 9.) - Drehregler+Taste Icon, aktiv rot oder inaktiv grau (Bild 4.) - Popup-Icon (Bild 2.) - statischen Text (Bild 1.) - statischen Text mit eingebetteter Kanalnummer (Bild 6.) - statischen Text mit angehängtem Kanalsymbol (Bild 9.) - Icon, was dann zentriert für den Button gilt (Bild 10.) Die zweite Zeile kann folgende Elemente haben: - statischen Text (Bild 1.) - statischen Text mit eingebetteter Kanalnummer - Icon (Bild 5.) - einen Wert: - Enum-Wert als Text (Bild 9.) - Zeitwert (Bild 6.) - Spannungswert - Prozentwert - kleiner Button mit Bool-Wert (Bild 8.) - positioniertes Checkmark (Bild 12.) Die große Frage ist, habe ich alles erwischt? Das will ich also versuchen in einer Datenstruktur abzubilden, so daß der Button ohne individuellen Code auskommt. Eklig ist Bild 11. und 12., da schwebt mir ein "custom" Handler vor, damit man solche Sonderfälle doch individuell ausprogrammieren kann. Jörg
Angemeldet bin schon, nur nicht eingelogged. Jörg H. schrieb: > Wie, deinen Compiler? Schreibst du einen? Jeder hat doch seine Hobbies: Beitrag "Ein kleiner Oberoncompiler für die C16x-Familie" Grüße, Guido
Hallo Jörg, vielen Dank für die Rückmeldung. Jörg H. schrieb: > Jörg H. schrieb: >> Ich habe leider keine Literatur oder Open Source gefunden, wie man MVC >> im kleinen effizient auf einer Embedded Plattform umsetzt. Dieses Rad >> erfindet vermutlich jeder Gerätehersteller der weit genug ist selbst, >> oder es bleibt verborgen in kommerziellen Tool-Baukästen. Die konkrete >> Lösung wie's jeweils optimal gelöst ist mag aber auch sehr speziell >> sein. Dies habe ich gelesen und auch verstanden ;-) Ich dacht Du hättest vielleicht einen Literatur-Tipp, der die Sache etwas allgemeiner angeht. Wie bereits erwähnt ich höre den Begriff MVC heute zum ersten mal. Das was ich bisher darüber gelesen habe gefällt mir sehr gut. Mit freundlichen Grüßen Guido
Hallo, Guido schrieb: > Angemeldet bin schon, nur nicht eingelogged. LOL, dann haben wir jetzt einen "Guido B." und einen "Guido C." in diesem Thread. Mit freundlichen Grüßen Guido
Guido C. schrieb: > Dies habe ich gelesen und auch verstanden ;-) Ich dacht Du hättest > vielleicht einen Literatur-Tipp, der die Sache etwas allgemeiner angeht. > Wie bereits erwähnt ich höre den Begriff MVC heute zum ersten mal. Das > was ich bisher darüber gelesen habe gefällt mir sehr gut. Kann dir die "Gang of Four, GoF", [1] empfehlen. Ein Standardwerk in Sachen Designpatterns. [1] http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612
Hallo, Robert S. schrieb: > Kann dir die "Gang of Four, GoF", [1] empfehlen. Ein Standardwerk in > Sachen Designpatterns. Danke für den Tipp. Das Buch hat auf Amazon erstaunlich gute Bewertungen. Werde ich mir auf jeden Fall ansehen. Mit freundlichen Grüßen Guido
Jörg H. schrieb: > Hayo W. schrieb: >> Weiterhin hab ich auch schon >> eine Idee für eine neue Funktion des Oszis im Hinterkopf... > > Irgendwas, was wir bei Osoz frühzeitig berücksichtigen sollten? Oder > "Spielkram"? ;-) In meinen Augen kein Spielkram, aber muß aus Performancegründen ebenfalls auf Treiberlevel implementiert werden. Vorabtests und UAT (User Acceptance Test) werde ich auf der alten Firmware durchführen, dann kann man entscheiden ob OSOZ das braucht oder nicht. Jörg H. schrieb: > Hoffentlich > hat Hayo zwischen seiner Prüfungsvorbereitung noch einen Augenblick, um > das zu überprüfen. Klar doch, es gibt noch einen Button (in der originalen Firmware) den ich aber nicht mehr verwende. Evtl. willst Du den noch mit aufnehmen. Es ist eine Kombination aus 8 und 12. Statt Checkbox ist da ein Haken wenn aktiv und kein Haken wenn inaktiv. Gruß Hayo
kleines Update zum Status: ich habe die Implementation der Buttons im allgemeinen und die generische Zeichenfunktion jetzt fertig, siehe svn. Das Layout ist "ordentlich" definiert, es gibt anfangs ein paar Definitionen für Größe, Raster, Zeichenpositionen, daraus wird im Code alles abgeleitet. Es stehen also keine "magischen Zahlen" drin, ist leicht zu ändern. Schaut auf dem Bildschirm schon ganz gut aus. Statuszeile und Grid gibt es auch bereits. Man könnte fast meinen es wäre ein Oszilloskop. ;-) Ich habe mit Absicht den Fall 6. aus meinem obigem Bild nicht eingebaut (eine in den Text eingebettete Kanalnummer), sondern nur den Fall 9. (Kanalnummer als Icon angehängt). Das war irgendwie doppelt gemoppelt, und letzteres finde ich hübscher, war nebenbei auch einfacher zu implementieren. Ist das eine sinnvolle/zulässige Vereinfachung? Was noch fehlt sind die speziellen Zeichenfunktionen für Werte. Die habe ich noch nicht drin, auch weil mir die übergeordnete Menüverwaltung noch fehlt. Die ist als nächstes dran, macht dann auch die Anmeldung der Buttons als Views von MVC. Jörg
Oster-Osoz: Ich war über die Feiertage fleißig, es gibt viel neues. Osoz hat jetzt die Infrastruktur für ein Menüsystem aus obigen Buttons. Auch Popups sind schon drin, man kann auf einem Testmenü rumdrücken/drehen, was hauptsächlich die korrekten MVC-Benachrichtigungen testen soll. Das Hauptprogramm main.c ist jetzt kein Unit-Testcode mehr, sondern entwickelt sich zu dem echten Ding. Gestern habe ich noch dem Capture-Treiber erstes Leben eingehaucht und ein Modul zum Signalzeichnen angefangen. Nun sieht man auch allererstes Wellengezappel. Mit Messen hat das aber noch nichts zu tun, bitte keine falschen Erwartungen. Es gibt keinen Trigger, Zeitbasis ist immer 1GS, keine Skalierung. Man kann aber an Amplitude und Offset herumdrehen, die Relais klickern. Nach all den Arbeiten im Untergrund kommt nun also erstmals was an die Oberfläche. Hier wurde ich früher schon nach einer Vor-Vorversion gefragt, aber es gab nichts zu sehen, nur Unterbau. Hier im Anhang also was allererstes. Osoz ist trotzdem ein Eisberg, das meiste bleibt noch verborgen. Erste Qualitäten sind aber sichtbar. Die Menüs ploppen viel schneller auf, in der alten Firmware kann man dabei zugucken, hier sind sie einfach da. Wenn ein Popup offen ist arbeitet der Rest weiter, es bleibt nicht alles stehen. Es kann langsam losgehen, im Application-Land. Mitarbeit ist mehr denn je willkommen. Als nächstes steht im Unterbau noch an, die Eingangsstufen richtig auszunutzen, die Signale korrekt zu skalieren, den Offset darauf zu beziehen. Im Capture-Treiber ist noch viel zu tun, Triggerung, Zeitbasis, Signale korrekt auslesen, Workarounds. Weiter oben fehlt Infrastruktur für die Meßwert-Bubbles, deren Interaktion mit Popup-Menüs, von denen sie verdeckt werden können. Ganz oben noch jede Menge, da geht's ja gerade erst los. So long, Jörg
Hallo Jörg, hab mir das Osoz gerade mal angeschaut. Mit den Qualitäten hast du recht, die Bedienung wirkt extrem flüssig, wenn das so bleibt - die Firmware wird im Moment ja noch nicht so viele Aufgaben zu erledigen haben - ist das schon mal eine wunderbare Sache, im Moment kommt mir die Bedienung flüssiger vor als bei den 10x so teuren Tektronix-Geräten, mit denen ich in der Uni ab und zu gearbeitet habe. Das lässt die schlechte Haptik der Drehregler und Taster des Welecs vergessen :) Von der praktischen Seite kann ich leider nichts beitragen, wenn die Firmware langsam an Funktionsumfang gewinnt werde ich aber gerne Beta-Tester spielen und Feedback geben. Echt klasse, was hier auf die Beine gestellt wird - vielen Dank an alle Beteiligten! Gruß Sebastian
Hallo zusammen, ich wollte auch mal testen, allerdings falle ich unter linux (aktuelles (K)Ubuntu, echte RS232) noch auf die Nase: loading firmware to RAM... GERMSloader.pl Ver 1.2.0 *** No Warranty *** *** This program is distributed in the hope that it will be useful, *** but is provided AS IS with ABSOLUTELY NO WARRANTY; *** The entire risk as to the quality and performance *** of the program is with you. Should the program prove defective, *** you assume the cost of all necessary servicing, repair or correction. *** In no event will any of the developers, or any other party, *** be liable to anyone for damages arising out of the use or inability *** to use the program. Device : /dev/ttyS0 Flash filename : ramloader.germs UCL filename : TomCat_ram.ucl --- Writing GERMS firmware... Writing line 000012 of 000012: S8 detected, end of GERMS transmission. Successfully wrote GERMS firmware in 0.1 seconds! --- Writing compressed firmware (30686 bytes / 8 chunks of 4096 bytes)... Writing chunk 8 of 8 - 100.0% - 3.7 sec / 0 sec left Error: bad response from DSO! Error response was: '5' Firmware update was NOT successful! Kann ich irgendwas zur Fehlersuche beitragen? Viele Grüße, Rainer
Vermutlich hast du das gleiche Problem wie Hayo: Der serielle Treiber behauptet er kann 4096 Byte große Happen verarbeiten, aber er lügt und kriegt es nicht hin. Ersetze mal im Perl-Script die 4096 durch z.B. 4095. Jörg
Hallo Jörg, mit 4095 klappts. Super schnelle Sache, toll! Könnt Ihr das nicht automatisch erkennen? Wenn Linux -> 4095, sonst 4096? Oder ist das Problem nicht so verbreitet? Viele Grüße, Rainer PS: Meine geliebten Spikes sehe ich auch schon wieder...
Rainer H. schrieb: > Könnt Ihr das nicht automatisch erkennen? Wenn Linux -> 4095, sonst > 4096? Oder ist das Problem nicht so verbreitet? Das ist genau der Punkt. Bei mir geht es mit allen Geräten unter allen getesteten OS-Varianten mit 4096. /Hannes
Johannes S. schrieb: > Das ist genau der Punkt. Bei mir geht es mit allen Geräten unter allen > getesteten OS-Varianten mit 4096 Spricht aber wohl nichts dagegen, das trotzdem pauschal auf 4095 bzw.buffer_max-1 zu ändern. Werde ich bei Osoz mal tun. Leicht verwandtes anderes Thema: Osoz hat jetzt die Grundlagen für ein externes Kommandointerface, über RS232. Bisher tue ich damit nur eines: Jemand brachte mal das Thema SW-Update aus der laufenden Firmware heraus, ich finde es gerade nicht. Damit man nicht immer die beiden Knöpfe drücken muß. Das ist heikel, die Software müßte sich ja im laufenden Betrieb selbst überschreiben. Ginge nur mit einem autarken Stück Code, das an eine besondere Stelle kopiert wird. Mir ist jetzt eine ganz stumpfe Lösung eingefallen: ich springe zurück in den ROM-Monitor, und zwar an die Stelle hinter dem Tasten-Check. Dann kann das ganz normale GERMSloader-Prozedere stattfinden. Der Kommandoparser tut das wenn er eine S-Record Zeile erkennt. Das Perl-Script von Johannes macht glücklicherweise Retransmits, wenn die Zeile nicht bestätigt wurde. Beim erneuten Versuch sind wir im ROM-Code, dann klappt es und der UCL-Loader wird geladen. Sehr angenehmes Feature für meinen geplagten Entwicklerdaumen! Ich brauche nur in Eclipse auf "Run" zu drücken und automatisch geht alles los. Otto Normaluser startet ebenfalls einfach das Ramlod/Flashload-Script. Ansonsten hat Osoz jetzt minimale Zeitbasis-Unterstützung. Über das verrückte Capturing habe ich bereits im neuen Hardware-Thread geschrieben: Beitrag "Re: Wittig(welec) DSO W20xxA Hardware (Teil 2)" Jörg
Jörg H. schrieb: > Der Kommandoparser tut das wenn er eine S-Record Zeile erkennt. Das > Perl-Script von Johannes macht glücklicherweise Retransmits, wenn die > Zeile nicht bestätigt wurde. Beim erneuten Versuch sind wir im ROM-Code, > dann klappt es und der UCL-Loader wird geladen. Coole Idee! /Hannes
Ich blogge mal wieder ein bischen, was in den letzten knapp 2 Wochen passiert ist. Einiges, man sieht schon viel mehr: Mein Daumen hat sich gut erholt, jetzt wo ich neue Firmware einfach durchstarten 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. Kanal 3+4 sind hinzugekommen. Das Kanalmenü ist mit der Kanalnummer parametriert. Ein paar Dinge wie AC/DC Kopplung, Bandbreitenlimit und Invertierung sind dort auswählbar. Es gibt eine ganz rudimentäre Zeitbasis, 1GSa/n, das 'n' ist einstellbar. Alle Hauptmenüs sind zumindest angelegt, auch wenn oft nur TODO drinsteht. Alle Tasten tun bereits was (z.B. solche TODO-Menüs aufrufen ;-), die LEDs sind mit Funktion. Es gibt etwas Auswahl bei den Zeichenfunktion, "dots" und "persist" sind im Displaymenü auswählbar. Das Zeichnen geschieht jetzt im Hintergrund, mit Doppelpufferung, die Darstellung flackert nicht mehr. Als Optimierung wird nur so viel gelöscht/kompiert wie die Welle gerade hoch ist. Dank der maximal schnellen Kopierroutine memcpy32() (die damals für den Flash-Boot entstanden ist) und der davon abgeleiteten Löschfunktion memset32() kostet das fast keine Extra-Zeit. Ich habe das Zeichnen jetzt so gelöst, das es pro Kanal 4 Tabellen gibt (für jeden ADC eine), welcher ADC-Wert wo auf dem Bildschirm abgebildet wird. Diese Tabellen werden bei Bereichswechseln on the fly neu berechnet, mit schneller Festkommaarithmetik. So können Unterschiede der Kennlinen, sowie der Meßbereich und Clipping alles mit abgefrühstückt werden. Beim Zeichnen muß dann nichts mehr gerechnet oder geprüft werden. Braucht letztlich nicht viel Speicher, 2kB pro Kanal. (Verglichen mit den 16k Capture-Buffer und 37,5kB Screen-Backbuffer.) Ein etwas größerer Themenkomplex war die Parametrierung der Kanäle, damit die Bildschirmdarstellung die richtige Höhe hat und die Offset-DACs mit der richtigen Ãœbersetzung arbeiten, um gleichauf zu bleiben. Das habe ich jetzt in erster Version, für alle 3 möglichen Eingangsstufen. Mischbetrieb ist möglich, kostet nichts extra, z.Zt. habe ich meinen Kanal 1 wieder in den Originalzustand versetzt, Kanal 2 mit den korrigierten Widerständen, Kanal 3+4 mit neuer Eingangsstufe. Auch neu hinzugekommen sind die seitlichen Skalen, die DC-Werte und Triggerlevel anzeigen. Das sind "einfach" weitere angemeldete Views von MVC, sie verrichten ihre Arbeit dann ganz alleine. Als nächstes befasse ich mich mit der Kalibrierung, um die DC-Offsets der Kanäle und vielleicht auch die ADC-Kennlinien zu bestimmen. Es wäre auch denkbar, die jeweilige Eingangsstufe automatisch zu erkennen, nämlich daran wie programmierte Test-Offsets denn so "wirken". Kennt sich jemand mit Statistik aus? Es geht um gestörte Meßwerte, Ausreißerelimination, Ausgleichsgeraden, solcherlei. Dann wäre Persistenz in's Flash ganz praktisch, damit Osoz nicht immer alles vergißt. Sollte nicht so schwierig sein, derzeit ist noch alles im Model konzentriert. Wenn ich die beiden Dinge habe mache ich wieder eine Probierversion fertig. Ich habe recht oft das Gefühl, das Rad ein zweites Mal zu erfinden (wie kommt das bloß?), wenn ich die bestehende UI nachbaue. Da mache ich wahrscheinlich die gleiche Lernkurve durch wie Wittig und Hayo vor mir. Apropos, Hayo, wann bist du mit deiner Büffelei durch? Oft würde ich gern kleine Dinge auf kurzem Wege fragen. Und dir einen Osoz-Kurs geben, denn ich finde der Applikationslayer ist jetzt reif genug für Mitarbeit. So long, Jörg
Einen Aufruf habe ich noch vergessen: Was soll Osoz denn so neues können sollen, was vorher konzeptionell nicht ging und nun vielleicht möglich wäre? Im Moment baue ich quasi die alte Software nach, das muß ja nicht immer überall das Optimum sein. Jörg
Auweiah Jörg, weck doch keine schlafenden Hunde. Jetzt kommen bestimmt die Bussniffer wieder und wollen Protokollanalysen für Alles. ;-) Grüße, Guido
Hi Jörg, Du machst ja enorme Fortschritte. 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. Bin gespannt was da unterm Strich bei rauskommt. Ich habe am 12.5 die erste Prüfung, dann am 9.6. die zweite. Ich hoffen mal dass ich vorher wieder etwas Zeit finde um mich hier einzubringen - will ja auch nicht das Beste verpassen ;-) Jörg H. schrieb: > 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? Gruß Hayo
Guido schrieb: > weck doch keine schlafenden Hunde. Jetzt kommen bestimmt die > Bussniffer wieder und wollen Protokollanalysen für Alles. ;-) Können sie sich gerne bauen... ;-) Ich dachte auch schon mal an eine Plugin-Schnittstelle, um das irgendwie modular zu kriegen. Für den konkreten Fall haben wir aber mit unseren zumeist 4kB sehr wenig Capture-Speicher, und verwechseln ein Scope hoffentlich nicht mit einem Logic Analyzer. Off topic: Ich habe einen USBee SX, seehr nützlich, das sinnvollste Gerätchen was ich seit Jahren gekauft habe! Der bringt Protokollanalyzer für alles Mögliche mit, man kann sampleln bis der PC-Speicher voll ist. Trigger war gestern, heute einfach alles mitschneiden und dann gucken. On Topic: Mir geht es drum, ob ich in die richtige Richtung arbeite. Wollen wir das wieder so haben, oder was wäre denkbar? Ich kenne mich mit aktuellen Oszilloskopen zugegeben wenig aus, mache damit nicht viel. Jörg
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 | void PlatformMonitor(void) |
3 | {
|
4 | uint32_t startaddress = 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 |
7 | |
8 | fnBoot(); // call the bootloader |
9 | // we won't return from here
|
10 | }
|
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 Jörg, habe die aktuelle Version nochmal getestet. Das Problem bleibt leider wie oben beschrieben. Gruß Sebastian
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
Warum das Rad neu erfinden und nicht einfach libpng oder {g,b,x}zip
nehmen?
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
Angehängte Dateien:
-
Calibrate-Offsets-01.jpg
120 KB -
Calibrate-ADCs-01.jpg
120 KB -
1kHz-Trigger-01.jpg
120 KB -
1kHz-Trigger-02.jpg
110 KB -
Persist-01.jpg
110 KB
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
Nicht siegen ... kommt nicht von sehen ... es ist aber sehen gemeint ;-) Andiiiiy
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
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:
static inline int smul16(short mul1, short mul2)
{
register int res asm("o3");
asm volatile ("
MOV %%r0,%0 \n
LSLI %%r0,16 \n
MOV %%r1,%1 \n
LSLI %%r1,16 \n
MSTEP %1 \n
MSTEP %1 \n
MSTEP %1 \n
MSTEP %1 \n
MSTEP %1 \n
MSTEP %1 \n
MSTEP %1 \n
MSTEP %1 \n
MSTEP %1 \n
MSTEP %1 \n
MSTEP %1 \n
MSTEP %1 \n
MSTEP %1 \n
MSTEP %1 \n
MSTEP %1 \n
MSTEP %1 \n
SKP0 %0,31 \n
SUB %%r0,%%r1 \n
SKP0 %%r1,31 \n
ADD %%r0,%1 \n
MOV %%o3,%%r0;
"
:
: "r" (mul1) , "r" (mul2)
: "o3", "r0" , "g1"
);
return res;
}
Gruß Hayo
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
Jörg H. schrieb: > Bei dem Quartus-Projekt gibt es leider einen absoluten Pfad, den man > individuell ändern muß. Einen Hinweis möchte ich an der Stelle geben. Der angesprochene absolute Pfad befindet sich im File: http://welecw2000a.svn.sourceforge.net/viewvc/welecw2000a/osoz/platform/nios2/bsp/settings.bsp?revision=852&view=markup Zeile 7. ... diesen solltest Du unbedingt an den Checkout-Pfad anpassen. Gruß Andi
Ok, das ist doch ein Hinweis. da werd ich mal suchen. Danke Hayo
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
Stimmt, ich erinnere mich dunkel. Das blieb leider ein ungelöstes Mysterium... Jörg
Btw. muß ich die Addon Devices noch installieren, oder wird das nicht benötigt? Hayo
Zumindest den Cyclone II. Die anderen Altera-FPGAs sind nicht nötig. Wirst du aber haben, sonst ginge ja gar nichts. Jörg
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
Sebastian ... schrieb: > obwohl ich garkein Welec habe > und auch keines kaufen werde. Das ändert sich ja vielleicht noch... ;-)
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
Angehängte Dateien:
-
100_2625.JPG
310 KB -
100_2626.JPG
330 KB
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
Angehängte Dateien:
-
Stoerungen.jpg
150 KB
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
Angehängte Dateien:
-
Stoerungen3.jpg
210 KB -
Stoerungen4.jpg
150 KB
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
Angehängte Dateien:
-
Hauptplatinen.jpg
170 KB
Hayo W. schrieb: > ich muß leider gerade passen, da meine Schätzchen wieder zerlegt auf dem > Rücken liegen. So sieht das dann in Natura 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.
Angehängte Dateien:
-
BF.6.4C6-80MHz-Rechteck.jpg
89 KB -
OSOZ-80MHz-Rechteck.jpg
89 KB
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
Angehängte Dateien:
-
OSOZ-1kHz-Delay-01.jpg
72 KB -
OSOZ-1kHz-Delay-02.jpg
94 KB
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
Angehängte Dateien:
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
Zum Display, ich mache gerade eine Aufstellung von Displays, die in Frage kommen. Hat jemand eine Grundlage / Übersicht? Vor zwei Jahren habe ich schon mal geschrieben: Beitrag "Re: Welec W20xx Bedienelemente modifizieren: Drehgeber Encoder LED BNC-Buchsen" Eine Möglichkeit statt SVGA (800x600) ist WVGA (800x480), z.B. dieses: AUO AU Optronics A070VW04 http://www.beyondinfinite.com/lcd/Library/Auo/A070VW04_V0.pdf C. General Information 1 Display Resolution dot 800RGB(H) x 480(V) 2 Active Area mm 152.49 x 91.44 3 Screen Size inch 7.0 (Diagonal) 4 Pixel Pitch mm 0.1905 x 0.1905 5 Color Config -- R G B Stripe Note1 6 Color Depth -- 16.7 M Colors Note2 7 Overall Dimensions mm 164 x 103 x 5.1 Note3 8 Weight g 153.5 +/- 10% 9 Panel surface treat -- Anti-Glare 10 Display Mode -- Normally White Die gibt es als ASUS-Ersatzteil für ca. 90 Euro Product code: 18G240700310 EAN: 5711045166181 Oder dieses VGG804805-6UFLWD 7" gibt es für 30 Euro http://www.ebay.de/itm/LCD-DISPLAY-TFT-VGG804805-6UFLWD-7-WVGA-Landscape-NEU-/310405203669?pt=Bauteile&hash=item48459786d5
1 | Sharp |
2 | 7.0 LQ070Y5DG06 800x480 152.4x91.44 165.0x105.5x12.0 310 540 LED No Need 6-bit digital RGB |
3 | 7.5 LQ075V3DG01 640x480 151.68x113.76 179.0x139.5x12.7 600 400 1 CCFT CXA-0492 6-bit digital RGB Strong 2 |
4 | 8.0 LQ080Y5DR02 800x480 174.0x104.4 165.0x105.5x12.0 250 625 2 CCFT TBD 6-bit digital RGB |
5 | 8.4 LQ084S3DG01 800x600 170.4x127.8 191.5x149.5x12.0 250 350 2 CCFT CXA-L0612A-VJL 6-bit digital RGB |
6 | 8.4 LQ084S3LG01 800x600 170.4x127.8 191.5x149.5x12.0 600 400 2 CCFT CXA-L0612A-VJL LVDS Strong 2 |
7 | |
8 | Hitachi |
9 | 7.0 TX18D16VM1CAA 800x480 165.0x106.0x10.5 153.0x92.0 CFL 350 350 • • TX18D16VM1CBA INVC617, |
10 | INVC657 |
11 | 50k hr CFL, High Brightness, Wide Viewing |
12 | Angle |
13 | 7.0 TX18D16VM1CAB 800x480 165.0x106.0x10.5 153.0x92.0 CFL 600 350 • • TX18D16VM1CBB INVC617, |
14 | INVC657 |
15 | High Bright version |
16 | 7.0 TX18D57VM2BAA 800x480 167.8x108.6x15.6 152.4x91.44 CFL 450 600 • • • TX18D57VM2BBA n/a Wide Temp |
17 | 8.0 TX20D16VM2BAA 800x480 189.0x120.0x10.5 174.0x105.0 CFL 350 350 • • TX20D16VM2BBA INVC617, |
18 | INVC657 |
19 | 50k hr CFL, High Brightness, Wide Viewing |
20 | Angle |
21 | 8.0 TX20D17VM2BAA 800x480 192.0x123.5x10.7 174.0x104.0 CFL 600 200 • • TX20D17VM2BBA n/a High Brightness (SHB) |
22 | 8.0 TX20D19VM2BAA 800x480 192.0x123.5x10.7 174.0x104.0 LED 350 350 • • • TX20D19VM2BPA n/a High Brightness (SHB) |
23 | |
24 | Toshiba |
25 | 7.0 LTA070A320F 800x480 152.4x91.44 170.8x110.0x8.7 300 350 CFL CXA-L0612A-VSL CMOS Widescreen 15:9 format |
26 | 7.0 LTA070A321F 800x480 152.4x91.44 170.8x110.0x10.0 300 280 CFL CXA-L0612A-VSL CMOS Widescreen 15:9 format with Touch |
27 | 7.0 LT070AA32600 800x480 152.4x91.44 170.8x110.0x8.7 450 450 LED Not Required CMOS Widescreen 15:9 format |
28 | 7.5 LTA075A361F 640x480 152.0x114.0 195.2x137.5x7.5 450 350 CFL LXMG1617A-12-41 CMOS High Brightness |
29 | 7.5 LTA075A362F 640x480 152.0x114.0 195.2x137.5x9.0 450 280 CFL LXMG1617A-12-41 CMOS High Brightness with Touch |
30 | 8.4 LTA084C380F 640x480 170.4x127.8 221.0x152.4x12.0 300 250 CFL CXA-0395 CMOS Wide Bezel format |
31 | 8.4 LTM08C351S 800x600 170.4x127.8 199.5x149.5x12.0 300 350 CFL CXA-0395 CMOS Wide Viewing Angle |
32 | 8.4 LTM08C351L 800x600 170.4x127.8 199.5x149.5x12.0 300 350 CFL CXA-0395 LVDS Wide Viewing Angle |
33 | 8.4 LTM08C351R 800x600 170.4x127.8 199.5x149.5x12.0 300 350 CFL CXA-0395 LVDS Wide Viewing Angle with AR (Low Reflection) |
34 | 8.4 LTA08C270F 800x600 170.4x127.8 199.5x149.5x12.0 450 400 CFL CXA-0395 LVDS Wide-Temp |
35 | 8.4 LTA08C272F 800x600 170.4x127.8 199.5x149.5x12.0 450 320 CFL CXA-0395 LVDS Wide-Temp with Touch |
36 | 8.4 LTA08C271F 800x600 170.4x127.8 199.5x149.5x12.0 450 400 LED Not Required LVDS Wide Viewing Angle |
37 | 8.4 LTA084C191F 800x600 172.4x129.8 203.0x143.5x6.5 350 TBC CFL CXA-0395 CMOS Single lamp |
38 | 8.4 LTA084C190F 800x600 172.4x129.8 203.0x143.5x8.0 350 180 CFL CXA-0395 CMOS With Touch |
39 | 8.4 LT084AC37000 1024x768 170.4x127.8 199.5x149.5x12.0 400 400 LED Not Required LVDS High Brightness, Wide Viewing Angle, Wide-Temp |
40 | 8.5 LTA085C185F 800x480 189.8x116.0 224.0x135.0x11.0 450 270 CFL LXMG1617A-12-61 CMOS Widescreen 15:9 format |
41 | 8.5 LTA085C184F 800x480 189.8x116.0 224.0x135.0x13.5 250 215 CFL LXMG1617A-12-61 CMOS Widescreen 15:9 format with Touch |
42 | 8.9 LTD089EXWS 1280x768 193.3x116.4 224.0x133.0x5.1 140 225 LED Not Required LVDS Widescreen Transflective type |
43 | |
44 | NEC |
45 | 6.3 NL10276BC12-02 1024 x 768 250 0 to +65 500 179 x 127 x 12 3.3 CXA-0321 LVDS High resolution, Antiglare |
46 | 6.5 NL6448BC20-18D 640 x 480 400 –10 to +70 600 153 x 118 x 10.5 3.3 / 5 CXA-0420 CMOS Shrink size, antiglare, high brightness |
47 | 6.5 NL6448BC20-20 640 x 480 650 –10 to +70 600 153 x 118 x 10.5 3.3 / 5 CXA-0420 CMOS ST-NLT Model based on NL6448BC20-18D |
48 | 6.5 NL6448BC20-21C 640 x 480 800 –20 to +70 600 153 x 118 x 9 3.3 n/a LVDS ST-NLT Model, LED Backlight, replaceable, Inv. PS-DA0609 |
49 | 6.5 NL6448BC20-21D 640 x 480 550 –20 to +70 600 153 x 118 x 9 3.3 n/a LVDS LED Backlight, replaceable |
50 | 6.5 NL10276BC13-01 1024 x 768 500 –20 to +70 500 153 x 118 x 9 3.3 n/a LVDS LED - Backlight replaceable, LED Conv.PS-LD0602-1-015 |
51 | 6.5 NL10276BC13-01C 1024 x 768 650 –20 to +70 500 153 x 118 x 9 3.3 n/a LVDS ST-NLT , LED - Backlight replaceable, Inv. PS-LD0602-1-015 |
52 | 7.0 NL4823BC37-05 480 x 234 400 –20 to +70 600 174.5 x 105.5 x 10.5 3.3 CXA-0489 CMOS Wide aspect ratio |
53 | 7.0 NL8048BC19-02 800 x 480 400 –20 to +70 1000 170 x 111 x 8.5 3.3 n/a LVDS Wide format, LED Backlight |
54 | 7.0 NL8048BC19-02C 800 x 480 550 –20 to +70 900 170 x 111 x 8.5 3.3 n/a LVDS Wide format, LED Backlight, NLT |
55 | 8.4 NL6448BC26-01 640 x 480 450 0 to +60 500 200 x 152 x 12 3.3 / 5 CXA-0326 CMOS High Brightness, low Power |
56 | 8.4 NL6448BC26-03 640 x 480 450 0 to +60 500 200 x 152 x 12 3.3 / 5 CXA-0326 CMOS Portrait Format |
57 | 8.4 NL6448BC26-08D 640 x 480 330 –10 to +70 500 200 x 152 x 11 3.3 CXA-0437 LVDS SFT - technology, super wide viewing angle |
58 | 8.4 NL6448BC26-09 640 x 480 450 –20 to +70 600 200 x 152 x 10.5 3.3 / 5 CXA-0437 CMOS Clear Surface, compatible with NL6448BC26-01 |
59 | 8.4 NL6448BC26-09C 640 x 480 750 –20 to +70 600 200 x 152 x 10.5 3.3 / 5 CXA-0437 CMOS ST-NLT Model based on NL6448BC26-09 |
60 | 8.4 NL6448BC26-09D 640 x 480 450 –20 to +70 600 200 x 152 x 10.5 3.3 / 5 CXA-0437 CMOS Antiglare Surface, compatible with NL6448BC26-01 |
61 | 8.4 NL6448BC26-15 640 x 480 450 –20 to +70 600 200 x 152 x 10.5 3.3 CXA-0437 LCDS High Brightness |
62 | 8.4 NL8060BC21-02 800 x 600 400 –20 to +70 600 200 x 152 x 10.5 3.3 CXA-0437 LVDS Wide Viewing Angle, |
63 | 8.4 NL8060BC21-03 800 x 600 850 –20 to +70 600 200 x 152 x 10.5 3.3 CXA-0437 LVDS ST-NLT Model based on NL8060BC21-02 |
64 | 8.4 NL8060BC21-04 800 x 600 400 –20 to +70 600 200 x 152 x 10.5 3,3 / 5 CXA-0437 CMOS CMOS Version of NL8060BC21-02 |
65 | |
66 | CCT Crystal Clear Technology |
67 | T4880C03WP01 7.0 800 x 480 Optional Digital White LED 165.0 x 104.0 x 6.20 Rev. D |
68 | T4880C01WP01 8.0 800 x 480 Digital White LED 192.80 x 116.90 x 6.40 Rev. A |
69 | T6080C01WP01 8.0 800 x 600 Digital White LED 183.0 x 141.0 x 6.30 Rev. A |
70 | |
71 | Evervision |
72 | 7.0" VGG804805-6UFLWA W-VGA 800 x 480 Digital 6-bit 166.6 x 107 x 10 –20 to +70 3.3 55/65/65/65 250 350 30 LED n/a LED Backlight |
73 | 7.0" VGG804805-6UFLWC W-VGA 800 x 480 Digital 6-bit 166.6 x 107 x 11.5 –20 to +70 3.3 55/65/65/65 250 280 30 LED n/a LED Backlight, Touch version |
74 | 7.0" VGG804805-6UFLWD W-VGA 800 x 480 Digital 6-bit 166.6 x 107 x 10 –20 to +70 3.3 55/65/65/65 250 500 30 LED n/a LED Backlight, Highbright |
75 | 7.0" VGG804805-6UFLWE W-VGA 800 x 480 Digital 6-bit 166.6 x 107 x 11,5 –20 to +70 3.3 55/65/65/65 250 400 30 LED n/a LED Backlight, Highbright, Touch |
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
Cooooole Sache!!! Dann kann ich sobald ich daheim bin auch mal mein Welec wieder ausgraben :) Super Arbeit Jört!
Wie cool ist das denn? Welche Funktionen sind denn schon für Kanal 3 + 4 implementiert? Gibt es schon eine Triggerung? Gruß 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
Hallo Torsten, wirehead schrieb: > Wie kann ich im Quartus Programmer das orginal Configflash sichern? es gibt in unserem Wiki eine kleine englische Anleitung! http://sourceforge.net/apps/trac/welecw2000a/wiki/FPGAConfigFlash Wie schon von Dir geschrieben ist es wichtig den Inhalt des EPCS16 zu sichern wobei zur Not zwei existierende Versionen im Forum rumgeistern. In der folgenden Liste sind eine User mit den bis jetzt gefundenen Versionen aufgeführt: http://sourceforge.net/apps/trac/welecw2000a/wiki/usersinstrument Grüße Andiiiy
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
@Jörg, öhm, das sehe ich ja jetzt erst! Wie machst du denn beim Osoz einen Screenshot? Bei mir steht "Print" (to do)
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
Oliver P. schrieb: > Gibt es da noch irgend etwas zu beachten? Naja, du brauchst vermutlich eine NIOS-Lizenz.
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
Ich habe hier die Version 9.0 Build 132
Kann es sein dass ihr die Version 9.1 nutzt?
Hallöchen, Oliver P. schrieb: > Kann es sein dass ihr die Version 9.1 nutzt? Ja, Jörg benutzt die Version 9.1 Build 350 (SP2)! Grüße
Das wird dann wohl der Grund sein dass es nicht funktioniert. Danke für die Aufklärung. Grüße Oliver
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! -
W2024: Run 0x00025544, total errors 0x00000000
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
MM quartus II 9.1 meint das das File corrupted ist... Hat jemand nen direcktlink zur Version 13.0.1? Gruß
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?
>MM quartus II 9.1 meint das das File corrupted ist...
Unter 13.0 läuft's ohne Probleme, bleibt also nur
13.0 runterzuladen un zu instalieren.
wirehead schrieb: > Hat jemand nen direcktlink zur Version 13.0.1? Zum Upload der .sof-Datei sollte der sog. "Quartus Programmer" ausreichen, das ganze Quartus braucht es dazu nicht. Hier der Link auf die aktuelle Version für Windows: http://download.altera.com/akdlm/software/acdsinst/13.0sp1/232/ib_installers/QuartusProgrammerSetup-13.0.1.232.exe Jörg
> MM quartus II 9.1 meint das das File corrupted ist... > Hat jemand nen direcktlink zur Version 13.0.1? bei mir dasselbe... Ich habe hier 2 Versionen vom Quartus Programmer: II 9.1sp2 und II 11.1 beide behaupten dasselbe! Jetzt muß noch eine 3. Version her oder kann Jörg das auch auf die früheren Versionen konvertieren? Gruß Michael
jetzt habe ich die über 100 MB runtergeladen und installiert, das wäre mit dem II 13.01 die 3. Version auf dem Rechner... Die SOF wird jetzt nicht mehr angepöpelt. > Nach dem .sof Reinladen ist das LCD schwarz, es kriegt merkwürdigerweise > den Reset nicht mit. Man kann F1+F2 gleichzeitig drücken um es zur Räson > zu bringen (manueller Reset). Dann sieht man auch schön das > Vollschreiben mit den Zufallsmustern. Mit F1+F2, meinst du wohl die beiden linken unteren Buttons?! Das Display ist nach laden der SOF Schwarz. Wenn ich beide Tasten drücke, habe ich schwarzen Schnee mit pinkfarbenen Hintergrund, soll das so sein? Gruß Michael
Ich kann es zumindest bestätigen, gerade ausprobiert: Quartus 12.1 kann die Datei verarbeiten, 11.0 nicht. Dazwischen muß irgendwas passiert sein. Wundert mich aber, sonst ist Altera sehr auf Kompatibilität bedacht. Ich habe noch keinen Weg gefunden, da was runter zu konvertieren. Auch ein draus erzeugtes .jic für das Config-Flash weist die Version 11 ab. Jörg
Unsere Postings haben sich überkreuzt, bzw. ich war zu langsam. ;-) Michael D. schrieb: > Mit F1+F2, meinst du wohl die beiden linken unteren Buttons?! Ja, die meine ich, nennen wir sie mal Softkeys 1+2. > Das Display ist nach laden der SOF Schwarz. > Wenn ich beide Tasten drücke, habe ich schwarzen Schnee mit pinkfarbenen > Hintergrund, soll das so sein? Ja, ist korrekt. Die violette Bitplane liegt (nach Wittig-Default) zuoberst. Jörg
Alles klar, dann stimmt ja alles soweit! Mein 2022, weißt bei dem Test schon mal keine Fehler auf, ist soweit i.O. Kann man über Quartus nicht das RAM sichern unter Attached Device? Habe da mal etwas experimentiert, aber irgendwie komme ich nicht ins RAM! Eine Sicherung "attached Device" funzt unter ver.9.1 und ist natürlich als jic 2MB groß. Beim wiederaufspielen startet das Scope aber nicht mehr ohne Neustart...
Hi, da ich jetzt 2h drann geknabbert habe die 13.0.1 unter XP-SP3 ans laufen zu bekommen, hier ein kleiner tip: Quartus Programmer braucht Microsoft Visual C++ 2008 SP1 Redistributable Package, das sagt er aber nicht sondern quitiert den Programmaufruf nach der Installation einfach mit "Anwendung konnte nicht richtig initialisiert werden" Danach gings bei mir. Seid 10min läuft auch der Ramtest bei meinem 2022
W2012: 30 Min. und keine Fehler. Dank an wirehead für den Tip mit dem C++. Gruss Klaus
Hi, so die Kiste ist jetzt 3h ohne Fehler gelaufen, sieht also gut aus für das Speicherinterface. Gruß
Danke an die Tester! Scheint soweit also bei allen zu laufen. Für die Testabdeckung sind meine Geräte also wohl auch schon ganz gut geeignet, mein primäres Bastelgerät scheint die ärgste Problemkiste zu sein. Schlecht für mich persönlich, aber gut für das Projekt. In der zurückliegenden Woche hatte ich dann das Gesamtsystem mit Qsys und 100 MHz zusammengebaut. Läuft nun, nach ein paar Anpassungen. Andi und Oliver habe mitgetestet, es läuft auf allen getesteten Geräten, nur meine Problemkiste will nicht recht. Selbst reduziert auf 94 MHz ist es knifflig. Das erdet mich momentan, ich hatte dieses WE keine rechte Lust, daran weiterzufrickeln. Es gibt irgendwie noch Unterschiede zwischen dem Speichertest und dem Gesamtsystem, obwohl ich die am externen Timing beteiligten Flipflops festgenagelt habe. Ich sollte mich weniger um diese Geschwindigkeitsoptimierungen kümmern... So allgemein ist das neue Timing mit Qsys aber eine tolle Sache. Vorher brauchte ich um 75 MHz zu schaffen alle erdenklichen Optimierungsschalter auf Maximum, die Kompilierzeit stieg auf etwa das Dreifache. Nun "gehen" 100 MHz ganz locker mit den Standardeinstellungen. Interessanterweise ist das zweite, quasi leere FPGA nun kritischer als das erste. Der kritische Pfad geht vom Capture-Speicher zu den Pins des Businterfaces, da kriege ich eine minimale Violation von z.B. 0,1ns. Es ist von Layout her anscheinend einfacher, vom Speicher zum internen Nios zu kommen (erstes FPGA), als zu den Pins (zweites FPGA). So long, Jörg
Jörg H. schrieb: > , die Kompilierzeit stieg auf etwa das > Dreifache. Nun "gehen" 100 MHz ganz locker mit den > Standardeinstellungen. Wie lässt sich das erkläen? Hängt das mit dem Beschreibungssystem von QSYS zusammen oder steckt da ein besserer Synthesealgo dahinter?
Ersteres, Altera hat mit Qsys eine neue Architektur für die Bus-Crossmatrix eingeführt, sie nennen es "network on chip". Orientiert sich wie der Name andeutet an Netzwerktopologie, soll insbesondere bei größeren Systemen mit vielen Busteilnehmern besser skalieren. Ich habe mir die Details noch nicht angeguckt, mit Google findet man so einige Aufsätze. Altera spricht vollmundig von doppelt so schnell, in der Realität bleiben bei uns ca. 20% Verbesserung. (Die 83 MHz schaffe ich wegen eigener Verbesserungen auch noch mit SOPC Builder.) Jörg
Ok, danke. Ich errinnere mich gerade an ein Altera Seminar wo einer der Vortragenden sehr eindringlih den enormen resourcen-Verbrauch der SOPC Systeme beleuchtet hat.
Beim Resourcenverbrauch sind mir keine nenneswerten Unterschiede aufgefallen. Unser FPGA ist etwa halb voll, vorher wie nachher. (Memory ausgenommen, davon könnten wir mehr gebrauchen.) Ich verfolge derzeit noch einen anderen Ansatz für den zwischen SRAM und FPGA-Interconnect gemeinsamen Bus. Statt die 2 verschiedenen Abtastzeitpunkte mit DDR-Inputs zu behandeln nehme ich nun die Delays der Padzellen. Das ist etwas feiner einstellbar und genauer zu kontrollieren, ich habe nun sogar mit meiner Kummerkiste eine Art Plateau von Werten, für die der Speichertest läuft, nicht nur eine einzige Einstellung. Im Gesamtsystem klappt es auf meinem besagten Problemgerät noch nicht so hundertprozentig, aber schon deutlich besser. Im Moment habe ich was präpariert und warte auf einen Absturz, aber nun rennt das Ding seit über einer Stunde unverdrossen... Davon abgesehen, andere Ideen: Ich erwäge, den Samplespeicher nicht mehr fest mit mit dem Capture-Teil zu verbinden, sondern beide über den internen Bus zu schicken. Der Anschluß dieser beiden Teilnehmer wäre mächtig breit (derzeit 256 Bit) und 125 MHz schnell. Wenn sie sich direkt unterhalten bleibt eigentlich alles beim alten, der restliche Bus ist davon unbeeindruckt, wir schaffen dann pro FPGA 2*1GSa/s weg. Man könnte aber bei langsameren Abtastraten den Capturer auch ins SRAM schreiben lassen. Die Zugriffe werden automatisch auf 8 Stück zu 32 Bit zerteilt, wir hätten deutlich mehr Samplespeicher. Dummerweise brauchen wir dann kostbare FPGA-Ramblöcke für FIFOs und so. Bei 4 Kanälen wird es ganz unangenehm, dann müßte man auch vom 2. FPGA aus als Busmaster auf das SRAM zugreifen können. Auch darüber habe ich nachgedacht, erfordert einige Koordination, u.A. weil nur FPGA1 die Adresse und Steuerleitungen anlegen kann. Da wird es mit den Signalleitungen zwischen den FPGAs verdammt knapp, von der Komplexität noch zu schweigen... So long, Jörg
Hallo Jörg! Wie ich gerade lese, bist du immer noch interessiert, die Geschwindigkeit hardwaremäßig zu optimieren. Bei deinen Überlegungen, bei "langsamen" Abtastraten direkt die Daten ins SRAM zu schreiben, möchte ich darauf hinweisen, dass man während die CaptureUnit in den Samplespeicher schreibt, dieser gelesen werden kann und sogar die Stoppadresse on the fly von der CPU Seite aus ändern kann (Roll-Mode). Solange der SRAM nicht voll ist, und die CPU oder DMA schneller die Daten auslesen können, als die CaptureUnit die Daten aufzeichnet, geht das jetzt schon. Die Daten könnten auch direkt vom 2ten FPGA per DMA vom ersten FPGA gelesen werden, wenn man die Schnittstelle zwischen den FPGAs komfortabel in den Adress-Datenbus einbindet. MFG Alexander
Hallo Alex, das ist mir bewußt, aber danke für die Erinnerung. Das 2. FPGA ist bereits "komfortabel" im Adreßraum erreichbar. Jörg
Ein Posting zum Ende des Sommerlochs, einige fragten schon: Ich bin seid ein paar Tagen aus dem Sommerurlaub zurück. Vorher ist auch nicht viel passiert. Das Welec hatte mit Instabilitäten frustriert, deren Quelle mir noch nicht klar ist. Daher ein gewisser Motivationsmangel. Und es war Sommer... Zuletzt habe ich recht erfolglos den externen Interrupt-Controller ausprobiert, Altera drängelt immer mehr den zu verwenden statt des Nios-internen. Der interne wird neuerdings gemobbt, eine nützliche Custom Instruction um die Nummer des höchsten Interrupt zu bestimmen ist entfallen. In der Tat werden Interruptroutinen mit den externen Controller deutlich schneller, statt vorher gut hundert Takte mit der Ursachenbestimmung und Registerrettung zu vebummeln wird der Code quasi direkt ausgeführt, die alternativen Registerbänke genutzt. Der Spaß kostet aber einen RAM-Block im FPGA. Bei uns sind die Interrupts derzeit weder häufig noch geschwindigkeitskritisch. Der Einbau war blöd, statt das nur zu ersetzen mußte ich das QSys-System von Grund auf neu zusammenklicken, vorher gab es obskure Fehlermeldungen, da war irgendwie der Wurm drin. "Lohn" der Mühe: die Software läuft nicht mehr, obwohl Interrupts schon kommen, das ist nicht grundsätzlich kaputtgegangen. Jetzt nach dem Urlaub bin ich erstmal ziemlich raus. Ich weiß noch nicht, wann ich damit wieder anfange. Wird weitergehen, aber derzeit prokrastiniere ich noch. Jörg
Wenn man Schrott poliert, dann sieht er zwar besser aus, bleibt aber trotzdem immer noch Schrott.
nö! Aufgewertet, würde ich sagen!
Aus Schrott kann man schöne Sachen machen... In diesem Sinne eine frohes neues Jahr Hayo
Hmm, ist das Projekt noch aktiv? Sah so vielversprechend aus. Wäre ja schade, wenn das auf Eis liegt...
Michael schrieb: > Hmm, ist das Projekt noch aktiv? > > Sah so vielversprechend aus. Wäre ja schade, wenn das auf Eis liegt... Es wird weitergehen. Ich hatte erstmal ein anderes Altprojekt in wieder in die Hand genommen, z.Zt. bastele ich etwas mit dem Raspberry Pi rum und habe es allgemein ruhiger angehen lassen. Bisher hatte das Projekt auch noch niemand vermißt... Das Welec hat mich wie gesagt mit Instabilitäten genervt. Laut Synthese alles gut, einzeln funktionierte auch alles, in Summe nicht. Das kann alles mögliche sein, vielleicht haben die FPGAs auch zuwenig Abblockkondensatoren und ich ziehe mit zuviel Gezappel die Versorgung punktuell in die Knie. Ich muß wohl etwas runterschalten, bisher habe ich mich sehr bemüht alles voll auszureizen und keine Kompromisse zu machen. Später mehr, Jörg
Jörg H. schrieb: > Bisher hatte das Projekt > auch noch niemand vermißt... > Kann ich mir kaum vorstellen. Ich halte das Projekt (wie sicherlich auch die meisten anderen) für das vielversprechenste überhaupt. Ich bin nicht sonderlich aktiv hier, aber schaue doch jeden Monat einmal rein, um zu sehen, ob es Fortschritte gibt. > Das Welec hat mich wie gesagt mit Instabilitäten genervt. Laut Synthese > alles gut, einzeln funktionierte auch alles, in Summe nicht. Das kann > alles mögliche sein, vielleicht haben die FPGAs auch zuwenig > Abblockkondensatoren und ich ziehe mit zuviel Gezappel die Versorgung > punktuell in die Knie. > Ich muß wohl etwas runterschalten, bisher habe ich mich sehr bemüht > alles voll auszureizen und keine Kompromisse zu machen. > Tja, vielleicht tatsächlich eine 80/20 Regel hier: 80% erreichen mit 20% des Aufwandes :-) Wäre auf jeden Fall immer noch absolut geil, da selbst 80% immer noch 100x besser als Originalfirmware :-D > Später mehr, > Jörg Super!
Hallo Jörg, > vielleicht haben die FPGAs auch zuwenig > Abblockkondensatoren und ich ziehe mit zuviel Gezappel die Versorgung > punktuell in die Knie. Vielleicht sollte sich Jemand mal das Datenblatt diesbezüglich vornehmen, ob genug von den Kondensatoren vorhanden sind und wo diese platziert werden sollten/müssen. Evtl. gibt es ja auch Layout Vorschriften in einer Appnote, so das die optimale Leistung erzielt werden kann, ohne das da was auf der Strecke bleibt. Gruß Michael
Ja, ich kann dem Michael nur Recht geben ... vor allem weil ich ja nun selbst auch die deutlichsten Unterschiede mit erleben dürfte (evtl. auch einen kleinen Beitrag leistete). Bitte mach weiter!!! Und das mit dem Thema Schrott sehe ich anders! Im technischen Umfeld wird schnell mit Kanonen auf Spatzen geschossen. Man(n) baut Controller ein, wo evtl. gar keine notwendig wären. ;-) Ich denke die verbauten FPGA's zeigen auch bei Deinen Test's was da so rauszuholen ist ... Grüße Andiiiy
Jörg H. schrieb: > Später mehr, > Jörg Schon ne Idee, wann Du uns was neues sagen kannst, ob und wie Du weitermachen möchtest?
Jörg H. schrieb: > Bisher hatte das Projekt > auch noch niemand vermißt... Nur weil keiner drängelt bedeutet das nicht, dass keiner wartet. Der USB-Blaster liegt bereit. Gruß Andy
Andy R. schrieb: > Nur weil keiner drängelt bedeutet das nicht, dass keiner wartet. http://www.youtube.com/watch?feature=player_detailpage&v=AL9Y_57fj4k#t=72 SCNR /Hannes
Hallo liebe Wartenden, Das Patentrezept Nummer 1 um mich wieder dranzukriegen wäre: mitmachen! Ich kann alleine keine Entwicklercommunity ersetzen. Und niemand kann sich rausreden er könne nichts beitragen, es gibt auch abseits von C und Verilog genug zu tun, nur ein paar Beispiele die mir gerade einfallen: - Ich bin zu betriebsblind um eine anfängertaugliche Anleitung zu erstellen - Die sinnvollen Modifikationen könnten im Wiki besser dargestellt werden, mit Übersichtsseite, derzeit ist viel in Forumspostings verstreut - Um die GUI könnte man sich fundiertere Gedanken machen - Unsere Zeichensätze sehen verbesserungswürdig aus - Wer sich mit "echten" Oszilloskopen auskennt könnte Anregungen geben, was wir mit den gegebene Mitteln ggf. noch umsetzen könnten - Für PC-Programmierer gäbe es auch zu tun, eine Fernsteuer- und Meßwertapplikation - Jemand der sich mit digitalen Filtern auskennt könnte die Filter von Alex optimieren Es ist ferner nicht so, das nix passiert. Hier ein paar Updates. Wegen anderer Projekte habe ich zuwenig Platz auf dem Tisch für meinen "losen" Welec-Aufbau mit der rausverlängerten Hauptplatine. Daher hatte ich das weggeräumt. Nun ist es aber im Prinzip wieder einsatzbereit. Letztes Wochenende habe ich das Welec seit Jahren erstmal wieder zusammengebaut, den JTAG durch einen Lüftungsschlitz in der Griffmulde unauffällig rausverlängert. Muß ich mal ein Foto von machen, zum Thema Mod-Doku. Ich habe auch noch mehr dran gebastelt, dazu später im Hardware-Thread. Mit Alex hatte ich Kontakt und über seine Filter gesprochen. Dazu gibt es demnächst einen Bugfix, sie konnten intern übersteuern und dann gibt es einen Wraparound-Effekt. Ich habe eine Idee für einen stufenweisen Shifter mit Saturation, um gefilterte Signale anzuheben, den Amplitudenverlust des Filters auszugleichen und mehr Auflösung zu kriegen. Alex hat die Filter seinerzeit auf Frequenzgang optimiert, daher haben wir gewisse Überschwinger. Ich finde, sie gehören für Oszilloskopanwendung stattdessen auf den Zeitbereich optimiert. Ich habe in der Zwischenzeit immer wieder nebenbei über die Architektur nachgedacht. Ich werde Osoz für die alte Hardware wohl sterben lassen, nur noch das neue FPGA supporten. Es sieht nicht so aus, als ob z.B. Hayo sich dem noch annimmt und die kleinen fehlenden Lücken bei Capture und Trigger schließt. Schade, da steckt auch viel Arbeit drin. Bisher ist die neue Hardware der alten recht ähnlich, nur viel schneller und zuende gedacht. Wenn wir ein paar alte Zöpfe abschneiden gibt es jedoch auch neue Möglichkeiten. Ein kleiner erster Schritt wäre das Page-Flipping statt Umkopieren für die Anzeige. Für die Grafik könnte ich mir allgemein noch andere Dinge vorstellen, wenn denn das RAM nicht so knapp wäre... Den Code sollte man bis auf eilige Ausnahmen grundsätzlich aus dem Flash ausführen (geht aber auch mit der alten Hardware). Allgemein zum Stand der Dinge: Viel fehlt ja eigentlich nicht für eine FPGA-Version 1.0, außer Stabilität, wenn ich recht erinnere. Der externe Trigger ist noch nicht samplegenau. Ich wollte da auch gerne eine Logicanalyzer-Funktionalität reinbauen, einen Kanal gibt der Triggereingang, 8 weitere sind am 2. FPGA bei den 4Kanälern verfügbar. Für die erste Version sollte ich mir das vielleicht noch verkneifen. Unsere Firma ist jetzt Altera-Partner. Wir haben nun Zugang zu den stets aktuellsten Tools, das Thema Nios-Lizenz sollte somit vom Tisch sein. Beruflich hatte ich auch gerade viel mit System Verilog zu tun, wenn auch nur für Verifikation. Aber Testbench und Simulieren sollte ich nun können, das habe ich beim Welec noch nicht gemacht, immer am echten FPGA probiert und gemessen. So long, Jörg
Klasse Jörg! Wenn es einen 1.0 Release gibt, helfe ich auf jeden Fall beim Wiki und beim Manual!
Ist das Projekt dann doch jetzt tot? Sauschade...
Hallo Michael, It's not dead, it just smells funny... Im Ernst, ich habe seitdem viele andere Dinge gebastelt, die (finde ich) auch sein mußten. Eine ergonomische Eieruhr mit MSP430, ein nicht so erfolgreicher DAB+ Empfänger, meine kleine RaspberryPi Soundkarte erfreut sich einer gewissen Beliebtheit, mein Wohnzimmer-DAC hat Fortschritte gemacht, im Moment rüste ich einen Oppo 103 zur digitalen AV-Vorstufe hoch, usw., falls die Schlagworte jemandem was sagen. Manchmal habe ich dabei ein "anständiges" Oszilloskop vermißt... Irgenwann geht es hoffentlich weiter, spätestens wenn wer mitmacht. Mit meinen obigen Gedanken vom 15.2. kann ich mich immer noch gut identifizieren. Grüße, Jörg
Hallo Jörg Ich kann Dich gut verstehen. Es gibt so viele spannende Projekte. Ich glaube, ich könnte Dir noch ein paar nennen :-) Trotzdem wäre es ja schaden, wenn dieses Projekt, was ja schon soooo weit gekommen ist, jetzt versandet. Ich hoffe daher, dass Du wieder den Spass und die Zeit findest, dies zumindest zu einer ersten Release-Version weiter zu entwickeln. Viele Grüsse Michael
Angehängte Dateien:
-
USB-Blaster.jpg
29 KB
Hallo Jörg und der Rest... Hier ein USB-Blaster Programmer für den Altera Chip. Der Blaster kostet beim Chinamann gerade mal 4,55€ inkl. Versand(4,72 wegen dem momentanen Wechselkurs) (Ich habe den günstigsten rausgesucht) Habe das Teil gerade geordert. http://www.ebay.de/itm/1Pcs-New-altera-Mini-USB-Blaster-Cable-For-CPLD-FPGA-Download-Line-Programmer-v-/321527128545?pt=LH_DefaultDomain_3&hash=item4adc82a1e1 Der Treiber dafür, ist hier erhältlich: www.altera.com/support/software/drivers Ich setze mal die Links plus die PDF hier rein. Gruß Michael
:
Bearbeitet durch User
Ja den habe ich auch. Hat aber 9.99€ gekostet. Ist so billig hergestellt, dass man noch das Papier über den Leuchtdioden selbst durchstechen muss, funktioniert aber mit dem Standardtreiber von Altera ganz prima. Ich hab das Ding an meinem W2014A (respektive W2024A / OPA656) fest angebaut und zwischen den Gehäusehälften rausgeführt. An der Durchführung habe ich das Flachbandkabel mit Tesa umwickelt, damit das Kabel nicht so gequetscht wird. Gruß aus Sami (Kefalonia) während meines Sundownings :-) Hayo
Nur blöd dass es keinen entgültigen Release gibt den man damit einspielen könnte. Das neue NIOS2 Design ist ja leider kurz vor der fertigstellung eingeschlafen. Die Leute mit genug Ahnung von FPGA Design haben so ein Teil eh schon und alle anderen brauchen es aus oben genanntem Grund eigentlich nicht. Zumindest nicht für das DSO. Ich selber habe auch so ein ähnliches China Teil. Es funktioniert prima. Egal ob mit den alten 5V FLEX Bausteinen, mit den MAX CPLD's oder mit den modernen Cyclons. Für den günstigen Einstieg in die FPGA-Welt auf jeden Fall empfehlenswert.
Oliver P. schrieb: > Das neue NIOS2 Design ist ja leider kurz vor der > fertigstellung eingeschlafen. Nur pausiert! Dass so ein Projekt zwischendurch mal etwas in der Intensität abnimmt, ist doch normal. Da wird es sicherlich noch wieder Neues geben.
Na ja, die Hoffnung stirbt ja bekanntlich zuletzt... :-D
Hallo, ich sollte mich wohl mal wieder melden... Hier hatte ich es bereits angekündigt, falls es jemand bemerkt hat: Beitrag "Re: Wittig(welec) DSO W20xxA Hardware (Teil 2)" Der Andi bearbeitet mich außerhalb der Öffentlichkeit, mein FPGA-Design doch mal langsamer zu drehen, damit es hoffentlich stabiler läuft und released werden kann, ist ja immer noch ein vielfaches schneller. Ich glaube aber da besteht noch ein anderes Problem, was untersucht gehört. Es passieren aber noch andere Dinge: Wenn Osoz die alte Hardware nicht unterstützt kann die neue prinzipiell anders werden. Ich habe viel über die Darstellungsmöglichkeiten nachgedacht, ob man irgendwie in Richtung DPO oder Intensity Grading kommt. Dazu hardwareunterstütztes Zeichnen. Babei gibt es mindestens 2 Engstellen: 1. Der (SRAM)Speicher ist verdammt knapp. 2. Eine Art Decay erfordert kontinuierlichen read-modify-write des gesamten Displays. Nun folgende Ideen: 1. Wenn man pro Kanal eine Byteplane in Größe von nur dem Raster (600*400) einrichtet, dann sind das 240 kBytes. Mal 4 geht gerade noch, Doppelpufferung in sichtbar/Hintergrund entfällt, komme ich noch zu. 2. Der Decay ginge über eine Art Palettenanimation, dann muß zum Abdunkeln erstmal nicht der Speicher verändert werden, nur die Interpretation wird umgewidmet. Allerdings müssen die Pixel, die jeweils ganz verdunkeln auf z.B. Wert 0 gesetzt werden, der außerhalb der Rotation steht und immer schwarz bedeutet. Sonst würden sie auf einmal ganz hell. Ein Decay-Durchgang muß also den ganzen Speicher lesen, und Fundstellen die den aktuellen Wert für minimale Helligkeit enthalten auf 0 schreiben. Das könnte der normale LCD-Scan im Nebenberuf erledigen. Der Speicher muß ja eh ca. 60 mal pro Sekunde gelesen werden. Für den Rest der GUI könnte ich mir eine vollformatig überlagerte 4-Bit Grafik vorstellen, die kostet dann nochmal 150 KiByte. Summa summarum ist dann bei einem 4-Kanäler gut die Hälfte vom RAM für das Display verbraten. Zeichnen ginge ggf. recht edel. Unser digitales Phosphorbyte könnte quasi aufgeladen werden, um einen bestimmten Wert, von einer vorbeistreichenden Interpolation der Meßwerte. So ergibt sich ein recht analoges Bild und das Intensity Grading. Das ginge sogar mit Subpixel-Genauigkeit, wenn die virtuelle Ladung anteilig der Entfernung der benachbarten Pixel aufgeteilt wird. Sowas könnte man mal simulieren, fühlt sich jemand berufen? Bleibt noch das Problem wie wir die schönen Zwischentöne mit der besch...eidenen 9-Bit Anbindung denn darstellen. Die ist ab Werk so verunglückt, das pro Farbe mit den 3 Bit nicht 8 Abstufungen möglich sind, sondern praktisch nur 5. Da erscheint unser Phosphorbyte mit 256 Abstufungen doch sehr verschwendet? Ich habe mir eine kleine Zusatzplatine ausgedacht, die den Datenbus zum LCD von 9 auf 18 Bit aufweitet, die tatsächliche Breite des LCD. Das FPGA könnte ein DDR-Signal ausgeben, Daten auf beiden Taktflanken, sowas ist Standard. Das wird dann von einem kleinen CPLD auf der Platine empfangen und auf die doppelte Leitungszahl demultiplext. So können wir das LCD in voller Farbauflösung nutzen. Es hat dann 6 Bit pro Farbe, also 64 Helligkeitsstufen. Nicht ganz ein Byte, aber immerhin dichter dran. Den Rest kann man vielleicht noch durch Dithering verbessern, je nachdem wie träge das Display ist. Das CPLD-Design steht und ist diesmal sogar simuliert, das Platinenlayout auch fertig (siehe Anhang), geht hoffentlich bald beim Platinensammlerjakob in Produktion. Das CPLD ist ein EPM3032A von Altera, kostet als Einzelstück bei Mouser gut einen Euro. Es kann mit dem ByteBlaster programmiert werden, ich habe auf der Platine wieder so eine 10-polige Stiftleiste vorgesehen. Die fertige Platine kann man dann ohne Löten zwischen Hauptplatine und Displaystecker einfügen. Ein Befestigungsloch ist noch vorgesehen, wenn's paßt wie gedacht kann man eine Schraube vom LCD zweckentfremden. Eine Besonderheit noch: Ich habe eine Erkennung und Modusumschaltung drin. Wenn die Hauptplatine eine gerade Anzahl von Pixeln pro Zeile ausgibt, dann verhält sich das CPLD zwecks Abwärtskompatiblität "neutral" und macht kein DDR-Demuxing. (Es werden lediglich die 3 Bits pro Farbe schlauer aufgeteilt, so daß sich echte 8 Abstufungen ergeben.) So lassen sich die existierenden FPGA-Designs weiter benutzen, ohne die Platine auszubauen. Wenn eine um eins verminderte, also ungerade Anzahl von Pixeln pro Zeile ankommt, dann wird die im weitergereichten Signal wieder erhöht um das ungeschehen zu machen, und der DDR-Demux ist aktiv. So kann das FPGA die Funktion der Platine ein/und ausschalten, ohne das wir eine extra Leitung dafür brauchen. Das ganze Design benötigt 31 Flipflops (=Makrozellen), 32 sind verfügbar. Ist übrigens in Verilog programmiert, auch sowas kleines kann man damit machen. Alle Pins sind belegt, das geht genau auf. Man könnte sagen das CPLD paßt perfekt. Es hat ferner 3,3V I/O- und Betriebsspannung, zufällig auch das was wir zur Verfügung haben. Zur Sicherheit gesagt: Ich mache da jetzt noch keine Sammelbestellung draus, möchte erstmal selber testen ob das auch wirklich so geht. So long, Jörg
Hallo Jörg, Sehr hübsch (auch die Abwärtskompatibilität) -wenn das läuft, nehme ich eine Platine! Viele Grüße, Egberto
Hi Jörg, erst mal danke für das Update! Schön dass das Projekt doch nicht so tot ist wie es den Anschein hatte. Das sind ja tolle Ideen die du hast, vor allem die Sache mit dem Display Extender. Was ich mich frage, könnte man diese Extender Geschichte nicht noch weiter treiben und das komplette Display RAM auf so eine externe Platine auslagern und den jetzigen Displayport als einen high Speed Datenbus zweckentfremden? So hätte man massig RAM im FPGA frei. Grüße Oliver
Hi, bin gerade aus Oslo zurück und lese beim Verlassen der Fähre diese Beiträge. Coole Sache! Ich wäre selbstredend mit mindestens zwei Platinen dabei. Und ich sach noch - hier geht es wieder weiter! Kreative Pausen gehören halt dazu. Hayo
wirklich hoch interessant! Hier wird auch kein mords Aufriss mit der "Kabelage" veranstaltet und ist ja quasi plug&play. Hayo, wie sieht's denn aus? Könntest du das vorübergehen, bzw. parallel zu Osoz, in "deine" FW einbauen? Das war mir gerade so durch den Kopf geschossen... Gruß Michael
Hatte ich auch schon drüber nachgedacht, da man dadurch die Möglichkeiten der neuen Displaysteuerung testen und auch schon praktisch nutzen könnte. Leider geht das aber nur mit entsprechenden Änderungen im FPGA. So wie Jörg das Funktionsprinzip beschrieben hat, schaltet das Modul nur dann in den erweiterten Displaymode um, wenn das FPGA die entsprechenden Signale sendet. Rein firmwareseitig kann man das nicht aktivieren. Gruß Hayo
Welecfan schrieb: > Wenn man Schrott poliert, dann sieht er zwar besser aus, bleibt aber > trotzdem immer noch Schrott. Lese ich daraus, dass Du das Oszi als Schrott bezeichnest oder die SW?
Naja, so wie die Teile vom "Werk" kommen sind sie ja auch tatsächlich Schrott. Sie haben aber genügend Potential um sie ordentlich aufzubürsten. (und das ist es ja was wir daran so lieben...) So wie die Geräte jetzt bei mir stehen kann man sie wirklich benutzen, was man vorher nicht wirklich konnte. Was im Laufe der Zeit an den Geräten verbessert wurde kann man aber schon lange nicht mehr als polieren bezeichenen. Das geht schon weit darüber hinaus. Und es ist noch nicht das Ende der Fahnenstange... Hayo
Andererseits würde ein kleiner Flameware diesem Thread gut zu Gesichte stehen. Dann schlägt endlich mal die Seitenaufteilung zu. :-))
Die Teile sind nun mal Schrott. Im Auslieferungszustand ist Schrott: -Die Firmware -Das FPGA-Design -Die Eingangsstufe Nach Jahrelanger Arbeit der Entwickler hier konnten die Probleme der Firmware und die meisten Unzulänglichkeiten der Eingangsstufe gelöst werden. Was nach wie vor Schrott ist, ist das zugunde liegende FPGA Design. Der Schrott-Faktor liegt also noch bei um die 30% ;-)
Ich würde euch das glatt unterstützen, aber habe wenig Zeit. Momentan lassen sich FPGA-Kenntnisse sehr gut wirtschaftlich vermarkten und zu Geld machen. Ich gehe auch davon aus, dass es nicht damit getan ist, euch ein paar Tipps zu geben, sondern man müsste da was komplett Neues machen, nehme ich an?
M. F. schrieb: > Ich gehe auch davon aus, dass es nicht damit getan ist, > euch ein paar Tipps zu geben, sondern man müsste da was komplett Neues > machen, nehme ich an? Naja, Jörg hat einen Neuentwurf mit enormen Verbesserungen zum Laufen gebracht. Nur mit dem Timing ist er etwas unglücklich, weil es zwar sehr gut aber nicht optimal gut geht. Da können ihm wohl nur wenige helfen, soviel Knowhow können wir nicht aufweisen. :-(
Angehängte Dateien:
-
before.jpg
190 KB -
after_unplugged.jpg
250 KB -
after_plugged.jpg
230 KB -
stack.jpg
140 KB
Die LCD-Platine ist jetzt endlich da, flugs bestückt und programmiert. Anbei ein paar Bilder, wie dieser Mod dann aussehen könnte. Sehr komfortabel ohne Löten einzubauen, man braucht das Gehäuse nur hinten aufschrauben und den Deckel etwas lupfen, Platine zwischenstecken, wieder zuschrauben. Ich bin mir noch nicht sicher, ob ich die LCD-Schraube wie hier abgebildet zur Befestigung nutze (braucht ein Distanzstück von ca. 2,7mm Höhe und eine längere Schraube), oder die Platine um den Teil hinter dem Stecker kürze und allen Halt dem Stecker überlasse. Die Stecker rasten immerhin etwas. Die 10-polige Pfostenleiste ist zum Programmieren des CPLD per Blaster, analog zum FPGA. Muß man nicht unbedingt bestücken, später reicht es vielleicht, das über Pogo-Pins einmalig zu machen. Zum Status: Ich habe mein Logikdesign noch etwas umändern müssen, die Signale sind vielleicht aufgrund von Clock-Skew zur fallenden statt steigenden Flanke stabil. Damit kriege ich nun das gewohnte Bild, der abwärtskompatible Durchreich-Modus funktioniert schon mal. Nun müßte ich einen neuen LCD-Controller für das FPGA programmieren, das ist der aufwändigere Teil... Jörg
:
Bearbeitet durch User
Das sieht ziemlich professionell aus. :-) Wenn das alles in dem Topf ist, wo es kocht, hätte ich bitte auch gern so eine Platine. Muss mir dann nur noch einer kurz den Weg weisen, wie man das Ding nach dem Löten programmiert... /Hannes
ist ja abgefahren und sieht aus, wie aus dem Laden! Und total unauffällig, als würde es zum Board gehören. Ich schließe mich Johannes an. Wo stehen denn da so die Kosten, für das Adapter-Platinchen? Gruß Michael
Michael D. schrieb: > Wo stehen denn da so die Kosten, für das Adapter-Platinchen? Das ist nicht teuer, die Materialkosten liegen unter 10€. Wer's genau wissen will, hier ein Mouser-Warenkorb für die Bauteile (Achtung Nettopreise): http://www.mouser.com/ProjectManager/ProjectDetail.aspx?AccessID=57960b7bcf Von den Platinen habe ich 2 bestellt und 6 bekommen (auch die Überproduktion gekauft), kosteten dann im Mittel 2,20€ das Stück. Jörg
Hi Jörg, dann würd ich hier auch direkt mal Interesse anmelden. (der Oliver aus dem alten Skype Chat) Grüße Oliver
Hallo Ich bin natürlich auch daran interessiert. Habe aber, wie die meisten denke ich, das Problem den CPLD zu programmieren. Man wird einen ByteBlaster kaufen/bauen müssen, Software dafür und einen PC mit LPT suchen usw. Wäre fein wenn sich jemand fände der ein Paar CPLDs gegen Entgelt kauft, programmiert und versendet. Noch besser wenn die Prints und die Stecker dabei wären. Oder steht dem Wunsch Jörgs Erweiterungen nutzen zu wollen noch mehr im Weg? Gruß, Kruno
zum Programmieren des Logik-Bausteins, reicht doch der USB-Blaster über den JTAG Header, oder liege ich da falsch? Den USB-Blaster, der ja über den Quartus-Programmer angesprochen wird, gibt es für unter 5€ hier: Beitrag "Re: made from scratch Firmware für Wittig/Welec Oszilloskop W20xxA" Sollte also kein Problem darstellen, wenn Jörg das Kompilat zur Verfügung stellt. Gruß Michael EDIT:Das "Hünerfutter" und Pinheader hat ja wohl jeder da(zumindest ich), das einzige was dann anfallen würde wären die EPM3032ATC44 und die Platinen-Stecker/Buchsen als auch die Platine.
Mit einer kurzen Doku/Anleitung sollte das eigentlich kein Problem sein. Da sehe ich ja wieder eine neue Ausgabe meiner Dokureihe auf mich zukommen...
Ihr seid ja gedanklich schon recht weit... Wie sagt man so schön: Man soll das Fell des Bären nicht verteilen, bevor er erlegt ist. Das muß erstmal ausprobiert werden ob's überhaupt geht, und auch dann ist es noch weit, bis man mit der Platine was sinnvolles anfangen kann. USB Blaster Clone kaufen ist aber immer eine gute Idee, jeder Welec-User sollte einen haben, finde ich. Jörg
Ok, dann mache ich erstmal mit anderen Dokumentationen weiter. Die Basics sind ja auch nicht unwichtig. -> Beitrag "Re: Wittig(welec) DSO W20xxA Einsteiger"
Jörg H. schrieb: > USB Blaster Clone kaufen ist aber immer eine gute Idee, jeder Welec-User > sollte einen haben, finde ich. Wenn du das sagst, mache ich das doch glatt. Ich hab zwar noch keine Ahnung, was ich damit anstellen kann, aber ich hab erstmal draufgeklickt. Wenn das Ding dann irgendwann da ist, melde ich mich wieder. :-D /Hannes
> ...muß erstmal ausprobiert werden... Na dann währ's doch gar nicht so schlecht wenn's noch ein paar andere Leute eingebaut hätten. Andere Frage, gibt es eigentlich ein aktuelles Repository von der Nios2 Geschichte? Ich kenne nur das bei SVN aber da gab es, im Nios2 Zweig, seit über einem Jahr keine Veränderung mehr. Grüße Oliver
Oliver P. schrieb: >> ...muß erstmal ausprobiert werden... > Na dann währ's doch gar nicht so schlecht wenn's noch ein paar andere > Leute eingebaut hätten. Ausprobieren meinte ich nicht im Sinne von Feldtest, sondern ob das überhaupt geht und sinnvoll ist. Die Platine ist nur die Spitze des Eisbergs, da gehört noch die Implementation eines entsprechenden LCD-Controllers im FPGA dazu. Die gibt es noch nicht. > Andere Frage, gibt es eigentlich ein aktuelles Repository von der Nios2 > Geschichte? Ich kenne nur das bei SVN aber da gab es, im Nios2 Zweig, > seit über einem Jahr keine Veränderung mehr. Doch, das ist der aktuelle Stand, seitdem ist fast nichts passiert. Ich könnte allenfalls noch einen kleinen Bugfix und die Platine einchecken. Jörg
Angehängte Dateien:
-
original.jpg
200 KB -
hicolor.jpg
200 KB -
beide.jpg
450 KB
Ich habe für das FPGA im Welec ein Test-Design gemacht. Es enthält nichts außer einem rudimentären neuen LCD-Controller, der ein hart codiertes Testbild generiert. Sowas ist in 15 Sekunden synthetisiert, viel schnellere Ausprobier-Zyklen als mit Nios, Software, usw. Ergebnis: Meine Platine funktioniert im Prinzip, aber die Datenübernahme ist super-kritisch. (Ein Deja-Vu zum SRAM-Controller...) Ich habe da ziemlich viel rumprobiert, und die Dinge verhalten sich merkwürdig. Ich hoffe das kriege ich noch entschärft. Mir fehlt ein ordentliches Oszi, um da mal zu messen was Phase ist. An dem CPLD kann man leider kaum was einstellen, es hat keine programmierbaren Delays. Bei der nächsten Platinenversion würde ich ein RC-Glied am Takteingang vorsehen, dann kann man da noch was schieben. Zur Erbauung aber mal ein paar Bilder, wie's aussieht wenn's mal funktioniert. Ist gar nicht so einfach zu fotografieren, in Natura sieht's viel besser aus. Der Generator erzeugt Farbverläufe von dunkel nach hell, in den 8 RGB-Kombinationen (na gut, 7, ohne schwarz): blau, grün, cyan, rot, magenta, gelb, weiß. Mit dem normalen LCD-Anschluß werden da 8 Stufen draus, wegen unglücklichem Anschluß der unteren Bits fallen je 2 benachbarte fast gleich aus und es sind praktisch nur noch 5 Stufen. Mit meiner Platine werden es 64 Stufen. Teils kann man die auch noch sehen, besonders im dunkleren Bereich. Die Helligkeit steigt recht steil an, man könnte sagen das Display hat falsches Gamma. Da kann ich aber nichts dran machen. Jörg
Super Jörg! Danke für die Einblicke. Wieder ein Beispiel was Wittig an Potential verschenkt hat. Hoffentlich gibt's irgendwann mal wieder was zum selber spielen.
Sehr cool! Mit der Technik könnte man nette Sachen für unser Oszi programmieren... Gruß aus den Dolomiten Hayo
Johannes S. schrieb: > draufgeklickt. Wenn das Ding dann irgendwann da ist, melde ich mich > wieder. :-D Gestern hat die Post das Briefchen aus China in den Kasten gestopft. Ich hab jetzt also auch ein Gerät da liegen, welches sich am Rechner als Altera USB-Blaster mit Seriennummer 00000000 meldet. :) Jetzt muss ich nur noch das Flachbandkabel ins Gerät fummeln und dann kann's losgehen (was auch immer) :-D /Hannes
Jörg H. schrieb: > Ergebnis: Meine Platine funktioniert im Prinzip, aber die Datenübernahme > ist super-kritisch. (Ein Deja-Vu zum SRAM-Controller...) Ich habe da > ziemlich viel rumprobiert, und die Dinge verhalten sich merkwürdig. > > Ich hoffe das kriege ich noch entschärft. Mir fehlt ein ordentliches > Oszi, um da mal zu messen was Phase ist. An dem CPLD kann man leider > kaum was einstellen, es hat keine programmierbaren Delays. Bei der > nächsten Platinenversion würde ich ein RC-Glied am Takteingang vorsehen, > dann kann man da noch was schieben. Ich habe mir jetzt ein "ordentliches Oszi" gekauft (Tektronix 2467B, soll das beste Analog-Oszi sein wo gibt) und es erfolgreich zum Einsatz gebracht. Gegenüber meinem Hameg 604 war das wie Brille aufsetzen, hurra, ich kann sehen! Es gab verschiedene Probleme, die ich nun lösen konnte. Das Original-FPGA wechselt die LCD-Signale zur fallenden Flanke, genau genommen etwa 2 ns dahinter. So soll es laut Datenblatt LCD nicht sein, das möchte alles zur fallenden Flanke stabil haben, mit 5 ns Setup- und Hold-Zeit drumrum. Welec begeht da also eine hold time violation. Die originale LCD-Ausgabe funktioniert wohl eher mit Glück. (Es ist aber auch gar nichts richtig an diesem Design!) Meine Platine ist also gut beraten, die Signale zur steigenden Flanke abzutasten und die neu erzeugten auch wieder so auszugeben. Dann ist die Übername vom FPGA sicher und die Signale zum LCD sozusagen repariert. So mache ich das also nun, vorher hatte ich zur fallenden Flanke übernommen. Aktuell habe ich eine Platine mit einem schnelleren Speed Grade des CPLD aufgebaut, um da mehr Luft zu haben. Ist aber wohl doch nicht so dringend nötig, stellt sich raus. Dann waren da noch ein paar Bugs in meinem Test-LCD-Controller, die mich daran hinderten dort das Timing durchzukurbeln. Nun habe ich Einstellungen, mit denen die Datenübername stabil und unkritisch klappt. Kurzum, die Erweiterung funktioniert nun ordentlich. Mal sehen wie es damit weitergeht, ich habe im Moment nur leider wenig Zeit dafür. Jörg
:
Bearbeitet durch User
Glückwunsch zum Tek! Ist ja irgendwie der große Bruder von meinem 2465A.
Obwohl technisch eigentlich nicht mehr ganz aktuell können die Dinger
doch schon Einiges was die Neuen nicht können. Haben früher immerhin
lockere 20 Kilo DM gekostet. Das konnten sich nur Profis leisten.... und
jetzt haben wir sie zu Hause stehen :-)
Etliche Funktionen der DSOs haben sie zwar nicht, aber wenn es hart auf
hart kommt zeigen sie einem mehr als die neuen Dinger.
> (Es ist aber auch gar nichts richtig an diesem Design!)
Da wäre ja auch ein Ruf zu verlieren ;-) Anders hat es wohl auch keiner
erwartet...
Wenn ich das richtig verstanden habe ist Dein Display-Converter ja kurz
vor der "Serienreife".
Wie gesagt, ich wäre dabei.
Gruß Hayo
Hi, ich überlege ein Wittig DSO zu Kaufen, die frage ist: Lohnt das noch und leben die Open Source Projekte noch? Das Sourceforge-Wiki scheint es nicht mehr zu geben? Gruß, Marc
Hi, wenn Du es günstig kriegst und wenn Du Lust hast auch selber Hand anzulegen ist es immer noch eine ergiebige Plattform zum Lernen und Basteln die über umfangreiche Funktionen verfügt. Wenn Du nur hin und wieder was messen willst und keine Lust hast Dich näher mit dem Ding zu beschäftigen - nimm was aus China. Die Projekte sind momentan alle nicht mehr aktiv, aber ich supporte immer noch die BF-Firmware und alle meine Hardware-Mods. Wenn Du da was machen möchtest und Fragen hast oder Fehler entdeckst stehe ich jederzeit zur Verfügung. Das sehr vielversprechende FPGA-Projekt pausiert seit einiger Zeit. Ob sich da evtl. wieder was tut kann ich nicht sagen. Gruß Hayo
Danke für die schnelle Antwort! Also grundsätzlich hab ich ein Rigol DS1104z, das Wittig fände ich hauptsächlich spannend aufgrund von 4 Dingen: - 1GS/s pro Kanal, beim rigol sinkt die samplingrate mit jedem zusätzlichen Kanal - 200MHz analog Bandbreite - viel Bastel Spaß, insbesondere Akku Mod finde ich sehr praktisch! - Open Source finde ich gut ;) Was würdest du denn als günstig ansehen? Gruß, Marc
Hi Marc, wenn Du so ein Teil zwischen 100,- und 200,- schießen kannst liegt das im grünen Bereich. Da gab es schon etliche Schnäppchen in der Bucht. Auf die Bandbreite brauchst Du nicht zu achten, das kann man mit einer Modifikation auf den richtigen Weg bringen. Du solltest nur wissen ob Du ein 2-Kanal oder ein 4-Kanal Gerät haben möchtest Das schöne daran ist, dass man zum Einen lernen kann SMD zu löten, Einiges zum Thema Messtechnik und Oszis im Speziellen und irgendwie baut man im Laufe der Zeit mit jeder Modifikation eine Art persönlicher Beziehung zu diesem eigentlich im Urzustand ziemlich unperfekten Gerät auf. Ich kann mir eigentlich keinen effizienteren Weg vorstellen um sich mit dem Thema Messtechnik und seinen Tücken vertraut zu machen. Wie mein Prof immer zu sagen pflegte: Wer misst, misst Mist! Sehr wahr! Also wenn Du da gerne basteln möchtest und Tips und Hilfe brauchst bin ich jederzeit über eines der Foren erreichbar. Ich denke etliche der alten Hasen sind ebenfalls noch über Email-Benachrichtigung im Forum verlinkt. Gruß Hayo
Hallo, wie von Hayo vermutet lese ich noch mit, die Email-Benachrichtigung ist noch aktiv. Aktiver als ich... Zu den Fragen: - Das Wiki gibt es noch, aber read-only. Als Sourceforge (mal wieder) sein System erneuerte drohte alles im digitalen Orkus zu verschwinden. Man konnte immerhin ein Backup ziehen, eine neue Datenbank aufsetzen und das wieder lesbar kriegen, aber das neue System ist inkompatibel. Hier der Link: http://welecw2000a.sourceforge.net/cgi-bin/trac.cgi - Ob so ein Gerät zu empfehlen ist: Allgemein würde ich das ehrlich gesagt nicht mit gutem Gewissen tun, es sei denn es geht um spezielle Dinge. Das Design ist mittlerweile 10 Jahre alt, das ist im schnellebigen Markt der Digitaloszilloskope eine lange Zeit. Mittlerweile ist der Speicher arg klein, sowohl für Meßwerte wie Programm, die VGA-Grafik recht grob, und es fehlt eine schnelle Schnittstelle. Und mal allgemein, wo ich gerade dabei bin: Nach wie vor habe ich einige Ideen, was man aus der Kiste noch rauskitzeln könnte, mit dem neuen FPGA-Design. Ich habe viel nachgedacht, ob was in Richtung DPO oder wenigstens Intensity Grading zu schaffen ist, aber es scheitert immer wieder am Speicher (im FPGA und das SRAM), aber auch an den FPGA-Resourcen wenn man in Richtung hardwareunterstützte Darstellung denkt. Ein Display mit vielen Schattierungen, wie es meine Hardware-Erweiterung prinzipiell bietet, braucht auch viel Bildspeicher. Damit wäre schon ein großer Teil des SRAM belegt, wie auch viel Bandbreite um das 60 mal in der Sekunde zu lesen. Dann muß es auch beschrieben werden. Ungünstigerweise liest das LCD von oben nach unten, wärend man das Signal von links nach rechts schreiben wird. Das verhindert leider eine elegante und effiziente Architektur des Bildspeichers. Das hängt also zu hoch, Schritt zurück. Eine andere interessante Sache ist, MSO-Funktionalität mit unter zu bringen. Das 4Kanal-Gerät hat intern 8 Leitungen frei. Die sind auf einem Stiftleisten-Footprint zugänglich. Wir hätten gerade noch genug Luft, die mit aufzuzeichnen. Debugging im 2. FPGA ist aber eine Strafe, sprich unmöglich, weil es keinen JTAG-Anschluß hat. Das 2Kanal-Gerät könnte immerhin den Triggereingang mit aufzeichnen, gibt also einen Digitalkanal, damit kann man das "üben". Ich würde heutzutage den Capture-Speicher anders aufbauen: unabhängig von der Capture-Unit, stattdessen als normalen Teilnehmer an einem (breiten) Avalon-Bus. Damit die Capture-Unit schreiben kann braucht sie dann einen DMA. Hat den Vorteil, das bei langsamem Capture auch das SRAM als Ziel genommen werden kann, mit größerer Speichertiefe. Haarig wird es dann beim 4-Kanäler. Über die eigentlich zu wenigen Handschake-Leitungen müßte das zweite FPGA auch Busmaster sein können. Das wird eng, geht nur wenn man die Waitstate-Leitung wegläßt und irgendwie durch die Programmierung sicherstellt, nix zu überfahren. Momentan ist die Filter-Mimik aus Alex' Diplomarbeit eingebaut. Das braucht viel Resourcen, ob es in sich lohnt ist die Frage. Ich würde zugunsten von einer feature-reicheren Triggerung weitgehend darauf verzichten. Cool wäre sowas wie segmented memory, kommt aus den Zeiten von wenig Speicher. Protokollanalyse in Hardware ist auch ein Thema. Mir fehlt im Moment die Zeit, das weiter zu voerfolgen. In den nächsten Monaten wird das auch nicht besser. Zuletzt hatte ich mich noch in eine Ecke festdesignt. Irgendwas ist instabil, die Software rennt in eine Exception, keine Ahnung warum. Man müßte schrittweise alles wieder ausbauen. So long Jörg
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.