AT Command URC 相关咨询

发布于 2023-01-13 13:48:28 浏览：846 订阅该版

你好!
我是 RT-Thread 的初学者。
首先，请原谅我使用翻译器，因为我不懂中文。

非常感谢你上次的帮助。
不过这次又出问题了，站在初学者的角度解决不了，所以又写了一道题。
我真的很感激以下方面的任何帮助。

我目前正在尝试使用 ucr 功能，但它不起作用。
这是我作为初学者的看法，但是由于at_client_send是在前面的AT COMMAND终止之前（在收到OK之前）通过urc执行的，
我认为这可能会发生。(AT$$TCP_PPPOP后没有收到信息)

我不知道这是否是正确的问题......但如果有好的方法，请发表评论！

代码是：
```c
char* TCPIP;
uint8_t IP[22]={"192,168,0,199,2500"};
rt_sprintf(TCPIP, "AT$$TCP_ADDR=0,%s\r\n", IP);

rt_kprintf("TCPIP: %s, %d\r\n", TCPIP, strlen(TCPIP));
at_client_send(TCPIP, strlen(TCPIP));

/* URC */
static void urc_tcp_func()
{
	at_client_send("AT$$TCP_PPPOP", 13);
}

static void urc_scop_func()
{
	at_client_send("AT$$TCP_SCOP", 12);
}

static void urc_tcp_scop_func()
{
	LTE_debug("tcp_scop success!!\r\n");
}

static struct at_urc urc_table[] = {
	{"$$A_BOOT_ALERT",						"\r\n",		urc_conn_func},
	{"$$TELL:34,Modem Boot Up", 			"\r\n",		urc_conn_func},
	{"$$TCP_ADDR: 0", 						"\r\n",		urc_tcp_func},
	{"$$TELL: 600", 						"\r\n",		urc_scop_func},
	{"$$TCP_PPPOP: 0",						"\r\n",		urc_scop_func},
	{"$$TELL: 603",							"\r\n",		urc_tcp_scop_func},
	{"$$TCP_SCOP: 0",						"\r\n",		urc_tcp_scop_func},
};
```

LOG:
```text
[D/AT] sendline: 0000-0020: 41 54 24 24 54 43 50 5F  41 44 44 52 3D 30 2C 31  39 32 2C 31 36 38 2C 30  2C 31 39 39 2C 32 35 30    AT$$TCP_ADDR=0,192,168,0,199,250
[D/AT] sendline: 0020-0040: 30 0D 0A                                                                                              0..
[D/AT] recvline: 0000-0020: 0D 0A                                                                                                 ..
[D/AT] recvline: 0000-0020: 24 24 54 43 50 5F 41 44  44 52 3A 20 30 0D 0A                                                         $$TCP_ADDR: 0..
[D/AT] sendline: 0000-0020: 41 54 24 24 54 43 50 5F  50 50 50 4F 50                                                               AT$$TCP_PPPOP
[D/AT] recvline: 0000-0020: 0D 0A                                                                                                 ..
[D/AT] recvline: 0000-0020: 4F 4B 0D 0A                                                                                           OK..
```

我希望你有一个有趣和快乐的一天！ :)

ine 2023-01-16

这家伙很懒，什么也没写！

ine 2023-01-16

这家伙很懒，什么也没写！

ambrosiahoney 2023-01-17

这家伙很懒，什么也没写！

ine 2023-01-17

这家伙很懒，什么也没写！

ambrosiahoney 2023-01-17

这家伙很懒，什么也没写！

请登录后再发布评论，点击登录

追加回复

3 个回答

lchnu 2023-01-16

Witness, Understand, Skill

Hi, ambrosiahoney.

could you please describe your problem in English instead of using transalation? or you can use both English and translated chinese.

The following is my personal viewpoint:

In `client_parser` function, `at_recv_readline` is firstly invoked. If the incoming data is newline or URC data, the while(1) loop of at_recv_readline will be breaked, and then invoke `get_urc_obj` function.

According to your LOG4, the condition `newline` is triggered, therefore STM32 prints recvline, and then invokes `get_urc_obj` function.

Since the cmd_prefix `($$TCP_ADDR:0, )` and cmd_suffix `\r\n`(which is the newline indicator of `TCPADDR:0,` , rather than your truely expected suffix) are both correct, at client finds out the correct URC callback function `urc_tcp_func` and peforms the function by function pointer `urc->func(client,....)`.

After this callback is done (send `AT$$TCP_PPPOP` to module), at client receives the real echo of TCP_ADDR (`\r\n` or `OK\r\n`, not sure), which is your expected cmd_suffix, and finally shown in LOG6/LOG7.

I can't find the AT command manual of Teladin TX500, and not sure wether LOG6 or LOG7 is the correct echo of AT ADDR. If correct echo is LOG7 (OK\r\n), maybe you should modify URC_Table as follows:

```c
{"$$TCP_ADDR:0", "OK\r\n", urc_tcp_function}
```

ambrosiahoney 2023-01-17

这家伙很懒，什么也没写！

Thank you very much for the long sentence reply.
I'm not from an English-speaking country, so I'm using a translator for English too. So I'm sorry that the question is not smooth... T_T

```text
URC Sequence
SEND : AT$$TCP_ADDR=0,%s\r\n
RECV : $$TCP_ADDR
         ▼
SEND : AT$$TCP_PPPOP\r\n
RECV : $$TCP_PPPOP
		 ▼
SEND : AT$$TCP_SCOP\r\n
RECV : $$TCP_SCOP: 0
		 ▼
		 .
		 .
		 .
		 
		 
```

I think it should be logged like this
```c
[D/AT] sendline: AT$$TCP_ADDR=0,192,168,0,199,2500
[D/AT] recvline: ..
[D/AT] recvline: $$TCP_ADDR: 0..
[D/AT] recvline: ..
[D/AT] recvline: OK..

[D/AT] sendline: AT$$TCP_PPPOP
[D/AT] recvline: ..
[D/AT] recvline: $$TCP_PPPOP: 0
[D/AT] recvline: ..
[D/AT] recvline: OK..
				.
				.
				.
```

but current log
```c
[D/AT] sendline: 0000-0020: 41 54 24 24 54 43 50 5F  41 44 44 52 3D 30 2C 31  39 32 2C 31 36 38 2C 30  2C 31 39 39 2C 32 35 30    AT$$TCP_ADDR=0,192,168,0,199,250
[D/AT] sendline: 0020-0040: 30 0D 0A                                                                                              0..
[D/AT] recvline: 0000-0020: 0D 0A                                                                                                 ..
[D/AT] recvline: 0000-0020: 24 24 54 43 50 5F 41 44  44 52 3A 20 30 0D 0A                                                         $$TCP_ADDR: 0..
[D/AT] sendline: 0000-0020: 41 54 24 24 54 43 50 5F  50 50 50 4F 50                                                               AT$$TCP_PPPOP
[D/AT] recvline: 0000-0020: 0D 0A                                                                                                 ..
[D/AT] recvline: 0000-0020: 4F 4B 0D 0A                                                                                           OK..
```

I think OK should come out after log 4, but the problem seems to be caused by sending 'AT$$TCP_PPPOP' before OK.
It does not work after sending "AT$$TCP_PPPOP".

When i receive '$$TCP_ADDR: 0..', it is a string registered in the URC Table, so before 'OK' is received, it executes the 'urc_tcp_func' function to send 'AT$$TCP_PPPOP'.
so it's impossible to proceed after that.
I'm a beginner, so I don't know if I'm right, but... In this case, can i use URC Table?