Bluetooth Kommunikation - Abfrage Trennung

Alle Fragen zur Netzwerkkommunikation
Benutzeravatar
af0815
Lazarusforum e. V.
Beiträge: 6198
Registriert: So 7. Jan 2007, 10:20
OS, Lazarus, FPC: FPC fixes Lazarus fixes per fpcupdeluxe (win,linux,raspi)
CPU-Target: 32Bit (64Bit)
Wohnort: Burgenland
Kontaktdaten:

Re: Bluetooth Kommunikation - Abfrage Trennung

Beitrag von af0815 »

Ich arbeite in einem anderen Mode, siehe auch meinen Post am Anfang

Code: Alles auswählen

s := fpsocket(AF_BLUETOOTH, SOCK_STREAM, BTPROTO_RFCOMM);
Der hängt trotzdem beim fprecv ewig, wenn ich nicht vorher mit fpIOCtl abfrage ob Daten da sind. Ich nehme an, das beim Protokoll BTPROTO_RFCOMM einiges anders ist.
Das was du vorschlägst, habe ich am Anfang geglaubt das es die Lösung ist. Nur hat mich die Wirklichkeit anderes gelehrt. Aktuell muss man echt was hinausschreiben um einen Fehler zu bekommen, aber erst dann wenn das System den Bluetoothstack schon abgeräumt hat. Vorher liefert selbst der Schreibbefehl obwohl das Device nicht da ist, brav positive Rückmeldungen.
Blöd kann man ruhig sein, nur zu Helfen muss man sich wissen (oder nachsehen in LazInfos/LazSnippets).

sstvmaster
Beiträge: 575
Registriert: Sa 22. Okt 2016, 23:12
OS, Lazarus, FPC: W10, L 2.2.6
CPU-Target: 32+64bit
Wohnort: Dresden

Re: Bluetooth Kommunikation - Abfrage Trennung

Beitrag von sstvmaster »

Hier gibt es auch was zu deinem Thema, bezieht sich hier zwar auf Windows:

https://www.delphipraxis.net/154412-blu ... 2-api.html

Speziell siehe Beitrag von Astat.
LG Maik

Windows 10,
- Lazarus 2.2.6 (stable) + fpc 3.2.2 (stable)
- Lazarus 2.2.7 (fixes) + fpc 3.3.1 (main/trunk)

Benutzeravatar
af0815
Lazarusforum e. V.
Beiträge: 6198
Registriert: So 7. Jan 2007, 10:20
OS, Lazarus, FPC: FPC fixes Lazarus fixes per fpcupdeluxe (win,linux,raspi)
CPU-Target: 32Bit (64Bit)
Wohnort: Burgenland
Kontaktdaten:

Re: Bluetooth Kommunikation - Abfrage Trennung

Beitrag von af0815 »

sstvmaster hat geschrieben:
Do 8. Okt 2020, 19:40
Hier gibt es auch was zu deinem Thema, bezieht sich hier zwar auf Windows:

https://www.delphipraxis.net/154412-blu ... 2-api.html

Speziell siehe Beitrag von Astat.
ich kann nicht in fprecv gehen, da das sonst blocking ist und der Thread komplett blockiert. Ich habe dann absolut keine Kontrolle. genaugenommen ist im Code da IOCtl an der falschen Stelle, es gehört vor dem Receive.

Was ich zumindest mal mitnehmen kann, das es scheinbar auch mit den Socket unter Windows gehen könnte (Wenn es unter Linux stabil läuft). Bin draufgekommen, das auch Drucker sich scheinbar damit ansprechen lassen. Zumindest habe ich meine Spezialdrucker hier schon mal in der Auflistung gesehen.

Ein bischen was probieren kann man mit dem inoffiziellen Fork von hier: https://github.com/afriess/bluetoothlaz unter source/examples/rfcomm/reader
Der Code ist zu gut um in der CCR zu verstauben :-) Wenn es besser läuft kommen noch mehr Beispiele und Code dort hinzu.
Blöd kann man ruhig sein, nur zu Helfen muss man sich wissen (oder nachsehen in LazInfos/LazSnippets).

