Also; Murphy's Gesetz hat wieder zugeschlagen: Ich wollte bei meinem DSO
W2000 Serie die firmware updaten (von 1.0.8.1 auf 1.10.3.1 - bei welec
seit dem 28.3.08) als plötzlich der Strom ausfiel! Nun habe ich beim
einschalten des Oszis kein Bild mehr noch ist ein erneuter Upload
versuch nicht möglich.(per USB) Hat vielleicht jemand eine Idee wie man
nun das DSO wieder zu laufen bekommt?
Vielleicht gibt es ja eine andere Möglichkeit ausser USB.

Joel N. wrote:
> Also; Murphy's Gesetz hat wieder zugeschlagen: Ich wollte bei meinem DSO
> W2000 Serie die firmware updaten (von 1.0.8.1 auf 1.10.3.1 - bei welec
> seit dem 28.3.08) als plötzlich der Strom ausfiel!
...
> Vielleicht gibt es ja eine andere Möglichkeit ausser USB.

Ich habe es via RS232 hinbekommen.

Falk

@Olaf:

> welchen Befehl hast Du für die RS-232-Üertragung eingegeben ?
... um was zu tun?

Man kann ueber die RS-232 Schnittstelle den Flash (in dem die Firmware
fuer den Prozessor liegt, nicht fuer's FPGA) neu beschreiben.
Man kann aber auch alle Einstellungen, die man sonst im Bedienfeld
macht, per RS-232 umstellen.

Nach was suchst Du also genau?

Cheers

Dave

Michael wrote:

...

> Vielleicht probierst Du es erstmal mit Falks Perl-Script?

Das ist noch zu buggy.....

Ich habe es shon verbessert, aber noch nicht hochgeladen.

Im Grunde muß man nur das W2000.zip unzippen und zeilenweise via RS232
(115400Bd) ans Scope schicken. Man muß nur nach jeder Zeile auf den
Prompt (">") warten.

Schick mir einfach eine Nachricht, dann bekommen wir das schon hin...

Falk
P.S.: Auf meinem Rechner läuft TOR, aber nicht als exit-Node. Deswegen
ist es für mich extrem nervig, daß ich hier nix schreiben kann, solange
TOR läuft.

> P.S.: Auf meinem Rechner läuft TOR, aber nicht als exit-Node. Deswegen
> ist es für mich extrem nervig, daß ich hier nix schreiben kann, solange
> TOR läuft.

Das hat wohl damit zu tun, daß manche TOR-Anwender es für nötig befunden
haben, das Forum mit unnötigen Beiträgen zu fluten. Ist zwar schon 'ne
Weile her, aber Andreas und die anderen Moderatoren (mich
eingeschlossen) hatten recht viel Arbeit, den ganzen Müll wieder aus dem
Forum zu löschen. Waren etliche hundert "Beiträge", die innerhalb
kürzester Zeit von irgendsoeinem Skript-Kiddie hier hineingeblasen
wurden.
Deshalb hat Andreas TOR abgeklemmt. Unschön, aber ist halt so.

Hallo Manja,

komme bei uns einfach mal im Club vorbei, frage Andy wann jemand da ist,
dann hängen wir das Wittig an die USV.

Grüße

Chris

Hi,

habe mir ein W2022A zugelegt nachdem ich die Beiträge hier und in den
anderen Gruppen/Foren gelesen hatte da das Gerät eine gute technische
Basis besitzt und es eine vielversprechende Spielwiese für Experimente
darstellt (nicht zu vergessen der günstige Einstiegspreis). Also, kaum
war das Teil da, hab ich mal versucht die (inzwischen modifizierte)
Firmware 1.2 mit Andreas germs_up Programm via RS232 ins Flash zu
schreiben. Das Programm scheint aber nicht richtig mit der RS232 meines
Rechners zusammen zu arbeiten, ebensowenig wie das Perlscript (das ich
in irgendeinem Forum gefunden habe) das im Prinzip das Gleiche macht.
Letztendlich habe ich es mit Hilfe von Minicom in Verbindung mit dem
irgendwo geposteten Script wieder zum Laufen gekriegt.

Leider wurden durch die ersten Versuche anscheinend Teile des
Flashspeichers ausserhalb des Programmbereichs überschrieben, jedenfalls
fehlen jetzt auf dem Eingangsbildschirm einige Daten wie Seriennummer
und Hardwareversion etc. und bei einigen Bildschirmbereichen die
anscheinend aus dem Framebuffer geladen werden gibt es Pixelfehler. Wo
kriege ich einen Flashdump her (habe ich dummerweise nicht vorher selbst
gemacht) und wie kriege ich den am besten wieder ins Flash (via minicom
script?)? Wer kann helfen?

By the way ich habe für Linux ein kleines Programm geschrieben, dass aus
den *.flash files ein minicom script erzeugt. Stelle ich bei Bedarf
gerne zur Verfügung. (Falls es andere probierfreudige W20xxA Besitzer
gibt die dabei auf die Nase gefallen sind oder es vermeiden wollen).

So für meinen ersten Beitrag habe ich jetzt genug geschrieben.

Gruß Hayo

Hallo,

das angehängte .tar Archiv irgendwohin auspacken und in das Verzeichnis
conv2mcom wechseln. Mit "make" wird dann im gleichen Verzeichnis das
Programm erzeugt. Ich habe es unter Suse erzeugt, aber es müßte auch
unter anderen Distributionen problemlos laufen, da es keine
Abhängigkeiten gibt.

Am einfachsten ist es wenn man dann das .flash File ebenfalls in das
Verzeichnis kopiert. Der Aufruf geht dann so:

./flash2mcom <Quelldatei> <Zieldatei>

z.B.
./flash2mcom W2000.flash W2000.minicom

Als erstes durch Drücken der linken beiden Softtasten unter dem Display
den Germs Bootloader aktiveren (die rechtere Taste zuletzt loslassen).

Um dann den Upload zu machen muß man Minicom als root starten(am besten
aus dem Verzeichnis heraus), damit man die Berechtigung zum Zugriff auf
den RS232-Port hat. In Minicom gibt es ein Menü welches man über
"ctrl-a" und dann "z" erreicht. Hier kann man das Skript W2000.mcom dann
angeben und ausführen. Am besten vorher kurz durch Enter ausprobieren ob
das DSO einen Speicherdump schickt, denn dann ist die Verbindung auf
jeden Fall ok.

Falls es ein .flash File aus der Zusammenstellung von Andreas Fellnhofer
ist, möchte ich noch darauf hinweisen, dass das abschließende r0 fehlt.
Ob das evtl. Probleme verursacht kann ich nicht sagen, ich habe es aber
einfach vor der Konvertierung von Hand eingetragen. Mit Minicom lief der
Upload bisher mehrfach ohne Probleme.

Die Laufzeit ist wie schon öfter beschrieben etwa 1,5 Stunden.
Es wird auch empfohlen während des Uploads die Hände still zu halten und
nicht am Oszi rumzuspielen (wohl um keine Interupts auszulösen).

Eine kurze Rückmeldung wäre nett.

Good luck

Hayo

@Markus

Ich hab mir schon gedacht, dass es ein Geschwindigkeitsproblem ist. Mein
Rechner ist ein alter AMD2000 mit 1,6 GHz. Allerdings wundert mich, dass
es mit Minicom nicht geklappt hat, da Minicom mit dem Script nach jedem
Sendebefehl wartet bis eine Antwort vom DSO kommt. Kommt denn der
Overflow error nach jedem einzelnen Sendebefehl?

Lade doch mal deine Progs hoch, das hört sich doch schon mal gut an das
wir zumindest der Ursache näher gekommen sind.

Was das Problem mit der Anzeige angeht, so denke ich dass einige
Bildschirmteile als Bitmaps im Flash liegen und durch diese Aktion
überschrieben wurden. Da hilft dann nur entweder das Flash neu zu
beschreiben oder die defekten Teile im Programm selbst via coding zu
ersetzen.

Wie ich dem Code entnehme liegen in diesem Speicherbereich auch die
Werte für die Korrektur der AD-Wandler (offset und
Verstärkungskorrektur). Ich vermute. dass die bei mir auch was
abgekriegt haben, da bei mir in der Vertikalablenkung die Signalausgabe
nicht mehr auf der virtuellen Nulllinie liegt sondern je nach Bereich um
einen imaginären Gleichanteil verschoben ist -> siehe angehängtes Bild.

Ich werde jetzt mal die Firmware so modifizieren, dass die Werte über
die RS232 ausgegeben werden.

Gruß Hayo

Hayo W. wrote:

...

> Was das Problem mit der Anzeige angeht, so denke ich dass einige
> Bildschirmteile als Bitmaps im Flash liegen und durch diese Aktion
> überschrieben wurden. Da hilft dann nur entweder das Flash neu zu
> beschreiben oder die defekten Teile im Programm selbst via coding zu
> ersetzen.
>
> Wie ich dem Code entnehme liegen in diesem Speicherbereich auch die
> Werte für die Korrektur der AD-Wandler (offset und
> Verstärkungskorrektur)....

So ist das nach meiner Erfahrung auch. Ich hatte mir auch diese Bereiche
im Flash gelöscht. Ein anderer User hier (Bruno W.?) hatte dann einen
Dump des gesamten Flashs gemacht. Nachdem ich den eingespielt hatte,
lief das Scope wieder wie am Anfang.

Ich könnte mit einem Dump dienen....

Falk

Falk Willberg wrote:
>
> So ist das nach meiner Erfahrung auch. Ich hatte mir auch diese Bereiche
> im Flash gelöscht. Ein anderer User hier (Bruno W.?) hatte dann einen
> Dump des gesamten Flashs gemacht. Nachdem ich den eingespielt hatte,
> lief das Scope wieder wie am Anfang.
>
> Ich könnte mit einem Dump dienen....
>
> Falk

Hallo Falk,

das wäre echt riesig. könntest Du den Dump hochladen und kurz
beschreiben wie Du Ihn ins Flash bekommen hast? Da dürfte sich auch
Markus freuen (und vielleicht auch noch einige andere).

Im übrigen bin ich erst über Deine Beiträge und auch die von Bruno und
einigen anderen hier bzw. in google groups auf die Idee gekommen mir so
ein Ding zuzulegen. Zuerst hatte ich nämlich mit einem OWON
geliebäugelt, aber das wäre wohl langweilig geworden...

Gruß und Dank

Hayo

Hayo W. wrote:
> Falk Willberg wrote:

...

>> Ich könnte mit einem Dump dienen....
>>
> das wäre echt riesig. könntest Du den Dump hochladen und kurz
> beschreiben wie Du Ihn ins Flash bekommen hast?

Die Datei ist 1,2MB groß. Sie besteht wieder aus den zum Scope zu
sendenden Kommandos. Ich schicke gerne jedem, der anfragt, URL und
Passwort zum Download.

> Im übrigen bin ich erst über Deine Beiträge und auch die von Bruno und
> einigen anderen hier bzw. in google groups auf die Idee gekommen mir so
> ein Ding zuzulegen.

Dann wußtest Du ja auch, was auf Dich zukommt. War bei mir nicht anders.

Falk

Also hier schon mal eine erste Rückmeldung.

Mein Flash ist jetzt komplett gelöscht!! Weiter ging es aber leider
nicht, da Minicom sich anscheinend an den längeren Strings verschluckt.

D.h. jetzt geht nix mehr. Zwischendurch hab ich mal versucht am germs_up
Programm etwas zu basteln damit die Daten nicht so schnell ins
Senderegister geschrieben werden. Hat aber noch nicht so richtig
funktioniert.

@Falk

Noch mal besten Dank für den Download. Wie hast Du das denn hochgeladen?
Mit dem Perlskript? Das meldet bei mir immer das der Port ttyS0 nicht
geöffnet werden kann.

@Markus

Ich glaube hier muß wohl Dein neues Programm zum Einsatz kommen. Melde
Dich mal wenn es soweit ist. Wahrscheinlich hast Du dann inzwischen auch
den Dump eingespielt.

Gruß Hayo

Markus wrote:
> Den Dump hab ich eingespielt. Jetzt heißt mein Oszi W2016A, Version
> 1.10.03. Das Einspielen hat in etwa 1h15 gedauert.

Na das ist doch super! In der Version müßte ja auch noch die FFT laufen,
dann kann man sich das ja mal anschauen.

Also ich habe auf meinem Athlon 2000 einmal Win XP und einmal Suse Linux
10.x drauf. Ich bin also flexibel.

Ich bin gespannt...

Gruß Hayo

Markus wrote:
> @Falk
> Wie heißen die Befehle um ein Dump des Oszis zu erstellen?
> Dann würde ich da auch in das Programm mit einbauen, dann kann zumindest
> eine Sicherung VOR einem Update gemacht werden.

Also wenn ich das  weiter oben richtig interpretiere, heißte der Befehl
zum Auslesen m40000 und so weiter. Wenn man damit alle Adressen
durchhechelt (die Schrittweite weiß ich jetzt nicht, müßte man aber aus
der Flashdatei ableiten können)  sollte man einen Dump haben.

Sehe ich das so ungefähr richtig?

Gruß Hayo

Markus wrote:
> @Falk
> Wie heißen die Befehle um ein Dump des Oszis zu erstellen?

Die Funktion des germs-monitors ist hier beschrieben:
http://www.altera.com/literature/manual/mnl_niossft.pdf

> Dann würde ich da auch in das Programm mit einbauen, dann kann zumindest
> eine Sicherung VOR einem Update gemacht werden.

Dein Programm werde ich mir als nächstes auch mal ansehen.

Gruß,
Falk

Markus wrote:
> Anbei das versprochene Programmm für Windows und Linux (beide Varianten
> sind im ZIP).
>
> Bekannte Bugs: keine.
>
> Über Rückmeldung der Funktion würde ich mich freuen.

Na gut: ./WelecUpdater: error while loading shared libraries:
libglib-1.2.so.0: cannot open shared object file: No such file or
directory

Ich habe übrigens ein kleines Programm, mit dem man unter Linux die
Meßwerte via USB auslesen kann: Es heißt W2022dump.c und findet sich
hier:
http://welec-dso.googlegroups.com/

Gruß,
Falk
P.S.: Vielleicht sollten wir auf SF
(https://sourceforge.net/projects/welecw2000a/) weitermachen?

Markus wrote:
...
> @Falk, kannst Du aufschreiben welche Pakete Du installieren musst,
> damits tut?

Wahrscheinlich eine Menge 32bit-libs... Ich habe ein 64bit-Linux.

Ich habe aber im Moment nicht viel Zeit.

Gruß,
Falk

Hi,

der Update mit der Windowsversion hat nicht geklappt, das Oszi ist immer
noch tot. Morgen (bzw. heute) werd ich mal die Linux Version
ausprobieren.

Gruß Hayo

@Manja

Hi, ich würde Dir dringend raten erstmal abzuwarten bis a) das
Ubloadprogramm von Markus ausgiebig getestet wurde (mehr dazu weiter
unten)
b) Du von Deinem eigenen Flash einen Dump besitzt, denn unter Umständen
sieht es in Deinem Flash etwas anders aus als in unserem "A" Flash.
Markus wollte noch eine Dumpfunktion in sein Programm einbauen.

