RIOT
RIOT copied to clipboard
drivers/at: parse +CME/+CMS responses and save error value
Parse +CME/+CMS responses and save error value
Contribution description
Motivation
Modems, especially mobile ones, can be very shaky. As such, in the scope of debugging, it is very helpful to know failure reasons.
Luckily, many modems can offer detailed error codes. Once this feature is enabled, they will answer with +CME ERROR: <error_code>
(or +CMS ERROR: <error_code>
for SMS-related commands), where <error_code>
is either an integer error code or a string. This is much better than the standard ERROR
response, which provides no further information.
Unfortunately, in the current state, the AT driver does not parse any errors. Generally, if the response is not OK
then -1
is returned and that's it.
Contribution
This patch enables extended error parsing. If a +CME/+CMS
answer is detected, most functions will return -AT_ERR_EXTENDED
, and the <error_code>
will be available in a buffer for further inspection.
Design considerations
I tried to keep the changes at a minimum, maintain API compatibility and offer a clean solution at the same time. At the end, I had to sacrifice on change minimalism. As follows, this is a big PR. Individual changes are annotated inline.
Anyway, some generalities:
-
<error_response>
is retrievable from a buffer instead of parsing and returning it as an error code because, depending modem configuration, it might be a string. Let the user handle that. - the error buffer is passed in at driver initialization out of following reasons
- to keep API as unchanged as possible (e.g. functions not expecting a response do not provide a response buffer)
- in the future, I might improve the URC parsing (currently is very unreliable - see this issue). This buffer could be then used for URC inspection. Otherwise, either heap or large stack allocations will be required.
Testing procedure
See tests/drivers/at/tests-with-config/emulate_dce.py.
~I will add inline comments regarding design decisions in a few moments.~ Done.
The title of this PR does not really cover the actual redesign that is going on.
Funny note. This evening I started looking at the at
driver (again, after more than two years). I was thinking to rewrite this driver, ha ha. Note, I wrote several Arduino libraries for Ublox modems, for example https://github.com/SodaqMoja/Sodaq_R4X. So, I do know bits and pieces about this stuff.
Funny note. This evening I started looking at the
at
driver (again, after more than two years). I was thinking to rewrite this driver, ha ha. Note, I wrote several Arduino libraries for Ublox modems, for example https://github.com/SodaqMoja/Sodaq_R4X. So, I do know bits and pieces about this stuff.
Looks good. Nice way of detecting echoes! Right now we're using a layer on top of this driver that provides ergonomic command formatting and response argument parsing. Might make sense to include that here too.
The title of this PR does not really cover the actual redesign that is going on.
Right, so next step is to fix the URC handling (as a first step, synchronously only). I wonder if I should open a separate PR for that, or to add it here and change the name to something like drivers/at: redesign error reporting and URC handling.
Murdock results
:heavy_check_mark: PASSED
c58b71b899683a0e3be1b8ce078edbb33c9c558c drivers/at: parse +CME/+CMS responses and save error value
Success | Failures | Total | Runtime |
---|---|---|---|
9997 | 0 | 9997 | 11m:00s |