Sieben
Beiträge: 202
Registriert: Mo 24. Aug 2020, 14:16
OS, Lazarus, FPC: Ubuntu Xenial 32, Lazarus 2.2.0, FPC 3.2.2
CPU-Target: i386

Re: Bluetooth Kommunikation - Abfrage Trennung

Beitrag von Sieben »

ich kann nicht in fprecv gehen, da das sonst blocking ist und der Thread komplett blockiert.
Vielleicht wäre dann ja der asynchrone Ansatz wie in dem von Theo verlinkten Buch unter 2.5.1 ff der richtige...?

Benutzeravatar
af0815
Lazarusforum e. V.
Beiträge: 6198
Registriert: So 7. Jan 2007, 10:20
OS, Lazarus, FPC: FPC fixes Lazarus fixes per fpcupdeluxe (win,linux,raspi)
CPU-Target: 32Bit (64Bit)
Wohnort: Burgenland
Kontaktdaten:

Re: Bluetooth Kommunikation - Abfrage Trennung

Beitrag von af0815 »

2.5.1 befasst sich speziell mit dem Discovery im BT Bereich. Das geht ja ohne Probleme. Ich bekomme die Devilistings genau nach dem was ich gesucht habe, entspricht dem 'select' aus dem Buch.

Alles nicht das Problem. Das Problem entsteht dort, wo ich von der 'Buch' Theorie in die Praxis gehe und die Geräte so verwende wie sie verwendet werden. Nicht wie man theoretisch die Kommunikation betreibt und auch geht, solange die Praxis nicht zuschlägt.

Nochmals, ich habe eine schöne stabile Kommunikation zwischen PC und BT-Gerät, die ich beliebig hoch und runterfahren kann. Null Problemo.

NUR: Wenn der Akku ausgeht, der Benutzer mal weiter weggeht,.... So stirbt die Kommunikation und der ganze BT-Stack muss neu erzeugt werden. Kratzt mich auch nicht, ABER ich muss es erst erkennen ohne das der ganze Thread/App damit stirbt. Programm schließen und öffnen IST KEINE OPTION.

Ausprobierter weise ist die Situation unter Windows tw. noch schlimmer :-) Der gestorbene virtuelle Serial-Port nimmt das Programm fast todsicher mit (aktuell).
Blöd kann man ruhig sein, nur zu Helfen muss man sich wissen (oder nachsehen in LazInfos/LazSnippets).

Sieben
Beiträge: 202
Registriert: Mo 24. Aug 2020, 14:16
OS, Lazarus, FPC: Ubuntu Xenial 32, Lazarus 2.2.0, FPC 3.2.2
CPU-Target: i386

Re: Bluetooth Kommunikation - Abfrage Trennung

Beitrag von Sieben »

Ich meinte speziell diesen Absatz:
In the communications routines described so far, there is usually some sort of waiting involved. During this time, the controlling thread blocks and can’t do anything else, such as respond to user input or display progress information. To avoid these pitfalls of synchronous programming, it is possible to use multiple threads of control, with one thread dedicated to each task that requires some waiting. That can get quite hairy and complicated, though, so instead we’ll turn to using asynchronous techniques as asolution. The first step in asynchronous programming is to switch the sockets to non-blockingmode, so that all the operations that would block (wait) beforehand return immediately instead. The idea is "Don’t wait for something to happen. Just get it started and we’ll figure it out later".
der mir genau das zu beschreiben schien, worunter du da offenbar zu leiden hast. Anschließend geht es dann zwar erst mal mit device listings weiter, aber vielleicht lohnt es sich, da noch ein bisschen weiter runter zu scrollen. Allerdings habe ich von dem Kram wirklich keine Ahnung, es war auch reiner Zufall, dass ich gerade da mal kurz reingelesen habe...

Antworten