two instance bluetooth transport

I have a board that could be populated with one of two slightly different
serial bluetooth modules.
They have different baudrate capabilities and some other differences. I have
a hardware switch that I can read to determine the populated module.

I would like to build just one image to support them both.
I think I can do something like:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Bluetooth\Transports\BuiltIn\1]
"Driver"="brf6300.dll"
"Flags"=dword:0
"Name"="COM1:"
"Baud"=dword:1c200
"ResetDelay"=dword:DAC
"Priority256"=dword:78

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Bluetooth\Transports\BuiltIn\2]
"Driver"="brf6300.dll"
"Flags"=dword:0
"Name"="COM1:"
"Baud"=dword:2580
"ResetDelay"=dword:200
"Priority256"=dword:78

I can detect at run time which module is populated but how do I control
which transport to bind too?
I would think there is some kind of API call I can make??

K
Mon Nov 27 22:33:11 CST 2006

Since the BuiltIn registry is enumrated by bthuniv,
$(_WINCEROOT)\PUBLIC\COMMON\OAK\DRIVERS\BLUETOOTH\TRANSPORTS\UNIV, you may
want to take a look at this driver.
One could use some way to let the BuiltIn\1 enuramted failed so taht the
bthuniv will go on to enuramte the next one.
for example to delete the "driver" registry value or make the
HCI_SetCallback or HCI_OpenConnection return FALSE and etc.
Instead of using the BuiltIn driver, you could also take a look at PnP type
activateion.
Whenever someone invoke the AdvertiseInterface with a GUID as parametere,
the BTHUNIV will enumrate the GUID under
[HKEY_LOCAL_MACHINE\Software\Microsoft\Bluetooth\Transports\PnP]
And then try to bind the corresponding transportation driver.


"skindiver" <xd@ttt.com> ¼¶¼g©ó¶l¥ó·s»D:ucp2GHnEHHA.4464@TK2MSFTNGP06.phx.gbl...
>I have a board that could be populated with one of two slightly different
>serial bluetooth modules.
> They have different baudrate capabilities and some other differences. I
> have a hardware switch that I can read to determine the populated module.
>
> I would like to build just one image to support them both.
> I think I can do something like:
>
> [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Bluetooth\Transports\BuiltIn\1]
> "Driver"="brf6300.dll"
> "Flags"=dword:0
> "Name"="COM1:"
> "Baud"=dword:1c200
> "ResetDelay"=dword:DAC
> "Priority256"=dword:78
>
> [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Bluetooth\Transports\BuiltIn\2]
> "Driver"="brf6300.dll"
> "Flags"=dword:0
> "Name"="COM1:"
> "Baud"=dword:2580
> "ResetDelay"=dword:200
> "Priority256"=dword:78
>
> I can detect at run time which module is populated but how do I control
> which transport to bind too?
> I would think there is some kind of API call I can make??
>
>
>
>
>
>

skindiver
Tue Nov 28 01:28:37 CST 2006

I was able to make it work by failing the HCI_OpenConnection which indeed
called the next.
I traced through the code and came up with the same solution you suggested

Thanks!

"K. S. Huang" <ksh_AT_bsquare_DOT_com> wrote in message
news:uW5g4YqEHHA.3768@TK2MSFTNGP06.phx.gbl...
> Since the BuiltIn registry is enumrated by bthuniv,
> $(_WINCEROOT)\PUBLIC\COMMON\OAK\DRIVERS\BLUETOOTH\TRANSPORTS\UNIV, you may
> want to take a look at this driver.
> One could use some way to let the BuiltIn\1 enuramted failed so taht the
> bthuniv will go on to enuramte the next one.
> for example to delete the "driver" registry value or make the
> HCI_SetCallback or HCI_OpenConnection return FALSE and etc.
> Instead of using the BuiltIn driver, you could also take a look at PnP
> type activateion.
> Whenever someone invoke the AdvertiseInterface with a GUID as parametere,
> the BTHUNIV will enumrate the GUID under
> [HKEY_LOCAL_MACHINE\Software\Microsoft\Bluetooth\Transports\PnP]
> And then try to bind the corresponding transportation driver.
>
>
> "skindiver" <xd@ttt.com>
> ¼¶¼g©ó¶l¥ó·s»D:ucp2GHnEHHA.4464@TK2MSFTNGP06.phx.gbl...
>>I have a board that could be populated with one of two slightly different
>>serial bluetooth modules.
>> They have different baudrate capabilities and some other differences. I
>> have a hardware switch that I can read to determine the populated module.
>>
>> I would like to build just one image to support them both.
>> I think I can do something like:
>>
>> [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Bluetooth\Transports\BuiltIn\1]
>> "Driver"="brf6300.dll"
>> "Flags"=dword:0
>> "Name"="COM1:"
>> "Baud"=dword:1c200
>> "ResetDelay"=dword:DAC
>> "Priority256"=dword:78
>>
>> [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Bluetooth\Transports\BuiltIn\2]
>> "Driver"="brf6300.dll"
>> "Flags"=dword:0
>> "Name"="COM1:"
>> "Baud"=dword:2580
>> "ResetDelay"=dword:200
>> "Priority256"=dword:78
>>
>> I can detect at run time which module is populated but how do I control
>> which transport to bind too?
>> I would think there is some kind of API call I can make??
>>
>>
>>
>>
>>
>>
>
>