Infineon hardware "SingleStone PBA31307"

Bluez-devel Götz Issel 1 participant 1 message Feb 22, 2006 Bluetooth drivers

Share & tools

Götz Issel

author

2006-02-22 10:14 UTC #0 lore raw

Re: Infineon hardware "SingleStone PBA31307" (Marcel Holtmann)

Hi Marcel,
I got the hardware to work simply by using the manufacturer "any" with the hciattach tool. Problem before was hardware based.

Now I will try to implement SAP and will probably come back to you on some upcoming problems.

Goetz

Send Bluez-devel mailing list submissions to
[email protected]

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/bluez-devel
or, via email, send a message with subject or body 'help' to
[email protected]

You can reach the person managing the list at
[email protected]

When replying, please edit your Subject line so it is more specific than "Re: Contents of Bluez-devel digest..."

Today's Topics:

1. Re: [DBUS PATCH] BlueZ D-Bus redesign (Johan Hedberg)
2. Re: [DBUS PATCH] BlueZ D-Bus redesign (Marcel Holtmann)
3. Deprecating some hcid.conf options (Marcel Holtmann)
4. Re: Can't discover device (Marcel Holtmann)
5. Re: [DBUS PATCH] BlueZ D-Bus redesign (Claudio Takahasi)
6. Re: [DBUS PATCH] BlueZ D-Bus redesign (Marcel Holtmann)
7. Re: [DBUS PATCH] BlueZ D-Bus redesign (Claudio Takahasi)
8. Re: [DBUS PATCH] BlueZ D-Bus redesign (Marcel Holtmann)
9. Infineon hardware "SingleStone PBA31307" (=?windows-1252?Q?G=F6tz_Issel?=)
10. Re: Infineon hardware "SingleStone PBA31307" (Marcel Holtmann)
11. Re: Re: Developing Broadcom driver support (Brad Midgley)
12. [DBUS PATCH] scan mode (Claudio Takahasi)

--__--__--

Message: 1
Date: Mon, 13 Feb 2006 09:30:21 +0200
From: Johan Hedberg <[email protected]>
To: [email protected]
Subject: Re: [Bluez-devel] [DBUS PATCH] BlueZ D-Bus redesign
Reply-To: [email protected]

Hi Marcel,

Quoted 7 lines · Marcel Holtmann

Quoted 3 lines
Btw Marcel, the API document should probably be added to CVS or published on this list since AFAIK currently you, I, Claudio and Eduardo are the only ones in posession of it.
Actually I wanted to wait until it is in a better shape, but since they mentioned it several times on the mailing list, we should make it public anyway. Please do a last review and then I commit it to the CVS.

I don't have currently any big issues with it. One thing we may want to add to it in the future is descriptions of the different types of errors that the methods can return.

Quoted 7 lines

Quoted 5 lines
Quoted 2 lines
Should we split the Manager interface and the Device interface into two separate files?
I think that would make sense. That way you could also define clearer interfaces between them in the code (function wise).
Any proposals on how we gonna do the split?

I see you've already made the split in CVS, and it looks ok. I'd probably split the dbus.h file also into separate files (one for each .c file). At some point we might also need a "dbus-common.c" file for common helper functions (e.g. the client lifetime tracking may be one thing that could go into it).

Johan

--__--__--

Message: 2
Subject: Re: [Bluez-devel] [DBUS PATCH] BlueZ D-Bus redesign
From: Marcel Holtmann <[email protected]>
To: [email protected]
Date: Mon, 13 Feb 2006 09:03:22 +0100
Reply-To: [email protected]

Hi Johan,

Quoted 11 lines

Quoted 7 lines
Quoted 3 lines
Btw Marcel, the API document should probably be added to CVS or published on this list since AFAIK currently you, I, Claudio and Eduardo are the only ones in posession of it.
Actually I wanted to wait until it is in a better shape, but since they mentioned it several times on the mailing list, we should make it public anyway. Please do a last review and then I commit it to the CVS.
I don't have currently any big issues with it. One thing we may want to add to it in the future is descriptions of the different types of errors that the methods can return.

and I am thinking of re-designing the errors. Once you deal with languages like C# or Java, you might wanna have clear exceptions.

