bluetooth-dev Mailing List http://lists.apple.com/archives/bluetooth-dev/2009/Nov/index.html bluetooth-dev Mailing List Sat, 07 Nov 2009 13:00:01 +0000 Broadcom BT Performance 20x slower than Cambridge Silicon http://lists.apple.com/archives/bluetooth-dev/2009/Nov/msg00004.html Reply to list

I have an application in which I use
Bluetooth to wirelessly control a robot which also supports Bluetooth.
The user can use the keyboard arrows/space bar to drive the robot around
and shoot balls much like they would a First Person Shooter video game. [...]
]]>
Re: How to release or disable SCO audio connection http://lists.apple.com/archives/bluetooth-dev/2009/Nov/msg00003.html Reply to list

[...]

After further study, I understand SCO connections are established by  
the Link Manager which resides within the Bluetooth Module or  
controller on modern Macs.  The HCI (Host Controller Interface) layer  
provides the interface to the Bluetooth Module, but I haven't found a   [...]
]]>
Re: IOBluetooth.framework 64 bits support on 10.5 http://lists.apple.com/archives/bluetooth-dev/2009/Nov/msg00002.html Reply to list

This might be useful for limiting 64 bit to SnowLeopard only.    http://www.cimgf.com/2009/10/31/limiting-64-bit-to-10-6/     -Craig      On Nov 1, 2009, at 4:39 PM, Camille Troillard wrote:  Hello David,    The solution I have found was to build a multiplatform binary which links against the 10. [...]
]]>
Re: IOBluetooth.framework 64 bits support on 10.5 http://lists.apple.com/archives/bluetooth-dev/2009/Nov/msg00001.html Reply to list
Hello David,    The solution I have found was to build a multiplatform binary which links against the 10.4 SDK in 32 bits for 10.4 and 10.5 platforms, and a 64 bits version for 10.6.     

On 10.5, the 64 bits version of the bluetooth framework seems to be broken, which is unexpected since it is available.        Best,  Camille        

On Sun, Nov 1, 2009 at 1:55 PM, David Christmass <email@hidden> wrote: > quoted text

  
]]>
RE:IOBluetooth.framework 64 bits support on 10.5 http://lists.apple.com/archives/bluetooth-dev/2009/Nov/msg00000.html Reply to list
Hi Camille, 

It has been the tradition in the past to build Applications which are platform specific. 68k coding for Moto chips differed to PPC builds and differed to CFM which could allow PPC to run 68K code and creating a Fat binary allows for integration of all systems of their kinds within time slots, beyond PPC integration is abbridged with Carbon, and later Cocca for want of a better word interpeter layers which patch code to machine specific platform, beyond this, when intel showed up, the same interpreter traditions existed in Rosseta, describing the platform you are building for exactly in the build processes will ensure that coverage exists for the platforms you are choosing to support. You might be forced to start from 32bit addressing perspectives because 64 bits are bigger words, to achieve cross compliance. Fitting 64bit on 32 bit words, well how would you stuff a small jar with so many goodies: two pints into a pint pot so to speak? You might have to
 think about compression, and even some kind of software based floating point numerator or FPU emulator to get the  64 bits understood by 32 bit systems: that involves additional provisions of interfacing to work on 32 bit systems, like a control panel for example or something, and suitable licensing for distribution arrangements. One the one hand building down for up is not going to give the later platforms full capacity, and building up for down is going to involve expanding operational system facilities in some form. My suggestion for you would be a multiple build process for dedicated systems, but that is what you are trying to avoid, I read. The hinderance is the material science of having software perform hardware tasks, which slows things down.

That is where your at, and the choices you have to make.

David



 
]]>