问题:报错:RuntimeError: One or more background workers are no longer alive或者Case 之类的错误 解决:问题是出在对于label的制作,由于尺寸不一,在进行转换为nii数据的时候进行了resize,但是插值方式导致label不再是二值化的[0,255],因此在resize的时候选择邻近插值,保证label的二值化即可.

ait＋左shift＋NumLock 多试几次就好了

一、驱动相关概念 1.操作系统的功能 向下管理硬件，向上提供接口 操作系统向上提供的接口类型： 内存管理：内存申请（malloc） 内存释放（free）等 文件管理： 通过文件系统格式对文件ext2、ext3、 ext4格式进行管理 进程管理： 进程的创建/调度/消亡 网络管理： 通过网络栈协议，完成数据的收发 设备管理： 字符设备、块设备、网卡设备 2.驱动的概念 2.1.定义 驱动是能够让硬件实现某个特定功能的软件代码，根据驱动代码是否使用了系统内核提供的接口，将驱动分为裸机驱动和系统驱动 2.2.裸机驱动和系统驱动 裸机驱动：不基于操作系统提供的接口完成驱动的编写，这种驱动比较简单，由开发者独立即可编写完成，但是实现的功能比较单一 系统驱动（操作系统设备驱动）：编写驱动时调用系统内核提供的接口，驱动程序会被加载到内核空间。系统驱动开发者无法独立完成，需要操作系统内核的辅助，但是基于系统驱动完成的硬件控制工作会更加完善和复杂。 3.系统驱动（操作系统设备驱动）在操作系统中的层次 设备驱动会被加载到系统内核空间，设备驱动主要完成对硬件功能的实现，相当于拓展了系统内核设备管理的功能 4.设备驱动的类型 设备驱动的类型时根据设备类型的不同进行划分的，一般将设备分为字符设备、块设备、和网卡设备 三类： 字符设备：以字节流的形式进行顺序访问的设备叫做字符设备。 90%的设备为字符设备，鼠标、键盘、摄像头... 块设备：以块为单位进行随机访问的设备叫做块设备。块设备一般是一些磁盘设备 网卡设备：用于进行网络数据传输的设备。网卡设备没有网卡设备文件，想要读取网卡设备的数据，需要基于socket套接字实现 二、内核模块编程 1.内核模块编程的意义 驱动属于内核的一部分，驱动资源要加载到内核中，所以要按照内核模块的编程去编写框架 2.内核模块的三要素 入口：主要进行资源的申请工作，安装内核模块时执行 出口：主要进行资源的释放工作，卸载内核模块时执行 许可证：声明当前内核模块遵循GPL协议 3.内核模块编写实例及代码解释 #inckude <linux/init.h> #include <linux/module.h> //入口函数：安装内核模块时执行 static int __init mycdev_init(void) { //static: 修饰当前函数只可在本文件使用 //int：函数返回值类型，如果函数规定了返回值但是没有加返回值，编译会报错 //mycdev_init：函数名，可以自己命名 //void：表示函数无参数，void不可以省略 //__init：告诉编译器当前函数保存在.init.text段 #define __init sectoin(".init.text") //linux内核中有自己的链接脚本文件 vmlinux.lds，这个链接脚本文件规定了不同的内容存放在内存中的哪个位置 return 0; } //出口函数：卸载内核模块时执行 static void __exit mycdev_exit(void) { //__exit：告诉编译器当前函数保存在.exit.text段 #define __exit section("

一、supplementary 和complementary 由于意思相近、拼写相似，所以常常让人困惑，其实它们的意义差别明显。 supplementary 的意思是附加或补充……使之更好更完善，例如： The technical report needs supplementary references. （这份技术报告还需要补充参考文献。） The authors should add supplementary explanations for their experimental results.（作者还应该对他们的实验结果做补充解释。） A supplementary protocol is required to ensure security of the system.（还需要一个补充协议来保证系统安全性。） complementary 的意思是互补的，它的意义在集合论中最清晰： A is the complementary set of B.（A是B的补集。） 一个数的补码是complementary的同根词complement ，这是因为原码与补码对于模2的n次方是互补的。 例句： We argued that Protocol A is complementary to Protocol B.（我们论证了协议A和协议B相互补充即它们缺一不可。） Computers are complementary to human brains in the sense that the former possess powerful capability of computation and the latter possess that of reasoning.