However we need an updated dbus-test script. Can someone please address this.

Quoted 6 lines

Quoted 6 lines
Quoted 5 lines
Quoted 2 lines
Should we split the Manager interface and the Device interface into two separate files?
I think that would make sense. That way you could also define clearer interfaces between them in the code (function wise).

Quoted 7 lines

Quoted 1 line
Any proposals on how we gonna do the split?
I see you've already made the split in CVS, and it looks ok. I'd probably split the dbus.h file also into separate files (one for each .c file). At some point we might also need a "dbus-common.c" file for common helper functions (e.g. the client lifetime tracking may be one thing that could go into it).

The split is not perfect, because we have overlaps for that I had to introduce some ugly hacks to get them working. However the current split makes it a little bit easier to work with the code. I also introduced some generic device handling. In the end this layer should take care of the inquiry cache and the connection tracking.

The Manager part should work now as expected, but I had some small race condition with the BD_ADDR. So I think we send the DeviceAdded signal a little bit too soon. I worked around it with re-reading the address if it hasn't been set correctly.

Does anybody know how to receive D-Bus signals within C#? I started to write some bluetooth-sharp bindings for the BlueZ D-Bus API, but I can't find any documentation on how to deal with the signals. The methods stuff is working perfect.

Regards

Marcel

--__--__--

Message: 3
From: Marcel Holtmann <[email protected]>
To: [email protected]
Date: Mon, 13 Feb 2006 09:26:19 +0100
Subject: [Bluez-devel] Deprecating some hcid.conf options
Reply-To: [email protected]

Hi,

while working on the D-Bus interface, I came along some unneeded complex functionality inside hcid and its configuration options. The questions is now what options are really used and what haven't been changed by anyone.

Does someone uses hcid with autoinit disabled?

What about the security and pairing option? What do we really need?

The iscan and pscan will combined into a new mode option.

Changing the pkt_type is useless and will be removed no matter what.

The auth and encrypt options will also be removed, because we don't support security mode 3 anymore.

Do we need link policy setting or should hcid calculate the best setting from the supported features?

Regards

Marcel

--__--__--

Message: 4
Subject: Re: [Bluez-devel] Can't discover device
From: Marcel Holtmann <[email protected]>
To: [email protected]
Date: Mon, 13 Feb 2006 09:30:36 +0100
Reply-To: [email protected]

Hi Arpit,

Quoted 2 lines

That fixed the problem. But its funny, coz everytime I restart the computer I have to run piscan.Hmm.

I've seen this race conditions with some dongles, but not with all of them and it seems the HCI flow control is broken on these. However I never fully investigated why this happens.

Regards

Marcel

--__--__--

Message: 5
Date: Mon, 13 Feb 2006 10:44:01 -0200
From: Claudio Takahasi <[email protected]>
To: [email protected]
Subject: Re: [Bluez-devel] [DBUS PATCH] BlueZ D-Bus redesign
Reply-To: [email protected]

Hi,

Quoted 5 lines · Johan Hedberg

Hi Marcel,
Quoted 2 lines · Marcel Holtmann
Quoted 2 lines
Btw Marcel, the API document should probably be added to CVS or published on this list since AFAIK currently you, I, Claudio and Edua=

rdo

Quoted 4 lines

Quoted 4 lines
Quoted 1 line
are the only ones in posession of it.
Actually I wanted to wait until it is in a better shape, but since they mentioned it several times on the mailing list, we should make it publi=

Quoted 7 lines

Quoted 1 line
anyway. Please do a last review and then I commit it to the CVS.
I don't have currently any big issues with it. One thing we may want to add to it in the future is descriptions of the different types of errors that the methods can return.
Quoted 1 line
Quoted 1 line
Quoted 1 line
Should we split the Manager interface and the Device interface into=

two

Quoted 5 lines

Quoted 5 lines
Quoted 4 lines
Quoted 1 line
separate files?
I think that would make sense. That way you could also define clearer interfaces between them in the code (function wise).

Quoted 7 lines

Quoted 1 line
Any proposals on how we gonna do the split?
I see you've already made the split in CVS, and it looks ok. I'd probably split the dbus.h file also into separate files (one for each .c file). At some point we might also need a "dbus-common.c" file for common helper functions (e.g. the client lifetime tracking may be one thing that could go into it).