@Markus

So jetzt habe ich einige Konstellationen durchprobiert.

PC Athlon 2000 / WinXP -> kein Erfolg Dauer 1,5 Stunden
Lappy HP mit Intel mobile single core 1,6 GHz /WinXP -> kein Erfolg
(1,5h)
PC Athlon 2000 / Linux -> berechnete Dauer 20:00h!!! Hab ich abgebrochen
Lappy Dell Pentium III-500MHz / Win 2000 -> läuft noch

Bei der Linuxversion handelt es sich um die ältere. Ich hab die
fehlenden Teile installiert und dann lief es. Bei allen Versuchen ist
mir aufgefallen, das der Zeilenzeile mehr oder weniger stark springt.
Teilweise nur so um 2 oder 3 im späteren Verlauf sogar um einige
Hundert. Wenn Deine Programmstruktur so ist wie ich mir das denke, dann
sollte das wohl nicht sein, sondern kontinuierlich hochlaufen, richtig?

Gruß Hayo

Sollte natürlich Zeilenzähler heissen ;-)

Hayo

@Markus

Lappy Dell Pentium III-500MHz / Win 2000 -> fehlgeschlagen

Ich werde jetzt mal die neue Linuxversion testen. Ich melde mich...

@Bruno

Ich hatte den Thread hier wieder reaktiviert, da ich das Gefühl hatte
dass es bei SFN und Google Groups eher um konkrete Firmware bzw. FPGA
Themen geht und wollte dort nicht mit Einstiegsproblemen stören. Aber
auf jeden Fall würde ich auch sagen, dass Ergebnisse dort publiziert
werden sollten.

Gruß Hayo

So hier ein Zwischenstand zum Upload mit der gtk2 Version unter Linux.

- Laufzeit bisher 30 Minuten
- Aktuelle Zeile 4400
- berechnete Restzeit 12:50h

Der Zeilenzähler springt im Sekundentakt in zweier oder dreier Schritten
weiter. Ich denke das kann ich wohl abbrechen oder?

Gruß Hayo

Markus wrote:
> Ja und Oszi ausschalten, nach ein paar Minuten Oszi nochmals einschalten
> und nochmal probieren. Ab 500 Zeilen sollte es schon schneller gehen.
> Irgendwie hatte ich bei meinem auch das Gefühl dass er ein PowerDown
> braucht.

-> hat nix gebracht :-(


So hier ein neuer Zwischenstand, nachdem ich den ganzen Tag mit
experimentieren zugebracht hab. (Zum Glück ist die beste aller Ehefrauen
grad im Urlaub).

@Markus

Mit Deinem Uploadprogramm bin ich nicht weiter gekommen. Schade
eigentlich, denn es ist so schön zu bedienen.

Ich hab mal in der Zwischenzeit das germs_up umgeschrieben. Das .flash
File lässt sich damit jetzt in die RS232 schieben. Ich habe das
Beschreiben des Senderegisters auf 2 millisekunden pro Zeichen
beschränkt. Damit scheint der Bootloader keine Probleme zu haben.
Weiterhin wichtig: den Flashdump den wir von Falk bekommen haben muß man
vorher mit unix2dos bearbeiten sonst passiert nix (zumindest unter
Linux).

Zusätzlich habe ich noch den Löschteil und den Schreibteil in
unterschiedliche Files kopiert. Anscheinend ist das DSO nach dem Löschen
erstmal außer Atem und macht dann nix.
Wenn ich es in zwei Schritten mache scheint es zu gehen (Upload läuft
noch).

Die Source hänge ich mal an damit Du Dir das mal ansehen kannst. Das
Programm kann mit make erzeugt werden. Für die Aufrufsyntax einfach
./germs_up eingeben, dann kommt eine kurze Hilfe. Und natürlich mit root
Rechten starten.

Vielleicht kannst Du ja was davon für Dein Programm gebrauchen.

Gruß Hayo

@Markus

Ich sehe Du warst auch recht rege heute. Der Test Deines Programmes muß
noch warten, mein Upload ins DSO läuft noch  (Zeile 110000 siehe voriger
Beitrag).

Ob das Ganze dann läuft wird sich in etwa einer halben Stunde zeigen.

Gruß Hayo

Success!!!

Ok es hat geklappt!!

Das Oszi meldet sich mit:
Model: W2022A
Hardwareversion: 8C7.0G
Softwareversion: 1.10.03

All Rights Reserved 2007!!!

Und tatsächlich es gibt eine FFT. Die ist aber grottenschlecht gemacht.
Da hab ich meine damals in der Diplomarbeit aber um Klassen besser
gemacht. Schätze da muß ich wohl mal ran...

Also wie es aussieht ist meine Vorgehensweise wie weiter oben
beschrieben erfolgreich. Die Gesamtlaufzeit für den gesamten
Flashdump-Upload war 3 Stunden. Mit den 2 Millisekunden Verzögerung ist
das Optimum sicher noch nicht ausgequetscht, ich denke bis 1,5 gehts
bestimmt, aber mit 2 ist man auf der sicheren Seite. Bei 1 Millisekunde
hatte ich hin und wieder einen Klemmer, das ist also nicht sicher.

@Markus
Zumindest ist das schon mal eine Möglichkeit, solange bis Dein Programm
auch auf anderen Rechnern stabil läuft. Übrigens zum Memory Dump - der
Doku von Altera entnehme ich dass Du nur das Offsetregister r auf Null
setzen mußt (r0) und dann immer Return (\r) senden mußt. dann kriegst Du
als Antwort den Dump 64 Byte weise als Antwort.

Danach muß man das nur noch in ein Flaschfile konvertieren. So wie ich
Deinen letzten Beitrag interpretiere bist Du da schon dran.

Gruß Hayo

Hallo Leute.
Da ja jetzt ein paar Experten zusammen sind:

Ich versuche gerade, einen Screendump des W2022A darzustellen.

Leider sieht der wie im Anhang gezeigt aus.

Ich hebe den Verdacht, daß hier ein paar Adressleitungen (X-Achse)
vertauscht wurden.

Kann mir jemand auf die Sprünge helfen, dieses Ding korrekt
darzustellen?

Gruß,
Falk

@Falk

da muß in X-Richtung ein Offset drauf. Dann schiebt sich der ganze
Screen nach rechts und der rechte Teil quasi von hinten rum nach links
vorne. Genaues kann man nur sagen wenn man weiß wie Du das ausgelesen
hast. Also entweder Du korrigierst das schon beim Auslesen, oder Du
verschiebst das nachträglich.

Gruß Hayo

Hayo W. wrote:
> @Falk
>
> da muß in X-Richtung ein Offset drauf.

Stimmt.

> Dann schiebt sich der ganze
> Screen nach rechts und der rechte Teil quasi von hinten rum nach links
> vorne. Genaues kann man nur sagen wenn man weiß wie Du das ausgelesen
> hast.

Der obere Graph ist die steigende Flanke eines Dreiecksignals....

Da ist noch etwas komplizierteres.

Aber da meine Leistungsfähigkeit nach 0:00 drastisch nachläßt, mache ich
jetzt erstmal Schluß.

Gute Nacht,
Falk

@Falk

Wie schon gesagt das ganze Bild muß quasi mit Ringshifting (hinten raus
vorne rein) nach rechts oder links geschoben werden. dann paßt der linke
Rand direkt an den rechten Rand.

Ich werd noch nen Moment weitermachen.

Gruß und gute Nacht

Hayo

@Markus

Habe jetzt Dein Programm getestet. Hier das Ergebnis:

-Testplattform -> Lappy HP Pentium Mobile 1,6 GHz / WinXP
-Flashdumpfunktion -> scheint gut zu funktionieren
-Updatefunktion getestet mit Original FW 1.3, selbst kompilierter FW und
dem Flashdump -> fehlgeschlagen

Der Zeilenzähler springt bei den Löschbefehlen immer um 2 oder 3 und bei
den Schreibbefehlen um 10 bis 80. Die Meldung Schreibfehler und die
Schreibwiederholung kommen nur ein einziges Mal am Anfang. Ich denke
danach hat er wohl das W2000A verloren und sendet nur noch ins Nirwana.

Zum Äußeren und zur Bedienung: Die Oberfläche hast Du wirklich gut
gemacht, läßt sich intuitiv bedienen. Die Bezeichnung Upload/Download
ist für mein Gefühl genau andersherum Bei Upload denke ich immer daran
Daten von meinem Rechner irgendwohin zu laden und bei Download auf
meinen Rechner. Das hat mich zu Anfang etwas verunsichert.

Zu meinen eigenen Versuchen:

Bei meinen Uploadversuchen (ins W2000A) hat es mit dem umgeschriebenen
germs_up mit dem Flashdump geklappt, mit den FW-Files aber nicht.

Wesentlicher Unterschied sind die Sendebefehle. Die langen S31 Befehle
scheinen eine kürzere Antwortzeit zu haben als die S21 Befehle.
Ich habe das Programm im Verdacht, dass es ab und zu einen
Bufferoverflow beim Auslesen der Schnittstelle erzeugt, da es ab und zu
nicht aus der
read() Funktion zurückkommt und auch keinen Timeout mit erneutem
Sendeversuch verursacht. Den Initialisierungsteil und das Signalhandling
hatte ich von Andreas übernommen. Evtl. muß ich das nochmal umschreiben.

So jetzt muß ich erstmal meine Steuer für 2007 fertigmachen, werde aber
trotzdem den Thread im Auge behalten.

Gruß Hayo

@Markus

Sehr cool!! Das Programm wird ja zum echten Überflieger. Ich muß aber
erstmal meine Steuererklärung fertig machen und mich dann schnell noch
mit dem Fahrrad auf zum Finanzamtz machen. Danach kann ich mich mal ans
Programmtesten machen.

Gruß Hayo

Markus wrote:
> @Hayo
> Kannst Du einen Download so nebenher laufen lassen, der dauert sowiso
> ewig...

Ok mach ich.

Bis nachher

Hayo

Hayo W. wrote:
> Markus wrote:
>> @Hayo
>> Kannst Du einen Download so nebenher laufen lassen, der dauert sowiso
>> ewig...
>
> Ok mach ich.
>
> Bis nachher
>
> Hayo

So hier schon mal ein kleiner Zwischenstand:

Testplattform: Athlon 2000 / WinXP
Upload ins DSO / Original FW 1.3 -> Der Zähler springt in
Hunderterschritten und bleibt teilweise ganz stehen.

Upload ins DSO / Flashdump -> Der Zähler läuft erst garnicht an und
springt dann auf 300. Dann hoppelt er weiter in Vierzigerschritten. In
beiden Fällen zeigt der Zähler nach kurzer Zeit viel zu wenig Restzeit
an.
Ich breche das mal ab und switche um auf Linux...

Bis gleich

Hayo

@Markus

Zu Deinem 2/4 Kanal Oszi, die Hardwarekennung liegt im protected Flash.
Ich wollte in den nächsten Tagen einige Routinen schreiben um diese
Werte auszulesen und über die serielle Schnittstelle auszugeben und auch
eine Routine um Werte reinzuschreiben. Dann können wir Dein Oszi wieder
aufpusten auf vier Kanäle (falls Du bis dahin keinen Dump hast, wobei
dank Deines Programms sollte es davon bald genug geben).

So nun zur Testsuite:

Testplattform: Athlon 2000 / Suse Linux 11.0
Upload ins DSO: Selbstkompilierte FW (Tomcat.flash)

Hier sieht alles etwas anders aus.

Status: läuft noch im Debug Mode
Details: Der Zähler springt in zweier Schritten. Im Debuggfenster kann
man leider nicht genau sehen ob er wirklich jede Zeile korrekt schreibt,
da die Ausgabe der Zeilen sich teilweise gegenseitig überdeckt. Ich kann
aber sehen, das etliche Zeilen mehrfach gesendet werden (4 - 5 Mal).

Er braucht dadurch ziemlich lange, die angezeigte Restzeit ist immer
noch bei 2,5h, aktuelle Zeile 4500. Ich denke das Ende werde ich nicht
abwarten. Selbst wenn tatsächlich erfolgreich geladen wird ist es so
noch nicht akzeptabel. Irgendwie müssen die Fehlversuche reduziert
werden.

Mal ne Frage, mit welcher Verzögerung sendest Du die einzelnen Zeichen?
Wie schon erwähnt scheint das W2000 nicht wesentlich schneller als mit 1
Zeichen alle 2 Millisekunden umgehen zu können.

Gruß Hayo

@Markus

ich habe gerade meine Vermutung zu großem Teil bestätigt gesehen.
Nämlich dass das Problem nicht im eigentlichen Sendevorgang liegt,
sondern in der korrekten Initialisierung der Schnittstelle.
Ich hatte ja schon von meinen Schwierigkeiten mit dem germs_up
geschrieben (Timeouts und Hänger etc.). Jetzt habe ich gerade (so wie es
Andreas Fellnhofer in seiner Doku angedeutet hat) vor dem Sendevorgang
einmal minicom gestartet, kurz die Komunikation getestet und dann wieder
beendet. Danach habe ich dann das germs_up gestartet - und was soll ich
sagen, es läuft wie Schmidts Katze. Ich will mich jetzt noch nicht zu
weit aus dem Fenster hängen, da der Upload noch läuft, aber auch nach
14000 Zeilen kein einziger Fehlversuch!!! Ob Dein Programm da auch drauf
anspringt, werde ich nach dem Upload mal ausprobieren.

So wie es den Anschein hat müssen wir unser Augenmerk also auf die
Portinitialisierung legen.

Gruß Hayo

Hayo W. wrote:
> @Markus
>
> ...Jetzt habe ich gerade (so wie es
> Andreas Fellnhofer in seiner Doku angedeutet hat) vor dem Sendevorgang
> einmal minicom gestartet, kurz die Komunikation getestet und dann wieder
> beendet. Danach habe ich dann das germs_up gestartet - und was soll ich
> sagen, es läuft wie Schmidts Katze.

Und ich dachte, das läge an mir...

> So wie es den Anschein hat müssen wir unser Augenmerk also auf die
> Portinitialisierung legen.

Das werde ich mir morgen mal ansehen. Mehr als das, was "stty -a <
/dev/ttyNN hergibt, kann es ja nicht sein.

Falk

@Markus
So, der Upload mit germs_up war erfolgreich! Kein einziger Ruckler. Das
selbstkompilierte 1.2 sah allerding wegen des völlig zerschossenen
Flashs ziemlich zerfranst aus, aber lief...

So danach hab ich dann das gleiche mit Deinem Programm ausprobiert. kein
Erfolg. Es hoppelt immer noch -> und ... mein Schirm ist wieder dunkel
nix geht mehr.
Aber die Richtung ist klar oder? Rumspielen an der Initialisierung bis
der Arzt kommt oder es problemlos funktioniert.

@Falk
Ich poste mal die aktuelle germs_up Version, damit kann man auf jeden
Fall schon mal (mit minicom Starthilfe) die flash.files hochladen, auch
wenn der Comfort von Markus Programm fehlt.
Wie sieht es denn mit Deinem Screenshot aus? Bist Du da weitergekommen?
An so einem Ausleseprogramm wäre ich auch interessiert!

Gruß Hayo

Markus wrote:
> PS: Sollten wir vieleicht diese Dateien besser per Mail austauschen?

Also ich denke wir sollten das ruhig weiter so machen, dann kommen
vielleicht noch ein paar freiwillige Betatester dazu. Den Downloads nach
scheint ohnehin schon der Eine oder andere im stillen Kämmerlein zu
testen. Müßte nur noch das Ergebnis hier gepostet werden...

Hayo

Markus wrote:
> Hol doch noch meine Versin von meinem Post 23:32 Uhr ab, damit könnte
> das Linux Start Problem gelöst sein.
> Bei mir läuft gerade noch ein Upload unter Linux.

Hab ich doch schon längst. Was denkst Du wohl wo die Downloads
herkommen?
Allerdings hab ich gerade einen anderen Test laufen. Ich wollte mal
sehen, ob der Upload mit germs_up (und minicom als Starthilfe) auch mit
dem kompletten Flashdump File funktioniert. Das hatte ich letztes Mal ja
nur in zwei Teilen laden können. Tja, und wie vermutet -> es läuft.

Der Löschteil ist etwas langsam aber danach rappelt er richtig los -
keine Verschlucker. Interessanterweise ist der waiting Timer
(Antwortzeit nach einem Sendebefehl) absolut konstant auf 49. Sonst hat
er immer stark variiert. D.h. es gilt jetzt die Initialisierungsdetails
rauszufinden die minicom hier vorgibt. Ich verrmute, dass es nicht die
Sendeeinstellungen sind, sondern die Empfangseinstellungen.

Da es bei Deinem Programm nicht funktioniert hat, denke ich das Du
bestimmte Einstellungen erzwingst die aber von denen der Minicom
Einstellungen abweichen.

Hayo

So ich lasse den Upload jetzt weiterlaufen und gehe ins Bett.
die weiteren Tests mach ich morgen im laufe des Tages nebenbei. Bist Du
morgen tagsüber schon aktiv, oder erst abends?

Gute Nacht

Hayo

@Markus

Ich habe mir mal eine Memory Map gemacht. Ich sehe das mit der
Flash-Endadresse genauso. D.h aber, das im flashdump ein Sektor zuviel
gelöscht wird und auch viel zu viel Adressraum beschrieben wird
(bis 008D 9200). Da sollte aber schon längst das RAM angefangen haben.

Laut Kommentar im generiertem Flashfile fängt das RAM sogar schon bei
0x0080 0000 an, was heißt, dass das Flash nicht komplett dekodiert wird.

Das werde ich auch noch testen

Gruß Hayo

@Markus

übrigens habe ich auch mittlerweile eine Erklärung für die
unterschiedlich lange Antwortzeit bei den verschiedenen Schreibbefehlen.
Die Befehle aus dem Flashdump werden absolut adressiert, d.h. der
GERMS-Monitor kann die Adresse direkt schreiben (r0). Bei den FW-Update
Files handelt es sich um relative Adressen. Das Offsetregister wird mit
r00800000-00040100 initialisiert und der GERMS-Monitor muß dann die
absolute Adresse daraus berechnen. Das dauert natürlich einen
Augenblick.

Ich werd mal die Unterlagen zu meinem alten Motorola DSP56000 Evaluation
Board rauskramen, da gibt es nämlich auch den GERMS-Monitor und die
Flash-Files waren auch im gleichen srec-Format. Ich erinnere mich ganz
wage, dass es da eine detailierte Doku zu gab.

Bis heute Abend

Hayo

So, schnell noch ein abschließender Kommentar.

Hab mich nochmal schlau gemacht.

http://de.wikipedia.org/wiki/S-Record

War bei mir mittlerweile über 10 Jahre her, dass ich damit gearbeitet
hab, aber jetzt bin ich wieder im Boot. Für die meisten anderen hier
wahrscheinlich ein alter Hut...

Gruß Hayo

So bin jetzt erstmal mit meiner Arbeit fertig und kann mich jetzt den
wirklich wichtigen Dingen widmen ;-).

