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

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

Nun mal zur Zukunft, was ich als nächstes mache, was noch fehlt, worüber
ich noch nachdenke, wo ich Hilfe gebrauchen kann.

SPI:
Wenn die Timer "etabliert" sind werde ich die Schieberegisterketten in
Betrieb nehmen, mit denen die Augänge realisiert sind. An solchen hängen
die LEDs der Frontplatine, sowie im wesentlichen die Steuerung der
Eingangsstufen (alt wie neu).

UART:
Die seriellen Schnittstellen kriegen noch "ordentliche" Treiber, mit
Übertragung per Interrupt. Nur wenn der Sendebuffer voll ist muß eine
Schreibfunktion blockieren, ansonsten passiert das im Hintergrund.
Empfangen wird auch in einen Puffer, das erste eintreffende Zeichen wird
per Message an die Hauptschleife gemeldet. (Nicht jedes, das erzeugt zu
viele Messages, das Hauptprogramm kann dann ja den Puffer leeren).
Wenn alle Interruptroutinen im System so schlank wie möglich sind, nur
die Hardwarewerte o.ä. abholen, eine Message schicken und den Rest dem
Hauptprogramm überlassen kriegen wir hoffentlich eine schnelle
Übertragung per USB hin.

Kanaleinstellung:
Setzt auf SPI auf, ist dann nicht mehr schwierig.

Flash:
Wir brauchen passende Routinen, um einen bestimmten Bereich des Flash
selbst verwalten zu können, für persistente Einstellungen und
Abspeichern von Messungen. Sollte sich abgucken lassen. Wenn später mal
das Programm selbst im Flash läuft muß diese Routine im RAM landen,
sowie auch alle Interruptroutinen, damit derweil keine anderen Zugriffe
stattfinden.

Capturing + Trigger:
Die beiden Arbeitspakete werden vermutlich schwieriger. Bisher weiß ich
noch fast gar nichts darüber. Eine gute Gelegenheit, sich Spikeproblemen
und anderen Phänomänen anzunehmen.

Dann wären wir in der unteren Schicht aber auch schon durch, oder habe
ich was vergessen?

Von der Architektur her bin ich noch nicht sicher, ob wir darüber dann
eine Abstraktionsschicht brauchen, um Unterschiede der Designs vor der
Applikation zu verbergen. Wenn z.B. dem Leon kein in einzelnen Bitplanes
organisierter Bildspeicher beizubringen ist, dann funktioniert das
Zeichnen fundamental anders, es sind mehr
Lösch-/Neuzeichne-/Kopieraktionen und der Speicher dafür nötig. In
zukünftig anderen Oszilloskopen wird man wohl auch eher einen "normalen"
Bildspeicher vorfinden als eine solch speziell optimierte Konstuktion.
Allerdings dürften solche Geräte dann auch die nötigen Resourcen haben,
sprich mehr und schnelleren Speicher.

Auch eine wie ich finde reizvolle Idee: Man könnte ein PC-Programm
schreiben, was diese untere Schicht simuliert. Dann kann man die
Applikation auch komfortabel auf dem PC entwickeln, sie dort
laufenlassen und debuggen. Ist jemand fit mit Qt, SDL oder sonstig
geeignetem und mag etwas programmieren, was einen Screen in VGA-Größe
umrahmt von den Bedienelementen zeigt, per Mausrad die Drehregler und
per Klick die Knöpfe bedienbar?

Eine weitere nötige Entscheidung: Ich überlege, ob wir die libc
überhaupt verwenden sollten. Sie ist nicht gerade klein, und wir
brauchen kaum Funktionen daraus. Sowas wie die Stringfunktionen,
memset(), memcpy() ist im benötigten Umfang auch leicht selbst zu
programmieren/kopieren. Bleibt noch printf(), sprintf() als recht teure
Funktion, hauptsächlich wegen des Formatparsings und Fließkomma. Auch da
kommt man mit einzeln angestückelten Ausgaben eigener Funktionen zum
Ziel.

Zuletzt die eigentliche Arbeit: die Applikation, neu geschrieben oder
mit Versatzstücken der alten Software.

Ich bin nicht der Experte, wie man effizient Benutzeroberflächen auf
kleinen Mikrocontrollern programmiert. UI Widgets und so. Da oben
sollten andere ran.
Das Menüsystem in (Spaghetti)Code ausformulieren ist sicher keine gute
Idee. Selbst die jetzige Software verwendet Tabellen (sehen allerdings
derzeit ungeschickt aus), sowas kann ich mir gut vorstellen, vielleicht
noch mit Funktionspointern für Handler drinnen.

So, mehr fällt mir nicht ein, nun warte ich darauf daß die richtigen
Leute diesen Thread entdecken und sich einbringen.

Jörg

Ok schon entdeckt :-)

Du kommst ja super schnell voran - Respekt!

Ich habe gerade erst nach dem Update auf Suse 12.1 mein System wieder
zum Laufen gekriegt. Diese blöden Schnickschnackfunktionen von KDE4.x
bringen bei mir alles durcheinander.


Zu den Timern, diese werden derzeit so genutzt:

Timer1 -> wird für den Combi-Trigger von Stefan als Timeout Counter
benutzt
Timer2 -> wird für den USTB Mode genutzt und steuert die Intervalllänge
          zwischen zwei Abtastwerten.
Timer3 -> wird für alle anderen zeitgesteuerten Ereignisse genutzt
(Popup-
          Anzeigedauer etc.)

Das mit der Multiplikation hört sich vielversprechend an und könnte für
die Mathematischen Funktionen extrem nützlich sein. Ebenso für das
Quickmeasurement.

Ein Debugger wäre natürlich das Non plus Ultra! Das hab ich die ganze
Zeit vermisst.

Das printf() ist übrigens eine abgespeckte Version ohne Floating Point
Unterstützung. Diese habe ich mittels kleiner Zusatzfunktion
implementiert.

Ein gutes Konzept für die neue Menüfunktion kann ich momentan leider
auch noch nicht anbieten. Da werden wir wohl etwas Rechercheaufwand
reinstecken müssen. Ich denke je mehr Zeit wir am Anfang in vernünftige
Konzepte investieren, desto schneller werden wir später Resultate
erzielen.

Gruß Hayo

Wie sind denn die Echtzeitanforderungen an die Timer? Ich vermute mal
bei 2 sehr straff, bei 1 weniger und bei 3 am allerwenigsten?

Timer sind immer ein knappes Gut, finde ich. Die Altera-Timer sind sehr
simpel, lassen sich eigentlich nur für je einen Zweck verwenden. (Bin
ich nicht gewohnt, im Atmel AVR kann man mit Capture, 2-3 mal Compare,
Overflow pro Timer gut mehrere Dinge abfrühstücken.)

Ich habe das in der Vergangenheit i.d.R. so gemacht, das ich die
schnellen Dinge direkt den passenden Timerresourcen zugewiesen habe (der
Timer gehört denen dann praktisch), aber alles was langsam läuft (so im
Millisekundenbereich) und kein präzises Timing braucht über einen
zentralen Heartbeat-Interrupt abwickle. Dort werden die zur Laufzeit
beantragten Timer runtergezählt und bei Ablauf Messages verschickt.
Für welche Timer würde sich so ein Verfahren noch eignen?

Die Reaktionszeit auf eine Message wird von der längsten Aktion der UI
bestimmt, was die halt so worst-case mäßig als Reaktion auf irgendwas
tut. Im Extremfall also z.B. den ganzen Bildschirm neu zeichnen, eine
FFT rechnen, einen Screenshot übertragen. Währenddessen wird auf nichts
anderes reagiert, muß ja vielleicht auch nicht, es staut sich aber alles
auf.

Jörg

Jörg H. schrieb:
> Wie sind denn die Echtzeitanforderungen an die Timer? Ich vermute mal
> bei 2 sehr straff, bei 1 weniger und bei 3 am allerwenigsten?

Ja korrekt.

> Timer sind immer ein knappes Gut, finde ich. Die Altera-Timer sind sehr
> simpel, lassen sich eigentlich nur für je einen Zweck verwenden.

Leider auch korrekt.

> Ich habe das in der Vergangenheit i.d.R. so gemacht, das ich die
> schnellen Dinge direkt den passenden Timerresourcen zugewiesen habe (der
> Timer gehört denen dann praktisch),
Ja so ist es bei Timer 1 und 2.

> aber alles was langsam läuft (so im
> Millisekundenbereich) und kein präzises Timing braucht über einen
> zentralen Heartbeat-Interrupt abwickle.
Da muß ich passen, dieser Begriff sagt mir nix.

> Dort werden die zur Laufzeit
> beantragten Timer runtergezählt und bei Ablauf Messages verschickt.
> Für welche Timer würde sich so ein Verfahren noch eignen?
Timer drei wird halt für alle Ereignisse im GUI-Bereich verwendet. Diese
operieren alle mit Intervallen von 1 - 3 Sekunden.

> Die Reaktionszeit auf eine Message wird von der längsten Aktion der UI
> bestimmt, was die halt so worst-case mäßig als Reaktion auf irgendwas
> tut. Im Extremfall also z.B. den ganzen Bildschirm neu zeichnen, eine
> FFT rechnen, einen Screenshot übertragen. Währenddessen wird auf nichts
> anderes reagiert, muß ja vielleicht auch nicht, es staut sich aber alles
> auf.
Momentan habe ich dieses Problem durch ein globales Flag (UI_request)
gelöst welches in der ISR gesetzt wird und dann den aktuellen
Ausgabevorgang oder Berechnung an definierten Stellen abbricht. Das
Ganze wäre aber mit einer Message-Queue sicherlich eleganter.

Gruß Hayo

p.s. bin heute in der Firma und daher nur über Forum zu erreichen.

Den Code lese ich so, das Timer 1 fest alle Millisekunde kommt, egal ob
da was aktiv ist oder nicht. Timer 2 für USTM je nach Zeitbasis alle 20
ms bis 20 s. Timer 3 löscht Popups nach 2 s.

Der Kombitrigger sieht so nach Workaround aus, das stelle ich gedanklich
erst mal zurück, bis ich ihn verstanden habe und nach Untersuchung von
Trigger/Capture einsehe das wir sowas tatsächlich brauchen. ;-)
Kann er mit USTB zusammenfallen?

Einen Timer sollten wir nach Möglichkeit frei laufenlassen, als
hochauflösende Systemzeit. Der kann dann keine programmierbaren
Interrupts generieren.

Ferner haben wir noch den VSync-Interrupt. Den habe ich noch nicht
getestet. Wenn er das tut was der Name sagt, dann eignet der sich wohl
als Heartbeat-Interrupt. Damit ist ein recht gemütlicher regelmäßiger
Interrupt gemeint (Größenordnung 100 Hz), für allgemeine Systemaufgaben
wie z.B. UI-Timer. Die haben dann als Auflösung die Anzahl dieser Ticks.

Gestern habe ich noch (erfolglos) mit den User-Instructions des Nios
experimentiert. Die waren wohl für die Mathematikfunktion gedacht, haben
es aber nicht in das ausgelieferte FPGA geschafft?

Jörg

Motivation kann auch nie schaden!

In der gestrigen Spätschicht habe ich den Heartbeat-Timer gebaut. Der
VSync-Interrupt kommt tatsächlich (auch wenn der DMA für das Display
noch gar nicht aktiviert wurde), mit knapp 60Hz, das wird dann also die
Zeitauflösung für den Applikationsteil. Die Applikation kann einen
"Rückruf" nach Zeitablauf beantragen, oder einen solchen laufenden
abbrechen, z.B. als Timeout verwenden.

Timer 3 ist meine freilaufende Systemzeit (für busy-wait und so), die
anderen beiden Timer sind noch frei, z.B. für Capturing und
Trigger-Workarounds.

Ferner habe ich einen kleinen SPI-Treiber geschrieben. Der benutzt das
busy-wait um abzuwarten, daß das FPGA die Daten rausgeschoben hat. Nun
freue ich mich über zeitgesteuert blinkende LEDs als Anwendung davon.
Drüberliegend kann man also die "echte" LED-Ansteuerung realisieren und
die Kanaleinstellungen der Eingangsstufe(n). Es geht voran in Richtung
Capturing...

Jörg

Jörg H. schrieb:

> Der Kombitrigger sieht so nach Workaround aus,
Genau das ist er...

> das stelle ich gedanklich
> erst mal zurück, bis ich ihn verstanden habe und nach Untersuchung von
> Trigger/Capture einsehe das wir sowas tatsächlich brauchen. ;-)
Da der hardwaremäßig implementierte Autotrigger bei niedrigeren
Zeitbasen (<500ns) nicht sonderlich gut triggert, da dann der Timeout zu
kurz ist, hat Stefan den Combitrigger implementiert. Dieser funktioniert
ganz einfach so, dass der Normaltrigger aktiv ist und wenn innerhalb des
Timerintervalls kein Ereignis auftritt dann auf den Autotrigger
umgeschaltet wird.

Im ADC-Handler wird dann die Flanke gesucht und das Anzeigefenster
passend positioniert. Das funktioniert ganz gut und ist bei langsameren
Zeitbasen eine echte Hilfe. Ich fürchte, das der Autotriggertimeout
nicht von außen änderbar ist, ich habe da jedenfalls nichts gefunden.

