串口 常见的以太网、USB 等接口的数据传输方式都是串行的，但我们通常所说的串口（Serial Port），并非是指他们，而是符合 RS-232 标准的一种接口（也可以是 RS-485 、TTL 电平标准，通常是使用 DB-9 连接器的接口）。虽然早在几年前 DB-9 接口几乎从商用电脑上消失殆尽，但由于串口具有实现电路简单、使用方便等优点，它依然活跃在通信系统的各个领...

Intel HEX 是一种用 ASCII 文本表达二进制文件信息的文件格式，对于我们玩嵌入式的人来说并不陌生。本文有两个目的： 阐明 Intel HEX 的文件格式； 用 C 语言解析和生成 HEX 文件。 文件格式 Intel HEX 是以记录（ record ）为单位的，文件的每行存放一条记录。记录的基本格式为...

简介 树莓派（ Raspberry Pi ）是一块 ARM 开发板，由埃本·阿普顿（ Eben Epton ）发布，现托管在 Raspberry Pi 基金会（ https://www.raspberrypi.org/ ）。基金会以提升学校计算机科学及相关学科的教育，让计算机变得有趣为宗旨。这块只有信用卡大小的卡片式电脑开放了 GPIO、USB、以太网、影音输出等接口，本身没有存储设备，但留有一个 MicroSD 卡座，用于系统和数据的存储。正因为如此开放的设计和低廉的价格，已在电子和编程爱好者圈内风靡。是我们电子 DIY 或产品快速原型设计的一个好平...

U：骗子，你是骗子！ I：呃……不，不是我欺骗了你，是你那自以为聪明的脑袋骗了你。 U：从何说起？！ I：从光波说起...

儿时的灯 儿时的白炽灯还依稀地亮在脑海的夜里。沾满了灰尘有些发黑的玻璃泡里，“W” 状的灯丝挂在那里，昏黄而又无力。那时经常停电倒是其次，在不同时段里，随着用电负荷的变化，灯的亮度也在不断地变化着。所以那个时候调压器成了电视机的伴...

当我们实现了控制界面，剩下的问题如何把选择的颜色信息（ RGB ）告诉 LED 驱动板，常用的方式就是串口了。对于单片机来说更为专业的叫法是 Uart 口，即 Universal Asynchronous Receiver/Transmitter（通用异步收发器）接...

控制 LED 的上位机可以是 PC，也可以是 Smart Mobile、Pad 。可以使用 Windows 系统，也可以使用 Linux、Android 系统。考虑到跨平台的便利性和语言之间的关联性，我选用了 Python + PyQt 的搭配。既能利用 Python 的良好的跨平台能力和便捷的编程，又能在界面库上向 C++ Qt 靠...

从寻觅远古岩画到见证印象画派的繁荣，在看得见的历史长河里，绘画艺术家们对色彩的追求和运用技法的研究从未停歇。从雷火到那些神神叨叨魔法术士炉子里幻化着的各色鬼火、圣火，那些跳动着的，闪耀着的，难以捉摸。当一缕阳光穿过牛顿手里的棱镜而变得理性，当一星火花迸发在伏特的线头而将不再神秘。这时的我们（就叫 “The Light Maker” 吧），才刚刚出...

在 GitHub 的 Markdown（GFM）中，实现提示、警告等醒目提示框非常简单，它基于块引用（Blockquote）语法进行了扩展。你只需要掌握一个固定的格式即可。 基本语法格式 核心格式是在块引用的第一行使用特殊标记 [!TYPE]，后续内容正常以 >开头： > [!TYPE] > 这里放你的提示内容，支持**加粗**、*斜体*、`代码`、列表等大部分 Markdown 语法。 注意：[!TYPE] 中的类型关键字（如 NOTE, WARNING）必须大写。 支持的 5 种类型 GitHub 目前官方支持以下 5 种提示类型，它们在渲染时会带有不同的颜色、图标和标题： [!NOTE]（蓝色） 用途：补充说明，用户快速浏览时也应注意的有用信息。 [!TIP]（绿色） 用途：建议或小贴士，帮助用户更轻松或更好地完成操作。 [!IMPORTANT]（紫） 用途：用户达成目标必须知晓的关键信息。 [!WARNING]（黄色/橙色） 用途：急需用户注意的内容，避免潜在问题或风险。 [!CAUTION]（红色） 用途：强烈警告，提示某些动作可能导致负面后果（如数据丢失）。 代码示例： > [!NOTE] > 这是一条补充信息。 > [!TIP] > 这是一个小技巧。 > [!IMPORTANT] > 这是关键信息。 > [!WARNING] > 警告，存在潜在风险。 > [!CAUTION] > 危险操作，请极其小心。 解析效果（取决于解释器）： Note 这是一条补充信息。 Tip 这是一个小技巧。 Important 这是关键信息。 Warning 警告，存在潜在风险。 Caution 危险操作，请极其小心。 使用注意事项 适用范围：支持在 README.md、.md文件、Issues、Pull Requests、Discussions、Gists 中渲染。 内容支持：提示框内部支持完整的 Markdown 语法，包括段落、列表、代码块、图片等。 使用建议：官方建议仅在对用户成功至关重要时才使用，且尽量限制每篇文章 1 - 2 个，避免连续堆叠使用，防止读者视觉疲劳。 兼容性：这是 GitHub 的扩展语法。在不支持该特性的其他 Markdown 渲染器（如某些旧版编辑器）中，它会降级显示为普通的块引用，不会破坏文档结构...