Also ich vermute ganz stark, das bei 0x8000 0000 das RAM tatsächlich
anfängt, daher würde es keinen Sinn machen da noch weiter zu lesen. Ich
werde das aber noch prüfen.

Ich werde mal das Flashdumpfile zerpflücken und in die Teile

 Firmware mit Bootloader  Protected Flash  Überflüssiges aufteilen

und auch den Löschteil entsprechend anpassen, dann kann man bei unseren
Versuchen die Speicherbereiche getrennt voneinander beschreiben.

Leider bin ich noch nicht zum Testen gekommen, da ich den ganzen Tag am
Programmieren war (beruflich).

Wenn ich die Teilungen fertig hab melde ich mich. Inzwischen werde ich
mal Dein neues Programm anwerfen und meine gerade wieder restaurierte
Firmware zerschießen. Meine Mailadresse schick ich Dir auch gleich noch.

Gruß Hayo

Hayo W. wrote:
> So bin jetzt erstmal mit meiner Arbeit fertig und kann mich jetzt den
> wirklich wichtigen Dingen widmen ;-).
>
> Also ich vermute ganz stark, das bei 0x8000 0000 das RAM tatsächlich
> anfängt,...

meinte natürlich 0x0080 0000

Hayo

So hier schon mal die FW 1.10.03, mit der FFT aktiviert. Noch nicht via
Upload getestet -> also auf eigenes Risiko wer sich das Ding runterlädt
und ins DSO flasht!!

Hayo

@Markus

Hier noch der restliche Teil vom Flash. Den Teil ab 0x0080 0000 hab ich
abgeschnitten da hier wohl nur ins RAM geschrieben wird. Ist ziemlich
kompakt jetzt (unter 30000 Zeilen). Der Upload dürfte schön schnell
gehen. Die Restlichen 70 000 Zeilen waren meines Erachtens ein reiner
RAM-Dump.

Ob das stimmt werden wir in Kürze wissen. Ich werde gleich mal testen.

@Bruno

An dieser Software hab ich nichts geändert. Ich wollte nur die Besitzer
einer neueren Version (so wie ich) darauf hinweisen, dass in dieser
Version die FFT aktiviert ist, damit man sich das mal ansehen kann wie
man es nicht machen sollte. Ich wollte dann auf der 1.2 Version von
Andreas aufsetzen und da eine neue FFT programmieren, insbesondere den
grafischen Teil. Ich kann ja mal Bilder von meiner alten Diplomarbeit
rauskramen, dann wisst Ihr was ich mir so vorstelle und könnt gleich mal
Kritiken anbringen.

Gruß Hayo

@Markus

So hier ein erster Bericht:

Testplattform: Athlon 2000 / Suse 11.0
SW Version: Updater_V0.3.8A20
Daten: protected.flash

-> Der Upload funktioniert anscheinend, aber: das Verhalten ist
unverändert wie gestern beschrieben. Er braucht für jede Zeile mehrere
Versuche, bis das W2000 sie endlich akzeptiert. Dadurch wird die
Gesamtprogrammierzeit viel zu groß (für die mickrigen 27 000 Zeilen
3,5h)

