Esing的小站

组合逻辑与时序逻辑 我们如何定义组合逻辑和时序逻辑？ 组合逻辑 (Combinational Logic) ：输出只由当前输入决定，电路没有存储单元； 时序逻辑 (Sequential Logic) ：输出由当前输入和以前的输入(电路状态)决定，用来实现需要若干步骤问题的解决，同时电路中需要存储元件来保存以前输入形成的结果。典型例子便是状态机。 对于时序逻辑，我们又可以分为两类： 异步(Asynchronous)时序电路：没有时钟，存储单元输出的变化由输入信号决定 同步(Synchronous)时序电路：统一的时钟，存储单元输出的变化在时钟沿发生 这两类对应两种状态机：Mealy和Moore。 输出和当前状态及输入有关，则称为米利（Mealy）状态机 输出只和当前状态有关，则称为摩尔（Moore）状态机 双稳态电路 交叉耦合的反相器对可以构成一个双稳态电路。本质上是一个正反馈。 能量越低越稳定，因此中间的交叉点处是非稳态。只要有一点扰动，电压就会变化到1或者0，所以中间的交叉点是非稳态。 为了改变电路保存的状态，我们可以： 使用驱动强度更强的电路（强行覆盖） 断开反馈 ...

感谢Cloudflare提供的免费服务，让本项目得以实现。 在此向Cloudflare致以最高的敬意。 前言 参考上一篇博客：使用 Cloudflare Workers 搭建随机图片 API，我搭建了随机P站图片API，结果博客上一直加载不出来。折腾了一个小时后搞定，记录一下方法。 问题 本地起Hexo服务器预览图片正常，本以为是缓存问题，强制刷新页面也没有用。 打开github.io托管版本是没有问题的，非常奇怪。 排查 请求分析 对比了一下图片的请求，发现： 来自blog.esing.dev的图片请求没有附带上自己的Referer，因此被workers内的请求头检测拦下； 来自zxis233.github.io的图片请求正常带上了自己的Referer，因此能正常显示。 这就很奇怪了，毕竟我访问blog-dsx.pages.dev时，图片也是能正常携带Referer的。问题可能出在HTTP的响应头上。 实际上Referer是Referrer的错误拼写。由于早期HTTP规范中的拼写错误，为了保持向下兼容，只好将错就错。 HTTP头中的Referrer-Policy以及JavaSc ...

感谢Cloudflare提供的免费服务，让本项目得以实现。 在此向Cloudflare致以最高的敬意。 前言 看了BlueSkyXN的博客后，准备自己搭一个二刺螈随机图片API（毕竟网上找到的都良莠不齐）。他的博客提到了这个库：BlueSkyXN/RandomIMGAPI: 业内最简的原创随机图API源码。自己在西雅图的服务器上部署了一下，效果不错，就是每次请求会很慢，毕竟线路很差。目光自然又转向了Cloudflare。能不能用Cloudflare Workers实现呢？ 准备 功能正常的Cloudflare账号 一个托管在Cloudflare的域名 包含目标图片的GitHub库（比如我的：Zxis233/img2020S7: Pixiv 2020精选集 删除大量NSFW图片） 步骤 创建Cloudflare Workers 左侧栏找到“Workers与Pages”，点进去新建。模板直接选JS的Hello World就行 （注意不要选成Python的了） 部署完毕后编辑代码，将下面的代码粘贴进去： 1234567891011121314151617181920212223 ...

痛，并快乐着~