> Kann er mit USTB zusammenfallen?
Da der Kombitrigger während des USTB-Modus nicht gebraucht wird kann der
Timer 1 auch für beide Zwecke verwendet werden.


> Ferner haben wir noch den VSync-Interrupt. Den habe ich noch nicht
> getestet.
Den hatte ich erstmal abgeschaltet, weil dieser ungenutzt ständig
Interrupts erzeugte. Den kann man aber natürlich wie Du schon sagtest
als "arme Leute Timer" verwenden.

Gruß Hayo

In der gestrigen Spätschicht entstand eine sehr optimierte
Linienzeichnefunktion. Die neue Software soll ja mehr Schwuppdizität
haben ;-)
Auch in Assembler dürfte sich das kaum verbessern lassen, das
Disassembly zeigt, daß der Compiler genau das erzeugt hat, was ich von
ihm wollte. Ich habe die Laufzeit mit der alten nicht verglichen, könnte
mir aber Faktor 2 oder so vorstellen.

Stay tuned...
Jörg

Hi Jörg,
ich wollte nur kurz einwerfen, dass ich hochinteressiert mitlese und
begeistert bin, was in so kurzer Zeit schon an Fortschritt erzielt
wurde. Außerdem toll, dass du die Energie hast, das ganze
voranzutreiben! Endlich werden wir die ganzen Altlasten los und
vielleicht läuft das ganze ja in absehbarer Zeit sogar auf dem
Leon-Design von Alex...
Weiter so!

Michael

Hi Jörg, Du bist ja kaum noch zu bremsen. Ich habe die Dateien mal dem
Compiler untergeschoben und Probemessungen gemacht. Die Ergebnisse
lassen sich sehen! Ich hab das im Firmwarethread mal gepostet.

Arbeitet die neue Zeichenfunktion nach Bresenham? Oder hast Du was Neues
ausgebrütet?

Zur Zeit prüfe ich gerade den nr_delay() - Hatte ich das richtig in
Erinnerung, dass der Zähler statt mit 50000 mit 10000 geladen werden
muß?

Gruß Hayo

Hayo W. schrieb:
> Arbeitet die neue Zeichenfunktion nach Bresenham? Oder hast Du was Neues
> ausgebrütet?

Besser als Bresenham geht wohl nicht, dem bin ich schon treu geblieben.
Ich mache aber die Wort- und Bitadressierung gleich mit in der Schleife,
statt eine SetPixel()-Funktion aufzurufen (bzw. als inline drin zu
haben).

> Zur Zeit prüfe ich gerade den nr_delay() - Hatte ich das richtig in
> Erinnerung, dass der Zähler statt mit 50000 mit 10000 geladen werden
> muß?

Nein, mit "nasys_clock_freq_1000" (also 12500), das steht in der Datei
die ich dir schickte aber schon drin.

@Sigi: deine Frage ist eher was für den Hardwarethread
(Beitrag "Wittig(welec) DSO W20xxA Hardware"). Die ADCs oder gar das
FPGA sind meines Wissens nach noch niemandem durchgebrannt. Wenn du dich
mit HDL auskennst, kannst du vielleicht das verwaiste Leon-Design
supporten? Da hätten wir dringend Bedarf...

@All: mein unterer Layer ist letztlich nicht viel Code. Aber er gibt dem
Ganzen hoffentlich eine Struktur. Ich bin auch gespannt auf's Feedback,
möchte ihn zur Eingewöhnung gern bald veröffentlichen. Vorher will ich
aber noch ein "ordentliches" Build-System (sprich Makefiles) und eine
Verzeichnisstruktur hinbekommen haben (lasse mir auch gern dabei helfen,
meine Makefile-Allergie schlägt wieder an). Im Moment verwende ich noch
das alte Schema, alles in ein Verzeichnis, muß meinen Code ferner .cpp
nennen obwohl es eigentlich reines C ist.

Jörg

@Sigi

Willkommen in der Gemeinde :-)

Kann gut sein, dass dem FPGA etwas Kühlung gut tun würde. Leider steckt
das gute Stück in dem schmalen Spalt zwischen den beiden Platinen. Da
passt nicht mehr viel rei, höchstens ein dickes Wärmeleitpad.


Jörg H. schrieb:
...
>> Zur Zeit prüfe ich gerade den nr_delay() - Hatte ich das richtig in
>> Erinnerung, dass der Zähler statt mit 50000 mit 10000 geladen werden
>> muß?
>
> Nein, mit "nasys_clock_freq_1000" (also 12500), das steht in der Datei
> die ich dir schickte aber schon drin.
Das dachte ich mir eigentlich auch so nachdem ich etwas in den Dateien
gestöbert hatte. Tatsache ist aber, dass eine Timingüberprüfung ergeben
hat, dass es erst richtig läuft wenn tatsächlich der Zähler mit 10000
geladen wird. Wie kann das angehen?


Gruß Hayo

Stimmt, das passt nicht ganz, Startwert 10000 ist wenn ich recht
erinnere korrekt. In Zukunft können wir aber mit der Timerfunktion
arbeiten statt mit einer Zählschleife.

Der Thread soll nun aber kein Fachgespräch zwischen Hayo und mir werden.
Solche Details klären wir besser direkt, statt hier die Leute
abzuschrecken. Hier geht es drum, wie es der neuen Firmware geht, was
wir auch gern von Anderen noch brauchen können, welche Entscheidungen
ausstehen.

Zum Status:

In den letzten Tagen habe ich die Zeichenfunktionen "zuende" optimiert
und mich an die Textausgabe gemacht. Es kamen ein paar Funktionen zum
Zeichnen von Buchstaben und kleinen Bitmaps (z.B. Icons) hinzu, sowie
die Handhabung von Zeichensätzen. Dazu mußte ich etwas weiter ausholen:

Bisher sind die Bitmaps für die Zeichen als vertikale Pixelreihen
gespeichert, obwohl der Bildspeicher horizontal organisiert ist. In
einer bizarr ineffizienten Zeichenfunktion wurde das dann zur Laufzeit
gedreht.

In der neuen Software ist das durchgehend horizontal und dürfte eine
Größenordnung schneller sein. Ich muß aber die bestehenden Zeichensätze
und Grafiken in mein neues Format konvertieren. Dafür habe ich nun ein
Programm geschrieben.

Als nächstes ist nun wirklich das von mir nicht so geliebte Thema
Build-System (Makefiles) dran. Mittlerweile stört es an mehreren
Stellen, daß ich meinen C-Code als C++ kompiliere.

Und dem was gern noch kommen möge:

Fühlt sich neben neuen Firmware- und FPGA-Entwicklern auch ein
talentierter PC-Programmierer mittelfristig berufen, uns zu
unterstützen? Ich denke dabei an die PC-Simulation der unteren Layer, um
die spätere Applikationsschicht wahlweise auf einem PC zu kompilieren
und zu debuggen.

Weihnachtliche Grüße
Jörg

Hallo
Betreffend der PC Software könnte ich vlcht. was machen. Kann Assembler
und C für µCs und C#(.NET) für PC, derweil nur auf Windows. Hab' viel
Erfahrung in alldem.
Bitte um eine Beschreibung/Skizze/Spezifikation der Aufgabe um den
Aufwand abschätzen zu können. Bin berufstätig, habe drei Kinder und Frau
die ich (noch) behalten möchte und will nichts anfangen dass ich nicht
fertigmachen und pflegen kann.
Bitte um eine EMail mit mehr Details.
Gruß
Kruno

Hallo Kruno,

danke für dein Angebot. Ist wie gesagt mittelfristig, ich wollte nur
schon mal Reklame machen. Noch ist es nicht konkret genug.
Was würdest du denn gerne machen? Daran liegt es ja hauptsächlich. Der
Spaß an der Sache soll ja nicht abhanden kommen.

Mal so ganz persönlich: Mit Beruf und meine-Frau-behalten gelingt mir
das hier nur knapp, mit zusätzlich 3 Kindern fände ich es geradezu
verantwortungslos, bist du dir sicher daß das hier was für dich ist?

Jörg

Mal weiter zum Status:

ich habe das Makefile umgearbeitet, so daß es mit einer "anständigen"
Verzeichnisstruktur arbeitet und der Code auch in C (statt C++)
kompiliert wird.
Das hat ein paar Probleme gelöst, die mich blockierten. Für den Nios
kommt nämlich ein uralter Compiler, Stand ca. anno 1999/2000, zum
Einsatz (gcc 2.9, aktuell 4.6.x), mit C kommt er beser klar.

Dann konnte ich meine neue Textausgabe mit der Zeichenfunktion testen.
"Hello World" auf dem Bildschirm. Ich habe dann noch ein weiteres
Softwaremodul für Icons gemacht und mit einer Scrolling-Funktion
experimentiert.

Heute ging es zum Aufwärmen mit einem kleinen LED-Treiber los, der auf
dem SPI-Treiber aufsetzt. Im Moment bin ich nun bei einem Treiber für
die serielle Schnittstelle, mit Interrupts und so.

Noch ausstehend: Ähnliches falls möglich für USB, und ein Flash-Treiber
für persistente Daten. Dann kommen die echten Oszilloskopfunktionen:
Kanaleinstellung, Offseteinstellung, Trigger, Capturing.
Und dann kann es mit der Applikationsentwicklung losgehen.

Wenn der Schwung nachlässt mache ich mal einen Release von meinem Code
in Sourceforge, damit man sich das angucken kann. Ohne
Versionsverwaltung fühle ich mich selber unwohl, dann kann man nicht auf
ältere Stände rückgreifen bzw. muß selber Backups machen.

Grüße
Jörg

Status: Der Treiber für die serielle Schnittstelle ist fertig. Ich kann
jetzt im Hintergrund Daten senden und empfangen. Davon verspreche ich
mir Verbesserungen für z.B. die Screenshot-Funktion. Das Hauptprogramm
kann den Bildinhalt komprimieren, während er im Hintergrundübertragen
wird.

@Kruno: nochmals danke für dein Angebot. Da finden wir sicher was. Bist
du bei Skype angemeldet? Wenn, ja, dann schicke mir doch mal deine ID
per PN, ich lade dich gern zu unserem Gruppenchat ein. Größere open
source Projekte haben i.d.R. einen IRC-Channel, wir machen das derzeit
per Skype-Gruppe.

@all: Wer sonst noch rein möchte, einfach melden. Anderes Thema: Fällt
jemandem ein schöner Name für dieses Projekt ein?

Jörg

Ich habe jetzt einen Zwischenstand eingecheckt, zum Review und zur
Sicherheit. Hauptproblem war der Name...  ;-)

Ich habe dem Projekt jetzt den Arbeitstitel 'Osoz' gegeben. Nicht
übermäßig einfallsreich, für 'Open Source Oszilloskop'. Es liegt ganz
bescheiden im Nios-Unterverzeichnis, obwohl es ja nicht nur dafür sein
soll.

Ich hänge hier absichtlich kein .zip ran, um euch gleich die richtige
Arbeitsweise mit Versionsverwaltung aufzunötigen. So kann man prima
verteilt entwickeln, Updates ziehen, Änderungen einchecken.

Man den Dateibaum mit einem svn-Client eigener Wahl auschecken. Z.B. mit
Linux/Cygwin Kommandozeile:

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

Nur nicht so drängeln!  ;-)

Kleines Status-Update: Die Kommentare in den Headern (unter
platform/include) für Funktionen und Typen sind jetzt für Doxygen
formatiert. So haben wir dann stets aktuell eine nette API-Beschreibung
meiner unteren Schicht. Wenn in Zukunft die Applikation auch mit solchem
Kommentarformat geplegt wird dann natürlich auch von selbiger.

Das Makefile ruft Doxgen auch auf, falls installiert, "make doc" erzeugt
die Dokumentation. Sie wird in 2 Formaten generiert: HTML zum
rumklicken, alles schön verlinkt, und LaTex. Wer das installiert hat
kann im erzeugten 'latex' Verzeichnis wiederum make aufrufen und erhält
ein PDF.

Jörg

Ich schreibe mal wieder was, nicht das ihr denkt ich liege hier faul
rum...
Bin fleißig dabei. Was ist seitdem passiert:

- Ich habe das SPI-Timing an den Schieberegisterketten (LEDs,
Kanaleinstellungen) präzise vermessen, damit die Software nicht länger
wartet als nötig (es gibt kein Ready-Flag o.Ä.)

- es gibt jetzt einen (kleinen) Treiber zur Einstellung der DC-Offsets

- ein etwas größerer Treiber ist neu, für die Kanaleinstellungen der
alten und neuen Eingangsstufe

- Optimierungen für die Relais: Settling Time jetzt gemäß Datenblatt,
und auch nur wenn es tatsächlich etwas umzuschalten gab

- die angefangene BitBlit-Funktion ist jetzt vollständig (sie dient zum
Umkopieren beliebiger Bildausschnitte, und ist eine harte Nuß, daran
kann man sich das Hirn verrenken)

- Treiber für Triggereinstellungen, bisher nur für den externen Trigger

Bei letzterem fiel mir auf, das beim externen Trigger ein
Hardwareproblem besteht, zumindest bei meinem Gerät. Könnte die nächste
Tuning-Baustelle sein. Mehr dazu demnächst im Hardware-Thread.

Grüße,
Jörg

Hi Jörg,

