[gta04] Meeting minutes for GTA04 discussion 20080411
laforge at openmoko.org
Mon Apr 14 22:13:21 CEST 2008
On Mon, Apr 14, 2008 at 08:36:53PM +0100, Andy Green wrote:
> | please dont' try to design hardware fixes for something that sounds like
> | a software design or implementaiton problem (polling an UART for data)
> Could you elaborate a bit? Polling the module at all during a call is
> bad news? If so, what is the better way to find out about other side
> ending the call, etc.
If the other side has ended the call, you should get a DICSONNECT
message or similar. IIRC you get a CONNECT after the call is
established and some other message when the call is taken down.
Also, if you have the AT%CPI call progress indications on, the call
progress (even the teardown progress) should be reported quite verbose
by unsolicited %CPI responses from the modem.
In any case, if there really is a need: FIC/OM does have the sources of
the AT command parsers inside the GSM firmware. So additional
indication could most likely added without too much effort. That would
still be a much cleaner solution than some kind of 'hardware fix'.
> I'm asking from the point of view to see how to best keep the CPU down
> during the call.
AFAIK, anything that alters call state would generate some kidn of
message on the AT command interface, which in turn should wake up the
- Harald Welte <laforge at openmoko.org> http://openmoko.org/
Software for the world's first truly open Free Software mobile phone
More information about the openmoko-kernel