在分布式系统和数据库设计中，“如何生成一个唯一的ID” 一直是个经典话题。我们最熟悉的可能是 UUID，但它也有不少槽点：无法排序、存储占用大、可读性差。今天给大家介绍一个非常有潜力的替代品 —— ULID（Universally Unique Lexicographically Sortable Identifier）。 什么是 ULID？ ULID 的全称是 通用唯一词典分类标识符。简单来说，它是一种既能保证全局唯一，又天然支持按时间排序 的标识符。 它的设计目标很明确： 全局唯一：不怕分布式环境下的冲突 时间有序：生成顺序 = 时间顺序 紧凑可读：比 UUID 更短、更友好 ULID 长什么样？ 一个标准的 ULID 看起来是这样的： 01H4Z7X8J7F9VYMQK7Z9G9Z9Z9 它是基于 Crockford's Base32 编码的（包含 0–9和 A–Z，去除了 I、L、O、U 以避免混淆），生成的字符串通常统一显示为大写，解码时大小写不敏感。 ULID 的结构 ULID 一共 128 位（16 字节），分为两部分： 部分 长度 作用 时间戳 48 位 Unix 毫秒时间（1970–2088） 随机数 80 位 保证唯一性 ┌─────────────── Timestamp (48 bits) ───────────────┐ ┌───────────────────────────────────────────────────┐ │ Time │ Randomness │ └───────────────────────────────────────────────────┘ 为什么要选 ULID？ 1、全局唯一性 ULID 结合了时间 + 随机数，即使在高并发的分布式环境中，碰撞概率也极低。 2、天生支持排序 因为时间戳在最前面，ULID 天然按时间递增。你可以直观地看到，随着时间推移，前面的字符会变大： 01H4Z...（较早） 01H5A...（较晚） 这意味着： 数据库按主键排序 ≈ 按时间排序 不需要额外的时间字段 查询更快，索引更高效 Tip 不要试图在 Windows 11 的资源管理器里按文件名排序来验证 ULID 文件名的时间排序，因为该资源管理器目前只支持自然排序。可以尝试换其他资源管理器或在命令行中列出文件。 3、比 UUID 更紧凑 类型 长度 示例 UUID 36 字符 550e8400-e29b-41d4-a716-446655440000 ULID 26 字符 01H4Z7X8J7F9VYMQK7Z9G9Z9Z9 更短 不含 - 更适合 URL / 文件名 4、高性能 & 去中心化 ULID 的生成： 不需要中心服务器 不需要锁 本地即可生成，非常适合微服务、消息队列、日志系统 5、跨平台支持 主流语言几乎都有成熟实现：Java / Go / Python / Rust / JavaScript。 什么时候不该用 ULID？ 虽然 ULID 很香，但并不是万能药。以下场景请慎重考虑： ❌ 需要完全随机且无规律的 ID 如果你的业务要求 ID 不能泄露任何时间信息（例如用于订单号防止被爬虫推测销量），ULID 的前缀时间戳可能会暴露生成频率和时间。这种情况下，UUIDv4 这种完全随机的方案更安全。 ❌ 需要绝对连续且无空洞的 ID ULID 是“趋势递增”，不是“绝对连续”。由于随机部分的存在，它会有空洞。如果你的系统要求 ID 必须严格连续（1, 2, 3...），ULID 不适合。 ❌ 存储空间极度敏感 虽然比 UUID 短，但如果是海量数据且不需要排序，单纯的整型自增 ID（Int/Long）仍然是最省空间的。 ULID 适合用在哪些场景？ 日志系统 按时间生成、天然有序，非常适合做日志追踪 ID。 分布式系统 不依赖数据库自增 ID，避免单点瓶颈。 数据库主键 B+Tree 索引友好，写入性能更好。 消息队列 消息 ID 自带时间顺序，消费端更容易处理。 总结 ULID 是一个兼顾“唯一性、时间排序、紧凑性”的现代分布式 ID 方案。如果你正在寻找一个比 UUID 更优雅、比雪花算法更简单的方案，不妨试试 ULI...