CW hängt beim Serial Port Scan

[mirabilos]

Bei echten seriellen Ports kriegst Du, wenn Du die falsche Bitrate ausgewählt
hast, auch was rein, nur halt „Müll“… wenn der Test wirklich nur scannt, ob da
_irgendwas_ reinkommt, ist die Bitrate in der Tat egal.

 

[Kappler]

Es kommt aber bei unterschiedlichen Bitraten kein "Müll" rein, sondern wunderschöne NMEA-Datensätze...

 

[MiK]

Es kommt aber bei unterschiedlichen Bitraten kein "Müll" rein, sondern wunderschöne NMEA-Datensätze...

Was aber in der Scan-Routine nicht überprüft wird. Unterschiedliche Baudraten zu testen ergibt also nur Sinn, wenn man dann auch testet, ob wirklich NMEA ankommt.

 

[Kappler]

Wenn aber bei vielen Baudraten NMEA reinkommt, dann macht das Testen mit unterschiedlichen Baudraten auch keinen Sinn...

 

[MiK]

Wenn aber bei vielen Baudraten NMEA reinkommt, dann macht das Testen mit unterschiedlichen Baudraten auch keinen Sinn...

Ach so war das gemeint... Aber eigentlich schon. Dann weiß man welche Port/Baud-Kombination funktionieren könnte.

 

[MiK]

Ich würde gerne vor den Feiertagen / langem Wochenende noch einen RC2 rausbringen. Macht noch jemand einen Patch hierfür?

 

[pfeffer]

bin dabei

Pfeffer.

 

[pfeffer]

so. Ich habe
1. den Test eingebaut, ob es GPS-Daten sind
2. eine Ausgabe, ob scan erfolgreich war
3. die Verwendung der angegebenen Baudrate beim scan
4. eine Fehlermeldung, wenn der Port nicht geöffnet werden konnte
5. für die Linuxer: Portangabe wird, wenn sie mit "/" beginnt so umgeschrieben, dass ewe sie von akzeptiert wird. @mirabilos: bitte testen.

@Dev: bitte begutachten.

Gruß,
Pfeffer.

 

[Kappler]

@Dev: bitte begutachten.

Angeschaut und auf dem PDA getestet: funktioniert...

Wobei wie gesagt bei mir auf dem HW-Port (auf dem Split-Port sowieso) unter beinahe allen Baudraten ordentliche Daten empfangen werden...

 

[MiK]

Die Änderungen sehen gut aus. Trotzdem habe ich auf meinem PDA weiterhin das Problem, dass beim Scan auf keinem Port Daten empfangen werden, obwohl es beim Test funktioniert.

 

[pfeffer]

