Stuffing Serial Bluetooth Module Inside C1k Casing, share your success stories ... Options

[albertr]

Since I haven't yet read/seen any posts about success stories on the subj (except for someone who claimed he added a usb bt dongle, but didn't support it by any tech info/pics), I'm getting ready to perform a first surgery on my C1K. Time permitting, I hope to do it sometime next week (maybe on July 4th holiday weekend).

Here's a few thoughts I have on the subj:
- There's a ffuart wired up to a port on the back of the C1K (so-called sharp i/o port) that has all modem control lines. I'm leaving it as a last resort (if everything else fails), since I want to retain it for rs232 comm.
- There's a btuart in PXA270 that has CTS/RTS control lines, but it's unknown if Sharp traced it on PCB. I would guess that it would make sense to have it traced just in case, i.e. planning for future models with built-in BT, but with Sharp you never know...
- Well, it leaves us with stuart that is wired up to IRDA transmitter/diode, but doesn't have any control lines, so hardware flow control is not possible.

If btuart lines can't be traced, either rs232 or irda has to go. Personally, I don't use IRDA myself, so for me the choice is clear. But not having hardware flow control leaves us with a challange of fighting high interrupt latency of bloated Sharp's kernel to avoid fifo overruns. I took a look at Sharp's serial driver, and as usual with sharp it's ... well, not good. I had troubles with overruns even at modest speeds. Now, the good thing is that it;s Intel PXA270, not Sharp's proprientary hardware, so full tech specs are available. I spend a few hours on "unsharp'ing" the serial driver, so now it seems to run ok. I tested it @ 460800 and not getting overruns anymore. I still need to test it @ 921600 and implement suspend/resume hooks, maybe add some hooks to front LED to show activity, etc.

Anyway, just thought it would be useful to have a dedicated thread where we all can share tech info and success stories. Please feel free to contribute... and I'll update you on status of my surgery.
-albertr

[albertr]

Thanks for sharing your experience! Now I see how you traced uart lines
Here's a direct link to that picture: http://zaurus-ja.sourceforge.jp/images/sl-...250_removed.jpg
Whoever did that had real nerve! I wish someone do the same to C1K/C3K, cause I'm afraid that pcb layout is different. However, it might be very helpful for folks who have 7x0/860 devices.

What do you mean under "not stable"? At what baud rate? You may want to try to short flying leads, or maybe even better - shield them to avoid interference. I'm not an electric engineer, but do you have an o'scope to check the signal?

As far as CSR module programming goes, take a look at their support web site. They have all required documentation available, so you can easily modify pskeys or write your own code to do that. I wrote some piece awhile ago for Win32 and can make it available on my site, so it can be used as a sample. Just let me know...

It seems weird that TX/RX BTUART lines are used in C700. Are you sure in this? You may want to grep for relevant register addresses on the kernel source to see where it gets used.
-albertr

[2x4ever]

Thanks for sharing your experience! Now I see how you traced uart lines wink.gif

Yes. Exactly.

Whoever did that had real nerve! I wish someone do the same to C1K/C3K, cause I'm afraid that pcb layout is different. However, it might be very helpful for folks who have 7x0/860 devices.

You may try to trace it another way: take devmem2 utility )from for example here http://2x4ever-vpn.compot.ru/zaurus/devmem2/devmem2 - compiled for arm) and write a little scipt to trigger a necessary GPIO pins while zaurus is running and oscilloscoping a PCB around CPU.
This shoud trigger TX/RX up and down ever second (for PXA250):
# while true; do devmem2 0x40E0001C 0xC00; sleep 1; devmem2 0x40E00028 0xC00; done

What do you mean under "not stable"? At what baud rate? You may want to try to short flying leads, or maybe even better - shield them to avoid interference. I'm not an electric engineer, but do you have an o'scope to check the signal?

Dongle is configured to use CTS/RTS at 230400 speed and works a second or two after that dongle is stops sending anything. When i'm reseting dongle it continues. While it is works for hcitool it doesn't works for PSKEY utility. I'm able to read a length of the PS key but not a contained info. Now i'm soldering dongle to a FFUART to use CTS/RTS and will try to change PS keys.

It seems weird that TX/RX BTUART lines are used in C700. Are you sure in this? You may want to grep for relevant register addresses on the kernel source to see where it gets used.

I'm sure. In the picture i've provided you can see that BTRXD is going to the chip named 2149 282 JRC. Googling on this gives me the folowing datasheet http://www.njr.co.jp/pdf/de/de05035.pdf. This is an amplifier for a zaurus buzzer.
While i can't trace where BTTXD goes, grepping source of the linux 2.6 kernel for zaurus gives the folowing defines wich are used in a battery charge code:
#define CORGI_GPIO_DISCHARGE_ON (42) /* Enable battery Discharge */
#define CORGI_GPIO_CHRG_UKN (43) /* Unknown Charging (Bypass Control?) */

[albertr]

You may try to trace it another way: take devmem2 utility )from for example here http://2x4ever-vpn.compot.ru/zaurus/devmem2/devmem2 - compiled for arm) and write a little scipt to trigger a necessary GPIO pins while zaurus is running and oscilloscoping a PCB around CPU.
This shoud trigger TX/RX up and down ever second (for PXA250):
# while true; do devmem2 0x40E0001C 0xC00; sleep 1; devmem2 0x40E00028 0xC00; done

That's a good idea in case there;s a suspected line. However, probing every line available doesn't seem to be practical unless you want to push your luck

Dongle is configured to use CTS/RTS at 230400 speed and works a second or two after that dongle is stops sending anything. When i'm reseting dongle it continues. While it is works for hcitool it doesn't works for PSKEY utility. I'm able to read a length of the PS key but not a contained info. Now i'm soldering dongle to a FFUART to use CTS/RTS and will try to change PS keys.

Looks like a mising flow control, unless you see frame or parity errors. If that's the case, then BCSP should help.

I'm sure. In the picture i've provided you can see that BTRXD is going to the chip named 2149 282 JRC. Googling on this gives me the folowing datasheet http://www.njr.co.jp/pdf/de/de05035.pdf. This is an amplifier for a zaurus buzzer.
While i can't trace where BTTXD goes, grepping source of the linux 2.6 kernel for zaurus gives the folowing defines wich are used in a battery charge code:
#define CORGI_GPIO_DISCHARGE_ON        (42) /* Enable battery Discharge */
#define CORGI_GPIO_CHRG_UKN                    (43) /* Unknown Charging (Bypass Control?) *

Interesting... Of course, they can steal GPIO pins, but what they're gonna do with data lines? And how buzzer can send any data to uart? Weird...
I'll try to take a look at 2.4.20 kernel source to see if there's any use of btuart data lines I have missed...
-albertr