daher habe ich nach einer halben Stunde abgebrochen. Die
Konfigurationsdaten hat er anscheinend korrekt reingeschrieben.
Jedenfalls stimmen die Oszidaten und auch der Signaloffset ist korrekt.
Diese Daten liegen wohl direkt im Bereich hinter dem Programm, (siehe
tc_vars.h ->

#define protected_Config_Flash (unsigned long *)  0x000F0000 )

Alles was danach kommt ist unvollständig, da ich den Upüload abgebrochen
habe (sieht lustig aus...). Insbesondere die Bitmaps fehlen anscheinend.

Gruß Hayo

Habe jetzt das aktuelle germs_up laufen -> klappt sehr gut. Viel
schneller und auch keine Fehlversuche. Hatte vorher einmal kurz minicom
gestartet.

Gruß Hayo

Übrigens noch eine Beobachtung die dafür spricht, dass das Flash bei
0x0070 FFFF zuende ist -> die Löschbefehle in der Ursprünglichen
Flashdumpdatei brauchen ab 0x0800 0000 ungefähr die drei bis vierfache
Zeit, was natürlich kein Wunder ist, da keine Löschbestätigung vom RAM
kommt und dann irgendwann der timeout greift.

Hayo

So, hab das germs_up noch mal ein kleines bißchen überarbeitet und das
Timing noch mal verschärft um zu sehen was geht. Läuft ohne Probleme...
(diesmal ohne minicom vorher zu starten, sollte es jetzt ok sein?)

Werde mal den Rechner neu durchstarten und das Oszi resetten und dann
nochmal mit verschiedenen Flashfiles testen, ich melde mich...

Hayo

Hier das Sendelog, scheint korrekt zu schreiben, aber seeeehr langsam.
Wenn das Timing etwas schneller wär, könnte man das fast so lassen.

Gruß Hayo

Jetzt teste ich nach einem Rechnerneustart (um sicher zu sein dass die
RS232 nicht anders vorinitialisiert wurde) mit der aktuellen germs_up
Version.

Source -> Original W2000.flash File von Wittig
Status -> läuft ohne Probleme trotz verschärftem Timing und ohne vorher
minicom gestartet zu haben.

Interessanter Effekt: bei den S3 Befehlen mit absoluter Adresse war der
Timer konstant auf 49 - bei den S2 Befehlen mit relativer Adresse
scheint die Antwortzeit stark von der Adresse abzuhängen.

Ich hänge das Programm mal an. Würdest Du das auch mal testen, damit ich
mal einen Vergleich habe?

Gruß Hayo

Markus wrote:
> @Hayo
> Noch eine Idee zu WinXP:
> Systemsteuerung >> Geräte-Manager >> Computerverwaltung >> im Zweig
> "Geräte-Manager >> unter Anschlüsse >> COM-Port >> Eigenschaften >>
> Anschlusseinstellungen >> Erweitert...
>
> Ist da der FIFO-Puffer aktiviert?
> Hier kannst Du auch den Interrupt von 14 (16) mal runter stellen, dann
> lößt der UART früher einen Interrupt aus (der Puffer wird nicht kleiner,
> der ist in der HW fest drin)
> Wenn das Häkchen nicht gesetzt ist, dann ist der Puffer deaktiviert und
> wenn Windows nicht schnell genug ist gehen Zeichen verloren.


So schon mal eine schnelle Rückmeldung zur Windowsversion:
-> Respekt, es klappt und zwar hitverdächtig schnell!!!!!!

Ich hab an den COM Einstellungen nichts geändert, ist alles original
WinXP. Teste noch weiter, Details gleich...

Gruß Hayo

So hier jetzt Details zum Test:

Zur Schnittstelle: alle COM-Ports sind im Rechner integriert,
keine USB->RS232 Wandler.

Rechner: Athlon 2000 (1,66 GHz)

Betriebssystem: WinXP (SP3)

Softwareversion des Updaters: 0.3.8A20

Testfile: original W2000.flash von WELEC -> erfolgreich Dauer 20 min!!!
Testfile: protected.flash aus meinem Posting gestern abend ->
erfolgreich Dauer 17 min.

Das DSO befindet sich danach komplett im Originalzustand und
funktioniert einwandfrei (abgesehen von den Firmwarebugs).

Die Geschwindigkeit ist erstaunlich, damit ist der Upload 2 -3 mal
schneller als mit der original USB-Software von WELEC. Vielleicht
solltest Du Ihnen das Programm verscherbeln damit sie auch mal was
Vernünftiges anbieten können ;-)

Wie es aussieht kannst Du diese (Windows) Version jetzt offiziell
freigeben, werde aber gleich mal mit einigen anderen Rechnern testen.

Gruß Hayo

So hier nun weitere Testergebnisse zur Windowsversion:

Rechner: Lappy HP Intel Mobile (1,66 GHz)
Betriebssystem: WinXP (SP2)
Softwareversion des Updaters: 0.3.8A20
Testfile: Tomcat.flash eigene Kompilation -> erfolgreich - Dauer 24 min

Rechner: Lappy Dell Pentium III (500 MHz)
Betriebssystem: Win2000 (SP4)
Softwareversion des Updaters: 0.3.8A20
Testfile: Tomcat.flash eigene Kompilation -> erfolgreich - Dauer 27 min

Rechner: Lappy Gateway Pentium I (166 MHz)
Betriebssystem: Win98
Softwareversion des Updaters: 0.3.8A20
-> keine Funktion, nicht lauffähig unter Win98

Ich denke abschließend läßt sich sagen, daß die (Windows) Version beim
Upload stabil ist. Jetzt muß ich noch die restlichen Funktionen testen.

Übrigens hatte ich einen interessanten Effekt beim Upload des
Tomcat.flash. Als ich nach dem Stand des Uploads sehen wollte war das
Oszi schon am laufen - ohne Neustart. Der abschließende S8048565A071
Befehl scheint den Germs-Monitor neu zu starten, echt cool.

Übrigens noch ein kleiner Änderungsvorschlag: die Endadresse des Flash
in der ini-Datei auf 0x7F FFFF setzen, da sonst das RAM ausgelesen wird.

Bis nachher

Hayo

Oszi-Beobachter wrote:
>>Habt ihr gesehen was Slog2 in SF geschrieben hat?
>>http://sourceforge.net/forum/forum.php?thread_id=2...
>>offensichtlich bekommen wir auch bald eine einfachere Möglichkeit (als
>>über JTAG) für den FPGA upgrade. Dann sollte das wirklich auch für
>>unerfahrene User zu machen sein.
>
>
> Treiber ist jetzt oben !!

Das wird ja immer besser!!

Ich habe nochmal den original Updater von WELEC ausprobiertm, der läuft
tatsächlich schneller, hatte ich irgendwie anders in Erinnerung, in
meinem Alter vergißt man halt schnell... ;-)

Allerdings verweigert der USB-Updater die Zusammenarbeit mit den
selbstkompilierten flash Files.

@Bruno

Danke


Gruß Hayo

Markus wrote:
> @ Bruno:
> Die letzte veöffentlichte Version V0.3.8A20 ist hier:
> Beitrag "Re: Wittig(welec) Oszilloskop firmware problem"
>
...

> Ich freue mich schon auf Rückmeldungen.

Ich kann's leider nicht benutzen, weil ich einen USB-RS232-Adapter
benutze.
In der Linuxversion könntest Du alle vorhandenen /dev/ttyS* und
/dev/ttyUSB* anbieten.

Gruß,
Falk

Bruno W. wrote:
> @ Falk:
> Falls du möchtest kannst du ja einmal den USB-Blaster von Slog
> austesten. Das sieht wirklich gut aus!!!

Dazu müßte ich Windows starten. Und meine Toolchain für nios habe ich
nur unter Linux laufen...

Falk

Falk Willberg wrote:
> Bruno W. wrote:
>> @ Falk:
>> Falls du möchtest kannst du ja einmal den USB-Blaster von Slog
>> austesten. Das sieht wirklich gut aus!!!
>
> Dazu müßte ich Windows starten. Und meine Toolchain für nios habe ich
> nur unter Linux laufen...
>
> Falk

Das ist bei mir auch so, deswegen wär's auch cool wenn wir den Updater
unter Linux vernünftig zum Laufen brächten. Ich vermute mal, dass der
Crosscompiler auf Windows optimiert ist. Wenn das so ist könnte es
schwierig werden.

Andererseits kostet mich das Umswitchen auf Windows nur einen Neustart
(3 Min). Damit kann man zur Not leben wenn man dann gute Werkzeuge unter
Windows zur Verfügung hat.

Zur Zeit teste ich bei der Windowsversion die Flashdumpfunktion ->
dauert ziemlich lange, weil er wirklich alle Adressen abklappern muß,
auch die leeren.

Melde mich nachher dazu

Hayo

@Markus

Test Download Flashdump -> fehlgeschlagen

Hab gerade ein 35MB großes Logfile erstellt!! Damit es etwas handlicher
wird hab ich etliche Bereiche in denen nichts weiter passiert, als das
er über leere Speicherstellen springt, rausgelöscht. Der Grund für die
große Datei ist, dass er sich irgendwann an einer Adresse festgebissen
hat und dann immer wieder versucht hat hier zu lesen. mehrere Male hab
ich den Eintrag Reinitialisierung gefunden.

Ich vermute, dass evtl. das Problem daraus resultiert, dass der Rechner
in den Suspend geschaltet hat. Könnte sein dass dann beim Aufwachen das
wiederaufsetzen nicht geklappt hat. Durch die lange Laufzeit muß man
aber damit rechnen, dass der Suspend kommt. D.h. hier muß das
Wiederaufsetzen an der letzten Adresse klappen.

Gruß hayo

@all

Ich stelle gerade eine Memory-Map zusammen auf Basis der original
Konfiguration des W2000A (W2000???), weiß jemand was in den Bereichen
vor 0x0004 0000 und hinter 0x00A0 0040 liegt?

Hayo

Hier die erste Version der Memory Map. Die Bereich oberhalb und
Unterhalb muß ich noch recherchieren. Wenn's vollständig ist gibts das
Ganze auch als Excel, das leg ich dann auf SFN ab. Für Anregubgen und
Tips bin ich jederzeit empänglich. So und nun leg ich mich in die
Wanne...

Bis dann

Hayo

Ich teste morgen (heute) im laufe des Tages.

gute Nacht

Hayo

@all

Moin, moin

mal ein Gedanke aus einer anderen Richtung: Nachdem sich jetzt
abzeichnet, dass wir eine gute Basis an Tools haben müßten wir uns mal
Gedanken ums Organisatorische machen. Ich gehe mal davon aus dass sich
bei dem jetzt vereinfachten Zugang zur Materie etliche Leute dranmachen
werden und an der Firmware rumschrauben. Da gibt es dann auch noch die
beiden grundsätzlichen Richtungen Neuentwicklung mit neuem FPGA-Design
und Weiterentwicklung auf Basis der Version 1.2 mit dem bisherigen
FPGA-Design.

Da sollte es eine Einigung zu den Versionsnummern geben sonst gibt es da
einen unüberschaubaren Wildwuchs und keiner weiß mehr welche Funktionen
(und Fehler in welcher Version stecken). D.h. man könnte die
weiterentwickelten Versionen auf Basis der V1.2 z.B. so benennen,
V1.2.<Entwicklerkürzel>.<Version>.<Subversion>.

So kann man sehen, dass die 1.2 die Ausgangsbasis ist und kommt auch
nicht mit zukünftigen offiziellen Versionen von WELEC (falls da welche
kommen) durcheinander.

In regelmäßigen Abständen könnte man dann die einzelnen
Entwicklerversionen zu einem Majorrelease zusammenfassen bei dem dann
statt Entwicklerkürzel die Majorreleaseversion steht
V1.2.<Majorrelease>.<Subrelease>. Vernünftige Doku im Header und
Kommentare im Coding würden die Wartung und Verwaltung vereinfachen.

Ich denke nur so haben wir die Möglichkeit statt eines reinen
Bastelprojekts eine vernünftige Weiterentwicklung zu machen.

So das ist jetzt mal eine Anregung, gibt es da andere Vorschläge oder
haltet Ihr das für übertrieben?

Gruß Hayo

@Bruno

Ich denke auch, das Beste wäre SFN bzw. Google Groups als offizielle
Plattform zu nutzen. Das erweitert den Bereich der Angesprochenen auf
den gesamten Englischsprachigen bzw. English verstehenden Sprachraum.
Trotzdem finde ich dieses Forum als schnelle und unkomplizierte
Kommunikationsplattform ganz in Ordnung. Wir müssen nur drauf achten,
dass neue Erkenntnisse dann nach außen weitergetragen werden und die
Versions und Sourcenverwaltung dann auf SFN bzw. GG stattfindet.


Im Übrigen sehe ich die Entwicklungen auf Basis des alten und neuen FPGA
Designs nicht unbedingt als völlig von einander getrennte Zweige. Ich
denke wenn es ein neues FPGA-Design gibt muß eigentlich nur der
Hardwarelayer komplett neu gemacht werden, viele von den bis dahin
entwickelten hardwareunabhängigen Funktionen kann man dann direkt oder
angepasst übernehmen. So muß das Rad nicht immer neu erfunden werden und
wir haben in absehbarer Zeit ein Oszi das auch den Vergleich mit
renomierten Marken nicht zu scheuen braucht.

Gruß Hayo

@Markus

So die nächsten Testergebnisse:

Updaterversion: V.0.3.8A21
Plattform     : Athlon 2000 / WinXP (SP3)
Dumpdownload  : erfolgreich - Dauer 45 min
Dumpupload    : erfolgreich - Dauer 34 min

Das Oszi ist danach wieder komplett im Ausgangszustand.

Der Suspendunterdrücker funktioniert sehr gut - Es wird nicht einmal der
Bildschirmschoner aktiviert. Da scheint der Noactivitytimer komplett
zurückgesetzt zu werden. Hast Du die Funktion nur für den Download
implementiert, oder auch für den Upload? Das konnte ich jetzt noch nicht
überprüfen.

Gruß Hayo

Manja wrote:
> Erstmal Hochachtung für das was hier passiert, bekomme immer mehr Lust
> an mein Welec was zu tun.
> Kann man das auch alles mit dem Modell ohne (A) machen, oder gibt es
> schon ne einfache Möglichkeit selber upzudaten. Nache vielen Mails habe
> ich aufgehört bei welec zu Fragen wie das mit dem Update aussieht. Nie
> eine Antwort bekommen.
>
> LG
>
>    Manja

Hallo Manja,

