Skip to main content
jarno2
jarno2
Associate
October 19, 2015
Question

SSI implementation issues

  • October 19, 2015
  • 5 replies
  • 1182 views
Posted on October 19, 2015 at 09:01

I think that there are some issues with the SSI implementation that I would like to point out. I hope that you could post this forward to the firmware developers of the module.

First, the SSI WIND event does not conform to the specified asynchronous indication format(UM1695, rev.5, page 4), which is

<cr><lf>+WIND:<number>:<descriptive string><cr><lf>

Instead the generated WIND event is

<cr><lf>+WIND:56:Insert message to client:<ID>

So in the other words the ending <cr><lf> are missing. This looks nice and fine for human operator on the console, but will require workaround the line parser which I would like to omit.

Second, if the response is not sent in time the device sends notification of this using just plain text “TIMEOUT OCCURRED!. It would be better if the initial indication was formatted correctly and the timeout indication would be another WIND indication. Once more this requires special handling which is not good.

Thirdly there is a possibility of probable race condition here. SPWF expects the host to send the response after sending the WIND indication. However at the same time the host might be starting some AT command or pushing data to the device. This might result in some wrong data being displayed on the SSI replacement. Consider following:

SPWF

Host

send: <cr><lf>+WIND:56:Insert message to client:<ID>

send: AT+S.SCFG=something,whatever

receive: AT+S.SCFG=something,whatever

receive: send: <cr><lf>+WIND:56:Insert message to client:<ID>

display:  AT+S.SCFG=something,whatever

send: Data for SSI

So, instead of expecting data directly, the SSI replacement should be operated via AT command, say AT+S.SSIR=<data for response>, this way it handling of SSI response data would be explicit.

To summarize I propose following changes:

  1. Fix SSI event to conform to syntax: <cr><lf>+WIND:56:Insert message to client:<ID><cr><lf>
  2. Add new event for missed SSI completions: : <cr><lf>+WIND:79:Missed SSI completion:<ID><cr><lf>
  3. Make SSI responses explicit via at command: AT+S.SSIR=<data for response>

I believe that this would make use of SSI features much easier on the host, as need for special cases and workarounds would be eliminated.

Regards,

Jarno
    This topic has been closed for replies.

    5 replies

    Gerardo GALLUCCI
    Gerardo GALLUCCI
    ST Employee
    October 19, 2015
    Posted on October 19, 2015 at 22:21

    Hi Jarno,

    first of all, thanks for your detailed analysis. We will take care of it.

    I want to share some evaluation.

    1 - WIND:56 was updated since FW3.4

    Old behaviour: ''+WIND:56:Insert message to client:%d''

    New behaviour: ''+WIND:56:Insert message to client:%s'' or generic ''+WIND:56:Insert message to client'', depending on SSI format (with or without '':tag''). Basically, incremental ''%d'' turned to user-defined ''%s''

    We need to update manuals. Thanks.

    In both cases, ending ''\r\n'' is missing. Its only a look&feel detail, which affects both input_demo (missing ''\r\n'') and output_demo (missing ''+WIND'' at all!).

    We cannot change this behaviour because of old customer's code.

    2 - after WIND:56 notification, external host needs to provide a result within 2000ms. If not, that SSI is skipped (''TIMEOUT'' string), and CGI engine passes to next SSI in the HTML page. The reason the ''TIMEOUT'' string is not another WIND is related to point #1: ''\r\nWIND:TIMEOUT\r\n'' should be very fine in case of ''\r\nWIND:56\r\n''. Cannot change now.

    3 - during WIND:56 event (ending with a \r or \r\n), module is not able to accept and parse AT commands. This means external host must be aware of this: do not provide AT commands during WIND:56 event.

    Thanks for your proposals. We will discuss about them for the future!

    Ciao

    jerry
    jarno2
    jarno2Author
    Associate
    October 20, 2015
    Posted on October 20, 2015 at 08:21

    Hello,

    Some additional feedback.

    1. Missing <cr><lf> is not just a look and feel issue. AT protocol is inherently line oriented, which paradigm is broken by violation of this format. This makes implementation of robust line detection -> line tokenization -> line state machine implementation more complicated.

    Currently I work around this by detecting the formatting violations in the line detection and passing ''correct'' data forward.

    3. Exactly my point, only that the host has no reliable way of knowing what the HTTP client is going to do. :)

    Regards,

    Jarno

    Steve Wood
    Steve Wood
    Visitor II
    May 26, 2017
    Posted on May 26, 2017 at 21:09

    Why not add another SSI input tag with a different name like <!--inputLFCR-->   ?     This no newline thing is a real pain in the ass, and NOT just a look and feel issue.

    Steve Wood
    Steve Wood
    Visitor II
    May 26, 2017
    Posted on May 26, 2017 at 21:16

    A related question:   Is it some how possible to insert CR LF as  characters in the WIND:56:Insert message to client:blahblah    tag?    This would accomplish the goal.

    Steve Wood
    Steve Wood
    Visitor II
    May 26, 2017
    Posted on May 26, 2017 at 21:17

    If so,

    What is the syntax?

    Terms & ConditionsAccessibility statement