Ich habe den eingangs beschriebenen Absturz :-(
Es ist sehr seltsam:
1. er passiert nur beim automatischen Port-scan
2. er passiert nicht (auch nicht beim automatischen Port-scan), wenn ich baud 9600 eingestellt habe

Der Absturz tritt auf in

			gpsLen = gpsPort.nonBlockingRead(gpsBuff,0, gpsBuff.length);

Mist - jetzt tritt er gar nicht mehr auf. Sehr seltsam das.

Gruß,
Pfeffer.

 

[pfeffer]

So, also, inzwischen habe ich ein kleines Bischen was herausgefunden:
1. Beim Portscan stürtzt mein Loox nicht mehr ab, seit dem ich ein Firmware-Update des SIRF-Chips gemacht habe (das auf der Web-seite von FuSi zu bekommen ist - jetzt habe ich Instant-Fix I ).

2. Dafür stürtzt jetzt CacheWolf Gerät ab, wenn ich es während das GPS läuft ab- und wieder einschalte :-(

Das Problem liegt in irgendeinem Bug, in der Schicht zwischen ewe, WM5 und Firmware des GPS. Die Frage ist, ob wir diesen Bug irgendwie umgehen können.

Ich berichte mal, was ich vor dem Firmwareupdate (d.h. als der Absturz noch auftrat) versucht habe, damit andere, bei denen ein ähnliches Phänomen auftritt berichten können, ob es bei ihnen auch so ist. Da der Hänger nicht auftritt, wenn man "test" drückt, habe zwischen alle IO-Operationen ein Vm.sleep(10000) eingebaut - es hat aber nichts genutzt :-(

Gruß,
Pfeffer.

 

[2cachefix]

So, also, inzwischen habe ich ein kleines Bischen was herausgefunden:
1. Beim Portscan stürtzt mein Loox nicht mehr ab, seit dem ich ein Firmware-Update des SIRF-Chips gemacht habe (das auf der Web-seite von FuSi zu bekommen ist - jetzt habe ich Instant-Fix I ).


2. Dafür stürtzt jetzt mein Gerät ab, wenn ich es während das GPS läuft ab- und wieder einschalte :-(

Das Problem liegt in irgendeinem Bug, in der Schicht zwischen ewe, WM5 und Firmware des GPS. Die Frage ist, ob wir diesen Bug irgendwie umgehen können.

Ich berichte mal, was ich vor dem Firmwareupdate (d.h. als der Absturz noch auftrat) versucht habe, damit andere, bei denen ein ähnliches Phänomen auftritt berichten können, ob es bei ihnen auch so ist. Da der Hänger nicht auftritt, wenn man "test" drückt, habe zwischen alle IO-Operationen ein Vm.sleep(10000) eingebaut - es hat aber nichts genutzt :-(

Gruß,
Pfeffer.

zu1.
Mein PDa stürtz zwar nicht ab, aber es hängt sich auf. Ein Firmware für ASUS969 habe ich nicht gefunden

zu2.
das ist bei mir schon immer so.

D.h. das Problem bzieht sich nicht nur auf WM5 sondern auch auf WM6


Wird denn bei Dir beim Testscan ein Port gefunden?
Hier nutzt ein Timer glaube ich nichts. Vielleicht aber bei dem Ein-Ausschaltabstutz. Es sieht doch so aus, als ob Cw schneller GPSdaten erwartet, als das PDA/GPS liefern kann.

 

[pfeffer]

Zu 1: ich habe mich unpräzise ausgedrückt: CacheWolf reagiert nicht mehr, andere Anwendungen funktionieren noch.

Zu 2: bei mir war das schon immer so mit Destinator. Bei CacheWolf habe ich nach dem Einschalten eine Meldung bekommen (die ich programmiert habe ;-) ), dass keine Daten mehr vom GPS kommen und der Port geschlossen wird. Erneutes Drücken auf "Start" hat dann schön wieder die Daten geliefert.

Ja, bei mir wird der GPS-Port korrekt gefunden (mit der aktuellen Nightly Build, mit älteren habe ich es nie probiert bzw. kann mich nicht erinnern).

Zum Abschalt-Problem: Ich denke, CacheWolf muss den Port schließen, kurz warten und danach wieder öffnen. Ich gucke mal, ob ich da was hinkriege. Es könnte auch sein, dass der Port eben vor dem Abschalten geschlossen werden muss, ich fürchte, dann können wir nichts machen.

Gruß,
Pfeffer.

 

[2cachefix]

Ich glaube nicht, dass der Port vor dem Abschalten geschlossen werden muss. Da andere Anwendungen z.B. TomTom doch ebenfalls ein Problem haben. Das ist aber nicht der Fall.

 

[pfeffer]

Kannst Du das nochmal ausführlicher schreiben?
A. Hat TomTom bei Dir ein Problem nach dem Aus-Einschalten? - Bei mir hat Destinator eins

B. woher weißt Du, ob TomTom den Port schließt?

Oder was hast Due genau gemeint?

C. Könntest Deine Tests, die Du auf der ersten Seites dieses Threads beschrieben hast, nochmal mit der aktuellen NB durchführen und hier berichten?

Gruß,
Pfeffer.

 

[2cachefix]

zu A: TomTom hat kein Problem mit dem Ein-Ausschalten.

zu B: das weiss ich nicht. Das war nur eine Schlussfolgerung. Ich gehe einfach mal davon aus, dass TomTom den Port nicht schliesst. Wie auch, wenn ich das PDA einfach ausschalte.

zu C: das werde ich sobald wie möglich machen.

 

[2cachefix]

So, nun hier meine Testergebnisse.
Hardwareport beim ASUS ist COM5

ohne eingeschalteten Splitter
- Scan läuft durch, findet aber keinen Port.
- COM5 fest vorgegeben funktioniert. Während meines Testes kein Abbruch.

Softwareport COM6
mit Splitter
- Scan läuft bis COM6 und hängt sich auf
- COM6 fest vorgegeben funktioniert, bricht aber nach Aus-/Einschalten ab.
- genauso verhält es sich mit GPSGate(ext. Splitter). Das ist also auch keine Lösung

 

[pfeffer]

So, ich glaube, vorgestern Nacht das Problem gelost zu haben. Das Lesen vom seriellen Port darf nicht in einem Event-Thread geschehen, sondern muss in einem anderen mThread laufen. Testweise funktioniert das auch prblemlos, ich muss den Code nur noch etwas optimieren und meine Debug-Ausgaben entfernen, dann stelle ich es als Patch zum testen zur Verfügung.

Weiterhin ungelöst ist allerdings das Problem, das CacheWolf nicht mehr reagiert, wenn ich den PDA abschalte und wieder einschalte, ohne vorher auf "stop GPS" gedrückt zu haben. Leider lässt sich CacheWolf dann nur noch durch ein Softreset des PPC beenden.


Gruß,
Pfeffer.

 

[pfeffer]

Für das Problem nach dem Abschalten habe ich mir folgendes überlegt:

1. CacheWolf bekommt leider keinen Event nach dem Einschalten. Es kann also nicht so einfach festgestellt werden, dass er ab- und wieder eingeschaltet wurde.

2. bei mir ist es so, dass ich nach dem Einschalten noch Daten aus dem Puffer bekomme und erst bei dem 2. Versuch Daten vom seriellen Port zu lesen, sich CacheWolf aufhängt.

Wenn das richtig ist, dass die ersten Daten noch alte, gepufferte sind, dann könnte man das feststellen daran, dass die Differenz zwischen den in den GPS-Daten gesendete Uhrzeit und der Systemzeit des PDA sich geändert hat. Wenn diese Differenz eine bestimmte Schwelle überschritten hat, dann könnte CW quasi vorsichtshalber automatisch den seriellen Port schließen und automatisch erneut öffnen.

Könnte Ihr bitte mal testen, ob Ihr nach dem wieder einschalten auch noch kurz korrekte Daten bekommt?

Eine schöne Lösung ist das nicht, aber besser als ständige Abstürze. Was meint Ihr?

Gruß,
Pfeffer.