[Claudio Takahasi]
1. The functions get_device_name(hcitool.c) and get_peer_name(dbus-device.c) does the same thing. We should move it to a common file.
2. The header file dbus.h intends to be a file used by D-Bus client developers. There are some constants, type definition and function prototypes that we could move to internal header file:
"dbus-internal.h" or split into separeted file(one for each .c file - according with Johan's suggestion).

Regards,
Claudio.

Quoted 6 lines

Johan
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi=

les

Quoted 3 lines

for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D103432&bid=3D230486&dat=

=3D121642

Quoted 5 lines

_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

--
---------------------------------------------------------
Claudio Takahasi
Instituto Nokia de Tecnologia - INdT

--__--__--

Message: 6
Subject: Re: [Bluez-devel] [DBUS PATCH] BlueZ D-Bus redesign
From: Marcel Holtmann <[email protected]>
To: [email protected]
Date: Mon, 13 Feb 2006 13:51:42 +0100
Reply-To: [email protected]

Hi Claudio,

Quoted 3 lines

1. The functions get_device_name(hcitool.c) and get_peer_name(dbus-device.c) does the same thing. We should move it to a common file.

not right now. The code duplication is that small that I have no problems with it and creating another internal library for it, is way too much overhead.

Quoted 5 lines

2. The header file dbus.h intends to be a file used by D-Bus client developers. There are some constants, type definition and function prototypes that we could move to internal header file:
"dbus-internal.h" or split into separeted file(one for each .c file - according with Johan's suggestion).

I have no favor in any direction at the moment, but I don't think that we need a global dbus.h file for other C clients using the D-Bus interface. My understanding is that no client should depend on any code or headers provided by bluez-libs or bluez-utils. We will make a clean split with the D-Bus API. If this means that every client has some kind of duplication, so will be it.

Regards

Marcel

--__--__--

Message: 7
Date: Mon, 13 Feb 2006 11:37:31 -0200
From: Claudio Takahasi <[email protected]>
To: [email protected]
Subject: Re: [Bluez-devel] [DBUS PATCH] BlueZ D-Bus redesign
Reply-To: [email protected]

Hi guys,

Just to avoid code conflicts, I will start implement the discoverable/connectable functions. Eduardo told me that he can fix the dbus-test python script.

Regards,
Claudio.

Quoted 25 lines · Marcel Holtmann

Hi Claudio,
Quoted 3 lines
1. The functions get_device_name(hcitool.c) and get_peer_name(dbus-device.c) does the same thing. We should move it to a common file.
not right now. The code duplication is that small that I have no problems with it and creating another internal library for it, is way too much overhead.
Quoted 5 lines
2. The header file dbus.h intends to be a file used by D-Bus client developers. There are some constants, type definition and function prototypes that we could move to internal header file:
"dbus-internal.h" or split into separeted file(one for each .c file - according with Johan's suggestion).
I have no favor in any direction at the moment, but I don't think that we need a global dbus.h file for other C clients using the D-Bus interface. My understanding is that no client should depend on any code or headers provided by bluez-libs or bluez-utils. We will make a clean split with the D-Bus API. If this means that every client has some kind of duplication, so will be it.
Regards

Quoted 7 lines

Marcel
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi=

les

Quoted 3 lines

for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D103432&bid=3D230486&dat=

=3D121642

Quoted 5 lines

_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

--
---------------------------------------------------------
Claudio Takahasi
Instituto Nokia de Tecnologia - INdT

--__--__--

Message: 8
Subject: Re: [Bluez-devel] [DBUS PATCH] BlueZ D-Bus redesign
From: Marcel Holtmann <[email protected]>
To: [email protected]
Date: Mon, 13 Feb 2006 15:16:35 +0100
Reply-To: [email protected]

Hi Claudio,

Quoted 2 lines

Just to avoid code conflicts, I will start implement the discoverable/connectable functions.

go ahead. I have some other stuff to finish first.

Quoted 2 lines

Eduardo told me that he can fix
the dbus-test python script.

That would be great.

Regards

Marcel

--__--__--

Message: 9
Date: Mon, 13 Feb 2006 17:03:07 +0100
From: =?windows-1252?Q?G=F6tz_Issel?= <[email protected]>
To: [email protected]
Subject: [Bluez-devel] Infineon hardware "SingleStone PBA31307"
Reply-To: [email protected]

Hi all,

I am trying to get the Infineon bluetooth hardware to work. Exact name
is: PBA31307 SingleStone. It is a bluetooth module with a serial interface. See link:
http://www.infineon.com/cgi-bin/ifx/portal/ep/channelView.do?channelId=-65244&channelPage=%2Fep%2Fchannel%2FproductOverview.jsp&pageTypeId=17099

I am using the 2.4.19 kernel with bluez-libs-2.25 and bluez-utils-2.25.

Maybe someone can aggree or correct me on the assumption that

1. I need to add the initialisation sequence for this hardware to bluez-utils-2.25/tools/hciattach.c ?

2. and then use i.e. "hciattach -s 115200 /dev/ttyS2 infineon" in the shell followed by "hciconfig hci0 up" etc ?

The problems will arise with the correct initialisation I guess. I do have a datasheet with a suggested sequence which is:

--------------------------------------------------------

# Initialisation sequence on PMB8761 v7.50 for Singlestone # Switch to manufacturer mode

send: Infineon_Manufacturer_Mode
Mode_Switch: 0x01
Reset: 0x00

received: Command_Complete
Num_HCI_Command_Packets: 0x01
Command_Opcode: Infineon_Manufacturer_Mode (0xfc11)
Status: Command succeeded (0x00)

send: Infineon_Write_Clock_Data
Clock_Control1: 0x000088
Clock_Control2: 0x641415
Freq_Dev: 0xc8
RF_Boost: 0x3c
Startup_Control: 0x02
Sascal: 0x00
# UART rate is 115200 bit/s
Sabaud: 0x70
Multiple_Clock: 0x000000b4b405
LPM_Drift: 0x00

received: Command_Status
Status: Command succeeded (0x00)
Num_HCI_Command_Packets: 0x01
Command_Opcode: 0xfc1e

--------------------------------------------------------

and so on. Question: what about the longer hex numbers, i.e.
Command_Opcode: Infineon_Manufacturer_Mode (0xfc11) ? I figured out the 2 digit hex numbers, but how to send the longer ones as hci command?

Any help appreciated.

Greetings from Germany,

goetz

--__--__--

Message: 10
Subject: Re: [Bluez-devel] Infineon hardware "SingleStone PBA31307"
From: Marcel Holtmann <[email protected]>
To: [email protected]
Date: Mon, 13 Feb 2006 17:24:37 +0100
Reply-To: [email protected]

Hi Goetz,

Quoted 7 lines

I am trying to get the Infineon bluetooth hardware to work. Exact name
is: PBA31307 SingleStone. It is a bluetooth module with a serial interface. See link:
http://www.infineon.com/cgi-bin/ifx/portal/ep/channelView.do?channelId=-65244&channelPage=%2Fep%2Fchannel%2FproductOverview.jsp&pageTypeId=17099
I am using the 2.4.19 kernel with bluez-libs-2.25 and bluez-utils-2.25.

Quoted 7 lines

Maybe someone can aggree or correct me on the assumption that
1. I need to add the initialisation sequence for this hardware to bluez-utils-2.25/tools/hciattach.c ?
2. and then use i.e. "hciattach -s 115200 /dev/ttyS2 infineon" in the shell followed by "hciconfig hci0 up" etc ?

that is basically what is needed to make this device work.

Quoted 34 lines

The problems will arise with the correct initialisation I guess. I do have a datasheet with a suggested sequence which is:
--------------------------------------------------------
# Initialisation sequence on PMB8761 v7.50 for Singlestone # Switch to manufacturer mode
send: Infineon_Manufacturer_Mode
Mode_Switch: 0x01
Reset: 0x00
received: Command_Complete
Num_HCI_Command_Packets: 0x01
Command_Opcode: Infineon_Manufacturer_Mode (0xfc11)
Status: Command succeeded (0x00)
send: Infineon_Write_Clock_Data
Clock_Control1: 0x000088
Clock_Control2: 0x641415
Freq_Dev: 0xc8
RF_Boost: 0x3c
Startup_Control: 0x02
Sascal: 0x00
# UART rate is 115200 bit/s
Sabaud: 0x70
Multiple_Clock: 0x000000b4b405
LPM_Drift: 0x00
received: Command_Status
Status: Command succeeded (0x00)
Num_HCI_Command_Packets: 0x01
Command_Opcode: 0xfc1e

Quoted 5 lines

--------------------------------------------------------
and so on. Question: what about the longer hex numbers, i.e.
Command_Opcode: Infineon_Manufacturer_Mode (0xfc11) ? I figured out the 2 digit hex numbers, but how to send the longer ones as hci command?

Looks like the chip is talking HCI even when it is not initialized. The correct byte streams depends on the on the structure of these vendor specific commands. Send me the datasheet and we see how it should look like.

Regards

Marcel

--__--__--

Message: 11
Date: Mon, 13 Feb 2006 10:27:16 -0700
From: Brad Midgley <[email protected]>
To: [email protected]
Subject: Re: [Bluez-devel] Re: Developing Broadcom driver support
Reply-To: [email protected]

Keith

Did you try something similar to Whoopie's patch that changes both mtu and sco_cnt?

http://bluetooth-alsa.sourceforge.net/sco-mtu.patch

Brad

--__--__--

Message: 12
Date: Mon, 13 Feb 2006 15:50:40 -0200
From: Claudio Takahasi <[email protected]>
To: [email protected]
Subject: [Bluez-devel] [DBUS PATCH] scan mode
Reply-To: [email protected]

------=_Part_12528_9485329.1139853040920
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hi guys,

This patch add/fix the following services:
1. Changed GetMode/SetMode arguments to string, instead of use byte
2. Added IsConnectable
3. Added IsDiscoverable

Next action:
- Discoverable timout functions.

Regards,
Claudio
--
---------------------------------------------------------
Claudio Takahasi
Instituto Nokia de Tecnologia - INdT

------=_Part_12528_9485329.1139853040920
Content-Type: text/x-patch; name=scan04.patch; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Attachment-Id: f_ejmwiip7
Content-Disposition: attachment; filename="scan04.patch"

hcid/dbus.h +6 -5

@@ -206,17 +206,18 @@
 #define DEV_SIG_DISCOVER_COMPLETE	"DiscoverComplete"
 #define DEV_SIG_DISCOVER_RESULT		"DiscoverResult"
 
-/* FIXME: Change to string
+/*
  * Scanning modes, used by DEV_SET_MODE
  * off: remote devices are not allowed to find or connect to this device
  * connectable: remote devices are allowed to connect, but they are not
  *              allowed to find it.
  * discoverable: remote devices are allowed to connect and find this device
+ * unknown: reserved to not allowed/future modes
  */
-#define MODE_OFF		0x00	
-#define MODE_CONNECTABLE	0x01	
-#define MODE_DISCOVERABLE	0x02	
-
+#define MODE_OFF		"off"
+#define MODE_CONNECTABLE	"connectable"
+#define MODE_DISCOVERABLE	"discoverable"
+#define MODE_UNKNOWN		"unknown"
 
 /* BLUEZ_DBUS_ERROR 
  * EFailed error messages signature is : su

hcid/dbus-device.c +46 ~~-24~~

125 lines not on this page · raw message

hcid/dbus.c +2 -2

@@ -1054,7 +1054,7 @@
 	struct hci_request rq;
 	int id;
 	int dd = -1;
-	uint8_t scan_mode;
+	const char *scan_mode;
 
 	baswap(&tmp, local); local_addr = batostr(&tmp);
 	id = hci_devid(local_addr);

@@ -1123,7 +1123,7 @@
 	}
 
 	dbus_message_append_args(message,
-					DBUS_TYPE_BYTE, &scan_mode,
+					DBUS_TYPE_STRING, &scan_mode,
 					DBUS_TYPE_INVALID);
 
 	if (dbus_connection_send(connection, message, NULL) == FALSE) {

------=_Part_12528_9485329.1139853040920--

--__--__--

_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

End of Bluez-devel Digest