RT-Thread / RT-Thread/rt-thread
echo发送给控制台所用串口字符串后控制台无响应 echo xxx /dev/uart0
Open
Nobody has claimed this yet.
- Dominant language
- C
- Stars
- 12.2k
- Forks
- 5.4k
- Avg merge
- 4d 12h
- Merged PRs (30d)
- 40
Description
echo发送给控制台所用串口字符串异常 echo xxx /dev/uart0
问题现象
- 正常使用控制台 交互情况下,控制台使用uart0
- 使用命令 echo XXX /dev/uart0 向uart0发送XXX,数据在控制台正常收到
- 但是再也无法进行交互
问题追踪 - 串口中断正常运行,但是控制台是直接从ops.getc取数据,而不是之前的FIFO
- 进一步追踪发现,echo调用了 fd = open(argv[2], O_RDWR | O_APPEND | O_CREAT, 0);,而这个里面执行了串口打开rt_serial_open(struct rt_device *dev, rt_uint16_t oflag),在这里有个传参oflag,直接在下文中对 dev->open_flag进行了赋值操作,而这个设备已经打开 重新打开却直接覆盖了标志位,原本开的串口中断未关闭 从而导致了本次异常
https://github.com/RT-Thread/rt-thread/blob/75f65b6af6e48f61e36e951aaa447bfc97e46773/components/drivers/serial/serial.c#L640
如果检测到设备已经打开是否应为直接获取设备句柄而不再进行打开动作
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with components/drivers/serial/serial.c around line 640 and reproduce the issue with echo XXX /dev/uart0 while using uart0 as the console. Trace rt_serial_open, open_flag, and the existing console input path to understand the repeated-open behavior. Done means sending data to /dev/uart0 does not leave the console unresponsive and interactive input continues to work.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- c
- Domain
- embedded-iot
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100