Ich möchte eine BT-Kommunikation zwischen einem Android-Smartphone und einem Atmel µC realisieren.
Aktueller Versuchsaufbau: Ein HC05 Bluetoothmodul hängt über einen USB/TTL-Wandler am Rechner, auf selbigen läuft HTerm als Terminalprogramm. Starte ich auf dem Smartphone ein BT-Terminalprogramm aus dem Playstore so kann ich Daten hin- und herschicken.
Aus einem etwas umfangreicheren Code (https://www.youtube.com/watch?v=vesPd5WvykA ; Code ist in den Kommentaren verlinkt) und diesen Units http://www.pclviewer.com/android/ habe ich ein Testprojekt gebaut, bei dem auf einer Form ein Label liegt auf dem Text ausgegeben werden soll, der vorher vom PC über den HC05 gesendet und vom Smartphone über BT empfangen wurde. Ferner wird dieser Text direkt wieder retour geschickt und dann in HTerm angezeigt.
Unit und Form habe ich mal angehängt, hier auch nochmal zum direkten Lesen der Code:

markieren

Code:

unit BTUnit3;

interface

uses
  System.SysUtils, System.Types, System.UITypes, System.Classes, System.Variants,
  FMX.Types, FMX.Controls, FMX.Forms, FMX.Graphics, FMX.Dialogs, FMX.StdCtrls,
  Androidapi.JNI.BluetoothAdapter,
  Androidapi.JNI.JavaTypes,
  Androidapi.JNIBridge,
  Android.JNI.Toast,
  FMX.ListBox, FMX.Layouts, FMX.Memo, FMX.Edit, FMX.Objects, FMX.ListView.Types,
  FMX.ListView, System.Rtti, FMX.Grid, Data.Bind.GenData,
  System.Bindings.Outputs, Fmx.Bind.Editors, Data.Bind.EngExt,
  Fmx.Bind.DBEngExt, Data.Bind.Components, Data.Bind.ObjectScope;

type
  TForm1 = class(TForm)
    Timer1: TTimer;
    OutLabel2: TLabel;
    procedure FormShow(Sender: TObject);
    procedure Timer1Timer(Sender: TObject);
  private
    { Private-Deklarationen }
  public
    { Public-Deklarationen }
    targetMAC:string;                     // remote MAC address of the selected
    targetName: string;
    ostream:JOutputStream;
    istream:JInputstream;
    uid:JUUID;                            // UUID for SPP traffic
    Sock:JBluetoothSocket;
    Adapter:JBluetoothAdapter;            // Local BLUETOOTH adapter
    remoteDevice:JBluetoothDevice;
  end;

var
  Form1: TForm1;

implementation

{$R *.fmx}

procedure TForm1.FormShow(Sender: TObject);
var
  s:string;
  i:integer;
  list:TStringList;
begin
  list:=TStringList.Create;
  s:=checkBluetooth;                      // Make sure bluetooth is enabled
  Toast(s);
  if pos('disabled',s)<>0 then exit;

  // This is the well known SPP UUID for connection to a Bluetooth serial device
  uid:=TJUUID.JavaClass.fromString(stringtojstring('00001101-0000-1000-8000-00805F9B34FB'));

  list.Clear;
  list.AddStrings(getbonded);   // produce a list of bonded/paired devices

  for i := 0 to list.Count-1 do
  begin
   targetName := list[i].Split(['='])[0];
   targetMAC := list[i].Split(['='])[1];
   if targetName = 'HC05' then
    begin
     Adapter:=TJBluetoothAdapter.JavaClass.getDefaultAdapter;
     remoteDevice:=Adapter.getRemoteDevice(stringtojstring(targetMAC));
     Toast('Connecting to ' + targetName +' (' + targetMAC + ')');
     sock:=remoteDevice.createRfcommSocketToServiceRecord(UID);
     try sock.connect;
      except Toast('Could not create service record!');
     end;
     if not sock.isConnected then
      begin
       Toast('Failed to connect to '+targetMAC+'! Try again...');
       exit;
      end;
     Toast('Connected!');

     ostream:=sock.getOutputStream;          // record io streams
     istream:=sock.getInputStream;

     Application.ProcessMessages;
     sleep(200);

     timer1.Enabled:=True;
    exit;
    end;
   end;

end;


procedure TForm1.Timer1Timer(Sender: TObject);
var
  len,i:integer;
  s:string;
  buffer:TJavaArray<byte>;
begin
  len:=istream.available;
  if len=0 then exit;
  timer1.Enabled := false;
  buffer:=TJavaArray<byte>.create(len);
  istream.read(buffer,0,len);

  s:='';
  for i:=0 to len-1 do
  begin
   s := s + chr(buffer[i]);
   ostream.write(buffer[i]);
  end;
  OutLabel2.text := s;
  FillChar(buffer, SizeOf(buffer), 0);
  timer1.Enabled:=True;

end;

end.

Eigentlich ganz simpel: Es wird eine Devicelist erstellt, geprüft ob das HC05 drin vorkommt und dann direkt mit selbigen verbunden.
Über einen Timer - hier mit 0.5s Preset, Wert spielt aber letztlich keine Rolle - wird geprüft ob ein InputStream vorliegt,selbiger im Label ausgegeben und danach wieder zurück geschickt.
Generell funktioniert das, aber mit einer Merkwürdigkeit: Es wird immer erst nur ein Zeichen ausgegeben, dann jeweils Pakete von 9-11 Zeichen der übrigen Zeichen und zuletzt die noch überzähligen Zeichen. Die Pausen dazwischen entsprechen dem Timerpreset.
Beispiel: Gebe ich '0123456789abcdefghijklmnopqrstuvwxyz' in HTerm ein so ist die Ausgabe auf dem Label nacheinander
0
(0.5s Pause)
123456789
(0.5s Pause)
abcdefghij
(0.5s Pause)
klmnopqrs
(0.5s Pause)
tuvwxyz
Die zurückgesendeten Daten erscheinen in HTerm in genau den gleichen Paketen, allerdings in einer Zeile (also ohne CRLF), aber ebenso mit den Pausen dazwischen.
Hat irgend jemand eine Idee woraus dieses merkwürdige Verhalten resultiert? Vor allem merkwürdig dass generell zu Beginn nur ein Zeichen erscheint, in den Paketen danach dann aber die Länge (ohne nachvollziehbare Logik) zwischen 9 und 11 Zeichen schwankt? Wieso wird es überhaupt un Pakete zerlegt?
Ich stehe komplett auf dem Schlauch...

Danke!

Hallo toenne,

erstens würde ich auf aktuelle Dx10 / Rx10 upgraden, da funktionieren die Komponenten out-of-the Box,
und man muss nicht von Hand etwas basteln.
Ausserdem gibt es einige Stabilitäts-Verbesserungen die sich lohnen, also für Crossplatform
würde ich immer die aktuellste Version empfehlen.

Zweitens solte man im FormCreate keine langdauernden Schleifen bauen

markieren

Code:

for i := 0 to list.Count-1 do

da könnte dich das Phone mal direkt abwürgen und deine App killen.
Solche Dinge sollte man in Threads legen, z.B. mit TTask.Run(

Drittens würde ich versuchen im Empfänger auf ein EOL zu Testen, und mich nicht nur
auf das Verlassen was mit die RX-Routine gerade liefert.
Solche Datenpakete kommen oft zerhackt an, und erst zwischengespeichert und als Ganzes analysiert
machen die Sinn.
Ich versuche immer auf ein CRLF oder ähnliches zu Prüfen, und erst dann alle Teilstrings
zurückzugeben.

Rollo

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.

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

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.

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.

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.

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 .

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.

Zitat:

Aber bevor ich die Hardwareliste durchhangel würde mich interessieren, welche Hardware explizit bei XE8 versagen soll?

RAM-Speicher: defekt, zu langsam, Stecker locker, ...

UPDATE:
Übrigens, weil XE8 noch das Out-Of-Memory Problem hat und unmengen Speicher braucht. Das ist bei DX10 viel besser geworden.
Vielleicht nehmen deine 24/7 Programme niemals soviel Speicher das es bis zum defekten Bit kommt.

Solche Effekte hatte ich auch wirklich nur auf Rechnern mit Hardwarefehler, das mit VM kann ich
nur bestätigen, die Anschaffung von VmWare lohnt sich.

Rollo