小石头的博客

uvm32 一个极简、无依赖的虚拟机，可用于嵌入式执行bin文件UVM32 是一个极简、无依赖的虚拟机沙盒，专为微控制器及其他资源受限设备设计。单 C 文件，无动态内存分配，异步设计，纯 C99。 uvm32 是一个 RISC-V 模拟器，采用管理接口，并配备了构建高效代码的工具。 这是干什么用的？ 作为嵌入式脚本引擎（Lua、Duktape、MicroPython 等）的简洁替代方案 作为一个沙盒 ，用于隔离系统中不可信或不可靠的元素 作为一种允许在现代系统编程语言中开发的方式，比如在可能没有目标编译器的情况下（rust-hello） 作为一种写入一次、随处运行 、避免维护多个软件变体的方法 特色 用 C、Zig、Rust 和汇编编写的字节码示例应用 非阻塞设计，防止不良的字节码导致主机停顿 没有对主机 IO 能力的假设（没有标准配置） 简单、带有主见的执行模型 安全的最小类型 FFI 体积小到能用“如果这样那个”的脚本/插件，也能支持更多 安全优先于速度，虚拟机中运行的糟糕代码绝不应该导致主机崩溃 https://github.com/TutuBinary/uv ...

双电源切换我们都很熟悉，也很常用，一般是一个外部电源加一个内部电池，外部电源优先级高于电池。有电池，电池给系统供电，有外部电源，外部电源给系统供电，两者都有时，外部电源给系统供电，同时也给电池充电，外部电源意外断电，内部电池会续上。 前段时间画了一个三电源切换电路，我们一起来看下： 电路描述： Q1、Q2为NMOS，Q3、Q4和Q5为PMOS管，D1为二极管。 BAT1和BAT2为电池，BAT2的容量比BAT1大，VIN_5V为外部电源，VOUT为输出，给系统供电。 VOUT会从优先级高的电源取电，优先用外部电源，其次容量大的电池，最后才是容量较小的电池，优先级排序：VIN_5V > BAT2 > BAT1。 工作原理： 接下来，我们再看一下电路的工作原理。 当只有BAT1时，Q2、Q3和Q5导通，VOUT从BAT1取电。 当只有BAT2时，Q1导通，Q2、Q3和Q5截止，Q4导通，VOUT从BAT2取电。 当只有VIN_5V时，VIN_5V通过二极管D1到VOUT，VOUT从VIN_5V取电。 当BAT2和BAT1同时存在，Q1导通，Q2、Q3和Q5截 ...

https://tools.liumingye.cn/music/?page=searchPage#/

https://codecv.top/

https://connectorbook.com/

前言这里主要收集一些免费字体网站 免费字体识别、字体转换、字体下载 https://fontmeme.com/zh/ ASCII码字体生成器 http://www.figlet.org/ google font https://fonts.google.com/

前言很多DCDC芯片的手册都有对应的PCB Layout设计要求，有些还会提供一些Layout示意图，都是大同小异的。 比如我随便列几点buck的设计要点： 输入电容器和二极管在与IC相同的面，尽可能在IC最近处。 电感靠近芯片的SW，输出电容靠近电感放置。 反馈回路远离电感，SW和二极管等噪声源。 那你知道这些要点都是怎么来的吗？ 如果拿到一个具体的芯片，因为芯片管脚分布的问题， 可能这些条件不能同时满足，那什么办？到底孰轻孰重？ 举个Buck的例子 比如下面这个buck，它的管脚分布就不好。 SW在IN和GND之间，如果按照要点，直接将输入滤波电容放到IN和GND旁边，那么SW的信号就出不来，而电感也要求放在芯片旁边，这就矛盾了。 那我们看看这个芯片手册推荐的Layout 芯片手册推荐的layout倒是都就近放置了，但是它的方法是SW在输入滤波电容底下走线， 这是逗我吗？这在现实中能做到？ 我们不能采用芯片手册推荐的这种方式，但事实是这种管脚分布的芯片多得是， 那我们的Layout如何布局布线呢？ 这个问题先不回答，我给大家说一个最根本的方法： DCDC的Layout终极奥 ...

前言对于Windows下开发，很多IDE都集成了编译器，如Visual Studio，提供了“一键编译”，编码完成后只需一个操作即可完成编译、链接、生成目标文件。 Linux开发与Windows不同，Linux下一般用的的gcc/g++编译器，如果是开发ARM下的Linux程序，还需用到arm-linux-gcc/arm-linux-g++交叉编译器。 Linux下也可以实现“一键编译”功能，此时需要一个编译脚本“Makefile”，Makefile可以手动编写，也可以借助自动化构建工具（如scons、CMake）生成。手动编写Makefile是Linux和Windows程序员的区别之一，一般地一个通用的Makefile能够适合大部分Linux项目程序。 这里提供了三个 Makefile 模板 编译可执行文件Makefile12345678910111213141516171819202122232425VERSION =1.00CC =gccDEBUG =-DUSE_DEBUGCFLAGS =-WallSOURCES =$(wildcard ./s ...

AT command 解析小组件AT command 在处理MCU端非常难处理，笔者接触到很好的框架如下: rt thread 代码下的小组件功能, 解析AT指令思路很巧 在源码目录下： rt-thread/components/net/at/src https://github.com/RT-Thread/rt-thread AT Command 代码库，将 AT 命令解析做了成了一个库的形式，可以借鉴参考 https://gitee.com/tutubinary/AT-Command

前言在日常工作中，软件和硬件工程师（Bug修复者）经常会碰到各种Bug，但很多时候我们的精力都浪费在了和测试人员（Bug提交者）反复沟通上，因为我们搞不懂测试人员想要表达啥？ 当你的软件或硬件出现不符合预期的问题时，我们希望它能够尽快修复，而不希望时间浪费在无效沟通上。 作为软件或硬件开发者，我们以工作为荣，但就像开发的任何方面一样，沟通至关重要。描述出了什么问题可能有些困难，但如果你能在一开始提供一个详尽的问题描述，这会加快问题的解决。 行业内对于如何描述Bug有各种思考，本文的三句话法是其中一种。下面的Bug模板用三句话来描述一个Bug： 复现 Bug 的步骤 步骤1 步骤2 … 2.期望的结果 3.实际的结果 复现步骤说明你是如何遇到错误或问题的，即使对你来说似乎很明显（对别人不明显）。 为什么提供重现错误的步骤很重要？ 重现错误通常比实际进行修复的代码更耗时；大约80%的工作是找出最初出了什么问题！清晰地重现步骤，意味着我们可以大大缩短这段时间。 对发生了什么问题有一个清晰的描述，也给我的测试人员后续验证Bug是否修复提供了步骤，利人利己！ 如何提供 ...