2022年9月

为将基于不同MCU/不同编译环境/不同产品功能的嵌入式项目能统合在一起编译, 提出这个分层模型.

层级 层名 解释 硬件相关性 产品型号相关性
8 编译层 为方便项目快速编译而开发的批处理文件(如.bat), 可进行dev/build/release等操作,不同产品通过f5y_config.bat配置文件修改 有 (多数)有
7 配置层 用于配置产品型号,版本,功能等信息,C语言统一为proj_conf.h 有 有
6 功能层 提供各种产品的各种功能,与硬件解耦, 分功能子层func.c/h和驱动测试子层driver_tester.c/h - 有
5 驱动层 上驱动层driver.c/h对功能层提供标准驱动接口, 下驱动层修改必要的SDK示例内容以实现不同产品功能的兼容 有 有
4 项目层 为编译使用的项目文件, uv5.proj文件或.mk文件等 有 (多数)有
3 SDK层 为原生SDK, 可能在硬盘的其他位置 有 (多数)无
2 编译器层 为编译器文件, 如uv4.exe, gcc.exe等, 在硬盘其他位置安装 有 无
1 硬件层 为基于不同MCU的实际硬件, 如C51的某型号产品PCB, ESP8266某型号PCB等 有 有

项目生成的固件一般放置在firmware目录中
4~8层在一个集合目录中, 3层SDK看实际情况放置

U430 touch前几年启动巨慢无比,得半小时到一两个小时, 还得看运气. 后来发现是用作缓存的16G建兴SSD坏掉了, 我估计是超出了写入寿命. 于是闲鱼上买了个威刚的240G二手SATA 2242 SSD. 注意这个型号, 2242不是通用的, 而是联想和hp等笔记本厂家的专属型号, 市面上很难买到,新品只有金胜维, 价格过于便宜, 不太敢买. 闲鱼有大量威刚240G的HP拆机条, 似乎要保险一些.
买回来刚装上发现读取速度还可以但写入速度极慢(10M/S上下), 4K随机读取只有2M/S左右, 解决方式似乎是: 设备管理器->磁盘驱动器->属性->策略,勾选启动设备上的写入缓存. 并且所有盘都要勾上.
另外发现设备管理器->磁盘驱动器的SSD名称还是旧的LITEON 16G, 需要删掉重新发现才变正常.
Intel有一个Intel RST快速存储技术, 另外联想官方还能下载一个ExpressCache软件, 似乎和intel RST作用类似.
已经安装的ExpressCache有问题无法运行且很难删除, 主要是服务不能删除. 我在安全模式下禁用了Intel RST服务和ExpressCache服务, 再回到正常模式下才删除. 然后重新安装, 其中重启了好几次. 安装ExpressCache前, 需要在SSD盘上预留一些未分配空间, 我留了40多G, 安装完重启后, ExpressCache自己取了其中的32G来用.
ExpressCache安装后再次要是命令行操作. 管理员打开命令行输入eccmd -info可以看到当前缓存信息.
值得注意的是, 刚刚安装好ExpressCache, 管理员身份似乎不能马上运行, 如services.msc等需要管理员身份的程序一开始运行会报错, 要过一会儿才行, 似乎是在等待缓存到SSD?

