www.mikrocontroller.net

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


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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...
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

Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Guido (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Roberto (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gefällt mir :-)
l.G. Roberto

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: branadic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael H. (stronzo83)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Sigi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Krunoslav O. (kruno3)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Kruno (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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ß

Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
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/brows...

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

Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Meister Eder (edson)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: branadic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/brows...

Intessierend sind die Zeilen 263 - 268.

branadic

Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: alex008 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
OK, ist behoben, sorry.
Änderungen im Makefile und im Script.

Jörg

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Bjoern (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Bjoern (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bin gerade (noch mal) dabei den CDK aus den Quellen neu zu kompilieren. 
Soll ich es Dir dann mal zusammenpacken?

Bjoern

Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/...
(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

Autor: Björn F. (modes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/...

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

Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg H. schrieb:

> Edit: hab's gerade gefunden, bei Sourceforge unter Files, Development:
> 
http://sourceforge.net/projects/welecw2000a/files/...

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

Autor: Björn F. (modes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok es lebt wieder! Werd jetzt noch mal cygwin testen...

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Björn F. (modes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Björn F. (modes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Björn F. (modes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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....

Björn

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?)
diff -qrb nios-gnupro-src-3.1/src/ nios-gnupro-src-3.2/src/ | grep ".c differ"
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

Autor: Guido (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg H. schrieb:
> (Björn, wie hast du denn vermutlich
> automatisiert die line ends korrigiert?)

Naja, vermutlich einfach mit "fromdos".

Gruß, Guido

Autor: Björn F. (modes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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

Autor: Thomas O. (kosmos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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#...

> 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

Autor: Thomas O. (kosmos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: alex008 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hab's gerade gesehen (das Busy-Signal ist offenbar verdrahtet), als ich 
selber meine Optimierungen einchecken wollte...

Nun merge ich erstmal...

Jörg

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sector Erase braucht jetzt nur noch die halbe Zeit!

-> nicht vergessen FlashInit() in die main mit einzubauen!

Hayo

Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schade :-(

sah irgendwie geschmeidig aus. Aber wenn das Auslesen eines beliebigen 
Bytes reicht und zuverlässiger ist, dann nehmen wir das lieber.

Gruß Hayo

Autor: alex008 (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Guido (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hmmh,

liegt ev. das Übersprechproblem garnicht an Kurts Platine sondern
am Welec? Dass es mit LA nicht auftritt macht mich stutzig.

Autor: Thomas O. (kosmos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
vielleicht Reflektionen die mit der geringen Last des LA schon 
verhindert werden, ist es mit einer längeren Leitung besser oder eher 
schlechter?

Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Johannes S. (johannes_s94)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)...

Autor: Jürgen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Beitrag #2528169 wurde vom Autor gelöscht.
Autor: Daniel R. (daniel-r)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Johannes S. (johannes_s94)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Johannes S. (johannes_s94)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Johannes S. (johannes_s94)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jörg H. (idc-dragon)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Johannes S. (johannes_s94)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Johannes S. (johannes_s94)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Johannes S. (johannes_s94)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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)?

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg H. (idc-dragon)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Johannes S. (johannes_s94)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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? ;-)

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Johannes S. (johannes_s94)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Björn F. (modes)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Johannes S. (johannes_s94)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Christian M. (monty2011)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Monty, du bist hier etwas OT, in jenem Thread besser aufgehoben:
Beitrag "Wittig(welec) DSO W20xxA Hardware"

Grüße
Jörg

Autor: Christian M. (monty2011)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für die Info Jörg, ich stelle meine Anfrage in den richtigen 
Thread.

Gruß Monty

Autor: Jörg H. (idc-dragon)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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:
nios-elf-objcopy -O binary obj/TomCat.out tomcat.bin
Dann braucht man das Oberhumer-Tool "uclpack", Aufruf mit ein paar 
undokumentierten Optionen:
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

Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Thomas O. (kosmos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frames/min ist aber eine ungewöhnliche Einheit.

Assembler = 16,15 fps
C         = 17,65 fps
C(invert.)= 19,25 fps

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich messe in fpm, hatte aber keine Lust zum Umrechnen.

Hayo

Autor: Hayo W. (blueflash)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: branadic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Björn F. (modes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Eventuell kannst Du damit ja etwas anfangen, falls Du das nicht schon 
selbst gefunden hast.

Gruß Björn

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael D. (mike0815)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
immer dasselbe mit dir... :-)))

Autor: Jörg H. (idc-dragon)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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/u...
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Guido (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hayo W. schrieb:
> ' not found!at_ram.ucl

Fehlt da im Skript ein TomC?

Grüße, Guido

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
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

Autor: Johannes S. (johannes_s94)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Random ... (thorstendb)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schade ... schau gerad auf ebay, aber es gibt keines dieser Geräte mehr 
zu kaufen? Wollt mir eins als Spielzeug zum Basteln zulegen :-)

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Weitersuchen,

habe gerade neulich zwei für einen Kumpel günstig geschossen. Die 
tauchen immer mal wieder in der Bucht auf.

Hayo

Autor: Michael W. (slackman)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael W. (slackman)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg H. (idc-dragon)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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/brows...

Weil das komplett neuer Code ist könnte Hayo mal ausprobieren, ob er 
damit immer noch sein Problem hat.

Grüße
Jörg

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Jörg,

habe den Ramloader ausprobiert - mehr dazu im Firmware Thread.


Hayo

Autor: Guido (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rainer H. (rha)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg H. (idc-dragon)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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/brows...

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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rainer H. (rha)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Guido (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tja Hayo, so kommt man schließlich auf die Idee den Compiler
lieber selbst zu schreiben (das muss doch besser gehen?).;-)

Grüße, Guido

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rainer H. (rha)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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äß:
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/brows...
http://sourceforge.net/apps/trac/welecw2000a/brows...
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

Autor: Guido (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
// bugfix for heap manager, _sbrk() expects this to be a variable and point to heap
extern uint32_t* _nasys_uninitialized_storage_end;
_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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Guido (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg H. (idc-dragon)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Guido C. (guidoanalog)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)

Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg H. (idc-dragon)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Guido (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Guido C. (guidoanalog)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Guido C. (guidoanalog)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Robert S. (razer) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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-Reu...

Autor: Guido C. (guidoanalog)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg H. (idc-dragon)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Sebastian S. (sebastian_s47)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rainer H. (rha)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rainer H. (rha)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Johannes S. (johannes_s94)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Johannes S. (johannes_s94)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Guido (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Auweiah Jörg,

weck doch keine schlafenden Hunde. Jetzt kommen bestimmt die
Bussniffer wieder und wollen Protokollanalysen für Alles. ;-)

Grüße, Guido

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
// jump to the ROM monitor program, for bootstrapping
void PlatformMonitor(void)
{
    uint32_t startaddress = na_boot_ROM_base + 0x4A; // magic: behind the button / flash signature test
    // note: stack and CWP may not be optimal, missing the init
    void (*fnBoot)(void) = (void*)(startaddress/2); // half because of Nios-style jump, 16 bit instructions
  
    fnBoot(); // call the bootloader
    // we won't return from here
}

Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg H. (idc-dragon)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Thomas O. (kosmos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jörg H. (idc-dragon)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Dirk B. (garag)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael H. (stronzo83)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Alex (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 !

Autor: Ein Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: f00bar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: egberto (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: egberto (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!!

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ingo M. (ingom)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg H. (idc-dragon)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Sebastian S. (sebastian_s47)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg H. (idc-dragon)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ulrich B. (ulrich_b18)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: branadic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Sebastian S. (sebastian_s47)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Jörg,
habe die aktuelle Version nochmal getestet. Das Problem bleibt leider 
wie oben beschrieben.

Gruß
Sebastian

Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael D. (mike0815)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael D. (mike0815)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg H. (idc-dragon)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hayo W. (blueflash)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg H. (idc-dragon)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael D. (mike0815)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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

Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"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

Autor: egberto (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Lukas K. (carrotindustries)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Warum das Rad neu erfinden und nicht einfach libpng oder {g,b,x}zip 
nehmen?

Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Sigi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Sigi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>..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

Autor: Jürgen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Sigi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg H. (idc-dragon)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael D. (mike0815)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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...