Hey,
First of all, who is the maintainer of driver_at? In other words,
who should I be asking questions about this driver?
I have a bunch of modems that I am considering to write drivers
for (SIM800/900, several Ublox).
There is this concept of URC, Unsolicited Response Code, that some of
the modems can emit. I don't quite grasp how this is supposed to work
with our AT driver. There are no examples or uses of the AT driver.
Before throwing in my first question, here is an excerpt of the Ublox
datasheet
"The DCE/MT interface can operate in these modes:
• Command mode: the DCE waits for AT command instructions. The DCE interprets all the characters received
as commands to execute. The DCE may send responses back to the DTE indicating the outcome of the
command or further information without having received any commands by the DTE (e.g. unsolicited response
code - URC). Any communication in the command mode (in both directions) is terminated by the command
line termination character.
..."
The way I interpret this is that the device may or may not output URCs
after sending a command. And it is not clear to me in which order URCs
are mixed with the normal output.
To be able to handle both normal output and URC there must be a single
function that reads responses from the device and while doing so it should
handle URCs. In any case, our (SODAQ) Arduino libraries do it that way.
The function process_urc has a while loop that reads lines from the device,
it processes URCs, but it also throws away anything else. That doesn't feel
right. Or does it?
Is somebody using the AT driver? Is somebody using the URC facility?
Hi,
There wasn't any reaction to my question, so I'm trying again.
Or, should I be opening an issue at GitHub?
Besides my question about the handling of URCs, I'm quite curious
if there are people using the generic AT module.
-- Kees
He Kees,
First of all, who is the maintainer of driver_at? In other words,
who should I be asking questions about this driver?
As I'm the original author, I'd consider myself the author, but Vincent
has contributed a lot. Asking on this mailing list was probably the best.
Sorry for the delayed answer.
Is somebody using the AT driver? Is somebody using the URC facility?
I'm using the driver in a production device, but without URC.
I'm sure URC can be improved. I was thinking whether we can write a UART
RX handler that can be switched to line-mode when needed (compared to
bytewise handling), and then hook URC handling in there.
I think we're all not entirely clear on how URC's are supposed to work
in general, and if modems actually behave as expected. Most
documentation states that URC cannot occur while a command is handled.
When does that "handling" start? after sending the newline
(AT<foo><CR>), or maybe after receiving AT?
Could someone with a modem on the desk try, e.g, does "RING" arrive
after typing "AT"?
Kaspar
What would be the best medium for me to start shooting at it?
Shall I start an "issue", so that we can keep everything together?
Hi Kees,
> He Kees,
>
> > First of all, who is the maintainer of driver_at? In other words,
> > who should I be asking questions about this driver?
>
> As I'm the original author, I'd consider myself the author, but
> Vincent
> has contributed a lot. Asking on this mailing list was probably the
> best.
> Sorry for the delayed answer.
>
Sorry for the late answer!
I also contributed to this driver indeed, and wrote this part
originally. The idea was to find a simple way to parse URC and let the
user code decide when to parse them. The design is inspired by the AT
parser from MBED.
My understanding of the documentations from u-blox is that in between
the command echo and OK, there should not be any URC other than for the
given command. So parsing them in background while not doing anything
else should be fine.
The use-case and design have been discussed in [1] with @maxvankessel
who use this code in combination with the ring indicator interrupt.
As Kaspar said before, I'm also sure URC handling could be improved but
this might need a big rework of the UART interface and would involve
threads, which so far are kept out of this driver.
Anyway, do not hesitate to open an issue or a PR if the current code is
not good enough for you.
[1]: drivers/at: at out-of-band data support for at commands parser by vincent-d · Pull Request #8542 · RIOT-OS/RIOT · GitHub
I started an issue [1]. Let me know if this is a good way to approach
this.
[1]: https://github.com/RIOT-OS/RIOT/issues/9785