ich muß mich entschuldigen, dass ich bislang noch nichts beigetragen
habe zum neuen Projekt. Bin momentan etwas busy und konnte nur schnell
ein paar Bugfixes für die alte Firmware einreichen.

Ich werd mich aber in Kürze mal dranmachen und einen Flashtreiber
beisteuern.

Gruß Hayo

Nachtrag - falls Du mit Hardwareproblem meinst, dass der Triggerlevel
nicht proportional zum Registerwert ist beim Ext. Trigger -> das ist
"normal".

Hab übrigens erste Versuche mit dem KDE-SVN unternommen und die OSOZ
Ordnerstruktur ausgecheckt. Compilieren geht. Hab mal etwas in den
Sourcen gestöbert - ist etwas anders vom Stil als ich es gewohnt bin
aber sieht ganz aufgeräumt aus. Muß mich erst an die neue Struktur
gewöhnen.

Für den Flashtreiber würde ich dann einfach eine flash.c und flash.h
beisteuern, entspricht das Deinen Vorstellungen?

Hayo

Hallo Hayo,

> ich muß mich entschuldigen, dass ich bislang noch nichts beigetragen
> habe zum neuen Projekt. Bin momentan etwas busy und konnte nur schnell
> ein paar Bugfixes für die alte Firmware einreichen.

Kein Entschuldigung nötig, so war mein Posting keinesfalls gemeint. Ich
wollte nur kundtun was so abgeht.

> Nachtrag - falls Du mit Hardwareproblem meinst, dass der Triggerlevel
> nicht proportional zum Registerwert ist beim Ext. Trigger -> das ist
> "normal".

Nein, ich meine damit das ich einen heftigen 500mV-Ripple von der PWM
auf der "Gleichspannung" habe mit der die Triggerung vergleicht. Dadurch
kriegt der Komparatorausgang einen erheblichen Jitter, Netztrigger ist
sogar quasi unmöglich weil des Vergleichssignal eine kleinere Amplitude
hat.

> Hab übrigens erste Versuche mit dem KDE-SVN unternommen und die OSOZ
> Ordnerstruktur ausgecheckt. Compilieren geht. Hab mal etwas in den
> Sourcen gestöbert - ist etwas anders vom Stil als ich es gewohnt bin
> aber sieht ganz aufgeräumt aus. Muß mich erst an die neue Struktur
> gewöhnen.

Ich führe dich gern ran, frag bzw. sag Bescheid was du als ungünstig
empfindest. Die API hat noch kein Review gesehen. Ist keinesfalls in
Stein gemeißelt, sondern ein erster Vorschlag.

> Für den Flashtreiber würde ich dann einfach eine flash.c und flash.h
> beisteuern, entspricht das Deinen Vorstellungen?

Ja, ganz genau. Im "Peer Review" werden wir es spätestens richten.

Ich hätte auch noch zahllose kleinere Fragen, laß' dich gern mal wieder
im Chat sehen... ;-)


Jörg

Bin leider gleich wieder weg zum Punktspiel und komme erst spät wieder.
Wird also heute wohl nix mehr.

> Kein Entschuldigung nötig, so war mein Posting keinesfalls gemeint.
Nein das hatte ich auch nicht so verstanden, aber Du gibst hier so viel
Gas, das man schon etwas ein schlechtes Gewissen bekommt... :-)

Aber ich finde das echt prima, dass Du so vorlegst, das motiviert einen
auch was beizutragen.

> sag Bescheid was du als ungünstig empfindest.
War so nicht gemeint, sondern das ich mich erst an den neuen
Progammierstil gewöhnen muß. Ist doch schon anders als die alten Sourcen
- zum Glück. Macht auf jeden Fall keinen schlechten Eindruck.

> das ich einen heftigen 500mV-Ripple von der PWM auf der
> "Gleichspannung" habe
ist ja eine üble Nummer. Da müßte man auf jeden Fall mal gegenprüfen ob
das auch in der Serie vorkommt und gegebenenfalls versuchen da eine
Filterung einzubauen.


Gruß Hayo

Jörg H. schrieb:
> @all: Wer sonst noch rein möchte, einfach melden.

Sorry, hab kein solches Scope. Vielleicht fällt mir ja mal eins in die
Hände...

> Anderes Thema: Fällt
> jemandem ein schöner Name für dieses Projekt ein?

Wie wärs mit neoWIWEO? ;)

Gruß,
Edson

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

Ich habe den Make-Flow nun so verändert, daß beim Kompilieren auch der
Loader mit gebaut wird, für genau die passende Größe. So hat man dann
automagisch alles richtig beisammen.
Im per Script erzeugten .flash-File wird auch die korrekte Anzahl
Flash-Blöcke gelöscht. (Das Script hat mich echt Nerven gekostet, ich
wollte das erst als Einzeiler mit ins Makefile packen, habe aber
schließlich aufgegeben.)

Man könnte diese Mimik auch für die alte Software übernehmen. Osoz wird
sich vermutlich irgendwann vom getrennten Loader wegevolutionieren...

Jörg

Ich schau mir das Makefile mal an. Inzwischen habe ich mich etwas mit
SVN angefreundet. Scheint soweit ganz gut zu funktionieren. Ich bin auch
schon beim Flash-Treiber (wenn ich zwischendurch mal Zeit hab) und habe
auch schon einige Zwischenstände eingecheckt (wie Du wahrscheinlich
schon bemerkt hast).

Gruß Hayo

Ja, ist beides positiv aufgefallen.  ;-)
Weiter so!

Wo ich denn schon so eine effiziente Art memcpy() für den Loader
gebastelt hatte, habe ich heute daraus eine generische Funktion gebaut,
wie auch für memset(), und beides Osoz hinzugefügt. Sie sind aber schon
noch auf 32Bit Alignment spezialisiert, heißen daher memcpy32() und
memset32().

memset32 ist gut Faktor 2,2 mal schneller als memset, memcpy32 ist 1,4
mal schneller als memcpy.

Im Moment verwende ich die Funktionen zum LCD-Löschen und in meinem
Terminal-Testprogramm zum Scrollen. Eine LCD-Plane löschen dauert 2,4
Millisekunden, eine umkopieren 5,6 ms.

Beim Timer ist eine Inline-Funktion für einfaches timergesteuertes
Warten dazugekommen, der Flash-Treiber scheint Bedarf dafür zu haben.

So long
Jörg

So bin etwas schrumpelig von der Badewanne, muß aber trotzdem nochmal
checken was hier so los ist.


> Wo ich denn schon so eine effiziente Art memcpy() für den Loader
> gebastelt hatte, habe ich heute daraus eine generische Funktion gebaut,
> wie auch für memset(), und beides Osoz hinzugefügt. Sie sind aber schon
> noch auf 32Bit Alignment spezialisiert, heißen daher memcpy32() und
> memset32().
Hört sich gut an. 32 Bit wird aber wohl auch die Hauptanwendung sein
denke ich.

> Beim Timer ist eine Inline-Funktion für einfaches timergesteuertes
> Warten dazugekommen, der Flash-Treiber scheint Bedarf dafür zu haben.
Ja so ist es, für die alte Firmware habe ich dafür ein nr_delay_us()
gebaut und der Niosbibliothek hinzugefügt. Ich brauche eine Möglichkeit
relativ genau (5%) 1 µs zu warten, kann die Funktion das?


Übrigens habe ich nach dem Vorbild von Osoz das Makefile der alten
Firmware umgebaut. Leider habe ich das Problem, dass dis entstandene
Tomcat.flash nur nach manueller Nacharbeit vom Perlskribt geladen wird.
Es hakt daran, dass da Leerzeilen drin sind und nach der Bootroutine ein
S8 Befehl steht der das Skribt zum Anhalten bringt. wenn man das manuell
entfernt funktioniert alles.

Hattest Du da keine Probleme?

Gruß

Hayo

Hayo W. schrieb:

>> Beim Timer ist eine Inline-Funktion für einfaches timergesteuertes
>> Warten dazugekommen, der Flash-Treiber scheint Bedarf dafür zu haben.
> Ja so ist es, für die alte Firmware habe ich dafür ein nr_delay_us()
> gebaut und der Niosbibliothek hinzugefügt.

So etwas ähnliches hatte ich damals auch für das SPI-Bitbanging der
neuen Eingangsstufe eingebaut, Sleep_us().

> Ich brauche eine Möglichkeit
> relativ genau (5%) 1 µs zu warten, kann die Funktion das?

Im Prinzip ja, aber der Call-Overhead kommt hinzu, liegt in der
Größenordnung von 31 Takten, dauert also bereits länger. Mit einem
Dutzend NOPs kommst du wohl besser hin.
Wie immer können auch Interrups dazwischenkommen und die Sache weiter
verzögern (aber derzeit nicht auf's Flash zugreifen).

Bei den Flash-Bausteinen kann man doch in der Regel auch drauf pollen,
das sie fertig sind, mit einem Toggle-Bit?
Es gibt auch einen m.W. noch nicht näher erforschten Flash-Ready-GPIO.

> Übrigens habe ich nach dem Vorbild von Osoz das Makefile der alten
> Firmware umgebaut.
Prima. Ist mir auch aufgefallen. ;-)

> Leider habe ich das Problem, dass dis entstandene
> Tomcat.flash nur nach manueller Nacharbeit vom Perlskribt geladen wird.
> Es hakt daran, dass da Leerzeilen drin sind und nach der Bootroutine ein
> S8 Befehl steht der das Skribt zum Anhalten bringt. wenn man das manuell
> entfernt funktioniert alles.
>
> Hattest Du da keine Probleme?

Öm, könnte dran liegen das ich es selbst nicht ausprobiert habe. Da muß
ich wohl nochmal ran...

Jörg

OK, ist behoben, sorry.
Änderungen im Makefile und im Script.

Jörg

Super, läuft wie geschmiert!

Klasse ist, dass die alte Firmware schon so von den Arbeiten an der
neuen Firmware profitiert. Die Routinen für den Flashtreiber verwende
ich z.B. auch gleich für die alte Firmware, da ich ohnehin die Tests mit
der alten FW mache.

> Bei den Flash-Bausteinen kann man doch in der Regel auch drauf pollen,
> das sie fertig sind, mit einem Toggle-Bit?
Mache ich auch, aber ich möchte das Timeout möglichst genau haben um
nicht versehentlich zu kurz zu liegen (so wie bei der alten Routine).

> Es gibt auch einen m.W. noch nicht näher erforschten Flash-Ready-GPIO.
Den könnte ich mal näher unter die Lupe nehmen.

Hayo

Habe gerade mal versucht das Cygwin auf den aktuellen Stand zu bringen,
falls ich mal unter Windows was machen will oder für diejenigen die kein
Linux haben.

Leider gibt es hier Probleme mit dem Shellscript das die
Sektorlöschbefehle generiert. Aus irgendeinem Grunde bleibt es in der
Schleife hängen und schreibt bis zum jüngsten Tag e00040000 hinein.

Eine Idee?

Hayo

Ah so. Vielleicht kann man zum kompatibleren Berechnen "expr" verwenden.
Vermutlich muß man die Variablen dann dezimal führen, was ich bisher aus
Gründen der Lesbarkeit nicht getan habe.

So in der Art:
addr=262144
...
addr=$(expr $addr + 65536)

Jörg

Edit: es funktioniert zumindest mit der Bash noch, ich checke das mal
probehalber so ein.

Eine aktuellere Cygwin Build Umgebung wäre natürlich das Optimum da wir
dann alles 1:1 übernehmen könnten. Ansonsten übernehme ich erstmal Jörgs
Lösung um überhaupt etwas anbieten zu können.

Ich bin gespannt...

Hayo

Ich habe mir jetzt auch Cygwin auf meinem Windows-Notebook installiert,
allerdings natürlich die aktuelle Version. Das gestrige Script läuft
damit.

Wo bekommt man denn das Nios CDK für Cygwin her?

Jörg

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

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

Hallo Björn,

werde ich probieren, danke!

Das ist ja ein interessantes Versionskuddelmuddel. Ich kannte bisher nur
das verwaiste CDK4NIOS Projekt bei Sourceforge:
http://cdk4nios.sourceforge.net/
Deren neueste Version heißt 2.9-nios-010801-20030923. Die habe ich wohl
probiert. (Und auch unter Linux im Einsatz.)
Nun gerade noch mal frisch mit den Sourcen von Altera. Das ist immerhin
der vertraute configure-make-make install Flow.
Aber auch da entgleist mir das make wieder. Was für einen gcc verwendest
du? (hier: 4.4.3)

Jörg

Jörg H. schrieb:

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

Genau die wollte ich auf den aktuellen Stand bringen. Selbige hat
nämlich den Charme dass man sie ohne Installation auch vom USB-Stick
starten kann.

Übrigens funktioniert das Script auch nach Deiner Modi nicht mit der
alten Cygwin-Umgebung.


@Björn

Wenn Du das so kompakt auf den neueren Stand bringen könntest (mit Bash)
wäre das natürlich echt super. Dann könnte ich (oder Du wenn Du einen
User hast den ich einrichten könnte) das auf SFN für alle zum Download
bereitstellen.

Gruß Hayo

@Jörg

Du musst einen 3er GCC nehmen, mit den 4er GCCs mag er den Code nicht
mehr compilen. Unter Cygwin geht es auch nur mit dem gcc-3 (3.4.4). Dazu
kommt, dass der Source bergeweise DOS line endings enthält. Die müssen
weg, sonst provoziert das auch einige Fehler.

