XE5 + Android + Bluetooth = Problem

[toenne]

Erstmal danke für die Antwort.
Das mit dem FormCreate werde ich beherzigen, dürfte aber wohl eher nicht Auslöser meines Problems sein vermute ich?
Was die Auswertung des EOL angeht: Die Übertragung von HTerm zu irgendeiner anderen BT Terminal-APP (und zurück) funktioniert tadellos, genauso wie zu irgendwelchen Windoof-Anwendungen. Wo sollen die zusätzlichen EOL plötzlich herkommen? Ich werde es mal testen, verspreche mir aber nicht allzu viel davon.
Hast du den Code denn evtl. mal bei dir getestet?

Was XE8 angeht ist das ein ganz finsteres Kapitel. Ich hatte mir die XE8 Demo heruntergeladen und installiert. Mal abgesehen davon dass nicht einmal die "Classic Bluetooth Basic app" aus den samples funktioniert (die Devices werden zwar gelistet, eine Kopplung ist aber nicht möglich...und Tante Google sagt mir dass ich damit nicht alleine bin) hats mir das System geschreddert! Seit der Installation bekommen ich einige Zeit nach dem Start von XE (und zwar jetzt egal ob XE5 oder XE8!) das prächtige Farbenspiel im Anhang zu sehen, der Rechner ist dann komplett tot und der Reboot dauert eine gefühlte Ewigkeit da Windows (7 Ultimate 64Bit) offensichtlich einiges zu fixen hat. Übrigens auch wenn ich XE längst wieder beendet habe, irgendwann gehts urplötzlich los. Einzige Möglichkeit: Nicht allzu lange mit XE arbeiten, dann beenden und vorsorglich neu booten...nicht besonders witzig...
Leider sind seit meinem letzten Backup ein paar Dinge dazu gekommen auf deren Neuinstallation ich derzeit einfach keinen Nerv habe, daher muss ich wohl erstmal damit leben. Starte ich zwischen zwei Reboots XE nicht dann passiert übrigens auch nicht.
Auf meinem Rechner nutze ich alles mögliche von 3D CAD/Cam über Video- und Bildverarbeitung bis hin zu Spielen, das System läuft 100% stabil, einen BSOD kenne ich eigentlich nicht. System & Hardware kann ich also ausschliessen, da hat Emba mir eine fette Laus ins Fell gesetzt. Daher steht ein finales Upgrade und eine Weiternutzung von XE8 nicht zur Debatte.

[Rollo62]

Also was du da in deinem Video hast:

Bist du sicher das du nicht das LowLevelGrafik-Beispiel gestartet hast

Nein, solche Effekte kenne ich nicht.
Bei mir ist XE8 zwar gefühlte alle 5 Minuten abgestürzt, aber hat ToiToiToi nie etwas in den Orkus gerissen.
Wie gesagt Rx10 ist da erheblich stabiler.

Aber ich hatte auch fast keine Fremdkomponenten auf dem System (eben deswegen), und wie ich dich verstehe
hast du alles Mögliche installiert.

Ich würde mal versuchen das Ganze auf einem sauberen Win8.1 und Xe8.1 nochmal zu kompilieren.
Vielleicht hilft das ja.

Wenn so eine lange Ausgabezeile zerhackt wird liegt es vielleicht an zu kleinen Buffergrößen
(das scheint zumindest immer in gleiche Längen aufgeteilt zu werden), oder es liegt am Timing des Lesethreads.
Deshalb meinte ich ja:
Einfach alles im Empfänger wieder in einen String zusammenbauen, und erst wenn ein finales ELO erscheint
dann diesen ganzen String als gelesen übergeben und weiterverarbeiten.
Aber die Pausen von 0.5 Sek. sind natürlich extrem, bist du sicher das dies nicht vom HC05 kommt ?

Bei Funkverbindungen würde ich mich nicht drauf verlassen das alles im richtigen Timing ankommt.
Es können natürlich auch Daten komplett verschluckt werden, also müsste das Ganze ein Timeout überwachen.

