Merging changes from ATParser towards parser unification

[SenRamakri]

ARM Internal Ref: IOTMORF-1232
Adding @kjbracey-arm @hasnainvirk

[geky]

formatting, should be while (oob) {

[geky]

formatting, should match comment style in file

[0xc0170]

@SenRamakri Any update or respond to this ?

[hasnainvirk]

Why are you writing a separate routine ? This logic is already a part of vrecv(), check here https://github.com/ARMmbed/mbed-os/blob/master/platform/ATCmdParser.cpp#L274

[kjbracey]

I do feel, as I did when I saw this go into ATParser, that it was duplicating quite a lot of code. Having the API does avoid having to do recv("impossible string") to just check for oobs, which is nice though.

Could we not make it defer to recv? Maybe pass NULL as the "expected" to invoke the behaivour?

Also I think it doesn't change behaviour /enough/.

I'm wary that this leaves the timeout quite high, and - if any unrecognised OOB arrives, we end up waiting for the same timeout we would have used for a command response. Seems like we should have the timeout set lower while checking for OOB - effectively we want a "hurry up and finish the line" timeout, not a "respond to my command" timeout. Also, after a newline, we should do redo the readable check and immediately return, to avoid:

* We're readable
* We parse an OOB we don't recognise
* We sit there for 5 seconds waiting for more data

So I guess my counter proposal is something like:

• parse_oob() sets timeout lower temporarily, calls recv(NULL)
• recv(NULL) checks for readable at start of each line, so recv only waits for input if looking for a response or trying to complete a line

[geky]

So the problem this fixed is here:
https://github.com/ARMmbed/esp8266-driver/blob/44fb447c72a37fb397a413467e02208ffeddb88e/ESP8266/ESP8266.cpp#L232

The read is inside an oob callback that's called from process_oob (here). It reads in the packet and is very likely to fail if the timeout is small. Not only will you lose the packet, but the esp8266 will dump a bunch of raw data on the serial line.

So you can't set the timeout low while processing oobs, unless you're able to set it high again in the callback. But the callback will also need to return the atparser to its previous timeout.

I think only doing the readable check once was just a simple coding mistake, but it still caught the majority of issues.

You could use a flag or something to share the same code path, but at this point recv(NULL) and process_oob() are the same function with just different names. We went with process_oob() to make its intention a bit more clear.

Feel free to refactor the function, but not sure it should block the unification effort.

[kjbracey]

Yeah, I guess further tweaks can wait - as this is effectively a merge, let it just be a merge. (Plus as this is an addition, can't break any existing AtCmdParser users).

That timeout of 0 that ESP8266 was setting was totally inappropriate - you do need some reasonable finite time to let the line be transferred - 0 would fall apart quite readily, as you'd never wait for an ongoing line to be finished.

Conceptually the API should probably have two timeouts - the "wait for expected string" timeout and the "when do I give up reading the current line" timeout. What you want for the OOBs is effectively the first one being zero, while the second remains small and finite as ever.

[SenRamakri]

Thanks for the review, Kevin. Since we all agree that the unification doesn't adversely affect anything I'll go ahead merge the unified ATCmdParser and take care of the changes being discussed later.

[theotherjimmy]

/morph test

[mbed-bot]

Result: ABORTED

Your command has finished executing! Here's what you wrote!

/morph test

[studavekar]

/morph test

[mbed-bot]

Result: SUCCESS

Your command has finished executing! Here's what you wrote!

/morph test

Output

mbed Build Number: 1516

All builds and test passed!

[0xc0170]

@hasnainvirk To be certain with the proper testing for this changeset, is morph enough?

[hasnainvirk]

@0xc0170 It should be alright.

[kjbracey]

My proposed change finally implemented in #8598