Welche Distri benutzt Du eigentlich zum Entwicklen?

@Hayo

Ich schau mal, was sich machen lässt.

Grüße,
Björn

Hallo Björn,

deine Cygwin-Kompilate funktionieren bei mir. Analog zu der
Linux-Installation habe ich noch so ein Pfade-Setz-Script nach
/opt/cdk4nios/etc kopiert, und mir einen Alias gemacht der das
durchsourced.
Ich habe Osoz erfolgreich damit kompiliert.

Ist aber gruselig langsam. So habe ich das aus einem anderen Projekt vor
Jahren auch in Erinnerung.

Ich habe zum Test erstmal die Default-Installation von Cygwin gemacht.
PATH enthält (dummerweise?) die Windows-Suchpfade, so holt er sich bei
mir "make" aus einer AVR-Installation ran, und würde Perl aus einer
ActiveState-Installation nehmen. Das täuscht drüber weg, daß man das
eigentlich noch bei Cygwin nachinstallieren muß.

Jörg

Hab mir gerade bei meinen Tests für den Flashtreiber das Flash
zerschossen. jetzt warte ich bis der Dump wieder eingespielt ist...

Aber es geht voran.

Hayo

Ok es lebt wieder! Werd jetzt noch mal cygwin testen...

@Björn

Ich habe erstmal die alte Cygwin Umgebung mit Jörgs neuem Script zum
Laufen gebracht und zum Download bereitgestellt. Falls Du da eine
aktuellere Cygwinversion zusammengebaut kriegst sag Bescheid.

Gruß Hayo

Hallo,

ich habe mich mal an einer neue Cygwin Version versucht, inkl. Perl und
passender Pfade. Das Archiv ist allerdings eine ganze Ecke größer als
das Alte (~60MB). Wäre nett, wenn Ihr mal testen könntet, ob das ganze
bei Euch funktioniert.

http://dl.dropbox.com/u/3409975/NIOS_Cygwin_1.7.zip

@Jörg

Ich habe die Version 3.2 von Altera mal unter Ubuntu kompiliert. Falls
das bei Dir sauber funktioniert, könnten wir dann unter Cygwin und Linux
die selbe Compilerversion verwenden.

http://dl.dropbox.com/u/3409975/cdk4nios-linux-3.2.tar.gz

Grüße,
Björn

Hallo Björn,

(ggf. erstmal herzlich willkommen! Du bist mir bisher noch nicht als
"Projektmitarbeiter" aufgefallen. Sorry wenn ich was übersehen habe, bin
neu hier.)

Ich habe da mal reingeschaut, aber aber es noch nicht installiert. Mir
fällt auf, daß ein bischen mehr drin ist, mit Absicht?
Im bin-Verzeichnis finden sich noch bison, flex, make und andere Tools,
die eigentlich besser vom Host kommen sollten. Unter lib liegen auch
noch Systembibliotheken, man und share enthalten "Zeug".
Kann ich natürlich selbst ausdünnen.
Nochmal: mit welchen Compiler kannst du das erfolgreich übersetzen?

@All:
Ich habe gestern noch mit Eclipse experimentiert. Wenn man ein Projekt
passend eingerichtet hat ist das eine sehr komfortable Sache. Ich kann
auf Knopfdruck kompilieren, den Download zum Welec anstoßen, Files in
SVN einchecken. Man hat das Crossreferencing zur Hand, kann also mit
Rechtsklick auf Funktionsnamen oder sonstige Bezeichner gleich zur
Definition springen. Kompilerfehler kann man anklicken und landet gleich
im Code.
Das ist der Mercedes, meine bisherige Arbeitsweise mit getrenntem
Editor, einer Shell zum Kompilieren und dem Download-Batch ist dagegen
wie Dreirad fahren.
(Ich habe Eclipse schon in der Vergangenheit benutzt, eine IDE ist ja
nix neues, nur für die Welec-Sachen halt noch nicht.)
Das SVN-Plugin "stört" sich etwas daran, das wir auf gleicher Höhe wie
das Makefile unsere Produkte ablegen, unter obj/ und die Doxygen-Sachen
unter latex/ und htmt/. Das möchte er defaultmäßig alles mit einchecken,
sehr gefährlich. Man kann das auf die Ignore-Liste setzen, muß es aber
halt tun. Vielleicht sollten wir unseren Flow ändern und die Produkte
unter ../build oder so erzeugen?

Ich habe Eclipse unter Windows eingerichtet, zum Kompilieren muß er dann
Cygwin nehmen. Funktioniert fast genauso wie unter Linux, man muß dem
Projekt als Build Environment PATH nur
"C:\cygwin\bin;C:\cygwin\opt\cdk4nios\bin" mitgeben.

Leider ist Cygwin (bei mir) enorm langsam. Das kleine Osoz-Projekt
kompiliert unter Linux in 3 Sekunden, unter Cygwin bummelt er 54
Sekunden dran rum. (Die Rechner sind beide nicht schnell, Linux ist ein
VIA-C7 Stromsparserver mit 1 GHz, Windows ein Centrino-Notebook mit 2
GHz.)

Jörg

Hallo Jörg,

danke, ich bin in der Tat ganz neu hier.

Du hast recht, das Linux Kompilat gehörte noch aufgeräumt. Ich hatte
gestern nur getestet, ob es bei mir unter Ubuntu BlueFlash kompiliert
und es dann direkt einfach in ein Tar gepackt, um zu sehen, ob das ganze
bei Dir überhaupt funktioniert. Ich hab gerade ein aktualisiertes tar
auf dropbox gepackt, das ist deutlich aufgeräumter.

Wie schon gesagt, mit dem gcc > 4 mag er den Code nicht übersetzen.
Übersetzt ist das ganze also mit gcc 3.4.4 unter Ubuntu 10.04. Den alten
gcc muss man allerdings aus dem Hardy Repository installieren.

Björn

EDIT: Die Cygwin Umgebung habe ich auch noch mal aktualisiert.

Björn F. schrieb:
> Wie schon gesagt, mit dem gcc > 4 mag er den Code nicht übersetzen.
> Übersetzt ist das ganze also mit gcc 3.4.4 unter Ubuntu 10.04. Den alten
> gcc muss man allerdings aus dem Hardy Repository installieren.

Entschuldigung, ich hatte dein Posting von gestern 18:50 Uhr übersehen.
Ich verwende Ubuntu 10.04, auf meinem Stromspar-Server läuft allerdings
was ganz spezielles (Porteus).

Jörg

Hallo Jörg,

ich Dir mal den gepackten Source, so wie er jetzt bei mir compiled, auf
dropbox gelegt.

http://dl.dropbox.com/u/3409975/nios-gnupro-src-3....

Björn

Prima,

das schreitet ja super voran. Auch von mir ein willkommen an Dich Björn.
Bist Du auch ein WELEC-DSO Besitzer oder einfach ein Interessierter?


@Jörg

Habe den vorläufig fertigen Treiber eingecheckt. Die Funktionen sind
soweit als stabil getestet. Nicht getestet aber vermutlich wegen des
einfachen Aufbaus trotzdem ok sind die Byte- und Integerschreibfunktion.

Todo:

- die Delays sind zurzeit noch nicht mit Timer realisiert. Man muß mal
sehen ob das noch umgestellt werden muß

- es gibt nur Grundfunktionen. Spezialisiertere Funktionen werden wir
wohl außerhalb der Treiberschicht implementieren denke ich. Wenn noch
eine entscheidende Funktionalität fehlt bitte ich um Info.

- falls Dir moch weiteres Optimierungspotential auffällt (soll heißen
wenn ich irgendwo einen Bock geschossen habe) immer raus damit.

Hayo

Ich habe heute mal die CDK-Quelltexte der Sourceforge-Version 3.1 und
der Altera-Version 3.2 verglichen. (Björn, wie hast du denn vermutlich
automatisiert die line ends korrigiert?)

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

Hayo W. schrieb:
> Bist Du auch ein WELEC-DSO Besitzer oder einfach ein Interessierter?

Ich habe seit kurzem ein W2024A hier stehen. Dank Eurer Arbeit ist das
Teil für meine Zwecke im Moment absolut ausreichend. Vielen Dank an
alle, die die Firmware soweit gebracht haben. Was Ihr hier mit der neuen
Firmware anfangt, sieht ja auch schon sehr fein aus. Die Möglichkeit
(und wenn aus Zeitgründen auch nur theoretisch) an dem Teil "schrauben"
zu können war dann auch einer der Gründe es anzuschaffen.

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

Tar entpackt, src mit zip wieder komprimiert und dann mit unzip -a
wieder entpackt. Ging bei den vielen kleinen Dateien schneller als find
+ fromdos.

Jörg H. schrieb:
> Vermutlich sind wir mit der gewohnten Version 3.1 besser dran.

Ja, vermutlich. Das war dann also mal effizient Zeit verschwendet :-)

Kann mir jemand sagen, wo der Source für die aktuell verwendete Cygwin
nios-gnupro zu finden ist? Die Versionsnummer ist die
2.9-nios-010801-20030718, was zwischen der cdk4nios 3.1
(2.9-nios-010801-20030923) und 3.01 (2.9-nios-010801-20030320) liegt.

Grüße,
Björn

Hayo W. schrieb:
> Todo:
>
> - die Delays sind zurzeit noch nicht mit Timer realisiert. Man muß mal
> sehen ob das noch umgestellt werden muß
>
> - es gibt nur Grundfunktionen. Spezialisiertere Funktionen werden wir
> wohl außerhalb der Treiberschicht implementieren denke ich. Wenn noch
> eine entscheidende Funktionalität fehlt bitte ich um Info.
>
> - falls Dir moch weiteres Optimierungspotential auffällt (soll heißen
> wenn ich irgendwo einen Bock geschossen habe) immer raus damit.

Ich habe jetzt eine revidierte Version eingecheckt. Sie ist noch völlig
ungetestet, da komme ich vielleicht heute abend zu.



Björn F. schrieb:
> Ja, vermutlich. Das war dann also mal effizient Zeit verschwendet :-)

Finde ich nicht, es ist doch sehr beruhigend, wenn man prinzipiell den
Compiler übersetzen kann.
Hast du dir die Differenz in gcc.c mal angesehen?
Ferner habe ich (unter gcc/config/nios/abi) eine Beschreibung der
Calling Convention gefunden. Bisher konnte ich bei meinen (wenigen)
Assemblerfunktionen nur raten, welche Register ich erhalten muß.

> Kann mir jemand sagen, wo der Source für die aktuell verwendete Cygwin
> nios-gnupro zu finden ist? Die Versionsnummer ist die
> 2.9-nios-010801-20030718, was zwischen der cdk4nios 3.1
> (2.9-nios-010801-20030923) und 3.01 (2.9-nios-010801-20030320) liegt.

Ich leider nicht...

Jörg

Mal was ganz anderes, um nach kleinen Details wieder auf das große Ganze
zu blicken:

Ich mache mir schon länger im Hintergrund Gedanken, wie wir denn in die
Applikation Grund rein kriegen, ohne daß es wieder so ein Verhau mit
ganz vielen globalen Variablen wird. Na gut, so hätten wir das diesmal
nicht gemacht, aber verallgemeinert: ohne eine große Menge Zustände, auf
die an verschiedensten Stellen zugegriffen werden muß. Oder gar an
verschiedenen Orten verändert, mit allen möglichen Konsequenzen der
Aktualisierung.

Angefangen hat mein Gedankenweg bei der Statusleiste, die ich langsam
brauche. Wenn ich an den Kanalempfindlichkeiten drehe, sollen sich die
Werte ja dort wiederfinden. Dazu müßte man im Code der die Drehregler
behandelt Funktionen der Statusleiste aufrufen, daß die sich
aktualisiert. Dabei will der Drehregler doch eigentlich keine
Abhängigkeit zur Statusleiste haben, den interessiert ja gar nicht was
die darstellen will und was nicht. Ähnliches findet man bei weiterem
Nachdenken allerorten: über die serielle Kommandoschnittstelle wollen
wir auch mal Parameter einstellen können, Änderungen sollen im Flash
landen, etc. Ergebnis ist wieder das Gespinst, in dem jeder Zugriff auf
alles braucht und alles ändern kann.

Vor ein paar Tagen ist der Knoten in meinem Kopf geplatzt, nach etwas
Recherche erkenne ich das uns eine "klassische" Model-View-Controller"
Architektur die Sache entwirren würde.
Siehe z.B. hier, Wikipedia fand ich ausnahmsweise nicht so hilfreich:
http://msdn.microsoft.com/en-us/library/ff649643.aspx
(Die Web-spezifischen Details bitte überlesen.)
Es gibt aber noch unzählige weitere Literatur.

Das Modell enthält die eigentliche Mimik, aber keine Darstellung und
keine Bedienung.
Der View ist die Darstellung der Zustände des Modells.
Der Controller steuert das Model, und stößt ggf. Aktualisierung des
Views an.

Das Modell ist in unserem Fall die eigentliche Meß-Maschine des
Oszilloskops. Sie enthält die ganzen Zustände wie Kanaleinstellungen,
Zeitbasis, Trigger, und ist im Prinzip unabhängig lauffähig, wenn auch
erstmal "blind und taub".