阈值损失 因为MOSFET的特性，导通时漏级始终比栅极有一个阈值电压的损失！ 对于NMOS，低电平时无损失，高电平时会降低一个 VTN 输出，因此使用NMOS进行下拉； 对于NMOS，高电平时无损失，低电平时会升高一个 |VTP| 输出，因此使用PMOS进行上拉。 伪NMOS逻辑门 伪NMOS两输入或非门 若其中一个输入为高，则输出为低；若两个输入均为高，则输出更低。可看成两个NMOS并联，尺寸翻倍。 对于瞬态，相同尺寸的或非门和反相器相比，寄生电容更大，因此速度更慢！ 伪NMOS两输入与非门 考虑工程近似，认为靠近输出的NMOS管无体效应，则可以将串联的NMOS管看成一个晶体管，尺寸减半。 多输入或非门可以将NMOS进行并联实现。下拉电流等于所有导通的NMOS管流过的电流之和。同理，多输入或非门可以将NMOS进行串联实现。 问：忽略PMOS管面积，两输入与非门的驱动能力与反相器相同时，与非门的面积与反相器相比是多少？ 答案4:1。 晶体管串联，串联后尺寸减半，因此等效后和反相器的NMOS尺寸相同，为1，则减半前的两个管子各自尺寸为2。2x2=4。 离输出端近的晶体管速度快！在 ...

嘉立创的免费SMT贴片券真的是太香了！大爱嘉立创！

延迟时间 传输延迟τPHL、τPLH定义为：在输入到输出波形的50％电压处（阈值电压）。 上升/下降时间τr、τf定义为10~90%的电压时间。 计算 长沟道CMOS τPHL=Cloadkn(VDD−VT0,n)[2VT0,nVDD−VT0,n+ln⁡(4(VDD−VT0,n)VDD−1)]τPLH=Cloadkp(VDD−∣VT0,p∣)[2∣VT0,p∣VDD−∣VT0,p∣+ln⁡(4(VDD−∣VT0,p∣)VDD−1)]\begin{aligned} \tau_{PHL}&=\dfrac{C_{load}}{k_n(V_{DD}-V_{T0,n})}\left[ \dfrac{2 V_{T0,n}}{V_{DD}-V_{T0,n}}+\ln\Big(\dfrac{4(V_{DD}-V_{T0,n})}{V_{DD}}-1\Big) \right] \\ \tau_{PLH}&=\dfrac{C_{load}}{k_p(V_{DD}-|V_{T0,p}|)}\left[ \dfrac{2 |V_{T0,p}|}{V_{DD}-|V_{T0,p}|}+\ln\B ...

“高性能ですから！”

前言 继先前使用 Cloudflare R2 存储桶搭建图床之后，为了再一次提高图片的访问速度，我采用了WebP Cloud Services来讲图片转为适合浏览器的现代化文件格式Webp。找了下，有一个Hexo博客插件hexo-webp-cloud-proxy可以方便的做到这一点。它可以很好的将所有的Post内图片链接转换成带有WebP Cloud的链接。 安装 npm install hexo-webp-cloud-proxy --save 问题 博客内含有GIF图，这玩意难以压缩，体积又大，很容易就把WebP Cloud的200M缓存吃光，因此我不打算处理它们。在Hexo根目录的_config.yml_插件设置内配置： 12345678910webp_cloud_proxy: enable: true # the suffix of img type to use webp cloud service convert_type_list: ["jpg", "jpeg", "png"] # your site ur ...

感谢Cloudflare提供的免费服务，让我得以在互联网上有一个小小的容身之地。 在此向Cloudflare致以最高的敬意。 前言 今天在整理博客的图片时，想起来Cloudflare还有免费的存储额度，即R2存储桶。GitHub上传图片也不错，但考虑到访问速度，我准备将图片迁移到Cloudflare。毕竟GitHub的图片引用也是采用CF反代GitHub的方法，那为啥不直接用Cloudflare呢？况且存储桶还可以自己选择存储区域，一定程度上还能提升大陆的访问速度。 准备 正常的Cloudflare账户 PicList（一个基于PicGo修改的云存储和图床平台管理工具） 一个托管在Cloudflare的域名 步骤 Cloudflare配置 创建R2存储桶 在CF的管理面板侧栏找到R2的选项，进入。第一次配置时会让你填写支付信息（但是只要在免费额度内就不会扣费）。我选择了PP作为支付方式。 之后会让你选择存储桶的位置和默认存储类。保持默认就行，或者你可以自己选择存储桶的地区。 创建完毕后进入存储桶的设置页面。找到“自定义域”的配置选项，这里可以将你托管在CF的域名和存储桶的访问域 ...