ich denke jetzt kannst Du mit einsteigen und Dein W2000(ohne A)
untersuchen. Du kannst ja mal einen kompletten Dump von Deinem Flash
machen, (mit der Updaterversion V.0.3.8A21). Wenn Du dann probeweise
neue Firmware einspielst und es schiefgeht kannst Du danach alles wieder
zurücksetzen auf den alten Stand.

Ich vermute allerdings, das ein einfaches Einspielen der Firmware nicht
reichen wird. Da wird wohl nicht viel funktionieren wenn ich das richtig
mitbekommen habe. Grund wird wohl eine geänderte Aufteilung im
Config-Bereich des Flash sein. D.h. den Config-Bereich müßtest Du auch
neu beschreiben. Dafür kannst Du die protected.flash Datei verwenden die
ich weiter oben gepostet habe.

Letztlich gibt es natürlich keine Garantie, dass nicht auch das
FPGA-Design geändert wurde. Ich gehe aber stark davon aus dass WELEC
sich nicht die Mühe gemacht hat und für alle Versionen das
Referenzdesign verwendet hat.

Das Ganze natürlich at your own risc. Denn Du weißt ja: Garantien gibt
Dir keiner - nicht mal der liebe Gott.

Wenn Du einen Dump gemacht hast, kannst Du Ihn ja mal für andere
Besitzer eines alten W2000 hier posten, damit sie evtl. Ihre zerflashte
Kiste wieder zum Laufen kriegen.

Gruß Hayo

@Bruno

Was vieleicht auch ganz geschickt wäre, das ist wenn wir einen
Themenkatalog erstellen (quasi eine ToDo-Liste) bei der sich dann
einzelne Entwickler zuordnen können. Das hätte den Vorteil, dass

- nicht mehrere Entwickler gleichzeitig an gleichen Themen aneinander
  vorbeientwickeln

- wenn mehrere Entwickler am gleichen Thema arbeiten, diese sich
  besser austauschen können

- man grundsätzlich weiß wen man zu welchen Themen am besten
  ansprechen kann

- man (der Koordinator) beim Zusammenstellen von Majorreleases
  den Überblick behält

Als Themen fallen mir so abrupt folgende ein:

- Quadraturdecoder für die Drehgeber
- Bildschirmdesign (unter anderem die Gridteilung)
- Geschwindigkeitsoptimierungen
- Mathematische Funktionen (insbesondere FFT, da würde ich
  mich ganz gerne mit beschäftigen)
- Neue Funktionen (z.B. Auswerten von Busprotokollen, Logicanalyser)
- Rauschreduzierung mit FIR/IIR-Filtern (hatte Andreas da nicht was
  zu geschrieben?)
- Übertragung zum PC
  |-PC-Auswertungssoftware (da ist meines Wissens Falk dran)
  |-Übertragungsroutinen im W2000A (USB/RS232)
  |-Flashdump und Updatesoftware (da hätten wir dann Markus)
- Hardwaremodifikationen
  |-zusätzliche Anschlüsse (Markus wollte einen Erdungsanschluß)
  |-Einbau eines Akkus mit Ladeschaltung (wollte ich bei mir einbauen)
  |-weitere Schnittstellen
  |-

So, bin sicher dem einen oder anderen fällt noch was ein.

Auch das ist wieder als Anregung zu verstehen um das Ganze in sinnvolle
Bahnen zu lenken und überschaubar zu halten.

Gruß Hayo

Zum Themenkatalog:


Da hab ich jetzt natürlich noch nicht die Themen für das FPGA-Neudesign
berücksichtigt. Hierzu fehlen mir die Detailkenntnisse. Nach meinem
bisherigen Kenntnisstand sind hier die Russischen Entwickler um Slog auf
jedenfall dran. Wer ist denn hier noch in das Thema involviert??
Interesse daran haben ja einige gezeigt (siehe Google Groups und SFN).


Gruß Hayo

Markus wrote:

> @Bruno W.
> Wegen dem Wicki: Es wäre schön wenn alle Dateien als HTML verfügbar
> wären, dann kann daraus eine Komplett-Doku mit z.B. einer CHM Datei
> gemacht werden.
>
> Ich habe da schon angefangen und die erste Steite Doku für den
> WelecUpdater geschrieben. (Quelle als HTML, Doku als CHM kompilliert)
>
> Ich finde CHM Doku ist einfach angenehmer zu handeln als Anwender (auch
> offline) und die Quellen sind gut handelbar als Entwickler.

Womit erstellst Du denn Deine HTML-Doku?

Hayo

Hayo W. wrote:

...
> - Übertragung zum PC
>   |-PC-Auswertungssoftware (da ist meines Wissens Falk dran)
>   |-Übertragungsroutinen im W2000A (USB/RS232)

Ja, ein wenig. Ich habe erstmal die PC-Übertragung der Puffer in der 1.2
halbwegs repariert. (Basierend auf der Version "Official_Build" aus dem
SF)

Ich glaube, daß sich ein Screendump, geschickter programmiert, in 1/10
Sekunde übertragen lassen müsste.

Die Arbeiten an der Firmware und der PC-Software müssen natürlich
koordiniert werden. Leider habe ich fast keine Erfahrung mit PC-GUIs.

> Auch das ist wieder als Anregung zu verstehen um das Ganze in sinnvolle
> Bahnen zu lenken und überschaubar zu halten.

Deswegen werde ich jetzt nach Sourceforge gehen ;-)

Falk

Hayo W. wrote:

> Als Themen fallen mir so abrupt folgende ein:
>
> - Quadraturdecoder für die Drehgeber
> - Bildschirmdesign (unter anderem die Gridteilung)


Noch ein Nachtrag zum Punkt Bildschirm, das könnte man so aufteilen:
-Display
 |-Videogenerator
   |-Charactergenerator
   |-Grafical functions
 |-Screenlayout
   |-Menülayout
   |-

oder so ähnlich.

Hayo

@All W20xxA Owners

kann jemand mit einem aktuellen Gerät d.h. mit ausgelieferter Firmware
1.2 oder 1.3 (nach dem 14. Juli ausgeliefert) mit Hilfe des Updaters der
Version V.0.3.8A21 (oder höher wenn bis dahin verfügbar) einen Flashdump
ziehen und hier posten, da wir zur Zeit nur einen von einem älteren
Gerät
haben. Wäre interessant ob sich da was geändert hat.




Danke Hayo

Hayo W. wrote:
...
> Wäre interessant ob sich da was geändert hat.
>


Am Protected-Bereich meinte ich natürlich.

Hayo W. wrote:

> Hallo Manja,
>
> ich denke jetzt kannst Du mit einsteigen und Dein W2000(ohne A)
> untersuchen. Du kannst ja mal einen kompletten Dump von Deinem Flash
> machen, (mit der Updaterversion V.0.3.8A21). Wenn Du dann probeweise
> neue Firmware einspielst und es schiefgeht kannst Du danach alles wieder
> zurücksetzen auf den alten Stand.
>


Hallo noch mal,

warte noch mal mit den Experimenten, ich habe beim Rumprobieren
rausgefunden, dass wahrscheinlich der Flashbereich doch größer ist als
in der SREC-Datei im Header angegeben. Das hieße dann, dass dir ein Teil
fehlt.

Ich melde mich sobald ich dazu eine endgültige Aussage machen kann.

Gruß hayo

Markus wrote:
> @Falk:
> Du möchtest die Kommunikations-Komponenten vom Oszi auf Fordermann
> bringen...
>
> Ich kann Dir helfen ein "WelecView" für Darstellung von Kurvengrafiken
> auf dem PC helfen...

Wenn Du Dir mal http://www.mtoussaint.de/qtdso.html ansehen willst. Da
ist schon vieles (für ein Velleman PCS64i) fertig. Es müßten die
Bedienung und der Datentransfer angepasst werden.

Diese Funktionen habe ich zum Teil schon mal angepaßt, scheitere aber am
GUI.

Mit Qt ließe sich das sowohl für Windows als auch für die Unixe
realisieren lassen. Ich kenne Qt aber praktisch nicht.

Ich fühle mich an Systemschnittstellen und auf µCs wohler.

Falk

@Markus

Noch ein Vorschlag für Programm: Wenn der Löschteil durchlaufen wird
kommt nur die Meldung "Programmiere bitte warten" ohne eine weitere
Ausgabe.

Perfekt wäre es, wenn er die Löschbefehle erkennt und ausgibt:

"Lösche Sektor" und dann den Sektor im Adressfenster anzeigen.

und dann bei den Schreibbefehlen
"Schreibe auf Adresse" oder so ähnlich

Wie siehst Du das?

Hayo

Markus wrote:
> @Falk
> Mit Qt habe auch noch nie etwas gemacht. Ich habe mir vorgestellt etwas
> mit Lazarus aufzubauen. Vorteil: Das Programm läuft einfach ohne irgend
> was extra installieren zu müssen, so wie der WelecUpdater.

Wenn man, was der Fall sein dürfte, C-Bibliotheken linken kann, sehe ich
kein Problem, das Backend zu programmieren.

> Ich kann mir auch vorstellen dass der Screen auch Online nicht nur am
> Oszi sondern auch auf den PC übertragen kann. (ist ja USB)

Bei 10Ms/s dürfte das knapp werden. Aber 640*2 Bytes, also die Werte auf
einem Screen, sollten sich sogar über RS232 in etwa 1/10 Sekunde
übertragen lassen.

Falk

Wichtig für die PC Software fände ich, dass man den Screendump in
kompletter Breite, also die 16k Speicher exportieren kann!

@Markus

ich hab mir die Version mal gezogen. Testergebnis folgt. Ich hab heute
den ganzen Abend mit der 0.3.8A22 (Windows) getestet. Ca. 10 - 12 Up und
Downloads mit unterschiedlichen Dateien. Läuft super stabil, keine
Probleme. Zweck der Sache war es eigentlich die Speicherbereiche nochmal
auszuloten.

Verunsichert war ich weil bei mir folgender Effekt auftrat:

Beim Einspielen der Flash-Files (FW und Protected bzw. kompletter
Flashdump) in unterschiedlicher Reihenfolge scheinen bei einer
bestimmten Kombination die Konfigurationsdaten für den Kanal 2
überschrieben zu werden. Jedenfalls liegt das Signal von Kanal 2 beim
ersten Start "flach am Boden" anstatt sich im unteren Drittel
einzupendeln. Wenn der komplette Dump der Version 1.10.03 eingespielt
wird ist der ganze Spuk vorbei und beide Signale sind beim ersten Start
wo sie hingehören.

Hatte das außer mir noch jemand beobachtet? Ich teste jetzt erstmal aus
ob wirklich was überschrieben wird, oder ob die 1.3 Firmware
diesbezüglich eine Macke hat.

Gruß Hayo

@Markus

Schon mal vorab ein Lob, schön implementiert die Adressanzeige. So ist
man wirklich die ganze Zeit auf dem Laufenden. Teste jetzt mit der neuen
Version weiter und melde mich zu der Sache mit den Konfigurationsdaten.

Hayo

branadic wrote:
....
> Anfangs läuft alles problemlos und man sieht schön, wie eine Zeile nach
> der anderen ausgelesen wird. Dann plötzlich verliert das Programm seine
> Verbindung und versucht erneut zu verbinden... nach ein paar Versuchen
> klappt das dann scheinbar auch, einige Zeilen werden gelesen und *zack*
> ist die Verbindung wieder weg.
> Ich werde das heute Abend noch einmal probieren und berichten.
>
> Beste Grüße, branadic

Hallo branadic,

das hatte ich auch, bei mir war es wohl der Suspend der zugeschlagen
hat, denn seit Markus den Suspend-Unterdrücker eingebaut hat ist es
nicht wieder aufgetreten. Zur besseren Nachvollziehbarkeit schreib doch
mal ein paar Details zu Deiner Testumgebung:

- Updaterversion
- Rechnerhardware
- Betriebssystem (Servicepack)
- Laufzeit bis zum Abbruch

Wenn Du im Debuggingmodus bist kannst Du nach einem Download ein Logfile
erzeugen indem Du mit der rechten Maustaste in das Debuggerfenster
klickst. Da kannst Du dann das Ergebnis als Liste kopieren und in einem
Editor einfügen. Da kann Markus dann evtl. mehr draus ersehen.

Gruß Hayo

Hi,

war gestern etwas busy und hatte keine Zeit. Aber hier jetzt wieder neue
Ergebnisse zu den überschriebenen Konfigurationsdaten:

- der protected Bereich wird nicht beim flashen überschrieben
- die FW 1.2 / 1.3 hat einen weiteren Bug

Und zwar werden die Konfigdaten beim Start des Oszi überschrieben. Die
Stelle im Coding muß ich noch raussuchen.

Das Ganze ist beliebig reproduzierbar. Folgende Testreihe habe ich
wiederholt durchgeführt:

- upload protected-flash
- upload FW 1.10.03 -> alles läuft normal
- upload FW 1.3     -> config ist beschädigt
- upload protected-flash
- upload FW 1.10.03 -> alles läuft normal
- upload FW 1.3   kein Neustart!!!!!
- upload FW 1.10.03 -> alles läuft normal