Testen kann ich leider nicht, mir fehlt so ein BT-Device.

Rollo

[toenne]

Zitat:

Bist du sicher das du nicht das LowLevelGrafik-Beispiel gestartet hast

Immerhin kann ich weiterhin sagen ich hätte keinen Bluescreen .

Zitat:

Ich würde mal versuchen das Ganze auf einem sauberen Win8.1 und Xe8.1 nochmal zu kompilieren.
Vielleicht hilft das ja.

Nix für ungut, aber ich werde ganz bestimmt nicht ein neues System nur wegen XE8 aufsetzen. Ohne XE läuft das System 100% stabil, ergo wird demnächst doch das Backup zurück gespielt und dann ist XE8 Geschichte.

Zitat:

Wenn so eine lange Ausgabezeile zerhackt wird liegt es vielleicht an zu kleinen Buffergrößen

Das war nur ein Beispiel zur Veranschaulichung. Selbst wenn nur 2 oder 3 Byte übertragen werden erscheint zunächst nur ein Byte und die weiteren erst im nächsten Timerintervall. Und nach durchschnittlich weiteren 10 Byte ist jeweils wieder Pause.
Übrigens hatte ich HTerm noch vom letzten Test offen, da habe ich die Darstellung mal auf HEX umgeschaltet: Es wurde zumindest kein EOF zurückgeschickt, ergo dürfte - da ja der Inhalt des Buffer 1:1 zurückgesendet wird - auch keiner empfangen worden sein.
Die 0.5 Sek sind übrigens wahlfrei, den gleichen Effekt gibt es auch bei weitaus längeren Intervallen. Die 0.5 Sek hatte ich nur zuletzt verwendet weil ich keine Lust hatte immer so lange zu warten . Bei 9.6kBd dürfte das aber trotzdem kein Ding sein, zumal Sender und Empfänger 1m voeinander getrennt auf dem Tisch liegen und daher keine Funkprobleme eine Rolle spielen sollten. Und wie gesagt: Schicke ich den String statt an diese Testapp an ein BT-Terminalprogramm auf dem Smartphone so erscheint er dort sofort und in voller Schönheit.
Mir ist alleine schon rätselhaft wieso zunächst immer zuverlässig nur 1Byte erscheint und dann jeweils ~10er Päckchen...wenn wenigstens alle Päckchen die gleiche Länge hätten...

Zitat:

Testen kann ich leider nicht, mir fehlt so ein BT-Device.

Ich muss mal schauen wo ich meinen PC BT-Stick verbuddelt habe und mit dem testen, ich bin aber überzeugt dass das Ergebnis das gleiche ist. Die HC05/06 sind eigentlich absolut zuverlässig und unkompliziert.
Ich habe auch zwei verschiedene USB-TTL Wandler für den Anschluss des HCxx getestet, den kann man als Fehlerursache eher auch auschliessen.

[toenne]

Mal ein kleiner Nachtrag zum 'Bunt-Screen' Problem: Ich hatte mal das Tool ProzessExplorer gestartet und mir jeweils die Liste der aktiven Dienste vor dem Start von XE5, während des Laufs des Programms und nach Beendigung exportiert. Nach dem Nebeneinander legen zeigte sich dass mit XE5 auch ICloud gestartet wurde (hatte ich mangels Obst-Produkten in meinem Haushalt nie wissentlich installiert?) welches auch nach Ende weiterlief. Also habe ich den Quatsch deinstalliert und nun läuft XE5 wieder fehlerlos. Aber nur XE5, bei/nach Benutzung von XE8 stürzt der Rechner weiterhin irgendwann gnadenlos ab. Und zwar so gnadenlos dass Windows nicht einmal mehr ein Event protokollieren und/oder ein Memory Dump erstellen kann.
Nun ja, die Testfrist läuft Mitte der Woche ohnehin ab, dann putze ich es wieder von der Platte.

