AtatCmd: consider changing the default termination from <CR><LF> to <CR> ?

[sjorsdewit]

When using the #at_cmd() derive macro, the default command termination seems to be "\r\n" (also called<CR><LF>).
While debugging an unrelated issue I noticed that most (all?) modems don't actually require the extra "\n" character. This is usually just ignored, but it can also cause subtle bugs which can be hard to reproduce (depending on modem model/timing/baudrate).

The specs

After looking into some hayes command set definitions and modem datahseets, none of them seem to require the trailing "\n" in commands. So far all the specs and datasheets I've seen define the commands something like:

• <CR> Carriage return character ("\r" = ASCII character 13)
• <LF> Line feed character ("\n" = ASCII character 10)
• All command lines must start with 'AT' or 'at' and end with <CR>

Example of a bug caused by trailing "\n"

In this example I used the Quectel EC21 modem to publish an MQTT message over a 3Mbaud serial connection. The bug is timing-dependent, so might not reproduce at other baudrates or modem models. But I expect this same bug to potentially occur with all AT commands that expect to receive data after a 'prompt' character.
For example, consider this conversation between an atat client and a Quectel modem to publish a 30-byte MQTT message::

AtClient: 'AT+QMTPUBEX=0,0,0,0,“topic/pub”,30<CR><LF>'
Modem: '>'
AtClient: 'This is test data, hello MQTT!'

In this example, the client announces 30 bytes of topic data, then intends to send 30 bytes after the prompt ('>').
However, as the modem does not require the trailing <LF> as part of the command, it can immediately send the prompt character. The modem might then interprets the above conversation as:

AtClient: 'AT+QMTPUBEX=0,0,0,0,“topic/pub”,30<CR>'
Modem: '>'
AtClient: '<LF>This is test data, hello MQTT!'

Where the modem publishes <LF>This is test data, hello MQTT, instead of This is test data, hello MQTT!.

The fix

Luckily atat is flexible enough that we can set a custom termination string. Setting termination = "\r" fixes the problem:
#[at_cmd("+QMTPUBEX", termination = "\r")]
In fact, I've set termination = "\r" on all at commands just to be sure and everything works fine. I'm not sure if there are any cases where the "\r\n" termination is required? Otherwise I would suggest setting the default to "\r\n".

[MathiasKoch]

Hmm.. I never really thought about that. I will give it a shot on our devices, but I am fairly sure you are correct that just the one is enough

[MathiasKoch]

Would you be open to opening a PR for this?