Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Merging changes from ATParser towards parser unification #5212
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
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
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:
So I guess my counter proposal is something like:
So the problem this fixed is here:
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
Feel free to refactor the function, but not sure it should block the unification effort.
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.