[Bernhard Geyer]

Zitat von toenne:

Rechner weiterhin irgendwann gnadenlos ab. Und zwar so gnadenlos dass Windows nicht einmal mehr ein Event protokollieren und/oder ein Memory Dump erstellen kann.
Nun ja, die Testfrist läuft Mitte der Woche ohnehin ab, dann putze ich es wieder von der Platte.

Eine normale Anwendung (und das sind Delphi-IDEs) können gar nicht dafür sorgen das Windows so abstürzt.
Dein Fehlerbild deutet auf einen HW-Defekt hin. Also entweder RAM oder die CPU/Mainboard. Mit geringer Wahrscheinlichkeit die Festplatte auf der die Auslagerungsdatei liegt.
Lass einfach eines der üblichen HW-Testprogramme laufen bevor bei dir irgendwelche wichtigen Daten verloren gehen.

[toenne]

Festplatten (Raid1) sind nagelneu.
Aber bevor ich die Hardwareliste durchhangel würde mich interessieren, welche Hardware explizit bei XE8 versagen soll?
Denn nochmals: Mein Rechner läuft 24/7 durch, mit den verschiedensten Applikationen - fehlerfrei. Kaum aber habe ich XE8 gestartet (und ruhig auch wieder beendet) so ist dieser Crash unausweichlich.
Ich habe in den Untiefen des Zwischennetzes von einem Fall von Inkompabilität mit dem Avast Virenscanner gelesen, den benutze ich auch. Also habe ich den testweise mal deinstalliert und es dann getestet -> Crash.
Da mir inzwischen jede Idee ausgeht was die Ursache sein könnte belasse ich es dabei, ohne XE8 läuft die Kiste 100% stabil, da werde ich nicht dran rumfingern und es verschlimmbessern .

[mensch72]

für solche Aktionen wurden VMs erfunden... man nehme eine fertige archivierte cleane VM mit der gerade benötigten Windowsversion, packe diese aus und installiere darin XE8 "alleine".. und siehe da, XE8 wird funktionieren. (Was macht XE8 anders gegen XE5.. es braucht "allen" RAM, es ist durch das Castalia Zeug Grafíktreiberabhängig, es hängt im langen SuchPath weiter hinten und man hofft das auch alles aktuelle gefunden wird und teilweise nicht irgendwas älteres als MischMasch geladen wird.. aber das ist völlig egal, wenn in einem Windows immer nur frisch ein Delphi jeweils neu installiert wird)

Warum auf einem PC wo schon zig Programme drauf und wieder runter gekommen sind etwas nicht geht... schade um die Mühe es zu suchen, wenn der Gegentest per VM fast ohne Mühe geht.
Und WorstCase: für ~400Eur ein zusätzlicher beliebiger Aldi/Mediamarkt PC... bei den Preisen von XE8..XE10 und normalen Stundensätzen die man mit Absturz-Test&Suche verplempert kann auch das sich lohnen. VMs per USB3 Festplatte/SSD/schnellem 128GB-Stick laufen per VMplayer sogar zum Test im Laden vor dem PC-Kauf.



=> hier ging es ja ursprünglich um ein Android-Bluetooth Problem
wir hatten auch mit XE5 was mit JNI selbst gebastelt, XE6 hatten wir ausgelassen. Ab XE7 und XE8 dann mit den BT/BLE Komponenten gearbeitet und richtig sicher geht es erst ab XE8.1 und jetzt XE10... soll heißen im MobileBereich nimmt man egal ob man will oder nicht einfach immer die aktuellen EW-Tools. Selbst XE8-RTM wäre da jetzt schon 2 Schritte zurück und es ist schade um die Zeit die man da teils mit Dingen kämpft welche in neueren Versionen besser gelöst sind.

Zumindest HC05/HC06 sowie dann als BLE Variante HC12 funktionieren mit den aktuellen XEs und Android ab V4.4.2 sicher.