Views haben wir mehrere: Die Wellendarstellung incl. Offsets und
Triggerleveln ist natürlich einer. Mitunter gibt es eine zweite
Darstellung, wenn man herumzoomt, das könnte vielleicht ein zweiter View
sein, falls zweckmäßig.
In der Statusleiste sehe ich einen weiteren, die könnte man auf diese
Weise unabhängig halten.
Bei näherem Nachdenken ist auch das Flash einer, denn es empfängt auch
Zustandsänderungen. Es zeigt sie zwar nicht an, aber speichert sie.

Controller haben wir auch mehrere: Als erstes natürlich die Gesamtheit
der Regler und Knöpfe, in Kombination mit dem zu schaffenden Menüsystem.
Ein weiterer ist die serielle Kommandoschnittstelle.
Ein dritter ist das Flash während der Startphase, es hat dann die aktive
Rolle, stellt die gespeicherten Einstellungen wieder her.

Wir haben die aktive Variante von MVC, d.h. nicht (nur) der Controller
stößt eine Aktualisierung der Views an, sondern vor allem auch das
Modell.
Dazu wird das Observer-Pattern erwähnt, genau das schwebte mir auch vor:
Die Views melden sich beim Modell als Beobachter an, um in Folge von ihm
benachrichtigt zu werden. Im Detail können sie noch angeben, für welche
Arten von Ereignissen sie sich interessieren.

Diese Konzepte kommen aus der objektorientierten Welt. In C sollte sich
das mit ein paar Funktionszeigern aber auch hinkriegen lassen.

Ich hoffe, so kriegt man das beherrschbar. Mir fallen gute Nebeneffekte
ein. Die Kommandoschnittstelle kann z.B. völlig gleichberechtigt
agieren, das macht für das Oszi keinen Unterschied.

Kann/mag mir jemand folgen?

Jörg

> Ich habe jetzt eine revidierte Version eingecheckt. Sie ist noch völlig
> ungetestet, da komme ich vielleicht heute abend zu.

Alles klar, ich hab noch einige kleine Scheinheitskorrekturen an der
Namensgebung gemacht und eingecheckt. Sieht soweit ganz gut aus.
Allerdings bin ich mir nicht so sicher ob beim Byte-Verify die
Timerfunktion etwas "träge" ist und unter Umständen das Ganze etwas
verlangsamt.

Hast Du schon eine Test-Suite für den Flash-Zugriff?


> Kann/mag mir jemand folgen?
Jup, das Konzept gefällt mir. Ich werde mich mal etwas genauer in die
Theorie des Model View Controllers einlesen. Grundsätzlich hört sich das
sehr gut an, wir müssen aber mal sehen wie sich das performanceseitig
auswirkt.

Gruß Hayo

Jörg: Ich vermute auch das die Performance darunter leidet, wenn die
Beobachter sich anmelden und extra mit Daten versorgt werden müssen. Ich
würde jedem Beobachter eine änderbare Priorität geben, wann er sich die
benötigten Daten aus einem zentralem Datenspeicher holen darf.

Thomas O. schrieb:
> Jörg: Ich vermute auch das die Performance darunter leidet, wenn die
> Beobachter sich anmelden und extra mit Daten versorgt werden müssen.

Ich meinte nur den Kontrollfluß, nennenswerte Daten werden da nicht
bewegt. Da ist es meiner Erfahrung nach völlig unerheblich, ob. z.B. ein
Tastendruck 3 Funktionsaufrufe auslöst oder eine Kaskade von 10
Aufrufen, ob ein Aufruf hart codiert passiert oder über einen
Funktionspointer.

Pointer darf man ja weiterhin verwenden. ;-)

Ich bin ein großer Freund von performantem Code, habt ihr wahrscheinlich
schon gemerkt. Aber im Kontrollpfad geht eine saubere Architektur
eindeutig vor.

Ein berühmtes Softwarezitat: "Premature optimization is the root of all
evil".
http://en.wikipedia.org/wiki/Program_optimization#...

> Ich
> würde jedem Beobachter eine änderbare Priorität geben, wann er sich die
> benötigten Daten aus einem zentralem Datenspeicher holen darf.

Das habe ich nicht verstanden. Wieso Priorität? Die Benachrichtigungen
müssen doch eh verteilt werden. Kleinere Daten kann man da z.B. gleich
mitgeben, größere kann sich der View in Reaktion abholen.

Thomas, hast du da Erfahrungen mit einem ähnlichen oder anderen Modell?
(Ich will hier keinesfalls irgendwas abbügeln.)

Jörg

nein habe keine Erfahrung mit solchen Modellen, meinte nur das es nicht
nötig ist irgendwelche Benachrichtigungen durch die Gegend zu schicken,
sondern lieber irgendwo ein Bit zu setzen und einzelnen Routinen schauen
dann im Pollinverfahren noch ob etwas interessantes für sie vorliegt.
Wie oft dann eine Routine nachsieht könnte man dann noch mittels Zähler
beeinflussen.

Hayo W. schrieb:
> Hast Du schon eine Test-Suite für den Flash-Zugriff?

Jetzt ja, siehe mein Commit.
Apropos: Hayo, magst du beim Einchecken englische Kommentare verwenden?
Passt besser zum Code.  ;-)

Der Treiber scheint zu funktionieren. Erste Zahlen:
sector erase took 12024502 cycles
byte write took 299 cycles
word write took 963 cycles
sector write took 13989317 cycles

Morgen optimiere ich noch ein bischen dran rum. (root of all evil...)

Zur Architektur später mehr.

Jörg

Warte mal mit dem Optimieren, ich habe noch einige Änderungen die ich
noch eincheckken möchte. Es wird Dir gefallen. Die kannst Du dann gleich
mit optimieren.

Hayo

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

Nun merge ich erstmal...

Jörg

Sector Erase braucht jetzt nur noch die halbe Zeit!

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

Hayo

Hayo W. schrieb:
> Sector Erase braucht jetzt nur noch die halbe Zeit!

Hatte es bei mir auch...
Man braucht nämlich nicht den ganzen Sektor auszulesen. Der interne
Löschalgorithmus ist durch, wenn ein beliebiges Byte 0xFF geworden ist.

Und mein gestriger Fehler: erst recht braucht man nicht für jedes
akkurat gelöschte Byte auf die Uhr schauen.

Ich habe jetzt die Methode "Status aus Chip auslesen" und "externes
Busy-Signal prüfen" ausgiebig verglichen. Ergebnis: das externe Signal
ist langsamer, mitunter drastisch(?), und ich habe es sogar beim Prellen
"erwischt".

In Konsequenz habe ich das wieder ausgebaut. Wir müssen dem nicht
nachtrauern. Ist höchstens dann von Vorteil, wenn es einen Interrupt
auslösen kann (im Nios-Design nicht der Fall) und wir ein
Multitasking-RTOS hätten, was in der Zwischenzeit andere Tasks
dranlassen kann.

Jörg

Schade :-(

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

Gruß Hayo

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

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

Ich glaube nicht das es ein elektrisches Problem ist, vermutlich kriege
ich die Softwaresituation halt nicht nachgestellt. Mit dem LA bin ich
hinter dem Pegelwandler auf dem Welec, da ist es eine Punkt-zu-Punkt
Verbindung zum FPGA.

Kurt hatte (meine ich) eine Leitung auf seiner Platine einfach offen
gelassen.

Jörg

Jörg H. schrieb:
> Wo der LA grad dran hängt habe ich die Auslastung der RS232 beim
> Firmware-Upload gemessen. Da geht noch was, zwischen den S-Record-Zeilen
> macht der Upload Pausen, vermutlich wegen seiner Ausgabe. Mit
> Multithreading könnte man das noch ca. 15-20% schneller kriegen. Ich
> hab's aber nicht so mit Perl.

Das galt dann wohl mir. :-)
Ich schau mir das gelegentlich mal an (wenn sich nicht vorher einer
findet)...

Hallo Jörg,

ich bin seither zwar nur stiller Mitleser, aber da ich mich mit Perl
einigermaßen auskenne, habe ich das Perlskript mal leicht modifiziert,
um die Performance der seriellen Schnittstelle besser messen zu können.
Ergebnis bei mir beim Auslesen der Firmware: ~112,2 kbps (WinXP,
USB-Seriell-Konverter). Damit sind wir schon ziemlich am theoretischen
Maximum von 115,2 kbps => eine Performance-Steigerung um 15-20% ist
(zumindest bei mir) somit also nicht mehr möglich.

Das geänderte Perlskript benutzt jetzt übrigens eine deutlich höher
aufgelöste Zeit und rechnet mit Float-Werten => die Zeitangaben sind
auch am Anfang schon ziemlich stabil und springen nicht mehr so wild hin
und her.

Bei dieser Gelegenheit möchte ich den ganzen Entwicklern und Testern mal
herzlich für die super Arbeit danken. Ihr habt mein W2024 überhaupt erst
sinnvoll verwendbar gemacht.

Gruß, Daniel

Dein Script kann ich nicht downloaden, vielleicht hat die Forumssoftware
was gegen Perl-Attachments, hält die gleich für CGI-Scripte etc.?
Hättest du das vielleicht in einem .zip?

Lesen habe ich nicht getestet, schreiben finde ich relevant. ;-)
Vielleicht erledigt dein Rechner die Ausgabe viel schneller als meine
Möhre.
Besonders drastisch gebremst wird das Script, wenn ich es unter Eclipse
laufen lasse, der sich die Ausgabe abgreift (habe ich noch nicht mit LA
gemessen). Ich denke, da kann es nur dann ungebremst schnell werden,
wenn man das RS232-Protokoll in einen Thread auslagert. Dann kann die
Ausgabe während der I/O-Wartezeit nebenherlaufen.
Ferner muß man ja auch nicht nach jeder S-Record-Zeile was kundtun,
einmal pro Sekunde reicht ja auch.
Das "klassische" Script vertut sich am Anfang ziemlich, weil die Zeilen
mit den Flash-Löschbefehlen so viel langsamer laufen als der Rest.
Noch eine Beobachtung an der Stelle: bei diesen Löschzeilen läßt es sich
auch besonders viel Zeit. Nach dem Bestätigungs-"X" passiert erstmal
100ms lang nichts, bis die nächste Zeile gesendet wird. Die Lücken
zwischen den normalen Datenzeilen sind bei mir unterschiedlich, von <1ms
bis 6ms. (vergleiche Übertragungszeit der Zeile: 4,9ms)

Jörg

Jörg H. schrieb:
> Besonders drastisch gebremst wird das Script, wenn ich es unter Eclipse
> laufen lasse, der sich die Ausgabe abgreift (habe ich noch nicht mit LA
> gemessen).

Hast du denn mal spaßeshalber die Ausgabe auskommentiert und geschaut,
ob es dann Vollgas gibt oder das Ganze doch an irgendeiner anderen
Komponente bei dir liegt?

Johannes S. schrieb:
> Hast du denn mal spaßeshalber die Ausgabe auskommentiert und geschaut,
> ob es dann Vollgas gibt oder das Ganze doch an irgendeiner anderen
> Komponente bei dir liegt?

Das war wohl zu naheliegend als das ich drauf käme...

Aber wenn die Ausgabe in der gleichen Schleife passiert, dann muß sie ja
bremsen.

Habe ich nun gemacht. Die Lücken zwischen den Paketen sind deutlich
kleiner, wenn auch nicht "nahtlos". Ich habe ab und an trotzdem noch
größere Lücken, das liegt wohl an der Auslastung durch den LA, eine
"USBee". Den (oder den Upload) muß ich mal auf einem separaten Rechner
laufen lassen.

Soo eine große Welle wollte ich aus dem Thema gar nicht machen. Nur mal
aufzeigen, daß da noch was geht. Man könnte auch mal ausprobieren,
längere S-Records zu schicken, dann sinkt der Overhead. Ferner kann man
die Übertragung vielleicht sogar ineinander verschränken, noch bevor die
Bestätigung kommt bereits mit der nächsten Zeile anfangen. Weil die
GERMS Monitor Implementation vermutlich nicht mit Interrupts und
Empfangspuffer arbeitet, sondern der Einfachheit halber pollt, geht
vielleicht nur ein Zeichen Verschränkung, z.B. das 'X' nicht abwarten.

@Daniel: Das Perl-Download-Problem bestand wohl nur bei mir. Ich habe
die Datei nun von André bekommen (aber noch nicht ausprobiert).

Jörg

Ich liebe Performancemessungen...  :o)

Also hier der Vergleich vorher nachher:

System: AMD X2 3GHz - echter RS232 Port unter Linux.

Testsuite: Flashen der aktuellen BF-Version.


Ergebnis:

Altes Script 164s
Neues Script 164.2s

Das sieht mir nicht so großartig unterschiedlich aus. Die Ausgabe ist
aber tatsächlich ruhiger. Ich übernehme also die neue Version mal.

Gruß Hayo

So hab mal die Textausgabe ausgeknipst. Ergebnis 161.8s - das scheint
also tatsächlich für die nicht ganz ausgereizte Performance
verantwortlich zu sein.

Hayo

Hayo W. schrieb:
> Das sieht mir nicht so großartig unterschiedlich aus. Die Ausgabe ist
> aber tatsächlich ruhiger. Ich übernehme also die neue Version mal.