一、什么是BootCDN BootCDN - Bootstrap 中文网开源项目免费 CDN 加速服务 BootCDN是一个开源的前端开发资源加速服务，它为开发者提供了一种快速、稳定的前端资源加载方式。BootCDN基于CDN（内容分发网络）技术，通过将前端资源部署在全球各地的服务器上，使得用户可以从离自己最近的服务器获取资源，从而提高资源加载速度和用户体验。 二、BootCDN的特点和优势 1. 快速稳定：BootCDN通过全球多个节点服务器分发资源，用户可以从离自己最近的服务器获取资源，从而提高资源加载速度和稳定性。 2. 开源免费：BootCDN是一个开源项目，任何人都可以免费使用和贡献。这使得开发者可以方便地获取和使用各种前端资源，同时也可以为项目贡献自己的资源。 3. 多种资源支持：BootCDN支持多种类型的前端资源，包括CSS、JavaScript、字体等。开发者可以根据自己的需求选择合适的资源进行加载。 4. 版本管理：BootCDN支持多个版本的前端资源，开发者可以根据自己的需求选择合适的版本进行加载。这使得开发者可以方便地切换和管理不同版本的资源。 5. 自定义加载：BootCDN支持自定义加载，开发者可以根据自己的需求选择需要的资源进行加载。这使得开发者可以根据项目的具体情况进行资源加载的优化。 三、如何使用BootCDN 1. 引入BootCDN资源：在HTML文件中引入BootCDN提供的资源链接，例如： <link rel="stylesheet" href="https://cdn.bootcdn.net/ajax/libs/bootstrap/5.1.0/css/bootstrap.min.css"> <script src="https://cdn.bootcdn.net/ajax/libs/jquery/3.6.0/jquery.min.js"></script> 2. 使用BootCDN提供的资源：在页面中使用引入的资源，例如： <button class="btn btn-primary">Click me</button> 4. 测试和调试：在浏览器中打开页面，测试资源加载和使用效果，并进行必要的调试。 四、BootCDN的应用场景 1. 加速资源加载：BootCDN通过全球多个节点服务器分发资源，可以加速前端资源的加载速度，提高用户体验。特别是对于一些大型的前端框架和库，如Bootstrap、jQuery等，使用BootCDN可以加速其资源的加载。 2. 资源版本管理：BootCDN支持多个版本的前端资源，开发者可以根据自己的需求选择合适的版本进行加载。这对于项目的升级和维护非常有帮助，可以方便地切换和管理不同版本的资源。 3. 跨域资源加载：由于浏览器的同源策略限制，有时候我们需要加载其他域下的资源。BootCDN提供了跨域资源加载的支持，开发者可以方便地加载其他域下的资源。 4. 自定义加载：BootCDN支持自定义加载，开发者可以根据自己的需求选择需要的资源进行加载。这使得开发者可以根据项目的具体情况进行资源加载的优化，减少不必要的资源请求。 五、总结 BootCDN是一个开源的前端开发资源加速服务，通过全球多个节点服务器分发资源，提供快速、稳定的前端资源加载方式。BootCDN具有快速稳定、开源免费、多种资源支持、版本管理和自定义加载等特点和优势。开发者可以通过引入BootCDN提供的资源链接来加速资源加载，并在页面中使用这些资源。BootCDN的应用场景包括加速资源加载、资源版本管理、跨域资源加载和自定义加载等。通过使用BootCDN，开发者可以提高前端资源加载速度，优化项目的资源管理，并提升用户体验。

CentOS Cockpit 开启 root 用户登录权限 安装的 CentOS 虚拟机，装完某些包后在终端一直提示开启 Cockpit，心痒试了一下，但是在登录是时候提示 root 用户密码错误，肯定是默认被禁用了，就是不知道在哪配置，搜了半天没命中关键词，最后在 GitHub 找到答案了，这里记录一下，当然，在生产环境不能这么干。 keyword : CentOS Cockpit 默认 root 账号禁用 登录失败 解决方法 解决方法： $ vim /etc/cockpit/disallowed-users # List of users which are not allowed to login to Cockpit # root 参考： Can not login by default root user on Debian11 · Issue #18427 · cockpit-project/cockpit

2024年第四届消费电子与计算机工程国际学术会议（ICCECE 2024） 2024 4th International Conference on Consumer Electronics and Computer Engineering 进入21世纪以来，计算机技术的高速发展带来了消费电子产品的快速更迭。在技术迅速发展历程中，众多高校与企业研发了许多相关技术和产品，取得了丰硕学术和应用成果。2024第四届消费电子与计算机工程国际学术会议将于2024年1月12-14日在中国广州召开。本次会议主要围绕消费电子发展、网络信息安全、人工智能、物联网等研究领域展开讨论。大会将就目前的热点问题展开研讨，共享研究成果，推动相关研究与应用的发展与进步，推进学科的发展和促进人才培养。我们诚挚欢迎相关领域中的相关各个专家学者踊跃参会。 重要信息 大会官网：www.iccece.org（点击参会/投稿） 大会地点：中国·广州 大会时间：2024年1月12-14日 收录检索：EI/SCOPUS 征文主题 ICCECE 2024 将征集并展示高质量的最新研究成果文章，并将组织相关的主题研讨。会务组诚邀世界各地的专家学者提交您最的论文，并与其他参会者分享您的成果与经验。征文主题包括但不限于: Track I：消费电子发展与应用 （汽车CE应用，信号和图像处理，CE中的机器学习，深度学习和AI等） Track II：计算机与网络信息安全 （信息系统，互联网和边缘计算，区块链协议的安全性，计算机的安全性和隐私等） Track III：人工智能与机器学习 （人工智能，人机交互和用户体验，虚拟现实，增强现实和显示，计算机视觉与图像处理等） Track Ⅳ：物联网与传感器技术 （物联网，传感器和执行器系统，音频/视频系统和信号处理，射频，无线和网络技术等） ... ... 更多征稿主题，请查看大会官网 论文评审 所有投稿将有3轮评审。组委务将首先进行初步审核，在这一阶段，将审核文章结构主题方向是否符合要求。通过初审审核的每篇文章将提交2-3位独立审稿人进行同行评审，审稿人将根据论文集要求，预定的标准，文章创新性，完整性以及语法等评估文章作出评定。 投稿要求 1. 文章必须用英文书写； 2. 文章须按照会议模板排版； 3. 文章主题须符合会议征文主题； 4. 文章页数不少于4页； 5. 文章应是原创且从未公开发表； 6. 文章应具有一定创新性和科研性。 出版信息 ICCECE 2024所有的投稿都必须经过2-3位组委会专家审稿，经过严格的审稿之后，最终所有录用的论文进行出版，见刊后由出版社提交至EI, Scopus检索。 参会方式 ○主讲嘉宾：申请主题演讲，由组委会审核。 ○口头报告：论文一经录用即可注册参会发表口头报告，时间为15分钟，含问答环节。无投稿亦可报名申请。 ○海报展示：论文一经录用即可注册参会展示海报，海报尺寸为A1。无投稿亦可报名申请。 ○听众参会：无需提交稿件，直接注册听众参会即可。