Weitere Testergebnisse zum Updater folgen noch

Gruß Hayo

branadic wrote:
...
> Wie speichert man eigentlich im Debug Modus? Muss ich zeilenweise
> kopieren? Irgendwie wollt das bei mir nicht so recht klappen.
>


Hallo branadic,

wie ich weiter oben schon mal beschrieben habe:

mit der rechten Maustaste ins Debuggfenster klicken, kopieren als Liste
auswählen und in einen Editor kopieren.

Gruß Hayo

branadic wrote:
> Hallo zusammen,
>
> wusst ich doch, dass ich die Mailadresse irgendwo gesehen hatte, hab sie
> nur nicht wiedergefunden.
> Also die Mail ist raus. Ich hoffe Markus kann damit was anfangen.
> Seltsam nur, das sich so wenig Leute beim Test beteiligen. Scheinbar
> haben doch eine ganze Menge Leute solch ein Oskar, da möchte man doch
> meinen, dass die Beteiligung etwas höher wäre!?
>
> Gruß, branadic

Hallo branadic,

ich denke, dass wohl einige noch zögern, weil sie Angst haben sich Ihr
Gerät zu zerschießen. Aber, sein wir ehrlich, wenn Markus und ich uns
nicht gleich zu Anfang unser DSO mir dem alten germs_up von Andreas
zerflasht hätten, dann wäre wahrscheinlich auch nicht nach so kurzer
Zeit eine so ausgefeilte Software dabei rausgekommen. Man muß halt ab
und zu ins kaltze Wasser springen. Ich hatte mein Gerät schon 4 Stunden
nach öffnen des Kartons zerschossen, das ist doch wohl rekordverdächtig
oder?

Apropo, wenn ich das weiter ober richtig gelesen habe hast Du doch
inzwischen einen Download hinbekommen. Würdest Du den zur Verfügung
stellen? Markus und ich haben (weil wir unser DSO eben vorher schon
zerschossen hatten) dank Falk nur ein Update der Config-daten auf dem
Stand  der alten 1.10.03 FW. Wäre nett wenn man mal sehen könnte ob es
da Unterschiede gibt.

Gruß Hayo

@branadic

Super, vielen Dank. Wie ich am Downloadcounter sehe bin ich auch nicht
der einzige der interessiert ist.

Gruß Hayo

@Markus

...dachte ich mir schon. Bin übrigens dabei die Linuxversion zu testen.
Die Uploadrate ist allerdings tränentreibend. FW-Update 3 Std + !!

Inzwischen habe ich auch noch ein wenig mit einem neuen Kommandozeilen
Firmwareloader experimentiert. Läuft schon recht stabil. Gäbe es die
Möglichkeit die Uploadroutine bei Dir einzubauen, oder das Programm per
Parameterübergabe im Hintergrund zu starten?

Gruß Hayo

Hi,

es wird langsam ruhiger hier, sind alle in Ihrem Kämmerlein am dengeln
(so wie ich)? Es gibt jetzt eine neue detailierte Memory Map als
Exceldatei hier:

http://groups.google.com/group/welec-dso/files?hl=de

Das Flash fängt übrigens nicht bei 0x0004 0000 an, sondern bei 0x0000
0001 (Basisadresse 0x0000 0000) und hat damit auch die vollen 8 MByte.
In den ersten vier Sektoren steht allerdings nicht viel drin, nur einige
Zeilen (siehe Anhang) deren Zweck ich bislang nicht zuordnen konnte.

@Markus

Der Vollständigkeit wegen müßte also ein Flashdump von 0x0000 0001 bis
0x0080 0000 gehen.

Gruß Hayo

Markus wrote:

>Ich mach am Oszi gerade nichts mehr, ich muss auch noch Geld
>verdienen...

Verdammt, ich wußte da war noch was...

> Wäre es möglich dass in diesen Sektoren der Bootloader für die serielle
> Schnittstelle drin ist?

Wäre zu klären. Ich dachte allerding, dass das in den GERMS-Monitor
integriert ist, und der sollte im Flash für den FPGA stehen.


Bis das geklärt ist lasse ich den
> Adressbeginn beim WelecUpdater auf 0x00040000. (Von Hand kanst Du ja
> diese Adresse einstellen und Downloaden.

Hab ich schon, siehe Dateianhang Topsectors.flash weiter oben. Klar war
auch eher theoretisch, denn der wichtige Teil fängt ja definitiv erst ab
dem 4. Sektor an.

Gruß Hayo

Egon125 wrote:
> Hallo,
>
> habe mir im Oktober 2008 ein W2012A zugelegt und ich bin sehr zufrieden.
> Für den Preis von 300€ kann man die kleinen Mängel vernachlässigen.
> Allerdings ist das Gerät mit der Softwareversion 1.4 ausgestattet.
>
> Gruß Egon125

Hallo Egon125,

hört sich interessant an. Da es die FW 1.4 noch nicht offiziell bei
Welec gibt wäre ich an einem Download zum Zwecke des Vergleichs sehr
interessiert. Ich selbst entwickle zur Zeit an der Open Source Version
weiter und habe mittlerweile so viele Buggs gefunden, dass man sagen
kann pro Bug den ich beseitige finde ich zwei neue. Wichtigste Neuerung
bei meiner Weiterentwicklung sind neue größere Grids mit sinnvoller
Einteilung und eine Überarbeitung der Menüs. Der Entwickler von Welec
hatte um etwas Platz für Texte zu haben das Grid auf die blöde Höhe von
384 Punkten ausgelegt, was dazu führt dass keine vernünftigen Teilungen
möglich sind. Meine neuen Grids sind jetzt 600 X 400 Punkte groß und
lassen sich dadurch auch in Zehner und Fünferschritten teilen (siehe
Screenshot).
Zur Zeit habe noch kein stabiles Release zur Verfügung, aber sobald es
soweit ist stelle ich es in Google Groups und SFN zur Verfügung.

Ich nehme an Du kennst das Programm von Markus mit dem Du einen
Flashdump ziehen kannst (siehe oben).

Gruß Hayo

Manja wrote:
> Hallo,
> wolltze jetzt mal Firmware aus mein 2000 ohne A ziehen und habe gleich
> Probleme. Seriell ist alles angeschlossen, den Welecupdater habe ich
> auch geladen leider kann ich auf dem Download Button nicht drücken, es
> passiert nichts. Drücke ich nun die beiden linken Softkeys am 2000er
> passiert auch nicht. Mache ich es beim einschalten ändert sich nichts.
> Das W2000 startet ganz normal.
>
> Kann miur jemand helfenß
>
> LG
>
>   Manja

Hi Manja,

also hier nochmal eine Checkliste:

- W2000 mit RS232 Nullmodemkabel korrekt mit dem PC-Verbinden (COM1 -
COM4)
- evtl. im PC-BIOS prüfen ob die COM-Ports aktiviert sind
- W2000 anschalten
- WelecUpdater von Markus starten (ich hab die Version 0.4.8A22)
- COM-Port wählen!!! (Button ganz links)
- Downloadbutton drücken evtl. vorher den Adressbereich einstellen,
default ist 0x00040000 - 0x007FFFFF, das ist die Firmware und der
gesamte Konfigurationsbereich. Wenn Du alles runterladen willst, dann
stellst Du den Bereich auf 0x00000001 - 0x007FFFFF.

Gruß Hayo

@Markus

Hi Markus, was macht das Geschäft? Bist Du auch fleißig am
programmieren? Wenn ja, sollten wir uns über einige Details austauschen
(Bug-List und bereinigte Fehler). Nebenbei hab noch mal eine kleine
Übersicht für die LED-Belegung, die Button-Belegung und die Menüstruktur
(siehe Anhang).

Gruß Hayo

Ach so, hier noch ein Screenshot vom neuen Delayed-Grid

Hayo

Manja wrote:
> Nullmodem war das problem, dacht ich kann das normale nehmen. Also heute
> mit dem Nullmodemkabel. Kann ich das für die experten hier reinstellen,
> würde gerne das w2000 ohne a etwas auf dem neusten stand bringen.
>
> LG
>
>  Manja

Hi Manja,

also versuche erstmal einen vernünftigen Flashdump zu machen, damit Du
auf jeden Fall wieder zurück kannst. Dann mußt Du mal sehen wie Du den
GERMS-Monitor aktivierst, denn sonst gibt es keinen Upload über die
RS232. Bei mir sind es halt die beiden linken Funktionstasten. Ich
drücke immer erst die ganz linke und dann die weiter rechts und lasse
dann beide gleichzeitig los. Funktioniert bei mir immer.

Wie ich dem Firmwarecoding entnehmen kann gibt es bei der den
verschiedenen Hardwareversionen einen Unterschied in der
Bildschirmansteuerung (laut Coding wird unterschieden zwischen vor
HW-Version 4C7 und danach - welche ist Deine?).

Sollte aber kein Problem sein das mit einzubauen in die neue FW.

Gruß Hayo

Hayo W. wrote:
...
> Ich selbst entwickle zur Zeit an der Open Source Version
> weiter

Du auch? Schön. Ich bearbeite gerade die PC-Kommunikation. (USB tut's
bei meinem nicht mehr, aber RS232 ist nicht langsamer)

Gleichzeitig schreibe ich eine QT-Applikation für die Steuerung. (s.
Screenshot)
...
> Der Entwickler von Welec
> hatte um etwas Platz für Texte zu haben das Grid auf die blöde Höhe von
> 384 Punkten ausgelegt, was dazu führt dass keine vernünftigen Teilungen
> möglich sind. Meine neuen Grids sind jetzt 600 X 400 Punkte groß und
> lassen sich dadurch auch in Zehner und Fünferschritten teilen (siehe
> Screenshot).

384? Oh, das ist wirklich ungeschickt. Mir ist aufgefallen, daß nicht
der ganze Bereich der 8-Bit ADC angezeigt werden können.

> Zur Zeit habe noch kein stabiles Release zur Verfügung, aber sobald es
> soweit ist stelle ich es in Google Groups und SFN zur Verfügung.

Das würde mich brennend interessieren. Ich brauche etwa drei bis fünf
Zeilen, in denen meine Funktionen angesprungen werden. Zusätzlich habe
ich mir einen Timer-Interrupt genommen und nutze den RS232-Interrupt
ausgiebig.

Gruß,
Falk

@Falk

Schön das noch mehr Entwickler am Ball sind.

-> RS232: Ich hatte auch schon die Idee die Kommunikation über RS232
auszubauen, da ich diese für flexibler halte. Wenn man die Übertragung
auf die reinen Daten beschränkt, und die eigentliche Rechenarbeit auf
dem PC macht sollte auch eine Echtzeitübertragung (oder fast) möglich
sein. Leider bekomme ich das QTDSO (unter Suse 11.0)bei mir nicht zum
Laufen, hätte mich schon mal interessiert.

Da Du in dem Thema drin bist kann ich mich ja derweil weiter auf die FFT
konzentrieren. Die Grundroutinen habe ich schon implementiert, aber ich
bin dann erstmal dazu übergegangen grundlegende Fehler zu beseitigen,
damit das Ganze auch ein anständiges Fundament bekommt.

Zur Zeit überprüfe ich die Einträge in der Zoomfaktortabelle und in der
Zoomindextabelle, da ich den Verdacht habe dass hier falsche Faktoren zu
Fehlberechnungen von Werten und Triggerpositionen bzw. Cursorpositionen
führen.

Sollte ich hier neue Erkenntnisse haben werde ich das auf jeden Fall
posten, damit das auch in andere Entwicklungen einfließen kann.

Gruß Hayo

Manja wrote:
> Hallo Hayo,
>
> habe HW 3C7.0H, ich frage mal so kann ich den W2000 auch irgendwie
> richtig kaputt machen oder komme ich immer wieder mit dem WelecUpdater
> weiter? Ich frage lieber vorher was ich auf keinen Fall machen soll.
>
> LG
>
>   Manja

Hi,

beim Download kannst Du nichts kaputt machen, der geht - oder er geht
nicht. Anders ist es beim Upload, denn hier wird das Flash vor dem
Schreiben gelöscht. Also solltest Du sicher sein, dass dein Download
geklappt hat und Du am besten eine Sicherungskopie auf einem USB-Stick
hast).

Aber wie schon gesagt, wenn der GERMS-Monitor sich nicht starten läßt,
solltest Du keinen Upload mit dem (USB)Originalupdater machen, da die
Wiederherstellung nur über RS232 funktioniert!!!!

Auch die Opensource FW läßt sich nicht mit dem USB-Updater laden.

Ein erfolgreicher Start des GERMS-Monitor läßt sich folgendermaßen
erkennen:

- Bildschirm wird kurz weiß und dann komplett schwarz
- manchmal leuchten auch versteckte LEDs unter der Frontplatte
- wenn Du ein Terminalprogramm startest (Hyperterminal, Minicom etc.)
und auf die richtige Übertragung einstellst (115200, 8N1 - 8Bit kein
Startbit 1 Stopbit) kannst Du mittels ENTER Memorydumps anfordern. Da
kommen dann immer 4-zeilige Ausgaben mit Hex-Adresse am Anfang.

