Openmoko gsmd/libgsmd
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
 
 
Harald Welte ea175de97e gsmd/AT@COPS: don't use cmd before it is allocated 9 years ago
debian misc: Update the debian packaging for 0.1.0 9 years ago
doc some further gsmd/libgsmd work 16 years ago
include wavecom/sysmocom: use AT@COPS if available, instead of AT+COPS 9 years ago
logs first compiling (unfinished, not-working) version of userspace gsm infrastructure 17 years ago
src gsmd/AT@COPS: don't use cmd before it is allocated 9 years ago
.gitignore misc: Ignore various files of Openmoko GSMD 9 years ago
COPYING - Add copyright / license notice to all source code files 16 years ago
COPYING.library - Add copyright / license notice to all source code files 16 years ago
ChangeLog remove changelog, it's incomplete 14 years ago
Makefile.am gsm: modernize autotool framework and pkgconfigize it 16 years ago
README.txt some further gsmd/libgsmd work 16 years ago
THIS_PROJECT_IS_UNMAINTAINED add note about status 14 years ago
autogen.sh gsm: modernize autotool framework and pkgconfigize it 16 years ago
configure.ac increment library version as we broke the ABI 9 years ago
libgsmd.pc.in gsm: modernize autotool framework and pkgconfigize it 16 years ago

README.txt



1. GSMD api towards libgsmd
- provides api for other processes to interact with GSM subsystem
- is not documented and subject to change

2. GSMD api towards vendor-specific plugins
- implement vendor-specific AT commands
- is not documented and will initially only support TI
- later, a Motorola plugin is planned.

3. libgsmd api towards applications
- wraps GSMD-libgsmd api into C functions that can be used by applications
- will be documented and is supposed to be stable.

3.1. Events

The application registers callback handlers for events. libgsmd can call these callback
handlers at any given time. Events include "incoming call", "remote end hangup", ...

3.2. Commands

Commands have the form of command-reply. Usually they will be performed
synchronously, i.e. the the caller will be blocked until a response to the command has been
received.

If this behaviour is not desired, a completion handler callback function can be
registered. In this case, the function call will return immediately after the
command has been sent to gsmd. Further incoming packets on the gsmd socket
will be handled to libgsmd by calling lgsm_handle_packet(). If one such packet is the
response to a currently-executing command, the completion handler will be
called from within lgsm_handle_packet(). Matching of responses to requests is done by
assigning a unique id to each request. gsmd responses will have a matching id.


code flow in gsmd:

- select loop detects data has arrived on user socket
- gsmd_usock_user_cb()
- if this is atcmd passthrough,
- alloc + fill in gsmd_atcmd
- atcmd_submit()
- append it to pending_atcmds
- mark interest of writing to UART
- if this is not passthrough
- do whatever handling, including enqueueing of atcmds
- select loop detects UART is marked writable
- atcmd_select_cb()
- iterate over list of pending_atcmds()
- write a particular atcmd to UART
- move atcmd to busy_atcmds
- select loop detects UART is marked readable
- atcmd_select_cb()
- read up to 1024 bytes into buffer
- llparse_string()
- llparse_byte()
- llparse_append()
- llp->cb == ml_parse()
- if this is not unsolicited
- call cmd->cb()
- alloc + fill ucmd reply
- add to finished_ucmds
- mark user sock writable
- unlink + free atcmd
- if this is unsolicited
- unsolicited_parse()
- usock_evt_send()
- alloc + fill ucmd reply
- add to finished_ucmds
- mark user sock writable
- select loop detects user sock writeability
- gsmd_usock_user_cb()
- iterate over finished_ucmds
- write ucmd
- unlink + free ucmd