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 CPU. -- - Harald Welte <[EMAIL PROTECTED]> http://openmoko.org/ ============================================================================ Software for the world's first truly open Free Software mobile phone