一、线程池的概念和作用 线程池是一种用于管理和重用线程的机制。它允许你创建一个线程池，然后将任务提交给这个线程池，线程池会自动分配线程来执行这些任务。 线程池的作用是优化线程的管理和资源利用，以减少线程创建和销毁的开销，提高系统的性能和响应速度。 二、线程池的参数 如果是在 Spring 中，可以用 ThreadPoolTaskExecutor 配合 @Async 注解来实现。（不太建议） 如果是在 Java 中，可以使用 JUC 并发编程包中的 ThreadPoolExecutor 来实现非常灵活地自定义线程池。 线程池参数： public ThreadPoolExecutor(int corePoolSize, //核心线程数 int maximumPoolSize, //最大工作线程数 long keepAliveTime, //非核心线程存活时间 TimeUnit unit, //时间单位 BlockingQueue<Runnable> workQueue, //阻塞队列 ThreadFactory threadFactory, //线程工厂 RejectedExecutionHandler handler //拒绝策略 ) { 如何确定线程池的参数？ 结合实际情况（实际业务场景和系统资源）来测试调整，不断优化。 corePoolSize（核心线程数）：正常情况下，我们的系统应该能同时工作的线程数（随时就绪的状态） maximumPoolSize（最大线程数 ）：极限情况下，我们的线程池也最多有这么多的线程。 keepAliveTime（空闲线程存活时间）：非核心线程在没有任务的情况下，过多久要删除（理解为开除临时工），从而释放无用的线程资源。 TimeUnit unit（空闲线程存活时间的单位）：分钟、秒 workQueue（工作队列）：用于存放给线程执行的任务，存在一个队列的长度（一定要设置，不要说队列长度无限，因为也会占用资源） threadFactory（线程工厂）：控制每个线程的生成、线程的属性（比如线程名） RejectedExecutionHandler（拒绝策略）：任务队列满的时候，我们采取什么措施，比如抛异常、不抛异常、自定义策略。 常见的拒绝策略： AbortPolicy（默认）：这是默认的拒绝策略。当线程池的任务队列已满，且线程池中的线程数已达到最大值时，新任务将被立即拒绝，并抛出RejectedExecutionException异常。这是一种宁可抛出异常也不丢失任务的策略。 CallerRunsPolicy：在这个策略下，当任务被拒绝时，会由提交任务的线程自己来执行这个任务。这意味着如果线程池被拒绝接受新任务，提交任务的线程将尝试执行该任务，从而减缓任务提交的速度。 DiscardPolicy：这个策略下，新任务会被默默地丢弃，不会抛出异常，也不会被执行。这可能会导致任务的丢失。 DiscardOldestPolicy：当任务被拒绝时，这个策略会丢弃任务队列中最老的任务，然后尝试再次提交新任务。这可以减少任务丢失的可能性，但可能会导致某些较旧的任务被丢弃。 自定义策略：除了上述内置策略，你还可以实现自定义的拒绝策略，以满足特定需求。你可以实现RejectedExecutionHandler接口，然后根据自己的逻辑来处理被拒绝的任务。 三、线程池如何工作？ 假设核心线程数是：2 最大工作线程数是：4 任务队列大小为：5 下面分析线程池的工作过程： （1）初始状态时，还没有任务的时候，线程池中是空的，没有线程。 （2）当来了一个任务时，任务数=1，此时就会创建一个核心线程来处理，核心线程数=1， 任务数=2时，再创建一个核心线程，核心线程数=2。此时核心线程数满了。 （3）此时如果再来一个任务，并不会创建线程来处理。而是放到任务队列中。

文章目录 1. 网络结构模式C/S结构B/S结构 2. MAC地址3. IP地址简介IP地址编址方式 4. 端口简介端口类型1.周知端口（Well Known Ports）2.注册端口（Registered Ports）3.动态端口 / 私有端口（Dynamic Ports / Private Ports） 5. 网络模型OSI七层参考模型TCP/IP四层模型简介四层介绍 6. 协议简介常见协议UDP协议TCP协议IP协议以太网帧协议ARP协议 7. 封装与分用封装分用 8. socket介绍9. 字节序字节序举例通过代码检测当前主机的字节序字节序转换函数 10. socket地址通用socket地址专用socket地址 11. IP地址转换（字符串ip-整数 ，主机、网络字节序的转换）12. TCP通信流程13. TCP通信过程中的函数14. TCP通信实现服务器端客户端 15. TCP三次握手16. TCP滑动窗口17. TCP四次挥手18. 多进程实现并发服务器服务器端程序客户端程序 19. 多线程实现并发服务器服务器端程序 20. TCP状态转换21. 端口复用22. I/O多路复用（I/O多路转接）23. select24. poll25. epoll26. epoll的两种工作模式27. UDP27.1 UDP通信 1. 网络结构模式 C/S结构 简介 服务器 - 客户机，即 Client - Server（C/S）结构。C/S 结构通常采取两层结构。服务器负责数据的管理，客户机负责完成与用户的交互任务。客户机是因特网上访问别人信息的机器，服务器则是提供信息供人访问的计算机。客户机通过局域网与服务器相连，接受用户的请求，并通过网络向服务器提出请求，对数据库进行操作。服务器接受客户机的请求，将数据提交给客户机，客户机将数据进行计算并将结果呈现给用户。服务器还要提供完善安全保护及对数据完整性的处理等操作，并允许多个客户机同时访问服务器，这就对服务器的硬件处理数据能力提出了很高的要求。在C/S结构中，应用程序分为两部分：服务器部分和客户机部分。服务器部分是多个用户共享的信息与功能，执行后台服务，如控制共享数据库的操作等；客户机部分为用户所专有，负责执行前台功能，在出错提示、在线帮助等方面都有强大的功能，并且可以在子程序间自由切换。 优点 能充分发挥客户端 PC 的处理能力，很多工作可以在客户端处理后再提交给服务器，所以 C/S 结构客户端响应速度快；操作界面漂亮、形式多样，可以充分满足客户自身的个性化要求；C/S 结构的管理信息系统具有较强的事务处理能力，能实现复杂的业务流程；安全性较高，C/S 一般面向相对固定的用户群，程序更加注重流程，它可以对权限进行多层次校验，提供了更安全的存取模式，对信息安全的控制能力很强，一般高度机密的信息系统采用 C/S 结构适宜。 B/S结构 简介

git stash命令用于保存当前工作目录的临时状态，包括暂存区和已修改但未暂存的文件。它会将这些修改保存在一个临时区域（即“堆栈”）中，让你能够回到一个干净的工作目录，可以进行其他操作。等到你完成其他任务后，可以再回到之前的状态，继续之前的开发。 使用场景 切换分支： 当你正在开发一个功能或修复一个bug，但需要切换到另一个分支来处理其他任务时，使用git stash可以将当前的修改保存起来。这样你可以切换到其他分支并开始另一个任务，而无需提交或放弃你当前的修改。 合并代码： 在进行代码合并操作之前，你可能需要切换到目标分支并更新代码。使用git stash可以保存当前分支的修改，然后切换到目标分支并执行更新操作。完成后，你可以切换回原分支，并使用git stash pop来恢复之前的修改。 临时修复问题： 如果你遇到一个紧急的问题，需要快速切换到其他分支进行修复，但又不想丢失当前的修改，可以使用git stash将修改保存起来。然后你可以切换到修复分支，并在修复完成后再回到原分支恢复之前的修改。 多任务处理： 在开发过程中，你可能会同时处理多个任务或功能。当你想切换到另一个任务时，可以使用git stash将当前任务的修改保存起来，然后切换到另一个任务并开始工作。完成后，你可以回到之前的任务并使用git stash pop来恢复修改。 代码审查： 在进行代码审查时，你可能需要将修改保存起来，以便在审查过程中进行对比和讨论。使用git stash可以暂时保存你的修改，并切换到源代码分支进行对比和审查。 以下是git stash命令的用法和一些常见的选项： git stash save "message" 这将保存当前的工作目录状态到一个新的stash，并添加一条可选的消息来描述这个stash的内容。 git stash list 查看当前保存的所有stash列表，每个stash都有一个唯一的标识符和对应的描述信息。 git stash show [stash] 查看某个特定stash的变更内容。默认情况下，会显示最新的stash。 git stash apply [stash] 将某个stash的变更应用到当前工作目录。这个stash不会从stash列表中移除。如果不指定stash，默认会应用最新的stash。 git stash pop [stash] 与git stash apply类似，但在应用完stash后会将该stash从stash列表中删除。 git stash drop [stash] 删除某个stash，从stash列表中移除。如果不指定stash，默认会删除最新的stash。 git stash clear 删除所有的stash，慎用，它会清除所有保存的stash记录。 git stash branch <branch_name> [stash] 创建一个新分支并将某个stash中的变更应用到新分支上。这样可以在一个干净的环境中继续开发。 git stash -p 交互式地选择要保存的修改，即对每个修改进行确认。

使用浮点型参与计算 func main() { // 使用浮点型参与计算 var f1 float32 f1 = -3.0 / 2 fmt.Println(f1) x := 8 if x > 5 && x < 10 { //go语言运算符不能连用 fmt.Println("x在5-10之间") } } 逻辑运算符 && || ! func main() { a := 3 b := 2 c := 0 if (a < b) && (a/c > 0) { fmt.Println("短路运算") } } 自增、自减 func main() { sc := 9 sc++ sc-- fmt.Println(sc) } 运算符

基本数据类型 整型、浮点型、复数、布尔类型、字符串、字符类型（byte、rune） /* uint8 无符号 (0-255) uint16 (0-65535) uint32 int8 有符号 () int16 int32 int64 int 操作系统 32 -- int32 操作系统 64 -- int64 float32 float64 */ var a int8 var b uint8 var c uint8 整型 func main() { // 整型 a = 200 fmt.Println(a) //无符号8位整型 注意计算 溢出 b = 1 c = 2 fmt.Println(b - c) // 进制表示 bin_num1 := 0b11 oct_num2 := 0o11 hex_num3 := 0x11 fmt.

输入输出 1. fmt 是 go 语言中的格式化输入输出库，其中主要分为两个部分，分别是输出部分和输入部分。 输入部分 func main() { //输入 fmt.Scan fmt.Scanf fmt.Scanln var a int var b string fmt.Println("请输入a和b：") //&a 获取a的内存地址 //接受用户的输入，空格分割，分别传给a和b fmt.Scan(&a, &b) fmt.Println("a is :", a, ", b is :", b) //严格按照指定的形式输入 fmt.Scanf("a=%d,b=%s", &a, &b) fmt.Println("a is :", a, ", b is :", b) //以换行符来结束这次输入 fmt.Scanln(&a, &b) fmt.Println("a is :", a, "b is :", b) print("test print") //错误输出 fmt.Println("test fmt println") } 输出部分 func main() { //输出 // fmt.

一、引言 首先需要实现android13设置静态IP的功能，就要对android13以太网架构变化大致理解，谷歌把以太网相关的功能进行模块化，提取到packages/modules/Connectivity/目录，导致之前的实现需要调整，本文主要从2大块进行阐述，分别为framework与原生Settings。 本文涉及功能点主要有如下几点： 1.设置IP的方式分为DHCP和静态两种 2.IP地址的设置 3.子网掩码设置 4.DNS设置 5.网关设置 6.代理设置 二、Framework部分 2.1、涉及修改的类 packages/modules/Connectivity/framework-t/api/module-lib-current.txt packages/modules/Connectivity/framework-t/src/android/net/EthernetManager.java packages/modules/Connectivity/framework-t/src/android/net/IEthernetManager.aidl packages/modules/Connectivity/framework/api/current.txt packages/modules/Connectivity/framework/api/system-current.txt packages/modules/Connectivity/framework/src/android/net/IpConfiguration.java packages/modules/Connectivity/framework/src/android/net/ProxyInfo.java packages/modules/Connectivity/service-t/src/com/android/server/ethernet/EthernetNetworkFactory.java packages/modules/Connectivity/service-t/src/com/android/server/ethernet/EthernetServiceImpl.java packages/modules/Connectivity/service-t/src/com/android/server/ethernet/EthernetTracker.java 2.2、涉及类修改阐述 android其实不管怎么更新，都离不开client-aidl-server这样的模式，所以大体思路就是根 据以太网源码框架，在其上模仿原有的接口进行添加内容的方式，先把路打通。 2.2.1、客户端接口添加及修改 1.IEthernetManager.aidl类中添加4个接口，提供给上层使用 /* * Copyright (C) 2014 The Android Open Source Project * * Licensed under the Apache License, Version 2.0 (the "License"); * you may not use this file except in compliance with the License. * You may obtain a copy of the License at * * http://www.

不会吧，不会吧，都21世纪了，不会还有人不会用Python来免费听歌吧！ 来来来，今天我们用Python试试怎样去随便下载自己想要的音乐，付费也拦不住我，Python说的！ 这是要用到的模块 1、requests 2、prettytable 这是使用的环境 1、python 3.8 2、pycharm 2021.2 大致流程思路 一、分析网站(思路分析) 1、搜索歌曲功能 通过关键词搜索对应的 歌曲名称 歌手名称 专辑名称 2、下载歌曲功能 明确 免费的音乐怎么下载 我们才会明白 付费的音乐是怎么来的 二、搜索功能代码实现 1、向 目标网站 发送网络请求 2、获取数据 3、提取数据 (歌曲名称 歌手名称 专辑名称) 4、格式化打印数据 三、下载歌曲实现 分析这个链接从哪里来的 我知道你们最想看的就是代码了，所以解释我都写到注释去了，大家直接看代码（留了个小报错，看看聪明的你能不能看出来） 来人，上代码 from urllib.parse import quote import requests # 发送网络请求的模块 import prettytable as pt # 格式化输出表格 as pt # 1. 向 目标网站 发送网络请求 # 请求方式: get post delete... # 加一些伪装 伪装就已经准备好了 # 快捷替换小技巧 # 1. 选中要替换的内容 # 2.

目录 一，规则 二，每日拼图 2022年2月 2022年3月 竖条下滑问题 2022年4月 2022年5月 2022年6月 三，术语 四，启发式搜索策略 1，数独 2，策略一 3，策略二 4，策略三 5，策略四 6，策略五 7，策略六 五，数字化 1，读取图片并二值化 2，边缘检测 3，轮廓检测 4，求解格子尺寸、坐标 5，计算有效轮廓数量 6，坐标微调 7，手动删减轮廓 8，解析空出来的3个格子 8，连通性计算 9，完整代码 六，以解生解 1，大拇指 2，可视化 3，U型 4，新解 5，日期汇总 6，完整代码V1 7，BUG修复 8，日期优化（完整代码V2） 9，BUG修复、新增检查（完整代码V3） 七，说明 八，直接求解 1，可视化V2版 2，直接求解 一，规则 每天根据月、日、星期去掉3个格子，剩下的格子刚好全部覆盖。 日历拼图有两千多组合，如果所有组合都能拼的话，那真的太神奇了。 二，每日拼图 2022年2月 根据下面的数字化的方法，2022年2月1日-2月28日的答案分别是： 2月1日周二 1 0 1 8 2 2 0 1 1 1 8 8 2 0 0 3 3 9 8 2 2

一、数字信号处理（digital signal processing ，DSP) 20世纪中在连续时间信号处理的基础上发展起来的工程和科学技术以微积分、差分方程、现行表示等数学知识为基础用离散序列的方式表征信号采用数字系统处理信号提取信号中携带的有用信息近年来，随着集成电路、数字电路、计算机等数字技术的飞速发展得到广泛应用 二、信号 2.1 信号 信号是信息的载体。 2.2 信号分类 信号可按照确定性、信号维数、连续性等分类。 按确定性分类 随机信号 未可预知但又服从一定统计特性的信号，又称不确定信号。 确定信号 可以用明确的数学关系表示或者图表描述的信号称为确定信号，或者说：可以表示为确定的时间函数，可以确定其任何时刻的量值。 按维数分类 一维信号f(x) f(x): 语音、电压、电流信号等 二维信号 f(x,y): 图像信号 三维信号 f(x,y,z): 立体图像信号等 按连续性分类 自变量为连续值的信号称为连续信号 自变量为离散值的信号称为离散信号 自变量和函数值均为连续值的信号称之为模拟信号 自变量和函数值均为离散值的信号称之为数字信号 三、系统 系统是对信号进行处理实现某种功能的物理设备

本文纯属本人个人感悟，如有错误，欢迎指正交流； 主机 是指master而非电脑主机； I2C协议在嵌入式中应用十分广泛，但是你有没有想过，为什么I2C要设计成这样？为什么读从设备寄存器数据的时候要发送两遍start信号？为什么从设备可以拉低时钟线等等。 首先，为什么start信号是：SCL高电平时，主机将SDA拉低？ 要想分析这个问题不妨做一个假设，比如我现在要定义新的I2C规范，start信号改成：SCL高电平时，主机将SDA释放为高电平，可以吗？当然可以，因为从机一直是开漏输出，从机不停的检测SCL和SDA两根线的电平高低，那么初始SDA线为低电平，start信号后SDA线变成了高电平，从机一定可以检测到，那这个电平的变化就可以定义成一种新的start信号； 那为什么真正的I2C协议没有这么做呢？很简单，比如一般的GPIO口，输出高电平时只要下面的NMOS管关闭就可以了，没有功耗；而要是输出低电平呢？那NMOS就一直要打开，换言之一直有电流通过，无论是功耗的增加还是发热问题，都是我们不希望看到的；因此I2C的SDA和SCL线在空闲状态时都是高电平。 紧接着我们回顾一下I2C通信协议的具体内容，首先是写： 第一步发送start信号；第二步发送写设备地址，第三步发送写寄存器地址，第四步发送写入的数据；读的步骤是这样的：第一步发送start信号，第二步发送写设备地址，第三步发送写寄存器地址，第四步再发送一个start信号，第五步发送读设备地址，第六步接收从机发送过来的数据。 对比读和写的过程不难发现，读操作的前半部分和写操作是一样的，但是紧接着读操作又发送了一个start信号，为什么要发送两遍start信号？ 这个问题并不难，正如上面所说的，读操作的前半部分和写操作是一样的，如果不再次发送start信号的话，主机发送的下一个字节就会被从机当作是数据，而不是读设备的地址了。 可见，读操作中发送两遍start信号是必要的，那么读操作的大致流程如下： 主设备：XXX这个地址的设备在不在？ XXX地址从设备： 来了老弟 主设备：AXXX这个寄存器地址你有吧？ XXX地址从设备： 有的 主设备：发送start （意思是我要读数据啦） 主设备：发送读设备地址 XXX地址从设备： 回复数据 这个流程乍一看没有问题，但是如果你仔细思考一下，说不定会与我有一样的疑惑：“主机发送读设备地址”这个步骤不是多余的吗？ 毕竟主设备发完start、从设备地址、寄存器地址、start信号后就已经可以区分写操作，表明自己是读操作了呀？如果我是I2C协议的设计者的话，去掉这个“多余”的步骤，不是更简洁易记，并且能提高通信速度吗？ 事情并没有那么简单；我们回过头来仔细看一下，I2C协议中规定：无论是主机还是从机，发送完一个字节（8bit)数据后，另一方都要给一个ACK信号，也就是应答信号，这就保证了数据传输的准确性；但是唯独start信号是没有应答的！ 比方说现在主设备要写从设备的某个寄存器，上来就发一个start信号，start信号后是什么状态？SCL和SDA都是被主机拉低的状态！这时候从机是没有任何的话语权的，即便从机没有准备好，即便是从机不愿意，也“没有办法表达”，因为两根线都被主机拉低了呀！但是在写操作中，这根本不会造成问题，为什么？因为start信号后，主机还要发送设备地址、寄存器地址等等，如果从机此时在执行其他的指令，就不会拉低SDA线，也就不会产生应答信号，主机一看：喔没有应答，终止（有内鬼！终止交易！）。 但是在读操作中，情况就不一样了；主机还是发start，发设备地址，发寄存器地址，假设从机这时候没有任何问题，表示：没错 这个设备地址是我，没错，这个寄存器地址我有；但问题是从机这时候压根不知道主机是想写数据还是读数据呀！那么可能从机的缓冲区并没有准备好，也就是没有做好发送数据的准备，这时候紧接着主机的第二个start信号过来了，假设主机不需要再发送读设备地址而是直接判断SDA电平接收数据，那么会发生什么？ 从机并没有准备好，但是SCL和SDA都是被主机拉低的状态，从机有苦说不出呀！可是主机并不知情，它先是释放SDA线，然后开始SCL线上时钟照旧，SCL每个上升沿采样SDA电平······，那不用说，数据全是FFFFFFFFF······ 而且主机永远意识不到——这个数据是错的，从机根本没有再发送数据； 那真正的I2C协议呢？读操作的第二个start信号后，主机还要发送一个读设备地址给从机，这就是在询问从机，我要读数据，并且准备好接受了，你准备好发送了吗？这样从设备就有了话语权，从设备发送一个ACK，主机就知道：喔从机准备好了，我可以开始发送时钟，采样数据了；相反的，从设备没有发送ACK，那么主机就不会再盲目地往下进行了。 这样解释真的无懈可击了吗？并不是；不要忘了，从机还有个“杀手锏”，那就是强行拉低SCL线来暂停主机的时钟，从而暂停数据传输，即Clock Stretching；那要这么说的话，“主机发送读设备地址”这个步骤不还是多余的嘛，毕竟从机没有准备好的话，在start信号后直接拉低SCL线就好了嘛； 这个问题的分析首先我要引用一段说明，来自维基百科的I2C页面介绍： One of the more significant features of the I²C protocol is clock stretching. An addressed slave device may hold the clock line (SCL) low after receiving (or sending) a byte, indicating that it is not yet ready to process more data.

目录 一、RTL8723DS WiFi 适配 --- 篇章1、原理图分析（WiFi部分）`补充:`RTL8723DS时钟输入源讲解 2、根据原理图修改设备树和编辑驱动文件3、实验验证4、RTL8723DS WIFI驱动参考文档和博客网站 二、RTL8723DS 蓝牙Bluetooth 适配 --- 篇章1、原理图分析（蓝牙Bluetooth部分）2、根据原理图修改设备树3、修改蓝牙相关的配置4、RTL8723DS 蓝牙Bluetooth驱动参考文档 瑞芯微RK系列对“REALTEK瑞昱公司”的wifi、蓝牙双模的模组都有内置适配的，因此HAL层、Framework层、协议栈及库文件都不需要移植适配，只需修改设备树和一些配置文件即可。 一、RTL8723DS WiFi 适配 — 篇章 1、原理图分析（WiFi部分） 补充:RTL8723DS时钟输入源讲解 RTL8723DS模组的第24号引脚是模组的时钟输入源，需要给此提供1.8V~3.3V，32KHz的输入源。由原理图可知，提供时钟输入源的是RK808 CLK32KOUT1引脚提供的外部32KHz时钟。因此需要添加： clocks =<&rk808 1>; clock-name = "ext_clock"; PATCH文件和规格书和参考文档👈 — 提取码：baeg 2、根据原理图修改设备树和编辑驱动文件 由原理图可以看出，板子上使用的RTL8723DS模块WIFI部分的接口是SDIO接口的，因此在设备树上修改对应的GPIO即可。 Ⅰ、首先打开对RTL8723DS模块的供电，也就是WL_ON引脚->GPIO8_A4，先需要使用pinctrl将其复用成GPIO功能，然后将其WL_ON引脚拉低电平，让其P-MOS管导通，处理方法如下图所示： 我这在HD_gpio_control.c这个GPIO驱动程序上初始化GPIO8_A4，默认拉低电平，如下图所示，这里随意写个驱动即可。 Ⅱ、修改sdio0设备树节点，如下图所示： 将RTL8723DS驱动添加到内核吗，如下图所示： Ⅳ、修改make menuconfig，如下图所示： 3、实验验证 通过以上配置，基本驱动移植就配置好了，如下图所示： 4、RTL8723DS WIFI驱动参考文档和博客网站 博客参网站👈 路径：a\RKDocs\android\wifi\Rockchip_Introduction_REALTEK_WIFI_Driver_Porting_CN&EN.pdf和a\RKDocs\android\wifi\Rockchip_Introduction_WIFI_Configuration_CN&EN.pdf 二、RTL8723DS 蓝牙Bluetooth 适配 — 篇章 1、原理图分析（蓝牙Bluetooth部分） 上图黄色框框就是本次蓝牙功能适配需要关注的引脚接口。 2、根据原理图修改设备树 3、修改蓝牙相关的配置 diff --git a/device/rockchip/common/init.connectivity.rc b/device/rockchip/common/init.connectivity.rc index 40fa8d31b2..66c4abf930 100755 --- a/device/rockchip/common/init.connectivity.rc +++ b/device/rockchip/common/init.connectivity.rc @@ -17,16 +17,16 @@ on zygote-start chown bluetooth net_bt ro.

摘要 火山引擎智能拥塞控制算法 VICC（Volcano Intelligent Congestion Control）是一种自适应的拥塞控制算法，旨在解决全球不同网络环境下，不同音视频应用对带宽利用率和延时的差异化要求。它结合了传统拥塞控制算法（如 GCC 和 BBR）的优点，并且能够根据不同的网络条件、业务偏好和码率特征进行自适应调整，包括自适应拥塞响应速度、自适应带宽探测幅度、自适应丢包检测策略、自适应抗抖动能力和自适应 Padding。通过这些自适应调整，VICC 算法能够提升各种复杂弱网下的带宽利用率，同时在满足不同延时的条件下，尽量提升带宽的稳定性，为用户提供更好的音视频体验。 1. 行业现状和挑战 实时音视频应用的网络传输面临诸多方面的挑战，其中包括： 带宽利用率：为了提供高质量的音视频体验，需要充分利用网络带宽，这就要求网络传输算法具有高效的带宽探测能力。 延迟和响应时间：实时音视频应用要求快速的响应时间和超低延迟，这就要求网络传输技术具有快速的传输速度和低延迟的特性。 可靠性和稳定性：网络传输过程中可能会出现拥塞、丢包等问题，这会影响到音视频的质量和稳定性，因此要求网络传输技术具有可靠性和稳定性，能够保证数据的正确传输和恢复。 公平性和资源分配：在多用户场景下，需要保证网络传输的公平性和资源分配的合理性，以避免某些用户获得过多的资源，导致其他用户的服务质量下降。 除了上述挑战，实时音视频传输还需要关注体验指标，如实时性、流畅性、清晰度、音画同步性等，这些指标对于提供高质量的音视频体验至关重要。 1.1 现网音视频卡顿归因 为了快速提升线上用户弱网相关的体验，火山引擎根据抖音集团真实用户的负反馈数据打磨研发了“音视频卡顿归因模型”，它可以对线上音视频卡顿的所有 case 进行自动归因和聚类，为弱网问题的优化和优先级给出有效指导。 根据模型对线上用户音视频卡顿反馈的归因和聚类，我们发现，当前引起线上卡顿问题的主要原因是上下行大小缓存问题。 线上用户视频/音频卡顿归因类型占比 大小缓存的描述，可以参考：https://www.ietf.org/archive/id/draft-cardwell-iccrg-bbr-congestion-control-00.txt 大缓存：Deep buffers，at bottleneck links with deep buffers, congestion happens before packet loss. 小缓存：shallow buffers， in shallow buffers, packet loss happens before congestion. 1.2 RTC 主流拥塞控制算法分析 自 Google 开源 WebRTC 实时音视频框架以来，GCC 作为默认拥塞控制算法备受行业研究和关注，而 WebRTC 在演进过程中，也在不断演进集成 BBR、PCC 等拥塞控制算法，以期望进一步提升实时音视频的传输性能。 下文以 GCC 和 BBR 算法为例，我们来看一看当前主流拥塞控制算法的特性和不足。 1.2.1 GCC 算法 GCC 算法是专为实时音视频传输设计的拥塞控制算法，但随着网络环境日益复杂、音视频应用场景越来越丰富，GCC 算法难以提升上限以获得更好的音视频传输体验。