参考: https://mp.weixin.qq.com/s/aNC6cgLSrK3dzrlwbaDzOA
日本人长寿, 男性人均81, 女性87, 现在养老负担及其重, 占到GDP的大头. 日本政府不堪重负, 用尽各种招数:

  • 延长退休年龄, 从最初的55延长至65, 现在又鼓励延长至70
  • 削减养老金, 降低退休工资
  • 扩大养老保险参保范围, 将以前交不起/不符合条件的人也纳入来缴纳养老金, 并口头承诺提高退休后收益
  • 海外养老计划, 让房地产公司在低成本国家建设日本养老村, 出国养老, 又被人诟病为弃母山计划
  • 社会5.0计划, 通过高科技远程医疗, 智能管家辅助, 让老人可以自主居家养老, 但似乎也是单纯的幻想
    然而现状是:
  • 日本老人退休金养不起自己, 人均每月缺口2000多元, 靠自己的积蓄生活
  • 积蓄花完, 有些老人自杀, 有些老人偷盗入狱, 去监狱享受免费养老
  • 日本65岁以上老人自杀率和犯罪率都逐年升高, 有的监狱40多个犯人平均年龄达到了70多岁
  • 同时, 日本生育率又很低, 劳动力人口短缺, 生育欲望萎靡
    从目前来看, 中国已有端倪. 去年人口统计仅增长几十万, 预计今年将迈入负增长. 虽然放开了三胎,但并没有形成预期的生育潮. 退休金总额不足也已经被讨论过. 同时国家不断吹风要延迟退休年龄. 劳动力不足加上老龄化社会到来, 最糟的情况可能比日本还糟, 未到达富裕就先衰退了.
    挑战与机遇并存. 老年人作为人要满足基本的生存需求. 在我国如果退休金很少甚至没有的老年人, 国家应该有低保户之类的兜底政策, 出现自杀或者偷盗犯罪的可能性要低于日本. 另外强制提高上班族的养老保险可能也是不得不做的政策, 并且政策推行不会像日本社会那么有阻力. 在其他国家或者省份建立养老村这样的措施,可能因地而异. 有些地方的老人可能不愿意离开故土, 而有些地方则比较开放, 或者是逼到一定程度则不得不离开. 海南那么多东北人的聚居小区也说明了这个政策一定程度是可行的, 尤其房地产现在增长乏力, 必然会想这样的方式结合国家政策推出异地养老房.
    老人有几个方面的需求, 一个是生存, 吃喝拉撒衣食住行, 这个每天都需要钱; 二是医疗, 老年人基础病更多, 虽然不一定每天需要费用, 但是一旦有需要就是很大的费用. 三是交流, 老人往往孤独, 这个不见得需要钱, 但需要让一群老人们可以每天很方便的见面.
    需求由问题引发. 关于钱, 前几年还有租房养老或者卖房养老的问题和报道, 说明很多老年人退休就已经没有足够积蓄和养老金维持生活了. 这些年不报道了并不能说明问题已经消失了. 而关于孤独, 报道则比较少, 现在国内似乎认为孤独是很个体的事情, 并不需要什么常态化机制去解决; 这应该是群体认识和人文关怀还比较初期, 未来应该是会重视起来.
    我想, 总的趋势是国家养老负担越来越重, 平均到每个老人手里的钱也越来越少, 即便能保底, 也不能保证很好的生活质量. 因此对于日用品来说, 需要便宜耐用, 且非常安全, 减少疾病的可能, 这样的产品和品牌应该会更受欢迎. 对于医疗救助需要及时便捷, 可以自助, 减少对他人的依赖, 这样的产品和措施应该也会很受欢迎.
    对于日常沟通交流来说, 一是需要有一个便捷的遮风挡雨的容纳空间的, 农村中倒是容易, 而在拥挤的城市中真是个问题. 二是需要有空闲, 城市里老人似乎都是忙着带小孩, 小孩上学又要忙着准备饭菜, 抽不出空隙来. 三是要有共同语言, 需要固定的一些老人们在一起做做同样的事情, 才能建立起交流来.

