回复了主题帖： TMS320F28P65外部晶振负阻测试

但为君故chris 发表于 2024-9-19 09:15 您好，请问一下可变电阻两端是接在 芯片与晶振连接的 X1和X2口吗 是的，我理解是这样，你可以试试看

回复了主题帖： TMS320F28P65外部晶振负阻测试

接在两个晶振线路之间，XI和XO

回复了主题帖： 立创·ESP32S3R8N8开发板

其实esp idf真的很好用，用习惯了，比python更顺手，生态也更完善

回复了主题帖： 幼儿园要求带月饼上学

我家娃儿没到中秋就惦记上吃月饼了

加入了学习《Follow me第二季第2期视频演示》，观看 演示视频

回复了主题帖： 编译错误的问题

再往前找第一个错误

回复了主题帖： [BearPi-Pico H2821]测评 ⑧拉距测试

目前hi2821的最远拉距测试是409米，在B站可以查到。 一般拉距测试建议去河边，或者田野这种宽阔，同时周边没有干扰信号的场所进行测试。

发表了日志： 国产以太网控制器CH390h试用体验----替代W5500

发表了主题帖： 国产以太网控制器CH390h试用体验----替代W5500

前言 W5500是一款集成了TCP/IP协议栈的以太网控制器，广泛用于嵌入式系统中，以实现网络通信功能。它通过SPI接口与微控制器（如STM32）进行通信，支持TCP、UDP、ICMP、IPv4、ARP、IGMP和PPPoE等多种网络协议 。 在使用的过程中，发现W5500发热量很大，价格也不便宜，封装尺寸也比较大。由于网络上并没有太多相关替代产品的信息，个人在购买了DM9051和CH390h的模块并测试后，发现CH390h应该是更好的国产替代产品。   一、实际产品对比照片   可以看到W5500的外围电路复杂度远远比CH390h的要大，并且由于 w5500的尺寸比CH390h要大得多。 二、传输速率对比 由于个人比较懒，没有直接用esp32测试w5500的带宽速率，在wiznet官网上可以查到w5500的性能测试数据，数据截图如下。   可以看到在使用STM32F103芯片，36Mhz的SPI情况下，最高速率在3.63Mbps （官方文章地址https://docs.wiznet.io/Product/iEthernet/W5500/Application/spi-performance） 而CH390h的测试速率如下，测试条件 ：主控esp32c6，SPI速率40Mhz，最高速率21.6Mbps，也就是7.7MBytes   虽然两者测试平台和方法有所不同，但是也可以看出CH390的性能已经比W5500要强。 通过搜索esp32 + W5500的iperf性能测试，也可以发现W5500的性能并未超越CH390，具体文章地址（https://forum.arduino.cc/t/spi-ethernet-iperf-speed-on-mega-and-esp32-wifi-and-lan8720/530429/2） 同时网络上也广泛流传有Wiznet的设备选型指南，W5500的最高速率是15Mbps ，参考文章地址（http://www.hschip.com/solution_view.aspx?typeid=63&id=412&fid=t25:63:25）   三、CH390H的最大socket连接数量 W5500的最大socket连接数量是8个，我这边最经常使用的就是esp32的websocket，但是由于 esp32的http server默认最大连接数是7个，只能测试是否达到7个。根据我的实际测试，确实可以同时打开7个websocket连接，第8个就连不上了。websocket是一种长连接协议，有延迟低和占用资源少的优点。   四、运行温度 由于我手上并没有红外测温仪，只能通过手摸来体验，三种芯片在接入网络的5小时后，温度体验如下：CH390H微温（比小孩发烧体温低），DM9051接近小孩发烧体温，W5500发烫（不能将手指长时间触摸） 五、价格 在价格方面，CH930h的淘宝价格4.9元（已购买模块和芯片，芯片与测试模块的外观一致），DM9051的零星采购价格12.7元，W5500的采购价格10.1元（淘宝优信） 总结  无论是从价格、性能、发热量、外围电路的对比，CH390H都是非常适合替代W5500的国产产品。至于CH390H是否能满足工业长期运行、稳定性如何 ，还需要进行长期测试才知道。WCH长期深耕各种转换芯片，以太网控制器也做了很多产品。在短暂的两天功能测试的过程中，静态IP，DHCP动态获取IP，插拔网线重新获取IP上线，性能测试和socket测试等等，都未发现有什么问题，接下来如果这个芯片在使用过程中遇到什么问题，会继续发帖分享。

回复了主题帖： 各位大佬，高手，留神看一呢呢，w5500官方驱动库编写连接上之后三四秒就接受不到数据

rzp 发表于 2024-9-10 14:07   还是一样   那就不清楚了