Da hatte ich aber irgendwann noch eine klitzekleine Änderung dran
gemacht, wo ich mich gar nicht mehr erinnern kann, warum. Hatte sicher
was mit der Erkennung des Upload-Endes zu tun, aber auf jeden Fall war
das nicht Grundlage der Änderung von Daniel.

Ich führe das mal zeitnah zusammen und schau, dass ich die Ausgabe in
einen anderen Thread ausgelagert bekomme.

Johannes S. schrieb:
> Da hatte ich aber irgendwann noch eine klitzekleine Änderung dran
> gemacht, wo ich mich gar nicht mehr erinnern kann, warum. Hatte sicher
> was mit der Erkennung des Upload-Endes zu tun, aber auf jeden Fall war
> das nicht Grundlage der Änderung von Daniel.

Das war hier:
Beitrag "Re: Wittig(welec) DSO W20xxA Open Source Firmware"

Diese kleine Änderung habe ich jetzt mit Daniels Anpassung
zusammengeführt, siehe Anhang.
Jetzt werde ich mir mal die Ausgabe in einem getrennten Thread zu Gemüte
führen.

Ich habe mich rangetastet, wie lange S-Record-Zeilen der GERMS Monitor
vertragen kann. Ergebnis: 89 Byte. Bisher wurden immer nur 21 Byte pro
Zeile übertragen.

Hayo, wenn du die offiziellen Meßwerte nimmst, dann probier' diese
TomCat.ram mal aus. Sie enthält deine Version 5.2C2, ist aber wegen des
geringeren Zeilenoverheads gut 20% kleiner. Sollte auch entsprechend
schneller laden.

Wie ich die erzeugt habe:
"srec_cat -Output test.hex -Motorola -Line_Length 192 TomCat.ram"
srec_cat ist ein Tool aus dem Paket "srecord". Unter Linux mit der
Paketverwaltung der Wahl zu installieren, gibt es auch für Windows:
http://sourceforge.net/projects/srecord/files/
So ganz perfekt arbeitet es nicht, erzeugt alle 1,5kB ein Alignment und
dann kürzere Zeilen.

Wir könnten so ein Tool zur S-Record Nachbearbeitung mit in den Makeflow
einbauen, oder das Perl-Script müßte die Daten parsen und zu längeren
Zeilen zusammenstellen.

Jörg

Haach, das überschneidet sich alles wieder :)

Ich habe jetzt kein Scope hier, darum kann ich überhaupt nix testen,
aber ich habe mal einen ersten threaded Versuch des Perlscripts
angehängt.
Vielleicht kann das mal einer ausprobieren?

Jörg H. schrieb:
> Wir könnten so ein Tool zur S-Record Nachbearbeitung mit in den Makeflow
> einbauen, oder das Perl-Script müßte die Daten parsen und zu längeren
> Zeilen zusammenstellen.

Erklär mir, was da wie passieren muss, und es wird eingebaut. Das
Verarbeiten von Text ist ja gerade die Domäne von Perl.

Das lange Zeilenformat ist etwas problematisch. Einmal hat der Upload
geklappt. Danach hatte ich nur noch Abbrüche, immer bei Zeile 3, also
der ersten langen Zeile.

Hayo

@Hayo: kannst du bitte mal mit dem ursprünglichen Format den letzten
Skript-Upload testen? Geht das Ding, und wenn ja, wie schnell
(verglichen mit dem alten Skript)?

So und noch ein Vergleich. Um die Scripte mit einander vergleichen zu
können hab ich nochmal einen RAM-Upload mit der aktuellen BF-Version
(mit kurzen Zeilen) gemacht.

-> alte Version 157s
-> Daniels Version 157,7s
-> Johannes threaded Version 157,8s

Die threaded Version hat zudem auch noch ein Problem mit dem Linefeed,
es werden die ganze Zeit neue Zeilen erzeugt.

So viel läßt sich da wohl nicht mehr rausquetschen. Die ein oder zwei
Sekunden kann ich aber auch locker aussitzen. Wenn ich da an die Anfänge
denke als ich noch 20 Min auf jeden Upload gewartet habe...

Hayo

Ich habe die Ausgabe des Threaded-Scripts noch etwas korrigiert, es
landete nicht alles im Thread.
Mit den langen Zeilen hat es Probleme. Merkwürdig, das Script hat doch
keine Limitierung, oder? Vielleicht war es Zufall, ist generell
instabil.
Probiere ich nochmal aus, wenn ich mehr Zeit habe.

So richtig schnell würden wir die Sache kriegen, wenn wir im
GERMS-Format nur einen kleinen Dekompressor schicken und starten, der
dann das eigentliche Image binär und komprimiert über die RS232
entgegennimmt.
Ich habe sowas schonmal gemacht, der Dekompressor (UCL) war ca. 800 Byte
groß, schnell, und effizienter als .zip.
Das würde die zu übertragenden Daten auf ca. 1/10 reduzieren.

Jörg

@Jörg: könnest du dir das nochmal mit dem LA anschauen? Ich vermute,
dass die Perl-Thread-Mimik (also das Übergeben der Ausgabezeile in den
anderen Thread) einfach genauso lahm ist wie die direkte Ausgabe, was es
mit reinem Perl dann also etwas umständlicher machen würde, noch
Beschleunigung rauszuholen.
Achso, und ja, ich hab da leider noch ein paar Stellen vergessen, die
innerhalb der Schleifen eine Ausgabe erzeugt haben, aber die Ausgaben am
Ende sind sicher eher nicht tempo-relevant. Hast du die nur der guten
Ordnung halber auch in den Thread verlegt? ;-)

Und das Vergleichsergebnis mit Jörgs modifizierter threaded Version:

-> 159,6s

Es wird irgendwie nicht besser.

Mir scheint die Kompressormethode tatsächlich die einzige Möglichkeit zu
sein dass ernsthaft zu beschleunigen.

Hayo

Ich vermute die Thread-Aufteilung ist noch ungünstig. Die Schleife
schreibt ja nicht nur auf RS232, sondern kümmert sich auch und das
Dateilesen, Parsing, Übergabe der Ausgabestrings, halt alles außer nun
die Ausgabe selbst. "Idealerweise" macht der eine Thread nur die
Datenpumpe.

Nun denn. Vorwärtsblickend in Richtung Kompression: Johannes, kannst du
das Skript vielleicht folgendermaßen weiterentwickeln:
Wenn eine Zeile mit einem Spezial-Steuerbefehl kommt (irgendein
Anfangsbuchstabe den der GERMSloader noch nicht verwendet), dann
schaltest du in einen zu schaffenden Binärmodus?
Um die Eingangsdaten weiterhin als ASCII zu halten würde ich sagen, da
kommen weiterhin S-Records, aber du müßtest die Binärdaten da rauspuhlen
und senden.
Das ganze so lange, bis der Spezialbefehl wieder zurückschaltet.
Z.B. B1 für binär an, B0 für binär aus.

Ggf. vielen Dank!
Jörg

Jörg H. schrieb:
> Ich vermute die Thread-Aufteilung ist noch ungünstig. Die Schleife
> schreibt ja nicht nur auf RS232, sondern kümmert sich auch und das
> Dateilesen, Parsing, Übergabe der Ausgabestrings, halt alles außer nun
> die Ausgabe selbst. "Idealerweise" macht der eine Thread nur die
> Datenpumpe.

War ja nur ein erster Schnellschuss. Ich werd mal schauen, wo das Skript
welche Zeit vertrödelt, dann stell ich das entsprechend um.

> Nun denn. Vorwärtsblickend in Richtung Kompression: Johannes, kannst du
> das Skript vielleicht folgendermaßen weiterentwickeln:
> Wenn eine Zeile mit einem Spezial-Steuerbefehl kommt (irgendein
> Anfangsbuchstabe den der GERMSloader noch nicht verwendet), dann
> schaltest du in einen zu schaffenden Binärmodus?

Klar. Ist das so geplant, dass das Gegenstück im Scope beides versteht
und mittels des neuen Befehls seinerseits erst in den Binärmodus
geschaltet wird? Bzw., zumindestens sollte der neue Loader im Scope
anders prompten, damit ich erkennen kann, dass ich da in die richtige
Senke hineinschaue.

> Um die Eingangsdaten weiterhin als ASCII zu halten würde ich sagen, da
> kommen weiterhin S-Records, aber du müßtest die Binärdaten da rauspuhlen
> und senden.
> Das ganze so lange, bis der Spezialbefehl wieder zurückschaltet.
> Z.B. B1 für binär an, B0 für binär aus.

Ok. Gib mir mal - falls du das schon hast - ein Stück Firmware mit so
einem Dekompressor (bzw. ein Win- oder Linuxbinary, ich finde
hoffentlich noch einen alten Rechner mit serieller Schnittstelle, der
mir das Scope emuliert), um das dann auch zu testen.

/Hannes

Johannes S. schrieb:
> Ist das so geplant, dass das Gegenstück im Scope beides versteht
> und mittels des neuen Befehls seinerseits erst in den Binärmodus
> geschaltet wird?

Nein, nicht ganz. Auf den GERMSloader haben wir keinen Einfluß, deshalb
müssen wir "klassisch" anfangen. Ich würde dann aber "nur" einen
möglichst kleinen Loader voranstellen, der binär und Dekompression kann.
Der wird als S-Record geladen und gestartet. Das Perl-Script macht
derweil weiter und schickt ihm die Binärdaten.

> Bzw., zumindestens sollte der neue Loader im Scope
> anders prompten, damit ich erkennen kann, dass ich da in die richtige
> Senke hineinschaue.

Das stelle ich mir "on the fly" vor, da wird gar nicht gepromptet. Du
schickst einfach weiter Daten. Wenn's Probleme gibt müssen wir da eine
kleine Pause oder eine Startbestätigung des Loaders einfügen, zugegeben.

> Ok. Gib mir mal - falls du das schon hast - ein Stück Firmware mit so
> einem Dekompressor (bzw. ein Win- oder Linuxbinary, ich finde
> hoffentlich noch einen alten Rechner mit serieller Schnittstelle, der
> mir das Scope emuliert), um das dann auch zu testen.

Da kriegen wir jetzt ein Henne-Ei Problem? Ich kann meinen Loader ohne
deinen Binärmodus nicht gut testen. Da müßte ich mit einem Mischbetrieb
aus Script und vielleicht Terminalprogramm probieren, als Binär
hinterhersenden.
Mir ist nicht ganz klar, was du genau testen willst. Den Binärmodus
kannst du vielleicht mit ein paar Test-Ausschriften in Betrieb nehmen?

Jörg

Ich habe ein wenig mit den Sourcen gespielt. Um sowohl BlueFlash, als
auch die Anfänge von OSOZ besser zu verstehen, habe ich damit begonnen,
BlueFlash auf die Osoz Platform zu "portieren". Über den Sinn der Übung
kann man sicher streiten und bisher beschränkt sich das ganze auch auf
die Display und Flash Teile. Die funktionieren allerdings soweit
problemlos,

Dabei bin ich über einen kleinen Bug in der text.c gestolpert. string
ist ein const char *, ch ist uint32_t. Ohne einen unsigned cast geht das
für Zeichen >127 schief. Siehe Patch.

Gruß,
Björn

Jörg H. schrieb:
> Der wird als S-Record geladen und gestartet. Das Perl-Script macht
> derweil weiter und schickt ihm die Binärdaten.

Einfach so, ohne Punkt und Komma? Ok. :-)

> Das stelle ich mir "on the fly" vor, da wird gar nicht gepromptet. Du
> schickst einfach weiter Daten. Wenn's Probleme gibt müssen wir da eine
> kleine Pause oder eine Startbestätigung des Loaders einfügen, zugegeben.

Jo, das wäre genau das, was ich mir vorgestellt hatte, aber ich bin ganz
offensichtlich nicht ansatzweise so sehr auf Performance getrimmt wie
du, ich geh lieber dreimal sicher als einmal zu schnell.

> Mir ist nicht ganz klar, was du genau testen willst. Den Binärmodus
> kannst du vielleicht mit ein paar Test-Ausschriften in Betrieb nehmen?

Ich wollt nur sehen, ob das, was ich da treibe, auch klappt. Bin gar
nicht auf die Idee gekommen, dass dir das genauso geht. :-)

Also, ich werd dann mal den Binärmodus da reinbasteln und dann sehen wir
weiter.

/Hannes

Björn F. schrieb:
> Ich habe ein wenig mit den Sourcen gespielt. Um sowohl BlueFlash, als
> auch die Anfänge von OSOZ besser zu verstehen, habe ich damit begonnen,
> BlueFlash auf die Osoz Platform zu "portieren". Über den Sinn der Übung
> kann man sicher streiten und bisher beschränkt sich das ganze auch auf
> die Display und Flash Teile. Die funktionieren allerdings soweit
> problemlos,

Sehr schön daß du dich damit beschäftigst!
(Ich hoffe allerdings inständig die Portierung bleibt eine Übung...)
Da haben wir schon noch Besseres vor.
Der Capture-Treiber steht noch aus, dessen bin ich mir sehr bewußt. Aus
bestimmten Gründen habe ich mit dem noch nicht weitergemacht, kommt
aber. Dann kann es mit der Applikation so richtig losgehen.

> Dabei bin ich über einen kleinen Bug in der text.c gestolpert. string
> ist ein const char *, ch ist uint32_t. Ohne einen unsigned cast geht das
> für Zeichen >127 schief. Siehe Patch.

