Announcement: there is an English version of this forum on 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.
Hab selber kein Wittig. Solche Geräte können aber typischerweise auch über einen internen JTAG-Anschluss programmiert werden. Dazu braucht man allerdings die richtigen Zutaten: JTAG-Hardware, -Software und vor allem Informationen. Bei älteren Geräten ist der Flash-Speicher oft gesockelt. Man kann ihn damit in einem externen Programmiergerät neu beschreiben. Die W2000-Oszis sind zwar neu, deswegen ist das Flash wahrscheinlich gelötet. Aber Nachschauen kostet nichts. Sonst halt bei Welec fragen, vielleicht haben die noch andere Möglichkeiten vorgesehen.
Angehängte Dateien:
-
DSC00615-800x600.JPG
150 KB
Hmmm, auf der Welec seite funtioniert der email support anscheinend nicht! Auf der Platine befinden sich zwei Buchsen. Vieleicht kann hier programiert werden.
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
Hallo Falk, welchen Befehl hast Du für die RS-232-Üertragung eingegeben ? Gruss Olaf
Ich nehme an, dass ein Kommunikationsprogramm notwendig ist. Werde mal danach suchen. Gruss Olaf
@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
Mir sind zwei Möglichkeiten bekannt, allerdings beide unter Linux. Eins ist das kleine Perl-Script, das Falk geschrieben hat und auf der Google-Groups Seite veröffentlicht hat. Bei mir funktionierte es allerdings nicht. Es gab immer Fehler und die Memory-Pages waren nicht ordentlich geflasht. Daher habe ich für mich eine zweite Möglichkeit zusammengestellt. Flashen klappt bei mir nämlich ganz gut unter Minicom. Ich habe das flash-File in ein passendes Minicom-Script umgewandelt und das dann mit minicom geflasht. Dauerte insgesamt glatte 1,5 Stunden, aber danach lief das Oszi wieder :-) Übrigens wurde mein Oszi durch den ganz offiziellen Wittig-Firmware-Updater zerstört. Der brauchte auch fast ne Stunde, aber danach tat sich nichts mehr im Oszi. Hat mich vier Tage und etliche Versuche gekostet, bis ich es dann mit dem Minicom-Script wieder gerettet bekommen habe. Vielleicht probierst Du es erstmal mit Falks Perl-Script?
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.
Hallo, Danke für die Beiträge. Hab zuerst Falks Perl-Script mit tinyperl unter vista in eine auszuführende datei umgewandelt, der Anfang also die ersten Zeilen(erase enough flash sectors) klappte noch, dann etwas später brach die Datenübertragung einfach ab. @falk: die ganzen Zeilen von W2000.flash manuell einzugeben wird sehr mühselig. Gruss Olaf
Hi Falk Ja, bei mir lief Dein Script leider nicht korrekt. Irgendwo gab es (vielleicht) Probleme bei der Kommunikation (???). Auf jeden Fall war maximal jede zweite Zeile geflasht (ob korrekt habe ich gar nicht mehr geschaut). Häufig hing das Script bei mir auch nach einer kurzen Zeit. Interessant war zudem auch, dass es immer eine Ausgabe auf dem Bildschirm erzeugte, die so aussieht, als ob man einfach nur ein Return sendet (sprich: Monitor-Dump). Anyway, über minicom funktionierte die Kommunikation mit dem Oszi problemlos. Auch das manuelle Erasen und Flashen ging perfekt. Nur wie Olaf schon schreibt, ist das bei etwas über 30000 Zeilen keine Alternative. Olaf: Wie oben beschrieben, habe ich noch ein Flash-Sript erzeugt, das mit minicom (unter Linux) läuft. Damit funktionierte das Flashen bei mir. Ob Dir das hilft, weiss ich nicht, da Du ja Windows-User bist. Wenn Du willst, kann ich die Datei posten. Grüsse Michael
> 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.
Hi Michael, Danke am Flash-Sript bin ich interessiert. Linux hab ich auf einem anderen Rechner. Gruss Olaf
Hier das Minicom-Flash-Script, das bei mir funktioniert hat: http://homepage.hispeed.ch/mb-home/W2000-1.3.flash.minicom Zur Anwendung: Erstmal Minicom starten und dafür sorgen, dass es richtig konfiguriert ist: Also Port, Geschwindigkeit, Automatischer Zeilenvorschub AN. Dann mal testen: Return drücken sollte jeweils vier Zeilen Memory-Dump geben. Mit "m40000" kann man die Vektortabelle sehen, ebenfalls als Memory-Dump. Mit "e40000" wird sie gelöscht (danach nur noch FFs drin). Wenn das alles funktioniert, dann über das Menu das Script starten, Kaffee kochen, ggf. mehrere Zigaretten rauchen. Es dauert... Bei mir etwa 1,5 Stunden! Wenn das Script dann bis zum Ende durchgelaufen ist (der letzte Befehl ist "r0"), dann das Oszi aus- und wieder einschalten und wenn alles gut gegangen ist, sollte es wieder laufen... Viel Glück Michael
@Vielen Dank Michael, hab noch eine andere Möglichkeit gefunden: mit Telix, der Ms-Dos-Vorgängerversion von Minicom. Die Übertragung ist allerdings noch langsamer, dauert ca. 1s pro Zeile also etwa 8,5 Stunden insgesamt.Woran das bloss liegt, an meinem USB-RS232-Wandler ? Gruss Olaf
Also bei 8,5 Stunden würde ich aber sicherheitshalber testen, ob auch alles korrekt läuft. Also das Script nach 15 min oder so mal stoppen und dann per Memory-Dump reinschauen, ob 1.) die Blöcke 40000-dffff alle gelöscht sind (sind die ersten Befehle des Scripts) und dann bei 40000 die ersten etwa 64 Bytes oder so korrekt geschrieben wurden sowie dann der Anfang bei 40100. Gegebenenfalls vorher wieder ein "r0" eingeben. Wenn dann alles korrekt, dann würde ich das Script über Nacht laufen lassen... Btw. Keine Ahnung, wieso es so lange bei Dir braucht. Kann mir nicht vorstellen, dass das am USB-Seriell-Wandler liegt. Ich habe auch einen benutzt. Grüsse Michael
So Thema erledigt, das Oszi ist auch noch ausgefallen (kein Bild mehr, d.h. keine Spannungsversorgung mehr, Sicherung intakt) Werde das Ding wieder zurückschicken , zum Glück ist es noch innerhalb der 30tägigen Rückgabefrist. Gruss Olaf
Hallo Olaf, man kann auf die alten W2000 die aktuelle Firmware der A Modelle drauf packen? Habe es mir bisher nicht getraut da ich Angst habe das es nicht mehr startet. LG Manja
Hallo Manja, beim Firmwareupdate keine Knöpfe bewegen oder Tasten betätigen und der 230V-Stecker muss hinten auch fest stecken, bei einer Unterbrechung der Stromversorgung oder Bewegung der Knöpfe oder Tasten stürzt das Update ab und das Oszi ist vorerst unbrauchbar. Meine Hardwareversion ist 8C7.0F W2012A. Ist es noch in der Garantiezeit ? Eigentlich sollte Welec Auskünfte geben. Ich habe den Eindruck, dass Welec höchstens am Anfang nach einem ebay-Verkauf vielleicht noch eine Auskunft gibt, auch ein Umtausch innerhalb der Umtauschfrist ist problemlos möglich (Angst vor schlechter Bewertung) Später sieht es schlechter aus, warum bleibt ein Rätsel. gruss olaf
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, bei mir hat der Download mit germs_up auch fehl geschlagen. Können Sie bitte das Programm mal posten und kurz dazu schreiben wie ich das benutze? Vielen Dank. Gruß Markus
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
@Hayo Vielen Dank für das Script. Das hat bei meinem PC (2,5GHz Core Duo T9300, also super schnell) auch nicht funktioniert. Wenn die Daten mit voller Bandbreite (115200 Baud) geschickt werden, dann kann das der Oszi nicht und meldet ein [OE] (Overrunn Error) zurück. Also mussten die Daten gebremst werden. Ich habe jetzt eine Programm geschrieben, das sowohl unter Windows und Linux läuft und das Update durchführt. Danach hat das Oszi wieder funktioniert. Die Anzeige ist bei meinem Oszi nun auch fehlerhaft, es Fehlen einfach Teile und es sieht beschissen aus. Auch wenn ich die Orinal-Datei V1.3 mit dem "W2000-Update.exe" von Welec einspiele, keine Besserung. Weiß jemand hier rat?
PS: Das Programm braucht für den Update ca. 30-45 Minuten.
Angehängte Dateien:
-
Offset_Signal.jpg
170 KB
@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
Angehängte Dateien:
-
WelecUpdater_Linux.png
16 KB
Der Dump wäre Super! (und auch ein Demo wie mans einspielt)
Ich bin gerade dabei die Linux Version fertig zu stellen, es hatte noch
ein paar kleine Bugs drin. (Progress-Baar zeigte nix, Restzeitanzeige
falsch)
Anbei ein Screenshot...
Wie es bedient wird:
- Taste für Schnittstellenauswahl
- Taste für Datei Öffnen
~ Dabei wird am Ende der Datei r0 automatisch angefügt
~ Anzeige der Zeilenanzahl (kann differieren zur Originaldatei da
Leerzeilen gelöscht werden.
~ Im Editor wird die Datei angezeigt und kann noch manipuliert werden
- Taste Download
~ Sicherheitsabfrage mit Warnhinweis
~ Verbindungstest mit [CR] (Timeout 15 Sekunden)
~ Fortschrittanzeige mit ProgressBar
~ Restzeitanzeige in der Statusleiste
- Taste Abbruch Download
~ Dann ist das Flash garantiert unbrauchbar
- Status Leiste
~ COM Port
~ Baudrate
~ Bearbeitungsschritt
~ Momentan verarbeitete Zeile
~ Hinweistext
Vermisst jemand eine Funktion?
Ich würde das ganze wenn es fertig ist nach SF SVN einspielen, natürlich
mit den fertig kompillierten EXEs da man wohl von niemanden erwarten
kann Lazarus zu installieren.
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
@Hayo Das Dump braucht noch kurz (mit der Windows-Version). Ich bin noch dabei die ein oder andere Unschönheit zu beseitigen. (Zwischendurch muss ich auf unsere keine Tochter aufpassen) Ein paar Details sind zwischen Windows und Linux (Debian hab ich) schon anders. Was für ein Betriebssystem hast Du?
Den Dump hab ich eingespielt. Jetzt heißt mein Oszi W2016A, Version 1.10.03. Das Einspielen hat in etwa 1h15 gedauert.
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
@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.
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
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. Auch wenn Verbesserungsvorschläge gewünscht sind. Beschreibung siehe oben. Download wird erst nach einem Erfolgreichen Verbindungstest gestartet. Nutzung auf eigene Gefahr, keine Garantie!!!
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?
Angehängte Dateien:
-
libglib.png
37 KB
Anbei ein Screenshot von den installierten libglib meines Linuxes. Eigentlich sollte ich daraus ein .rpm Packet machen, dann würden die Abhängigkeiten stimmen, leider weiß ich weder wie das geht noch welche Abhängigleiten das Linux Programm hat. @Falk, kannst Du aufschreiben welche Pakete Du installieren musst, damits tut?
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
Ich würde im SF einen neuen Ordner anlegen: /firmware/trunk/welecupdater/ und da dann alles rein schieben. Ist das OK oder soll ichs wo anders hin tun?
Ich hab einen Thread im SF gestartet: https://sourceforge.net/forum/forum.php?thread_id=2388717&forum_id=848386
Angehängte Dateien:
-
WelecUpdater_ldd.png
7,9 KB
Ich kenne nun die Abhängigkeiten für die Linux-Version, da gibts den Befehl ldd. Anbei ein Screenshot.
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
@Hayo Wenn die Linux-Version nicht startet, ich habe noch eine andere Möglichkeit gefunden wie ich diese Version kompillieren kann, bitte erst mal keine sachen zusätzlich installieren, ich werde das andere Programm posten.
@Folk Das letzte Programm aus dem vorigen Post war für GTK erstellt. Das jetzige ist für GTK2 erstellt, damit sollten Sie keine Startprobleme haben. Bitte um Rückmeldung.
Sorry, meinte Falk. PS: Mit meiner Windows-Version hatte ich auch Probleme, ging nur ab und zu. Linux Version hat funktioniert, allerding hab ich Linux nur in der Vitual-Box (sidux/debian). Ich untersuche das noch. PS: Für alle die noch nie ein FW-Update mit meinem Programm gemacht haben: Nutzt es erstmal noch nicht, zumindest so lange nicht bis es ein Dump des Flashes auslesen kann. Mit diesem Dump kann nämlich das Oszi wieder restauriert werden falls etwas schief geht!
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
@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
Der Zeilenzähler wird getriggert von der Antwort vom Oszi. Die Anzeige unter Linux mit 20h ist normal, zumindest am Anfang. Beim Dump-File werden sehr viele Erase-Befehle (ca. 120) ausgeführt und da ist das Oszi ziemlich beschäftigt, daher wird auch 20h ausgerechnet. Später dann, wenn die Daten-Zeilen kommen geht das viel schneller. Schlussendlich dauert dann der Download ca. 2h-2,5h. (Hab ich gestern Nacht ausprobiert, Ich dachte über Nacht juckt mich das nicht...) Gerade bin ich daran: - Wenn Oszi eine Fehlerrückmeldung bringt, dass ich dann die letzte Zeile erneut schicke. Dann sollte es auch unter Win besser sein. (Ist leider von Altera nicht dokumentiert) - Uploader. Hast Du schon die "gtk2" Version getestet?
@Falk / Bruno: Ich schreibe das alles nicht im SF Forum, mein Englisch ist eher ein Denglisch was zu missverständnissen führt. Zudem testet sowiso grand niemand aus dem englischsprachigen Sprach-Raum.
@ Markus Ja, kein Problem. Wir sollten dann nur die Ergebnisse zusammenfassen und auf SF stellen. (Zumindest gegenüber den Russen, speziell Slog2 ist das nur fair- wir haben schon sehr viel von seiner Vorarbeit profitiert) Ich bin eh am überlegen, ob wir die FW-Welec-Update Entwicklung nicht als SF Unterprojekt etablieren. Nicht das es zu unübersichtlich auf SF wird. Das kann ich aber beizeiten nochmal einrichten. Gruß, Bruno P.S.: Kompliment an Alle- Das Projekt macht gute Fortschritte!
@Bruno: Ich hab es schon in das SF eingespielt, siehe: "/firmware/trunk/WelecUpdater/" Zumindest die sourcen... Aber ich bin gerade dabei weiter zu proggen. (Doku fehlt natürlich noch, die Bedienung ist aber selbsterklärend...)
@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
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.
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
@Hayo Anbei die neue EXE für XP. V0.2.8A18. Verbesserung: - Download sollte nun eine fehlerhaft übertragene Zeile erkennen und diese erneut schicken. - Bei erkannten Übertragungsfehlern wird automatisch der Download gebremst Neu: - Upload-Funktion - Speichern nach Upload Bin gespannt ob es nun bei Dir geht. Download hab ich noch nicht testen können, ich möchte erstmal ein Upload machen. Das Flashdump von Falk tut aber nicht genügend Erase Befehle ausführen, die S Befehle werden in mehr Speicher geschrieben. Warum ist das so? Jetzt mach ich erstmal ein Upload meines jetzigen Standes, nämlich mein Oszi tut gerade wieder... Meldet sich aber mit W2022A anstatt mit W2024A. Kann ich irgendwo her ein Dump eines W2024A bekommen?
@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
Das ist schon fertig. Ich nehme den M Befehl und setze die Abfrage-Größe immer auf 0x100... Immer wenn ich eine Zeile empfange, dann wird die sofort in das Motorola-S Format konvertiert, also ein nachträgliches Konvertieren ist nicht nötig. Auch werden "Leerzeilen" mit lauter FFFF erkannt und verworfen. Damit bleibt die Datei etwas kleiner. Als Motorola-S Code verwende ich S2, denn 6 Adressbytes reichen auch. Im Dump von Hr. Falk war S3 drin, daher ist die Datei etwas größer.
Angehängte Dateien:
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
@Hayo Vielen Dank für den Test! >Ich denke danach hat er wohl das W2000A verloren und sendet nur noch ins >Nirwana. Das ist nicht so, denn es stehen tatsächlich Daten im Flash. Wenn er die Verbindung "verliert" dann sendet er auch nichts mehr. Das Prog wartet immer auf eine Antwort vom Oszi, das "+" Zeichen. Die Oberfläche hat das Ziel Einfach bedienbar zu sein. Ich habe nochmals viel verbessert und auch Übertragungssicherheit optimiert. Das Oszi schickt ein "?" wenn es einen Befehl nicht versteht, dann gibts ein Resend, der auch funktioniert (habs kontrolliert mit Terminal-Prog) In der Konfigurationsdatei gibt es zusätzlich den Debug-Schalter, auf 1 gesetzt zeigt das Programm die gesammte serielle Kommunikation sowie alles andere in einer extra Liste. - Auch kann der Flash-Bereich geändert werden. - Auch kann der Download nun als S2 oder S3 Format erzeugt werden. - Namensgebung hab ich umgedreht und anstatt Upload >> Programmierung geschrieben. Im Anhang also wieder eine ZIP mit Linux und Win Version sowie eine CHM Hilfe Datei in der alles genau beschrieben ist (Auch die INI-Datei Parametrierung). Vielen Dank, wenn Du diese neue Version "V0.3.8A19" testen könntest. Meine Tests laufen gerade noch... (und dauern halt ewig...) PS: Sourcen + Doku gibts hier: http://welecw2000a.svn.sourceforge.net/viewvc/welecw2000a/firmware/trunk/WelecUpdater/
@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
@Hayo Kannst Du einen Download so nebenher laufen lassen, der dauert sowiso ewig...
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
Grad eben konnte ich das Flash Dump über Linux einspielen, hat 2h gedauert. Eine Fehlübertragung wurde erkannt und automatisch korrigiert. Danach hat das Oszi wieder mal funktioniert :) ... Aber nur 2 der 4 Kanäle :( Kann ich irgendwo her ein Dump von einem 4-Kanal Oszi bekommen?
Un jetzt hab ich die TomCat.flash aus dem SF SVN (selbst compilliert) drüber gebügelt (WinXP diesmal, nur 20 Minuten!), siehe da, das Oszi meldet sich als "V1.2 Fellnhofer" ... Ich teste noch weiter....
@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
Ich hab jetzt die Datei flash_t.cpp manipuliert und Kompilliert. einfach die Variable tc_model auf einen Festen Wert geändert und fertig. Ach ja, nach dem EInspielen von "V1.2 Fellnhofer" zeigte das Oszi wieder 4CH, nur der Text war auf 2022. Die Zeichenverzögerung ist relativ einfach. Ich mache auf meiner Seriellen Komponente ein "Flush" Befehl, dann wartet die so lange bis das Zeichen raus ist und dann erst kommt das nächste dran. Dadurch ist ein kleiner Versatz drin. Ich habe auch die SW BinTerm mit dem USB Datenspion erstellt, damit konnte ich es genau anschauen. PC Senden ein Byte, Oszi das Echo. Das hat sehr gut funktioniert.
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
Mit der Portinitialisierung hatte ich auch mal Probleme, ich habe da alles mögliche schon rein programmiert, aber ich glaube es hat noch nicht den erfolg gebracht. Den Minicom Trick hatte ich auch verwendet, dann hats geklappt. (Ich sah das mit dem BinTerm, mein Programm schrieb SendByte, aber es wurde nichts protokolliert, dann wieder Minicom gestartet und es gin was raus, dann wieder mein Programm und plötzlich hat es auch wieder getan. Hmm... !?! Unter WinXP tuts.
Ich hab nochmal was an der EXE geschraubt, die Linux Variante sollte jetzt auch ohne diese Minicom auskommen (hoffe ich). Anbei beide Versionen nochmals
PS: Sollten wir vieleicht diese Dateien besser per Mail austauschen?
@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
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.
Mein Oszi meldet sich mit dem manipulierten Pogramm wieder mit W2024A !!!
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
>Hab ich doch schon längst. Was denkst Du wohl wo die Downloads >herkommen? Sorry, bei zeigte der Zähler noch 0 an... Meine Frau zieht mich auch schon früh ins Bett, sie hat ja recht... Du wolltest noch den Flash-Bereich der Kalibrier-Daten auslesen, wäre es nicht sinnvoll dies auch über mein Tool zu machen? (Dort ein Dialog mit Extra-Funktionen zu implementieren?) Ich habe diesen Bereich bei Adresse ab 0xF0000 geladen, die 2024 rein geschrieben und mit meinem Programm wieder zurückgespielt, jetzt zeigt der für immer die 2024 an. Ist das Flash 8MByte oder 16 MByte groß?
Anbei die Version V0.3.8A20. Bugfix: Letzte Zeile wurde nicht übertragen (eh nur "r0" gewesen). Parameter FlashEnd auf 0x83FFFF gesetzt (falls der Flash 8MByte groß ist wäre das richtig.) Jetzt muss ich arbeiten gehen... Können wir heute Abend mal telefonieren? Hier ist meine Mail-Adresse: http://sourceforge.net/users/mmvisual/
@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
Ich bin jetzt wieder da. Ich hab da eine bessere S-Record Doku mit Google gefunden, siehe Anhang. Funktioniert jetzt die EXE V0.3.8A20 bei Dir auch?
Also Du meinst den Flash sollte ich nur bis Adresse 0x007FFFFF auslesen?
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
Hallo Hayo, nur das ich eurer Arbeit folgen kann... Bei der FW 1.10.03 ist FFT doch von Haus aus aktiviert, was genau hast du daran geändert? Bruno W.
@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
Ich konnte heute Anbend nicht viel machen und gabe nur mal ein Upload
von einem anderen PC aus gestartet. Ich hatte keine Probleme. Download
versuche ich morgen.
Wegen den Fehlern, kannst Du mir bitte vom Debug Fenster >> rechte Maus
>> Alles Kopieren und dann in eine Textdatei einfügen mir schicken?
(Vorher leeren, damit ich nichts altes lese...)
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
@Hayo Du Nutzt aber einen ecten COM Port, nicht einen USB-To-Serial Converter? Bei solch einem Teil wurde meine Kommunikation auch sehr langsam.
@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.
Meine XP-Version hab ich nun an einem anderen PC getestet: - Download funktioniert ohne Fehler - Programmieren der Version 1.2 ohne Fehler, Dauer: 19 Minuten (30000 Zeilen) @Bruno, @Falk: Könnt Ihr mit dieser letzen Version ein Download testen (damit wird nichts in das Oszi geschrieben und sollte ungefährlich sein.)
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
Klasse, dann kann ich heute Abend weitere Funktionen anfangen... (Ich wollte warten bis es wirklich geht, denn ansonsten braucht man das Programm nicht) :)
Hallo, bin erst jetzt wieder online. Scheint ja alles bestens zu laufen bei euch?! Wo hast du denn das XP-Prg. hingestellt und was ist die aktuelle Versionsnr.? Was mich sehr wundert, sind die Zeiten die ihr immer zum einspielen einer FW angebt. Ich hab das bislang immer via USB gemacht, muss das mal stoppen, aber max. 15min- (d.h. längere Zeiten resultieren aus einer langsameren Übertragung, nicht von der W2000A- Verarbeitungsgeschwindigkeit) Ich möchte aber demnächst, an einem anderen PC, auf jeden Fall das XP Prg. testen. Habt ihr gesehen was Slog2 in SF geschrieben hat? http://sourceforge.net/forum/forum.php?thread_id=2388717&forum_id=848386 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. @Hayo: habe dich in SF eingetragen. Gruß, Bruno
@ Bruno: Die letzte veöffentlichte Version V0.3.8A20 ist hier: Beitrag "Re: Wittig(welec) Oszilloskop firmware problem" Datei: http://www.mikrocontroller.net/attachment/41346/WelecUpdater_V0.3.8A20.zip Es sind Linux und Win Versionen im ZIP, beide funktionieren gleich. Nach dem Start wird die INI-Datei angelegt mit allen Parametern. Dann sollte der Parameter "FlashEnd" auf 0x007FFFFF geändert werden, denn ab 0x800000 beginnt der RAM (und es ist sinnlos das zu lesen). Dann EXE neu starten. In meiner noch nicht veröffentlichten Version hab ich das schon geändert, aber das ist nur ein kleiner gut umgehbarar Bug. Folgedes möchte ich noch implementieren: - Test ob der Protected Flash Bereich überschrieben wird beim Programmieren >> Mit Frage ob man dies wirklich machen möchte - Flash-Download Adressbereich einstellbar über Eingabefeler (nicht mehr in der INI Datei. - Extra-Dialog, in dem man z.B. den Protected Flash-Bereich auslesen kann. Ich freue mich schon auf Rückmeldungen.
PS: Im Zip ist eine CHM-Hilfe Datei mit drin, da ist alles beschrieben. Die USB-Software von WELEC ist bei mir auch schneller, da USB einfach schneller ist. Vieleicht findet jemand heraus wie man den USB Treiber anspricht, dann kann ich diese Variante auch in mein "WelecUpdater" einbinden...
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
>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 !!
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
>Vieleicht findet jemand heraus wie man den USB Treiber >anspricht, dann kann ich diese Variante auch in mein "WelecUpdater" >einbinden... Da kann dir sicher der Slog2 helfen- am besten über Sourceforge einmal konkret bei ihm anfragen!
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
@ Falk: Falls du möchtest kannst du ja einmal den USB-Blaster von Slog austesten. Das sieht wirklich gut aus!!! Er würde sich bestimmt auch über eine Rückmeldung freuen. ...Wir entlocken dem W2000a immer mehr Geheimnisse... Ich denk mir das wir jetzt eine gut funktionierende Toolchain haben um sowohl FPGA als auch den Softcore- Flash upzudaten. Gruß, Bruno
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
Notfalls kann man unter Windows auch die VirtualBox installieren, darin Linux laufen lassen und man kann dann ohne Neustart programmieren.... Wie kann man den FPGA auslesen?
@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
Weiss jemand, was das CyUSB.spt für ein Format ist? Scheint ja kein reines Binary zu sein. Dafür ist es zu gross (ca 9kb). Würde es gerne in ein Intel Hex-Format wandeln, dann kann man es unter Linux mit fxload laden.
Oder falls jemand das hex-file direkt haben sollte, wäre das natürlich auch gut :-)
*.spt: The .SPT file extension identifies an ESPL Programming file which is a source code file belonging to the ESPL development environment for creating applications relating to the science industries. In order to update a .LIB file, you must load its companion .SPT source file into the ESPL Editor window and then save the changes. See also: http://www.ensignsoftware.com/espl/espl126.htm
Hmm, dann müsste das spt-File ein ASCII-File sein (source code). Ist es aber nicht :-( Ich denke mal, das ist ein anderes Format.
hat sich erledigt. slog hat die Sourcen und das Hex-File gepostet. Super :-)
@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 hab nun die Dateiversion V0.3.8A21 fertig gestellt. Verbesserungen: - Verhinderung dass automatisch das System den Suspend Mode oder Bildschirmschoner aktiviert - Überschreibschutz wählbar für den Bereich 0xF0000 (Protected Code Bereich mit Werkeinstellungen) - Download-Adressbereich nun über "v" Button neben dem Download-Button anwählbar. Die Linux-Version mache ich ein anderes mal. Die Hilfe ist entsprechend aktualisiert. Bitte Testen und Rückmeldungen schreiben... Vielen Dank.
Ich teste morgen (heute) im laufe des Tages. gute Nacht Hayo
Anbei die Datei V0.3.8A22: - Statusleiste bei den "e" Befehlen aktualisiert - Restzeitanzeige während Programmierung verbessert - Deaktivierung Suspend auch während programmierung der "e" Befehle - Übertragungssicherheit nichmals verbessert
@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
Hallo Hayo, genau darüber habe ich mir auch schon öfter Gedanken gemacht... Bislang stand hier im Forum ja "nur" die Erstellung der Toolchain im Vordergrund. Ich glaube das wird sich zunehmend zum FW- Improvement auf Basis der 1.2 Sourcen ändern. Es ist bestimmt auch nicht so sinnvoll, jeden Tag eine neue SW-Version in dieses Forum zu posten. Besser ist sowas entweder in den Google Groups aufgehoben, da lässt sich eine alte SW Version einfach durch eine neuere ersetzen, oder eben in SF (wegen dem Repository). Meiner Meinung nach ist, spätestens sobald mehrere an der gleichen SW programmieren (FW 1.2 +), eine ordentliche Versionskontrolle/ Abgleich eh unverzichtbar. Leider habe ich noch nicht herausgefunden wie sich in SF ein Sub-project einrichten lässt, das würde wohl am meisten Sinn machen. Eigentlich handelt es sich sogar um drei Bereiche: 1.) FPGA- Neudesign 2.) Common Tools (WelecUpdater, sonst noch was?) 3.) FW 1.2+ (Verbesserung der FW auf Basis der 1.2 Sourcen) Vielleicht sollte ich zumindest schon einmal das SF- Forum auf dieser Basis neu- organisieren (Beiträge in entsprechende Ordner verschieben)??? Für Anregungen dazu bin ich ebenfalls dankbar! Gruß, Bruno
@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
@Hayo, vielleicht habe ich mich etwas ungeschickt ausgedrückt. Ich gehe auch davon aus, dass vieles was in die Original FW von uns einprogrammiert wird, mit wenigen Anpassungen übernommen werden kann. Ich bin gerade dabei SF dementsprechend zu erweitern. Erstmal in Wiki und im Forum Gruß, Bruno
@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
@Hayo >Hast Du die Funktion nur für den Download >implementiert, oder auch für den Upload? Das konnte ich jetzt noch >nicht überprüfen. Ist für beide aktivitäten drin. Grund: Das die Bildschirmschoner nicht den Rechner belasten und den Up/Download verlangsamen. @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.
>> Hardware
Ja, eine Masse-Buchse (GND) (für 4mm Bananenstecker), das braucht man
doch immer. Ich verstehe nicht wie man ein Messgerät ohne so was
überhaupt herstellen kann.
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
Ich nutze den von Macromedia, ein sehr alte Version. Aber es gibt auch Freeware: http://www.nvu-composer.de
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.
Ich hab heute einmal das Wiki unter SF auf Vordermann gebracht. Es wäre nett wenn sich jeder der schon am Programmieren ist, dort einträgt- speziell in Bereichen die später zusammengeführt werden sollen (Firmware 1.2+, FPGA Redesign,...?)- : http://welecw2000a.wiki.sourceforge.net/Project+Planning Ziel soll es sein, Doppelentwicklungen zu vermeiden und das Projekt besser zu strukturieren. Morgen ändere ich noch das SF-Forum entsprechend ab, so das sich sowohl die FPGA Neuentwicklung als auch die Firmwareänderungen und die Erstellung der Toolchain/ zusätzlicher Software unter dem gemeinsamen Projektnamen: http://sourceforge.net/projects/welecw2000a/ etablieren lassen, ohne sich in die Quere zu kommen. psionic passt zwischenzeitl. den Tracker an. Gruß, Bruno
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
@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...
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
@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. Und Compiller gibts für Linux und Windows (ev. auch MacOS). Das Schönde daran: Es sind nur kleine Unterschiede im Code... Ich habe auch schon viel mit USB gemacht, also auf der Microcontroller Seite sowie auf der PC Seite. Das qtdso sieht sehr gut aus. Ich kann mir auch vorstellen dass der Screen auch Online nicht nur am Oszi sondern auch auf den PC übertragen kann. (ist ja USB) @Hayo Stimmt nicht ganz, es wird die Zeilennummer in der Statusleiste angezeigt. Kann ich aber gerne einprogrammieren.
Hallo Hayo, ich wollte heute einfach mal das Programm testen, aber irgendwie wird der auch nach über einer Stunde nicht fertig mit dem Download. Hab es dann abgebrochen. Wie lange dauert ein normaler Download? Ich habe im Übrigen das 2014A. Gruß, branadic
@branadic Welche Datei denn? Nutzt Du einen USB-To-Serial-Converter? Der ist deutlich langsamer.
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
Hallo Markus, ich habe mit der 21er und der 22er Version versucht den Flash auszulesen, einfach mal rein aus Neugierde. Hab übrigens noch einen PC mit RS232, ohne USB-Adapter dazwischen. Irgendwie hab ich anfangs gesehen, wie die Zeilen hochzählten und nach einer ganzen Weile wurde das Ganze total langsam und die Zeilen zählten rückwärts??? Gruß, branadic
Wichtig für die PC Software fände ich, dass man den Screendump in kompletter Breite, also die 16k Speicher exportieren kann!
@branadic In der Parameterdatei WelecUpdater.ini gibt es einen Parameter "Debug", den mal von 0 auf 1 setzen und dann öffnet sich ein zusätzliches Fenster. Hier sieht man was das Programm genau macht. (EXE muss neu gestartet werden... Wie das dann geht ist in der Hilfe beschrieben.
Ich habe vom WelecUpdater nun das erste Release V0.4.8A22 fertig gestellt und unter: http://groups.google.com/group/welec-dso/files veröffentlicht. Datei: WelecUpdater.zip Innhalt: Windows-Version, Linux-Version, Hilfe-Datei @Falk: In der Linux-Version werden auch die ttyUSB* angezeigt.
@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
Hallo Markus, hab gestern Abend noch mal ein Test gemacht und versucht das Flash-File aus dem Oszi zu ziehen, leider ohne Erfolg. Diesmal habe ich auch mitbekommen wieso. 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
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
Hallo Hayo, ich werde das, wenn ich heute Abend die Zeit finde, noch einmal angehen und versuchen die fehlenden Informationen nachzuliefern. Gruß, branadic
Hallo zusammen, nach 1h 26min 38s ist nun der erste Download meines FlashDumps mit der v22 erfolgreich fertig. Hab diesmal den Rechner rödeln lassen, ohne daran zu arbeiten. Die Zeit kommt mir aber irgendwie unverhältnismäßig lange vor, gegenüber der Zeit von Hayo!? Rechner: Athlon 2500+ (1,83 GHz) Betriebssystem: WinXP (SP3) Softwareversion des Updaters: 0.3.8A22 Gruß, branadic
Die Zeit ist normal. Erst wenn es 1,5h dauert, dann ist es viel.
PS: In Google-Groups gibts die Version 0.4.8A22. http://groups.google.com/group/welec-dso/files?&sort=date
Hallo Markus, nenn mich großspurig, aber 1:26:38 sind bei mir nährungsweise 1,5h. Auf die 3min22sec kommt es dann auch nicht mehr drauf an. Gruß, branadic
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 Sorry, die "1h" hab ich übersehen. Gibt es sonst noch etwas was den PC langsam macht? (Software?) Virenscanner und Co sollten keinen Einfaluss haben da ja keine Datei gelesen und geschrieben wird.
Hallo Markus, was anderes lief nicht im Hintergrund, kann dir nicht sagen, woran es gelegen hat. Gruß, branadic
@ branadic Kannst Du ein Log machen im Debug Modus? Gibt es darin irgend welche Übertragungsfehler, Resend usw.? Wenn ja, dann haben die Maßnahmen die ich ein programmiert habe funktioniert ;) , ... aber es sollten wenn möglich diese Fehler nicht auftauchen, das wäre dann besser. Kannst Du in der Systemsteuerung die Parameter der seriellen Schnittstelle mal anschauen? Siehe: Beitrag "Re: Wittig(welec) Oszilloskop firmware problem"
Hallo Markus, gab keine Verbindungsunterbrechung, keine Übertragungsfehler, kein Resend. Wie speichert man eigentlich im Debug Modus? Muss ich zeilenweise kopieren? Irgendwie wollt das bei mir nicht so recht klappen. Hab auch mal wie von dir beschrieben in der Systemsteuerung nachgeschaut. FIFO ist aktiviert, ich werde aber mal den Interrupt ein wenig runter stellen und schauen, was sich tut. Das Programm startet bei mir schon mit 57min Downloadzeit, nur schafft es den Download in der Zeit nicht. Gruß, branadic
Hab heute noch mal Versuche gemacht, scheinbar hat das Problem was mit Skype zu tun, schreibe ich nebenbei im Skype bekommt das Programm Disconnects... irgendeine Idee wie sowas sein kann? Gruß, branadic
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
Bei Skype hab ich auch schon festgestellt, dass es irgendwie die ganze Zeit was zu tun hat, es benötigt die ganze Zeit Rechenleistung. Ich habe mein Skype deaktiviert und mach es nur noch auf wenn ich was brauche. (Irgendwie werde ich bei Skype das gefühl nicht los, dass es sich um eine Spionage-Software handelt...)
Hallo, so langsam glaub ich auch ich verliere den Verstand, ich bekomme die Zeilen im Debuggfenster einfach nicht kopiert. So langsam zweifel ich an mir selbst. Ich kann auf Liste kopieren klicken, dann merkt man kurz das was im Hintergrund passiert, doch wenn ich "einfügen" im Notepad oder irgendeinem anderen Schreibprogramm sage passiert nichts. Deswegen hatte ich auch nachgefragt, ob es irgendeinen Trick gibt. Jedoch starte ich den Dwonload, stoppe ihn nach kurzer Zeit und kopier die Debugginfo's, die dann ja nicht ganz so lang sind, klappt es. Irgendeine Idee woran das liegen mag? Komm mir gerade wie der derbste Newbee am PC for. Der Download hat eben wieder mal 1:28:06 gedauert. Absolut abgefahren, da ist was faul! Gruß, branadic
So, endlich geschafft. Scheinbar hat das Standard Windoof-Notepad ein echtes Problem. Hab mal das Notepad++ gestartet und siehe da, man kann die Daten endlich auch mal einfügen und abspeichern. Wenn ich jetzt noch eine Möglichkeit finde das Log-File kleiner zu bekommen, dann könnt ich das auch mal hochladen. Oder kann ich das dem Markus an irgendeine Mailadresse schicken? Gruß, branadic
Hallo Branadic, Vielleicht an seine SF-Mailadresse? Gruß Bruno
Natürlich zippen, oder besser mit Winrar raren. Meine Mail-Adresse gibts hier: Beitrag "Re: Wittig(welec) Oszilloskop firmware problem" Postfach ist auf 2MB begrenzt.
@Branadic Ja, ich habe 2 Mails bekommen.... In dem Log gibt es nur gute Übertragungen, kein einziger Fehler. Ich habe die gleiche Übertragung gerade bei mir ausprobiert: "17:44:29 Download... Verbindungsaufbau" : : : : "18:39:30 Download Fertig. Gesamtdauer: 00:55:00" Da ist mein Rechner um 30 Minuten schneller. (Ich hatte meinen WelecUpdater während dem Download minimiert, damit muss Windows nichst ständig sinnloserweise Grafikausgaben malen >>> Download geht schneller) Die Zeiten vom Programmieren von Hayo (und meine 20 Minuten) kommen daher, weil in der .flash Datei viel weniger Daten stehen. (Programmieren ist nicht Download!) Hingegen dieser Download liest die ganzen 8MB Flash aus und das dauert einfach viel länger als das Programmieren. Denn im Download muss daskomplette Flash gelesen werden, auch wenn da nichts drin steht. Erst nach dem Lesen weiss der WelecUpdater dass nix drin stand und erzeugt dann automatisch keine Motorola-S Zeile.
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
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
Hallo Hayo, klar doch, wenn's weiter nichts ist, dann anbei mal mein FlashDump. Gruß, branadic
@branadic Super, vielen Dank. Wie ich am Downloadcounter sehe bin ich auch nicht der einzige der interessiert ist. Gruß Hayo
Ja, ich bin auch noch da. @branadic, meine Antwort von 18:52, gestern hast Du ja gesehen?
@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
Hallo Markus, ja habe ich gesehen ;) Gibt es schon erste Erkenntnisse zu meinem Flashdump? Hab's mir mal angeschaut, aber ohne das zu dekompilieren bringt das wohl eher nichts... Ich denke ich muss mich mal mit Quartus beschäftigen, auch wenn mich FPGA's aus irgendeinem Grund noch irgendwie abschrecken. Keine Ahnung wieso, aber aus irgendeinem Grund habe ich noch gebürtigen Respekt vor den Dingern. Werd mich wohl mal überwinden müssen ;) Gruß, branadic
Wenigstens funktioniert die Linux-Version ohne Probleme. Ich verwende ein Komponente "Synaser", die ist für Windows und Linux geeignet. Wenn ich in Linux einen Kommandozeilen Aufruf rein mache, dann ist die ganze Bedienung und Statusanzeige über den Haufen gschmissen. Viel mehr sollte man untersuchen was hier der "Zeitfresser" ist. - Lesen der Daten-Zeile aus dem Fenster - Darstellen unwichtiger Infos auf dem Bildschirm - Sende-/Empfang Zeit - zu wenig RAM verfügbar - langsamer Rechner - ... Bei mir lief die Linux Version auch langsamer, was wohl auf die Virtual Box zurückzuführen ist. PS: ein Firmwareupdate dauerte bei mir unter Linux aber nur ca- 40 Minuten (V1.3, nicht den Update des gesamten Dumps!).
@branadic Solange ich von meinem FPGA keine wirkliche Sicherung habe die ich jederzeit zurückspielen kann, spiele ich auch nichts neues ein. Und wie ich das Ding auslesen kann weiß ich nicht. Wenn mir jemand schreiben kann wie das über serielle Schnittstelle geht, dann kann ich das gerne in den WelecUpdater einbauen.
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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.