GTA02 Battery Capacity (Was: Re: More about the GTA02)
andy at openmoko.com
Fri Feb 15 09:11:02 CET 2008
-----BEGIN PGP SIGNED MESSAGE-----
Somebody in the thread at some point said:
> Am Fr 15. Februar 2008 schrieb Andy Green:
>> Still for quite a few embedded tasks I2C or LVTTL UART --
>> let's not forget USB OTG 12Mbps host from the mini USB B connector --
>> will be enough to make a practical solution though.
> Good point! If i need additional GPIO, so what. I got I2C, so i just chain up
> some with a dirt cheap chip.
> The interfacing of the smart battery in GTA01 shouldn't be a big thing this
> Homebrew I2C->GPIO driver, patching GPIO_Bat DEF in src for GTA02 smartbat
Well you need a bit of caution on that particular one because the smart
battery uses a "1 wire" type protocol called HDQ that is reasonably
time-sensitive and uses a "width of 0 level" encoding scheme to define
the bit state. So ~~~._.~ can be a '0' and ~~.__.~ can be a '1' for
example. The crisis comes with that when you receive the data back from
the battery, you have to sample it in a fairly stable way to assess the
'0' length on the wire. See the bq27000 datasheet link I posted before
for details and timing.
In Linux, the I2C stack has a nasty gotcha, it cannot work from
interrupt context, and in fact if you have interrupts on you are screwed
anyway because other interrupts like USB or whatever can come take take
the CPU for considerable periods making your IO crazy jittery. If you
try to get around that by using a workqueue so it is out of interrupt
context, then your IO is insanely jittery at scheduler granularity and
depending on userspace load :-) So sampling that HDQ '0' length becomes
You can square the circle by disabling interrupts and doing your own I2C
bitbang via GPIO from CPU, and spinning for the right period between I2C
actions, but the owns the CPU for many ms each time. Its probably okay
since one doesn't read the battery very often. But you can see it is a
bit more of an advanced project.
On GTA02 I used a single CPU GPIO with a FIQ driver triggered off a
timer, with the HDQ protocol implemented in a state machine in the FIQ
ISR to beat these restrictions. The patches for both the FIQ driver and
the HDQ and BQ27000 drivers are in the kernel mailing list archives. If
people want to provide patches to reuse ANY GTA02 work that is done for
GTA01, that will be really welcome.
> So real issue left for some projects is "which power should i use" (especially
> for those devices that don't do their own power-down).
Its going to depend on the current you need. IO_3V3 is unswitched but
high current. Really I think for most projects, the real answer is the
USB OTG Host connector. You don't have to open the case and it provides
switched power for you.
> And i wonder whether there will be *good* (near circuit diagram) specs for the
> connectors. I.E.:
Well I am under NDA, but some of these datasheets are available in the
world and the answers may not be a million miles away from the typical
application circuits in there.
> *-what kind of OverVoltage-Protection (clamp-diodes etc) / HF-blocking /
> ground potential..., can i expect behind any external connector.
I have to leave that, but there is EMC and ESD protection considered on
> *-What exactly is the impedance (R, C) of headset out, what are the absolute
> maximum ratings (so i may figure out e.g. whether the headset out makes for a
> high-quality (HiFi) 1,5V at 10K line out, or should i plan for a 56R load
> instead of the standard 10k-50k).
> *-USB-host power shortcircuit...? Will it blow my battery or whole NEO up in
> smoke? ;-).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the community