Vielen Dank! Werde ich mir anschauen und korrigieren.

Jörg

Ein freundliches Hallo an die Gemeinschaft der Wittig/Welec Oszilloskop
W2022A Begeisterten.

Da ich neu im Forum bin stelle ich mich kurz mal vor. Rufname Monty, 34
Jahre alt und in der Elektronikwelt tätig.

Ich habe mit großem Interesse die Ideen und die Umsetzung zum Thema
W2022A verfolgt und bin seit ca. 1/2 Jahr auch Besitzer eines dieser
Geräte. Auf der Suche nach einem gut bedienbarem Oszi, bekam ich mal die
Gelegenheit eines zu testen und zu benutzen und so bin ich nach kurzer
Überlegung einem Kaufangebot gefolgt. Die Firmwareumrüstung war mit
einigen Hindernissen verbunden, aber ein gut informierter Kollege konnte
mir da erfolgreich zur Hand gehen, bzw. er hat die Umrüstung erfolgreich
gemeistert. Die letzte verfügbare Version ist vorhanden und lässt sich
auch bedienen, jedoch plagen mein Oszi ein wenig andere Probleme.

Beide Kanäle sind tot, also um es ganz einfach auszudrücken ich sehe auf
dem Display kein Eingangssignal. Ich habe schon mal den Kontakt zu
einigen W2022A Nutzern gesucht, aber hier konnte mir auch nicht geholfen
werden und so hoffe ich bei euch Rat zu finden. Ich denke mal ich
schlage mich da mit einem Hardwareproblem rum, vielleicht es ja auch nix
Wildes, aber ich suche dringend nach einer Lösung. Hat sich jemand schon
mal der Hardware angenommen und eventuell schon mal diesen Defekt
vorleigen gehabt?
Großartiges Messen ohne Stromlaufplan gestaltet sich schwierig, so hätte
ich zumindest mal die Möglichkeit dem angelegten Eingangssignal zu
folgen, aber wild und ohne Plan die Bauteile gegenzuprüfen könnte ein
langes Projekt werden.Gibt es verfügbare Stromlaufpläne die man erwerben
könnte, oder noch besser gibt es unter den Forumsmitgliedern versierte
Fachleute die meine Hardware wieder funktionsfähig bekommen würden?

Meine Ideen sind momentan ein wenig begrenzt, vielleicht sind die A/D
Wandler tot oder ein anderes Bauteil hat sich verabschiedet. Ich kann
leider nur Überlegungen dazu anstellen und komme aber auf keinen grünen
Zweig.

Kann mir da jemand auf die Sprünge helfen?

Danke für Die Infos im Forum, ich werde weiterhin treuer Leser bleiben.

Gruß Monty

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

Grüße
Jörg

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

Gruß Monty

Hayo W. schrieb:
> Und das Vergleichsergebnis mit Jörgs modifizierter threaded Version:
>
> -> 159,6s
>
> Es wird irgendwie nicht besser.
>
> Mir scheint die Kompressormethode tatsächlich die einzige Möglichkeit zu
> sein dass ernsthaft zu beschleunigen.

Ich hätte hier ein nettes Vergleichsergebnis, mein Dekompressor läuft in
erster Version: was haltet ihr von knapp 16 Sekunden? (!)
Kein Tippfehler, könnt ihr selbst ausprobieren, siehe Anhang.

Jörg H. schrieb:
> So richtig schnell würden wir die Sache kriegen, wenn wir im
> GERMS-Format nur einen kleinen Dekompressor schicken und starten, der
> dann das eigentliche Image binär und komprimiert über die RS232
> entgegennimmt.
> Ich habe sowas schonmal gemacht, der Dekompressor (UCL) war ca. 800 Byte
> groß, schnell, und effizienter als .zip.
> Das würde die zu übertragenden Daten auf ca. 1/10 reduzieren.

Genau so habe ich es jetzt gemacht. Weil es den Binärmodus von Johannes
noch nicht gibt habe ich die Ramloader-Scripte so modifiziert, daß die
den Dekompressor klassisch mit dem Perl-Script hochladen, danach ein
Binärfile stumpf auf die serielle kopieren. So haben wir zwar keine
Fortschrittsanzeige und Erfolgsmeldung, aber es funktioniert erstmal.
Kann vielleicht sogar so bleiben?

Der Dekompressor ist knapp 2kB groß, wird selbst in einer knappen
Sekunde hochgeladen. Ich habe ihn in C programmiert, da er doch recht
komplex ist, in Assembler wäre das sehr aufwändig. Etwa 500 Byte an Code
sind nicht von mir, sondern der C-Runtime. Ich habe sie schon sehr klein
konfiguriert. Ein gewisser Overhead müßte auch in Assembler sein, da ich
z.B. den seriellen Empfang mit Interrupts mache. Das ist für die
Parallelität von ungebremster Übertragung und gleichzeitiger
Dekompression nötig.

Der nächste Schritt wäre, so einen Loader auch für's Flash zu machen
(Dieser hier ist nur für Ramload). Er muß dann Sektoren löschen und das
Flash gemäß dem Datenblatt-Algorithmus zu beschreiben. Der Download wird
dann nicht so schnell gehen, weil das Flash selbst dann der Flaschenhals
ist. Es ist leider nicht möglich, einen Sektor im Voraus zu löschen und
parallel einen anderen zu beschreiben.

Zurück zur Praxis, wie erzeugt man so ein .ucl-File mit den passend
komprimierten Daten? Ich verwende den Algorithmus NRV-2e, weil er mit
unseren Daten die höchste Kompression erreicht, siehe:
http://www.oberhumer.com/opensource/ucl/
Man braucht erstmal ein Binärfile der Applikation, statt einem S-Record.
Das geht im Makefile oder einzeln mit:

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

Ich schreib' mal wieder was, nicht das jemand denkt Osoz wäre
eingeschlafen, mitnichten.

Die letzten 2 Wochen habe ich mich dem Exkurs "wie kriegen wir zügig die
Software in's Oszi" beschäftigt, mit denke ich recht gutem Erfolg.
Mittlerweile gibt es das Verfahren auch für's Flash, und kaum langsamer.

Als "Abfallprodukt" ist für Osoz eine schnellere Routine zum Schreiben
in's Flash abgefallen. Der Trick ist, nach dem erfolgreichen Warten auf
ein geschriebenes Byte möglichst schnell das Nächste anzufangen, keine
Totzeit aufkommen zu lassen. Daher bereite ich nach dem Schreibbefehl
das nächste Byte schonmal soweit wie möglich vor. Außerdem wird zu dem
Zeitpunkt getestet, ob das Timeout des vorherigen Bytes überschritten
wurde. Erst dann geht's in die Warteschleife.
Der Effekt ist nicht soo doll wie ich dachte, einen 64K-Sektor flashen
dauert nun etwa 0,7s statt vorher 0,9s, aber immerhin. Hat nun nach dem
Einsatz im Flashloader auch Einzug in den Flashtreiber von Osoz
gehalten.

Ich habe lang und breit experimentiert, wie der Flashloader denn am
Schnellsten arbeiten kann, wie man das am geschicktesten aufteilt. Er
hat 4 Dinge zu tun:
1. Datenempfang (im Interrupt, daher schon mal nebenläufig)
2. Dekompression, wenn Eingangsdaten da sind
3. Sektoren löschen und Bytes flashen, wenn das Flash nicht busy ist
4. Prüfsumme der dekomprimierten Daten errechnen, soweit verfügbar

Die Aufteilung zwischen 2/3/4 ist kniffliger als es sich anhört. Während
das Flash gelöscht oder beschrieben wird kann ich anderswo nicht mal
lesend drauf zugreifen. Ich dekomprimiere daher erstmal prinzipiell ins
RAM, um da nicht limitiert zu sein. (Der Dekompressor braucht den
Rückgriff auf bereits produzierte Daten, das ist gerade der Kern des
Verfahrens.)
Letztendlich mache ich nun die eigentliche Dekompression und
Prüfsummenbildung für einen Sektor in der Zeit, die es braucht diesen
Sektor zu löschen (ca. 0,5s). Auch das Warten auf Eingangsdaten passiert
ggf. dort. Das paßt ganz gut, ich bin eine Idee langsamer, in der Regel
ist der Sektor dann bereits gelöscht wenn ich wieder nachgucke, ich
brauche nicht weiter warten. Das Schreiben passiert dann mit der oben
beschriebenen Routine.

Soweit aus dem Entwickler-Nähkästchen,
Jörg

Ok, vielleicht etwas OT in diesem Thread aber nur ein bißchen. Auch ich
bin nicht untätig (trotz etwas knapper Zeit). Zum Einen verfolge ich
sehr interessiert den Werdegang des neuen Loaders - wobei mir nicht ganz
klar ist ob schon ein stabiles Release erreicht ist oder nicht, benutze
aber noch den Alten.

In der Zwischenzeit bin ich dabei (inspiriert von den OSOZ
Fortschritten) die BF Firmware im Bereich Datenacquisition zu
überarbeiten.

Ziel: alle alten Assemblerroutinen rauszuschmeißen.

Derzeitiger Stand: Die Ausleseroutinen sind schon umgestellt auf C++ und
laufen genauso schnell wie die alten Routinen. Die Invertierung habe ich
wieder in die Capture-Routine zurückverlagert, da ich dadurch doppelt so
schnell geworden bin.

Ich hoffe dass Teile davon in OSOZ einfließen können oder zumindest
hilfreich sind. Die neue BF.5.4 gibt's jedenfalls in Kürze, evtl. schon
mit dem neuen Loader.

Gruß Hayo

Hayo W. schrieb:
> Zum Einen verfolge ich
> sehr interessiert den Werdegang des neuen Loaders - wobei mir nicht ganz
> klar ist ob schon ein stabiles Release erreicht ist oder nicht, benutze
> aber noch den Alten.

Doch, könnte man so sagen. Ich benutze nur noch den Neuen, gerade zum
Entwickeln ist das eine echte Arbeitserleichterung.

Es könnte vielleicht noch Verfeinerungen des Protokolls geben. Das
Perl-Script muß dann zum Loader passen. Dank SVN ja kein Problem.

> In der Zwischenzeit bin ich dabei (inspiriert von den OSOZ
> Fortschritten) die BF Firmware im Bereich Datenacquisition zu
> überarbeiten.

Hmm, du könntest dich auch um den Capture-Treiber von Osoz kümmern. Das
ist ja der letzte, der noch fehlt. Ich schrecke noch ein bischen davor
zurück, wegen diesen unverstandenen Filterung und den "magischen"
Registerwerten. Stattdessen verdrücke ich mich auf
Nebenkriegsschauplätze wie den Loader.  ;-)
Auch sehr unglücklich ist eine Verquickung mit der LCD-Funktionalität:
die Helligkeit des Grid-Layers wird mit ein paar freien Bits der
ADC-Register eingestellt. Aus diesem Grunde erwäge ich, erstmal einen
generischen internen ADC-Treiber zu machen, auf den dann Capture und LCD
zugreifen können. Ähnlich SPI, auch dafür habe ich so einen Innenlayer,
der von LED, Ext-Trigger und Kanaleinstellungen benutzt wird.

Im Moment lerne ich gerade, wie man Interruptserviceroutinen in
Assembler schreibt. Der SDK-Support für Interruptroutinen ist sehr
unglücklich, mit enormen Latenzen. Es dauert 75 Takte bis man endlich in
der eigenen Funktion ankommt, und nach deren Ende nochmal 40 Takte, bis
abgeräumt ist und der Rücksprung erfolgt. Beim der eigentlich sehr
kompakten ISR für die serielle Schnitstelle führt dieser Overhad dazu,
daß die CPU bei Datenempfang bereits zu 20% ausgelastet ist.
Kern des Problems ist, das der Compiler keinen Support für ISRs hat. Bei
den Atmel AVRs gibt Pragmas dafür das ein entsprechender Prolog/Epilog
gebaut wird, bei Nios nicht. Das SDK enthält quasi als Workaround ein
Framework, was für normale C-Funktionen über einen generischen
Einsprungmechanismus vorbereitet und nachbereitet. Der ist recht
umständlich.

So long,
Jörg

Ich sehe Du rührst schon wieder im Eingemachten ;-)

Ich gebe zu, so sehr habe ich mich mit den Interna noch nie
auseinandergesetzt. Aber offensichtlich ist da an Stellen
Optimierungspotential an denen ich das nicht vermutet hätte.

Meine Ausleseroutine vermischt aus Performancegründen den Hardwarelayer
etwas mit dem Applicationlayer. Für OSOZ ist das vermutlich so nicht zu
übernehmen. Aber ich denke man es als Ansatz für die OSOZ-Routinen
verwenden. Unter Umständen siehst Du auch noch Optimierungspotential.
Ich mach das mal fertig und dann kannst Du ja mal nen Blick drauf
werfen.

Ich habe übrigens jetzt auch den hart im Assembler adressierten
Wertebuffer durch ein Array ersetzt. Das ging ja gar nicht...

Unter Anderem stelle ich gerade diverse Variable nach dem Schema
"Variable_CH1, Variable_CH2..." um auf "Variable[4]".

Das ist etwas nervig und mühselig, aber ermöglicht viel schöneren und
schnelleren Code.