看了Linus的一些新闻, 吐槽C++, 决定引入Rust也不用C++, 引起的我的好奇, 并在知乎上找了一些文章, 看大家怎么评价的:
https://www.zhihu.com/question/25535134
https://www.zhihu.com/question/266995763
https://www.zhihu.com/question/30292024
C和C++一直都是并列写作C/C++的, 包括很多教材也都这么写, 不知道何时开始这么不共戴天了? 我2000年前后开始学C/C++, 后来进华为开发, 虽然用的还是C但是IDE是微软的Visual C++ 6.0, 这俩看起来跟好的不能再好的哥们一样的编程语言竟然暗地里结了这么深的梁子?
现在来看, C++诞生于1983年, 在1998年才第一次被标准化. 这和Windows的诞生几乎是同时代的. Windows1.0发布与1985年, 到1995年之后的Win95/98风靡世界, GUI开发成为最重要的开发目标. 所以C++语言有两个野心, 一个是替代C, 另一个是成为GUI的开发标准. 从前面的各个吐槽来看,这么多年以来, 在底层开发领域C的地位也没有被C++取代,反而在上层应用领域有了很多的替代, 包括服务器端和安卓端的Java, IOS端的OC, H5的Javascript, 游戏脚本Lua, 万能语言Python, 多线程Go. 还有Linus青睐的Rust.
以前以为Qt只能用C++开发, 现在发现居然有一个QtScript, 是ECMAScript的实现. 在Qt的官网发现, 现在QtScript似乎已经被替换成了额QML(像是XML/HTML的变形),也支持Python了. Qt可以在LGPL下开发,也可以通过商业许可证购买.

本来用了多年的ES文件管理器,最近总是弹出一个广告, 弹出也就罢了, 关闭按钮给的黑小还有给了一真一假两个, 每次都按错. 心想这么多年买个会员吧, 定价又有点儿超预期😅
然后评测了其他的文件管理器, 需要G Play下载

  • Total Commander. 老牌管理器了, 不过默认版本不支持SMB, 还需要额外下载插件, UI体验不好.
  • Amaze File Manager. alternativeto高分推荐, 不过却不支持SMB.
  • File Commander. 还不错, 有广告但只在最下面.
  • CX文件管理器. 非常好, 没有广告, 支持SMB.

找了好久, 一开始的方案是 subprocess.Popen, 结果发现能收不能发, 能发不能收. 很郁闷.
发的代码:

import subprocess
import time
proc = subprocess.Popen(["a.exe"], stdin=subprocess.PIPE)
p=proc
p.stdin.write(b'asdf')
time.sleep(1)
p.stdin.write(b'2q3w')
p.stdin.write(b'zxcv')
p.communicate()
p.wait() # wait for the subprocess to exit
print("py finished")

收的代码:

import subprocess
import time
proc = subprocess.Popen(["a"], stdout=subprocess.PIPE)
p=proc

with p.stdout:
    for line in iter(p.stdout.readline, b''):
        print(line)

p.wait() # wait for the subprocess to exit
print("py finished")

直到有位大哥提到了Pexpect这个库. 以及envoy和sarge. https://stackoverflow.com/questions/10872767/differences-between-subprocess-module-envoy-sarge-and-pexpect

node的expect版本也有, 叫做node-suppose

sarge

发现sarge是比较好的解决方案:

import sys
from time import sleep
from sarge import Feeder, run, Capture

feeder = Feeder()
p = run(['a'], input=feeder, stdout=Capture(), async_=True)
sleep(1)
feeder.feed('Hello')
print(p.stdout.readline())
print(p.stdout.readline())
print(p.stdout.readline())
print(p.stdout.readline())
print(p.stdout.readline())
print(p.stdout.readline())
print(p.stdout.readline())
print(p.stdout.readline())
print(p.stdout.readline())
sleep(1)
feeder.feed('Yes')
sleep(1)
print(p.stdout.readline())
print(p.stdout.readline())
print(p.stdout.readline())
print(p.stdout.readline())
print(p.stdout.readline())
print(p.stdout.readline())
print(p.stdout.readline())
print(p.stdout.readline())
feeder.feed('Man')
sleep(1)
print(p.stdout.readline())
print(p.stdout.readline())
print(p.stdout.readline())
print(p.stdout.readline())
print(p.stdout.readline())
print(p.stdout.readline())
print(p.stdout.readline())
print(p.stdout.readline())
feeder.close()
p.close()

监控键盘输入

pynput