2009-05-25 5 views
4

Je dois me connecter à un périphérique Bluetooth via un port COM virtuel créé dans Windows. C'est facile quand le port a déjà été créé pendant la procédure d'appariement manuel. Mais je voudrais que mon application soulage un utilisateur de l'appariement manuel d'un appareil. Je voudrais présenter tous les périphériques de la gamme, permettre à l'utilisateur d'en choisir un, puis créer un port COM virtuel connecté avec le périphérique sélectionné. Je n'essaie pas d'éviter la procédure d'appariement elle-même, mais je voudrais plutôt l'invoquer par mon application.Accès au port COM virtuel Bluetooth sous Windows sans appariement manuel

J'ai commencé à me familiariser avec Microsoft Bluetooth API. Et puis quelques doutes ont surgi. Je me demandais ce qui se passerait si un utilisateur utilisait une pile Bluetooth différente (que celle de Microsoft)? L'API de Microsoft est-elle la véritable API Bluetooth, qui doit être implémentée par n'importe quel autre fournisseur de pile Bluetooth? Ou plutôt chaque fournisseur a sa propre API, et le Microsoft est seulement l'un des nombreux autres?

Répondre

2

Merci à tous pour vos commentaires précieux. J'aimerais résumer ce que j'ai trouvé jusqu'à présent. L'API Microsoft Bluetooth n'est pas l'API du système d'exploitation. Demande écrite contre elle ne coopèrera pas correctement avec un autre Bluetooth stack. Il semble que les applications destinées à coopérer avec plusieurs piles doivent fournir une couche d'abstraction de pile et empiler du code spécifique pour chacune d'elles. L'autre solution consiste à permettre à l'utilisateur de coupler manuellement le périphérique Bluetooth, ce qui crée éventuellement un périphérique virtuel dans le système d'exploitation (par exemple, port COM). Ensuite, l'application peut utiliser l'interface standard d'un tel appareil.

+0

Merci de partager vos découvertes. – TeamWild

1

Je ne peux pas parler pour l'API Microsoft Bluetooth, mais il y a multiple Bluetooth stacks disponible pour la plate-forme PC (encore plus pour les appareils mobiles). L'API sous-jacente est définie par le Bluetooth Core Spec et toutes les piles doivent pouvoir interagir, en fait, elles doivent être interopérables ou ne peuvent pas utiliser le nom et le logo Bluetooth. En ce qui concerne l'appariement, vous aurez du mal à faire en sorte que les appareils soient appariés s'ils ont une sécurité par défaut, ce qui nécessite un code PIN. Les choses pourraient être plus simples dans le futur (proche), puisque la norme Bluetooth a introduit un nouveau modèle de sécurité, secure simple pairing, qui a un mode 'fonctionne' qui ne requiert aucun code PIN. C'est encore plus fort que la sécurité actuelle, sauf contre les attaques de l'Homme au milieu. Cependant, il pourrait être un peu de temps avant de voir les puces avec cette fonctionnalité dans les PC.

+0

Merci pour la réponse. Pour être plus précis, je n'essaie pas du tout d'éviter l'appariement. En fait, je voudrais commencer à appairer la procédure de mon application si l'appareil n'a pas déjà été apparié. Je voudrais faire cela indépendamment de la pile installée (si possible) et c'est la raison pour laquelle j'ai demandé à propos de l'API Bluetooth disponible sur Windows. Si je pouvais utiliser l'API indépendamment de la pile sous-jacente, ce serait génial. Si toutes les piles fournissaient leurs propres API, je devrais programmer chacune d'elles ... –

1

Si vous pouvez changer en utilisant .NET: -/je peux recommander notre bibliothèque 32feet.NET. Pour un appariement explicite, il y a BluetoothSecurity.PairDevice. Nous pouvons également créer le port virtuel pour vous, par exemple:

BluetoothClient cli = new BluetoothClient(); 
    BluetoothDeviceInfo[] list = cli.DiscoverDevices(); 
    BluetoothDeviceInfo selected = GetUserToSelectOne(list); 
    BluetoothSecurity.PairDevice(selected, pin); 
    // Ask Win32 to create a virtual serial port 
    selected.SetServiceState(BluetoothService.SerialPort); 

Cependant, je n'aime vraiment pas de ports série virtuels, donc je suggère toujours que les gens utilisent une connexion sockets normale en utilisant notre classe BluetoothClient, il se chargera automatiquement une demande d'appariement si nécessaire. Sur Win32, nous supportons les piles de Microsoft, Widcomm/Broadcom et BlueSoleil. Sur Widcomm il n'y a encore aucun support pour SetServiceState, et leur API n'a pas de support pour répondre à l'appariement demandes. BlueSoleil devrait supporter les deux.

Un bref guide de l'utilisateur est au 32feet.NET — User’s Guide, et toute la documentation de classe est disponible sur le site principal http://32feet.net, la documentation de Widcomm est seulement dans notre code repository pour le moment.

+0

Merci pour les astuces. Malheureusement, je dois supporter plus de piles que deux gérées par votre bibliothèque ... Mais, de toute façon, vous avez indirectement répondu à ma question sur les API Bluetooth, fournies par différentes piles Bluetooth - elles ne sont pas interchangeables, et chacune doit être traitée séparément . –

Questions connexes