Was mir noch einfällt - Du erwähntest die Möglichkeit mit einem
"Section" Befehl bestimmte Speicherbereiche zu reservieren. Ich konnte
da nix drüber finden. Kannst Du mir da auf die Sprünge helfen? So wie es
im Moment läuft, ist es ja vermutlich nur ein glücklicher Zufall, dass
sich das da nicht in die Quere kommt.

So werde gleich mal Frühstück machen.

Gruß Hayo

Hayo W. schrieb:
> Was mir noch einfällt - Du erwähntest die Möglichkeit mit einem
> "Section" Befehl bestimmte Speicherbereiche zu reservieren. Ich konnte
> da nix drüber finden. Kannst Du mir da auf die Sprünge helfen? So wie es
> im Moment läuft, ist es ja vermutlich nur ein glücklicher Zufall, dass
> sich das da nicht in die Quere kommt.

Siehe Osoz (das .ld Script für den Linker), da mache ich das so, für den
Bildschirmspeicher. Dessen Adresse ist ja durch die Hardware fest
vorgegeben, der Rest muß sich drumrum organisieren.
Der Capturebuffer hingegen ist unter unserer Kontrolle, da würde ich das
ohne Not nicht machen. Ganz normal statisch deklarieren oder mit
malloc() holen. Letzteres hat den Vorteil, das der Speicher vom
Startup-Code nicht erst genullt wird, weil er dann auf dem Heap statt im
BSS-Segment liegt.

Jörg

Ja mir geht es da auch nur um die Bereiche die fest vorgegeben sind. Für
den ADC-Readout habe ich einfach ein Array als statisches
Klassenattribut deklariert.

Die Signalbuffer muß ich noch umstellen.

So werd jetzt erstmal den Baumarkt unsicher machen. Noch frohes
Schaffen.

Hayo

Jörg H. schrieb:
> Im Moment lerne ich gerade, wie man Interruptserviceroutinen in
> Assembler schreibt. Der SDK-Support für Interruptroutinen ist sehr
> unglücklich, mit enormen Latenzen. Es dauert 75 Takte bis man endlich in
> der eigenen Funktion ankommt, und nach deren Ende nochmal 40 Takte, bis
> abgeräumt ist und der Rücksprung erfolgt. Beim der eigentlich sehr
> kompakten ISR für die serielle Schnitstelle führt dieser Overhead dazu,
> daß die CPU bei Datenempfang bereits zu 20% ausgelastet ist.

Es hat geklappt, ziemlich auf Anhieb sogar. Ich kann den "isrmanager"
nun weglassen, was mir die Größe der verbliebenen C-Runtime halbiert.
Der Loader ist nun etwas kleiner und schneller.
Ist bei Osoz eingecheckt, aus Versehen hat das keinen Checkin-Kommentar.
(Ist ungefähr so blöd wie eine Email ohne Subject-Zeile)

Hayo W. schrieb:
> Ja mir geht es da auch nur um die Bereiche die fest vorgegeben sind.

Was wäre das? Mir ist nur der LCD-Framebuffer bewußt.

Jörg

Jörg H. schrieb:
> Was wäre das? Mir ist nur der LCD-Framebuffer bewußt.
Genau, aber bis ich alle andern Speicherbereiche umgestellt habe möchte
ich diesen Bereich lieber auch schützen.

Mein Readout schreitet übrigens voran. Zur Zeit experimentiere ich mit
Geschwindigkeitsoptimierungen.

Gruß Hayo

Die ersten Messungen des optimierten Readout ergeben Erstaunliches. Der
Invertierte Modus ist jetzt schneller als der normale Modus!

Dieser bringt die Framerate im Einkanalbetrieb von 969 (Assembler) auf
1059 Frames/min (C-Code) Im invertierten Modus sind es sogar 1155
Frames/min.

Damit bin ich ganz zufrieden.

Hayo

Frames/min ist aber eine ungewöhnliche Einheit.

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

Ich messe in fpm, hatte aber keine Lust zum Umrechnen.

Hayo

Meine Optimierungen und Tests sind soweit fertig. Hier mal das Coding.
Evtl. ist das für den OSOZ-Treiber ja ganz hilfreich.

Den schnellen Predecrement habe ich von OSOZ übernommen.

Vielleicht siehst Du da ja noch Optimierungspotential.

Hayo

Nein, das ist nicht ganz korrekt. Ich wollte nur keine größeren neuen
Funktionalitäten mehr einbauen.

Was ich im Augenblick mache ist eine Mischung aus Optimierung der alten
Firmware und Erkenntnisse sammeln für OSOZ. Das Coding für den aktuellen
Readout z.B. ist entstanden, weil ich gesehen hatte, dass Jörg mit der
Umstellung der ADC-Routinen angefangen hat. Er hat aber bislang nur ganz
fundamentale Funktionalitäten implementiert.

Mit den neuen Routinen der BF-Version hat Jörg jetzt einen weiteren
Anhaltspunkt was noch gebraucht wird und wie man es implementieren
könnte - oder auch noch optimieren könnte.

Die Übernahme einzelner Funktionen von OSOZ in die alte BF ist auch eine
prima Möglichkeit die Funktionalität zu konsolidieren.

Dabei handelt es sich aber immer nur um einzelne Funktionen, die
Gesamtstruktur läßt sich leider nicht mit vertretbarem Aufwand ändern.
Daher wird auf jeden Fall die BF-Version irgendwann ein Auslaufmodell.

Kein Grund zur Sorge also.


Gruß Hayo

Mal wal ganz anderes:

Liest "Toolmaster" Björn noch mit? An den hätte ich mal eine Frage. Wir
haben ja im Moment keinen gdb-Client, aber die Sourcen sehen danach aus,
als ob man einen bauen könnte.
Björn, könntest du das mal versuchen? Mein Thema wäre dann wohl der
Server auf dem Oszi.

Jörg

Hallo Jörg,

ja, ich lese noch mit und schaue mir Eure Änderungen an, komme aber
momentan leider kaum selbst zum Coden.

Unter Cygwin habe ich den GDB nicht kompiliert bekommen (ein Problem mit
TCL IIRC). Das nios-elf-gdb Binary, das in der SF Cygwin Umgebung dabei
ist, läuft (bei mir zumindest) auch nicht (auch TCL).

Ich habe mir das ganze aber auch nicht weiter angesehen, denn unter
Linux lies sich der nios-elf-gdb problemslos kompilieren. Das Binary
startet unter Ubuntu bei mir auch ohne Probleme. Mangels Gegenstelle
habe ich aber noch nicht weiter getestet.

Auf der Suche nach dem Nios Gegenstück bin ich zwar über einen GDB Stub
gestolpert, aber auch hier bin aber noch nicht zum Ausprobieren
gekommen.

http://users.ece.gatech.edu/~hamblen/4006/projects...

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

Gruß Björn

Hallo Jörg,

ich wollte mal den ultra boost loader testen. Beim make bekomme ich aber
schon folgende Meldung:

make: uclpack: Kommando nicht gefunden


Was ist zu tun?

Hayo

immer dasselbe mit dir... :-)))

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

Jörg H. schrieb:
> uclpack installieren.  ;-)

Jupp hatte ich, aber das scheint nicht so ganz geklappt zu haben. Ich
habe die Datei jetzt mal manuell ins bin-Verzeichnis kopiert. Die
Erzeugung der komprimierten Files klappt jetzt.

Allerdings funktioniert Deine ramloader.sh bei mir nicht. Irgendein
Shellbefehl passt ihm da nicht.

Wenn ich das anpasse auf mein System läuft er auch los - aber ich
bekomme folgende Ausgabe:



Device         : /dev/ttyS0
Flash filename : ramloader.germs
UCL filename   : TomCat_ram.ucl

--- Writing GERMS firmware...
Use of uninitialized value $filesize in addition (+) at GERMSloader.pl
line 268.
Writing line 000025 of 000025: Use of uninitialized value $filesize in
concatenation (.) or string at GERMSloader.pl line 273.
S8 detected, end of GERMS transmission.
Successfully wrote GERMS firmware in 0.3 seconds!

--- Writing compressed firmware ( bytes / 0 chunks of 4096 bytes)...
Writing chunk 1 of 0 - Illegal division by zero at GERMSloader.pl line
289.
done.


Hayo

Wenn ich das aktuellste Perlskript nehme kommt folgendes:


Device         : /dev/ttyS0
Flash filename : ramloader.germs
UCL filename   : TomCat_ram.ucl

' not found!at_ram.ucl
done.


Hayo

Er findet die Datei nicht.

Ist aus deinem Make ein TomCat_ram.ucl rausgefallen? Das Makefile muß
analog zu Osoz umgebaut werden.

Ich hatte die Make-Targets von Osoz noch etwas umgeräumt:
Ein normales "make" ohne spezielles Target baut die beiden .ucl-Files,
TomCat_ram.ucl und TomCat_flash.ucl.
Ein "make srec" baut die alten Hex-Files, wie früher.
Für uns ungeduldige Entwickler gibt es noch "make ram", der baut nur das
für Ramload nötige TomCat_ram.ucl.
Ferner noch "make aux" für die Listings und "make doc" für Doxygen.

Die Shellscripte habe ich nicht getestet, mangels Linus nah am Scope.
Wenn da noch was falsch ist, gerne korrieren und wieder einchecken.

Jörg

Jörg H. schrieb:
> Er findet die Datei nicht.

Genau, aber warum? Die Datei steht definitiv im gleichen Verseichnis.

Der Fehler tritt auch nicht nur bei der BF-Version auf, sondern auch bei
OSOZ. Am make kann es also nicht liegen. Das hab ich für das BF-Build
längst angepasst und läuft gut. Es werden schön die komprimierten
Dateien rausgeworfen.

Irgendwie ist es das Perlskript das da über die komprimierte Datei
stolpert - Grund unbekannt.

Hayo

Wäre eine Möglichkeit,

aber ich denke da ist nur die Ausgabe nicht ganz ok. Ich vermute da
kommt ein return bevor die Ausgabe durch ist.

Hayo

Ok - neue Erkenntis!

Unter Windows funktioniert es! Das scheint ein Problem mit Linux zu
sein.

Ich bin leider nicht so firm mit Perl dass ich den Grund erkennen
könnte.
Es ist aber wohl definitiv der Abschnitt ab

if ($uclfilename) {

Danach wird dann die Datei geöffnet was irgendwie schiefgeht. Da ist
jetzt Johannes gefragt. Ich werd mal parallel im Firmwarethread eine
Anfrage machen.

Hayo

Ich habe mal nachgeschaut - in den Scripten sind versehentlich DOS line
endings reingekommen, das habe ich gerade behoben. Ansonsten scheinen
die anzulaufen.
Ich habe kein Oszi hier, kann daher nur trockentesten. Das Perl-Script
scheint mir soweit auch OK zu sein.
Was macht denn ein nackter Aufruf von

perl GERMSloader.pl -d /dev/ttyS0 -b TomCat_ram.ucl

(Schnittstellenname ggf. anpassen.) Ohne irgendwas angeschlossen sollte
der die Chunks der Datei rauspusten, dann ca. 10 Sekunden auf Antwort
warten, danach mit einem Fehler abbrechen.

Jörg

Den Fehler, dass durch das Verwenden der Shellskripte falsche Dateinamen
ans Perlskript durchgereicht werden, wenn in den Shellskripten
DOS-Lineendings stehen, das Ganze aber unter Linux ausgeführt wird
(dadurch bekommt das Perlscript effektiv den Namen TomCat_flash.ucl<#13>
übergeben) werde ich gleich noch abfangen. Danke für's Finden, das hätte
ich selber nie entdeckt. ;-)

Nicht passiert wäre der Fehler übrigens, wenn du es einfach direkt von
der Befehlszeile ausgeführt oder die UCL-Datei über den Automatismus in
der GERMS-Datei angehängt hättest (dort behandle ich die Zeilenenden
schon korrekt, bilde ich mir ein, das überprüfe ich aber auch gleich
noch).

/Hannes

Hi Jörg,

hier das Coding des schnellen ADC_Readout(). Leider läßt sich hier der
Application Layer aus Performancegründen nicht ganz vom Hardwarelayer
trennen. Vielleicht hast Du ja eine Idee wie man das für OSOZ verwerten
kann ohne das Layerprinzip dabei zu verletzen.

Auf jeden Fall ist das Ganze hitverdächtig schnell. Da kann man die
"tollen" Assemblerroutinen getrost vergessen.

Gruß Hayo

Ohne die Details schon zu verstehen fällt mir auf:

Diese parallele Offsetkorrektur funktioniert nur so lange, wie kein
ADC-Wert plus Offset je die Byteauflösung überschreitet. Sonst gibt es
böse Wraparound-Effekte und Überläufer in Nachbarbytes. Vielleicht ein
Grund für (Pseudo-)Spikes? War das vorher auch schon so?

(Pointer-Dereferenzierung für adc_offs muß auch nicht sein, das könnte
einfach ein Wert sein. Mit Glück hat der Compiler das bereits aus der
Schleife genommen.)

Die alte Eingangsstufe ist ja recht schwach ausgesteuert, da mag das
noch eher gutgehen. Wenn die Offsets aus irgendeinem Grunde "aggressiv"
stehen aber auch nicht. Spätestens mit der neuen riecht es nach
Problemen.

Meine 0,02€...

Jörg