GSMTask and GSM APIs workflow

From openPicus Wiki
Jump to: navigation, search


GSM Task

OpenPicus framework integrates the stack with FreeRTOS operating system, to ease the management of any GSM/GPRS operation. APIs framework for GSM/GPRS has several functions to handle Voice Call, SMS, TCP, HTTP, FTP and SMTP services. Those APIs manage the communication with GPRS module, sends all the required AT commands, parses responses, and manages asynchronous messages too. In this way, developer doesn't need to have specific knowledge about AT commands usage, or bother about GSM module usage.

Note: a minimum knowledge of the GSM services is needed, and also some knowledge of TCP/IP is requested for data connection services.

Standard mode vs Low Level Mode

Flyport GPRS / Flyport PRO GPRS can be used in two different modes: Standard mode or Low Level mode.
Using Standard mode all the AT commands are handled by GSMTask, instead in Low Level Mode user firmware should keep track of all the messages on GPRS dedicated serial port, specially all the asynchronous messages sent by GPRS Module for network events.
With Low Level Mode you actually loose all the GSM Task capabilities, and loose all the GSM Events features. It's less or like a ready to use microcontroller connected to a GSM Modem, but no RTOS / Framework is used in this way!

Standard Mode

In Standard mode, all the serial commands (AT commands) between PIC Microcontroller and GPRS Module are processed inside the “GSMTask”. In this way, user application can be independent from GSM commands execution, and “FlyportTask” must not be locked waiting for the end of UART (serial) operations.
Another advantage of Standard mode is all the “Unsolicited messages” received from GPRS Module are analysed by GSMTask, and dedicated events are executed automatically to perform different actions. Unsolicited messages are asynchronous messages sent by GPRS module to inform master device (in our case microcontroller) of any kind of events. Such events could be incoming SMS, connection to network, data on TCP Socket, and so on...

IMPORTANT: Flyport can control GSM Module events only in Standard mode. If user forces Low Level Mode, GSM Events functions will NOT be executed. The message parsing and detecting is left to user firmware if Low Level mode is enabled!

GSM APIs workflow

Since GSM module response to certain AT commands can be really slow (timeouts of up to 120 seconds are necessary), it is mandatory to provide framework APIs of a different structure respect Flyport Wi-Fi and Ethernet.

To permits GSM Task to handle incoming data, and execute Flyport Task requests APIs execution, all the UART data exchanges are handled using multitasking architecture. This means that all the functions provided does not response directly with values, but its execution is performed in background. This permits to create user applications that continue them operations while waiting for GPRS commands to finish.

The generic workflow of Flyport GPRS API functions is the following:

  • Inside Flyport Task the function "GPRS_API_function" is called
  • All necessary parameters are set, and the type of operation is communicated to GSM Task, and Execution status is changed to “OP_EXECUTION”
  • Flyport Task continues, but GSM Task handles (in background) requested AT commands for "GPRS_API_function" execution
  • When GSM Task finishes "GPRS_API_function" execution, it sets Execution Status to the result of operation.
  • Flyport Task is now free to analyse the results, and request another GPRS API function.


Note: Please read also this tutorial to know how to handle execution status and results

Personal tools