Re: polling for bluetooth events
Re: polling for bluetooth events
- Subject: Re: polling for bluetooth events
- From: Hans-Christoph Steiner <email@hidden>
- Date: Tue, 11 Mar 2008 14:33:21 -0400
Yeah, that's what I was afraid of. Thanks for the breakdown. Does
this need to be a totally separate process to work? Or can it be a
thread?
Also, anyone know about using Bluetooth devices thru HID Manager?
.hc
On Mar 10, 2008, at 1:34 PM, Joseph Kelly wrote:
So basically you require a polling model -- occasionally you'll
poll for any available input, process it, and then return to
whatever it is you're doing. Unfortunately, the bluetooth api is
dependent on the main thread run-loop (unlike HID which has a
queueing mode), i.e. your main thread should spend its life
handling events and otherwise remaining idle, and you would offload
cpu intensive tasks to worker threads.
Have you considered handing off your bluetooth stuff to a separate
process?
So basically, the process that needs to poll for events will spawn
the bluetooth process (which creates a broadcast CFMessagePort),
set up an event fifo, create a listener thread which creates a
CFMessagePort to the bluetooth process. Then the bluetooth process
connects to the device, sets up callbacks for data, then sits in
the run loop. When data comes in from the wiimote to your bluetooth
process' callbacks, it forwards the data over the message port to
the listener thread, the listener thread stuffs the event into the
event fifo. And then whenever your main process polls for events,
it simply gets the lock on the event fifo, checks for available
data, and unlocks.
It's not the cleanest solution, but I think it should get you a
continuous flow of data from the device.
Joe K.
On Mar 7, 2008, at 6:08 PM, Hans-Christoph Steiner wrote:
Pd (aka Pure Data) has two processes that communicate via a
network socket. There is a Tcl/Tk process that handles the GUI
('pd-gui') and the C process ('pd') that handles all of the
digital signal processing. It is a realtime system, so it has its
own cooperative scheduler. All processing needs to happen within
the timeslice, or it will cause an interruption in the
processing. So, for example, when I connect to the device, it
causes everything to hang until the device is connected, and
CFRunLoopStop() is called.
Since Tcl/Tk is based on Carbon, AFAIK, there is probably a
CFRunLoop in it. But that's a separate process, so the 'pd'
process isn't using any of that.
I wrote HID support for Pd, and I just polled the event queue, it
works well. I was hoping for something like that for Bluetooth
HID events. In particular, I am working on getting data from a
Nintendo WiiRemote.
.hc
On Mar 7, 2008, at 8:34 PM, Joseph Kelly wrote:
Much of the user space Bluetooth API depends on run loops, i.e.
for getting data to and from the kernel. It's surprising that
your GUI framework itself does not rely on run loops. How does it
respond to user input etc. ?
Unfortunately, I found that some Bluetooth calls only run
reliably on the main thread, at least on Tiger and earlier.
Maybe you could explain your architecture a bit more. The model
I've been using is I set up a callback for when data comes from
the device, then I just return and wait; when the user does
something which causes me to send commands to the device, and
when I return from doing that (i.e. program flow returns to the
event manager and the runloop code) I then get my data-in
callbacks which I respond to.
Joe K.
On Mar 7, 2008, at 12:55 PM, Hans-Christoph Steiner wrote:
I am currently in the process of adding bluetooth HID support to
Pure Data, a realtime, visual programming language for sound,
video, etc. The GUI is all written in Tcl/Tk, so we are not
handling a CFRunLoop at all.
I have gotten device searching and connection working by using
CFRunLoopRun() then sticking CFRunLoopStop(CFRunLoopGetCurrent
()) the end of the of the inquiry completion callback. I am
trying to get the same thing working for getting events, but I
haven't been able to.
Ideally, I would be able to poll for bluetooth events, is there
a way to do that, outside of creating a separate thread to
handle the event callbacks? Maybe something with
CFRunLoopRunInMode()?
Here's the code in question:
http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/
externals/io/wiiremote/
.hc
-------------------------------------------------------------------
---------
http://at.or.at/hans/
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Bluetooth-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40mac.com
This email sent to email@hidden
---------------------------------------------------------------------
-------
All mankind is of one author, and is one volume; when one man
dies, one chapter is not torn out of the book, but translated into
a better language; and every chapter must be so translated.... -
John Donne
------------------------------------------------------------------------
----
News is what people want to keep hidden and everything else is
publicity. - Bill Moyers
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Bluetooth-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden