Android GSM Driver Module (rild) detailed analysis (3) Response Process

In the previous analysis of the request, the writeline operation in at_send_command_full_nolock was terminated, because the operation to write the command to the hardware device was completed here, and the next step was to wait for the hardware response, that is, the response process. Our analysis also starts from here.

Response information is obtained in the readerloop mentioned in the First initialization analysis. Received by the Readline function in the unit of 'row.
There are two types of at response: one is actively reported, such as the network status, SMS, incoming calls, etc. do not need to go through the request, there is a dedicated description of the unsolicited words. The other is the real response, that is, the command response.

Here we can see that all rows are filtered by the automatic reporting of SMS, because at processing of SMS messages is usually troublesome and is listed separately regardless of sending and receiving. This is because the text message (two lines, logo + PDU) needs to be processed in real time and cannot be split for processing. The processing function is onunsolicited (pointed by s_unsolhandler). Let's take a look.

Except for the exception of SMS, all lines must go through processline. Let's take a look at this process:
Processline
| ---- No cmd ---> handleunsolicited // actively report
| ---- Isfinalresponsesuccess ---> handlefinalresponse // success, standard response
| ---- Isfinalresponseerror ---> handlefinalresponse // failed, standard response
| ---- Get '>' ---> send sms pdu // receive> symbol, send SMS data and wait for response
| ---- Switch s_type ---> the specific response // The specific response information of the Command needs to be analyzed accordingly.

Here we mainly focus on handleunsolicited automatic reporting (will be called to the onunsolicite that is also called by the previous smsunsolicite), and the specific response information of switch s_type. In addition, the specific response must be a standard response such as handlefinalresponse to fin.

1. onunsolicite (actively report the response)
Static void onunsolicited (const char * s, const char * sms_pdu );
The text message at design is really troublesome, so that the second parameter of this function is completely prepared for it.
The main parsing process of response is completed by the function in at_tok.c. In fact, the string is parsed by block. The specific parsing method is determined by each command or report information. Here we will not detail it here. onunsolicited only resolves the first part (usually in the form of + XXXX), and then decides the next operation based on the type. The operation is ril_onsolicitedresponse and ril_requesttimedcallback.

A) ril_onunsolicitedresponse:
Return unsolicited information directly to the upper layer. Use parcel to write response_unsolicited and unsolresponse (request number) to parcel first, then use the s_unsolresponses array to find the corresponding responsefunction for further parsing and store it in parcel. Finally, it is passed back to the original process through sendresponse. Process:

Sendresponse --> sendresponseraw --> blockingwrite --> write to s_fdcommand (the socket connection established earlier with the upper-layer framework)

After these steps, there are some other operations such as wake-up system. Not detailed.
B) ril_requesttimedcallback:
The timer mechanism implemented by the event mechanism (refer to Article 2) calls back the corresponding internal processing functions. Use internalrequesttimedcallback to add the callback to the event loop, and finally complete the callback of the function mounted on the callback. For example, pollsimstate, onpdpcontextlistchanged, and other callbacks can be processed internally without returning the upper layer.

2. Switch s_type (specific command response) and handlefinalresponse (standard response)
The command type (s_type) is set when sending command (see Article 2). There are several types of commands: no_result, numeric, singleline, and Multiline for different at times. For example, if at + CSQ is singleline, at + CSQ = XX, XX is returned, and a line of OK is added. For example, some setting commands are no_result and only one row is OK or error.

These types of parsing are very similar. Through some judgment (comparing at header tags, etc.), if the corresponding response is, it is mounted to a temporary result sp_response-> p_intermediates queue through addintermediate. If it is not the corresponding response, it should actually be interspersed with automatic reporting, which is handled by onunsolicite.

A specific response can only be used to obtain the response information to a temporary result and wait for the specific analysis. Whether or not there is a specific response, the standard response handlefinalresponse is finally completed, that is, the standard response such as OK and error is accepted to end. This is the specification of most AT commands.

Handlefinalresponse sets the s_commandcond object, which is the waiting object of at_send_command_full_nolock. At this point, the complete response information has been fully obtained, and the send command can further process the returned information (temporary results, and standard return success or failure, all in sp_response ).

The pp_outresponse parameter returns sp_response to the function that calls at_send_command_full_nolock.
In our analysis in Article 2, this function is actually requestdial, but requestdial ignores the response. So let's look at another example, such as requestsignalstrength, the command is actually the at + CSQ mentioned above:

We can see that the operation is indeed performed through at_send_command_singleline, and the response is in p_response.
P_response if the returned result fails (that is, the error of the standard response, etc.), send the returned data to the upper layer through ril_onrequestcomplete and end the command.
If the execution is successful, p_response-> p_intermediates will be further analyzed, which is also analyzed through the functions in at_tok.c. The result is also returned through ril_onrequestcomplete.

Ril_onrequestcomplete:
Ril_onrequestcomplete is similar to ril_onunsolicitedresponse and has the same functions.
It is passed back to the upper layer through parcel. It is also written first to response_solicited (different from response_unsolicited), PRI-> token (request number passed in the upper layer), error code (send command error, is not an AT response ). If an AT response exists, access pri-> PCI-> responsefunction to parse the specific response and write it to parcel.

Then, in the same way:
Sendresponse --> sendresponseraw --> blockingwrite --> write to s_fdcommand
Complete the final response delivery.

At this point, we have analyzed the automatic reporting and command response. In fact, the response part has come to an end.
This is the end of the three RIL analysis articles.