Wenn das funktioniert, kannst Du recht sorgenfrei rumexperimentieren, da
Du dann alles wieder rückgängig machen kannst.

Gruß Hayo

@Manja

Nochmal zu der Porteinstellung 8N1 - das N bedeutet keine Parität

Gruß Hayo

@Egon 125

Super, werd ich mir mal heute abend anschauen.

@Falk

Ich weiß nicht, ob es Dir schon aufgefallen ist, aber die printf()
Funktion in der Open Source Version ist nicht so ganz in Ordnung
(zumindest bei mir). Sobald man float Werte an die RS232 schickt hängt
sich das DSO komplett auf. Das kann man z.B. sehen wenn man via Terminal
mit der <,> Taste die Variablenübersicht anfordert. Es werden alle
Integer sauber ausgegeben, aber bei der ersten Float-Ausgabe ist dann
Schluß (bei ZFT_float).
Hast Du da eine Lösung? Ich benutze die Funktion ganz gerne als Debugger
für Arme. Bei der offiziellen FW 1.2 funktioniert alles.


@Manja

Der GERMS-Monitor wird nicht nur beim Starten aktiv, sondern auch wenn
Du die Tasten im ganz normalen Betrieb gleichzeitig drückst. Schon
probiert?

@Albert

Bei mir war anscheinend im .ini File schon ein Eintrag, daher hat es
wohl auch ohne das Öffnen funktioniert. Beim ersten Mal muß man
anscheinend erst die Datei öffnen.

Gruß Hayo

Hayo W. wrote:

...

> @Falk
>
> Ich weiß nicht, ob es Dir schon aufgefallen ist, aber die printf()
> Funktion in der Open Source Version ist nicht so ganz in Ordnung
> (zumindest bei mir). Sobald man float Werte an die RS232 schickt hängt
> sich das DSO komplett auf.

Ist mir nicht aufgefallen. Ich habe diese RS-232-Funktionen aber alle
abgeschaltet.

Im Übrigen meine ich sowieso, daß float nicht in einen µC gehören: 8Bit
Input, 9Bit (Display in Y-Richtung) Output sollten in allen Lebenslagen
mit Integer machbar sein. Mit 16Bit in den Zwischenrechnungen sollte die
Genauigkeit immer ausreichen.

Bei der Timebase sieht das anders aus (10s/10nS ist immerhin 10^9). Da
sollten aber long (64Bit) ausreichen.

Die Ursache kann sein, daß die verwendete libc eine andere ist, als in
der Wittig-Firmware.

Falk

Manja wrote:
> @Hayo
>
> Hallo Hayo,
>
> habe ich auch gemacht, auf dem Display sieht alles normal aus. Ich habe
> das Hyperterminal mal gestartet um zu sehen ob es kommt, es kommt aber
> nichts. Muss ich nich was an das W2000 senden damit ich erstmal den
> schritt fertig habe das das w2000 kommunizieren will.
>
> LG
>
>   Manja

Also da gibt es mehrere Möglichkeiten;

