Who am I?
Konstantine Voytenko
BluSPAN project coordinator
Fishnest Ltd.
bluspan@gmail.com
Calendar
Recently...
- Symbian, Descriptors and Unicode
- PAN service advertise
- Lost in the dark
- Reset S60-3rd emulator defaults
- Attempt to create a CSY module
- Serial protocol modules
- Symbian Networking interface
- Carbide code bookmarks
- Accomplish SSL connection from S60v3
- Insert Multiselection list into GUI
- Get project from CVS to Carbide C++
- Switching Avkon Views
- Code implementation for GUI
- Assembling GUI set reflecting future BluSPAN functionality
- Bluetooth Driver for S60 SDK
- Difference between the pointers in Carbide c++ and C++
- BlueZ port using P.I.P.S. environment
- Obtaining Carbide license
- Port of PAND (BlueZ) system
- The Battle for BlueZ
Categories
Open Source Bluetooth PAN's Forum Nokia Blog
Port of PAND (BlueZ) system
Carbider | 26 September, 2007 12:44
To build a system's skeleton we decided to construct all the GUIs which will be presented at final BluSPAN program. But after 20 days have passed, my Carbide License was expired and I could not use the UI designer. While the license gets outlined (via https://pro.forum.nokia.com/)
I decided to look at the existing PAN and BNEP sources. The first I found was “BlueZ” linux bluetooth protocol stack (http://www.bluez.org/).
It is written on C language, so I supposed it will be a good attempt to port it into Carbide C++ as Symbian application.
I’ve downloaded two archives.
“bluez-libs-3.18.tar.gz” and “bluez-utils-3.18.tar.gz”
As Carbide C++ project base I chose Bluetooth Chat example that still available with expired license. I took Chat example, because I thought it has all headers and libraries included to work with BT.
To do that, I created new directory for future workspace, and copied “S60ExChat” folder there.
Then opened Carbide, switched workspace to which I recently made.
Next step was importing example.
Choose File->Import->Symbian OS Bld.inf -> Browse to “workspaceChatgroupbld.inf”.
So Chat example is imported.
Then I created new files: pand.h, bnep.h, bnep.c .... which are copy-pasted from BlueZ.
Now there was a time to see how Unix C code would be compatible with Symbian one. Of course, they were not so alike. I started porting, that means to make Unix source code and algorithms functioning. For that time my idea was to achieve just out of error compilation.
The first problem I saw were type definitions undefined for carbide. So I wrote “myPortedTypes.h” header file which typedefs some Bluetooth types known in Symbian. Some types were available from <systypes.h> library.
I made some type definitions out of “myPortedTypes.h” also.
At bnep.c I defined
#define AF_BLUETOOTH 31
#define PF_BLUETOOTH AF_BLUETOOTH
#define BTPROTO_BNEP 4
This types were expected at <syssocket.h> library but were absent there. So I had to determine them.
At bnep.h I defined
#define ETH_ALEN 6 // That was expected at <netethernet.h> lib
One more pain was connected with lib <sys/ioctl.h>.
Carbide has a little different implementation of <sys/ioctl.h> than BlueZ expected.
<ioctl.h> has the macroses _IOR and _IOW which are used by bnep.h.
But Carbide’s ones have 2 arguments , but BlueZ expects 3 arguments…
I passed through 3 ways before solve this problem.
»The first.
I thought I have to use other source code of <ioctl.h> (and <ioctl.c>) library. I’ve found some sources in the web, and used them in my project. Everything seems to be ok. But there are 2 disadvantages:
1. The Symbian’s one ioctl should be much more effective, because it’s native to their phones.
2. I’m not sure that new trouble will not appear because of possible conflicts with hardware.
»The Second.
Due to _IOR is a macros declared with #define directive, The #undef directive is applicable to it. In this case I can apply new definition to that macros using other source libraries.
By this manipulations I reached redefinition just of the part of <ioctl.h> library. So it was more effective way.
»The Third.
The third way was to examine, how Bnep.h uses those macros, and to transform the Bnep.h code to use 2 arguments instead of 3.
During the code examination, I found out that the third argument of _IOR macrosis not used. It was just drowned by useless int type. So the only thing I had to do is to cut every third parameter from _IOR macros call. This was a best way to leave standard <ioctl.h> macros definition.
The current problems that brake porting are signal operations.
I created new file “mySysSignal.h” which includes <sys/signal.h> header and determines some definitions from <signal.h>. Yes, they are different.
Furthermore, <sys/signal.h> doesn’t want to declare “sigaction” struct, because _STRICT_ANSI was defined. So I had to #undef it and then #define back.
But I could not find the sigaction() function implementation at this headers!
I tried to adopt other sources where sigaction()is implemented, but no result. Those codes want more and more implementations. Does anyone know which sigaction()implementation would be the best for Symbian? Please, write your comments if you do.
I downloaded some sigaction sources from:
I started CVS project at Sourceforge.net. You can download my sources and examine them here:
You can checkout this source codes directly to Carbide C++. To do this look for my post: Get project from CVS to Carbide C++. The source files I worked with are:
Bluetooth.h Bnep.h Getopt.h Hci_lib.h Hci.h L2cap.h myPortedTypes.h | mySysLog.h mySysSignal.h pand.h poll.h sigaction.h sigvec.h |
and their *.cpp implemenation at "src/".
The written code is pretty chaotic because of Porting process. So don’t be wonder for that : -)
Thanks
Symbian C++, Testing |
Next | 
Previous |
Comments (1) | 
Trackbacks (1)
Re: Port of PAND (BlueZ) system
Octobit | 30/09/2007, 16:37
Maybe this is of interest to you, don't see your signal.h though
http://developer.symbian.com/wiki/display/oe/P.I.P.S.+Home
http://www.symbian.com/news/pr/2007/pr20078721.html