Re: [riot-devel] Driver AT, what is the concept of process_urc
On 13-08-18 10:04, Vincent Dupont wrote: Hi Kees, Le dimanche 12 août 2018 à 14:44 +0200, Kees Bakker a écrit : On 10-08-18 09:10, Kaspar Schleiser wrote: He Kees, On 08/05/2018 01:20 PM, Kees Bakker wrote: 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]: https://github.com/RIOT-OS/RIOT/pull/8542 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 -- Kees ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Driver AT, what is the concept of process_urc
Hi Kees, Le dimanche 12 août 2018 à 14:44 +0200, Kees Bakker a écrit : > On 10-08-18 09:10, Kaspar Schleiser wrote: > > He Kees, > > > > On 08/05/2018 01:20 PM, Kees Bakker wrote: > > > 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]: https://github.com/RIOT-OS/RIOT/pull/8542 -- Vincent Dupont ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Driver AT, what is the concept of process_urc
On 10-08-18 09:10, Kaspar Schleiser wrote: He Kees, On 08/05/2018 01:20 PM, Kees Bakker wrote: 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. 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? -- Kees ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Driver AT, what is the concept of process_urc
He Kees, On 08/05/2018 01:20 PM, Kees Bakker wrote: > 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), or maybe after receiving AT? Could someone with a modem on the desk try, e.g, does "RING" arrive after typing "AT"? Kaspar ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Driver AT, what is the concept of process_urc
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 On 05-08-18 13:20, Kees Bakker wrote: 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? ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] Driver AT, what is the concept of process_urc
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? -- Kees ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
