为将基于不同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这个库. 以及envoysarge. 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

引用文章

讲述MongoDB的开源许可证: [开源许可证,欢迎来到云时代]()https://3g.163.com/dy/article/HEHAH8HU0511CUMI.html)
开源软件许可证类型完整指南 2020

开源许可证分类

首先看是否是OSI(Open Source Initiative)认证的许可证, 包括: GPL MPL LGPL AGPL MIT BSD Apache. 其他, 包括SSPL(APGL + Common Clause), Elastic License V2.
在OSI之下, 分为Copyleft(著佐权)和Permissive(宽松许可证).
Copyleft会要求基于本软件的代码也要开源, Permissive则无此要求.
Copyleft包括GPL, 轻度Copyleft包括 CDDL MPL Eclipse.
Permissive包括MIT BSD Apache.

许可证排名

MIT Apache GPL

MIT

也称为X许可证或者X11许可证
MIT内容与条款3伯克利许可证(3-clause BSD license)内容颇为近似,但是赋予软件被授权人更大的权利与更少的限制。

  • 被授权人有权利使用、复制、修改、合并、出版发行、再授权及出售软件及软件的副本。
  • 被授权人可根据程序的需要修改授权条款为适当的内容。
  • 在软件和软件的所有副本中都必须包含版权声明和许可声明。
  • MIT的内容可依照程序著作权者的需求更改内容。此亦为MIT与BSD(The BSD license, 3-clause BSD license)本质上不同处。
  • MIT条款可与其他授权条款并存。另外,MIT条款也是自由软件基金会(FSF)所认可的自由软件授权条款,与GPL兼容。

Apache

Apache 许可证2.0和GNU GPL之间的区别

   GNU GPL是一个著佐权许可证。因此,使用GPL许可证组件的软件,必须发布其源代码,和所有修改及发行整个源代码的权利。Apache 许可证2.0 不强制这样的条款,不强制你发布修改过的版本。此外,你能选择使用不同的许可证发布你修改过的版本(然而,对未被修改过的代码,要求你保留Apache 许可证)。

    GPL中不包含特定的要求(这个要求指对程序做广告)。

在Apache2.0和伯克利之间的区别

   伯克利许可证是另一个高度宽松许可证,允许你修改和按照自己的意愿选择许可证,并再发行伯克利许可证下软件。早期Apache许可证和初版伯克利(后来修改版)许可证一样,但Apache2.0把二者区分开。这两者之间关键的区别:

明确授予专利权:Apache许可证2.0明确规定,当使用、修改或发行Apache许可证下的软件时,授予专利权;它也列出了撤销授予的情况。

清晰定义使用概念:Apache 2.0 清晰定义它所使用的所有的条款和概念,几乎不会引起歧义。

重复使用,不用改写:Apache2.0能很容易的被其他项目使用,无需对许可证文档本身做任何改写。