小石头的博客

C4：4个函数实现的C语言编译器 (C语言脚本解释器)它是一个C语言编译器项目，整个实现只有： 一个C语言源码文件 528行C语言代码 4个函数 仅此而已。 它简洁，却不简单。 https://github.com/TutuBinary/c4.git PicoC :PicoC 是一款非常小的 C 脚本解释器PicoC是一个轻量级的C语言编译器，它可以将C语言源代码编译成可执行文件。 核心 C 源代码大约有 3500 行。它并非 ISO C 的完整实现，但它具备所有基本功能。编译后，它仅占用几 k 的代码空间，并且非常节省数据空间。这意味着它可以在小型嵌入式设备中很好地工作。它也是一个有趣的示例，展示了如何创建非常小的语言实现，同时仍保持代码的可读性。 https://github.com/jpoirier/picoc QuickJSQuickJS是一个小型并且可嵌入的Javascript引擎，它支持ES2020规范，包括模块，异步生成器和代理器。 它可选支持数学扩展，例如大整数 (BigInt)，大浮点数 (BigFloat) 以及运算符重载。 https://gi ...

双电源切换我们都很熟悉，也很常用，一般是一个外部电源加一个内部电池，外部电源优先级高于电池。有电池，电池给系统供电，有外部电源，外部电源给系统供电，两者都有时，外部电源给系统供电，同时也给电池充电，外部电源意外断电，内部电池会续上。 前段时间画了一个三电源切换电路，我们一起来看下： 电路描述： 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是否修复提供了步骤，利人利己！ 如何提供 ...