- entweder gibt es beim W2000 keine Tastenkombination :-(
- oder es gibt eine Andere -> ausprobieren
- eventuell muß auf dem Board ein Kontakt gebrückt werden oder was
ähnliches.

Irgendeine Möglichkeit das Ding zu starten werden die auf jeden Fall
vorgesehen haben. Zur Not mal bei Welec anfragen, vielleicht geben die
ja wider Erwarten Auskunft. Als letzte Möglichkeit fällt mir noch ein,
dass man sich an den früheren Entwickler wenden könnte (Oliver
Gorzellik) der jetzt eine eigene Internetseite hat:

http://thinklogic.de

Da gibts auch eine Email-Adresse.

Gruß Hayo

Egon125 wrote:
> Hallo Hayo,
>
> habe von der Firmware 1.4 einen Flashdump gezogen, ...

So, hab die 1.4 mal eingespielt und gesichtet. Mir sind auf den ersten
Blick keine Unterschiede aufgefallen. Es gibt immer noch die gleichen
Fehler.

Gruß Hayo

Hallo werte W2000(a) Gemeinde,

hier ein paar aktuelle Infos.

Wie ich bei meinen Tests herausgefunden habe ist die Open Source FW
(1.2) nicht auf dem gleichen Stand wie die offizielle 1.2 FW. D.h. es
handelt sich um eine alte Version (WELEC wollte wohl einen gewissen
Entwicklungsvorsprung gegenüber der Open Source Version haben). Ein
Fehler den ich bei der Open Source Version festgestellt habe ist, dass
bei den Werteeinblendungen keine Nachkommastellen berechnet werden und
auch ein Werteüberlauf nicht abgefangen wird. Bei der offiziellen
Version 1.2 ist der Fehler behoben.

Macht aber nichts, ich habe mal einige vorab Fixes in ein Paket
geschnürt (anbei als Anhang) damit alle die an der Open Source FW
rumschrauben das mit einfließen lassen können. Folgende Fixes sind
enthalten:

- Funktion RenderText() -> kann jetzt auch Nachkommastellen ausgeben und
behandelt einen Überlauf

- Funktion CALCPRETRIGGER() -> Mich hat genervt, dass der Triggervorlauf
immer völlig verkehrt berechnet wurde. Durch eine korrigierte Berechnung
und eine Timebase-Tabelle mit neuen Faktoren ist der pre trigger wert
jetzt korrekt. Weiterhin fehlten für zwei Zeitbasen die Faktoren ganz,
was ich übrigens auch an anderen Stellen festgestellt habe. Diese
Fehlfunktion ist übrigens auch in der neuen FW 1.4 noch zu finden.

- Funktion floatprintf() -> dies ist eine neue Funktion, die ich
geschrieben habe weil in der Open Source Version keine Float-Ausgabe mit
printf() auf die RS232 möglich ist (verursacht Systemcrash). Damit kann
man dann wieder quasi Debuggen und sich Werte ausgeben lassen.

Die Funktionen können einfach per copy and paste (ersetzenderweise) in
das Coding  kopiert werden. Es sind keine Variablendeklarationen nötig.
Nur für floatprintf() muß ein Eintrag in die Headerdatei gemacht werden.

Gruß Hayo


@Firma WELEC

Sehr geehrte Herren,

gerne können sie die Fixes auch in die offizielle Firmware mit
einfließen lassen.

mfG
Hayo W.

Hi,

bin in letzter Zeit nicht zum Forenschreiben gekommen, da ich bis zum
Ellenbogen im Firmwareumbau stecke. Eigentlich wollte ich ja die FFT
vernünftig schreiben, aber ich bin auf so viele Ungereimtheiten
gestoßen, dass ich erstmal angefangen habe aufzuräumen. Zum Grid - ich
habe eine Solid line und eine Dotted line Version gemacht, die sich zur
Zeit aber nur durch Tastaturbedienung über RS232 umschalten läßt (soll
in Zukunft ins Menü).

Übrigens habe ich in meinem letzten Bugfix zur Rendertext-Funktion noch
einen kleinen Fehler entdeckt, den ich im angehängten File beseitigt
habe.

Zur Zeit bin ich an den Themen ADC-Justierung und Zeichenroutinen dran.
Ich habe nämlich festgestellt, dass das W2000A gar nicht so ein starkes
Rauschen produziert wie bisher in allen Foren kritisiert wurde. Das
Ganze kommt zustande durch eine ungeschickte Skalierung kombiniert mit
einer etwas (aus Performancegründen) suboptimalen Zeichenroutine und
einer fehlenden (bzw. falschen) Synchronisierung der vier Einzel-ADCs
eines jeden Kanals. Eingestellt ist ein fester Abgleichwert, der aber
nur in seltenen Fällen zum Gerät passt. Vielmehr muß man das dynamisch
ermitteln. Daher habe ich jetzt eine Abgleichroutine geschrieben, und
auch die Zeichenroutine komplett umgekrempelt und optimiert. Vom
Rauschen bleibt da kaum noch was übrig.

Eine Testversion werde ich wohl im Januar ins Netz stellen, dann könnt
Ihr Euch das mal ansehen. Zwischendurch bin ich zum Skifahren weg, da
komme ich nicht zum programmieren.

Ansonsten melde ich mich wenn es was Neues gibt,

Gruß Hayo

Hi, auch von mir ein frohes neues Jahr.

- die Ruhe täuscht! Bin gerade aus dem Urlaub zurück und gehe jetzt
wieder mit Elan an die Arbeit um die Firmware auf Vordermann zu bringen.

Man könnte es also eher als stille Geschäftigkeit bezeichnen. Ich denke
auch die Anderen sind bestimmt wieder am dengeln...

Gruß Hayo

Was brauche ich wenn ich an der W2000A Firmware entwickeln will?

Hallo allerseits,

wegen aktueller Nachfrage hier ein kleiner Leitfaden für alle die an der
W2000A Firmware basteln wollen. Grundlage ist die Source die Andreas
Fellnhofer auf SourceForge.net zur Verfügung gestellt hat. Eine kleine
Bitte von mir - kommentiert Änderungen die Ihr macht damit man eventuell
die Entwicklungen zusammenfließen lassen kann.

Am Anfang des Codings wäre ein Änderungsjournal (Historie) ganz
hilfreich. Als kleine Anregung habe ich mal meine aktuelle Historie
beigefügt, dann könnt Ihr auch gleich mal abschätzen an welchen Themen
ich dran bin.

Viel Spaß Hayo

branadic wrote:
...
> nett von dir, den kleinen Leitfaden einzustellen.
> Eigentlich fehlt in deinem Leitfaden noch eine wichtige Kleinigkeit.
> Erst einmal muss man sich noch die Entwicklungsumgebung (NIOSxxx)
> herunterladen oder nicht?

-> nein, der Leitfaden ist schon so komplett. Man braucht wie
beschrieben nur die NIOS-CDK Komponenten und das unix2dos unter Linux.
Die Programmierung mache ich mit dem Editor KWrite, der auch C++
Highlighting beherrscht. Die Kompilierung erledigt dann der Befehl make
all - das wars. Das Tomcat.flash File kopiere ich mir dann auf einen
USB-Stick, dann auf den Windows PC und dann via WelecUpdater ins W2000A.


> Wozu ist das Terminalprogramm? Daraus bin ich nicht schlau geworden...

-> Das Terminalproagramm braucht man um mit dem W2000a zu kommunizieren.
Zum Einen kann man via Tastatur Befehle absetzen (unter Anderem zur
Fernsteuerung), zum Anderen kann man in der Firmware Meldungen ausgeben
(Variablen etc.). Damit fungiert das Ganze dann quasi als Debugger.


> gibt es eine Möglichkeit ganz ohne Linux auszukommen? Was
> mache ich als reiner Windows-User. Welche Programme/Software brauche >ich, um
bei der Entwicklung mitwirken zu können und meine Sources zu
> kompilieren?

-> Also theoretisch könnte es auch unter Windows gehen, es gibt da wohl
einige Software um den GNU Compiler unter Windows zu benutzen, die Idee
kam mir auch schon. Allerdings hatte ich dann keine Lust daran
rumzufrickeln. Es ist aber (wirklich) viel einfacher sich Linux zu
installieren und dann das Ganze unter Linux zu machen. Ich selbst bin
eigentlich auch kein Linux-Freak, hab mir aber dann das Suse-Linux
DVD-Image runtergeladen (alles freie Software!!!) schnell die DVD
gebrannt und mir das Ganze auf eine freie Partition installiert. Geht
wirklich gut und ist größtenteils selbsterklärend. Das Look and Feel des
KDE-Desktops kam mir als Windows-User auch entgegen.

Probiere es doch einfach mal aus - nur keine Scheu!!!

Gruß Hayo

Hallo allerseits,

noch ein kleiner Nachtrag zum Leitfadfen.

Ich habe zwei Excelsheets mit Memory Map und Programming Map
zusammengestellt die einem beim Programmieren das Leben etwas leichter
machen. Die Dateien gibt es hier als Anhang.

Die Memory Map gibt es auch auf Google Groups.

Gruß Hayo

Hallo werte W2000 Gemeinde.

Um die Hemmschwelle für die Enwicklung unter Linux etwas herabzusetzen
habe ich eine weitere Anleitung geschrieben. Sie ist auf deutsch und
englisch geschrieben und auch auf Google Groups verfügbar.

Wenn jemand Probleme hat kann er auch gerne Fragen dazu posten oder mir
mailen.

Gruß Hayo

Hallo W2000 Entwickler und Besitzer,

hier eine neue Version der Programming Maps, erweitert um eine
Timbase-Tabelle.

Die Fertigstellung meiner ersten Betaversion rückt näher, zur Zeit
kämpfe ich noch mit den Zeichenroutinen, die ich mittlerweile um 80%
eingedampft und optimiert habe.

Wenn es so weit ist gibt es das Flash-File und die gesamten Sourcen auf
Google Groups, ich poste das dann hier.

Gruß und happy developing

Hayo

Hallo Guido,

ich hab mir das mal angesehen und festgestellt, dass ich bei mir
zusätzlich das Paket cdk-nios-libstdc++-3.1 installiert habe, vermutlich
ist es das. Da es bei Andreas nicht in der Liste erschien bin ich davon
ausgegangen dass es nicht wirklich notwendig ist -> ist es aber
anscheinend doch. Bei Google Groups passte es leider nicht mehr mit ins
Paket (es gehen nur 10MB Upload im Stück), daher habe ich es
rausgeschmissen. Ich werde das mal zusätzlich bei Google Groups
einstellen, sind etwa 3,8 MB.


Gruß Hayo

Guido wrote:
> Hallo Hayo,
>
> die libstdc++ habe ich testweise auch schon installiert. hilft
> aber nichts, da auch hier stdio.h und stdlib.h (und ev. noch
> andere) fehlen. Kannst du mal schauen, ob da bei dir Links sitzen?
> In den Paketen finde ich sie nicht.
>
> Gruß Guido

Hi, ich hab mal gegoogelt und es sieht so aus als wäre es kein NIOS
Problem, sondern Deiner Linux-Installation fehlt wohl das entsprechende
devel-Paket. Also in die Paketverwaltung (YAST2) gehen und mit dem
Suchbegriff stdio.h und stdlib.h suchen. Dann die devel-Pakete markieren
und installieren. Dann sollte es gehen (laut gefundenen Forenbeiträgen).

Welche Linux Distribution benutzt Du? Die aktuelle openSuse ist nämlich
eine 11.1 dagegen ist meine eine 11.0 -> evtl. werden  bei der Neuen die
Developmentpakete nicht mitinstalliert.

Gruß Hayo

Na, super!

Das hört man gerne. War leider bis eben ziemlich busy und bin erst jetzt
zum lesen gekommen.

Meine Beschreibung ist natürlich nur für die Suse-Distribution 1:1
anwendbar. Die anderen Distributionen haben alle so Ihre Eigenheiten wie
ich von diversen Anderen mitbekommen habe.

Für alle die sich zur Zeit ins Coding einarbeiten und den rechten
Überblick noch nicht so auf Anhieb kriegen:

 - ich stelle gerade für meine Programming Maps eine Übersicht über die
Programmstruktur zusammen, die genau zeigt wann und wo welche Funktion
aufgerufen wird. Wenn sie fertig ist stelle ich sie wie immer zum
Download bereit.

Gruß Hayo

Hallo werte Gemeinde,

da meine Beta noch etwas braucht hier mal vorab ein kleiner Vorgeschmack
was so möglich ist ohne FPGA-Redesign, sondern nur mit reiner
Softwareoptimierung. Ihr seit mit Sicherheit auch so genervt von dem
heftigen Rauschpegel den das Gerät produziert. War ja auch schon oft
Thema in etlichen Beiträgen. Daher für den Vergleich hier mal das
typische Bild das Ihr ja auch kennt, aufgenommen mit der original FW1.3
in der 2V Einstellung, die ja ziemlich übel rauscht...

...und hier zum direkten Vergleich die gleichen Einstellungen und das
gleiche Signal mit meiner PreBeta 1.2.BF.0.36 - ist doch schon ganz
anständig finde ich. Angedacht waren ja mal FIR-Filter, die jedoch
Performance fressen. Da finde ich die Optimierung der ADC-Justierung und
der Zeichenroutinen doch besser.

Das ist noch nicht das Ende der Fahnenstange! Die Justierung ist noch
nicht optimal, sondern eher provisorisch implementiert um die Wirkung zu
testen. Im nächsten Beitrag...

...mal das Ganze in der etwas günstigeren 5V Auflösung, die einen etwas
besseren Scalierungsfaktor hat (5V -> 2, 2V -> ca. 3). Ich möchte
übrigens darauf hinweisen, das der schlechte Rauschpegel trotz
günstigerem Skalierungsfaktor bei der Original FW1.3 (wegen des
kleineren Grids) soviel schlechter ist. Das zeigt eigentlich ziemlich
deutlich, dass die Zeichenroutine und der ADC-Abgleich etwas ungeschickt
implementiert wurden und man sich damit ein hausgemachtes Problem ins
Boot geholt hat.

-> Sagt was...

Gruß Hayo

...ach ja, zusätzlich hatte ich immer mit einem lausigen
Nullpunktabgleich zu kämpfen, das ist auch erheblich besser geworden, da
die Änderung der Zeichenroutinen auch ein geänderte Ansteuerung der
Eingangsverstärker beinhaltet.

Gruß Hayo

Hallo Hayo,

das sieht wirklich sehr sehr gut aus. Zur Beurteilung hänge ich mal
eine Vergleichsaufnahme mit dem TDS210 an. Dein Zwischenstand sieht
schon besser aus.

Für weitere Vergleiche solltest du mal Messstandards einführen, im
Sinne von mit/ohne Tastkopf, 1/10-Tastkopf oder mit 50-Ohm-Abschluss.
Ich habe den Eindruck, dass die Wittigs (ich habe ein W2012A) ihre
Bandbreite nur mit 1/10-Tastkopf bringen, nicht mit 50-Ohm-Abschluss.

Weiter so und viele Grüße,

Guido

Guido B. wrote:
> Hallo Hayo,
>
> das sieht wirklich sehr sehr gut aus. Zur Beurteilung hänge ich mal
> eine Vergleichsaufnahme mit dem TDS210 an. Dein Zwischenstand sieht
> schon besser aus.

Hi, das ist eine gute Idee mit dem Vergleichsbild, ich selbst habe zum
Vergleich nur ein analoges Oszi. Dann hat man gleich mal eine Messlatte.


> Für weitere Vergleiche solltest du mal Messstandards einführen, im
> Sinne von mit/ohne Tastkopf, 1/10-Tastkopf oder mit 50-Ohm-Abschluss.
> Ich habe den Eindruck, dass die Wittigs (ich habe ein W2012A) ihre
> Bandbreite nur mit 1/10-Tastkopf bringen, nicht mit 50-Ohm-Abschluss.

Du hast natürlich recht, aber die Bilder sollten auch nur ne kurze Demo
sein. Meine Messungen sind alle mit 50 Ohm Abschluß gemacht.

Gruß Hayo

Bruno W. wrote:
> Dennoch, kannst du mir bitte erklären wie/ wo der Code in die
> Ansteuerung der (analogen) Eingangsverstärkerstufen eingreift?
> (Das kommt mir doch sehr seltsam vor, ohne das ich momentan tiefer in
> der Programmierung oder dem Schaltungsaufbau stecke...)

Hallo Bruno.

ich habe mal das Coding der FW 1.2 zur Ansteuerung der
Eingangsverstärker angehängt. Da kann man sehen, dass der Nullpunkt des
Eingangsverstärkers verschoben wird. Grundsätzlich kein schlechter
Gedanke, und auch nicht neu. Vorteil ist, dass man immer den gesamten
ADC-Bereich für das Signal zur Verfügung hat, und die
Nullpunktberechnung zeitsparend nur einmal pro Durchlauf stattfindet.

Nachteil ist, dass der Nullpunktabgleich nicht so ganz einfach ist und
auch definitiv nicht richtig geklappt hat. Ich habe den Zero-Shift bei
meinem Coding rausgenommen und die Berechnung wieder klassischerweise in
die Zeichenroutine verlegt, was natürlich die beiden oben erwähnten
Nachteile mit sich bringt, aber einen besseren Nullpunktabgleich
gewährleistet. Dadurch dass ich die Zeichenroutine etwas optimiert habe
macht sich der zusätzliche Rechenaufwand auch nicht so bemerkbar.

Grundsätzlich habe ich aber schon überlegt, wenn die anderen Macken
erstmal weitestgehend behoben sind, ob ich noch einmal versuche den
Zero- Shift etwas besser zu implementieren - eventuell mit einer neuen
FPGA-Version von unseren FPGA-Cracks.

Gruß Hayo

Hi allerseits,

kleiner Zwischenstand: kämpfe immer noch mit den Math-Funktionen
(richtige Scalierung, bessere Offsetansteuerung, schnellere Ausgabe
etc.).

Anbei eine neue Version der Programming Maps mit der Programmstruktur,
allerdings noch unfertig. Neue Funktionen von mir sind rot.

An der Vervollständigung arbeite ich noch.

Gruß man alle

Hayo

Hallo allerseits,

wegen aktueller Nachfrage von Sebastian und da die Fertigstellung der
Beta doch noch etwas dauert, habe ich mich entschlossen meine Prebeta
ins Forum zu stellen. Es sind noch etliche Fehler drin, aber vielleicht
fühlt sich der Eine oder Andere ja berufen da Hand anzulegen. Ich bin
für Verbesserungsvorschläge, Fehlerbeseitigung oder Weiterentwicklungen
jederzeit empfänglich.

Beachtet bitte das Read Me in dem ansonsten alles Weitere steht. Das
Flash-File ist auch mit dabei für die, die nicht selbst kompilieren
wollen oder nur Windows haben.

Gruß Hayo

Keine Kommentare???

Ist das ein gutes oder ein schlechtes Zeichen? Hat schon jemand
getestet, oder sogar schon was verbessert?

-> Das Abschneiden des unteren Randes bei der Signalausgabe z.B. wäre
eine Sache zu der ich bislang noch nicht gekommen bin. In diesem Bereich
ist sonst bei dem kleineren Grid das Menü bzw. der Hintergrund.

Vielleicht findet das ja jemand raus, dann könnte man das auch schon
einfließen lassen.

Die Math-Funktionen schreiten bei mir inzwischen voran. Trotz nicht so
effizienter Berechnung ist die Ausgabe mit ein paar Tricks schneller als
vorher.

Gruß Hayo

Hallo,

freut mich sehr dass da was weiter gemacht wird. Ich habe ein 2012 und
da ich mit C++ und FPGA Erfahrungen nicht helfen kann werde ich auf
jeden Fall veröffentlichte Testversionen testen und berichten was ich
denke und was mir auffällt. Dass es auch fertig kompilierte Files gibt
kommt mir sehr entgegen. Spätestens morgen oder übermorgen werde ich
mich einlesen wie man die original Software sichert und man mit dem
Updater neue Software einspielt. Ich hoffe dass man da nicht in die
Verlegenheit kommen kann dass man bei nem Fehler beim Update nicht mehr
auf den Speicher zugreifen kann und somit das Gerät mehr oder weniger
defekt ist...

Also bitte nicht aufgeben wenn zu wenig Feedback im Moment kommt, von
mir wirds auf jeden Fall kommen!

Ich hab übrigens auch schon drüber nachgedacht die Drehencoder durch
andere zu ersetzen, die originalen sind ja furchtbar mit den schweren
Rastungen. Ich hoffe auch dass sich an der Abfrage der Encoder noch was
machen lässt, bzw. an der Reaktionszeit auf Eingaben an den
Drehencodern, das ist einfach nur furchtbar im Originalzustand.

Ich weis nicht ob das bei allen so ist, aber bei mir sind in V1.3 die
Mathefunktionen gänzlich unbenutzbar. Sie errechnen zwar irgendwas, aber
das hat mit dem echten Ergebnis nur in Ausnahmefällen was zu tun.
Meistens ist das was rauskommt völliger Unsinn.

Bin echt gespannt auf die Testsoftware, danke dafür!

@Branadic,

Sorry, mir ist doch tatsächlich die 8 um zwei Stellen verrutscht!

Der Adressbereich muß natürlich lauten 0x00000001 - 0x00800000.

Kann man sonst auch überprüfen in der Memory Map die ich weiter oben
eingestellt habe.

@Stephan

Wenn Du an den Mathefunktionen interessiert bist, solltest Du bis heute
Abend warten, ich stelle dann eine neue Version zur Verfügung in der
schon etwas mehr geht (vor allem schön schnell!!). Ihr könnt ja mal
testen ob das was raus kommt Sinn macht. Mir fehlt zum Teil etwas die
Zeit zum Testen, daher bin ich an Feedback natürlich sehr interessiert.

Gruß Hayo

Ich bin an allen Funktionen die besser oder überhaupt mal funktionieren
:-)

Werde auch alles testen was es neues gibt.

Die Sache mit dem Updater klappt aber nicht. Nachdem ich die 2 linken
Softbuttons drücke wie es in der Anleitung steht kommt nur noch ein
schwarzer Bildschirm, am Updaterprogramm zeigt sich keine Regung. Kein
Fenster an dem man bestätigen muss wie es in der Anleitung steht, kein
Zähler der läuft, garnichts. Wenn ich auf den Downloadbutton drücke
bevor ich die Softbuttons drücke passiert auch garnichts.

Ich benutze V0.3.8A22 vom Updater, WinXP prof, serielles nicht
gekreuztes Kabel vom STK500 Board, W2012A Oszi mit 1.3er Software.

Problem hat sich erledigt, man muss zuvor das File was man flashen will
einlesen bevor man was anderes auslesen kann. Seltsame Logik. Da muss
man erstmal drauf kommen...