Bluetooth to 2410 Wiring

[Harald Welte]

Hi Wally!

On Thu, Jul 26, 2007 at 10:48:59PM -0400, Wally Ritchie wrote:
> > I'll look into that issue, though.  If we still can make it, we will.
> > But I'm not very confident.
> >
> Thanks for looking. There are a total of 8 flexible PIO's on the on BT module
> of which you are using two. 

I know.  The problem is that the bluetooth module was put on a FPC, and
that FPC has only a fixed (minimal) number of lines.   The entire design
was done by the hardware team which was not really under our control at
that time, so our influcence (and actual knowledge of what was going on)
was very minimal.

> The wakeup function needs one external int (of the 16) and another
> GPIO. This is two signals for a very critical function of a BT
> equipped smartphone (actually one solved 5 years ago). If not possible
> in first copper, maybe next or GTA03 but IMHO this an important function.
> Personally i think failing to get BT right is not an option.

Well, the main issue seems that none of the core developers in this
project seems to have ever used bluetooth at all.  To me it is still
this somewhat strange technology, that I have used about five times
with consumer equipment to exchange contact data between phones.  That
is, I enabled it for about two minutes each time, then disabling it
again.  For security reasons, having a enabled (even non-discoverable)
bluetooth doesn't really seem to be a good idea, at least with
non-updatable consumer handheld devices.

But even after many, many days of time put into it, I still have not
managed to get any of my three bluetooth keyboards to work on any of my
linux machines.  It seems that it is intertwisted with complex things
like dbus, that I definitely do not want to have on my machines due to
its resource usage.

In any case, I actually have to admit that I don't see a reason why
wakeup from bluetooth is that important.  In which particular scenario
would you use this?

Once the cpu is in POWRE_OFF mode (that's how samsung calls their
suspend-to-ram mode), it actually takes significant time to 'boot' into
the existing RAM image again. (It first starts by loading the first 4k
of NAND into SRAM, executing the bootloader, taking SDRAM out of
self-refresh, jumping into the kernel, then re-enablign all the various
hardware devices).

If I was to use bluetooth, then I would explicitly connect to some other
device, let's say another phone.  As long as that transfer is ongoing,
would you want to suspend between the individual packets?  That's way
too short timeframes.

And if I think about BT headset use, then its use is always connected to
an incoming or ourgoing call, i.e. the CPU will have to be woken up by
either the GSM modem before, or by the user dialing a number.

And if you want to set your phone discoverable to ceate a
connection/association with another device, then that, too. will have a
manual 'set phone discoverable' event before, and not be autonomously
woken up by bluetooth.

In fact, the more I think about it, the lesser I like the idea of this
capability.  Why would I want my phone to wake up and draw power for
something that I didn't explicitly request it to do?

Maybe you can educate me.

I'm not really arguing against producing hardware that has this
technical capability (as long as we can do it given the resources we
have).  But I somehow doubt its general usefulness.

-- 
- Harald Welte <laforge at openmoko.org>          	        http://openmoko.org/
============================================================================
Software for the world's first truly open Free Software mobile phone