回复了主题帖： 各位大佬，高手，留神看一呢呢，w5500官方驱动库编写连接上之后三四秒就接受不到数据

W5500工作不正常，可以尝试在复位w5500设备后，延时10ms再做初始化等操作。试一下这个办法，之前esp32搞w5500，能工作，速率较低，就是这么修复的（延时配置后一切正常）。手上没高级示波器那些设备，不知道时序还是晶振启动慢的问题

回复了主题帖： SOT23-6这种封装，引脚很容易粘连

没发觉。。。助焊剂搞搞就得了

回复了主题帖： 【DigiKey“智造万物，快乐不停”创意大赛】3、使用lv_port_esp32适配1.69寸触摸屏

lion101 发表于 2024-9-5 23:14 楼主有空开微雪的工程 https://gitee.com/walker2048/esp32_169t/tree/master/2_throughput_test/lv_esp32 这个是之前无聊折腾的espnow吞吐量测试案例，适配的lvgl 9.1，最近暂时没空折腾，先看看这个能不能用

回复了主题帖： 【DigiKey“智造万物，快乐不停”创意大赛】3、使用lv_port_esp32适配1.69寸触摸屏

lion101 发表于 2024-9-5 01:18 编译cst816.c时报错，找不到vgl_i2c_conf.h 和tp_i2c.h 我用的是lvgl8.3,我看你用的是7.9。会不会和版 ... 8.3也可以不用lvgl的内置驱动吧，你是用微雪的板子还是自己做的？如果是微雪的，我晚点会开源一个工程

发表了主题帖： [经验分享] 「2024 DigiKey 创意大赛 」3、ESPNOW发送单包时间测试

前言 ESP-NOW（Espressif Now）是乐鑫（Espressif Systems）开发的一种快速、低功耗的无线通信协议，专为 ESP8266 和 ESP32 等 Wi-Fi MCU 设计。ESP-NOW 允许设备之间直接进行数据传输，无需通过传统的 Wi-Fi 网络连接。这种协议非常适合用于物联网（IoT）设备之间的快速通信，特别是在需要低延迟和高可靠性的应用场景中。   1、测试目的 由于ESPNOW的实现底层是未知的，我们也不知道在espnow发送数据时，底层的流程到底经过了什么。在本人使用espnow的过程中，发现现场环境的干扰越少，平均延时就越低。但是单包的延时时高时低，想知道在执行esp_now_send函数后，是否立即发送数据。   2、测试方法  通过在发送前记录发送时间，然后在发送完成的回调函数里，记录发送完成时间，这样就知道具体使用了多长的时间发送数据了。   接下来是在发送完成的回调函数里，记录完成时间，然后输出   3、结果 从结果上可以看出，espnow并不是想发就可以发的，正常发送一个60字长度的包，最短时间大概是1300us左右，而有时候一些包需要3ms左右才能发出，干扰严重的时候，甚至是十几ms才可以发出。目前使用的是广播模式发出数据，也就是不需要配对和连接设备就能发送，也不管其他设备是否收到了该数据。在这种模式下仍然不是想发就发，根据发送时间的异常长度猜测，和家庭里使用的无线路由，手机等等2.4G信号干扰有关。根据之前个人评测的espnow的实际丢包情况，个人觉得espnow应该是有防碰撞机制，也就是说当前信道若有设备还在发送数据时，espnow设备会延迟发送，直到通道无其他设备占用，才发送数据出去。    

回复了主题帖： 【DigiKey“智造万物，快乐不停”创意大赛】3、使用lv_port_esp32适配1.69寸触摸屏

lion101 发表于 2024-8-29 23:33 新手小白一枚，按照上面你的方法，把显示给搞定了，谢谢。触摸部分沿用你的方法，编译缺lvgl_i2c_conf.h和t ... 发一下具体报错的详细信息看看，我印象中没有这种错误

回复了主题帖： 【颁奖】全能小网关|CH32V208: BLE5.3+ USB2.0+ 10M Ethernet+ CAN + 4*UART

已确认个人收件信息

回复了主题帖： [BearPi-Pico H2821]测评 ⑥丢包及连接稳定性测试

短距离不丢包很正常

回复了主题帖： 【2024 DigiKey 创意大赛】二月柳絮大作战项目——物料开箱

idf可以直接用屏幕和板载外设，用其他的反而麻烦，arduino也可以，不过我不用

回复了主题帖： [BearPi-Pico H2821]测评 ⑤SLE client源码解读

我是ble和sle小白，问一下大佬，我想知道sle里，从机和主机任意一方想实现快速响应的数据发送，是通过什么方式处理呢？比方说不考虑最高吞吐量，仅仅考虑偶发的数据快速响应的情况下