wiznet icon indicating copy to clipboard operation
wiznet copied to clipboard

WIZnet TCP/IP chips (such as W5500/W5100..) SAL framework implement.

Results 18 wiznet issues
Sort by recently updated
recently updated
newest added

wizchip_socket.c 中的`ctlsocket`应该改成`wizchip_ctlsocket`

测试的时候发现调用select函数会导致系统崩溃,要如何解决这个问题?非常感谢!!

在执行ping指令后,从启动到send都正常,只有在recv的时候,因为收不到中断回调,导致获取信号量失败,超时退出。这个你们有遇到过吗,怎么解决呢

使用了最新的RT-thread 4.1.0系统,总是报错如上。请教两个问题: 1.不清楚最新的wiznet2.0.0的代码中修改的头文件部分 ```c #ifdef RT_USING_SAL #include #include #endif /* RT_USING_SAL */ ``` 增加的`sal_low_lvl.h`文件在哪里?在rt-thread studio软件中添加软件包后无法自动下载下来,且wiznet2.0.0的代码中也么有这个。 2.咱们更新记录中说的适配5.0.0,是指适配什么组件的5.0.0?

问题: TCP通信,当使用单独的线程去收数据时,并且线程里只使用read函数,不使用select函数配合,代码如下: ``` while (1) { ret = read(sock, buf, 64); if (ret 0) { rt_mutex_take(sock->recv_lock, RT_WAITING_FOREVER); recv_len = wizchip_recv(socket, mem, len); if (recv_len > 0) { rt_mutex_release(sock->recv_lock); goto __exit;...

问题: 当在创建socket时,wiz_socket函数会去调用WIZ_INIT_STATUS_CHECK来检查物理上是否link up,并且accept函数里面也是,这就导致我不插网线时,无法创建socket。这种做法不符合通用的使用方法。 环境: RT-Thread Studio 2.1.2 wiznet latest

我仔细看了Wiznet的源码,没有发现源码使用rt_spi_bus_attach_device()函数将W5500挂载至SPI总线上,请问程序是如何实现挂载的?或者就没有挂载,要用户自己挂载?谢谢!

我在配置好wiznet组件后,使用命令行测试ping命令时发现ping命令ping完一次就卡住,命令行也无响应,debug后发现报NMI_Handle ![Snipaste_2021-06-10_16-11-45.png](https://oss-club.rt-thread.org/uploads/20210610/970024ddc54e1f6e1c500f56b207016b.png) 研究下报错的地方发现是wiz_do_event_changes中的sock没有正常初始化 ![image.png](https://oss-club.rt-thread.org/uploads/20210610/bf094221dd7a44ebe4967c7e911014be.png) 导致后续rt_wqueue_wakeup调用的时候程序跑飞 我在所有调用了wiz_do_event_changes添加了调试信息,输出如下: ![image.png](https://oss-club.rt-thread.org/uploads/20210610/36b280255ff99a10e5527674f3090183.png) 大概可以判断,wiz_do_event_changes被调用之前socket被关闭了,sock变量也被置零,在调用wiz_do_event_changes之前的wiz_recv_notice_cb函数里,有个释放信号量的地方: ![image.png](https://oss-club.rt-thread.org/uploads/20210610/9ad9963e38478926bcd810f24f227255.png) rt在执行rt_sem_release的时候会调用rt_schedule重新进行进程调度,而我的shell进程优先级比wiznet接收进程的优先级高: ![image.png](https://oss-club.rt-thread.org/uploads/20210610/6d56452902f118fcd5f4a2c4f4542074.png) 这导致shell执行的ping命令会抢占,而ping命令执行后会有wiz_closesocket关闭socket,执行完后再回到wiznet的接收线程里执行wiz_do_event_changes就报错,wiz_do_event_changes没有预防socket被关闭的操作,也就容易导致程序跑飞 我参考AT_Socket的方法,在wiz_closesocket加以延时: ![image.png](https://oss-club.rt-thread.org/uploads/20210610/dc59cb0ed566a7a1a5e103897d4c127a.png) 让wiz_do_event_changes在socket没被关闭前执行完,再执行ping命令就不报错了,算是简单解决了这个问题,但总感觉指标不治本 这个问题应该只会在shell进程优先级或者其他会执行closesocket的进程优先级大于wiz接收进程优先级的时候发生